it-swarm-vi.tech

Cách khôi phục từ "Quá nhiều lỗi xác thực cho người dùng root"

Tôi đã thực hiện một số nỗ lực để thiết lập SSH-connecton cho người dùng root @ Host bằng thiết bị đầu cuối PuTTY. Trong khi làm như vậy, tôi đã chỉ định thông tin đăng nhập sai nhiều lần và sau đó tôi đã chỉ định chúng một cách chính xác, và sau đó sau khi thông tin đăng nhập được chấp nhận, phiên ssh bị phá vỡ với

"Máy chủ đột ngột đóng kết nối mạng".

Lỗi này được báo cáo bởi thiết bị đầu cuối PuTTY. Khi cố gắng ssh root @ localhost từ bảng điều khiển cục bộ - nó hoạt động tốt. Nó cũng hoạt động tốt khi tôi ssh otheruser @ Host từ máy chủ khác. Vì vậy, vấn đề kết nối mạng không có tội. Lỗi duy nhất tôi nghĩ đến là: "Quá nhiều lỗi xác thực cho người dùng root" mặc dù PuTTY đã báo cáo một lỗi khác.

Câu hỏi là: làm thế nào để phục hồi từ tình trạng lỗi này và để PuTTY đăng nhập lại? Khởi động lại sshd dường như không giúp ích

70
user11722

Bạn có chắc chắn rằng đăng nhập root vào ssh được cho phép?

Kiểm tra sshd_config và xác minh rằng đăng nhập root được cho phép. sshd sẽ cần phải được khởi động lại nếu cài đặt thay đổi.

8
damorg

"Quá nhiều lỗi xác thực cho người dùng root" có nghĩa là máy chủ SSH của bạn vượt quá giới hạn MaxAuthTries. Nó xảy ra để khách hàng của bạn đang cố xác thực với tất cả các khóa có thể được lưu trữ trong /home/USER/.ssh/.

Tình trạng này có thể được giải quyết bằng những cách sau:

  1. ssh - i/đường dẫn/đến/id_rsa root @ Host
  2. Chỉ định Máy chủ/Nhận dạng cặp trong / home/USER/.ssh/config. [.__.]
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. Tăng MaxAuthTries giá trị trên máy chủ SSH trong / etc/ssh/sshd_config (không được đề xuất).
128
Peta Sittek

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. Trong trường hợp này nếu tùy chọn -i Không được chỉ định tại dòng lệnh, máy khách ssh trước tiên sẽ cố gắng đăng nhập bằng mỗi danh tính (khóa riêng) và 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).

Vì vậy, nếu bạn có một số khóa riêng trong thư mục .ssh, bạn có thể tắt Public Key Authentication 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 [email protected]
98
Will Verna

Trên máy từ xa mở/etc/sshd_config và thay đổi giá trị

MaxAuthTries 30

Đây là vấn đề điển hình khi Bạn đã cài đặt nhiều khóa hoặc mở nhiều kết nối. Máy chủ kiểm tra từng bước từng phím và nếu MaxAuthTries được thiết lập vào ngày 3 thì sau lần thử thứ 3 đầu tiên sẽ ngắt kết nối Bạn. Bảo mật ssh điển hình.

Tôi đề nghị Bạn sử dụng chế độ dài dòng trong khi kết nối với máy từ xa để phân tích vấn đề.

ssh -v -p port_number người dùng @ tên máy chủ

Đoán giống như hầu hết các poeple trên diễn đàn này làm là SAI và lãng phí thời gian của nó. Đầu tiên hãy thử phân tích vấn đề, thu thập thông tin và sau đó hỏi.

Chúc vui vẻ.

17
user59664

Đối với tôi, vấn đề này đã được giải quyết bằng cách tạo ssh_config bên dưới cho Máy chủ tôi đang kết nối.

(~/.ssh/config)

Host example
HostName example.com
User admin
IdentityFile ~/path/to/ssh_key_rsa
IdentitiesOnly=yes

Sự cố xảy ra do tôi có quá nhiều khóa ssh trong ~/.ssh thư mục, như 16 hoặc hơn. Và không có cả hai lệnh IdentityFile AND IdentitiesOnly trong cấu hình, máy của tôi rõ ràng đang thử tất cả các phím trong ~/.ssh và đạt số lần thử tối đa trước khi thử nhận dạng chính xác.

15
Ninjaxor

Đây là thực hành xấu. Chỉ cần có một người dùng thông thường trên hộp từ xa và kết nối thông qua ssh bằng cách sử dụng nó, sau đó có quyền truy cập root bằng su/Sudo.

12
Anonymous

Tôi cũng phải đối mặt với vấn đề tương tự. Điều này có thể dễ dàng xảy ra nếu bạn đang sử dụng Pagete và có số lượng lớn các khóa được tải vào nó , vì các máy chủ này tính mỗi ưu đãi của khóa công khai là một nỗ lực xác thực.

(Lời khuyên này được lấy từ tại đây .)

6
Prabath Dolawatta

Tôi muốn giới thiệu bạn, như Anon ở trên đã đăng, sử dụng một người dùng khác để có quyền truy cập ssh sau đó sử dụng lệnh su để có quyền truy cập root.

Đồng thời đảm bảo bật PermitRootLogin trong /etc/ssh/sshd_config tập tin trên máy chủ.

6
Rodent43

Tôi đã khắc phục sự cố này trong các hệ thống của mình bằng cách chạy các lệnh sau:

eval $(ssh-agent)
ssh-add  ~/.ssh/keyname

Sau đó thử ssh trong máy từ xa

5
Sunil shakya

Để tạm thời giải quyết vấn đề này cho đến khi mọi thứ có thể được giải quyết đầy đủ như đã lưu ý ở nơi khác, bạn có thể đặt lại kiểm đếm PAM của người dùng để họ có thể thử lại:

pam_tally --reset --user <USERNAME>
pam_tally2 --reset --user <USERNAME>
3
andyfeller

Tôi đã bị cắn bởi một vấn đề tương tự. Tuy nhiên nguyên nhân thực sự là tôi đã có ForwardAgent yes trong tệp cấu hình của máy dọc theo đường ống. Tôi đã kết nối từ máy A vào máy B vào máy C.

Thông báo lỗi được hiển thị trong lần thử ssh từ B -> C, nhưng nguyên nhân là do A có hoạt động chuyển tiếp. Vì vậy, C lần đầu tiên được phục vụ tất cả các khóa từ A, và chỉ sau đó là các khóa từ B.

Nó đột nhiên xuất hiện khi tôi thêm một khóa nữa vào A.

2
Igor Stoppa

Tôi đã khắc phục sự cố này trên máy Mac của mình bằng cách:

  1. đặt mật khẩu gốc bằng "Sudo passwd root" rồi
  2. chỉnh sửa và lưu tệp cấu hình ssh bằng "nano/etc/ssh_config" và
  3. thay đổi RSAAuthentication thành "không" thay vì có.
1
tallbr00

Các câu trả lời khác cho bạn biết cách tốt nhất để được kết nối với quyền root và ý nghĩa bảo mật của điều đó, nhưng câu hỏi rõ ràng của bạn là

làm thế nào để phục hồi từ tình trạng lỗi này và để PuTTY đăng nhập lại?

Bạn đề cập đến lần cuối cùng bạn kết nối thì máy chủ từ xa đã ngắt kết nối.

Những gì tôi nghĩ bạn có thể tìm thấy là máy chủ từ xa đang chạy fail2ban (*) và nó đã "bỏ tù" IP của bạn sau khi đăng nhập thành công. Bạn có thể kiểm tra điều này bằng cách thử đăng nhập lại và thậm chí bạn sẽ không nhận được Nhắc đăng nhập.

Có hai giải pháp, bạn có thể đợi thời gian ngồi tù, lúc đó mọi thứ đơn giản trở lại bình thường, nhưng thời gian ngồi tù có thể là bất cứ điều gì. Hoặc bạn có thể tìm thấy máy tính khác để đăng nhập, thực hiện điều đó và "bỏ tù" IP của bạn, trong trường hợp này "khác" là từ phối cảnh của máy chủ từ xa, do đó, một máy tính khác có cùng tường lửa có thể sẽ không hoạt động .

(*) fail2ban là một trình nền siêu tiện dụng, có thể kiểm tra định kỳ các tệp nhật ký khác nhau và điều chỉnh các quy tắc tường lửa để làm cho máy chủ "biến mất" khi phát hiện hành vi nguy hiểm tiềm tàng từ máy khách. Trên debian, nó đi ra khỏi hộp được cấu hình để phát hiện nhiều lần đăng nhập ssh không thành công từ một IP cụ thể và sau 3 (tôi nghĩ) nó sẽ bỏ tất cả các gói từ IP đó. Hoạt động tuyệt vời để ngăn chặn những cuộc tấn công kịch bản, vũ phu.

0
Sufferer

Tôi đã giải quyết vấn đề này bằng hai bước đơn giản trên máy chủ Ubuntu 16.04 của mình -

Trước tiên hãy dừng máy chủ vnc của tôi hoặc tắt tiến trình -

vncserver -kill :1

và sau đó bắt đầu lại -

vncserver

Sau đó kết nối nó từ máy khách Remote Desktop -

999.99.99.99:5901

Làm xong !!

0
Rajnesh Thakur

OK, vì vậy trong trường hợp của tôi, điều này khá kỳ lạ, ở đây nó ...

Tôi có một vagrant tiêu chuẩn VM với khóa SSH và tôi có thể SSH vào nó bằng PuTTY. Trong khi thử sử dụng nó trong khi triển khai trong PHPStorm, tôi gặp lỗi too many authentication failures. Vì vậy, tôi đã tăng MaxAuthTries trong sshd_config của tôi và sau đó tôi gặp phải lỗi Auth failed và sau đó Auth cancel.

Bây giờ, tôi không biết rõ tại sao tôi thậm chí đã thử điều này nhưng ... Tôi đã thêm dấu chấm ở cuối đường dẫn khóa SSH của mình trong cửa sổ triển khai trong PHPStorm. Vì vậy, nó là như thế này:

C:\Users\Deadpool\\.ssh\chimichanga

và bây giờ nó là như thế này:

C:\Users\Deadpool\\.ssh\chimichanga.

Và nó hoạt động ... Trong thư mục ".ssh" của tôi, tôi có nhiều tệp hơn:

chimichanga - copy of "id_rsa" from vagrant machine
chimichanga.ppk
chimichanga.pub

Tôi không chắc dấu chấm fcuking đó làm gì nhưng sử dụng tệp .ppk Không hoạt động nên tôi đoán đó là loại phép thuật;) Ồ, và tôi có thể thoát khỏi MaxAuthTries sau "dấu chấm" đó.

0
Adam Witorean

Như @sufferer đã đề cập trong một câu trả lời khác, một số bản phân phối Linux bao gồm các màn hình để bảo vệ khỏi các cuộc tấn công vũ phu vào các dịch vụ hiển thị bên ngoài như SSH, ví dụ DenyHosts hoặc fail2ban. Các màn hình này kiểm tra các tệp nhật ký tìm kiếm các lần thử thất bại và thêm các bộ lọc để chặn các địa chỉ IP có quá nhiều lỗi (số này có thể định cấu hình và độc lập với cấu hình sshd).

Nếu bản phân phối của bạn bao gồm fail2ban, bảo vệ các dịch vụ thêm quy tắc vào tường lửa iptables, bạn có thể kiểm tra các dịch vụ hoặc "tù" nào được giám sát bằng lệnh:

Sudo fail2ban-client status

Nhà tù cho dịch vụ SSH là sshd, vì vậy để kiểm tra xem có IP bị cấm hay không, bạn có thể sử dụng:

Sudo fail2ban-client status sshd

và để unban một số IP a.b.c.d:

Sudo fail2ban-client set sshd unbanip a.b.c.d

Nếu bạn có DenyHosts, danh sách bị cấm nằm trong tệp /etc/hosts.deny; bạn có thể chỉnh sửa tập tin này trực tiếp như root. Để cấp một số quyền truy cập vĩnh viễn IP a.b.c.d, bạn có thể thêm dòng sshd:a.b.c.d vào tệp /etc/hosts.allow.

Như mọi khi, lệnh man là bạn của bạn:

man fail2ban
man hosts.deny

Có tồn tại các tiện ích tương tự khác, nhưng tôi chỉ sử dụng những tiện ích này.

Lưu ý rằng việc tăng số lần thử lại được phép trong cấu hình sshd không miễn phí các IP bị cấm, chỉ cho phép nhiều lỗi hơn trong cùng một kết nối. Nếu vượt quá số lượng cho phép, người dùng/kẻ tấn công chỉ cần kết nối lại để thử thêm n lần nữa.

Các dịch vụ khác có danh sách cấm được tích hợp (như trong câu trả lời của Rajnesh Thakur về việc khởi động lại máy chủ VNC).

0
Fjor