ssh bağlantısı başlatmak için sonsuza kadar sürer, “rehin: ağ”

Sunucularımdan birine ssh kullanan bağlantıların başlatılması 20 saniyeden uzun sürüyor.

Bu LAN veya WAN koşullarıyla ilişkili değildir, çünkü kendi kendine bağlantı aynıdır (ssh localhost). Bağlantı nihayet kurulduktan sonra, sunucuyla etkileşime geçmek süper hızlıdır.

-Vvv kullanılması, "rehin: ağ" derken bağlantının yapıştığını gösterir. Bu noktada, burada görüldüğü gibi kimlik doğrulama (burada anahtarı kullanarak) yapılmıştır:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... 15 ila 25 saniye burada kaldı ...)

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Sunucu Ubuntu 16.04. Geçmişte zaten başıma başka bir sunucuyla başıma geldi (Ubuntu 12.04 idi), sinir çözümünü buldu ve sorun bir süre sonra hayal kırıklığına uğradı ...

sshd_config, Ubuntu tarafından sağlanan varsayılan değerdir.

Şimdiye kadar denedim:

• -o kullanarak GSSAPIAuthentication = ssh komutunda hayır
• anahtar yerine şifre kullanılması
• UsePrivilegeSeparation no yerine yes (sshd_config) kullanarak

Bu muhtemelen bir konudur D-Busve systemd. Eğer dbushizmet nedense yeniden, ayrıca yeniden başlatma gerekir systemd-logind.

Sorunun ssh daemon logunu açarak (Ubuntu'da olması gerektiği gibi /var/log/auth.log) olup olmadığını kontrol edebilir ve şu satırları olup olmadığını kontrol edebilirsiniz:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Eğer evet ise, systemd-logindservisi yeniden başlatmanız yeterlidir:

systemctl restart systemd-logind

Aynı sorunu CentOS 7'de de yaşadım, çünkü messagebusyeniden başlatıldı ( D-Bushizmet CentOS'ta böyle adlandırılıyor).

cevabı buldum:

sshd_config dosyasında UsePAM'i evet'den hayır'a değiştirdi

Ssh servisini yeniden başlattıktan sonra bağlantı şimdi sunucuya anında gönderilir. Bu sunucuda PAM, ldap ile bağlantılıdır, bu yüzden muhtemelen nedeni, burada bir LDAP sunucusundan değil, sunucunun kendisinde ilan edilen bir kullanıcıyla bağlantı kursam bile.

Peki, bu sorunu atlamak için daha bir yoldur, gerçekten bir çözüm değil ... Bu sunucuya sahip aynı şekilde ayarlanmış başka sunucular var.

Umarım bu birine yardımcı olabilir ...

Bu, iki Fedora 25 sunucumda oldu ve birçok SSH giriş denemesi başarısız oldu.

(Kullanmanın GSSAPIAuthentication=nove UseDNS=noyeniden başlatmanın genel önerileri bir systemd-logindfark yaratmadı .)

Bu sunucularda, /etc/pam.d/postloginşunları içerir:

session     optional      pam_lastlog.so silent noupdate showfailed

İçin man sayfası pam_lastlog, showfailedseçeneğin şöyle olacağını açıklar :

Başarısız oturum açma denemelerinin sayısını ve btmp'daki son başarısız denemenin tarihini görüntüleyin.

Bu sunucularda, /var/log/btmpbirçok başarısız oturum açma girişimi nedeniyle dosyalar muazzamdı. btmpGünlük dosyaları ya döndürülmüş olması değildi.

logrotateGünlük dosyalarının ileride döndürülmesini sağlamak için paketi kurdum . (Fedora'da, birlikte verilen yapılandırma logrotate, dönüşünü gerçekleştirir /var/log/btmp.)

Ayrıca büyük btmpgünlük dosyalarını sildim ; Bunu yapar yapmaz, sunuculara bağlanmak tekrar anında oldu.

Benim durumumdaki sebep çöktü rsyslogd oldu. Bunu öğrendim çünkü örn. / Var / log / syslog veya /var/log/mail.log’da daha fazla log mesajı yoktu.

Böylece service rsyslog restartbizim için sorunu çözdü.

Benim için bu sorun büyük (yüzlerce MB) btmpdosyasından kaynaklanıyor. Bu dosya giriş girişimlerini günlüğe kaydeder. İnsanlar kaba kuvvete zorlamaya çalışırken bu dosya büyük olabilir ve bu "pledge: network"aşamada gecikmelere neden olabilir .

Günlük dosyasını temizlemeye çalışın

echo "" > /var/log/btmp

ve yardımcı olup olmadığını görmek.

Benim için çözüm ekliyordu

UseDNS no

için /etc/ssh/sshd_configve sonra tabii ki service ssh restart(bizim Debian / Jessie sunucuda). Başka hiçbir şey...

önce :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

sonra :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

Hata ayıklama geribildirimimde şu satırı fark ettim:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

root:rootBen ise sahip olduğum bir dosyaydı jenkins. Bu dosyayı kaldırmak sorunlarımı çözdü.