> И, кстати, я где-то слышал, что telnet: не безопасен.

Вот тебе, митрофаныч, задача.
Есть у нас некий "кластер на проводах", состоящий, скажем, из
десятка хостов с UNIX-like системой, скажем, Linux.

Есть у нас десятки тысячи задач, которые нужно равномерным слоем
размазать по этому кластеру. Да, кстати, кластер внутри
небольшого езернет фрагмента большой "корпорастии",
так что за безопасность трафика можно не беспокоиться.

Решаем мы ее так:

paexec -x -n 'host1 ... host10' -c remote_command -t transport < tasks

paexec -- это моя поделка, но сути ведь это меняет, правда?
remote_command принимает задачу (одну) в качестве своего
единственного аргумента. В качестве транспорта мы можем
использовать любую ssh-like утилиту, скажем, ssh или rsh.

Проблема вот в чем. В случае транспорта ssh, если мы жмем C-c или C-\,
локальные ssh-ы прибиваются, а вот remote_command-ы на хостах -- нет.
В случае rsh -- прибивается все, включая удаленные процессы,
т.е. remote_command-ы получают
свои SIGINT/SIGQUIT и честно умирают, и именно это
поведение мне кажется единственно верным.
Болтающиеся часами не понятно зачем процессы никому не нужны,
как мне представляется.

В man-е NetBSD (пардон) на rsh сказано следующее:

  Interrupt, quit and terminate
  signals are propagated to the remote command

В мане на rsh в Debian-е ничего подобного нет, но работает он
так же, т.е. с моей точки зрения правильно.

Итого, варианты наших действий:
1) читаем код ssh/sshd и выясняем, в чем причина такого поведения, пишем патч,
   отсылаем его апстриму;
2) пинаем апстрим (OpenBSD-шников) на предмет, фича это или баг, и в чем причина
   такого поведения, далее запрашиваем фичу в случае, если бага;
3) быстро решаем проблему, заменяя привчный ssh на "устаревший" rsh
   и откладываем пункты 1 и 2 "на потом", когда появится время.

Что будем делать, митрофаныч?