Quá nhiều lỗi xác thực cho * tên người dùng *


256

Tôi có một tài khoản hostgator với quyền truy cập ssh được kích hoạt. Khi cố tải lên tệp khóa .pub đã tạo bằng lệnh này:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Tôi tiếp tục nhận được:

Đã ngắt kết nối từ 111.222.33.44: 2: Quá nhiều lỗi xác thực cho tên người dùng
rsync: kết nối bị đóng đột ngột (nhận được 0 byte cho đến nay) [người gửi]
lỗi rsync: lỗi không giải thích được (mã 255) tại io.c (601) [sender = 3.0.7]

Tôi đã từng đùa giỡn với ssh trước đây cho đến khi tôi bị lỗi auth. Nhưng bây giờ có vẻ như bộ đếm lỗi auth không thiết lập lại (đã đợi hơn 12 giờ rồi, bộ phận hỗ trợ kỹ thuật "giả sử" nó đặt lại sau 30 phút đến 1 giờ và một anh chàng khác nói với tôi "nó đặt lại mỗi khi bạn cố gắng đăng nhập tên người dùng ", jeesh).

Điều này là lái xe cho tôi hạt. Tôi thậm chí đã thiết lập điều này trong một máy chủ tùy chỉnh Slicehost và có ít vấn đề hơn so với những người này.

Lời khuyên nào? Có lẽ đó là một cái gì đó phía khách hàng và không phải phía máy chủ.


Trong trường hợp của tôi, có một lỗi trong việc tạo khóa. Tôi đã tạo một khóa và tôi đã bỏ lỡ đề cập đến địa chỉ nguồn và tên người dùng được sử dụng ở cuối khóa.
phóng viên

Câu trả lời:


416

Điều này thường được gây ra bởi việc vô tình cung cấp nhiều khóa ssh cho máy chủ. Máy chủ sẽ từ chối bất kỳ khóa nào sau khi có quá nhiều khóa được cung cấp.

Bạn có thể tự mình nhìn thấy điều này bằng cách thêm -vcờ vào sshlệnh của bạn để có được đầu ra dài dòng. Bạn sẽ thấy rằng một loạt các khóa được cung cấp, cho đến khi máy chủ từ chối kết nối với nội dung: "Quá nhiều lỗi xác thực cho [người dùng]" . Nếu không có chế độ dài dòng, bạn sẽ chỉ thấy thông báo mơ hồ "Thiết lập lại kết nối theo ngang hàng" .

Để ngăn các khóa không liên quan được cung cấp, bạn phải chỉ định rõ ràng điều này trong mỗi mục nhập máy chủ trong ~/.ssh/configtệp (trên máy khách) bằng cách thêm IdentitiesOnlynhư vậy:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Nếu bạn sử dụng tác nhân ssh, nó sẽ giúp chạy ssh-add -Dđể xóa danh tính.

Nếu bạn không sử dụng bất kỳ cấu hình máy chủ ssh nào, bạn phải xác định rõ ràng khóa chính xác trong sshlệnh như sau:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Lưu ý: tham số 'Nhận dạng Chỉ có có' cần có giữa các dấu ngoặc kép.

hoặc là

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

5
nó không rõ ràng cho tôi nơi để đặt dòng này. Trên máy chủ mà tôi đang cố đăng nhập, .ssh / config chỉ có thông tin cho các máy chủ khác. Bạn có nghĩa là điều này sẽ đi vào tệp .ssh / config trên máy tính mà tôi đang cố gắng ssh từ? Nếu vậy, điều này không rõ ràng vì câu trả lời của bạn cho biết "một khi bạn đã đăng nhập lại ..."
David LeBauer

2
Tôi phải đặt tùy chọn trong dấu ngoặc kép, như thế này:ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/
knb

1
Người dùng Windows đang chạy PAGENT (Putty Agent), kiểm tra để đảm bảo bạn chỉ có các khóa bạn cần tải. Tôi gặp vấn đề này sau khi vô tình tải TẤT CẢ các khóa riêng của mình.
Chris Rasco

2
Câu hỏi vẫn còn: tại sao ssh"cung cấp nhiều khóa" (bất cứ điều gì bên dưới ~/.ssh) ngay cả khi quy tắc cho máy chủ lưu trữ có IdentityFile /path/to/private_key_filecài đặt rõ ràng . Không nên khóa được chỉ định rõ ràng này (ít nhất là) được cung cấp đầu tiên? Đây không phải là một lỗi / lỗi sai trong máy khách openssh sao?
thân

2
Nhưng nó không nên sử dụng khóa được chỉ định với IdentityFiletùy chọn? Ví dụ, không có IdentitiesOnlytùy chọn, nó cố gắng sử dụng githubkhóa của tôi khi tôi cố gắng ssh gitlab.com. Không có nghĩa lý gì.
Iulian Onofrei

188

Tôi tìm thấy một cách dễ dàng hơn để làm điều này (nếu sử dụng xác thực mật khẩu):

ssh -o PubkeyAuthentication=no username@hostname.com

Điều này buộc xác thực không chính. Tôi đã có thể đăng nhập ngay lập tức.

Tài liệu tham khảo


3
+1, ước gì tôi có thể cho bạn nhiều hơn. Raspberry Pi là thiết bị duy nhất tôi ssh vào mà không có khóa chung. Đã nhận được: "Quá nhiều lỗi xác thực cho pi"
blak3r

1
Và để sử dụng điều đó với rsync:rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file'
Ciro Santilli 心 心 六四 事件

1
Bạn cũng có thể tạo Bí danh để nhanh hơn cho việc xác thực mật khẩu. bí danh sshp = 'ssh -o PubkeyAuthentication = no'
dhempler

26

Tôi cũng đã gặp lỗi này và thấy rằng nó đã xảy ra b / c máy chủ được cấu hình để chấp nhận tối đa 6 lần thử:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

Ngoài việc thiết lập IdentitiesOnly yestrong ~/.ssh/configtệp của bạn, bạn có một vài tùy chọn khác.

  1. Tăng MaxAuthTries(trên máy chủ ssh)
  2. xóa một số cặp khóa bạn có trong ~/.ssh/thư mục của bạn và chạyssh-add -D
  3. liên kết rõ ràng một khóa với một máy chủ nhất định trong ~/.ssh/configtệp của bạn

Thích như vậy:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo
  1. Có lẽ không phải là một cách hay để làm điều đó, vì nó làm suy yếu máy chủ ssh của bạn một chút vì giờ đây nó sẽ chấp nhận nhiều khóa hơn trong một nỗ lực kết nối nhất định. Hãy nghĩ rằng vectơ tấn công vũ phu ở đây.

  2. Đây là một cách hay để giả sử bạn có các khóa không cần thiết và có thể bị xóa vĩnh viễn.

  3. Và cách tiếp cận của việc thiết lập danh tính có lẽ là những cách ưa thích để xử lý vấn đề này!


Trong dòng cuối cùng của bạn, bạn đã xác định /home/YOU/.ssh/foo nhưng nó phải là nhận dạng (không phải là f)
Nin

7

Tôi đã thêm vào ~ / .ssh / config này:

Host *
IdentitiesOnly yes

Nó cho phép tùy chọn IdentitiesOnly = yes theo mặc định. Nếu bạn cần kết nối với khóa riêng, bạn nên chỉ định nó với tùy chọn -i


6

Nếu bạn gặp phải lỗi SSH sau:

$ Received disconnect from host: 2: Too many authentication failures for root

Điều này có thể xảy ra nếu bạn có (mặc định trên hệ thống của tôi) năm hoặc nhiều tệp nhận dạng DSA / RSA được lưu trữ trong thư mục .ssh của bạn và nếu tùy chọn '-i' không được chỉ định trong dòng lệnh.

Đầu tiên, khách hàng ssh sẽ cố gắng đăng nhập bằng cách sử dụng từng danh tính (khóa riêng) và lời nhắc tiếp theo để xác thực mật khẩu. Tuy nhiên, sshd giảm kết nối sau năm lần đăng nhập xấu (một lần nữa mặc định có thể thay đổi).

Nếu bạn có một số khóa riêng trong thư mục .ssh, bạn có thể tắt "Xác thực khóa chung" tại dòng lệnh bằng cách sử dụng đối số tùy chọn '-o'.

Ví dụ:

$ ssh -o PubkeyAuthentication=no root@host

Đây chính xác là những gì đã xảy ra với tôi! Cảm ơn rất nhiều vì lời giải thích;)
El Ninja Trepador

6

Nếu bạn có mật khẩu và chỉ muốn sử dụng mật khẩu để đăng nhập, đây là cách bạn thực hiện.

Để sử dụng xác thực mật khẩu CHỈ và KHÔNG sử dụng khóa công khai và KHÔNG sử dụng "tương tác bàn phím" hơi sai lệch (là một superset bao gồm mật khẩu), bạn có thể thực hiện việc này từ dòng lệnh:

ssh -o PreferredAuthentications=password user@example.com

3

Tắt @David, chỉ cần thêm nó IdentitiesOnly yes vào .ssh / config của bạn, nó thực hiện tương tự nhưssh -o PubkeyAuthentication=no.

Sau khi bạn đăng nhập, loại bỏ .ssh/authorized_keys. Bây giờ, quay trở lại máy cục bộ và gõ như sau

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Điều này sẽ kích hoạt lại ssh của bạn với khóa chung


2

Tôi biết đây là một chủ đề cũ, nhưng tôi chỉ muốn thêm vào đây rằng tôi gặp phải thông báo lỗi tương tự, nhưng nguyên nhân là do chủ sở hữu của thư mục .ssh là root chứ không phải người dùng đang sử dụng khóa. Tôi đã khắc phục sự cố bằng cách chạy các lệnh sau:

sudo chown -R user:user /home/user/.ssh

Tôi cũng đảm bảo rằng các quyền là chính xác trên thư mục .ssh:

sudo chmod 700 /home/user/.ssh

Các tệp trong thư mục .ssh phải có sự cho phép của 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

Tôi sẽ cẩn thận với việc sử dụng này mà không cần cảnh báo. Quyền khóa SSH thường bị giới hạn ở mức 400 đối với một số khóa, cụ thể là AWS. Cố gắng đặt chúng ở trên sẽ dẫn đến khóa không được chấp nhận và điều đó có thể khóa bạn khỏi tài khoản AWS của bạn.
Michael Ryan Soileau

1

Trong trường hợp của tôi, vấn đề là quyền thư mục. CÁi này đã sửa nó giúp tôi:

$ chmod 750 ~;chmod 700 ~/.ssh

0

Trong trường hợp của tôi, điều đó đã xảy ra vì tôi đang sử dụng tên người dùng "ubfox", nhưng tên người dùng trong trường hợp này là "ec2-user"

Sau khi tôi làm những gì "John T" đề xuất, tôi đã gặp lỗi này:

Quyền bị từ chối (khóa công khai).

Sau đó, tôi đã tìm thấy giải pháp (nghĩa là thay đổi tên người dùng thành "người dùng ec2") trong câu trả lời này: https://stackoverflow.com/questions/1454629/aws-ssh-access- allow-denied-publickey-su


0

Tôi đã có khóa công khai của mình .ssh/authorized_keys2, nhưng máy chủ được cấu hình để chỉ đọc .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Sau khi chuyển tệp của tôi sang .ssh/authorized_keys, tôi có thể đăng nhập thành công bằng khóa của mình.


0

Quá nhiều lỗi xác thực

Thông báo này được gây ra bởi có quá nhiều lần thử xác thực không thành công với các giới hạn cho phép được thi hành trên máy chủ SSH từ xa. Điều này có khả năng có nghĩa là bạn đã thêm quá nhiều danh tính trong tác nhân SSH.

Dưới đây là một vài gợi ý:

  • Thêm -vđể xem nếu đó là trường hợp (bạn đã sử dụng quá nhiều danh tính).
  • Danh sách thêm danh tính bằng ssh-add -l.
  • Xóa danh tính không thành công từ đại lý bằng cách : ssh-add -d.
  • Bạn cũng có thể xóa tất cả các danh tính bằng cách ssh-add -Dchỉ thêm lại một danh tính.
  • Nếu bạn đã truy cập vào máy chủ SSH, hãy kiểm tra MaxAuthTriestùy chọn (xem man sshd_config:).

    Bài đăng liên quan: Kết nối cho sshd_configgiới hạn 'MaxAuthTries' là gì?

  • Nếu không có sự giúp đỡ này, hãy đảm bảo rằng bạn đang sử dụng đúng thông tin hoặc tệp.


-1

Thông báo này có thể xuất hiện khi tên người dùng và mật khẩu chính xác không được nhập.

Trước tiên hãy kiểm tra xem người dùng có được liệt kê không:

vim /etc/passwd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.