SSH — (Secure Shell) — это протокол удаленного управления компьютером с операционной системой Linux. В основном ssh используется для удаленного управления серверами через терминал. Если вы администратор нескольких серверов или даже продвинутый веб-мастер, то наверное, вы часто сталкиваетесь с необходимостью работать с тем или иным компьютером по ssh. В Linux для этого используется сервер ssh на машине, к которой нужно подключится и клиент, на той из которой подключаются.
Но openSSH — не единственная реализация, вот и другие:
SSH-серверы:
- openSSH — OpenBSD SSH, поставляется в дистрибутивах BSD, Linux и Windows, начиная с Windows 10
- Dropbear — реализация SSH для сред с малым объемом памяти и ресурсов процессора, поставляется в OpenWrt
- PuTTY — реализация SSH для Windows, обычно используется клиент, но реже используется сервер.
- CopSSH — реализация OpenSSH для Windows
Библиотеки SSH (реализация на стороне сервера):
- libssh — мультиплатформенная библиотека C, реализующая протокол SSHv2 с привязками в Python, Perl и R; он используется KDE для sftp и GitHub для инфраструктуры git SSH
- wolfSSH — серверная библиотека SSHv2, написанная на ANSI C и предназначенная для встраиваемых систем, ОСРВ и сред с ограниченными ресурсами
- Apache MINA SSHD — Java-библиотека Apache SSHD основана на Apache MINA
- paramiko — библиотека протокола Python SSHv2
В этой инструкции мы рассмотрим как пользоваться ssh, а также ее возможности, о которых вы даже не знали. Скорее всего, вы уже знаете как подключиться к серверу по ssh, но у этой утилиты есть еще много возможностей, таких как передача файлов ssh, подключение без пароля или выполнение скрипта на удаленном сервере. Все это мы и рассмотрим далее в статье.
Но начнем с самых основ.
Синтаксис команды выглядит следующим образом:
ssh [опции] имя пользователя@сервер [команда]
Важно заметить что ssh может работать по двум версиям протокола. Версии 1 и 2. Понятное дело, что версия 2 лучше и поддерживает больше типов шифрования и аутентификации. Больше в этой статье об отличиях протоколов мы говорить не будем и я буду подразумевать что вы используете версию 2.
1 ОПЦИИ КОМАНДЫ SSH
Теперь давайте рассмотрим самые основные опции команды ssh:
b - привязка интерфейса B - привязка адреса c - спецификация шифрования C - включить сжатие D - привязка адрес:порт f - перевести ssh в фоновый режим F - конфигурационный файл g - разрешить удаленным машинам обращаться к локальным портам l - имя пользователя в системе i - идентификационный файл n - перенаправить стандартный вывод в /dev/null J - jump пользователь@хост:порт p - порт ssh на удаленной машине q - не показывать сообщения об ошибках v - режим отладки x - отключить перенаправление X11 X - включить перенаправление Х11
Это далеко не все опции утилиты, остальные выходят за рамки данной статьи. Многие настройки работы ssh можно изменять через конфигурационный файл ~/.ssh/config но здесь мы это тоже подробно рассматривать не будем.
2 НАСТРОЙКА СЕРВЕРА SSH
Настройки сервера SSH находятся в файле /etc/ssh/sshd_config. Многие из них мы тоже трогать не будем. Рассмотрим только самые интересные. Сначала откройте файл /etc/ssh/sshd.conf
3 ПОРТ SSH
По умолчанию ssh работает на порту 22. Но такое поведение небезопасно, поскольку злоумышленник знает этот порт и может попробовать выполнить Bruteforce атаку для перебора пароля. Порт задается строчкой:
Port 22
Поменяйте значение порта на нужное.
4 ПРОТОКОЛ SSH
По умолчанию сервер ssh может работать по двум версиям протокола, для совместимости. Чтобы использовать только протокол версии два раскомментируйте строчку:
Protocol 2
5 РУТ ДОСТУП
По умолчанию Root доступ по ssh разрешен, но такое поведение очень небезопасно, поэтому раскомментируйте строчку:
PermitRootLogin no
6 ДОСТУП ТОЛЬКО ОПРЕДЕЛЕННОГО ПОЛЬЗОВАТЕЛЯ К SSH
Мы можем разрешить доступ к ssh только для определенного пользователя или группы. Для этого добавьте строчки:
AllowUsers User1, User2, User3 AllowGroups Group1, Group2, Group3
Здесь User1 и Group1 — пользователь и группа к которым нужно разрешить доступ.
7 ВЫПОЛНЕНИЕ X11 ПРИЛОЖЕНИЙ
Не все знают но есть возможность использовать ssh для запуска полноценных X11 приложений. Об этом мы поговорим ниже, но чтобы все заработало необходимо разрешить эту возможность на стороне сервера, добавьте такую строчку:
X11Forwarding yes
Основные опции рассмотрели, перед тем как переходить дальше, не забудьте перезагрузить ssh сервер чтобы сохранить изменения:
service sshd restart systemctl restar ssh
8 ИСПОЛЬЗОВАНИЕ SSH
Основная цель этой статьи — показать интересные и полезные способы использования ssh, о которых, возможно, вы не знали. Переходим к самому вкусному — возможности ssh.
9 ПОДКЛЮЧЕНИЕ К СЕРВЕРУ
Чтобы просто подключиться к серверу по SSH используйте такую команду:
ssh user@host
10 ВЫПОЛНИТЬ КОМАНДУ
Мы привыкли подключаться к удаленному серверу, а уже потом выполнять нужные команды, но на самом деле утилита ssh позволяет сразу выполнить нужную команду без открытия терминала удаленной машины. Например:
ssh user@host ls
Выполнит команду ls на удаленном сервере и вернет ее вывод в текущий терминал.
11 ВЫПОЛНИТЬ ЛОКАЛЬНЫЙ СКРИПТ
Выполним интерпретатор bash на удаленном сервере и передадим ему наш локальный скрипт с помощью перенаправления ввода Bash:
ssh user@host 'bash -s' < script.sh
12 БЕКАП НА УДАЛЕННЫЙ СЕРВЕР И ВОССТАНОВЛЕНИЕ
Мы можем сохранять бекэп диска сразу на удаленном сервере с помощью 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 имя файла вашего жесткого диска.
13 АУТЕНТИФИКАЦИЯ БЕЗ ПАРОЛЯ
Использование ssh пароля для входа на сервер не только неудобно но и небезопасно, потому что этот пароль в любой момент может быть подобран. Самый надежный и часто используемый способ аутентификации — с помощью пары ключей RSA. Секретный ключ хранится на компьютере, а публичный используется на сервере для удостоверения пользователя.
SSH поддерживает несколько алгоритмов аутентификации с открытым ключом. К ним относятся:
- rsa — старый алгоритм, основанный на сложности разложения на множители больших чисел. Для RSA рекомендуется размер ключа не менее 2048 бит; 4096 бит лучше. RSA устаревает, и в факторинге достигаются значительные успехи. Может быть целесообразным выбор другого алгоритма. Вполне возможно, что алгоритм RSA станет практически уязвимым в обозримом будущем. Все SSH-клиенты поддерживают этот алгоритм.
- dsa — старый алгоритм цифровой подписи правительства США. Он основан на сложности вычисления дискретных логарифмов. Обычно с ним используется ключ размером 1024. DSA в его первоначальном виде больше не рекомендуется.
- ecdsa — новый алгоритм цифровой подписи, стандартизированный правительством США, использующий эллиптические кривые. Вероятно, это хороший алгоритм для текущих приложений. Поддерживаются только три размера ключей: 256, 384 и 521 (sic!) бит. Мы бы рекомендовали всегда использовать его с 521 битами, поскольку ключи все еще маленькие и, вероятно, более безопасные, чем ключи меньшего размера (хотя они также должны быть безопасными). Большинство SSH-клиентов теперь поддерживают этот алгоритм.
- ed25519 — это новый алгоритм, добавленный в OpenSSH. Его поддержка в клиентах еще не универсальна. Таким образом, его использование в приложениях общего назначения может быть пока нецелесообразным.
ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f output_keyfile] [-m format] [-N new_passphrase] [-O option] [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa] [-w provider] [-Z cipher] ssh-keygen -p [-a rounds] [-f keyfile] [-m format] [-N new_passphrase] [-P old_passphrase] [-Z cipher] ssh-keygen -i [-f input_keyfile] [-m key_format] ssh-keygen -e [-f input_keyfile] [-m key_format] ssh-keygen -y [-f input_keyfile] ssh-keygen -c [-a rounds] [-C comment] [-f keyfile] [-P passphrase] ssh-keygen -l [-v] [-E fingerprint_hash] [-f input_keyfile] ssh-keygen -B [-f input_keyfile] ssh-keygen -D pkcs11 ssh-keygen -F hostname [-lv] [-f known_hosts_file] ssh-keygen -H [-f known_hosts_file] ssh-keygen -K [-a rounds] [-w provider] ssh-keygen -R hostname [-f known_hosts_file] ssh-keygen -r hostname [-g] [-f input_keyfile] ssh-keygen -M generate [-O option] output_file ssh-keygen -M screen [-f input_file] [-O option] output_file ssh-keygen -I certificate_identity -s ca_key [-hU] [-D pkcs11_provider] [-n principals] [-O option] [-V validity_interval][-z serial_number] file ... ssh-keygen -L [-f input_keyfile] ssh-keygen -A [-a rounds] [-f prefix_path] ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number] file ... ssh-keygen -Q [-l] -f krl_file [file ...] ssh-keygen -Y find-principals -s signature_file -f allowed_signers_file ssh-keygen -Y match-principals -I signer_identity -f allowed_signers_file ssh-keygen -Y проверка-обновление -n namespace -s signature_file ssh-keygen -Y sign -f key_file -n namespace file [-O option] ... ssh-keygen -Y verify -f allowed_signers_file -I signer_identity -n namespace -s signature_file [-r krl_file] [-O option]
Настроить такое поведение очень легко. Сначала создайте ключ командой:
ssh-keygen -t rsa -b 4096 ssh-keygen -t rsa -b 8192 или ssh-keygen -t ed25519
Во время создания ключа нужно будет ответить на несколько вопросов, расположение оставляйте по умолчанию, если хотите подключаться без пароля — поле Passphare тоже оставьте пустым.
Затем отправляем ключ на сервер:
ssh-copy-id -i ~/.ssh/id_rsa.pub user@host
Вот и все. Теперь при попытке подключится к этому серверу пароль запрашиваться не будет, а стазу произойдет подключение.
Смотрите подробнее создание открытого ключа для ssh.
Чтобы исправить $HOME/.ssh/known_hosts2: No such file or directory, вы можете добавить файл для UserKnownHostsFile в свою конфигурацию SSH, например:
UserKnownHostsFile ~/.ssh/known_hosts
Чтобы исправить/etc/ssh/ssh_known_hosts: No such file or directory и /etc/ssh/ssh_known_hosts2: No such file or directory, вы можете добавить файл GlobalKnownHostsFile в свою конфигурацию SSH, например:
GlobalKnownHostsFile /dev/null
14 ХРАНЕНИЕ МЕНЕДЖМЕНТ КЛЮЧЕЙ
ssh-add — это команда для добавления закрытых ключей SSH в агент аутентификации SSH для реализации единого входа с помощью SSH. Процесс агента называется ssh-agent; см. эту страницу, чтобы узнать, как ее запустить.
Самое замечательное в ssh-agent и ssh-add заключается в том, что они позволяют пользователю использовать любое количество серверов, распределенных по любому количеству организаций, без необходимости каждый раз вводить пароль при перемещении между серверами. Это обычно используется системными администраторами для перемещения между администрируемыми ими машинами. Он также широко используется в университетах и исследовательских институтах для доступа к вычислительным ресурсам. Однако это также привело к увеличению количества ключей SSH на предприятиях, и об этом должны знать администраторы, а аудит должен принять меры для решения этой проблемы.
ssh-add принимает следующие параметры командной строки.
-c Запрашивает подтверждение у пользователя каждый раз, когда добавленные идентификаторы используются для аутентификации. Подтверждение запрашивается с помощью ssh-askpass.
-D Удаляет все идентификаторы агента.
-d Удаляет указанные идентификаторы из агента. Файлы секретных ключей для удаляемых идентификаторов должны быть перечислены в командной строке.
-E Указывает хеш-алгоритм для отображения отпечатков ключей. Допустимые параметры: md5 и sha256.
-e pkcs11path Удалить идентификаторы, предоставленные с использованием интерфейса PKCS#11, идентифицированные по заданному пути к его общей библиотеке. Интерфейсы PKCS#11 обычно используются для доступа к ключам на смарт-картах и аппаратных модулях безопасности (HSM).
-k При загрузке ключей в агент или удалении ключей из агента обрабатывать только простые закрытые ключи, пропуская сертификаты.
-L Перечисляет параметры открытого ключа всех идентификаторов, представленных в данный момент агентом.
-l Перечисляет отпечатки всех идентификаторов, представленных в данный момент агентом.
-s pkcs11path Добавляет идентификаторы, предоставленные общей библиотекой PKCS#11 по адресу pkcs11path. Это можно использовать для добавления ключей на смарт-карты или в аппаратные модули безопасности (HSM).
-t life Устанавливает максимальное время, в течение которого агент будет хранить данный ключ. По истечении таймаута ключ будет автоматически удален из агента. Значением являются секунды, но к нему можно добавить суффикс m для минут, h для часов, d для дней или w для недель.
-X Разблокирует агента. Для разблокировки запрашивается пароль.
-x Блокирует агента. Это запрашивает пароль; пароль необходим для разблокировки агента. Когда агент заблокирован, его нельзя использовать для аутентификации.
15 ВЗЯТЬ ПАРОЛЬ ИЗ ЛОКАЛЬНОГО ФАЙЛА
Напомню, что хранить пароли в обычных текстовых файлах небезопасно, но если хотите, то да — возможно. Для этого используется оператор перенаправления ввода Bash:
ssh user@host < local_file.txt
16 ИЗМЕНИТЬ ПРИВЕТСТВИЕ SSH
При входе по ssh может выводиться приветствие, изменить его очень легко. За это отвечает файл /etc/issue.
Просто откройте этот файл и введите нужный текст:
nano /etc/issue
Welcome!su
17 СМОТРИМ НЕУДАЧНЫЕ ПОПЫТКИ ВХОДА SSH
Хотите посмотреть были ли попытки неудачного доступа по ssh к вашему серверу и с каких IP адресов?
Запросто, все запросы логируются в файл /var/log/secure, отфильтруем только нужные данные командой:
cat /var/log/secure | grep "Failed password for"
18 ПЕРЕДАЧА ФАЙЛОВ ПО 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 позволяет отправлять сразу целые папки.
19 ЗАПУСК ГРАФИЧЕСКИХ ПРИЛОЖЕНИЙ ПО SSH
Если вам нужно запустить то или иное графическое приложение на удаленной машине необязательно для этого использовать VNC, вы можете обойтись возможностями ssh. Программа будет выполняться на стороне сервера, а вам будет лишь транслироваться окно, чтобы вы могли сделать все что нужно. Причем все данные шифруются. Чтобы эта функция работала, нужно включить ее поддержку на стороне сервера.
Затем просто выполняем команду запуска графического приложения на удаленном сервере вот таким образом:
ssh -XC user@remotehost "firefox"
Как вы уже видели опция X разрешает перенаправление X11 на стороне клиента, а С — сжатие данных.
20 ЗАВЕРШЕНИЕ СЕССИИ SSH
Если вы использовали ssh с нестабильным интернетом, когда соединение время от времени рвется, то вам уже, наверное, надоело закрывать терминал, потому что иначе, на первый взгляд, сеанс никак не прекратить. Когда соединение с удаленным сервером разорвано вы не можете ввести никакую команду и сочетания клавиш Ctrl+C, Ctrl+Z, Ctrl+D не работают. И не будут работать поскольку клиент пытается отправить эти команды на сервер. Но есть решение — Escape последовательности. Чтобы активировать их поддержку добавьте строку:
EscapeChar ~
В файл
/etc/ssh/ssh_config
Теперь, чтобы разорвать ssh соединение достаточно нажать Enter и набрать:
~.
Другие управляющие символы можно узнать нажав:
~?
21 CОЗДАЕМ ТУНЕЛЬ
Для идентификации пользователя нужны два ключа — приватный и публичный (открытый). Открытый хранится на сервере, приватный — на локальной машине. Создание безопасного подключения отличается в зависимости от операционной системы.
Чтобы сделать подключение безопаснее, не стоит использовать аккаунт с правами суперпользователя. Кроме того, можно ограничить связь между консолями локальной машины и удалённого сервера, указав параметр -N. Пример команды:
ssh -N -L -g 3389:192.168.0.105:3389 user@host
Это исключит ситуацию, при которой пользователь случайно выполняет на удалённой машине команды, предназначенные для локального компьютера.
22 ИСПОЛЬЗУЕМ SSH Proxy
SSH-tunnel Proxy помогает организовать доступ к домашней или корпоративной системе. Важно только, чтобы приложения, которые используются для работы при подключении, поддерживали SOCKS-прокси. Один из вариантов такого использования туннелей — сотрудник подключается к рабочей сети, используя публичную сеть в другом конце мира, при этом вся информация шифруется.
Для туннелирования через прокси достаточно выполнить:
ssh -D 8888 user@remoteserver
Этой командой вы запускаете SOCKS-прокси. Порт — 8888. В этом случае служба работает на localhost. Но можно изменить команду, чтобы прослушивать Ethernet и Wi-Fi. Это позволит приложениям подключаться к прокси-серверу через Secure Shell.
Например, можно запустить браузер Google Chrome:
google-chrome --proxy-server="socks5://192.168.1.10:8888"
Команда создаёт SOCKS-прокси, а также инициирует туннелирование DNS-запросов
23 Динамический SSH-tunnel
Динамический SSH-tunnel открывает локальный сокет TCP и использует его как SOCKS4/SOCKS5-прокси. Такой туннель отвечает всем требованиям безопасности.
Динамический туннель также подходит для однократного выхода в интернет:
ssh -D 1080 user@host
SOCKS-прокси работает через порт 1080. Динамический туннель не предусматривает открытие портов во внешнюю сеть. Весь трафик проходит по нему, скрывая деятельность пользователя.
24 Примеры использования туннелей
Рассмотрим несколько примеров использования туннелей.
Проброс портов — SSH Port Forwarding
SSH Forwarding — одна из самых распространенных операций, для которой требуется создать туннель. Вы открываете порт на локальной машине и выбираете порт на другом конце — удаленном сервере:
ssh -L 9999:127.0.0.1:80 user@remoteserver
В этой команде вы говорите, что нужно слушать порт 9999. Для проброса используется порт 80.
Обратный туннель
Туннель может работать и в обратном направлении. Для этого достаточно подключить слушающий порт к другому порту на локальной машине:
ssh -v -R 0.0.0.0:1999:127.0.0.1:902 192.168.1.100 user@remoteserver
В этом туннеле соединение идёт от удалённого сервера к порту 1999, затем к порту 902 на локальной машине.
Удалённое выполнение команд
Через Secure Shell можно создать интерфейс для выполнения команд на удалённой машине. Сами команды прописываются в качестве последнего аргумента. Пример:
ssh remoteserver "cat /var/log/nginx/access.log" | grep badstuff.php
После скачивания лога на удалённом сервере выполнится команда grep.
25 Выполнение команды SFTP
Другая распространенная неправильная конфигурация SSH часто встречается в конфигурации SFTP. В большинстве случаев при создании сервера SFTP администратор хочет, чтобы пользователи имели доступ по протоколу SFTP для совместного использования файлов, но не получали удаленную оболочку на машине. Поэтому они думают, что создания пользователя, присвоения ему оболочки-заполнителя (например, /usr/bin/nologin или /usr/bin/false) и помещения его в заключение достаточно, чтобы избежать доступа к оболочке или злоупотреблений во всей файловой системе. Но они ошибаются: пользователь может попросить выполнить команду сразу после аутентификации до того, как будет выполнена команда или оболочка по умолчанию. Таким образом, чтобы обойти оболочку заполнителя, которая будет запрещать доступ к оболочке, нужно только попросить выполнить команду (например, /bin/bash) раньше, просто выполнив:
ssh -v user@192.168.1.250 id
Password: debug1: client_input_global_request: rtype hostkeys- 00@localhost want_reply 0 debug1: Sending command: id debug1: client_input_channel_req: channel 0 rtype exit- status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@localhost reply 0 debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2412, received 2480 bytes, in 0.1 seconds Bytes per second: sent 43133.4, received 44349.5 debug1: Exit status 0
ssh st@192.168.1.250 /bin/bash
Вот пример безопасной конфигурации SFTP (/etc/ssh /sshd_config — openSSH) для пользователя st:
Match User st ChrootDirectory /home/st ForceCommand internal-sftp AllowTcpForwarding no PermitTunnel no X11Forwarding no PermitTTY no
Эта конфигурация разрешит только SFTP: отключение доступа к оболочке путем принудительного запуска команды и отключения доступа TTY, а также отключение всех видов переадресации или туннелирования портов.
OpenSSH Test Mode
OpenSSH имеет опцию тестового режима. Используйте опцию -t , чтобы проверить достоверность файла конфигурации и работоспособность ключей. Это полезно для надежного обновления sshd, поскольку параметры конфигурации могут измениться. После внесения изменений в файл конфигурации введите следующую команду, выполните проверку синтаксиса файла конфигурации, введите:
sshd -t на выходе получим:
/etc/ssh/sshd_config: line 26: Bad configuration option: PermitRootLogins /etc/ssh/sshd_config: terminating, 1 bad configuration options
Проверка конфигурации sshd с использованием расширенного тестового режима
Передайте опцию -T следующим образом:
sshd -T
Вам нужно оценить пользовательский файл конфигурации ssh и вывести эффективную конфигурацию, примененную к вашей команде ssh во время выполнения, для целей отладки? Попробуйте передать -G следующим образом:
ssh -G {host_or_ip_here}
ssh -F {~/path/to/ssh_config} -G {host_or_ip_here}
ssh -G 192.168.1.250
ssh -G -F ~/.ssh/config user
Rsync через SSH
Бэкапы важных данных можно делать с помощью bzip2. Порядок простой — сначала вы сжимаете каталог на удалённом сервере, а затем распаковываете на другой стороне: на локальной машине или на другом сервере, заведённом под хранение резервных копий. Пример команды:
tar -cvj /datafolder | ssh remoteserver "tar -xj -C /datafolder"
Если бэкапы нужно делать регулярно (обычно так и происходит), то проще использовать команду rsync:
rsync -az /home/user/data server:backup/
Rsync не копирует файлы с нуля, а сравнивает отличия в разных временных точках. Это экономит время на создание бэкапов, а также помогает найти данные для восстановления при утере или повреждении.
Запуск приложений
Через SSH-туннель можно запускать GUI-приложения на удалённом сервере:
ssh -X remoteserver firefox
Несмотря на то, что приложение выполняется на удалённом сервере, его интерфейс доступен на локальной машине. Это удобно если, например, нужно больше ресурсов для работы, а локальная машина уже не справляется.
Прыжки по хостам
Если сеть сегментирована, то при туннелировании придётся пройти через несколько хостов. При этой рабочий сеанс должен быть полностью зашифрованным. Добиться такого результата можно с помощью параметра -J. Для установления связи с каждым следующим хостом будет использоваться переадресация:
ssh -J host1,host2,host3 user@host4.internal
Локальная папка на удаленной машине
С помощью sshfs можно примонтировать локальный каталог к удалённому серверу.
apt install sshfs
sshfs user@kvmserver:/media/data ~/data/
Это удобное решение для обмена файлами и выполнения других операций.
Для постоянного монтирования в /etc/fstab добавляется такая строка.
user@server:/home/user/backup /home/user/backup fuse.sshfs defaults,_netdev,IdentityFile=/root/.ssh/id_rsa 0 0
SSH Jump Server
SSH Jump Server — это обычный сервер Linux, доступный из интернета, который используется в качестве шлюза для доступа к другим машинам Linux в частной сети с использованием протокола SSH. Иногда SSH Jump Server также называют jump host или bastion host. Назначение SSH Jump Server — быть единственным шлюзом для доступа к вашей инфраструктуре, уменьшая размер потенциальной поверхности атаки. Наличие выделенной точки доступа SSH также упрощает ведение сводного журнала аудита всех SSH подключений.
Почему бы не использовать термин SSH-proxy? Отчасти по историческим причинам. В первые дни использования SSH пользователям приходилось подключаться по SSH к Jump Server, а оттуда им приходилось снова вводить ssh, чтобы «перейти» к хосту назначения. Сегодня это делается автоматически, и Teleport фактически использует термин SSH-proxy для описания этой функции.
Настройка SSH Jump Server
Одной из хороших практик информационной безопасности будет использование выделенного SSH Jump-сервера, то есть отказаться от размещения на нём какое-либо другого общедоступного программного обеспечения. Кроме того, нужно запретить пользователям напрямую входить на jump-сервер. Вот парочка причин:
- Чтобы предотвратить непреднамеренное обновление конфигурации jump-сервера
- Чтобы исключить возможность использования jump-сервера для других задач
Также неплохо изменить порт TCP по умолчанию на сервере перехода SSH с 22 на другой.
Давайте рассмотрим настройку сервера перехода SSH с использованием двух проектов с открытым исходным кодом. Начнём с OpenSSH, самого распространённого варианта.
Но сначала давайте введём некоторые имена, которые будут использоваться в примерах ниже:
- Домен организации: localhost
- DNS-имя jump-сервера организации будет proxy.localhost
Также предполагается, что proxy.example.com — это единственная машина в локальной сети организации, доступная из Интернета.
Если у вас есть доступ к jump-серверу proxy.localhost, вы можете получить доступ к другим серверам в локальной сети за этим NAT с помощью -J флага в командной строке:
ssh -J proxy.schoolsintez.ru 192.168.1.250
В приведённом примере 192.168.1.250 – это адрес конечной станции в локальной сети, к которой вы подключаетесь. Выглядит довольно просто.
Чтобы не печатать в командной строке параметры -J proxy.localhost, вы можете обновить конфигурацию SSH на вашем клиенте в файле /etc/ssh/ssh_config следующим образом:
Host 192.168.1.*
ProxyJump proxy.localhost
Теперь, когда пользователь вводит ssh 192.168.1.250, SSH-клиент даже не пытается разрешить адрес 192.168.1.250 локально, а вместо этого устанавливает соединение c proxy.example.com, которое перенаправляет его на 192.168.1.250 в своем локальном сегменте.
Теперь нужно немного усилить конфигурацию безопасности jump-сервера, отключив интерактивные сеансы SSH на jump-сервере для обычных пользователей, но оставив их включёнными для администраторов. Для этого необходимо обновить конфигурацию sshd, обычно она лежит в файле /etc/ssh/sshd_config:
# Не позволяйте SSH-клиентам делать что-либо, кроме перенаправления к месту назначения: PermitTTY no X11Forwarding no PermitTunnel no GatewayPorts no ForceCommand /sbin/nologin
Приведённый выше пример будет работать для Debian и его производных, советуем проверить наличие файла /sbin/nologin.
Это конфигурация будет работать, если на jump-сервере есть учётные записи для всех пользователей SSH, что не очень удобно. Вместо этого рассмотрите возможность создания отдельной учётной записи на jump-сервере, предназначенной для перенаправляемых пользователей ssh. Назовём эту учётную запись jumpuserи обновим конфигурацию ssh-сервера:
Match User st PermitTTY no X11Forwarding no PermitTunnel no GatewayPorts no ForceCommand /usr/sbin/nologin
И пользователям нужно будет обновить конфигурацию своего клиента SSH в файле /etc/ssh/ssh_config:
Host 10.2.2.*
ProxyJump user@proxy.localhost
Для получения дополнительной информации по конфигурированию SSH для вашей конкретной ситуации, обратитесь к man ssh_config и man sshd_config.
Надо заметить, что описанная выше настройка работает только когда общедоступные ключи SSH правильно распределены не только между клиентами и jump-сервером, но также между клиентами и серверами назначения.
Более подробней по ssh и sshd смотрите :
man ssh_config man sshd_config