Masalah SSH yang aneh, ssh bekerja dengan -t tetapi macet tanpa itu

Ketika saya sshmasuk ke salah satu server saya, sepertinya masuk, tetapi kemudian hang sebelum memberi saya prompt ( message debug2: shell request accepted on channel 0 is the last log entry).

Padahal yang aneh adalah ssh -t "/bin/bash"berhasil padahal sshtidak.

Apa yang saya temukan sejauh ini

• Saya dapat masuk dengan baik dari server di lokasi geografis yang sama secara normal
• Jika saya ssh -t '/bin/bash'- saya dapat masuk dengan sempurna dari lokasi APA PUN.
• Jika saya gunakan rsync ke server, sepertinya berfungsi, dan kemudian mengunci
• Jika saya gunakan rsync dari server, itu berfungsi tanpa masalah

Apa yang saya coba

• menghapus atau mengubah semua opsi masuk .profile,.bashrc /etc/profile
• Mengubah ssh_config dan / atau sshd_config ke satu dari server identik yang berfungsi dengan baik
• Saya sudah memeriksa rute
• Saya sudah minta pakar jaringan tcpdumpuntuk memeriksa tetapi tidak berhasil (walaupun tampaknya ada banyak transmisi ulang)

Saya benar-benar tidak dapat memikirkan hal lain

Terlepas dari driver / firmware kartu jaringan yang cerdik.

Itu mungkin berasal dari masalah di profil.
Ketika Anda terhubung dengan ssh -t /bin/bash shell Anda tidak akan 'login', tidak akan sumber /etc/profilemaupun ~/.profiledan ~/.bashrc...

Jadi setelah terhubung, letakkan shell dalam mode debug kemudian sumber setiap file untuk menemukan apa yang menghalangi di dalam:

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

EDIT

Perhatikan bahwa saya salah, file .bashrc akan bersumber dari shell interaktif (jadi hanya profil, file profile.d yang penting di sini).

Cobalah untuk membuat daftar fase berbeda dari proses koneksi. Sesuatu seperti ini

1) ssh menghubungkan (config, ...)
2) login (PAM, tty, wtmp, ...)
3) memulai shell (profil, home dir access, ...)

Untuk memeriksa (1) Anda dapat memulai daemon sshd dalam mode debug. Untuk itu Anda perlu memulai sshd lain, mendengarkan port khusus (bukan pada port 22 sehingga tidak perlu menghentikan daemon sshd biasa).

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

SSD itu hanya akan menerima satu koneksi dan tidak akan masuk ke latar belakang. Buka terminal lain dan sambungkan ke sesi ssh itu.

# ssh -vvv -p 2222 user@host

Anda dapat membandingkan pesan yang Anda dapatkan dengan server lain dengan merek yang sama. Maka Anda akan tahu apakah masalahnya ada di sisi ssh atau tidak.

(-ddd dan -vvv adalah level debug maksimum, Anda dapat menyetelnya)

Saya mendapatkan tautan itu , jauh lebih terperinci.

Jawaban untuk masalah saya Ternyata itu masalah jaringan. Saya akhirnya menemukan bahwa dengan menjatuhkan MTU dari semua kartu jaringan sedikit, masalahnya hilang.

Kemungkinan besar ada sesuatu yang salah konfigurasi untuk jaringan itu, tetapi sekarang saya dapat membuktikannya dan menyerahkannya kepada tim jaringan (yang terus mengatakan itu adalah masalah server).

Perlu diketahui juga, ini adalah pilihan terakhir . Keanehan yang saya miliki adalah bahwa ssh server bekerja dari subnet yang sama tetapi tidak di luarnya, dan ssh -t '/ bin / bash' bekerja dari mana saja.

Saya juga punya rsyncs yang akan mulai baik-baik saja, tetapi pada titik tertentu hanya menggantung, atau menjatuhkan koneksi.

Jadi jika Anda melihat jawaban ini, cobalah yang lain di atas terlebih dahulu, dan HANYA jika Anda mendapatkan keanehan seperti milik saya, apakah ini akan membantu.

Jadi terima kasih atas semua bantuannya. Saya mencoba semuanya, dan itu mengajari saya banyak, dan biarkan saya mengkonfirmasi itu tidak ada hubungannya dengan server (yang adalah semua yang saya harapkan).

Jadi terima kasih untuk semua yang telah membantu

Ketika Anda melakukannya ssh some_user@some_host /bin/bash, apa yang Anda lakukan adalah meluncurkan shell some_user (sebagaimana didefinisikan dalam/etc/passwd pada some_host ) dan kemudian menjalankan perintah yang diberikan /bin/bash,, dari dalam shell itu.

Sekarang, some_user shell (mari kita asumsikan juga bash) tidak diluncurkan secara interaktif (sebagai gantinya, ia menjalankan perintah yang diberikan). Jadi itu tidak mengalokasikan pty ( terminal pseudo ) dan ini berarti tidak ada pty untuk perintah yang dikeluarkan untuk menggunakan sehingga mulai non-interaktif.

Dalam contoh tersebut, /bin/bashperintah yang diminta diluncurkan tetapi tampaknya hang.

Anda dapat memperbaikinya dengan meminta sshuntuk membuat pty pula sehingga ada satu yang tersedia untuk shell dan proses anaknya. Inilah yang -tdilakukan.

    $ ssh -t some_user@some_host bash

Anda juga dapat memperbaikinya dengan memaksa perintah untuk membuat pty. Sebab bash, Anda melakukan ini dengan memberikan -iargumen. Baris perintah berikut juga harus berfungsi:

$ ssh some_user@some_host bash -i

Perhatikan, namun dalam kasus terakhir ini, shell tidak dapat mengakses /dev/tty dan ini menghasilkan peringatan:

bash: no job control in this shell

Alasannya dijelaskan di sini . Ini mungkin atau mungkin bukan masalah tergantung pada apa yang Anda rencanakan untuk dilakukan di shell tetapi menggunakan ssh -tmungkin merupakan pilihan yang lebih baik.

(perhatikan bahwa Anda hanya dapat meneruskan bashsebagai perintah karena harus berada di jalur shell default pengguna)

Saya memiliki masalah yang sama ketika saya menggunakan platform virtualisasi bersarang baru-baru ini.

Ini berfungsi setelah mengurangi MTU dari 1500 menjadi 1400 pada server sumber atau tujuan.

/sbin/ip link set dev eth0 mtu 1400