SSH: основы

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

Как и любая клиент-серверная архитектура, она состоит из двух частей, сервер и клиент. Как он работает? В точности также, как ssl, за исключением того, что ключ, генерируемый ssh, только ключ, без дополнительных полей. Там используется ассиметричное шифрование, чтобы обеспечить идентификацию связывающихся субъектов и для шифрования пароля, того ключа, которым происходит шифрование. Поскольку каждое подключение... Существовало когда-то служба telnet, ещё до этого был rsh, которые были предназначены для того же самого. rsh был совсем простой штукой, которая просто прокидывала терминал. telnet, отличалась только в сторону увеличения сервиса, ни то, ни другое ничего не шифровало, однако сейчас в некоторых ос типа freebsd шифровала траффик телнетный, но если нет ассиметричной схемы, то мы не можем гарантировать идент. telnet-службу не реком. исп. никогда. telnet обычно исп. вместо netcat. Всё это заменили на secure shell. Вообще, считается, что машина без ssh неполноценная.

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

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

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

Убедимся, что эт другой хост: /sbin/ip a. Посмотрим, что случилось с каталогоим .ssh. На лок. машине есть каталог польз. .ssh, бр. внимание, что второй раз нас уже не спрашивали о ключе, поск. host ke сохранился в .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

0

1

1

1

1

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


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex