Kapan ssh -t tidak sesuai bukan ssh?

Menggunakan ssh -tbukannya sshuntuk koneksi ke server jauh memiliki beberapa keunggulan. Sebagai contoh, saya dapat langsung mengedit file dengan vim:, ssh -t host vim foo.txtyang akan gagal jika tidak.

Apakah ada situasi di mana mengalokasikan (pseudo) -tty akan menjadi hal yang buruk ketika menggunakan ssh?

Ketika memipihkan input atau mendapatkan input kembali, yang merupakan penggunaan khas dari "perintah ssh host". Karakter kontrol dapat ditafsirkan oleh lapisan TTY (^ S untuk contoh.)

Ya, kadang-kadang Anda ingin membuat koneksi yang diam dan berlatar belakang, misalnya ketika menyiapkan terowongan (mis. SOCKS proxy). Dalam contoh seperti itu, Anda ingin proses TIDAK memiliki tty.

Berikut adalah contoh pengaturan port forwarding dari localhost ke beberapa host jarak jauh ...

ssh -l username -fNTL 8073:server:873

Setelah ini diatur, Anda kemudian dapat rsync ke localhost, bukan ke host jarak jauh, maka secara efektif, tunneling rsync Anda melalui ssh...

rsync --port=8073 -a me@localhost::myStuff /tmp/myStuff/

Anda akan melakukan ini mengatakan jika rsync keluar untuk serverdiblokir, tetapi sshtidak.

Selain di atas ...

(1) penanganan tilda melarikan diri yang berbeda:

"~." escape akan memutuskan koneksi Anda jika Anda memiliki pty (-t). Untuk perintah yang sudah berjalan lama, Anda mungkin ingin mencegah seseorang menghentikan proses secara tidak sengaja jika mereka mengetik ~.

$ ssh hostname.tomontime.com -t sleep 60
[type ~. dan itu terputus]
Koneksi ke hostname.tomontime.com ditutup.

$ ssh nama host -T tidur 60
[Saya ketik ~. dan itu memperlakukannya seperti penekanan tombol normal, yang diabaikan oleh perintah sleep.]
~.
~.

Coba hal yang sama dengan CTRL-C. Anda akan melihat bahwa dengan -t Anda mengirim CTRL-C ke "sleep". Dengan -T Anda mengirim CTRL-C ke program ssh yang berjalan pada mesin Anda. Mungkin ada saat-saat ini membuat perbedaan (yaitu program menangani INT berbeda dari HUP)

(2) Anda hanya ingin meminimalkan pty atau aktivitas koneksi jaringan.

Ketika mencoba untuk me-reboot mesin yang kehabisan ptys Anda tidak ingin mendorong sistem untuk mencoba mengalokasikan pty! Ini juga meminimalkan koneksi jaringan yang harus ditutup (menunda reboot).

Ini akan bekerja lebih cepat dan lebih andal:
ssh -T reboot nama host

Ini mungkin memiliki masalah:
ssh -t hostname reboot

ssh -t membuat terminal semu pada mesin jarak jauh. Ini berguna jika Anda chaining perintah ssh melalui beberapa server dan ingin terminal nyata di sisi yang jauh (jadi Anda bisa menggunakan 'vi' misalnya).

Anda mungkin TIDAK ingin '-t' ketika skrip login berperilaku berbeda jika ada terminal. Ini adalah praktik buruk IMHO, tetapi saya telah melihat kasus di mana skrip login memeriksa TTY sebelum 1) mengatur prompt, dan 2) memperluas jalur ke banyak aplikasi interaktif.

Dalam contoh lain (disebutkan oleh TomOnTime di atas), saya benar-benar mengalami kasus di mana semua TTY (ptys) digunakan. Jelas konfigurasi yang salah, tetapi tidak perlu mengunyah sumber daya untuk sekelompok terowongan dan rsyncs.