Cách phục hồi 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à cho phép đăng nhập lại? Khởi động lại sshd dường như không giúp được gì

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.

"Quá nhiều lỗi xác thực cho người dùng root" có nghĩa là giới hạn MaxAuthTries của máy chủ SSH của bạn đã bị vượt quá . 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 / path / to / id_rsa root @ host
2. Chỉ định cặp Host / IdentityFile trong /home/USER/.ssh/config .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Tăng giá trị MaxAuthTries trên máy chủ SSH trong / etc / ssh / sshd_config (không được khuyến nghị).

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 .sshthư mục của bạn . Trong trường hợp này nếu -itùy chọn 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 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).

Vì vậy, 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 Public Key Authenticationtại dòng lệnh bằng cách sử dụng -ođối số tùy chọn.

Ví dụ:

$ ssh -o PubkeyAuthentication=no root@host

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 khóa 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ẻ.

Đâ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.

Đố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 ~/.sshthư mục của mình , như 16 hoặc hơn. Và không có cả hai lệnh IdentityFileAND đó IdentitiesOnlytrong cấu hình, máy của tôi rõ ràng đã thử tất cả các phím trong ~/.sshvà đạt số lần thử tối đa trước khi thử nhận dạng chính xác.

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 sulệnh để có quyền roottruy cập.

Cũng đảm bảo bật PermitRootLogintrong /etc/ssh/sshd_configtệp trên máy chủ.

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ó một 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ừ đây .)

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

Để 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>

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à do tôi có ForwardAgent yestrong tập tin cấu hình của một máy dọc theo đường ống. Tôi đang 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.

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ó.

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 máy ảo tiêu chuẩn với khóa SSH và tôi có thể SSH vào nó bằng cách sử dụng Putty. Trong khi cố gắng truy cập nó trong quá trình triển khai trong PHPStorm, tôi gặp too many authentication failureslỗi. Vì vậy, tôi đã tăng MaxAuthTriestrong sshd_configvà sau đó tôi đã gặp Auth failedlỗi 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 .ppktệp 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" đó.

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 lời 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.

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ụ DenyHostshoặ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 abcd:

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 abcd, bạn có thể thêm dòng sshd:a.b.c.dvào tệp /etc/hosts.allow.

Như mọi khi, manlệnh 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ư thể hiện trong câu trả lời của Rajnesh Thakur về việc khởi động lại máy chủ VNC).

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 -

192.0.2.99:5901

Làm xong !!

vui lòng làm theo các bước dưới đây để giải quyết

1. Sao lưu / etc / ssh / sshd_config
2. Tăng giá trị của MaxAuthTries trong sshd_config
3. stoprc -s sshd; startedrc -s sshd

Và kiểm tra lại sau khi thay đổi ở trên

Tôi gặp vấn đề tương tự khi tôi liên tục nhận được "SServer đã gửi tin nhắn bị ngắt kết nối loại 2 (lỗi giao thức): Quá nhiều lỗi xác thực cho người dùng"

Tôi đã giải quyết vấn đề này bằng cách xóa tất cả ssh (khóa .ppk) của mình sau đó đăng nhập vào máy chủ tích hợp AD.