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


Tôi có một tài khoản hostgator với quyền truy cập ssh được kích hoạt và khi cố gắng tải lên tệp .pub được 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 khỏi 111.222.33.44: 2: Quá nhiều xác thực thất bại đối với tên người dùng
rsync: kết nối bất ngờ bị đóng (0 byte nhận được cho đến thời điểm này) [người gửi]
lỗi rsync: lỗi không giải thích được (mã 255) tại io.c (601) [người gửi = 3.0.7]

Tôi đã từng đùa giỡn với ssh cho đến khi tôi bị thất bại. Nhưng bây giờ có vẻ như bộ đếm auth failure không reset (đã chờ hơn 12 giờ rồi, hỗ trợ kỹ thuật "giả sử" nó reset sau 30 phút đến 1 giờ, và một người khác nói với tôi "nó reset mỗi khi bạn cố đăng nhập với 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 với những kẻ này. Bất kỳ mẹo 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ủ.


223
2017-09-12 17:14


gốc




Các câu trả lời:


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

Bạn có thể thấy điều này cho chính mình bằng cách thêm -v gắn cờ với bạn ssh lệnh để có được đầu ra tiết. 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 nói rằng: "Quá nhiều lỗi xác thực cho [người dùng]". Nếu không có chế độ tiết, bạn sẽ chỉ thấy thông điệp mơ hồ "Kết nối được thiết lập lại bởi peer".

Để 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/config (trên máy khách) tệp bằng cách thêm IdentitiesOnly như vậy:

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

Nếu bạn sử dụng ssh-agent, 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 chỉ định rõ ràng khóa chính xác trong ssh lệnh như vậy:

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

Lưu ý: thông số 'IdentitiesOnly yes' cần phải nằm giữa dấu ngoặc kép.

hoặc là

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

360
2017-09-12 17:53



nó không rõ ràng với 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 nên đi trong tập tin .ssh / config trên máy tính 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 "khi bạn đăng nhập lại ..." - David LeBauer
Tôi phải đặt tùy chọn trong dấu ngoặc kép, như sau: ssh -i some_id_rsa -o "IdentitiesOnly yes" them@there:/path/ - knb
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 sự cố này sau khi vô tình tải TẤT CẢ các khóa riêng tư của tôi. - Chris Rasco
Tuy nhiên, cho sshfs (cầu chì) Tôi phải viết tùy chọn với một dấu bằng bắt buộc, như thế này: sshfs -o "IdentitiesOnly=yes" -o IdentityFile=~/.ssh/id_dsa them@there/var/tmp /mnt/tmp  (Ubuntu 13.10) - knb
nó có thể được sử dụng mà không có dấu ngoặc kép, như thế này: -o IdentitiesOnly=yes - Valentin Kantor


Tôi đã tìm thấy một cách dễ dàng hơn để thực hiện việc 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 khóa. Tôi đã có thể đăng nhập ngay lập tức.

Tài liệu tham khảo


159
2018-03-25 00:14



1, ước gì tôi có thể cung cấp 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 công khai. Đã nhận được: "Quá nhiều lỗi xác thực cho pi" - blak3r
Và để sử dụng nó với rsync: rsync -av -e 'ssh -o PubkeyAuthentication=no' 'user@host.com:~/remote_file' 'local_file' - Ciro Santilli 新疆改造中心 六四事件 法轮功
Bạn cũng có thể tạo Bí danh để làm cho nó thậm chí còn nhanh hơn cho mật khẩu auth. alias sshp = 'ssh -o PubkeyAuthentication = no' - dhempler


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

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

Ngoài việc đặt IdentitiesOnly yes trong của bạn ~/.ssh/config tập tin bạn có một vài lựa 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 & chạy ssh-add -D 
  3. liên kết rõ ràng một khóa với một máy chủ đã cho trong ~/.ssh/config tập tin

Giống 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 tốt để đi về nó, cho nó làm suy yếu máy chủ ssh của bạn một chút vì nó bây giờ sẽ chấp nhận nhiều phím trong một nỗ lực kết nối nhất định. Hãy suy nghĩ các vector tấn công bạo lực ở đây.

  2. 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 thiết lập IdentitiesOnly có lẽ là những cách ưu tiên để giải quyết vấn đề này!


24
2018-06-09 04:56



Trong dòng cuối cùng của bạn, bạn có identfile /home/YOU/.ssh/foo nhưng nó phải là identityfile (a t không phải là f) - Nin
@Nin - cảm ơn, cố định. - slm


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 ONLY 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 gây nhầm lẫn (đó là một siêu bao gồm mật khẩu), bạn có thể thực hiện điều này từ dòng lệnh:

ssh -o PreferredAuthentications=password user@example.com

6
2018-06-19 14:22





Nếu bạn gặp 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 tại dòng lệnh.

Khách hàng ssh đầu tiên sẽ cố gắng đăng nhập bằng cách sử dụng mỗi nhận dạng (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 không hợp lệ (mặc định lại 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ể vô hiệu hóa "Xác thực khóa công khai" 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

5
2017-09-20 21:44



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


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

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ó bằng tùy chọn -i


3
2017-07-23 17:29





Tắt @David nói, chỉ cần thêm phần này IdentitiesOnly yes vào tệp .ssh / config của bạn, nó cũng giống như ssh -o PubkeyAuthentication=no.

Sau khi bạn đăng nhập, hãy xóa .ssh/authorized_keys. Bây giờ, quay trở lại máy địa phương 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 công khai


2
2018-01-25 05:48





Tôi biết đây là một chủ đề cũ, nhưng tôi chỉ muốn thêm vào ở đây mà tôi chạy vào cùng một thông báo lỗi, nhưng nó đã được gây ra bởi chủ sở hữu của thư mục .ssh được root chứ không phải là người dùng đã sử dụng phím. 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 đã 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ó quyền 600:

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

2
2018-06-13 17:37



Tôi sẽ cẩn thận với việc sử dụng điều này mà không cần báo trước. Quyền khóa SSH thường bị giới hạn ở mức 400 đối với một số khóa, AWS cụ thể. 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


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

Sau khi tôi đã làm những gì "John T" gợi ý, tôi nhận được 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 (ví dụ: 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-permission-denied-publickey-issue


0
2017-11-19 08:10





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

$ chmod 750 ~;chmod 700 ~/.ssh

0
2018-02-20 22:57