Комментарии 75
Спасибо. С беспарольным доступом раньше было лень разбираться для домашних машинок (тех же виртуалок). Теперь вижу, что всё очень не сложно.
-oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null
Первая автоматом добавляет узел в известные, вторая использует заведомо пустой /dev/null как файл хранения RSA fingerprint, что позволяет избежать проблем с измененными ключами на старых ip, а так же замусориванием локального known_hosts. Работают данные опции как для ssh, так и для scp.При использовании таких опций надо понимать, что будет пропущено предупреждение если ключ хоста изменился и, возможно, у вас проблемы. :)
Уж лучше каждому свое имя/порт назначать. И если что чистить через ssh-keygen -R…
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
LogLevel=ERROR
Что касается возможного MiTM — ну на сервере в консоли как правило не вводят конфиденциальные данные. А вот проброшенный SSH-агент (ForwardAgent=yes) может представлять интерес для такой атаки
Я бы ещё добавил, что при ручном создании ~/.ssh/authorized_keys и папке, и файлу нужно обязательно правильно выставить права доступа.
700 для .ssh и 600 для authorized_keys
В противном случае сервер будет считать их скомпрометированными и не позволит использовать ключ для доступа.
А ещё в authorized_keys можно добавить ограничение по доступным шеллам для разных ключей, префиксировав их параметром command=....
или например environment=
. Тогда при заходе в одного пользователя с использованием разных ключей можно получать различные эффекты вроде ограниченния на исполнение команд или установки переменных окружения.
Можно еще наверное было бы описать возможности ~/.ssh/config на клиенте, не знаю нужно ли.
-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>
http://sshmaster.com/ru/
Я вот все ищу какую-то альтернативу VNC, уж больно оно глюкавое и тормозное.
посмотрите в сторону x2go
при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить)
по этому поводу я все же соглашусь с комментарием в статье Оправданно ли размещение SSH на порту, отличном от 22?. Особенно со всякими пробросами можно запутаться что и куда смотрит.
Просто одно дело стукнуться в 22 порт и увидеть что он закрыт, а другое — просканировать какой-то диапазон портов в поисках SSH.
перевес ссш на кастомный порт — это даже не security by obscurity. это еще печальнее
SSH на стандартном порту — это когда на двери кабинета табличка «сейф тут». И так в 99% зданий.
На нестандартном — это когда вам нужно пройти 20-30 этажей, обсмотреть все или часть дверей по пути, и те которые не закрыты — открыть, чтобы проверить, нет ли там сейфа.
Понятно, что вы бегаете быстро, но все же, усилия и ресурсы разные.
По-моему скромному опыту (админ локалхоста, да), после регистрации VPS китайские боты начали стучаться на 22 порт менее чем через час, заспамливая лог. После смены порта SSH как отрезало.
Конечно, от целенаправленных действий (да хотя бы того же nmap) этот приём не спасёт. Но боты, похоже, как раз не заморачиваются — тупо ломятся на 22 порт, и если есть отклик — начинают брутить.
Я согласен с вами в том, что сама по себе смена порта категорически недостаточна. Нужна авторизация по ключу вместо пароля, fail2ban, и т.д. Но в дополнение к другим мерам — вполне себе полезно. Как минимум меньше шансов проглядеть целенаправленную атаку на ваш хост в толпе любителей сканировать весь IPv4.
22 порт на белом адресе прощупывается даже не регулярно, а постоянно
можно, конечно, fail2ban настроить, а можно перенести ssh на 2222 и сократить количество auth-логов на порядки
ну и fail2ban оставить настроенным
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
Т.е. через + любую цепочку можно организовать динамически. Я так часто пользуюсь, например, для доступа к виртуалкам.
В grub-e находите строку с ядром, добавляете в конец init=/bin/bash сразу загружаетесь без выхода в меню
Получаете полный доступ, возможно потребуется перемонтировать fs в режим write
P.S не внимательно прочитал про шифрование
Тогда увы никак
PasswordAuthentication no
а потом чтобы добавить новый ключ с новой машины ssh-copy-id уже не прокатит. хорошо что это был локальный роутер и там был telnet
Я правильно понял, что нам нужно на конкретный ip указать наш шлюз с tun5, если уже есть 0.0.0.0/0? Иначе мы можем положить всю сеть?
Вероятность положить часть сети на сервере при изменении маршрута по-умолчанию есть, включая ваше ssh-соединение. Об этом и написано предупреждение.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.
И зашифрован он будет плохо.
Используйте ключ -o
Почти то же самое, что вы изложили на русском.
Доброго вечера) а может кто-то подсказать как организовать соединение вида: SSH server(фиксированный IP, Nat)<=SSH Client=>RDP Server
Цель: подключение RDP клиентом к SSH server, и попадание на RDP сервер. (заранее предположим что пробросы уже сделаны) как выполнить такой проброс с SSH Client'a одним скриптом?
На 10 устройств/учетных записей бесплатен.
Позволит просто реализовать двух-факторную аутентификацию на Ваш SSH-сервер и входить, используя RSA-ключ + Push на сотовом телефоне. Плюс в Push сообщении видно IP-адрес входящего.
Удобная вещь — за почти год использования не подводила ни разу пока что.
https://habrahabr.ru/post/122445/
Для еще одно малоизвестного факта о SSH/SCP загляните в описание опции -3
в документации man scp
Для простой организации VPN через ssh можно использовать sshuttle. Используются iptables и python на локальной машине и только python на удаленной, без рута. UDP к сожалению не поддерживает. https://github.com/apenwarr/sshuttle
Например —
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
Магия SSH