Оглавление:
1) Local TCP forwarding
2) Remote TCP forwarding
3) TCP forwarding chain через несколько узлов
4) TCP forwarding ssh-соединения
5) SSH VPN Tunnel
6) Коротко о беспарольном доступе
7) Спасибо (ссылки)
1) Local TCP forwarding
Начнем с простого — local TCP forwarding:
Имеем удаленный сервер «host2» с неким приложением, допустим, PostgreSQL server, которое принимает TCP-соединения на порту 5432. При этом вполне логично, что на этом сервере стоит файрвол, который прямых соединений извне на порт 5432 не разрешает, но при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить). Требуется подключиться с нашего рабочего места «host1» клиентским приложением к серверу PostgreSQL на «host2».
Для этого на «host1» в консоли набираем:
host1# ssh -L 9999:localhost:5432 host2Теперь на «host1» мы можем соединяться с PostgreSQL сервером через локальный порт 9999:
host1# psql -h localhost -p 9999 -U postgresИдем по дереву настроек: Connection > SSH > Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.
ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).
/etc/ssh/sshd_config:
AllowTcpForwarding yesМы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:
Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:
host1# ssh -L 9999:host3:5432 host2Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».
Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:
Для этого нужно вставить в команду соединения ssh IP-адрес интерфейса, на котором будет поднят локальный порт 9999:
ssh -L 0.0.0.0:9999:host3:5432 host2В данном примере порт 9999 будет открыт на всех доступных на «host1» IPv4 интерфейсах.
2) Remote TCP forwarding
Но что делать, если, например, «host2» не имеет белого IP-адреса, находится за NAT или вообще все входящие соединения к нему закрыты? Или, например, на «host2» стоит Windows и нет возможности поставить SSH-сервер?
Для этого случая есть Remote TCP forwarding:
Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:
ssh -R 9999:localhost:5432 host1Идем по дереву настроек: Connection > SSH > Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.
Также у вас возникнут дополнительные сложности с обеспечением безопасности на «host1», если вы не доверяете узлу «host2». Однако это выходит за рамки данной статьи.
И, конечно, вы каким-то образом (сами или с посторонней помощью) должны инициировать ssh-соединение со стороны «host2» вводом приведенной выше команды, а «host1» должен иметь белый IP-адрес и открытый порт SSH.
После установки ssh-соединения все работает аналогично предыдущей главе.
3) TCP forwarding chain через несколько узлов
В закрытых сетях часто бывает, что нужный нам узел напрямую недоступен. Т.е. мы можем зайти на нужный хост только по цепочке, например host1 > host2 > host3 > host4:
host1# ssh host2
host2# ssh host3
host3# ssh host4
host4# echo hello host4Это может происходить например если эти узлы являются шлюзами, либо если на них доступны шлюзы только в соседние подсети.
В таком случае мы также можем делать TCP forwarding по цепочке:
Здесь порты 9991, 9992, 9993 выбраны для наглядности, на практике можно использовать один и тот же порт (например, 9999), если он свободен на всех узлах.
Итого нужно выполнить следующую цепочку команд:
host1# ssh -L 9991:localhost:9992 host2
host2# ssh -L 9992:localhost:9993 host3
host3# ssh -L 9993:localhost:5432 host4- на «host1»: открывается порт 9991, при подключении к которому данные перенаправляются по ssh-соединению на порт 9992 на «host2»;
- на «host2»: открывается порт 9992, при подключении к которому данные перенаправляются по ssh-соединению на порт 9993 на «host3»;
- на «host3»: открывается порт 9993, при подключении к которому данные перенаправляются по ssh-соединению на порт 5432 на «host4»;
Таким образом, при соединении на порт 9991 на «host1», данные перенаправляются по цепочке на «host4» на порт 5432.
ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).
4) TCP forwarding ssh-соединения
Иногда бывает нужно соединиться по ssh с сервером, который напрямую недоступен, а доступ возможен только по цепочке ssh-серверов (см. предыдущую главу). Теперь мы обладаем нужными знаниями чтобы сделать следующее:
host1# ssh -L 2222:localhost:2222 host2
host2# ssh -L 2222:host4:22 host3Таким образом, на порту 2222 на «host1» у нас теперь есть форвардинг на порт SSH (22) на «host4». Можем соединиться:
host1# ssh -p 2222 localhost
host4# echo hello host4Казалось бы, зачем это нужно? Например, вот зачем:
# копируем файл на host4
host1# scp -P 2222 /local/path/to/some/file localhost:/path/on/host4
# копируем файл с host4
host1# scp -P 2222 localhost:/path/on/host4 /local/path/to/some/file
# делаем еще один замечательный TCP forwarding на host4
host1# ssh -p 2222 -L 9999:localhost:5432 localhost
host1# psql -h localhost -p 9999 -U postgres
# обратите внимание, что порт для команды ssh задается ключем -p в нижнем регистре,
# а для команды scp -P в верхнем регистреНу и вообще, здорово что теперь «host4» так близко :)
Вывод: можно делать TCP forwarding большого уровня вложенности.
Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из ~/.ssh/known_hosts.
5) SSH VPN Tunnel
TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.
Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.
Настройка SSH-сервера:
PermitTunnel в настройках sshd по-умолчанию выключен, его нужно включить в /etc/ssh/sshd_config:
PermitTunnel yesили
PermitTunnel point-to-pointВАЖНО: для поднятия нового сетевого интерфейса туннеля и на ssh-клиенте, и на ssh-сервере необходимы права суперпользователя. Можно долго спорить о том, насколько это небезопасно, но в большинстве случаев на ssh-сервере достаточно настройки:
PermitRootLogin without-passwordТаким образом вы запрещаете вход root по паролю, а разрешаете только другими средствами, например, по ключу RSA, что гораздо безопаснее.
Перезапускаем sshd:
sudo service sshd restart # centosили
/etc/init.d/ssh restart # (debian/ubuntu)Туннель поднимается при использовании магического ключа -w:
host1# sudo ssh -w 5:5 root@host2Где 5:5 — номер интерфейса на локальной машине и на удаленной соответственно. Здесь вас может смутить, что ifconfig не выдаст в списке интерфейса «tun5». Это потому что он в состоянии «down», а вот если вызвать «ifconfig -a» или «ifconfig tun5», то интерфейс будет виден:
host1# ifconfig tun5
tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Назначаем интерфейсам IP-адреса и поднимаем их:
host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101Если есть файрвол, не забываем разрешить соединения с интерфейса tun5:
host1# # сохраняем исходные правила файрвола
host1# sudo iptables-save > /tmp/iptables.rules.orig
host1# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT
host2# # сохраняем исходные правила файрвола
host2# sudo iptables-save > /tmp/iptables.rules.orig
host2# sudo iptables -I INPUT 1 -i tun5 -j ACCEPTНа host1 это делать необязательно, здесь это сделано лишь для того чтобы ping работал в обе стороны.
Наслаждаемся пингом:
host1# ping 192.168.150.102
host2# ping 192.168.150.101Если рассмотреть более ранний пример с PostgreSQL, то теперь схема будет такая:
А команда для подключения к серверу PostgreSQL будет выглядеть так:
host1# psql -h 192.168.150.102 -U postgresНу а далее можно делать какой-либо из этих узлов шлюзом, если нужно обеспечить доступ не к одному узлу, а к сети. Например:
host2# # разрешаем IP forwarding
host2# sudo sysctl -w net.ipv4.ip_forward=1
host2# # разрешаем IP forwarding с host1
host2# sudo iptables -I FORWARD 1 -s 192.168.150.101 -j ACCEPT
host2# # разрешаем IP forwarding на host1
host2# sudo iptables -I FORWARD 1 -d 192.168.150.101 -j ACCEPT
host2# # маскируем IP адрес host1
host2# sudo iptables -t nat -A POSTROUTING -s 192.168.150.101 -j MASQUERADEhost1# # Предположим, у host2 есть доступ к сети 192.168.2.x, куда нам нужно попасть с host1
host1# # Прописываем host2 как шлюз в сеть 192.168.2.x
host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2
host1# # Наслаждаемся доступом в сеть с host1
host1# ping 192.168.2.1После окончания работы не забываем вернуть net.ipv4.ip_forward и файрвол в исходное состояние.
host1# sudo iptables-restore < /tmp/iptables.rules.orig
host2# sudo iptables-restore < /tmp/iptables.rules.origДопустим, есть доступ по ssh с вашей рабочей машины host1 на сервер host2, с него — на host3, а уже оттуда — на нужный вам host4. Тогда делаем TCP forwarding для ssh (если с host1 вы сразу можете соединиться с host4, пропустите этот шаг):
host1# ssh -L 2222:localhost:2222 host2
host2# ssh -L 2222:host4:22 host3Далее, соединяемся с host4 и поднимаем интерфейс tun5:
host1# sudo ssh -p 2222 -w 5:5 root@localhost
host1# # или если host4 доступен сразу: sudo ssh -w 5:5 root@host4
host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host4# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101Смотрим таблицу маршрутизации на host4, допустим видим следующее:
host4# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5
192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.56.254 0.0.0.0 UG 0 0 0 eth0ВАЖНО! Далее нам скорее всего захочется сделать маршрутом по-умолчанию интерфейс tun5 со шлюзом 192.168.150.101, через который будет доступен Интернет. Поэтому на данном этапе важно точно знать, какие маршруты нужно дописать, чтобы заменить маршрут по-умолчанию. Это важно, поскольку довольно часто маршруты на отдельные сети не прописывают отдельно, а просто задают маршрут по-умолчанию (0.0.0.0/0) со шлюзом, через который и идет весь межсетевой трафик. Более того, вполне вероятно что ваше ssh-соединение с сервером также использует исходный шлюз по-умолчанию.
Для простоты в данном примере предположим, что никаких маршрутов кроме 192.168.56.0/24 серверу для нормального функционирования не нужно и что предыдущий ssh-хост host3 имеет IP-адрес из этой же сети.
Запоминаем и записываем куда-нибудь исходную маршрутную таблицу со шлюзом по-умолчанию:
host4# route -n > routes.origНастраиваем наш host1 для работы в качестве шлюза в Интернет для host4:
host1# # разрешаем IP forwarding
host1# sudo sysctl -w net.ipv4.ip_forward=1
host1# # сохраняем исходные правила файрвола
host1# sudo iptables-save > /tmp/iptables.rules.orig
host1# # разрешаем IP forwarding с host4
host1# sudo iptables -I FORWARD 1 -s 192.168.150.102 -j ACCEPT
host1# # разрешаем IP forwarding на host4
host1# sudo iptables -I FORWARD 1 -d 192.168.150.102 -j ACCEPT
host1# # маскируем IP адрес host4
host1# sudo iptables -t nat -A POSTROUTING -s 192.168.150.102 -j MASQUERADEsudo ip route add 192.168.0.0/16 via 192.168.56.254
sudo ip route add 10.0.0.0/8 via 192.168.56.254
sudo ip route add 172.16.0.0/12 via 192.168.56.254Изменяем маршрут по-умолчанию на host4 (ОСТОРОЖНО, см. предупреждение выше!):
host4# sudo ip route replace default via 192.168.150.101
host4# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5
192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.150.101 0.0.0.0 UG 0 0 0 tun5Если весь Интернет нам не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные нам адреса через шлюз на tun5.
Проверяем, что есть Интернет:
host4# ping 8.8.8.8Отлично. Осталось настроить DNS. Есть множество способов это сделать, проще всего отредактировать файл /etc/resolv.conf и добавить туда строчки:
nameserver 8.8.8.8
nameserver 8.8.4.4После этого Интернет должен быть полностью доступен:
host4# ping ya.ruПосле окончания работы не забываем вернуть все в исходное состояние:
host1# # восстанавливаем правила файрвола на host1
host1# sudo iptables-restore < /tmp/iptables.rules.orig
host1# # не забудьте восстановить также значение net.ipv4.ip_forwardhost2# # восстановите маршрут по-умолчанию на host4:
host2# sudo ip route replace default via 192.168.56.254
host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf6) Коротко о беспарольном доступе
Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу RSA:
1. На клиентских машинах генерируем пользователю свой ключ RSA:
client1# ssh-keygen -t rsaПо-умолчанию приватный ключ сохраняется в ~/.ssh/id_rsa, а открытый — в ~/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.
2. Клиентские открытые ключи нужно сохранить на ssh-сервере в файле ~/.ssh/authorized_keys (~ это домашняя директория того пользователя, которым будете логиниться), каждый на отдельной строке. Для того чтобы это не делать вручную, на каждом клиенте можно воспользоваться командой:
ssh-copy-id user@sshserverГде user — имя пользователя на сервере, sshserver — имя или IP-адрес ssh-сервера.
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с passphrase):
ssh user@sshserverРекомендую не закрывать хотя бы одну активную ssh-сессию с сервером до тех пор, пока окончательно не закончите настройку и не убедитесь что все работает.
4. Отключите на SSH-сервере возможность входа по паролю в файле /etc/ssh/sshd_config:
PasswordAuthentication noВозможность входа по открытому ключу обычно уже включена по-умолчанию:
PubkeyAuthentication yesЯ обычно также отключаю две следующие опции:
GSSAPIAuthentication no
UseDNS noВ некоторых случаях это позволяет ускорить процесс соединения (например, когда на сервере нет доступа в Интернет).
5. Перезапустите sshd:
service sshd restartили
/etc/init.d/ssh restartВ случае ошибок полезно бывает смотреть лог /var/log/secure либо использовать опции -v, -vv или -vvv для вывода детального лога соединения:
ssh -vvv user@sshserver7) Спасибо (ссылки)
help.ubuntu.com/community/SSH_VPN
habrahabr.ru/post/87197
blog.backslasher.net/ssh-openvpn-tunneling.html
Комментарии (73)
esvaf
21.06.2017 18:56+2Чтобы не чистить каждый раз список известных хостов от RSA fingerprint, особенно при обходе большого списка узлов скриптом удобно добавлять две опции:
-oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/nullПервая автоматом добавляет узел в известные, вторая использует заведомо пустой /dev/null как файл хранения RSA fingerprint, что позволяет избежать проблем с измененными ключами на старых ip, а так же замусориванием локального known_hosts. Работают данные опции как для ssh, так и для scp.
При использовании таких опций надо понимать, что будет пропущено предупреждение если ключ хоста изменился и, возможно, у вас проблемы. :)nitro2005
21.06.2017 20:22+2Спасибо. Думаю, это опасненько :)
Уж лучше каждому свое имя/порт назначать. И если что чистить через ssh-keygen -R…esvaf
26.06.2017 13:58Дело не в назначении своего имени и порта, а в обходе скриптом сотен типовых устройств, на которые не факт что уже заходили с данной машины и данного пользователя, либо наоборот, где-то на объектах устройства могли быть заменены либо переустановлены операционные системы. Итог — требования подтверждения каждого нового узла при попытке скрипта подключиться к нему, либо вообще ошибка если отпечаток изменился. Туннели ssh тут совсем не причем, просто предложил полезные опции для автоматизации действий.
BasilioCat
22.06.2017 14:49+1Такие опции будут выдавать Warning при подключении, если не указать -o LogLevel=ERROR. Ну и конечно, их можно не указывать каждый раз, а засунуть в конфиг — ~/.ssh/config:
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
LogLevel=ERROR
Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
ValdikSS
26.06.2017 20:03Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные.
Если такое случится, злоумышленник не просто сможет смотреть, что вы вводите в сессию, но и выполнять произвольные команды самостоятельно, до первого rekeying (где-то час).
sabio
21.06.2017 19:18+3Я бы ещё добавил, что при ручном создании ~/.ssh/authorized_keys и папке, и файлу нужно обязательно правильно выставить права доступа.
700 для .ssh и 600 для authorized_keys
В противном случае сервер будет считать их скомпрометированными и не позволит использовать ключ для доступа.
zimyx
21.06.2017 20:19А ещё в authorized_keys можно добавить ограничение по доступным шеллам для разных ключей, префиксировав их параметром
command=....или напримерenvironment=. Тогда при заходе в одного пользователя с использованием разных ключей можно получать различные эффекты вроде ограниченния на исполнение команд или установки переменных окружения.nitro2005
21.06.2017 20:34+1Да, также это можно добавить в /etc/ssh/sshd_config. Это уже тонкая настройка, мануал писать не хочется.
Можно еще наверное было бы описать возможности ~/.ssh/config на клиенте, не знаю нужно ли.
funca
21.06.2017 22:02Насколько помню, прокинуть переменные окружения через chain или же сделать доступ, когда у пользователя на разных машинках в цепочке логины отличаются это вполне себе квест.
MrFrizzy
21.06.2017 21:35+3Для tcp only можно использовать встроенное socs5 прокси — работает без оверхеда на сеть так как по-сути является динамическим порт форвардингом, то есть работает быстрее VPN решений на базе tun\tap:
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.
Пример использования:
ssh -C2qTnN -D 3128 <host>
apple01
21.06.2017 22:00Для интересующихся, есть продукт для удаленного доступа реализующий описанные методы ssh tunneling.
http://sshmaster.com/ru/nitro2005
21.06.2017 23:39Сильно лучше VNC? Порты VNC тоже можно прокинуть.
Я вот все ищу какую-то альтернативу VNC, уж больно оно глюкавое и тормозное.apple01
21.06.2017 23:45собственно как в вашей статье написано, предоставляется ssh туннель, а поверх уже запускаете что вам нравится, VNC, RDP, HTTP и т.п. с разделением доступа. VNC тормозное но иногда имеет преимущества перед RDP, например можно вдвоем смотреть удаленный экран. RDP в плане удаленного экрана быстрее.
noRoman
21.06.2017 23:35+1при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить)
по этому поводу я все же соглашусь с комментарием в статье Оправданно ли размещение SSH на порту, отличном от 22?. Особенно со всякими пробросами можно запутаться что и куда смотрит.nitro2005
21.06.2017 23:41Возможно, если парк большой. Хотя и в этом случае можно унифицировать.
Просто одно дело стукнуться в 22 порт и увидеть что он закрыт, а другое — просканировать какой-то диапазон портов в поисках SSH.aol-nnov
22.06.2017 00:11+3похоже на мнение админов локалхоста, чесслово. если всё(!) адресное пространство ipv4 можно просканить, если мне не изменяет память, за сорок пять минут (см. zmap.io), то уж просканить 65к портов на хосте не составит труда.
перевес ссш на кастомный порт — это даже не security by obscurity. это еще печальнееKroid
22.06.2017 09:16Подавляющее большинство дверных замков профессионал вскроет за пару минут. Тем не менее, выходя из квартиры, люди закрывают дверь на ключ. Скажете, они просто зря тратят время?
aol-nnov
22.06.2017 09:18+1именно! запирают дверь на ключ, а не переносят замочную скважину в левый нижний угол двери… или по центру, вместо глазка.
nitro2005
22.06.2017 10:03+1Я бы выбрал другую аналогию :)
SSH на стандартном порту — это когда на двери кабинета табличка «сейф тут». И так в 99% зданий.
На нестандартном — это когда вам нужно пройти 20-30 этажей, обсмотреть все или часть дверей по пути, и те которые не закрыты — открыть, чтобы проверить, нет ли там сейфа.
Понятно, что вы бегаете быстро, но все же, усилия и ресурсы разные.
MaxLevs
24.06.2017 13:58Согласен. Профессиональный бегун проделает это "за пять минут". Большенству других же будет просто "в лом".
opxocc
22.06.2017 09:38SSH на нестандартном порте это не «security by obscurity», а отличный способ воспользоваться тем-же SOCKS прокси для доступа к «запрещенным» портам находясь за корпоративным прокси или пользуясь бесплатным wifi в кафе/гостинице, где закрыто всё наглухо кроме 80/443 портов, тогда ssh вешается на 443 порт и вуаля! :) Лет 10 уже пользуюсь этим трюком для обхода параноидальных настроек сети в различных организациях где приходилось работать.
Vindicar
22.06.2017 10:41+1Поспорю с вами.
По-моему скромному опыту (админ локалхоста, да), после регистрации VPS китайские боты начали стучаться на 22 порт менее чем через час, заспамливая лог. После смены порта SSH как отрезало.
Конечно, от целенаправленных действий (да хотя бы того же nmap) этот приём не спасёт. Но боты, похоже, как раз не заморачиваются — тупо ломятся на 22 порт, и если есть отклик — начинают брутить.
Я согласен с вами в том, что сама по себе смена порта категорически недостаточна. Нужна авторизация по ключу вместо пароля, fail2ban, и т.д. Но в дополнение к другим мерам — вполне себе полезно. Как минимум меньше шансов проглядеть целенаправленную атаку на ваш хост в толпе любителей сканировать весь IPv4.
Lennonenko
27.06.2017 22:50ну, вы не совсем правы
22 порт на белом адресе прощупывается даже не регулярно, а постоянно
можно, конечно, fail2ban настроить, а можно перенести ssh на 2222 и сократить количество auth-логов на порядки
ну и fail2ban оставить настроеннымnitro2005
27.06.2017 22:52+ можно сечь скан портов (> N TCP SYN запросов на разные порты с одного адреса) и банить негодяев еще до того как они досканят до XXX22 порта :)
apple01
22.06.2017 00:19Если доступ при помощи ключа то на мой взгяд не имеет смысла прятать порт, разницы почти нет с точки зрения безопасности. Для тунеллирования других протоколов я выбираю обычно какой-нибудь другой порт, например 6022, просто для того чтобы не путать с 22м. Чтобы не путаться что и куда смотрит, мы сделали SSH Master, туда же добавили права доступа и прочие полезные опции.
Pilat
22.06.2017 00:50+1ProxyCommand — @amarao писал об этом, вот более подробный пример, чтобы не делать вышеописанные ужасы типа host1->host2->host3->host4:
.ssh/config:
Host ruapehu HostName ruapehu.example.com Host aoraki ProxyCommand ssh -q ruapehu nc -q0 aoraki 22 Host tongariro ProxyCommand ssh -q aoraki nc -q0 %h 22
arteast
22.06.2017 05:20+1Упрощение номер раз — ssh -W делает то же, что ssh nc, но без nc
Упрощение номер два (правда, только для свежих 7.3+) — опция ProxyJump в ssh_config или -J в командной строке делают то же самое, но еще более читабельным образом. Ей можно указывать список серверов, и тогда она их пройдет по очереди (т.е. можно не писать отдельные параметры для каждого прокси-хопа, если они не представляют самостоятельного интереса)
nitro2005
22.06.2017 10:31Спасибо, я пока с этой опцией не разобрался.
Пока не дорос до полноценного использования ~/.ssh/config, к сожалению :( не знаю, лень это или иррационализм какой :-D
bormental
22.06.2017 16:57Есть еще из той же оперы полезный lifehack для .ssh/config. Пользуюсь очень давно, но, кажется, был утащен с вики Arch.
# Jump-host trick Host *+* ProxyCommand ssh $(echo %h | sed 's/+[^+]*$//;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/;s/:/ -p /') nc $(echo %h | sed 's/^.*+//;/:/!s/$/ %p/;s/:/ /')
Да, он использует nc. Но в результате можно не прописывать алиасы для многих хостов за входным jump-host, а доступаться к ним так:
ssh gateway+host1 ssh gateway+host2 ssh gateway+host1+host2+host3
Т.е. через + любую цепочку можно организовать динамически. Я так часто пользуюсь, например, для доступа к виртуалкам.
stychos
22.06.2017 01:46Как-то был случай, когда машина с беспарольным доступом после обновления потеряла сеть. Соответственно, через квм не зайти (сделано passwd -l), по сети не зайти, с загрузчика пароль не сбить (шифровано). В итоге переустановить систему оказалось проще, благо машина была частью кластера и потеря данных не грозила.
viiy
22.06.2017 14:48В таком случае зайти все же можно
В grub-e находите строку с ядром, добавляете в конец init=/bin/bash сразу загружаетесь без выхода в меню
Получаете полный доступ, возможно потребуется перемонтировать fs в режим write
P.S не внимательно прочитал про шифрование
Тогда увы никак
Dreyk
22.06.2017 07:44+1я вот себе тоже сделал
PasswordAuthentication no
а потом чтобы добавить новый ключ с новой машины ssh-copy-id уже не прокатит. хорошо что это был локальный роутер и там был telnetnitro2005
22.06.2017 09:44Я если делаю беспарольный доступ, то как минимум с двух-трех машин, чтобы доступ у меня всегда был, независимо от того где я (ноутбук рулит).
MasMaX
22.06.2017 09:03Чтобы не запоминать все команды рекомендую графическую утилитку «Gnome SSH Tunnel Manager» (gSTM). Все тоннели настраиваются в два клика.
Crystal_HMR
22.06.2017 09:30+1а потом в какой-то момент нужно сделать всё тоже самое, но без иксов, а ты умеешь только в два клика.
Ну и да, зубрить команды не нужно. Нужно помнить, что такое возможно, и знать, где прочитать.
psycho-coder
22.06.2017 10:08Касательно спойлера в 5 пункте:
Я правильно понял, что нам нужно на конкретный ip указать наш шлюз с tun5, если уже есть 0.0.0.0/0? Иначе мы можем положить всю сеть?nitro2005
22.06.2017 10:09Да, если вам весь Интернет не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные вам адреса через шлюз на tun5.
Вероятность положить часть сети на сервере при изменении маршрута по-умолчанию есть, включая ваше ssh-соединение. Об этом и написано предупреждение.
caban
22.06.2017 12:45Я бы ещё добавил про полезную утилиту ssh-keyscan, с помощью которой можно автомазировать добавление fingerprint в known_hosts.
varnav
22.06.2017 14:42При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.
И зашифрован он будет плохо.
Используйте ключ -o
delvin-fil
23.06.2017 08:11Автор, позвольте, а разве в FAQ к SSH не тоже самое написано? Да, не буду спорить, иными словами, но…
nitro2005
23.06.2017 09:16Буду благодарен за ссылку :)
delvin-fil
23.06.2017 09:59Вы издеваетесь? вот же
Почти то же самое, что вы изложили на русском.nitro2005
23.06.2017 10:05Я наверное слепой?
http://www.snailbook.com/faq/gatewayports.auto.html
Вы серьезно? Это все что там написано по теме «TCP port forwarding».delvin-fil
23.06.2017 10:58Нет, вы не слепой — кто-то планомерно убирает инфу.
Только что по вебархиву пробежался — нет о форвардинге ничего. Но было. Не мог же я придумать:)
ninetailedfirefox
23.06.2017 15:20Доброго вечера) а может кто-то подсказать как организовать соединение вида: SSH server(фиксированный IP, Nat)<=SSH Client=>RDP Server
Цель: подключение RDP клиентом к SSH server, и попадание на RDP сервер. (заранее предположим что пробросы уже сделаны) как выполнить такой проброс с SSH Client'a одним скриптом?nitro2005
23.06.2017 15:23ssh -R 3389:RDPserver:3389 user@SSHserver
При этом порт 3389 на SSHserver должен быть свободен, если нет — тогда надо использовать другой свободный:
ssh -R 9999:RDPserver:3389 user@SSHserver и его указать в RDP-клиенте
Dorlas
23.06.2017 16:18Для тех, кто еще не пробовал или просто не сталкивался — рекомендую попробовать проект: Duo Secyrity.
На 10 устройств/учетных записей бесплатен.
Позволит просто реализовать двух-факторную аутентификацию на Ваш SSH-сервер и входить, используя RSA-ключ + Push на сотовом телефоне. Плюс в Push сообщении видно IP-адрес входящего.
Удобная вещь — за почти год использования не подводила ни разу пока что.
saipr
27.06.2017 09:56Хорошая статья. А еще есть SSH на базе российской криптографии.
nitro2005
27.06.2017 10:46Чего-то там все начинается с длины ключа 512 бит… Толи это что-то очень старое, толи специально ослабленное))
hostmaster
27.06.2017 12:35Для еще одно малоизвестного факта о SSH/SCP загляните в описание опции
-3в документацииman scp
maxifree
27.06.2017 17:06Для простой организации VPN через ssh можно использовать sshuttle. Используются iptables и python на локальной машине и только python на удаленной, без рута. UDP к сожалению не поддерживает. https://github.com/apenwarr/sshuttle
LESHIY_ODESSA
28.06.2017 15:17-1Для «беспарольного» входа под Windows использую аргумент -pw.
Например —putty.exe -pw пароль root@10.1.2.1(создаю ярлык). Где root это имя пользователя.
Очень может помочь, когда нет времени вводить пароль, а нужно в течении пары секунд войти в BOOT.
Также в статье не упоминается «магия» с файлом команд. Например, чтобы не выполнять рутинные операции по перезагрузке и так далее, создаем ярлык и нажатием одной кнопки упрощаем себе жизнь.
putty.exe -pw password root@10.1.1.1 -m script.mikrotik.restart-samba.txt
DeXPeriX
Спасибо. С беспарольным доступом раньше было лень разбираться для домашних машинок (тех же виртуалок). Теперь вижу, что всё очень не сложно.