it-swarm.asia

"Kullanıcı kökü için çok fazla Kimlik Doğrulama Hatası" nasıl kurtarılır

PuTTY terminalini kullanarak kullanıcı root @ Host için SSH-connecton kurmak için birkaç deneme yaptım. Bunu yaparken birkaç kez yanlış kimlik bilgileri belirledim ve bundan sonra bunları doğru bir şekilde belirledim ve sonra kimlik bilgileri kabul edildikten sonra ssh oturumu sonlandırılıyor

Msgstr "Sunucu beklenmedik şekilde kapalı ağ bağlantısı".

Bu hata PuTTY terminali tarafından bildirilir. Yerel konsoldan root @ localhost kullanmaya çalıştığınızda - gayet iyi çalışıyor. Ayrıca diğer Host @ Host diğer kullanıcı @ ssh iyi çalışır. Dolayısıyla ağ bağlantısı sorunları suçlu değildir. Düşündüğüm tek hata: "Kullanıcı kökü için çok fazla Kimlik Doğrulama Hatası" , ancak PuTTY farklı bir hata bildirdi.

Soru şudur: bu hata durumundan nasıl kurtulur ve PuTTY'nin tekrar oturum açmasına izin verilir? sshd'yi yeniden başlatmak yardımcı görünmüyor

70
user11722

Ssh'de root girişine izin verildiğinden emin misiniz?

Sshd_config dosyasını kontrol edin ve kök oturum açmaya izin verildiğini doğrulayın. Ayar değişirse sshd'nin yeniden başlatılması gerekir.

8
damorg

"Kullanıcı kökü için çok fazla Kimlik Doğrulama Hatası" SSH sunucunuzun MaxAuthTries sınırının aşıldığı anlamına gelir. Böylece, istemciniz /home/USER/.ssh/ dizininde depolanan tüm olası anahtarlarla kimlik doğrulaması yapmaya çalışır.

Bu durum şu yollarla çözülebilir:

  1. ssh - i/yol///id_rsa root @ Host
  2. / home/USER/.ssh/config. İçinde Host/IdentityFile çifti belirtin.
    • Host host
    • IdentityFile /home/USER/.ssh/id_rsa
    • Host host2
    • IdentityFile /home/USER/.ssh/id_rsa2
  3. / etc/ssh/sshd_config (önerilmez) içindeki SSH sunucusundaki MaxAuthTries değerini artırın.
128
Peta Sittek

Aşağıdaki SSH Hatasını alırsanız:

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

.ssh Dizininizde (sistemimde varsayılan) beş veya daha fazla DSA/RSA kimlik dosyanız varsa bu olabilir. Bu durumda, komut satırında -i Seçeneği belirtilmezse, ssh istemcisi önce her kimliği (özel anahtar) ve bir sonraki parola doğrulaması istemini kullanarak oturum açmayı dener. Ancak, sshd beş hatalı giriş denemesinden sonra bağlantıyı keser (yine varsayılan olarak değişebilir).

Bu nedenle, .ssh dizininizde çok sayıda özel anahtar varsa, Public Key Authentication İsteğe bağlı bağımsız değişkenini kullanarak komut satırında -o Seçeneğini devre dışı bırakabilirsiniz.

Örneğin:

$ ssh -o PubkeyAuthentication=no [email protected]
98
Will Verna

Uzak makinede/etc/sshd_config dosyasını açın ve değeri değiştirin

MaxAuthTries 30

Birden çok anahtar yüklediğinizde veya birden çok bağlantı açtığınızda bu tipik bir sorundur. Sunucu her anahtarı adım adım kontrol eder ve MaxAuthTries 3'te ayarlanmışsa, ilk 3. denemeden sonra Sizi keser. Tipik ssh güvenliği.

Sorunu analiz etmek için uzak makineye bağlantı sırasında ayrıntılı modu kullanmanızı öneririm.

ssh -v -p port_numarası kullanıcı @ sunucuadı

Bu forumda çoğu insan gibi tahmin YANLIŞ ve zaman kaybıdır. Önce problemi analiz etmeye çalışın, bilgi toplayın ve sonra sorun.

İyi eğlenceler.

17
user59664

Benim için bu sorun bağlandığım ana bilgisayar için aşağıdaki ssh_config oluşturularak çözüldü.

(~/.Ssh/yapılandırma)

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

Sorun, ~/.ssh klasörü, 16 gibi. Yapılandırmadaki bu IdentityFile AND IdentitiesOnly yönergelerinin her ikisi olmadan, makinem görünüşe göre ~/.ssh ve doğru IdentityFile dosyasını denemeden önce maksimum deneme sayısına ulaşma.

15
Ninjaxor

Bu kötü bir uygulamadır. Uzak kutuda düzenli bir kullanıcı var ve onu kullanarak ssh üzerinden bağlanın, sonra su/Sudo kullanarak root erişimi kazanın.

12
Anonymous

Aynı sorunla da karşılaştım. Pageant kullanıyorsanız ve içine çok sayıda anahtar yüklüyse , çünkü bu sunucular bir ortak anahtarın her teklifini bir kimlik doğrulama girişimi olarak saymaktadır.

(Bu tavsiye burada adresinden alınmıştır.)

6

Yukarıda Anon'un yayınladığı gibi, ssh erişimi kazanmak için başka bir kullanıcı kullanmanızı ve su erişimi kazanmak için root komutunu kullanmanızı öneririm.

Ayrıca, PermitRootLogin işlevini /etc/ssh/sshd_config sunucudaki dosya.

6
Rodent43

Aşağıdaki komutları çalıştırarak sistemlerimdeki bu sorunu giderdim:

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

Sonra uzak makinede ssh deniyor

5
Sunil shakya

İşler başka yerlerde belirtildiği gibi tam olarak ele alınana kadar bu sorunu geçici olarak çözmek için kullanıcının PAM hesabını tekrar deneyebilir, böylece tekrar deneyebilirler:

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

Benzer bir sorundan ısırıldım. Ancak asıl sebep ForwardAgent yes boru boyunca bir makinenin yapılandırma dosyasında. A makinesinden B makinesine C makinesine bağlanıyordum.

Hata mesajı, B -> C den ssh denemesinde gösterildi, ancak A'nın yönlendirme etkin olması neden oldu. Bu yüzden C'ye önce A'nın tüm anahtarlarına, ancak o zaman B'den gelen anahtarlara hizmet edildi.

A'ya bir anahtar daha eklediğimde aniden ortaya çıktı.

2
Igor Stoppa

Bu sorunu Mac'imde giderdim:

  1. "Sudo passwd root" ile root şifresini ayarladıktan sonra
  2. ssh config dosyasını "nano/etc/ssh_config" ile düzenleme ve kaydetme ve
  3. rSAAuthentication'ı evet yerine "hayır" olarak değiştirmek.
1
tallbr00

Diğer yanıtlar size kök olarak bağlanmanın en iyi yolunu ve bunun güvenlikle ilgili sonuçlarını söyler, ancak açık sorunuz

nasıl bu hata durumdan kurtarmak ve PuTTY tekrar giriş izin?

En son bağlandığınızı belirttiğinizde, uzak sunucu bağlantıyı kesti.

Ne bulabileceğini düşünüyorum uzak sunucu fail2ban (*) çalışıyor ve başarılı giriş sonra IP "hapse". Tekrar giriş yapmaya çalışarak bunu test edebilirsiniz ve hatta giriş İstemi bile almayacaksınız.

İki çözüm var, ya hapis zamanını bekleyebilirsiniz, bu noktada işler normale döner, ancak hapis zamanı herhangi bir şey olabilir. Ya da oturum açmak, bunu yapmak ve IP'nizi "hapisten çıkarmak" için farklı bir bilgisayar bulabilirsiniz, bu durumda "farklı" uzak sunucunun bakış açısındandır, bu nedenle aynı güvenlik duvarının arkasındaki başka bir bilgisayar da muhtemelen çalışmaz .

(*) fail2ban, çeşitli günlük dosyalarını periyodik olarak kontrol edebilen ve sunucunun istemciden potansiyel olarak kötü niyetli davranışlar algıladığında sunucunun "kaybolmasını" sağlamak için güvenlik duvarı kurallarını ayarlayabilen süper kullanışlı bir arka plan programıdır. Debian'da, belirli bir IP'den birden fazla başarısız ssh girişini algılamak için yapılandırılmış kutudan çıkar ve 3'ten sonra (sanırım) bu IP'den tüm paketleri bırakır. Senaryo, kaba kuvvet saldırılarını durdurmak için mükemmel çalışıyor.

0
Sufferer

Bu sorunu Ubuntu 16.04 sunucumdaki iki basit adımla çözdüm -

Önce vnc sunucumu durdurun veya işlemi sonlandırın -

vncserver -kill :1

ve sonra tekrar başlatın -

vncserver

Bundan sonra Uzak Masaüstü istemcisinden bağlayın -

999.99.99.99:5901

Yapıldı !!

0
Rajnesh Thakur

Tamam, benim durumumda bu oldukça garipti, işte gidiyor ...

Standart bir vagrant VM bir SSH anahtarı ile ve SSH PuTTY kullanarak içine alabilirim. PHPStorm dağıtım sırasında üzerine almaya çalışırken ben too many authentication failures hata. Böylece MaxAuthTries değerini sshd_config ve sonra Auth failed hatası ve sonra Auth cancel.

Şimdi, neden bunu denediğimi tam olarak bilmiyorum ama ... Noktayı PHPStorm'daki dağıtım penceresinde SSH anahtar yolumun sonuna ekledim. Yani şöyleydi:

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

ve şimdi şöyle:

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

Ve çalışıyor ... ".ssh" klasörümde daha fazla dosya var:

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

Bu uğrak noktasının ne yaptığından emin değilim ama .ppk dosya çalışmıyor bu yüzden biraz büyü sanırım;) Oh, ve ben "nokta hile" sonra MaxAuthTries kurtulabilirsiniz.

0
Adam Witorean

@ Başka bir yanıtta belirtildiği gibi, bazı Linux dağıtımları, SSH gibi harici görünür hizmetlere yönelik kaba kuvvet saldırılarına karşı korunmak için monitörler içerir, örneğin DenyHosts veya fail2ban. Bu monitörler, başarısız denemeleri arayan günlük dosyalarını kontrol eder ve çok fazla başarısızlığa sahip IP adreslerini engellemek için filtreler ekler (sayı yapılandırılabilir ve sshd config'ten bağımsızdır).

Dağıtımınız iptables güvenlik duvarına kurallar ekleyerek hizmetleri koruyan fail2ban İçeriyorsa, aşağıdaki hizmetleri kullanarak hangi hizmetlerin veya "hapishanelerin" denetlendiğini kontrol edebilirsiniz:

Sudo fail2ban-client status

SSH hizmeti için hapishane sshd'dir, bu nedenle kullanabileceğiniz yasaklı IP'ler olup olmadığını kontrol etmek için:

Sudo fail2ban-client status sshd

ve bazı IP engellemelerini kaldırmak için:

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

DenyHosts varsa, yasaklanan liste /etc/hosts.deny dosyasında bulunur; bu dosyayı doğrudan kök olarak düzenleyebilirsiniz. Bazı IP a.b.c.d kalıcı erişimi vermek için, sshd:a.b.c.d Satırını /etc/hosts.allow dosyasına ekleyebilirsiniz.

Her zaman olduğu gibi, man komutu arkadaşınızdır:

man fail2ban
man hosts.deny

Başka benzer araçlar da olmalı, ama ben sadece bunları kullandım.

Sshd yapılandırmasında izin verilen yeniden deneme sayısının artırılmasının yasaklanan IP'leri serbest bırakmadığını, yalnızca aynı bağlantıda daha fazla hataya izin verdiğini unutmayın. İzin verilen sayı aşılırsa, kullanıcı/saldırgan n kez daha denemek için tekrar bağlanır.

Diğer hizmetlerde yasak listesi entegre edildi (Rajnesh Thakur'un VNC sunucusunu yeniden başlatma hakkındaki cevabında gösterildiği gibi).

0
Fjor