layanan pam (sshd) mengabaikan retries maks


32

Saya memiliki vps yang saya gunakan untuk menjalankan server web, saat ini menjalankan server ubuntu 12.04. Sejak beberapa minggu saya terus mendapatkan banyak kesalahan di konsol ssh saya.

2014 Apr 11 08:41:18 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:21 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:24 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:25 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:26 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3
2014 Apr 11 08:41:29 vps847 PAM service(sshd) ignoring max retries; 6 > 3

Bisakah seseorang tolong beri tahu saya apa artinya kesalahan ini. Atau setidaknya beri tahu saya cara menonaktifkan kesalahan ini. Benar-benar aneh ketika saya mengerjakan ssh dan kesalahan ini terus muncul di seluruh layar saya.

Jawaban:


40

PAM memberitahu Anda bahwa itu dikonfigurasikan dengan "coba lagi = 3" dan itu akan mengabaikan permintaan auth lanjut dari sshd dalam sesi yang sama. SSHnamun akan terus mencoba hingga pengaturan MaxAuthTries habis (yang standarnya adalah 6).

Anda mungkin harus mengatur keduanya (SSH dan PAM) ke nilai yang sama untuk coba ulang auth maksimum.

Diperbarui

Untuk mengubah perilaku ini:

Untuk sshdAnda edit /etc/ssh/sshd_configdan atur MaxAuthTries 3. Mulai ulang server SSH agar pengaturan mulai berlaku.

Sebab PAM, Anda harus mencari konfigurasi di /etc/pam.ddirektori (saya pikir itu common-passwordfile di Ubuntu), Anda harus mengubah retry=nilainya.

Catatan: Saya sangat menyarankan untuk juga memeriksa jawaban Peter Hommel mengenai alasan permintaan ini karena ada kemungkinan SSH Anda menjadi kasar.


Terima kasih, masalah telah diperbaiki dengan menambahkan MaxAuthTries 3konfigurasi ssh dan kemudian me-reboot server.
Jerodev

41

Sementara jawaban lain benar dalam menghilangkan pesan kesalahan yang Anda dapatkan, pertimbangkan bahwa pesan kesalahan ini mungkin hanya merupakan gejala dari masalah mendasar lainnya.

Anda mendapatkan pesan ini karena ada banyak upaya login gagal melalui ssh pada sistem Anda. Mungkin ada seseorang yang mencoba memaksa masuk ke dalam kotak Anda (jika saya mendapat pesan yang sama di sistem saya). Baca var/log/auth.loguntuk penelitian Anda ...

Jika ini masalahnya, Anda harus mempertimbangkan untuk menginstal alat seperti 'fail2ban' ( sudo apt-get install fail2bandi Ubuntu). Secara otomatis membaca file log sistem Anda, mencari beberapa upaya login gagal dan memblokir klien jahat untuk waktu yang dapat dikonfigurasi melalui iptables ...


4
Ini adalah komentar yang sangat bagus, saya telah memperbarui jawaban saya dengan catatan untuk membaca jawaban Anda juga untuk siapa saja yang mungkin menemukan ini.
phoops

5

Tampaknya analisis di atas tidak sepenuhnya benar. Tampaknya tidak ada opsi coba lagi = untuk otentikasi pam (saya memang menemukan satu untuk pam_cracklib, tetapi itu hanya menyangkut mengubah kata sandi di bagian "kata sandi", bukan otentikasi di bagian "auth" dari pam). Alih-alih, pam_unix berisi jumlah maksimum reti yang dibuat dari 3. Setelah 3 kali coba, pam mengembalikan kode kesalahan PAM_MAXRETRIES untuk menginformasikan sshd tentang ini.

sshd harus benar-benar berhenti mencoba dalam kasus ini, terlepas dari MaxAuthTries sendiri. Tidak, yang menurut saya adalah bug (yang baru saja saya laporkan dengan openssh ).

Sampai bug itu diperbaiki, tampaknya menetapkan MaxAuthTries ke <= 3 adalah satu-satunya cara untuk mencegah pesan ini muncul.


bug tampaknya diperbaiki dengan versi 7.3p1
Dennis Nolte

3

Klien ssh dapat mencoba untuk mengotentikasi dengan satu atau lebih kunci. Kunci apa pun yang tidak tercantum dalam otor_keys akan gagal, memakan salah satu dari coba sshd. Klien akan mencoba setiap kunci ssh yang dimilikinya sampai satu berhasil atau semua gagal, jadi ada baiknya sshd memungkinkan Anda mencoba beberapa.

Jika tidak ada kunci yang cocok, sshd memungkinkan Anda untuk mencoba kata sandi. Masing-masing upaya ini juga mengkonsumsi salah satu dari coba ulang sshd yang diizinkan. Tapi, itu juga mengkonsumsi salah satu retries yang diizinkan PAM.

Jadi, kombinasi dari 6 ssh auth mencoba dan 3 pam auth mencoba adalah hal yang baik: itu berarti ssh akan memungkinkan 6 auth mencoba total (kunci atau kata sandi) tetapi hanya 3 kata sandi mencoba.

Seperti yang orang lain katakan, jika Anda sering melihat ini di log Anda, seseorang mencoba untuk memaksa masuk ke sistem Anda. Pertimbangkan untuk menggunakan fail2ban untuk sepenuhnya memblokir paket dari alamat IP dari mana upaya ini berasal.


1

Setelah meningkatkan dari Debian 6 ke Debian 7, saya mengalami masalah yang sama. Tiba-tiba kesalahan sshd ini muncul di konsol saya.

2014 Oct 15 13:50:12 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:17 vps456 PAM service(sshd) ignoring max retries; 6 > 3
2014 Oct 15 13:50:18 vps456 PAM service(sshd) ignoring max retries; 6 > 3

Dalam kasus saya, masalahnya adalah bahwa rsyslogitu tidak diinstal lagi setelah peningkatan Debian.

Setelah menginstal rsyslog kesalahan ini menghilang dari konsol saya: apt-get install rsyslog


3
Ini hanya membuat mereka muncul di tempat lain alih-alih konsol. Jawaban saya memperbaiki penyebab kesalahan karena kesalahan konfigurasi SSH / PAM setelah peningkatan.
phoops

-1

Tentu saja mendapatkan pemberitahuan itu di konsol Anda dapat mengganggu, tetapi ketika saya melihat dalam file log saya bahwa kemarin saya telah gagal 987 upaya login root yang berasal dari alamat IP di Cina, atau 2670 dari beberapa layanan cloud di California, atau ... banyak yang lain, saya tidak khawatir. Root pengguna tidak diizinkan masuk sama sekali di mesin saya. Tidak peduli berapa banyak yang mencoba.

Jika mereka mulai mencoba nama pengguna yang dapat masuk, itu akan menjadi masalah yang berbeda, tetapi jika seseorang memiliki kata sandi yang baik, saya juga tidak melihat risiko di sana. Kata sandi masuk (tidak seperti kunci enkripsi) hanya dapat dicoba dengan sangat cepat.

Menggunakan sesuatu seperti fail2ban tampaknya tidak perlu kompleksitas yang tidak membeli apa pun (jika Anda memiliki kata sandi yang baik) dan kompleksitas buruk untuk keamanan. Upaya pelambatan adalah sesuatu yang harus diimplementasikan oleh sshd, bukan sesuatu yang membutuhkan tambahan ... dan sshd melakukan upaya pembatasan. Baik.

-kb, Kent yang hanya menggunakan kata sandi yang baik, dan tidak pernah didaur ulang di antara berbagai situs.


2
Menggunakan kunci ssh dan menonaktifkan kata sandi bahkan lebih baik dalam mencegah serangan brute-force yang berhasil.
HBruijn

Ya, tapi kemudian masalahnya bergeser untuk melindungi kunci ssh Anda. Dimana mereka? Apakah mereka dienkripsi? Seberapa baik kunci melindungi mereka? Jika kata sandi tidak dapat di-crack dalam percobaan X-tahun, maka itu tidak dapat di-crack dalam percobaan X-tahun, untuk apa Anda perlu "lebih baik"? Saya menaruh banyak waktu untuk mengelola kata sandi saya, dan saya bisa mengetiknya, banyak dari mereka yang saya ingat. Tapi banyak kunci ssh? Butuh tempat aman untuk menyimpannya.
Kent Borg

2
Brute-forcing password (biasanya kurang dari 20 karakter dan terlalu sering dipilih dengan buruk) jauh lebih sederhana daripada brute yang memaksa kunci pribadi 1024 bit (disederhanakan setara dengan kata sandi 128 karakter) untuk mendapatkan akses melalui SSH. Mari kita bandingkan apel dengan apel. - - Kecuali Anda idiot (mis. Menyimpan kunci pribadi Anda di github publik Anda) mendapatkan kunci ssh pribadi Anda sulit karena tidak perlu meninggalkan workstation Anda, selamanya. Setelah kunci pribadi Anda dikompromikan, kami tidak lagi berada dalam serangan acak, tetapi memasuki ranah serangan yang ditargetkan ...
HBruijn

@ Kent Anda tahu Anda dapat melindungi kata sandi Anda dengan kunci SSH? Juga, Anda mengatakan fail2ban tidak perlu tetapi terus menyarankan bahwa SSH harus mengimplementasikan fitur ini dengan sendirinya. Juga, jika Anda tidak memblokir permintaan, mereka hanya bisa DDoS sistem Anda lebih mudah.
phoops
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.