Магия SSH

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

    Оглавление:

    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:

    image

    Имеем удаленный сервер «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

    Если на «host1» Windows
    Например, в PuTTy это делается так:
    Идем по дереву настроек: Connection → SSH → Tunnels.
    Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, и нажимаем Add.
    Не забываем после этого сохранить настройки сессии, если требуется.
    image

    Как это работает
    После успешного подключения к SSH-серверу на «host2», на «host1» SSH-клиент начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-сервер на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-клиентом на «host1» на порт 9999.
    ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).

    Настройка SSH-сервера
    Port forwarding, как правило, уже включен в настройках sshd по-умолчанию.
    /etc/ssh/sshd_config:
    AllowTcpForwarding yes

    Мы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:

    image

    Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:

    host1# ssh -L 9999:host3:5432 host2

    Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».

    Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:

    image

    Для этого нужно вставить в команду соединения 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:

    image

    Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:

    ssh -R 9999:localhost:5432 host1

    Если на «host2» Windows
    Например, в PuTTy это делается так:
    Идем по дереву настроек: Connection → SSH → Tunnels.
    Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.
    Не забываем после этого сохранить настройки сессии, если требуется.

    image

    Как это работает
    После успешного подключения, на «host1» SSH-сервер начинает слушать порт 9999. При подключении к порту 9999 на «host1», SSH-клиент на «host2» устанавливает соединение с localhost (коим и является для себя самого «host2») на порт 5432 и передает по этому соединению данные, принятые ssh-сервером на «host1» на порт 9999.

    Также у вас возникнут дополнительные сложности с обеспечением безопасности на «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 по цепочке:

    image

    Здесь порты 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-серверов (см. предыдущую главу). Теперь мы обладаем нужными знаниями чтобы сделать следующее:

    image

    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 большого уровня вложенности.

    Замечания про RSA fingerprint
    В некоторых случаях scp не отработает, пока не зайдете сначала через ssh -p 2222 localhost и не примете RSA fingerprint удаленного сервера.

    Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из ~/.ssh/known_hosts.

    5) SSH VPN Tunnel


    TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.

    Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.

    Еще про TCP forwarding
    А вот TCP port forwarding с помощью SSH, если его достаточно, во многих случаях выиграет по производительности у VPN, т. к. при TCP port forwarding передаются только данные приложения, а не исходные пакеты целиком вместе с заголовками, см. ссылку: http://blog.backslasher.net/ssh-openvpn-tunneling.html

    Настройка 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, то теперь схема будет такая:

    image

    А команда для подключения к серверу 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 MASQUERADE


    host1# # Предположим, у 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-сервер или цепочку ssh-серверов. Предположим, для настройки сервера вам нужен на нем доступ в Интернет. Тогда проще самостоятельно настроить временный доступ в Интернет на требующем настройки сервере, чем просить это сделать обслуживающий персонал.

    Допустим, есть доступ по 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 MASQUERADE


    На всякий случай можно прописать серые сети на шлюз из текущего маршрута по-умолчанию
    Если не прописаны:
    sudo 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_forward


    host2# # восстановите маршрут по-умолчанию на host4:
    host2# sudo ip route replace default via 192.168.56.254
    host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf


    6) Коротко о беспарольном доступе


    Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу 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-сервера.
    Права на файл ~/.ssh/authorized_keys
    UPD от sabio: В случае ручного создания файла ~/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
    chmod 0700 ~/.ssh
    chmod 0600 ~/.ssh/authorized_keys



    3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с 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@sshserver

    7) Спасибо (ссылки)


    help.ubuntu.com/community/SSH_VPN
    habrahabr.ru/post/87197
    blog.backslasher.net/ssh-openvpn-tunneling.html
    Поделиться публикацией

    Похожие публикации

    Комментарии 78
      +1

      Спасибо. С беспарольным доступом раньше было лень разбираться для домашних машинок (тех же виртуалок). Теперь вижу, что всё очень не сложно.

        +13
        На хабре есть очень хорошая статья про ssh от amarao
          0
          Спасибо, не видел! Отличная статья!
            0
            Благодарю вас, очень полезная статья!
          +2
          Чтобы не чистить каждый раз список известных хостов от RSA fingerprint, особенно при обходе большого списка узлов скриптом удобно добавлять две опции:
          -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null
          Первая автоматом добавляет узел в известные, вторая использует заведомо пустой /dev/null как файл хранения RSA fingerprint, что позволяет избежать проблем с измененными ключами на старых ip, а так же замусориванием локального known_hosts. Работают данные опции как для ssh, так и для scp.
          При использовании таких опций надо понимать, что будет пропущено предупреждение если ключ хоста изменился и, возможно, у вас проблемы. :)
            +2
            Спасибо. Думаю, это опасненько :)
            Уж лучше каждому свое имя/порт назначать. И если что чистить через ssh-keygen -R…
              0
              Дело не в назначении своего имени и порта, а в обходе скриптом сотен типовых устройств, на которые не факт что уже заходили с данной машины и данного пользователя, либо наоборот, где-то на объектах устройства могли быть заменены либо переустановлены операционные системы. Итог — требования подтверждения каждого нового узла при попытке скрипта подключиться к нему, либо вообще ошибка если отпечаток изменился. Туннели ssh тут совсем не причем, просто предложил полезные опции для автоматизации действий.
              +1
              Такие опции будут выдавать Warning при подключении, если не указать -o LogLevel=ERROR. Ну и конечно, их можно не указывать каждый раз, а засунуть в конфиг — ~/.ssh/config:
              StrictHostKeyChecking=no
              UserKnownHostsFile=/dev/null
              LogLevel=ERROR

              Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
                0
                Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные.
                Если такое случится, злоумышленник не просто сможет смотреть, что вы вводите в сессию, но и выполнять произвольные команды самостоятельно, до первого rekeying (где-то час).
              +3

              Я бы ещё добавил, что при ручном создании ~/.ssh/authorized_keys и папке, и файлу нужно обязательно правильно выставить права доступа.
              700 для .ssh и 600 для authorized_keys


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

                0
                Спасибо, добавил.
                0

                А ещё в authorized_keys можно добавить ограничение по доступным шеллам для разных ключей, префиксировав их параметром command=.... или например environment=. Тогда при заходе в одного пользователя с использованием разных ключей можно получать различные эффекты вроде ограниченния на исполнение команд или установки переменных окружения.

                  +1
                  Да, также это можно добавить в /etc/ssh/sshd_config. Это уже тонкая настройка, мануал писать не хочется.
                  Можно еще наверное было бы описать возможности ~/.ssh/config на клиенте, не знаю нужно ли.
                    0
                    Насколько помню, прокинуть переменные окружения через chain или же сделать доступ, когда у пользователя на разных машинках в цепочке логины отличаются это вполне себе квест.
                  +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>
                  
                    0
                    Спасибо. Только для этого само приложение должно поддерживать протокол SOCKS, ведь так?
                      +1
                      совершенно необязательно! см. tsocks, например
                        0

                        polipo превращает socks-прокси в http-прокси

                          0
                          Для Win/OSX есть Proxifier, который вообще хукается в tcp стек и прозрачно проксирует вообще любые приложения через SOCKS в том числе
                        0
                        Для интересующихся, есть продукт для удаленного доступа реализующий описанные методы ssh tunneling.
                        http://sshmaster.com/ru/
                          0
                          Сильно лучше VNC? Порты VNC тоже можно прокинуть.
                          Я вот все ищу какую-то альтернативу VNC, уж больно оно глюкавое и тормозное.
                            0
                            собственно как в вашей статье написано, предоставляется ssh туннель, а поверх уже запускаете что вам нравится, VNC, RDP, HTTP и т.п. с разделением доступа. VNC тормозное но иногда имеет преимущества перед RDP, например можно вдвоем смотреть удаленный экран. RDP в плане удаленного экрана быстрее.
                              +1

                              посмотрите в сторону x2go

                                0
                                Спасибо, обязательно изучу.
                            +1
                            при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить)

                            по этому поводу я все же соглашусь с комментарием в статье Оправданно ли размещение SSH на порту, отличном от 22?. Особенно со всякими пробросами можно запутаться что и куда смотрит.
                              0
                              Возможно, если парк большой. Хотя и в этом случае можно унифицировать.
                              Просто одно дело стукнуться в 22 порт и увидеть что он закрыт, а другое — просканировать какой-то диапазон портов в поисках SSH.
                                +3
                                похоже на мнение админов локалхоста, чесслово. если всё(!) адресное пространство ipv4 можно просканить, если мне не изменяет память, за сорок пять минут (см. zmap.io), то уж просканить 65к портов на хосте не составит труда.

                                перевес ссш на кастомный порт — это даже не security by obscurity. это еще печальнее
                                  0
                                  Подавляющее большинство дверных замков профессионал вскроет за пару минут. Тем не менее, выходя из квартиры, люди закрывают дверь на ключ. Скажете, они просто зря тратят время?
                                    +1
                                    именно! запирают дверь на ключ, а не переносят замочную скважину в левый нижний угол двери… или по центру, вместо глазка.
                                      +1
                                      Я бы выбрал другую аналогию :)
                                      SSH на стандартном порту — это когда на двери кабинета табличка «сейф тут». И так в 99% зданий.
                                      На нестандартном — это когда вам нужно пройти 20-30 этажей, обсмотреть все или часть дверей по пути, и те которые не закрыты — открыть, чтобы проверить, нет ли там сейфа.
                                      Понятно, что вы бегаете быстро, но все же, усилия и ресурсы разные.
                                        0

                                        Согласен. Профессиональный бегун проделает это "за пять минут". Большенству других же будет просто "в лом".

                                    0
                                    SSH на нестандартном порте это не «security by obscurity», а отличный способ воспользоваться тем-же SOCKS прокси для доступа к «запрещенным» портам находясь за корпоративным прокси или пользуясь бесплатным wifi в кафе/гостинице, где закрыто всё наглухо кроме 80/443 портов, тогда ssh вешается на 443 порт и вуаля! :) Лет 10 уже пользуюсь этим трюком для обхода параноидальных настроек сети в различных организациях где приходилось работать.
                                      +1
                                      Поспорю с вами.
                                      По-моему скромному опыту (админ локалхоста, да), после регистрации VPS китайские боты начали стучаться на 22 порт менее чем через час, заспамливая лог. После смены порта SSH как отрезало.
                                      Конечно, от целенаправленных действий (да хотя бы того же nmap) этот приём не спасёт. Но боты, похоже, как раз не заморачиваются — тупо ломятся на 22 порт, и если есть отклик — начинают брутить.
                                      Я согласен с вами в том, что сама по себе смена порта категорически недостаточна. Нужна авторизация по ключу вместо пароля, fail2ban, и т.д. Но в дополнение к другим мерам — вполне себе полезно. Как минимум меньше шансов проглядеть целенаправленную атаку на ваш хост в толпе любителей сканировать весь IPv4.
                                        0
                                        У меня также. От таких ботов и защита в первую очередь. Понятно что если человек захочет сломать сервер, то он будет сканировать все порты.
                                        0
                                        ну, вы не совсем правы
                                        22 порт на белом адресе прощупывается даже не регулярно, а постоянно
                                        можно, конечно, fail2ban настроить, а можно перенести ssh на 2222 и сократить количество auth-логов на порядки
                                        ну и fail2ban оставить настроенным
                                          0
                                          + можно сечь скан портов (> N TCP SYN запросов на разные порты с одного адреса) и банить негодяев еще до того как они досканят до XXX22 порта :)
                                      0
                                      Если доступ при помощи ключа то на мой взгяд не имеет смысла прятать порт, разницы почти нет с точки зрения безопасности. Для тунеллирования других протоколов я выбираю обычно какой-нибудь другой порт, например 6022, просто для того чтобы не путать с 22м. Чтобы не путаться что и куда смотрит, мы сделали SSH Master, туда же добавили права доступа и прочие полезные опции.
                                      +1

                                      ProxyCommand — @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
                                      
                                        +1

                                        Упрощение номер раз — ssh -W делает то же, что ssh nc, но без nc
                                        Упрощение номер два (правда, только для свежих 7.3+) — опция ProxyJump в ssh_config или -J в командной строке делают то же самое, но еще более читабельным образом. Ей можно указывать список серверов, и тогда она их пройдет по очереди (т.е. можно не писать отдельные параметры для каждого прокси-хопа, если они не представляют самостоятельного интереса)

                                          0
                                          Спасибо, я пока с этой опцией не разобрался.

                                          Пока не дорос до полноценного использования ~/.ssh/config, к сожалению :( не знаю, лень это или иррационализм какой :-D
                                            0

                                            Есть еще из той же оперы полезный 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
                                            

                                            Т.е. через + любую цепочку можно организовать динамически. Я так часто пользуюсь, например, для доступа к виртуалкам.

                                              0

                                              Спасибо. Вооружился.

                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Так тут проблема не в беспарольном доступе, а в passwd -l :)
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                В таком случае зайти все же можно
                                                В grub-e находите строку с ядром, добавляете в конец init=/bin/bash сразу загружаетесь без выхода в меню
                                                Получаете полный доступ, возможно потребуется перемонтировать fs в режим write

                                                P.S не внимательно прочитал про шифрование
                                                Тогда увы никак
                                                +1
                                                я вот себе тоже сделал
                                                PasswordAuthentication no
                                                а потом чтобы добавить новый ключ с новой машины ssh-copy-id уже не прокатит. хорошо что это был локальный роутер и там был telnet
                                                  0
                                                  Я если делаю беспарольный доступ, то как минимум с двух-трех машин, чтобы доступ у меня всегда был, независимо от того где я (ноутбук рулит).
                                                  0
                                                    0
                                                    Чтобы не запоминать все команды рекомендую графическую утилитку «Gnome SSH Tunnel Manager» (gSTM). Все тоннели настраиваются в два клика.
                                                      +1

                                                      а потом в какой-то момент нужно сделать всё тоже самое, но без иксов, а ты умеешь только в два клика.


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

                                                      0
                                                      Касательно спойлера в 5 пункте:
                                                      Я правильно понял, что нам нужно на конкретный ip указать наш шлюз с tun5, если уже есть 0.0.0.0/0? Иначе мы можем положить всю сеть?
                                                        0
                                                        Да, если вам весь Интернет не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные вам адреса через шлюз на tun5.
                                                        Вероятность положить часть сети на сервере при изменении маршрута по-умолчанию есть, включая ваше ssh-соединение. Об этом и написано предупреждение.
                                                        0
                                                        Я бы ещё добавил про полезную утилиту ssh-keyscan, с помощью которой можно автомазировать добавление fingerprint в known_hosts.
                                                          0
                                                          При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.


                                                          И зашифрован он будет плохо.
                                                          Используйте ключ -o
                                                            0
                                                            Автор, позвольте, а разве в FAQ к SSH не тоже самое написано? Да, не буду спорить, иными словами, но…
                                                              0
                                                              Буду благодарен за ссылку :)
                                                                0
                                                                Вы издеваетесь? вот же
                                                                Почти то же самое, что вы изложили на русском.
                                                                  0
                                                                  Я наверное слепой?
                                                                  http://www.snailbook.com/faq/gatewayports.auto.html
                                                                  Вы серьезно? Это все что там написано по теме «TCP port forwarding».
                                                                    0
                                                                    Нет, вы не слепой — кто-то планомерно убирает инфу.
                                                                    Только что по вебархиву пробежался — нет о форвардинге ничего. Но было. Не мог же я придумать:)
                                                              0

                                                              Доброго вечера) а может кто-то подсказать как организовать соединение вида: SSH server(фиксированный IP, Nat)<=SSH Client=>RDP Server
                                                              Цель: подключение RDP клиентом к SSH server, и попадание на RDP сервер. (заранее предположим что пробросы уже сделаны) как выполнить такой проброс с SSH Client'a одним скриптом?

                                                                0
                                                                ssh -R 3389:RDPserver:3389 user@SSHserver
                                                                При этом порт 3389 на SSHserver должен быть свободен, если нет — тогда надо использовать другой свободный:
                                                                ssh -R 9999:RDPserver:3389 user@SSHserver и его указать в RDP-клиенте
                                                                  0

                                                                  Спасибо) огромное человеческое)

                                                                0
                                                                Для тех, кто еще не пробовал или просто не сталкивался — рекомендую попробовать проект: Duo Secyrity.
                                                                На 10 устройств/учетных записей бесплатен.

                                                                Позволит просто реализовать двух-факторную аутентификацию на Ваш SSH-сервер и входить, используя RSA-ключ + Push на сотовом телефоне. Плюс в Push сообщении видно IP-адрес входящего.

                                                                Удобная вещь — за почти год использования не подводила ни разу пока что.
                                                                  0
                                                                  Спасибо. Хорошая статья.
                                                                    0

                                                                    Особенно порадовала нагладность и доступность.
                                                                    В статье от amarao фитч описано хоть и больше, но не так понятно. Лично у меня после начала чтения про forwarding начали слегка скрипеть мозги.

                                                                    0

                                                                    Хорошая статья. А еще есть SSH на базе российской криптографии.

                                                                      0
                                                                      Чего-то там все начинается с длины ключа 512 бит… Толи это что-то очень старое, толи специально ослабленное))
                                                                        0
                                                                        Ну вы же должны понимать, что не все короткое — плохое. Если мне не изменяет память, то в ГОСТ Р 34.10-2012 используется эллиптическая криптография. Там длины ключей меньше, при той же криптостойкости.

                                                                        P.S. Ни капли не агитирую использовать его.
                                                                      0
                                                                      Просто оставлю это здесь.
                                                                      https://habrahabr.ru/post/122445/
                                                                        0

                                                                        Для еще одно малоизвестного факта о SSH/SCP загляните в описание опции -3 в документации man scp

                                                                          0

                                                                          Для простой организации VPN через ssh можно использовать sshuttle. Используются iptables и python на локальной машине и только python на удаленной, без рута. UDP к сожалению не поддерживает. https://github.com/apenwarr/sshuttle

                                                                            0
                                                                            Магия? Магией называют то что не имеет объяснения научным эмпиризмом, т.е как правило это понятие (магия) или ощущение «магичности» употребляется, когда нет знаний.
                                                                              0
                                                                              Собственно, никто с этим и не спорит;)
                                                                              –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
                                                                                0
                                                                                Самая главная вещь в беспарольном доступе — понять как автоматически обнулять ключи для уволенных сотрудников. Вот я так и не сообразил как.
                                                                                  0
                                                                                  Удалить его ключ с сервера?
                                                                                  0
                                                                                  Офигеннейшая статья! Спасибо!

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

                                                                                  Самое читаемое