Garip SSH sorunu, ssh -t ile çalışıyor ancak onsuz donuyor

sshSunucularımdan birine girdiğimde , oturum açmış gibi görünüyor, ancak bana istemi ( message debug2: shell request accepted on channel 0 is the last log entry) vermeden önce kilitleniyor .

Her ne kadar garip bir şey olsa da ssh -t "/bin/bash"işe sshyaramaz.

Şimdiye kadar ne buldum

• Normalde aynı coğrafi konumdaki sunuculardan iyi giriş yapabilirim
• I ssh -t '/bin/bash'- Ben HERHANGİ bir yerden mükemmel giriş yapabilirsiniz.
• Ben kullanırsanız rsync için sunucuya, bu işin görünüyor ve sonra kilitler
• Ben kullanırsanız rsync gelen sunucunun, bu sorun olmadan çalışır

Ne denedim

• tüm giriş seçeneklerini kaldırmak veya değiştirmek .profile,.bashrc /etc/profile
• Değişen ssh_config ve / veya sshd_config para cezası çalışan benzer bir sunucudan birine
• Yönlendirmeyi kontrol ettim
• Hiçbir ağ boşluğunu incelemek tcpdumpiçin bir ağ uzmanım oldu (yeniden iletimlerin bir sürü gibi görünse de)

Gerçekten başka bir şey düşünemiyorum

Tehlikeli bir ağ kartı sürücüsü / firmware dışında.

Bu profildeki bir sorundan kaynaklanıyor olabilir. Kabuk
ile bağlandığınızda ssh -t /bin/bash'giriş' olmaz, /etc/profilene kaynak olmaz ~/.profileve ~/.bashrc...

Bağlandıktan sonra, kabuğu hata ayıklama moduna getirin ve içeride neyin engellendiğini bulmak için her dosyayı kaynaklayın:

set -x 
. /etc/profile 
...and so on

DÜZENLE

Yanlış olduğumu unutmayın, .bashrc dosyası herhangi bir etkileşimli kabuk tarafından kaynaklanacaktır (bu nedenle sadece profil, profil.d dosyaları burada önemlidir).

Bağlantı işleminin farklı aşamalarının listesini yapmaya çalışın. Böyle bir şey

1) ssh bağlantı (yapılandırma, ...)
2) oturum açma (PAM, tty, wtmp, ...)
3) kabuğu başlatma (profil, ana sayfa erişimi, ...)

(1) 'i kontrol etmek için sshd arka plan programını hata ayıklama modunda başlatabilirsiniz. Bunun için ayrı bir bağlantı noktasını dinleyerek başka bir sshd başlatmanız gerekir (bağlantı noktası 22'de değil, bu nedenle normal sshd arka plan programını durdurmaya gerek yoktur).

# /usr/sbin/sshd -p 2222 -ddd 

Bu sshd yalnızca bir bağlantıyı kabul eder ve arka plana girmez. Başka bir terminal açın ve bu ssh oturumuna bağlanın.

# ssh -vvv -p 2222 user@host

Aldığınız mesajları aynı markanın başka bir sunucusuyla karşılaştırabilirsiniz. O zaman sorunun ssh tarafında olup olmadığını bileceksiniz.

(-ddd ve -vvv maksimum hata ayıklama düzeyidir, bunu ayarlayabilirsiniz)

Bu bağlantıyı aldım , çok daha ayrıntılı.

Sorunumun cevabı bir ağ sorunu olduğu ortaya çıktı. Sonunda, tüm ağ kartlarının MTU'yu biraz aşağı bırakarak sorunun ortadan kalktığını öğrendim.

Büyük olasılıkla bir şey o ağ için yanlış yapılandırılmış, ancak şimdi bunu kanıtlayabilir ve ağ ekibine teslim edebilirim (bana bir sunucu sorunu olduğunu söylemeye devam etti).

Olsa da, bu son çare olduğunu fark Ben ssh sunucu aynı alt ağdan çalıştı ama onun dışında değil ve ssh -t '/ bin / bash' her yerden çalıştı oldu.

Ayrıca iyi başlayacak rsyncs vardı, ama bir noktada sadece asmak veya bağlantıyı bırakın.

Bu cevaba bakıyorsanız, önce yukarıdaki diğerlerini deneyin ve SADECE benim gibi tuhaflıklar alırsanız, bu muhtemelen yardımcı olacaktır.

Bu yüzden tüm yardım için teşekkürler. Her şeyi denedim ve bana yükleri öğretti ve bana sunucu ile ilgisi yoktu (ki umduğum her şey) teyit edeyim.

Yardım eden herkese teşekkürler

Bunu yaptığınızda ssh some_user@some_host /bin/bash, size başlatıyor ne yaptığını some_user (tanımlanan 'ın kabuk /etc/passwdüzerinde some_host ) ve daha sonra, verilen komutu yürütülürken /bin/basho kabuğun içinden.

Şimdi, some_user'ın kabuğu (varsayalım da bash) etkileşimli olarak başlatılmıyor (bunun yerine verilen komutu yerine getiriyor). Bu yüzden bir pty ( sahte terminal ) tahsis etmez ve bu, verilen komutun kullanması için bir pty olmadığı anlamına gelir, bu nedenle etkileşimli olmayan şekilde başlar.

Örnekte, istenen /bin/bashkomut başlatılır ancak askıda gibi görünür.

sshKabuk ve alt süreçleri için bir tane olması için yine de bir pty oluşturmayı sorarak bunu düzeltebilirsiniz . İşte -tböyle.

    $ ssh -t some_user@some_host bash

Bunu, komutu bir pty oluşturmaya zorlayarak da düzeltebilirsiniz. Çünkü bashbunu bir -iargüman ileterek yaparsınız . Aşağıdaki komut satırı da çalışmalıdır:

$ ssh some_user@some_host bash -i

Bununla birlikte, bu son durumda kabuğun erişemeyeceğini /dev/ttyve bunun bir uyarı ile sonuçlandığını unutmayın:

bash: no job control in this shell

Bunun nedenleri burada açıklanmaktadır . Bu, kabukta ne yapmayı planladığınıza bağlı olarak bir sorun olabilir veya olmayabilir, ancak ssh -tmuhtemelen daha iyi bir seçenektir.

( bashkomutun yalnızca kullanıcı olarak varsayılan kabuğunun yolunda olması gerektiği için iletilebileceğini unutmayın)

Son zamanlarda iç içe bir sanallaştırma platformu kullandığımda da aynı sorun yaşıyorum.

Kaynak veya hedef sunucuda MTU'yu 1500'den 1400'e düşürdükten sonra çalışır.

/sbin/ip link set dev eth0 mtu 1400