Забавы с OpenSSH

Anton Karpov

Хакер, номер #073, стр. 073-104-1

(toxa@real.xakep.ru)

Приемы эффективной работы

Давно канули в лету времена, когда для удаленного администрирования использовались telnet, rsh, rlogin. Secure Shell (ssh) - сегодняшний стандарт де-факто для удаленного управления *nix-машинами. OpenSSH - свободная реализация протокола ssh (версий 1 и 2) от разработчиков OpenBSD - имеет подавляющее преимущество над аналогичными реализациями и присутствует практически в каждом дистрибутиве Linux или BSD. Но, как это часто бывает, мало кто использует OpenSSH хотя бы на половину его возможностей. Прочитав эту статью, ты сможешь моментально управляться со многими задачами, на которые раньше зря тратил время.

Конфигурирование

Стандартно конфиги как клиентской, так и серверной частей располагаются в каталоге /etc/ssh. Серверные ключи, секретный и публичный, лежат там же. Я не буду рассматривать каждую строчку конфигов, а лишь приведу те минимальные изменения, которые желательно произвести в файле настроек демона /etc/ssh/sshd_config.

Первым делом нужно отказаться от совместимости с протоколом SSHv1. По умолчанию сервер лоялен к старым клиентам, которые не могут соединяться по протоколу SSHv2, и поддерживает обе версии протокола:

#Protocol 2,1

Эта строчка означает, что на этапе соединения сервер предлагает клиентам второй протокол, но если они откажутся, то позволительно использовать первый. В SSHv1 используется более слабый алгоритм генерации сессионного ключа, уязвимый к криптоатакам, и все современные клиенты умеют использовать SSHv2. Поэтому раскомментируем строчку и правим:

Protocol 2

По умолчанию (в некоторых дистрибутивах или если ты собрал OpenSSH из исходников) доступ суперпользователю по ssh разрешен:

#PermitRootLogin yes

Не стоит еще раз напоминать, что под рутом лучше не входить даже локально, а удаленно - тем более. Привыкай пользоваться утилитой sudo. А конфиг исправь:

PermitRootLogin no

Можно также ограничить доступ определенными хостами (host-based auth средствами sshd или используя банальный пакетный фильтр), но это неудобно. Ssh тем и хорош, что можно удаленно получить безопасный доступ с любой машины. Однако ограничить право логина по ssh отдельным пользователям или группам вполне разумно:

AllowUsers toxa

AllowGroups users

Наконец, если доступ планируется предоставить широкой группе пользователей, то можно приветствовать их специальным приглашением:

Banner /etc/ssh/sshd_banner

# echo "Access RESTRICTED. All you actions will be LOGGED" > /etc/ssh/sshd_banner

Остальные настройки пока можно оставить по умолчанию. После изменения конфига следует перезапустить sshd, предварительно проверив правильность внесенных изменений запуском /usr/sbin/sshd –t (обрати внимание: в данном случае необходимо указывать абсолютный путь к демону sshd). Ведь если ты совершишь ошибку во время правки конфига с удаленного компьютера, то можешь запросто потерять доступ к машине.

Золотые ключики

По умолчанию sshd аутентифицирует пользователей по системной базе паролей. То есть ты просто вводишь тот пароль, который используется при локальном доступе с физической консоли. Это самый распространенный метод, однако он не лишен недостатков. Представь, что помимо sshd у тебя в системе крутится pop3-сервер, аутентифицирующий пользователей все по той же базе паролей. Твой пароль можно отснифать во время pop3-сессии, а затем беспрепятственно войти с ним в систему по ssh.