Протокол удаленного доступа SSH. Практика
- Подробности
- Опубликовано 26.02.2016 02:52
SSH (Secure Shell) - это сетевой протокол удаленного доступа, использующий шифрование и сжатие для передаваемых данных. Проще говоря - это весьма полезный и мощный инструмент, позволяющий аутентифицироваться в системе и полноценно работать от имени локального пользователя, находясь за много километров от работающей машины. Также, в отличие от telnet и rsh - SSH шифрует весь трафик, так что вся переданная информация остается конфиденциальной.
Итак, ssh у нас уже установлен и ssh-daemon добавлен в автозагрузку при старте системы. Управлять им можно по команде:
service ssh stop|start|restart
В Ubuntu, или:
/etc/init.d/ssh {start|stop|reload|force-reload|restart|status}
В Debian, или:
systemctl start|stop|restart sshd.service
В ArchLinux (после каждой правки конфига нужно делать рестарт). В комплект входит клиент и сервер.
Опробуем в деле! Для начала создайте папку ~/.ssh
mkdir ~/.ssh
Сгенерируйте ключи для данного пользователя сервера командой:
ssh-keygen (от имени обычного пользователя).
При генерации, вы можете задать парольную фразу для ключа (желательно задать, и длинную - тогда даже заполучив ключ но не зная пароль от ключа, злоумышленник не сможет залогинится), а можете пропустить, просто нажав "Enter" - в таком случае, пароль никогда не спросится. В папке ~/.ssh появились те самые публичный и закрытый ключ.
Найдите ещё одну машину (даже смартфон подойдет - на Android есть несколько замечательных SSH-клиентов, вроде ConnectBot или JuiceSSH), установите на ней ssh и подключитесь к серверу командой:
ssh user@server [user - имя вашего пользователя на сервере|server - ip сервера]
Если всё сделано правильно, будет запрошен пароль пользователя, и после ввода вы окажетесь в своей системе с видом из командной строки.
Для Windows, к слову, также есть сервера и клиенты ssh.
Насладившись результатом трудов своих, приступим к ещё более скучной части - настройке клиента/сервера.
Конфиг клиентской части лежит в /etc/ssh/ssh_config, а серверной - /etc/ssh/sshd_config. Наиболее полным руководством по настройке является, пожалуй, страница в man - man ssh и man sshd_config, так что рекомендуем прочититать её. А в данной статье рассмотрим наиболее необходимые вещи.
Настройка
Стандартный порт ssh - 22. Его можно сменить на любой нестандартный (усложняя возможный взлом благодаря безопасности через неясность, или же для привлечения внимания потенциальных взломщиков:) - для этого расскомментируйте строчку:
#Port 22
И добавьте любой желаемый до 65535 (убедившись, что порт не конфликтует с другими сервисами командой #netstat -tupln | grep LISTEN).
Теперь при подключении к серверу, клиенту потребуется писать с ключом:
ssh -p [порт] [user]:[ip]
По умолчанию доступ от имени root разрешен. Крайне желательно ограничить его (и вместо этого правильно разграничить права локального пользователя с помощью sudo). Для этого найдите строчку "PermitRootLogin" и смените значение на "no". Можно также сменить на "without-password" - в таком случае, логин под рутом будет разрешен только из под машин с доверенным ключом.
Можно отключить аутентификацию по паролю и работать только с ключами - найдите строчку: "PasswordAuthentication" и смените значение на "no". Зачем? Если кто-то очень захочет получить доступ к вашей системе, то он сможет либо перебрать пароль при попытках авторизации, либо прослушать и расшифровать ваше соединение. Если отключить аутентификацию по паролю и добавить в ~/.ssh/authorized_keys на сервере публичный ключ своего, например, рабочего ноутбука, то, как мы помним, нас пустит на сервер сразу. Но как быть, если вы работаете на чужой машине и срочно нужно получить доступ на ssh-сервер, а он нас ожидаемо не пускает? Тогда можно не отключать парольную аутентификацию, а воспользоваться утилитой fail2ban. Просто установите её из вашего репозитория, после чего она применит настройки по умолчанию и, как минимум, защитит ваш ssh-канал от взлома методом перебора. Подробнее о fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.
На тот случай, если на вашем сервере хранятся ключи запуска ядерных ракет, то можно сделать как-то так:
PermitRootLogin no - запрещен логин под рутом.
PasswordAuthentication no - вход без пароля
Сгенерируем на удаленной машине длинный ключ (-t тип_шифрования, -b битовая длина):
ssh-keygen -t rsa -b 4096
С не менее сложной парольной фразой (восстановить забытый пароль, к слову, нельзя. Можно сменить его командой "ssh-keygen -p", но с вас в любом случае спросят старый). Перенесем публичный ключ удаленной локальной машины в ~/.ssh/authorized_keys сервера, и вуаля - теперь доступ можно получить с единственной машины, с помощью парольной фразы зыкрытого ключа. SSH позволяет настроить множество конфигураций безопасности и имеет для этого множество специфичных настроек - о них читайте в man.
Этим же целям служат два параметра sshd_config:
LoginGraceTime - задает время, по истечении которого будет разорвано соединение, если не произойдет аутентификация.
MaxAuthTries - задает количество неверных попыток ввода логина, по достижении которого соединение будет разорвано.
MaxSessions - количество одновременных сессий (если сервер - ваш домашний компьютер, к которому вы собираетесь подключаться из универа или с работы, то разумно будет ограничить число сессий до одной - отклоненный логин, в таком случае, станет поводом для повышения паранойи, генерации новых ключей и смены пароля). Впрочем, если вы внимательны, то могли заметить, что при каждом логине на сервер высвечивается строчка "Last Login". Помимо неё, можно добавить собственное приветственное сообщение - найдите строчку 'Banner' и вместо none задайте путь к файлу с текстом, который будет прочитан и выведен при логине.
Помимо прочего, можно разрешить вход в систему только определенным пользователям, или разрешить всем, помимо определенных пользователей:
AllowUsers user1 - разрешить вход только user1.
DenyUsers user1 - разрешить всем, кроме user1.
И аналогичные параметры для доступа определенных групп - AllowGroups и DenyGroups.
Также по SSH можно передавать сеанс X11. Для этого найдите строчку "ForwardX11" и измените значение на 'yes'.
Аналогичную строку найдите в конфиге клиента - /etc/ssh/ssh_config, и также смените на 'yes'.
Теперь присоединяться к серверу по ssh нужно с аргументом -X :
ssh -X user@server>
Можно сразу запуcтить приложение при коннекте:
ssh -X user@server 'приложение'
Вот так выглядит работающий GIMP в ssh-сессии:
Или mplayer:
Или можно получить вывод с веб-камеры ноутбука ничего не подозревающего пользователя:)
Вычисления производятся непосредственно на сервере, а вывод передается на клиентскую машину (то есть, даже если на самом сервере не стоят X11, графические приложения можно отрисовывать на вашей удаленной машине). Работает такая схема довольно медленно (не забываем, что весь трафик динамически шифруется) - но функция эта весьма полезна.
По SSH-сессии можно также копировать файлы - для этого есть простенькая утилита 'scp'. Передавать файлы можно прямо в сессии как с сервера на клиент:
scp user@server:/путь/к/файлу/на/сервере /куда/сохранить/на/локальной/машине
Так и с клиента на сервер:
scp путь/к/файлу/клиента user@server:/путь/на/сервере
Это достаточно удобно, если нужно скопировать текстовик или фотографию, но как быть, когда предстоит работа с многими файлами? Для этого существует удобнейшая вещь - sshfs (доступна для установки в репозиториях большинства *nix-систем).
Просто задайте путь аналогично scp:
sshfs user@server:/home/user /mnt/
И папка /home/user сервера появится в точке монтирования /mnt локальной машины!
Отмонтирование производится через umount.
И, напоследок, расскажем об одной малоизвестной фиче. Если создать файл /.ssh/config и заполнить его подобным образом:
Host [имя]
Hostname [ip сервера]
User [имя пользователя сервера]
...
...
желаемые опции
вроде
ForwardX11 yes
Port 30000
То можно будем логиниться по:
ssh [имя]
Вместо:
ssh -X -p 30000 user@server
И все опции подхватятся автоматически. Таким образом, при частой аутентификации на определенном сервере, вы упростите этот процесс к делу пары мгновений.
Что ж, мы рассмотрели всё (и даже больше) что нужно знать об SSH, для его бытового использования - научились пользоваться аутентификацией по ключу, защитили сервер от взлома перебором и в целом, наложили заплатки на большинство потенциальных дыр. На самом деле, SSH может ещё много разных штук - например, туннелирование и проброс портов через ssh-сессию, но вряд ли вы, как самый обычный пользователь, когда-либо этим воспользуетесь. Дополнительные ресурсы по теме:
http://www.openssh.com/ - официальная документация
http://putty.org.ru/articles.html - множество статей по настройке, с упором на настройку под Windows.
https://wiki.archlinux.org/index.php/Secure_Shell_(Русский)