Если к серверу необходимо подключаться с компьютеров, находящихся в сети с жёсткими ограничениями (вплоть до закрытия всех портов, кроме HTTP (80) и HTTPS (443), можно настроить SSH-демон на прослушивание порта 443:
Port 22 Port 443
Однако, этот способ не годится, если параллельно должен работать веб-сервер, выдающий страницы по протоколу HTTPS. В таком случае можно воспользоваться одним из приведённых ниже способов.
Один из способов - настроить веб-сервер на передачу SSH-трафика (определяемого по какому-либо критерию; например, по заданному URL или доменному имени) SSH-демону, работающему на каком-то другом порту.
SSH over SSL, episode 3: Avoiding using a patched apache.
К сожалению, в настоящее время (осень 2013) только Apache поддерживает метод “CONNECT”, необходимый для этой цели.
Можно воспользоваться мультиплексором протоколов sslh, который слушает порт 443 и сортирует входящий трафик по соответствующим сервисам далее (SSH, веб-сервер, …)
Чтобы разрешить клиентам перенаправлять подключения к некоторым портам сервера на свои локальные компьютеры, нужно в файле /etc/ssh/sshd_config
разрешить параметр GatewayPorts
. Согласно man sshd_config, этот параметр может иметь три значения: no
, yes
и clientspecified
. Будем использовать последнее, т.к. оно позволяет клиенту самостоятельно выбрать, разрешать внешним компьютерам использование обратного тоннеля или нет.
GatewayPorts clientspecified
Необходимо установить программу, создающую TCP-тоннель через прокси-сервер. Например, corkscrew
. После этого отредактировать пользовательский файл настроек SSH следующим образом:
Host * ProxyCommand corkscrew <proxy_server> <proxy_port> %h %p
Если прокси-сервер требует логина и пароля, то конфигурация SSH-клиента должна выглядеть следующим образом:
Host * ProxyCommand corkscrew <username:password@proxy_server> <proxy_port> %h %p
Или так?
Создаём файл, содержащий имя пользователя и пароль для доступа к прокси-серверу:
username:password
Затем добавляем путь к этому файлу в файл конфигурации SSH:
Host * ProxyCommand corkscrew <proxy_server> <proxy_port> %h %p /home/username/.corkscrew-auth
ssh -f -N -L<local_port>:jabber.od.ua:5222 -p <ssh_server_port> <ssh_server>
-f
уйти в фон
-N
не выполнять никаких команд
Обратный SSH-тоннель позволяет перенаправлять соединения, устанавливаемые с некоторым портом удалённого сервера, на наш локальный компьютер1)
ssh -R 19999:localhost:22 -p <ssh_server_port> <ssh_server_user>@<ssh_server>
после чего станет возможным с удалённого сервера (<ssh_server>) подключаться к локальному компьютеру до тех пор, пока живо вышеустановленное соединение.
ssh localhost -p 19999
По умолчанию ssh перенаправляет подключения только к локальному сетевому интерфейсу удалённого сервера (его localhost). Это означает, что подключения извне на этом удалённом сервере в указанный порт не принимаются. Если же неообходимо разрешить перенаправление соединений к нашему локальному компьютеру не только непосредственно из консоли удалённого сервера, но и для любых других компьютеров глобальной сети, то устанавливать обратный тоннель следует так:
ssh -R *:19999:localhost:22 -p <ssh_server_port> <ssh_server_user>@<ssh_server>
Здесь звёздочка (*
) указывает, что “слушать” удалённому серверу надо на всех его сетевых интерфейсов. Вместо неё можно указать и конкретный IP-адрес, на котором слушать. Тогда сервер будет принимать подключения только на указанном сетевом интерфейсе.
Следует отметить, что для реализации последнего варианта необходимо разрешить на сервере параметр ''GatewayPorts''.
Теперь любое подключение к серверу <ssh_server> в порт 19999
будет перенаправлено на наш локальный компьютер в порт 22
. Разумеется, номера портов можно менять на любые другие. С тем только исключением, что привелегированные порты использовать может только администратор системы (root).
Для того, чтобы подключаться без пароля, нужно сгенерировать ключ:
ssh-keygen -t rsa -b 2048 -f id_rsa.key
В результате появятся два файла: секретный ключ – id_rsa.key
и открытый ключ – id_rsa.key.pub
. Первый из них необходимо оставить на компьютере-клиенте и сделать доступ к нему для посторонних невозможным (поместить в каталог /home/taras/.ssh/
). Второй – открытый – ключ нужно поместить на сервер в домашний каталог того пользователя, от имени которого будет осуществляться подключение к серверу (дописать к файлу /home/taras/.ssh/authorized_keys
)
Подключаться с использованием этого ключа следует так:
ssh -i .ssh/id_rsa taras@server.org.ua
dropbearkey -t rsa -s 2048 -f id_rsa.key
В результате закрытый ключ будет записан в файл id_rsa.key
, а на экран будут выведены открытый ключ и отпечаток (“fingerprint”):
Public key portion is: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCClbPAs9q4i9WEmtIGX/XOArDa6r40bRei/ta6JZA217ucOhzYOabacasYi7HPDEGYqcs95KL5olnMr5UpELUbCyt1THy0W7e0lWbg10NuKkbq4OZAN3Dw59JHBHizWe+p8fsqKfwHrr1YSR6DxiZeKlEv0QWfckBnp3Xq5Y1cWWeMZlOApZTmmWJIvCMdyQwM4SW18nz9UZBkbypfSsZZYxVcht+EjXdBICHehezqwKQZkKnRa3WdTDKP0zKYA0WEQFK4UekPQYrHGS+4kgLiD7jZUS9Wh88sWMJwPcrfo3HgvcIAWTRzKsoUGimWKUYAfK2eMjxAz0GoQAcFYwu7 root@OpenWrt Fingerprint: md5 60:3f:47:8e:19:99:94:53:29:83:83:3e:84:c7:dd:09
В этом случае также надлежит открытый ключ дописать к файлу /home/taras/.ssh/authorized_keys
на сервере, а закрытый поместить в какой-либо защищённый каталог на компьютере, с которого будет происходить подключение.
Подключаться с использованием этого ключа следует так:
ssh -i id_rsa.key taras@server.org.ua
Если при попытке подключения ssh выдаёт ошибку
Unable to negotiate with example.com: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
Это обозначает, что сервер предлагает обмен ключей по алгоритму diffie-hellman-group1-sha1
, который не рекомендуется, начиная с версии OpenSSH 7. В общем случае это обозначает, что программа-сервер нуждается в обновлении. Временно можно эту ошибку обойти, если в явном виде разрешить своему ssh-клиенту использовать этот алгоритм. Сделать это можно так:
'ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@server
SSH-туннели — пробрасываем порт на Хабрахабре
Викикнига SSH туннелирование