SSH: основы

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

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

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

Существовало когда-то служба telnet, ещё до этого был rsh, которые были предназначены для того же самого. rsh был совсем простой штукой, которая просто прокидывала терминал. telnet был слегка пофичастей, но ни то, ни другое ничего не шифровало, однако сейчас в некоторых ОС типа FreeBSD шифруется траффик телнетный, но если нет ассиметричной схемы, то мы не можем гарантировать аутентичность. 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 e2:4d:55:26:db:ae:78:3c:dc:e1:56:e6:9b:47:47:7d /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.

[saj@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.

[saj@class305 ~]$ ls .ssh
agent  known_hosts

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

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

[saj@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/saj/.ssh/known_hosts to get rid of this message.
ssh: Offending key in /home/saj/.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).

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

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

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

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

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

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

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


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

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

18

1

1

1

1

MaximByshevskiKonopko, ОльгаТочилкина, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex