Bagaimana memulihkan dari "Terlalu banyak Kegagalan Otentikasi untuk root pengguna"

Saya telah melakukan beberapa upaya untuk membangun SSH-connecton untuk user root @ host menggunakan terminal dempul. Sambil melakukan hal itu, saya menentukan kredensial yang salah beberapa kali dan setelah itu saya menentukannya dengan benar, dan kemudian setelah kredensial diterima, sesi ssh terputus dengan

+ Msgstr "Server koneksi jaringan yang tidak terduga ditutup".

Kesalahan ini dilaporkan oleh terminal dempul. Ketika mencoba ssh root @ localhost dari konsol lokal - itu berfungsi dengan baik. Ini juga berfungsi dengan baik ketika saya ssh otheruser @ host dari host lain. Jadi masalah konektivitas jaringan tidak bersalah. Satu-satunya kesalahan yang saya pikirkan adalah: "Terlalu banyak Kegagalan Otentikasi untuk root pengguna" meskipun dempul melaporkan kesalahan yang berbeda.

Pertanyaannya adalah: bagaimana memulihkan dari kondisi kesalahan ini dan membiarkan masuk dempul lagi? Restart sshd tampaknya tidak membantu

Apakah Anda yakin bahwa login root ke ssh diizinkan?

Periksa sshd_config dan verifikasi bahwa login root diizinkan. sshd perlu di-restart jika pengaturan berubah.

"Terlalu banyak Kegagalan Otentikasi untuk root pengguna" berarti bahwa batas MaxAuthTries server SSH Anda terlampaui . Itu terjadi sehingga klien Anda mencoba untuk mengotentikasi dengan semua kunci yang mungkin disimpan di /home/USER/.ssh/.

Situasi ini dapat diselesaikan dengan cara-cara ini:

1. ssh -i / path / ke / id_rsa root @ host
2. Tentukan pasangan Host / IdentityFile di /home/USER/.ssh/config .
   • Host host
   • IdentityFile /home/USER/.ssh/id_rsa
   • Host host2
   • IdentityFile /home/USER/.ssh/id_rsa2
3. Tingkatkan nilai MaxAuthTries pada server SSH di / etc / ssh / sshd_config (tidak disarankan).

Jika Anda mendapatkan Galat SSH berikut:

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

Ini bisa terjadi jika Anda memiliki (default pada sistem saya) lima atau lebih file identitas DSA / RSA yang disimpan dalam .sshdirektori Anda . Dalam hal ini jika -iopsi tidak ditentukan pada baris perintah, klien ssh pertama-tama akan mencoba login menggunakan setiap identitas (kunci pribadi) dan prompt berikutnya untuk otentikasi kata sandi. Namun, sshd menjatuhkan koneksi setelah lima upaya login yang buruk (sekali lagi default dapat bervariasi).

Jadi, jika Anda memiliki sejumlah kunci pribadi di direktori .ssh Anda, Anda dapat menonaktifkan Public Key Authenticationdi baris perintah menggunakan -oargumen opsional.

Sebagai contoh:

$ ssh -o PubkeyAuthentication=no root@host

Pada mesin remote buka /etc/sshd_config dan ubah nilainya

MaxAuthTries 30

Ini adalah masalah umum ketika Anda telah menginstal beberapa kunci atau membuka beberapa koneksi. Server memeriksa langkah demi langkah setiap tombol dan jika MaxAuthTries diatur pada 3 maka setelah percobaan ketiga akan memutuskan Anda. Keamanan ssh yang khas.

Saya menyarankan Anda untuk menggunakan mode verbose selama koneksi ke mesin jarak jauh untuk menganalisis masalah.

ssh -v -p port_number user @ servername

Menebak seperti kebanyakan poeple di forum ini adalah SALAH dan membuang-buang waktu. Pertama mencoba menganalisis masalah, mengumpulkan informasi dan kemudian bertanya.

Selamat bersenang-senang.

Ini praktik buruk. Hanya memiliki pengguna biasa di kotak remote dan terhubung melalui ssh menggunakannya, lalu dapatkan akses root menggunakan su / sudo.

Bagi saya masalah ini diselesaikan dengan membuat ssh_config di bawah ini untuk host yang saya sambungkan.

(~ / .ssh / config)

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

Masalahnya terjadi karena saya memiliki terlalu banyak kunci ssh di ~/.sshfolder saya , seperti 16 atau lebih. Dan tanpa kedua arahan IdentityFileDAN itu IdentitiesOnlydalam konfigurasi, mesin saya tampaknya mencoba semua kunci ~/.sshdan mencapai jumlah upaya maksimum sebelum mencoba IdentityFile yang benar.

Saya akan merekomendasikan Anda, seperti Anon diposting di atas, gunakan pengguna lain untuk mendapatkan akses ssh kemudian gunakan superintah untuk mendapatkan rootakses.

Juga pastikan untuk mengaktifkan PermitRootLogindalam /etc/ssh/sshd_configfile di server.

Saya juga menghadapi masalah yang sama. Ini dapat dengan mudah terjadi jika Anda menggunakan Pageant dan memiliki sejumlah besar kunci yang dimasukkan ke dalamnya , karena server ini menghitung setiap tawaran kunci publik sebagai upaya otentikasi.

(Nasihat ini diambil dari sini .)

Saya memperbaiki masalah ini di sistem saya dengan menjalankan perintah berikut:

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

Kemudian coba ssh di mesin remote

Untuk sementara waktu mengatasi masalah ini sampai semuanya dapat diatasi sepenuhnya seperti yang disebutkan di tempat lain, Anda dapat mengatur ulang penghitungan PAM pengguna sehingga mereka dapat mencoba lagi:

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

Saya digigit oleh masalah yang sama. Namun penyebab sebenarnya adalah bahwa saya memiliki ForwardAgent yesfile konfigurasi mesin di sepanjang pipa. Saya menghubungkan dari mesin A ke mesin B ke mesin C.

Pesan kesalahan ditampilkan dalam upaya ssh dari B -> C, tetapi itu disebabkan oleh A yang memiliki penerusan aktif. Jadi C pertama-tama melayani semua kunci dari A, dan hanya kemudian yang dari B.

Tiba-tiba muncul ketika saya menambahkan satu kunci lagi ke A.

Saya memperbaiki masalah ini di Mac saya dengan:

1. mengatur kata sandi root dengan "sudo passwd root" lalu
2. mengedit dan menyimpan file konfigurasi ssh dengan "nano / etc / ssh_config" dan
3. mengubah RSAAuthentication ke "tidak" daripada ya.

OK, jadi dalam kasus saya ini sangat aneh, ini dia ...

Saya memiliki VM gelandangan standar dengan kunci SSH dan saya dapat SSH ke dalamnya menggunakan Putty. Saat mencoba untuk mendapatkannya selama penyebaran di PHPStorm saya mendapatkan too many authentication failureskesalahan. Jadi saya meningkatkan MaxAuthTriesdi saya sshd_configdan kemudian saya terkena Auth failedkesalahan dan kemudian Auth cancel.

Sekarang, saya tidak tahu persis mengapa saya bahkan mencoba ini tapi ... Saya menambahkan titik di akhir jalur kunci SSH saya di jendela penempatan di PHPStorm. Jadi seperti ini:

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

dan sekarang seperti ini:

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

Dan itu berfungsi ... Dalam folder ".ssh" saya, saya memiliki lebih banyak file:

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

Saya tidak yakin apa itu fcuking dot tetapi menggunakan .ppkfile tidak berfungsi jadi saya kira itu semacam sihir;) Oh, dan saya bisa menyingkirkan MaxAuthTries setelah "dot trick" itu.

Jawaban lain memberi tahu Anda cara terbaik untuk terhubung sebagai root, dan implikasi keamanannya, tetapi pertanyaan eksplisit Anda adalah

bagaimana memulihkan dari kondisi kesalahan ini dan membiarkan masuk dempul lagi?

Anda menyebutkan pada saat terakhir kali Anda terhubung maka server jauh menjatuhkan koneksi.

Apa yang saya pikir Anda mungkin temukan adalah bahwa server jauh menjalankan fail2ban (*) dan itu "memenjarakan" IP Anda setelah login sukses Anda. Anda dapat menguji ini dengan mencoba masuk lagi, dan Anda bahkan tidak akan mendapatkan prompt masuk.

Ada dua solusi, Anda bisa menunggu waktu penjara, di mana hal-hal kembali normal, tetapi waktu penjara bisa apa saja. Atau Anda dapat menemukan komputer yang berbeda untuk login, lakukan itu dan "batalkan" IP Anda, dalam hal ini "berbeda" adalah dari sudut pandang server jarak jauh, jadi komputer lain di belakang firewall yang sama mungkin tidak akan berfungsi dengan baik .

(*) fail2ban adalah daemon super berguna yang secara berkala dapat memeriksa berbagai file log dan menyesuaikan aturan firewall untuk membuat server "menghilang" ketika mendeteksi perilaku yang berpotensi berbahaya dari klien. Pada debian, itu keluar dari kotak yang dikonfigurasi untuk mendeteksi beberapa login ssh gagal dari IP tertentu, dan setelah 3 (saya pikir) itu akan menjatuhkan semua paket dari IP itu. Berfungsi dengan sangat baik untuk menghentikan serangan-serangan brute force yang dituliskan itu.

Seperti @sufferer sebutkan dalam jawaban lain, beberapa distro Linux menyertakan monitor untuk melindungi dari serangan brute force pada layanan terlihat eksternal seperti SSH, misalnya DenyHostsatau fail2ban. Monitor ini memeriksa file log yang mencari upaya yang gagal dan menambahkan filter untuk memblokir alamat IP yang mengalami terlalu banyak kegagalan (jumlahnya dapat dikonfigurasi dan independen dari konfigurasi sshd).

Jika distro Anda termasuk fail2ban, yang melindungi layanan menambahkan aturan ke firewall iptables, Anda dapat memeriksa layanan atau "penjara" mana yang diawasi menggunakan perintah:

sudo fail2ban-client status

Penjara untuk layanan SSH adalah sshd, jadi untuk memeriksa apakah ada IP yang diblokir, Anda dapat menggunakan:

sudo fail2ban-client status sshd

dan untuk membatalkan beberapa IP abcd:

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

Jika sudah DenyHosts, daftar yang terlarang ada di file /etc/hosts.deny; Anda dapat mengedit file ini secara langsung sebagai root. Untuk memberikan beberapa IP akses permanen, Anda dapat menambahkan baris sshd:a.b.c.dke file /etc/hosts.allow.

Seperti biasa, manperintahnya adalah teman Anda:

man fail2ban
man hosts.deny

Seharusnya ada utilitas serupa lainnya, tetapi saya hanya menggunakan ini.

Perhatikan bahwa meningkatkan jumlah coba lagi yang diizinkan dalam konfigurasi sshd tidak membebaskan IP yang diblokir, hanya memungkinkan lebih banyak kegagalan dalam koneksi yang sama. Jika jumlah yang diizinkan terlampaui, pengguna / penyerang hanya menghubungkan kembali lagi untuk mencoba n kali lebih banyak.

Layanan lain memiliki daftar larangan terintegrasi (seperti yang ditunjukkan dalam jawaban Rajnesh Thakur tentang memulai kembali server VNC).

Saya menyelesaikan masalah ini dengan dua langkah sederhana di server Ubuntu 16.04 saya -

Pertama-tama hentikan server vnc saya atau matikan prosesnya -

vncserver -kill :1

dan kemudian mulai lagi -

vncserver

Setelah itu hubungkan dari Remote Desktop client -

192.0.2.99:5901

Selesai !!

ikuti langkah-langkah untuk resolusi di bawah ini

1. Cadangkan / etc / ssh / sshd_config
2. Tingkatkan nilai MaxAuthTries di sshd_config
3. stopsrc -s sshd; beginrc -s sshd

Dan periksa lagi setelah perubahan di atas

Saya memiliki masalah yang sama di mana saya terus mendapatkan "SServer mengirim pesan terputus tipe 2 (kesalahan protokol): Terlalu banyak kegagalan otentikasi untuk pengguna"

Saya memecahkan masalah ini dengan menghapus semua ssh saya (.ppk keys) kemudian login ke server AD terintegrasi.