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, отпечаток ключа станет отличным от сохранённого, это значит, что либо мы их поменяли сами (если переустановили систему на сервере и забыли перенести ключи или сгенерировали их заново), или соединение слушается кем-то третьим, который подменяет содинение до сервера.

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

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

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

Вобще говоря, взм. запускать с той стороны прграммы для юних-подобных систем очень правильная штука. Далее мы поговорим про уд. запуск граф. программ, но даже сейчас консльные приложения да. Линукс в принципе упр. с консли, собенно, если доступны 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.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

11

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex