SSH-сервер: вопросы безопасности
Думаю, не стоит объяснять для чего обычно организуется SSH-сервер? Рассмотрим его установку и организацию безопасной работы с ним.
Для установки и клиента и сервера SSH следует использовать пакет OpenSSH. Хотя на сегодняшний день и существует целая масса различных программ для организации сервера и для работы в качестве клиента, именно OpenSSH позволяет организовать максимально безопасный и функциональный сервер.
Установить довольно просто, так как это популярный пакет, который присутствует в большинстве дистрибутивов, достаточно только воспользоваться пакетным менеджером:
$yaourt -S openssh
Настройки заданные по умолчанию вполне функциональны и безопасны. Теперь нам осталось немного настроить сам сервер, чтобы обеспечить максимальную его безопасность и запустить его…
Для настройки сервера изменяем файл /etc/ssh/sshd_config
Во-первых, запрещаем вход на сервер пользователю root и запрещаем использовать пустые пароли. Для этого снимаем комментарии со строк:
PasswordAuthentication yes PermitEmptyPasswords no PermitRootLogin no
Тем самым запрещаем вход пользователю, имя которого заранее известно и работа в системе которого может привести к печальным последствиям. Если необходимо будет удаленно изменять настройки системы – существует sudo, предоставляющая необходимый функционал, защищенный паролем пользователя. В том случае его определяли методом перебора, и вдруг каким то образом он был определен, злоумышленник получит доступ к системе, но не сможет воспользоваться sudo. Если вдруг по каким то причинам у вашего пользователя не окажется пароля, то зайти удаленно в систему вы не сможете. Так как доступ пользователю root запрещен, злоумышленнику подбора пароля придется еще подбирать имя пользователя, а это уже далеко не тривиальная задача…
Для того, чтобы свести брутфорс к бесполезной трате времени, можно использовать пакет fail2ban. После небольшой настройки fail2ban отслеживает логи, и при наличии нескольких попыток соединения с одного и того же айпи-адреса, заносит его в список блокируемых. Другой способ – это добавление в iptables следующих правил:
iptables -A INPUT -p tcp --syn --dport ssh -m recent --name ssh --set iptables -A INPUT -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 30 --hitcount 2 -j DROP
Эти правила позволяют отбрасывать соединения с ip-адресов, с которых происходит более двух попыток соединения за 30 секунд. Перебор вариантов становиться просто бессмысленным.
Но не будем останавливаться на достигнутом и пойдем дальше, зададим аутентификацию по закрытому ключу. При этом запретив аутентификацию по паролю:
PasswordAuthentication no
Но предварительно необходимо создать ключи, если это еще не было сделано и передать их на сервер:
$ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa $ssh-copy-id -i $HOME/.ssh/id_rsa.pub user@machine
При создании ключей будет произведен запрос пароля, который будет использоваться при обращении к закрытому ключу. Его следует обязательно задавать! Во избежание использования вашего закрытого ключа в случае его кражи.
При передаче ключа на сервер необходимо будет ввести пароль пользователя на сервере. Обращаю внимание на то, что передается именно публичный ключ! После чего запрещаем вход на сервер по паролю. Единственное неудобство данного способа заключается в том, что для аутентификации требуется наличие закрытого ключа.
Закрытый ключ с безпарольной аутентификацией самый надежный и безопасный способ. но он не всегда удобен. Вполне достаточно настроить сервер на запрет входа суперпользователю, запретить пустые пароли и ограничить количество соединений с одного ip-адреса.
После чего можно уже не опасаться взлома вашего ssh-сервера!
Теперь нам осталось только запустить сервер и настроить его запуск при старте компьютера. Для этого даем команду:
$sudo /etc/rc.d/sshd start
И вносим изменения в файл /etc/rc.conf, добавив sshd в список DAEMONS:
DAEMONS=(syslog-ng crond hal iptables network !netfs hddtemp sensors nscd alsa sshd mpd mpdscribble xinetd slim uptimed)
Собственно все! Приятной работы!
Похожие записи:
- pdnsd – локальный кэширующий dns сервер
- SSH авторизация без пароля
- archlinux & xorg 1.5
- Gentoo: dhcp & dns
- Ответы на вопросы…
Метки: Linux, ssh, Безопасность

Про ListenAddress – LOL
неужели ошибся??
dsa ключи уж предпочтительней будут, если мы подняли тему безопасности
А еще можно открыть доступ только для одного юзера и назвать его типа «gikhfrth».
И в sshd_config добавить
«AllowUsers gikhfrth»
Все остальные, вместе с рутом будут отметаться
по своей сути, на сегодняшний день, что dsa, что rsa, дело только во времени, которое нужно будет заполучить.
что то ломается быстрее, что то медленнее, однако оба типа ключа безопасны…
даже если скрываетесь от государства, любой из этих ключей даст необходимое время для передачи актуальной информации, перехват которой будет в любом случае произведен уже после того, как информация устарела.
хороший совет! спасибо!
Что делать если при попытке соединиться появляется ошибка
Agent admitted failure to sign using the key
И авторизация проходит только по паролю, но не по ключу.
Проверьте, включено ли в ssh авторизация по ключу. По симптомам она запрещена.
Port 22
Port 22222
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
AllowUsers user@*
пока ошибок не вижу… а как передавали на сервер открытый ключ??
Как Вы описали. Визуальный контроль ключа на сервере и ключа на клиенте показал совпадение обоих.
Очень странно, вроде все ок, но не работает… Даже и не знаю, чем помочь тогда. Попробуйте переконфигурировать с нуля, только настройки меняйте по чуть-чуть, контролируя, работают ли нужные функции на данном этапе.
Это какая то мистика. Захожу сегодня на сервер, где настраивал аунтификацию по ключам, и…он у меня запрашивает пароль ключа. И подключается по ключу. При этом я ничего со вчерашнего дня не менял. Разве что выключал свою рабочую станцию которая под debian squeeze на ночь.
Без мистики никуда… =)