PspoClasses/080730/02SshBasics

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.

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

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

Попробуем совершить ssh. Обратите внимание, во что мы упёрлись. В ту же самую картинку, что и с ssl-сертификатами. В отличие от сертификатов, взаимного подписывания ключей тут нету, только fingerprint. Для узнавания отпечатка на сервере можно сказать ssh-keygen -l -f <открытый ключ>. Мы занялись тем, что надо, вобщем-то, делать --- передали информацию о ключе по другому каналу --- произнести вслух (клиент и сервер в нашем случае находились в одной комнате). Вобщем-то, даже позвонить и сверить отпечаток ключа по телефону будет вполне достаточной гарантией безопасности соединения именно к тому хосту, к которому планировалось. К сожалению, практика показывает, что никто эти ключи не сравнивает, люди просто давят yes. Обратите внимание, что просто y недостаточно.

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

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

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

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

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

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

Таким способом легко передавать файлы (вариантов много, самый простой вариант ssh cat file > file)

ssh 10.30.5.197 'ls -l todolist.txt'

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

ssh 10.30.5.196 'cat todolist.txt' > todolist.local

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

Вообще, для копирования есть scp, secure copy, она занимается передачей файлов туда/сюда:

Обратите внимание, что команда scp рабтает как cp, если не нахдит в паараметрах удалённой машины.

scp todo.local saj@10.30.5.197:

Также обратите внимание, что можно логиниться под другими пользователями.

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

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

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex