Держим SSH в безопасности
Для повышения защищенности можно кое-что изменить в конфигурационном файле сервера (/etc/ssh/sshd_config). Для начала запретим вход в систему под пользователем root, установив параметр
Если в удаленной сессии нужно запускать программы от имени суперпользователя- root, можно войти на удаленный компьютер как обычный пользователь, а потом получить права администратора с помощью команды su или sudo. Чтобы налетчик смог это повторить, ему нужно знать имя пользователя, его пароль и пароль root – в три раза больше информации, чем было бы нужно для непосредственного доступа от имени root.
Для ограничения доступа используются и другие директивы: DenyUsers, AllowUsers, DenyGroups и AllowGroups. Их назначение понятно из названия. Каждая из них принимает разделенный пробелами список имен пользователей или групп (не числовых идентификаторов), доступ для которых нужно разрешить или запретить. Директивы обрабатываются в приведенном порядке, до первого совпадения. Если ни одна директива не задана, попытаться войти может любой пользователь. Имена пользователей могут задаваться как просто имена или в виде user@host, тогда проверяются и имя пользователя, и хост. Учтите, имя пользователя сравнивается с именем пользователя, под которым вы входите в систему, а хост сравнивается с именем удаленного компьютера, с которого вы пытаетесь зарегистрироваться. Это позволяет разрешить доступ только с определенных компьютеров: скажем, заходить на домашний ПК с работы. Можно применять шаблоны: например, директива
AllowUsers jim@*.mywork.ru
позволит входить в систему под пользователем jim с любого компьютера в сети на работе. Эти директивы разрешают или запрещают только попытки входа, без пароля вам все равно не обойтись…
Скорая помощь
Храните копии ваших закрытых ключей в надежном месте подальше от компьютера. В противном случае при их утрате или повреждении вы, возможно, не сможете зайти в систему.
Если только вы не задали вход в систему без пароля! Да почему же, после стольких лекций по безопасности? Потому что на самом деле это безопаснее. Сложность пароля ограничена – ведь вы должны его помнить, а файл ключа может быть больше и иметь в миллиарды раз больше перестановок, чем пароль. Для начала создайте пару файлов ключей с помощью команды
У вас запросят парольную фразу. Она может быть пустой (тогда для входа достаточно просто иметь закрытый ключ), но для повышения безопасности можно задать и ее. Беспарольные ключи больше подходят для автоматизированных систем, но они довольно удобны и в остальных случаях. Теперь в каталоге ~/.ssh есть два файла: id_rsa (или id_dsa, если вы указали ssh-keygen создать ключ DSA) и id_rsa_pub. Первый файл – это закрытый ключ, и его нужно хранить в безопасном месте, а второй – открытый, его нужно добавить в файл ~/.ssh/authorized_keys на удаленном компьютере. Файл можно скопировать на флэшку, вставить ее в удаленный компьютер и добавить с помощью команды
cat id_rsa.pub >>~/.ssh/authorized_keys
или, если у вас еще включен удаленный вход по паролю, передайте его по сети командой
cat ~/.ssh.id_rsa.pub | ssh remote.computer tee -a ~/.ssh/authorized_keys
Теперь разрешите аутентификацию по ключу, установив параметр
в файле /etc/ssh/ssh_config на удаленном компьютере, и перезапустите сервис SSH.
Как показано выше, вход в систему с паролем можно отключить совсем, требуя обязательного использования ключа (возможно, в сочетании с парольной фразой) – добавкой в файл sshd_config следующих строк:
PasswordAuthentication no
Обычно ключ хранится в каталоге ~/.ssh, и это хорошо, если вы подключаетесь со своего компьютера. Чтобы подключаться откуда угодно, закрытый ключ можно записать на флэшку и указать SSH, где его искать, опцией -i.
ssh -i /media/usbstick/id_rsa
В этом случае ключ нужно защитить с помощью парольной фразы, иначе потеря USB- брелка будет равносильна потере ключа от дома. Если вы хотите использовать парольную фразу только когда заходите извне, и не напрягаться с ней при работе на собственном компьютере, то для флэшки нужно создать собственную пару ключей.
Весь этот разговор о перезапуске службы может вызвать у вас вопрос: «А что будет, если я испорчу конфигурационный файл на удаленном компьютере и перезапущу службу?». Ну, плохая новость – вы не сможете войти до тех пор, пока не поправите его. А хорошая новость – существующие соединения не затрагиваются перезапуском. Так что, изменив конфигурационный файл и перезапустив sshd, не закрывайте текущую сессию и попробуйте открыть новую с другого терминала. Если сделать это не получится, у вас остается открытая сессия, в которой можно исправить ошибки.
