Как я могу подавить /etc /issue без потери сообщений об ошибках?

Question

Можно ли сказать клиенту ssh, что при подключении к удаленному хосту не печатать соединения /etc/issue с stdout, а распечатывать любые другие диагностические (например, сообщения об ошибках)?

Либо с помощью ssh -q либо с LogLevel quiet в ~/.ssh/config подавляет печать /etc/issue , но также отключает сообщения об ошибках. Я также попытался touch к ~/.hushlogin - это останавливает печать /etc/motd , но не влияет на /etc/issue .

Наиболее очевидное решение - просто удалить файл /etc/issue , но политика компании предписывает наличие файла с ужасными предупреждениями о несанкционированном доступе. Это не подлежит обсуждению. К сожалению, у меня есть несколько сценариев, которые запускаются на нескольких хостах через ssh, и файлы журналов а) очень большие и б) полные легальные. Поскольку многие вещи выполняются без присмотра, я не хочу потерять распечатанные сообщения об ошибках.

Answer 1

Да Добавьте файл ~/.ssh/config содержащий:

LogLevel ERROR

OpenSSH отображает содержимое /etc/issue с удаленного сервера. Этот параметр отключает этот дисплей. Очень полезно, когда компания Git repo удаленно выдает раздражающее предупреждение о безопасности.

Страница ssh config говорит:

LogLevel

Дает уровень многословия, который используется при регистрации сообщений от ssh(1). Возможные значения: QUIET , FATAL , ERROR , INFO , VERBOSE , DEBUG , DEBUG1 , DEBUG2 и DEBUG3 . По умолчанию INFO DEBUG и DEBUG1 эквивалентны. DEBUG2 и DEBUG3 каждый указывают более высокие уровни подробного вывода.

---

Дополнительный трюк Добавьте также в ваш ~/.ssh/config

Host *
     StrictHostKeyChecking no

Это предотвращает другое раздражающее сообщение. При подключении к новому хосту следующий секретный вопрос блокирует текущее соединение. Вышеприведенный трюк всегда предполагает yes . Тем не менее на практике вы всегда отвечаете yes , не так ли?

The authenticity of host 'newhostname (11.222.33.44)' can't be established.
RSA key fingerprint is aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00.
Are you sure you want to continue connecting (yes/no)?

Answer 2

Ни мой локальный хост OS X, ни мой сервер Ubuntu не печатают /etc/issue когда я ssh в (ни с оболочкой, ни с помощью удаленной команды), поэтому я не могу воспроизвести вашу проблему. Я попробую это по памяти.

Если вы не против создания двух соединений, вы можете сделать это:

num_lines="$(ssh yourhost 'cat /etc/issue' | wc -l)";
ssh yourhost 'your real command here' | tail +$(($num_lines / 2 + 1));

Первая команда ssh приведет к тому, что /etc/issue будет напечатан дважды (один раз системой, один раз cat), поэтому число строк будет в два раза больше, чем в /etc/issue . Вывод второй команды будет отображать только вывод из этого числа строк плюс одна.

Answer 3

Если ваш журнал будет содержать несколько сессий, добавленных в один файл, вы можете сделать так, чтобы ваш скрипт делал что-то вроде echo START LOGGING перед выполнением каких-либо других команд, а затем echo END LOGGING перед отключением, а затем используйте простой скрипт оболочки (используя sed или awk) зачистить все содержимое файла между END и START (т. е. шаблон перед каждым входом в систему).

РЕДАКТИРОВАТЬ:

Теперь я вижу, что вы не ведете журнал, а вместо этого ищете сообщения в окне - я рекомендую создавать журналы и сканировать журналы вместо того, чтобы полагаться только на вывод окна терминала - это гораздо более гибко и позволяет возвращаться к ошибкам предыдущих сессий если нужно.

Answer 4

Нет.

Когда хост отправляет обратно строки текста, как клиент SSH может узнать, какие строки были получены из /etc /issue хоста, а какие являются более интересными сообщениями? Не может

Answer 5

Вы можете установить это из командной строки с помощью:

ssh -o loglevel=ERROR

Если вы используете rsync (как это было для меня при поиске этой проблемы в Google), вы можете сделать это, указав командную строку ssh-соединения для rsync следующим образом:

rsync -e 'ssh -o loglevel=ERROR'