pam servisi (sshd) maksimum deneme sayısını yok sayarak


32

Bir web sunucusu çalıştırmak için kullandığım vps'im var, şu anda ubuntu server 12.04'ü çalıştırıyor. Birkaç haftadan beri ssh konsolumda birçok hata alıyorum.

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

Birisi lütfen bana bu hataların ne anlama geldiğini söyleyebilir. Ya da en azından bu hataları nasıl etkisizleştireceğimi söyle. Ben ssh üzerinde çalışırken gerçekten bu can sıkıcı ve bu hatalar ekranın her yerinde ortaya çıkmaya devam ediyor.

Yanıtlar:


40

PAM"retry = 3" ile yapılandırıldığını ve aynı oturum içinde sshd'den gelen diğer auth isteklerini yoksaydığını söylüyor. SSHancak, MaxAuthTries ayarını tüketene kadar çalışmaya devam edecektir (bu, varsayılan değer 6'dır).

Maksimum auth deneme için muhtemelen her ikisini de (SSH ve PAM) aynı değere ayarlamanız gerekir.

Güncellenmiş

Bu davranışı değiştirmek için:

İçin sshdsize düzenleme /etc/ssh/sshd_configve seti MaxAuthTries 3. Ayrıca, ayarın etkili olması için SSH sunucusunu yeniden başlatın.

Çünkü PAM, /etc/pam.ddizinde konfigürasyona bakmak zorundasınız (sanırım common-passwordUbuntu'da bu dosya), retry=değeri değiştirmek zorundasınız .

Not: Ayrıca, SSH'nizin kaba bir şekilde zorlanmasının mümkün olması nedeniyle Peter Hommel'in bu isteklerin nedenine ilişkin cevabını da kontrol etmenizi şiddetle tavsiye ederim.


Teşekkürler, sorun MaxAuthTries 3ssh config'e eklenerek ve ardından sunucunun yeniden başlatılmasıyla giderildi .
Jerodev

41

Diğer cevaplar aldığınız hata mesajını ortadan kaldırmakta haklı olsa da, bu hata mesajının sadece bir başka temel sorunun belirtisi olabileceğini düşünün.

Bu mesajları aldınız çünkü sisteminizde ssh üzerinden birçok başarısız oturum açma denemesi var. Kutunuza kaba kuvvet uygulamaya çalışan biri olabilir (sistemimde aynı mesajları aldığımda öyleydi). var/log/auth.logAraştırma için okuyunuz ...

Bu durumda, 'fail2ban' ( sudo apt-get install fail2banUbuntu'da) gibi bir araç yüklemeyi düşünmelisiniz . Sisteminizin günlük dosyalarını otomatik olarak okur, birden çok başarısız oturum açma girişimini arar ve kötü niyetli istemcileri yapılandırılabilir bir süre için iptables aracılığıyla engeller ...


4
Bu çok güzel bir yorum, cevabımı bu mesajla karşılaşabilecek herhangi biri için de cevabınızı okumak için bir notla güncelledim
18’de görüşüyor

5

Anlaşılan yukarıdaki analiz tam olarak doğru değil. Pam kimlik doğrulaması için bir yeniden deneme = seçenek görünmüyor (pam_cracklib için bir tane buldum, ancak bu yalnızca pam'in "auth" bölümünde kimlik doğrulaması değil, "parola" bölümünde parolanın değiştirilmesiyle ilgilidir). Bunun yerine, pam_unix yerleşik 3 maksimum deneme sayısını içerir. 3 denemeden sonra pam, bunu sshd'ye bildirmek için PAM_MAXRETRIES hata kodunu döndürür.

sshd, kendi MaxAuthTries değerlerinden bağımsız olarak, bu durumda denemeyi gerçekten durdurmalıdır. Bu bir hata olduğunu sanmıyorum (ki şimdi openssh ile bildirdim ).

Bu hata giderilinceye kadar, MaxAuthTries öğesinin <= 3 olarak ayarlanmasının, bu iletinin görünmesini engellemenin tek yolu olduğu görünüyor.


hata 7.3p1 versiyonu ile sabit görünüyor
Dennis Nolte

3

Ssh istemcisi bir veya daha fazla anahtarla kimlik doğrulaması yapabilir. Onaylanmış_ anahtarlarda listelenmeyen anahtarlar sshd denemelerinden birini tüketerek başarısız olur. Müşteri, başarılı olana veya hepsinin başarısız olmasına kadar olan her ssh anahtarını deneyecektir, bu yüzden sshd'nin birkaç denemenize izin vermesi iyidir.

Hiçbir anahtar eşleşmezse, sshd bir şifre denemenize izin verebilir. Bu girişimlerin her biri aynı zamanda sshd'nin izin verilen deneme sürümlerinden birini de tüketiyor. Ancak, PAM'ın izin verilen deneme sürümlerinden birini de tüketiyor.

Bu nedenle, 6 ssh auth denemesi ve 3 pam auth denemesi iyi bir şeydir: ssh, 6 auth denemesine izin verecek (toplam veya şifre) ancak sadece 3 şifre denemeye izin verecektir.

Diğerlerinin dediği gibi, bunları günlüklerinizde sık sık görürseniz, birisi kaba kuvvetleri sisteminize zorla girmeye çalışıyordur. Bu denemelerin kaynaklandığı IP adreslerinden gelen paketleri tamamen engellemek için fail2ban kullanmayı düşünün.


1

Debian 6'dan Debian 7'ye yükselttikten sonra aynı sıkıntıları yaşadım. Birdenbire sshd hataları konsolumda geldi.

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

Benim durumumda, sorun rsyslogDebian'ın yükseltmesinden sonra artık kurulmamış olmasıydı.

Rsyslog yüklendikten sonra bu hatalar konsolumdan kayboldu: apt-get install rsyslog


3
Bu, yalnızca konsol yerine başka bir yerde görünmelerini sağlar. Cevabım, yükseltme işleminden sonra SSH / PAM yanlış yapılandırması nedeniyle hatanın nedenini düzeltir.
18’de görüşüyor

-1

Kesinlikle bu uyarıları konsolunuzdan almak rahatsız edici olabilir, ancak log dosyalarımda dün 987’de Çin’deki bir IP adresinden veya California’daki bazı bulut hizmetlerinden gelen 2670’de kök giriş denemelerinde başarısız olduğumu gördüğümde ... diğerleri, endişelenmiyorum. Kullanıcı kökünün makinemde oturum açmasına izin verilmiyor. Kaç denemesi olursa olsun.

Giriş yapabilen kullanıcı adlarını denemeye başlamışlardı, bu farklı bir mesele olabilirdi, ancak birinin şifresi iyiyse, orada da bir risk göremiyorum. Giriş şifreleri (şifreleme anahtarlarının aksine) ancak çok hızlı bir şekilde denenebilir.

Fail2ban gibi bir şey kullanmak, hiçbir şey satın almayan (eğer iyi şifreleriniz varsa) gereksiz bir karmaşıklık gibi görünmektedir ve karmaşıklık güvenlik açısından kötüdür. Kısma girişimleri, bazı eklentiler gerektirecek bir şey değil, sshd'nin gerçekleştirmesi gereken bir şeydir ... ve sshd , gaz girişimi yapar . İyi.

-kb, yalnızca iyi şifreler kullanan ve hiçbir zaman farklı siteler arasında geri dönüştürülmeyen Kent.


2
Ssh anahtarlarını kullanmak ve parolaları devre dışı bırakmak, başarılı kaba kuvvet saldırılarını önlemede daha da iyidir.
HBruijn

Evet, fakat sorun ssh anahtarlarınızı korumak için değişiyor. Neredeler? Şifrelenmiş mi? Bir anahtar onları ne kadar iyi korur? Eğer bir şifre denediğiniz X yıllarında çözülemezse, o zaman X denediğiniz yıllarda çözülemez, ne için "daha iyi" ye ihtiyacınız var? Şifrelerimi yönetmek için çok zaman harcadım ve bunları hatırlayabiliyorum, çoğu hatırlıyorum. Ama bir sürü ssh anahtarı? Onları korumak için güvenli bir yere ihtiyacım var.
Kent Borg

2
Bir parolanın Brute-Forcing (tipik olarak 20 karakterden kısa ve çok sık kötü seçilmesi), SSH üzerinden erişim sağlamak için 1024 bitlik bir özel anahtarı (128 karakterlik bir şifrenin eşdeğerini basitleştirdiği) brüt'ten çok daha basittir. Elmaları elmalarla karşılaştırmaya devam edelim. - - Tam bir aptal olmadıkça (örneğin, özel anahtarınızı herkese açık github'ınıza depolamak gibi) özel ssh anahtarınıza ulaşmak zordur, çünkü iş istasyonunuzu terk etmek zorunda kalmazsınız. Özel anahtarınız tehlikeye girdiğinde, artık rastgele saldırılarda değiliz, ancak hedefli ataklar dünyasına giriyoruz ...
HBruijn

@ Kenti size SSH anahtarlarını koruyabileceğini biliyor musunuz? Ayrıca, fail2ban'ın gereksiz olduğunu söylüyorsunuz, ancak SSH'nin bu özelliği kendi başına uygulaması gerektiğini söylemeye devam edin. Ayrıca, istekleri engellemezseniz sisteminizi DDoS ile çok daha kolay bir hale getirebilirler.
14'te
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.