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

64

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

pengguna11722
sumber
superuser.com/questions/187779/…
Ciro Santilli 新疆 改造 中心 法轮功 六四 事件
1
Pastikan untuk menonaktifkan agen ssh Anda (misalnya kontes pada Windows) jika Anda mendapatkan Too many Authentication Failureskesalahan sebelum Anda bisa masuk sama sekali.
Mahn

Jawaban:

8

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.

Damorg
sumber
120

"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).
Peta Sittek
sumber
9
Ini benar-benar jawaban yang diterima!
Benjamin
4
Untuk menjadi jawaban yang diterima, jawabannya harus benar-benar mengenai perangkat lunak yang disebutkan dalam pertanyaan. =)
rakslice
4
Penyebab lain dari batas yang terlampaui adalah agen ssh Anda. ssh -vvmenunjukkan beberapa versi dari dua kunci (disediakan oleh ssh-agent) yang sedang dicoba. Saya berasumsi ini karena saya jarang reboot dan telah mengganti beberapa kunci yang kedaluwarsa; rupanya ssh-agent tidak menimpa kunci lama dengan yang baru. Saya membunuh ssh-agent dan masalahnya hilang.
Markus
Kelemahan apa yang akan muncul dari peningkatan MaxAuthTries? Saya ragu banyak serangan dilakukan dengan mencoba banyak kunci berbeda. Selain itu jika seorang penyerang ingin melakukan itu, mereka bisa saja menutup koneksi dan membuka yang baru setiap kali mereka mencapai batas. Mereka tidak akan berhasil dalam memaksa paksa kunci pula.
kasperd
@Ark, terima kasih! Restart ssh-agent memperbaikinya untuk saya!
winduptoy
91

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
Will Verna
sumber
1
Terima kasih banyak! Menggunakan Server Ubuntu di sini yang hanya dapat saya akses dengan SSH. Saya telah menetapkan "MaxAuthTries 1" setelah secara membabi buta mengikuti tutorial di internet.
Andre Figueiredo
Anda baru saja menyelamatkan hidup saya! Tidak menggunakan kunci auth sehingga jawaban lain tidak membantu. Ini menyelesaikannya soooo dengan mudah !!
George Green
5
Ini adalah yang jawabannya
smac89
Saya cukup menyalin kembali kunci saya, menggunakan otentikasi kata sandi, dan sekarang berfungsi setiap saat. Saya memiliki banyak kunci di .sshdirektori saya , saya tidak berpikir itu jumlah yang penting.
Ken Sharp
Ini adalah jawaban yang paling relevan dan harus benar-benar menjadi perilaku default untuk ssh-copy-id maka jika saya ingin menyalin id saya ke server, biasanya tidak ada. Tetapi jika ssh mencoba terlebih dahulu untuk mengotentikasi terhadap server menggunakan pubkey, server membatalkan koneksi sebelum dapat memasukkan kata sandi.
Sprinterfreak
17

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.


sumber
Dalam kasus khusus saya, masalahnya adalah saya masuk dengan penerusan agen, mencoba menjalankan skrip yang menggunakan identitas SSH itu sendiri. Ketika saya menjalankannya dengan penerusan agen, terlalu banyak identitas sebelum mencobanya sendiri. Jadi saya mengatur skrip untuk membuang lingkungan agen dan itu membersihkannya. Saya juga bisa meningkatkan MaxAuthTries, tetapi saya tidak perlu melakukannya.
Sean Reifschneider
1
Terima kasih. -vmenunjukkan klien ssh saya mencoba menggunakan beberapa kunci (saya punya beberapa sekarang). Saya membersihkan mereka dari agen denganssh-add -D
joeytwiddle
12

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

Anonim, tanpa nama
sumber
10

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.

Ninjaxor
sumber
6

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.

Rodent43
sumber
5

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

Prabath Dolawatta
sumber
1
Kami tidak terlalu tertarik pada jawaban hanya tautan di sekitar sini, karena tautan membusuk, dan jawabannya menjadi tidak berguna. Tetap pertahankan tautannya, tetapi jika Anda bisa meringkas solusinya dalam satu atau dua paragraf, Anda mungkin sudah mendapatkan jawaban yang dapat dipertahankan di sini.
MadHatter
2
Saya harap Anda akan memaafkan hasil edit saya selanjutnya; sekarang (saya harap) itu memperjelas bahwa saran yang Anda referensikan adalah saran yang Anda berikan, tetapi masih menghargai sumber aslinya. +1 dari saya karena berusaha keras untuk meningkatkan jawaban Anda!
MadHatter
Saya punya masalah "Terlalu banyak kegagalan otentikasi" di Putty juga. Setelah saya menghapus semua kunci lain dari PageAnt, akhirnya berhasil masuk.
klor
4

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

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

Kemudian coba ssh di mesin remote

Sunil shakya
sumber
3

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>
andyfeller
sumber
2

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.

Igor Stoppa
sumber
1

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.
tallbr00
sumber
0

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.

Adam Witorean
sumber
0

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.

Penderita
sumber
0

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

Fjor
sumber
-2

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 !!

Rajnesh Thakur
sumber
Ini tidak ada hubungannya dengan pertanyaan.
Ken Sharp
-3

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

Arun Mathuria
sumber
-4

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.

Eskimo-Jbk
sumber
Jawaban ini tidak berguna, dan merekomendasikan menghapus file .ppk berbahaya. Silakan orang-orang, jika Anda pikir Anda perlu menghapus file .ppk (dan saya tidak bisa memikirkan alasan bagus yang Anda inginkan), ubah nama menjadi sesuatu yang lain, jangan hapus. Mereka berisi kunci Anda, yang mungkin Anda butuhkan.
Law29