SSH: основы

SSH (Secure Shell) --- это возможность получить терминальный доступ к удалённой машине, при этом с точки зрения системы просто создаётся ещё один терминал. Для нас он будет выглядеть так же, как обычный терминал и обладать всеми его свойствами: обработка сигналов, превращение спецсимволов и так далее. На удалённой машине, к которой осуществляется подключение, запущен SSH-демон, который доступен по сети, и к которому можно подключиться при помощи специального клиента. Долгое время эта разработка была отчасти несвободной, потому что в ней использовались патентованные алгоритмы шифрования, однако в 2000-х годах основные патенты открыли, и с тех пор семейство OpenSSH активно развивается.

Как и любая клиент-серверная архитектура, SSH состоит из двух частей: сервер и клиент. Как работает SSH? Точно так же, как SSL, за исключением того, что ключ, генерируемый SSH, --- только ключ, без дополнительных полей. Используется ассиметричное шифрование, чтобы обеспечить идентификацию связывающихся субъектов и для шифрования пароля. Однако шифрование основного потока данных симметричное, потому что ассиметричное шифрование ключами того размера, которые используются в SSH было бы слишком медленным.

Краткая история удалённого терминального доступа

Раньше для реализации доступа к удалённой машине использовались службы telnet и rsh. Служба rsh была достаточно просто организована: она просто эмулировала терминал удалённой машины. Программа telnet была более сложной, однако также не шифровала передаваемые данные. Сейчас в некоторых ОС типа FreeBSD шифруется траффик telnet'a, но, если нет ассиметричной схемы, нельзя гарантировать аутентичность. В целом, службу telnet не рекомендуется использовать. Клиент telnet обычно используют вместо netcat для проверки работоспособности сервисов на заданных портах.

Использование, ассиметричные ключи

Для подключения к SSH-демону на удалённой машине необходимо, чтобы у него были сгенерированы ключи. Их генерирует sshd при первом запуске ( запуск можно осуществить, выполнив команду service sshd start). Это же он сделает при старте системы, если выполнить команду chkconfig sshd on. Всего генерируется три пары ключей (закрытый, открытый) на разные случаи жизни: ключи протокола ssh1, который уже упразднён, и два ключа протокола ssh2: более лёгкий rsa и тяжёлый dsa.

[root@localhost ~]# service sshd start
Generating SSH2 RSA host key: DONE
Generating SSH2 DSA host key: DONE
Generating SSH1 RSA host key: DONE
Starting sshd service: DONE

Посмотрим содержимое каталога /etc/openssh. Ничего сложного тут нет. .pub-файлы --- открытые ключи, остальные --- закрытые, есть каталог authorized_keys, и два конфигурационных файла --- от сервера и клиента. Внутрь мы лезть не будем, изучим опции.

Использование, соединение, проверка ключей

Попробуем совершить ssh. Обратите внимание, во что мы упёрлись. В ту же самую картинку, что и с ssl-сертификатами. В отличие от сертификатов, взаимного подписывания ключей тут нету, только возможность проверки fingerprint'а. Для узнавания отпечатка на сервере можно сказать ssh-keygen -l -f <открытый ключ>.

[root@localhost openssh]# ssh-keygen -l -f /etc/openssh/ssh_host_rsa_key.pub 
2048 2a:33:88:23:87:5c:26:c4:f3:66:76:fc:0a:b1:fe:89 /etc/openssh/ssh_host_rsa_key.pub

Мы занялись тем, что надо, вобщем-то, делать --- передали информацию о ключе по другому каналу --- произнесли вслух (клиент и сервер в нашем случае находились в одной комнате). Даже позвонить и сверить отпечаток ключа по телефону будет вполне достаточной гарантией безопасности соединения именно к тому хосту, к которому планировалось. К сожалению, практика показывает, что никто эти ключи не сравнивает, люди просто давят yes. Обратите внимание, что просто y недостаточно.

[user@demo ~]$ ssh 10.30.5.197
The authenticity of host '10.30.5.197 (10.30.5.197)' can't be established.
RSA key fingerprint is 2a:33:88:23:87:5c:26:c4:f3:66:76:fc:0a:b1:fe:89.
Are you sure you want to continue connecting (yes/no)?

Убедимся, что это другой хост: /sbin/ip a.

[user@localhost ~]$ /sbin/ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:11:2f:1d:9d:0d brd ff:ff:ff:ff:ff:ff
    inet 10.30.5.197/24 brd 10.30.5.255 scope global eth0

Посмотрим, что случилось с каталогом .ssh.

[user@demo ~]$ ls .ssh
agent  known_hosts

На локальной машине есть каталог ~/.ssh; обратите внимание, что второй раз нас уже не спрашивали о ключе, поскольку host key сохранился в .ssh/known_hosts. Если в какой-то момент при подключении к удалённому хосту, который прописан в known_hosts, отпечаток ключа станет отличным от сохранённого, это значит, что либо мы их поменяли сами (если переустановили систему на сервере и забыли перенести ключи или сгенерировали их заново), или соединение слушается кем-то третьим, который подменяет соединение до сервера.

Смоделируем ситуацию изменения ключа: перегенерируем ключи и попытаемся подключиться:

[user@localhost ~]$ ssh 10.30.5.197
ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ssh: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
ssh: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ssh: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ssh: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ssh: It is also possible that the RSA host key has just been changed.
ssh: The fingerprint for the RSA key sent by the remote host is
49:a9:8b:dd:68:6a:43:c1:d5:e5:af:e7:0f:6f:04:f3.
ssh: Please contact your system administrator.
ssh: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
ssh: Offending key in /home/user/.ssh/known_hosts:4
ssh: RSA host key for 10.30.5.197 has changed and you have requested strict checking.
ssh: Host key verification failed.

Эта надпись очень угрожающая, но обычно это бывает именно по первой причине.

sshd может сам просматривать содержимое passwd и осуществлять авторизацию, как это делает login. Там могут быть некие нюансы, но важно именно это: фактически, защита по ключу обеспечивает возможность безбоязненно вводить пароль с клавиатуры, потому что при передаче по сети он скрыт ассиметричным шифрованием. Хотя, разумеется, никто не гарантирует, что на машине, на которой набирается пароль, не стоит кейлоггер.

Использование, удалённый запуск программ, копирование файлов

В целом, возможность запускать с той стороны программы (при этом их вывод будет с этой стороны) для Unix-подобных систем очень правильная штука. Далее мы поговорим про удалённый запуск графических программ (при помощи перенаправления X), но даже консольные приложения позволяют совершать множество интересных вещей. Линукс, в принципе, полностью управляется с консоли (особенно, если доступны su/sudo).

Таким способом легко передавать файлы (вариантов много).

[user@demo ~]$ ssh 10.30.5.197 'ls -l todolist.txt'
todolist.txt
user@10.30.5.197's password: 

Что произошло? Мы осуществили соединения, при этом не заводится терминал, только перебрасываются байты.

[user@demo ~]$ ssh 10.30.5.197 'cat todolist.txt' > todolist.txt.local
user@10.30.5.197's password: 
[user@demo ~]$ ssh 10.30.5.197 'md5sum todolist.txt'
user@10.30.5.197's password: 
3c7ab21a21fe51d291833db681af4d5f  todolist.txt
[user@demo ~]$ md5sum todolist.txt.local 
3c7ab21a21fe51d291833db681af4d5f  todolist.txt.local

Обратите внимание, что весь ввод-вывод организуется даже не с помощью stderr, а напрямую с терминальным устройством. Это, во-первых, надёжнее, во-вторых, обеспечивает разделение stdout. Контрольные суммы удалённого и полученного файлов совпадают, то есть с достаточной степенью достоверности копирование произошло без ошибок. Это следствие того, что символы при передаче не преобразуются (как бы это могло происходить в случае преобразования между различными терминалами). Вывод команды cat вообще без модификаций передаётся на эту сторону.

Вообще, для копирования есть специальная утилита scp, secure copy, она занимается передачей файлов с локального компьютера на удалённый и обратно. Команда scp работает как cp, если не находит в параметрах адреса удалённой машины вида <имя пользователя>@<хост>:<путь на хосте>.

Со стороны sshd можно разрешить sftp (по умолчанию в ПСПО он выключен), который более удобен для копирования файлов. sftp --- это протокол на основе ssh, который с виду похож на ftp. На самом деле, sftp не имеет отношения к ftp и является совершенно другим протоколом прикладного уровня. Для защиты ftp ssl-ем, используется ftp/tls, не поддерживаемый повсеместно и потому редкий. Ещё есть sshfs (монтирование удалённой файловой системы через ssh).

Сведения о ресурсах

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex