Вопросы Теги

Печатаемые символы неASCII в sshd баннере

Существуют некоторые функции для перемещения и копирования файлов и после них к целевому каталогу, происходящему из потока на Дуге платы Linux:

# Follow copied and moved files to destination directory
cpf() { cp "$@" && goto "$_"; }
mvf() { mv "$@" && goto "$_"; }
goto() { [ -d "$1" ] && cd "$1" || cd "$(dirname "$1")"; }

Вы можете затем {перемещение, копия} и следовать за файлом путем издания:

mvf file /dest/dir/

7
13.04.2017, 15:36
2 ответа

Упоминание № 1 - проект LinuxFromScratch

Одно место, что это упоминается, находится в Linux, С нуля проекта. Я нашел эту страницу названной:/etc/issue (Настраивающий Ваш вход в систему).

выборка

/etc/issue файл является файлом простого текста, который также примет определенные Escape-последовательности (см. ниже) для вставки информации о системе. Существует также файл issue.net, который может использоваться при вхождении в систему удаленно. ssh однако, будет только использовать его, если Вы установите опцию в конфигурационном файле и также не интерпретируете escape-последовательности, показанные ниже.

Упоминание № 2 - сообщение Форума SecurityFocus

Поскольку дополнительное доказательство, что это не возможно, существует эта выборка из названного сообщения форума: Ре: ssh и баннеры 18 августа 2009 13:20, который обсуждает функцию, которая реализует печать баннера в OpenSSH.

выборка

После выполнения еще некоторого рытья я нашел, что существует функция в ssh источнике (конкретно sshconnect2.c) названа "input_userauth_banner", который отображает баннер с сервера. В текст баннера теперь проникают другая функция, вызванная "strnvis", который кодирует непечатаемые символы ASCII печатаемым текстом, т.е.: восьмеричные коды. Поэтому ansi escape-последовательность отображена как "\033 [". Документация для strnvis не упоминает проблем безопасности, только "неожиданное поведение", которое могло быть связано с непечатаемыми символами.

Упоминание № 3 - информация о версии OpenSSH + RFC

Наконец я поощряю Вас просматривать информацию о версии для OpenSSH. Они здесь, а также RFC, которые управляют SSH v1 и v2 спецификациями.

Этот RFC покрывает часть поведения Banner функция. Этот раздел "5.4. Сообщение баннера" касается деталей того, почему это не позволяется. Этот абзац - то, где, говорит, что это явно запрещено.

выборка

Если строка 'сообщения' отображена, фильтрация управляющего символа, обсудил в [SSH-ДУГЕ], ДОЛЖЕН использоваться для предотвращения нападений путем отправки терминальных управляющих символов.

Дополнительные ссылки (на @hildred)

9
27.01.2020, 20:16
  • 1
    Это точно, что я в настоящее время использую. /etc/issue.net общее название для Banner, и, как упомянуто в вопросе непечатаемыми символами ASCII, кажется, оставляют sshd здесь. Извините, мой вопрос, возможно, был немного неясен. –  FireFly 13.01.2014, 00:09
  • 2
    @FireFly - Я думаю, что суть того комментария - то, что средство баннера ssh не позволит Вам включать escape-последовательности дизайном. Это - то, что Вы хотите подтверждение, правильно? –  slm♦ 13.01.2014, 00:18
  • 3
    Да, я предполагаю. Я приму это в настоящее время, но я, конечно, надеялся на обходное решение вместо этого. :P но увы, кажется, что это не возможно. –  FireFly 13.01.2014, 00:23
  • 4
    @FireFly - Я не думаю, что Вы собираетесь получить то, что Вы хотите. Я обычно делаю это в .bashrc или motd впоследствии, если я хочу символы управления + цвета. Посмотрите мои обновления. Я добавил все подробности, которые показывают, что это не возможно. –  slm♦ 13.01.2014, 00:56
  • 5
    @FireFly - Я не забываю изучать это несколько лет назад и врезаться в стену также и задаваться вопросом, почему, я просто отложил ее, но теперь мы знаем, что это из соображений безопасности. –  slm♦ 13.01.2014, 01:12

У клиента openssh есть ошибка в фильтре небезопасных символов, который вместо фильтрации управляющих символов отфильтровывает все, кроме пригодных для печати ascii (спецификация требует печатного utf8) патч для клиента исправит это.

2
27.01.2020, 20:16

Теги

Похожие вопросы