Penanganan Ctrl-C dalam sesi SSH


20

Ketika saya memulai sesi SSH yang mengeksekusi perintah yang sudah berjalan lama, apa yang terjadi dengan penanganan Ctrl+ C(SIGINT)?

Saya dapat melihat bahwa sesi SSH ditutup, tetapi saya tidak yakin siapa yang mendapatkan SIGINT pertama: apakah itu ...

  1. perintah jarak jauh yang berjalan lama? yaitu, (a) pengendali sinyal dalam perintah jarak jauh dipanggil dan menghentikan perintah jarak jauh, (b) shell yang menelurkannya mendeteksi bahwa perintah berhenti, dan berhenti juga (c) sshd jarak jauh mendeteksi shell berhenti, jadi itu menutup koneksi

    atau

  2. ssh lokal menerima sinyal, dan menutup koneksi.

Saya pikir (1) sedang terjadi, tetapi ingin memastikan.

Saya juga tidak yakin tentang apa yang terjadi dengan penanganan shell SIGINT dalam kasus ini. Misalnya, jika saya ...

ssh remote 'while true ; do sleep 1 ; date ; done'

dan Ctrl+ C, maka koneksi jarak jauh dijatuhkan. Apakah ada cara untuk menjalankan perintah remote di bawah shell yang akan tetap hidup setelah Ctrl+ C? Artinya, dalam hal ini, hentikan loop dan izinkan saya untuk terus bekerja pada shell jarak jauh?


3
Ssh noninteraktif ( ssh remote command, sebagai lawan dari ssh remote) akan dibunuh (di sisi lokal) oleh SIGINT yang dihasilkan dengan mengetikkan ctrl-C. Sisi jarak jauh mungkin (tergantung pada OS) tetap berjalan sampai mencoba membaca atau menulis ke soket yang tertutup. Jika Anda ingin semua penekanan tombol, termasuk ctrl-C, diteruskan ke remote, gunakan ssh remote.
Mark Plotnick

@MarkPlotnick: OK Tandai - jika Anda menambahkan respons Anda di bawah sebagai jawaban, saya akan menerimanya ... Dalam pengujian saya sendiri, saya memverifikasi bahwa remote tidak menerima sinyal apa pun.
ttsiodras

Jawaban:


23

sshdapat dipanggil dalam beberapa cara berbeda, masing-masing menghasilkan perlakuan yang sedikit berbeda dari sinyal yang diprakarsai terminal seperti Ctrl-C.

  • ssh remotehostakan menjalankan sesi interaktif remotehost. Di sisi klien, sshakan mencoba untuk mengatur tty yang digunakan oleh stdin ke mode "raw", dan sshdpada remote host akan mengalokasikan pseudo-tty dan menjalankan shell Anda sebagai shell login (misalnya -bash).

    Mengatur mode mentah berarti bahwa karakter yang biasanya mengirim sinyal (seperti Ctrl-Cdan Ctrl-\) malah dimasukkan ke dalam aliran input. sshakan mengirim karakter seperti apa adanya ke host jarak jauh, di mana mereka kemungkinan akan mengirim SIGINT atau SIGQUIT dan, biasanya, membunuh perintah apa pun dan mengembalikan Anda ke shell pada host jarak jauh. Koneksi ssh akan tetap hidup, selama shell jarak jauh hidup.

  • ssh -t remotehost command args ...akan menjalankan sesi interaktif remotehost, sama seperti di atas, kecuali di sisi jarak jauh, your_shell -c "command args ..."akan dijalankan. Seperti di atas, jika Anda mengetik Ctrl-C, itu akan dikirim ke host jarak jauh, di mana perintah kemungkinan akan menerima SIGINT dan segera keluar, dan kemudian shell jauh akan keluar. Remote sshdkemudian menutup koneksi, dan sshmelaporkanConnection to remotehost closed.

  • ssh remotehost command args ...akan menjalankan sesi non-interaktif remotehost. Di sisi klien, tidakssh akan mengatur tty ke mode mentah (well, kecuali untuk membaca kata sandi atau frasa sandi). Jika Anda mengetik , akan dikirim SIGINT dan akan segera dihentikan, bahkan tanpa mengeluarkan pesan.Ctrl-CsshConnection to remotehost closed

    The your_shell -c "command args ..."proses akan cenderung tetap berjalan pada host remote . Entah mereka akan keluar sendiri, atau satu proses akan mencoba untuk menulis data ke soket ssh yang sekarang ditutup, yang akan menyebabkan sinyal SIGPIPE (biasanya) fatal dikirim ke sana.


1
Secara teknis, perintah jarak jauh tidak menulis langsung ke soket. Stdout-nya adalah pipa. Dan sshd di ujung yang lain membaca data, mengenkripsi, dan mengirimkannya ke soket. Hasil akhirnya sama saja. Perintah akan mendapatkan sigpipe karena pipa itu hilang ketika klien terputus.
Stéphane Chazelas

@ StéphaneChazelas Terima kasih, saya akan mengedit jawaban untuk memperbaikinya.
Mark Plotnick
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.