Comments 75

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

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

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

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


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

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

Да, также это можно добавить в /etc/ssh/sshd_config. Это уже тонкая настройка, мануал писать не хочется.
Можно еще наверное было бы описать возможности ~/.ssh/config на клиенте, не знаю нужно ли.
Насколько помню, прокинуть переменные окружения через chain или же сделать доступ, когда у пользователя на разных машинках в цепочке логины отличаются это вполне себе квест.
Для 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>
Спасибо. Только для этого само приложение должно поддерживать протокол SOCKS, ведь так?
Для Win/OSX есть Proxifier, который вообще хукается в tcp стек и прозрачно проксирует вообще любые приложения через SOCKS в том числе
Для интересующихся, есть продукт для удаленного доступа реализующий описанные методы ssh tunneling.
http://sshmaster.com/ru/
Сильно лучше VNC? Порты VNC тоже можно прокинуть.
Я вот все ищу какую-то альтернативу VNC, уж больно оно глюкавое и тормозное.
собственно как в вашей статье написано, предоставляется ssh туннель, а поверх уже запускаете что вам нравится, VNC, RDP, HTTP и т.п. с разделением доступа. VNC тормозное но иногда имеет преимущества перед RDP, например можно вдвоем смотреть удаленный экран. RDP в плане удаленного экрана быстрее.
Возможно, если парк большой. Хотя и в этом случае можно унифицировать.
Просто одно дело стукнуться в 22 порт и увидеть что он закрыт, а другое — просканировать какой-то диапазон портов в поисках SSH.
похоже на мнение админов локалхоста, чесслово. если всё(!) адресное пространство ipv4 можно просканить, если мне не изменяет память, за сорок пять минут (см. zmap.io), то уж просканить 65к портов на хосте не составит труда.

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

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

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

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

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

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

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

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

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

UFO landed and left these words here
UFO landed and left these words here
В таком случае зайти все же можно
В grub-e находите строку с ядром, добавляете в конец init=/bin/bash сразу загружаетесь без выхода в меню
Получаете полный доступ, возможно потребуется перемонтировать fs в режим write

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

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


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

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


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

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

ssh -R 3389:RDPserver:3389 user@SSHserver
При этом порт 3389 на SSHserver должен быть свободен, если нет — тогда надо использовать другой свободный:
ssh -R 9999:RDPserver:3389 user@SSHserver и его указать в RDP-клиенте
Для тех, кто еще не пробовал или просто не сталкивался — рекомендую попробовать проект: Duo Secyrity.
На 10 устройств/учетных записей бесплатен.

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

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

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

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

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

Магия? Магией называют то что не имеет объяснения научным эмпиризмом, т.е как правило это понятие (магия) или ощущение «магичности» употребляется, когда нет знаний.
Для «беспарольного» входа под 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
Самая главная вещь в беспарольном доступе — понять как автоматически обнулять ключи для уволенных сотрудников. Вот я так и не сообразил как.
Only those users with full accounts are able to leave comments. Log in, please.