ssh şifre istemi olmadan kilitleniyor - root veya diğer hesaplarda çalışır

Ben ssh anahtar tabanlı giriş iyi çalışıyor vardı. Sonra bilgisayarımdaki ana bilgisayar adını değiştirdim ve anahtar tabanlı oturum açma işlemi durdu. Mantıklı görünüyordu. anahtarlar büyük olasılıkla eski ana bilgisayarıma dayanıyordu. Bu nedenle, ~ / .ssh / içindeki tüm anahtarlarımı ve tüm dosyaları sildim ve bunları yeniden oluşturdum (ve bağlandığım sunuculardaki yetkili_anahtarları değiştirdim)

Şimdi, ssh denemeye çalıştığımda, ssh için çalıştığımdan bağımsız olarak, şifre tabanlı oturum açmadan kilitleniyor, hatta anahtar tabanlı oturum açma ayarlarının olmadığı sunucular bile. .Ssh / config dosyasında hiçbir şey yok.

Üstelik kök salmaya başladığımda ssh mükemmel çalışıyor. hiç sorun yok. Bu yalnızca kullanıcı hesabımda olur.

Ssh bazı hata ayıklama bilgileri aşağıda

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Yapılandırma verilerini okuma /Users/myname/.ssh/config
debug1: Yapılandırma verilerini okuma / usr / etc / ssh_config
......
debug1: 'myremoteserver.com' ana bilgisayarı biliniyor ve RSA ana bilgisayar anahtarıyla eşleşiyor.
debug1: /Users/myname/.ssh/known_hosts:1 içinde anahtar bulundu
debug2: bit kümesi: 512/1024
debug1: ssh_rsa_verify: imza doğru
debug2: kex_derive_keys
debug2: set_newkeys: mod 1
debug1: SSH2_MSG_NEWKEYS gönderildi
debug1: SSH2_MSG_NEWKEYS bekleniyor
debug2: set_newkeys: mod 0
debug1: SSH2_MSG_NEWKEYS alındı
hata ayıklama1: SSH2_MSG_SERVICE_REQUEST gönderildi
debug2: service_accept: ssh-userauth
hata ayıklama1: SSH2_MSG_SERVICE_ACCEPT alındı

Ve sonra burada asılı kalıyor .....

Aşağıda asılı olduğu yere yakın dtruss (strace gibi ama OSX için) çıktı: sudo dtruss ssh -vv mylogin@myremoteserver.com

seçin (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
oku (0x3, "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260! {\ 342 \ 017 \ 271 = \ 222, \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z # \ 0 ", 0x2000) = 48 0
yazma (0x2, "debug2: service_accept: ssh-userauth \ r \ n \ 0", 0x26) = 38 0
bağlayın (0x4, 0xBFFFEEA2, 0x6A) = 0 0
yazma (0x4, "\ 0", 0x4) = 4 0
yazma (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
oku (0x4, "\ 0", 0x4) = -1 Hata # 4

Bir şey okumayı deniyor gibi görünüyor ve sadece bunun üzerinde asılı duruyor. Birinin önerileri veya fikirleri varsa, çok minnettar olurum!

Ssh istemcinizin hesabınız için askıda kalması, ancak diğer hesaplar (kök) için askıda kalmamasının nedeni muhtemelen ssh-agent'ınızla ilgili bir sorun var. Ya ssh-agentçalışmıyor ya da yapılandırması bir şekilde yanlış.

Bunu onaylamak için aşağıdakileri deneyebilirsiniz:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

Daha sonra ssh_key'inize geçiş deyimini girmeniz istenirse, ssh-agent'ınızla ilgili bir sorununuz olduğu anlamına gelir.

Bu ilgili soru hakkındaki yazımı da görün .

Sizi ters DNS ile ilgilendirebilir miyim?

Temel olarak, istemci sunucuda ters DNS yapıyor ya da tam tersi.

Bir test öneriyorum:

/ Etc / ssh / sshd_config dosyasını düzenleyerek ve "UseDNS" öğesinin "no" olarak ayarlandığından emin olarak sunucudaki DNS aramalarını devre dışı bırakın.

"Service ssh reload" (ya da ssh daemon'unuzun yapılandırmayı yeniden okumasına neden olan şey) çalıştırın, sonra tekrar deneyin.

Kesinlikle, uzun bir süre sonra nihayet sizi uyaracak gibi değil, değil mi?

Kontrol edebileceğiniz başka bir şey, sunucuda / etc / hosts içeriğinin hiçbir şeyin yanlış olmadığından emin olmaktır.

~ / .Ssh dizinindeki ve içindeki dosyalardaki izinleri kontrol edin. Varsayılan umask'ınız çok izin verici olabilir ve dosyaları yeniden oluşturduğunuzda, yanlışlıkla yanlış izinler vermiş olabilirsiniz. Bunu birkaç kez kendim yaktım. Hiç kullandığım ssh istemcileri (veya sunucuları) hiç bu konuda yararlı bir hata mesajı verdi ...

istemcinizde (ve sunucunuzda) boş disk alanınız var mı?

df -h

Benzer bir sorun yaşadım.

ssh domain.ip:user.name

Görünüşe göre böyle bir giriş adı girerek sorunu atlayabilirim.

ssh -v domain.ip -l user.name

Benim için Snow Leopard'a yükseltmek sorunu çözdü. Yani, OSX'teki bir hata ile ilgili olduğunu düşünüyorum.

Kayıtlı bir anahtardan kaynaklanıyorsa, bilinen_hosts dosyasındaki ~ / .ssh dizininizden silebilmeniz gerekir. Sadece girişi bulun ve silin, sonra tekrar sormanız gerekir.

Diğer yandan, ana bilgisayar kaydedilenle eşleşmediğinde bir uyarı vermelidir.

Ben OS X üzerinde ana bilgisayar adı arama başarısız gibi davranır sorunları vardı; bağlantının bu kadar uzun süre beklemesinden zaman aşımına uğrar veya bilgi istemi geldiğinde bağlantı kesilmeden önce bir parola girmeniz yaklaşık on saniye sürebilir. Ben insanlar ana bilgisayarına söz konusu ana bilgisayar ekleme önermek rağmen ben asla iz. Sanırım bu sadece bir "OS X'in DNS aramalarıyla ilgili bir aksaklıktı" ve tolere edilmesi bekleniyordu ... bir başkası bu sorunu yaşadıysa ve çözerse, bunu bilmek isterdim.

Sunucudaki günlükleri kontrol edin. Genellikle /var/log/auth.log(Debian / Ubuntu) veya /var/log/secure(RedHat / CentOS) 'dadır. Bağlanma ile ilgili sorunlar genellikle orada kaydedilir.

/ Etc / hostname öğesinin yeni satır sonlandırıldığından emin olun.