Руководства по ssh

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Управление ключами

Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа

(если на вопрос про расположение ответили по-умолчанию).
~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер

В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' (внимание на кавычки).

Ключ сервера

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Копирование файлов

Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.

scp path/myfile user@8.8.8.8:/full/path/to/new/location/


Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here


Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

Так тоже можно:

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash
sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

Удалённое исполнение кода

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/


Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command


Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk '{print $2}' |local_app


Это нас приводит следующей фиче:

Проброс stdin/out

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

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»

Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server "cd && tar -x"


Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

Алиасы

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

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Host ric
        Hostname ооо-рога-и-копыта.рф
        User Администратор
        ForwardX11 yes
        Compression yes
Host home
        Hostname myhome.dyndns.org
        User vasya
        PasswordAuthentication no

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

Опции по умолчанию

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host *
User root
Compression yes

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200


и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.

Socks-proxy

Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:

ssh -D 8080 user@server

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn
    Hostname desunote.ru
    User vasya
    Compression yes
    DynamicForward 127.1:8080
    Port 443

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача

: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8


Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.

Задача

. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.

Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8


Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача

: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8


Вложенные туннели

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2


Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Туннелирование

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации

Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.

Для начала о простом пробросе авторизации.

Повторю картинку:

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2


Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.

Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

.ssh/config:

Host raep
     HostName 10.1.1.2
     User user2
     ProxyCommand ssh -W %h:%p user@8.8.8.8

Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Финал

Разумеется, в посте про туннели должен быть туннель, а в любой успешной статье — секретный ингредиент всеобщей популярности. Держите:

Уровень сложности
Простой

Время на прочтение
5 мин

Количество просмотров 26K

Программистов, сисадминов, devops’ов, тестировщиков часто объединяет использование некоторых общих технологий. Например, возможность иметь удалённый доступ к серверу пригодилось бы любому из указанной выше анекдотичной компании. Поэтому в этой статье мы рассмотрим основы работы с протоколом SSH на базовом уровня (без генерации ключей, подписей, мам, пап и кредитов). «Продвинутое» использование посмотрим уже отдельно, в следующий раз. Материал подготовил Макс, автор YouTube-канала PyLounge. Поехали!

Введение

SSH (Secure SHell — защищенная оболочка) — сетевой протокол прикладного уровня, предназначенный для безопасного удаленного доступа к различным системам (Linux, Windows, Mac).

Данный протокол шифрует всю передаваемую информацию по сети. По умолчанию, используется 22-й порт. В основном он нужен для удаленного управления данными пользователя на сервере, запуска служебных команд, работы в консольном режиме с базами данных.

Эта служба была создана в качестве замены не зашифрованному Telnet и использует криптографические техники, чтобы обеспечить, что всё сообщение между сервером и пользователем было зашифровано.

Чтобы установить SSH-соединение, необходимы два компонента: SSH-сервер и SSH-клиент. Сервер прослушивает определенный порт (по умолчанию это порт 22) и при успешной аутентификации дает доступ пользователю. Все команды, которые используются на SSH-клиенте, отправляются через защищенный канал связи на SSH-сервер, на котором они выполняются и откуда отправляют результат работы обратно клиенту.

SSH-сервер

Устанавливается на управляемой операционной системе и принимает входящие подключения от клиентских машин, проверяя соединение одним из способов:

• по IP-адресу клиента, что не слишком безопасно из-за риска подмены;

• по публичному ключу клиента и имени пользователя. Нужно создать приватный (закрытый) и публичный (открытый) ключ. Зашифровав информацию одним ключом, можно расшифровать ее только другим;

• по паролю клиента, который передается в зашифрованном виде. Это один из наиболее распространенных вариантов. Вводить его нужно при каждом подключении.

Платные и бесплатные SSH-серверы есть для всех распространенных ОС:

• BSD — OpenSSH;

• Linux — dropbear, lsh-server, openssh-server;

• Windows — freeSSHd, copssh, WinSSHD, OpenSSH и т. д.

SSH-клиент

Используется для входа на удаленный сервер и выполнения команд. Через клиент выполняется управление удаленным компьютером.

SSH-клиенты разработаны для всех ОС. Имеют платные и бесплатные версии:

• Linux/BSD — openssh-client, putty, ssh, Vinagre;

• Windows — PuTTY, SecureCRT, ShellGuard;

• Android — connectBot.

Встроенный SSH-клиент Windows, основанный на OpenSSH, предустановлен в ОС, начиная с Windows 10 1809.

Установка OpenSSH на Ubuntu

Установка с помощью менеджера пакетов apt-get:

sudo apt-get install openssh-server

Проверка SELinux

Security Enhanced Linux, или SELinux – это усовершенствованный механизм контроля доступа, встроенный в большинство современных дистрибутивов Linux. Первоначально он был разработан Агентством национальной безопасности США для защиты компьютерных систем от вторжения злоумышленников и взлома. SELinux также может помешать работе с ssh. Поэтому необходимо убедиться, что он отключен, либо отключить его.

Устанавливаем доп. инструменты для работы с сетью и настройками безопасности:

sudo apt-get install policycoreutils
sudo apt-get install net-tools

Проверяем статус SELinux. Состояние должно быть disable.

sestatus

Подключение к виртуальной машине с типом подключения NAT

Если виртуальная машина использует тип сетевого подключения NAT, то первоначально необходимо настроить проброс портов. Пробросим порт хоста 2222 (или любой свободный) на гостевой порт виртуальной машины номер 22 (порт ssh по умолчанию).

После этого мы можем подключиться из Windows к нашей виртуальной машине.

Подключение по ssh через PuTTY

Т.к. в качестве сетевого подключения у виртуальной машины используется NAT, при подключении мы будем указывать петлевой адрес localhost (127.0.0.1) c портом, на который был назначен проброс.

После этого вводим имя пользователя (пользователь должен существовать в linux!!!) и пароль от этого пользователя.

Подключение по ssh через Командную строку Windows (cmd)

Запускаем командную строку сочетанием клавиш Win + R . В открывшемся окне указываем cmd. Нажимаем OK.

В общем видео подключение по ssh имеет вид:

ssh имя_пользователя@ip_адрес_компьютера_к_которому_подключаемся -p порт

Если для подключения используется стандартный порт ssh — 22, то порт можно не указывать.

В открывшемся окне вводим команду:

ssh student@127.0.0.1 -p 2222

Вводим пароль пользователя. Всё. Вы великолепны!

Подключение к виртуальной машине с типом подключение Сетевой мост

С типом подключения Сетевой мост необходимо выдать статический ip для Linux системы. Дальнейшее подключение будет уже по этому, выданному ip, а не через localhost.

Установка статического ip

Начиная с выпуска Ubuntu 17.10 NetPlan теперь это инструмент настройки сети по умолчанию для управления настройками сети, заменяющий файл конфигурации /etc/network/interfaces, который использовался в предыдущих версиях.

Файлы конфигурации для Netplan находятся в каталоге /etc/netplan и написаны на языке YAML. В этом каталоге вы найдете файлы конфигурации YAML.

Откроем конфигурационный файл:

sudo nano /etc/netplan/*.yaml

Отредактируем конфигурационный файл:

network:  
  version: 2
  renderer: NetworkManager
  ethernets:
      enp0s3:
          dhcp4: false
          addresses: [10.40.0.224/24]
          gateway4: 10.40.0.1
          nameservers:
              addresses: [10.2.0.8, 10.2.0.3]

Здесь:

• ethernets — указывает на проводное Ethernet подключение;

• enp0s3 — имя сетевого интерфейса (можно узнать командой ifconfig);

• dhcp4 — автоматическая выдача ipv4-адреса с помощью службы dhcp (для ipv6 указывать dhcp6);

• addresses — ip-адрес и маска сети, которые назначаются компьютеру;

• gateway4 — шлюз по умолчанию;

• nameservers — список dns-серверов.

Посмотреть настройки можно с хостовой машины на Windows с помощью команды ipconfig /all.

Чтобы применить изменения и перезагрузить сеть, вводим команду:

sudo netplan apply

Подключение по ssh

Запускаем командную строку сочетанием клавиш Win + R . В открывшемся окне указываем cmd. Нажимаем OK.

В открывшемся окне вводим команду:

ssh student@10.40.0.224

Вводим пароль пользователя. Всё. Вы великолепны (2)!

Заключение

Несмотря на высокую защиту протокола, использование стандартного порта значительно повышает риск взлома сервера. Например, это можно сделать при помощи brute-force (атака полным перебором). Порт 22 — открытый, поэтому злоумышленнику нужно только подобрать логин и пароль к серверу. Это сложно, но возможно. Чтобы максимально ограничить доступ к серверу для злоумышленников (настроить брандмауэр, iptables), можно сменить SSH-порты.

Ресурсы, которые использовал

1. Как включить SSH в Ubuntu 20.04 (Routerus):https://routerus.com/how-to-enable-ssh-on-ubuntu-20-04/

2. Коротко об SSH / Хабр: https://habr.com/ru/sandbox/166705/

3. Что такое SSH (блог REG.RU): https://help.reg.ru/support/hosting/dostupy-i-podklyucheniye-panel-upravleniya-ftp-ssh/chto-takoye-ssh

Представим, что вы арендовали облачный сервер на cloud.timeweb.com для того, чтобы разместить на нем сайт. После покупки вы получите чистую систему, которую предстоит настраивать — устанавливать веб-сервер, загружать файлы и так далее. Для этого не нужно ехать в дата-центр с флешкой, в таких случаях используется протокол SSH.

SSH (от английского secure shell — защищённая оболочка) — это протокол для удалённого доступа к любым устройствам с операционной системой Linux: компьютерам, серверам, телефонам и так далее. Иными словами, это некий набор правил, позволяющий устанавливать соединение с устройством, которое физически расположено в любой точке мира. 

Слово secure в названии протокола значит, что обмен данными между устройствами шифруется, а значит вы можете работать с чувствительной информацией — паролями, кодами доступа и так далее. 

Информация передаётся в зашифрованном виде, таким образом повышается безопасность обмена данными, с которыми вы работаете. Соединение и аутентификация осуществляются одним из двух способов:

• Вход по паролю. Между клиентом и сервером создаётся общий секретный ключ, с его помощью шифруется трафик.
• Вход с помощью пары ключей. Перед первым соединением пользователь генерирует два ключа: открытый и закрытый. Они хранятся на удалённом и локальном устройствах соответственно. 

В статье рассмотрим возможности протокола, синтаксис SSH-команд и настройки демона SSH. 

Вход в систему с помощью ключей

Использовать пароль входа на сервер по протоколу SSH — небезопасно и неудобно. Во-первых, пароль можно подобрать перебором. Во-вторых, может произойти случайная утечка, ведь устройств может быть несколько, а значит и пароли разные, все не запомнить. А в-третьих, это утомительно — каждый раз вводить кодовое слово перед началом сеанса. 

Самый надёжный способ — входить в систему с помощью пары ключей RSA. 

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

ssh-keygen -t rsa

В процессе создания вам нужно будет выбрать расположение файлов ключей и кодовое слово. Если хотите подключаться без пароля, оставляйте поле Passphrase пустым. Passphrase — это кодовое слово, которым дополнительно защищается ключ. Так, если ваш приватный ключ будет скомпрометирован, злоумышленники не смогут им воспользоваться без кодового слова.

Затем нужно отправить на сервер публичный ключ; на его публичность указывает суффикс .pub и права на чтение для всех пользователей:

ssh-copy-id -p 222 -i ~/.ssh/id_rsa.pub remote@example.com

Команда создаст сеанс SSH. После введения пароля публичный ключ будет скопирован в файл авторизованных ключей, и вам больше не понадобится вводить пароль.

Вы можете ещё больше увеличить безопасность, полностью отключив доступ по паролю. Для этого отредактируйте файл /etc/ssh/sshd_config, выставив следующие директивы:

1. PasswordAuthentication no — запрещаем вход с паролем.
2. PubkeyAuthentication yes — разрешаем аутентификацию по ключам SSH. 
3. ChallengeResponseAuthentication no — отключаем PAM-аутентификацию

После обновления файла перезагружаем демон SSH:

sudo systemctl reload ssh

Настройка SSH

Чтобы выполнить подключение, на удалённом устройстве должен быть запущен сервер sshd, в Ubuntu он запускается с помощью диспетчера systemd:

sudo systemctl start ssh

Конфигурация сервера sshd находится в файле /etc/ssh/sshd_config. Рассмотрим основные параметры настройки SSH, которые вы можете использовать. 

Порт. По умолчанию sshd отслеживает изменения на 22 порту. Часто злоумышленники пытаются получить доступ к вашему устройству перебором паролей от суперпользователей — root, admin и так далее. Можно усложнить эту задачу и изменить стандартный порт на любой другой с помощью директивы Port.

Однако это не гарантирует полную безопасность, так как существуют скрипты, сканирующие порты устройства. Они определят порт, который «слушает» демон sshd, и всё равно попытаются заполучить доступ. Для большей безопасности рекомендуем закрыть SSH для root-пользователя.

Доступ суперпользователя. Поскольку в основном SSH используется для администрирования удаленных серверов Linux, по умолчанию во всех современных системах удалённый доступ суперпользователя root разрешён. Но это очень небезопасно, так как злоумышленники могут попытаться подобрать пароль и, если смогут попасть в систему, получат полный контроль над устройством. Для того, чтобы избежать таких сценариев, используйте директиву PermitRootLogin со значением no. 

Протокол. SSH может работать по двум версиям протокола — 1 и 2. Вторая поддерживает больше методов шифрования и способов аутентификации. Если вы хотите использовать только одну из версий, используйте директиву Protocol: Protocol 2.

Доступ только нескольким пользователям. Ещё больше увеличивает безопасность разрешение удалённого доступа только для определённых пользователей и групп — директивы AllowUsers и AllowGroups соответственно. Так, мы можем запретить доступ к серверу всем, кроме администраторов:

AllowUsers adm1, adm2

или 

AllowGroups admin, infrastructure

Вы также можете запретить доступ конкретным пользователям с помощью DenyUsers и DenyGroups. 

Сохранение ошибок. Уровень логгирования можно задать с помощью директивы LogLevel. Она отвечает за уровень наполнения системного журнала, то есть насколько подробно sshd будет будет сохранять сообщения, которые регистрирует. По умолчанию используется INFO, но в отладочных целях можно поставить VERBOSE или вовсе отключить журналирование QUIET.

Доступ по паролю. За возможность попасть на удалённое устройство с помощью пароля отвечает директива PasswordAuthentication со значениями yes (по умолчанию) или no.

После того, как вы внесли изменения и сохранили файл, нужно перезапустить сервер sshd, чтобы новая конфигурация вступила в силу. Перед этим убедитесь, что вы сохранили на сервер файл ключей или оставили доступ по паролю — иначе существует риск остаться без доступа к серверу. 

sudo systemctl reload ssh

SSH-клиенты

На Windows-системах вы также можете использовать SSH для подключения к удалённому серверу с помощью специальных приложений. Они удобны тем, что позволяют запомнить данные для подключения или указать разные цветовые схемы для разных сеансов (полезно, когда вы администрируете несколько серверов). Среди наиболее популярных:

1. PuTTY
2. WinSCP
3. Termius
4. FileZilla — для передачи данных по SFTP
5. MobaXterm

Если вы работаете в unix-системах, можно использовать простой терминал или командную строку.

Синтаксис

Для удалённого подключения нужно использовать команду SSH с указанием IP-адреса или доменного имени сервера:

ssh example.com

В примере выше предполагается, что имена пользователей в локальной и удалённой системах совпадают. Чаще всего это не так, поэтому приходится отдельно указывать, какое имя использовать при подключении:

ssh remote@example.com

Завершить сеанс можно с помощью команды exit.

Если при настройке удалённого сервера вы указали порт отличный от 22, то на локальном устройстве вам нужно указать его при подключении, сделать это можно с помощью флага -p:

ssh -p 222 remote@example.com

Сценарии использования

Ниже рассмотрим частые и наиболее интересные сценарии использования протокола SSH.

Передача файлов и каталогов

Если на вашем сервере настроен демон sshd, вы также можете пользоваться другими утилитами, которые работают на основе протокола SSH. Одна из таких утилит — scp, которая использует протокол RCP для передачи файлов. 

Для того, чтобы передать файл filename.txt на устройство с адресом example.com и расположить его в каталоге ~/trash/txt, используйте следующую команду:

scp filename.txt remote@example.com:~/trash/txt

Если поменять местами локальный путь и сервер, то вы сможете забрать себе на локальное устройство файлы с удалённого сервера. 

Когда нужно передать весь каталог, добавьте флаг -r. При путь к каталогу, в который вы собираетесь копировать данные, должен завершаться косой чертой. 

Представим, что нам нужно скопировать каталог images с сервера себе на компьютер в папку documents:

scp -r remote@example.com:~/images ~/documents/

Вы также можете передавать файлы между двумя удалёнными машинами, указывая вместо локальных файлов путь подключения к серверу. 

SSH-туннели

Туннели через SSH позволяют устанавливать безопасный удалённый доступ и передавать файлы по защищённой сети. Чаще всего всего они применяются в случае, когда нужно получить доступ в частную сеть или создать зашифрованный канал.

Для того, чтобы пробросить порт с удалённого сервера, используйте флаг -L. Для примера рассмотрим случай, когда нам нужно разрешить работу с удалённой базой данных, которая доступна только на локальной машине, порт 3306. 

Для этого выполним следующую команду:

ssh -N 53306:127.0.0.1:3306 remote@example.com

В этой команде флаг -N означает, что на удалённой машине не нужно выполнять команду, 53306 — локальный порт, 127.0.0.1:3306 — адрес, на котором работает сервис MySQL на удалённом сервере.

Подробнее об SSH-туннелях читайте в нашей статье.

SFTP

SFTP (Secure File Transfer Protocol) — протокол передачи файлов, который работает поверх безопасного канала и является частью OpenSSH, поэтому если у вас корректно работает демон SSH, вы можете использовать SFTP без дополнительной настройки. Главное отличие SFTP от стандартного протокола FTP — шифрование абсолютно любой информации.

Создать сеанс SFTP можно с теми же доступами — логином и паролем или ключом — что и SSH. Кроме этого можно указать порт, если вы меняли его со стандартного 22 на какой-либо другой. Сделайте это с помощью команды:

sftp -oPort=222 remote@example.com

После успешной аутентификации вы окажетесь на удалённом сервере и сможете работать с файлами. 

Заключение

В статье мы разобрали, что такое протокол удалённого управления компьютером и как работает SSH. Знание основ работы этого протокола — незаменимый навык в работе системного администратора и программиста. SSH позволяет подключиться к устройству в любой точке мира и при этом иметь те же самые права и возможности, что и при физической работе с компьютером. 

Если вы размещаете в интернете сайт, при этом используете для этого выделенный сервер, то неправильная конфигурация SSH — угроза проникновения злоумышленников в систему, что может привести к непоправимым последствиям.

Любой сервер, который вы арендуете на cloud.timeweb.com, будет доступен по SSH по умолчанию. А если вам необходимо дополнительно его настроить, наши специалисты всегда на связи.

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

В этой инструкции мы рассмотрим как пользоваться ssh, а также ее возможности, о которых вы даже не знали. Скорее всего, вы уже знаете как подключиться к серверу по ssh, но у этой утилиты есть еще много возможностей, таких как передача файлов ssh, подключение без пароля или выполнение скрипта на удаленном сервере. Все это мы и рассмотрим далее в статье. Но начнем с самых основ.

Базовый синтаксис

Синтаксис команды выглядит следующим образом:

$ ssh [опции] имя пользователя@сервер [команда]

Важно заметить что ssh может работать по двум версиям протокола. Версии 1 и 2. Понятное дело, что версия 2 лучше и поддерживает больше типов шифрования и аутентификации. Больше в этой статье об отличиях протоколов мы говорить не будем и я буду подразумевать что вы используете версию 2.

Теперь давайте рассмотрим самые основные опции команды ssh:

• f — перевести ssh в фоновый режим;
• g — разрешить удаленным машинам обращаться к локальным портам;
• l — имя пользователя в системе;
• n — перенаправить стандартный вывод в /dev/null;
• p — порт ssh на удаленной машине;
• q — не показывать сообщения об ошибках;
• v — режим отладки;
• x — отключить перенаправление X11;
• X — включить перенаправление Х11;
• C — включить сжатие.

Это далеко не все опции утилиты, остальные выходят за рамки данной статьи. Многие настройки работы ssh можно изменять через конфигурационный файл ~/.ssh/config но здесь мы это тоже подробно рассматривать не будем.

Настройка сервера SSH

Настройки сервера SSH находятся в файле /etc/ssh/sshd_config. Многие из них мы тоже трогать не будем. Рассмотрим только самые интересные. Сначала откройте файл /etc/ssh/sshd.conf

Порт ssh

По умолчанию ssh работает на порту 22. Но такое поведение небезопасно, поскольку злоумышленник знает этот порт и может попробовать выполнить Bruteforce атаку для перебора пароля. Порт задается строчкой:

Port 22

Поменяйте значение порта на нужное.

Протокол SSH

По умолчанию сервер ssh может работать по двум версиям протокола, для совместимости. Чтобы использовать только протокол версии два раскомментируйте строчку:

Protocol 2

И приведите ее к такому виду:

Protocol 2

Рут доступ

По умолчанию Root доступ по ssh разрешен, но такое поведение очень небезопасно, поэтому раскомментируйте строчку:

PermitRootLogin no

Доступ только определенного пользователя к SSH

Мы можем разрешить доступ к ssh только для определенного пользователя или группы. Для этого  добавьте строчки:

AllowUsers User1, User2, User3
AllowGroups Group1, Group2, Group3

Здесь User1 и Group1 — пользователь и группа к которым нужно разрешить доступ.

Выполнение X11 приложений

Не все знают но есть возможность использовать ssh для запуска полноценных X11 приложений. Об этом мы поговорим ниже, но чтобы все заработало необходимо разрешить эту возможность на стороне сервера, добавьте такую строчку:

X11Forwarding yes

Основные опции рассмотрели, перед тем как переходить дальше, не забудьте перезагрузить ssh сервер чтобы сохранить изменения:

service sshd restart

Использование SSH

Основная цель этой статьи — показать интересные и полезные способы использования ssh, о которых, возможно, вы не знали. Переходим к самому вкусному — возможности ssh.

Подключение к серверу

Чтобы просто подключиться к серверу по SSH используйте такую команду:

ssh user@host

Выполнить команду

Мы привыкли подключаться к удаленному серверу, а уже потом выполнять нужные команды, но на самом деле утилита ssh позволяет сразу выполнить нужную команду без открытия терминала удаленной машины. Например:

ssh user@host ls

Выполнит команду ls на удаленном сервере и вернет ее вывод в текущий терминал.

Выполнить локальный скрипт

Выполним интерпретатор bash на удаленном сервере и передадим ему наш локальный скрипт с помощью перенаправления ввода Bash:

ssh user@host 'bash -s' < script.sh

Бекап на удаленный сервер и восстановление

Мы можем сохранять бекэп диска сразу на удаленном сервере с помощью ssh. Перенаправим вывод dd с помощью оператора перенаправления |, затем сохраним его на той стороне в файл:

sudo dd if=/dev/sda | ssh user@host 'dd of=sda.img'

Теперь чтобы восстановить состояние диска из сделанной копии выполните:

ssh user@host 'dd if=sda.img' | dd of=/dev/sda

Здесь и выше /dev/sda имя файла вашего жесткого диска.

Аутентификация без пароля

Использование ssh пароля для входа на сервер не только неудобно но и небезопасно, потому что этот пароль в любой момент может быть подобран. Самый надежный и часто используемый способ аутентификации — с помощью пары ключей RSA. Секретный ключ хранится на компьютере, а публичный используется на сервере для удостоверения пользователя.

Настроить такое поведение очень легко. Сначала создайте ключ командой:

ssh-keygen -t rsa

Во время создания ключа нужно будет ответить на несколько вопросов, расположение оставляйте по умолчанию, если хотите подключаться без пароля — поле Passphare тоже оставьте пустым.

Затем отправляем ключ на сервер:

ssh-copy-id -i ~/.ssh/id_rsa.pub user@host

Вот и все. Теперь при попытке подключится к этому серверу пароль запрашиваться не будет, а стазу произойдет подключение. Смотрите подробнее создание открытого ключа для ssh.

Взять пароль из локального файла

Напомню, что хранить пароли в обычных текстовых файлах небезопасно, но если хотите, то да — возможно. Для этого используется оператор перенаправления ввода Bash:

ssh user@host < local_file.txt

 Изменить приветствие SSH

При входе по ssh может выводиться приветствие, изменить его очень легко. За это отвечает файл /etc/issue. Просто откройте этот файл и введите нужный текст:

vi /etc/issue

Welcome!

Смотрим неудачные попытки входа SSH

Хотите посмотреть были ли попытки неудачного доступа по ssh к вашему серверу и с каких IP адресов? Запросто, все запросы логируются в файл /var/log/secure, отфильтруем только нужные данные командой:

cat /var/log/secure | grep "Failed password for"

Передача файлов по SSH

Кроме выполнения команд, можно копировать файлы по ssh. Для этого используется утилита scp. Просто укажите файл, который нужно передать, удаленный сервер и папку на сервере, вот:

$ scp /адрес/локального/файла пользователь@хост:адрес/папки

Например:

scp ~/test.txt user@host:documents

Кроме утилиты scp, передача файлов ssh может быть выполнена более хитрым способом. Прочитаем файл и с помощью cat, передадим, а там сохраним поток в файл:

cat localfile | ssh user@host "cat > remotefile"

Или так:

ssh user@host "cat > remotefile" < localfile

Пойдем еще дальше, вы можете сжимать файлы перед передачей с помощью tar, а потом их сразу же на лету распаковывать:

tar czf - /home/user/file | ssh user@host tar -xvzf -C /home/remoteuser/

Такое копирование файлов ssh позволяет отправлять сразу целые папки.

Запуск графических приложений по ssh

Если вам нужно запустить то или иное графическое приложение на удаленной машине необязательно для этого использовать VNC, вы можете обойтись возможностями ssh. Программа будет выполняться на стороне сервера, а вам будет лишь транслироваться окно, чтобы вы могли сделать все что нужно. Причем все данные шифруются. Чтобы эта функция работала, нужно включить ее поддержку на стороне сервера.

Затем просто выполняем команду запуска графического приложения на удаленном сервере вот таким образом:

ssh -XC user@remotehost "eclipse"

Как вы уже видели опция X разрешает перенаправление X11 на стороне клиента, а С — сжатие данных.

Завершение сессии SSH

Если вы использовали SSH с нестабильным интернетом, когда соединение время от времени рвется, то вам уже, наверное, надоело закрывать терминал, потому что иначе, на первый взгляд, сеанс никак не прекратить. Когда соединение с удаленным сервером разорвано вы не можете ввести никакую команду и сочетания клавиш Ctrl+C, Ctrl+Z, Ctrl+D не работают. И не будут работать поскольку клиент пытается отправить эти команды на сервер. Но есть решение — Escape последовательности. Чтобы активировать их поддержку добавьте строку:

EscapeChar ~

В файл /etc/ssh/ssh_config. Теперь, чтобы разорвать SSH соединение достаточно нажать Enter и набрать:

~.

Другие управляющие символы можно узнать нажав:

~?

Туннели SSH

С помощью SSH туннелей вы можете пробросить порт с удалённого сервера на локальную машину. Это очень полезно, в первую очередь, для разработчиков. Для того чтобы пробросить порт с удалённой машины локальной используйте опцию -L и такой синтаксис:

$ ssh -L локальный_порт:удаленный_адрес:удаленный_порт пользователь@сервер

Например, сделаем удалённую базу данных доступной локально на порту 5555. Для этого выполните подставив свои значения:

$ ssh -N -L 5555:127.0.0.1:3306 root@losst-1

Опция -N сообщает, что команду на удалённой машине выполнять не нужно. Локальный порт — 5555, поскольку сервер баз данных слушает на локальном интерфейсе удалённой машины, то и здесь надо указывать адрес 127.0.0.1. А порт MySQL по умолчанию 3306. Если же вы хотите чтобы локальный сервис был доступен на удалённой машине, то следует использовать опцию -R:

$ ssh -N -R 5555:127.0.0.1:3306 root@losst-1

Теперь локальная база данных на порту 3306 будет доступна на удалённом сервере при обращении к порту 5555.

Выводы

Теперь вы знаете как пользоваться SSH. Как видите, технология SSH позволяет сделать намного больше чем можно предположить с первого взгляда, и это еще далеко не все. Какие интересные возможности SSH используете вы при повседневной работе? Поделитесь в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.