Comments 54
Но часто бывает такая ситуация, когда необходимо со своим ключем перейти на сервер и там уже им воспользоваться. Существует три решения данной задачи
Если ssh-agent запускается на удаленном сервере то четыре.
Локальный ssh-agent + ForwardAgent yes
Локальный ssh-agent + ForwardAgent yes — я это и указывал
А цепочку можно построить так:
$ ssh-add
$ ssh -A server
connected
$ ssh-add # будет добавлен ключ из первого шага
$ ssh -A server2
connected
$ ssh-add # будет добавлен ключ из первого шага
$ ssh -A server3 
— стянуть приватный ключ, если он не запаролен
— прописать свой ключ в authorized_keys и ходить на пользовательскую машину пользоваться уже локальным агентом
— запустить любые туннели или сервисы
А там им воспользоваться зачем? Залогиниться на локальный (для удалённого сервера) узел?
Лично мне хватает пары записей в конфиге:
host server1
User vasya
Port 9222
host server2
User petya
ProxyCommand ssh server1 -W %h:%pОткрытый ключ прописан на обоих серверах в authorized_keys.
И всё, на server2 заходится в один клик, без всяких манипуляций с агентами и т.д.
Это что, способ 4?
Кто скажет насколько безопасен данный способ с ProxyCommand, если на промежуточном server1 сидит злодей под рутом и жаждет расширить сферу своего влияния на тебя.
Как я понимаю это получше, чем агента прокидывать, но безопасно ли проделывать такое с не доверенными хостами?
Дык приватный ключ никуда не пробрасывается.
ProxyCommand логинит на первый сервер по публичному ключу. И через него на второй — по тому же публичному ключу. Приватный остаётся у себя и никуда не пробрасывается.
Подозреваю, что это ничуть не более опасно, чем просто дать злодею напрямую прослушивать трафик (который зашифрован).
Отказаться уже наконец в 2018-м году от доступа по ключам и перейти к доступу по сертификатам. Например github.com/gravitational/teleport (ну или убера есть похожая штука)
А ещё приватные ключи можно хранить например на аппаратных кошельках криптовалют (например ledger nano s это умеет).
Расскажите, как вы будете управлять ключами десяти тысяч сотрудников на трёх сотнях тысяч серверов. Доступы у сотрудников добавляются и удаляются сотнями в день, сервера добавляются и исчезают тоже сотнями в день. Подсказка:
Читайте документацию, в ней все написано, как бы это пошло не звучало.Вот это будет интересный пост. Заранее спасибо.
А в энтерпрайзе другие подходы
Я для этого писал кучу скриптов и хакал ssh_agent :) Но у меня были тепличные условия: 50 сотрудников делились на примерно 5 груп и коннектились на сервера клиентов (~1k машин) на 2-3 аккаунта.
асскажите, как вы будете управлять ключами десяти тысяч сотрудников на трёх сотнях тысяч серверов.
PAM?
На хабре была статья про использование промежуточных SSH серверов, через них уже ппоизводился выход на целевые сервера. Опять же, если рассматривать тысячи серверов, то это уже enterprise решения и выходит за рамки этой статьи
У меня опыт был использования PAM + ldap для управления пользователями
Белое пятно — что root на сервере, куда вы пришли с форвардом ключа, может реюзнуть сокет и фактически воспользоваться ключем, пока открыта ваша сессия.
Дальше о безопасности говорить уже смысла нет
Никаких тебе агентов и у рута на удаленной машине нет доступа к агенту.
Технически не мешает и подобное я часто использую (делал внутренний доклад про сценарии использования, однако, на Хабре уже есть статьи на эту тему), но что, если надо зайти на сервер и выполнить
$ git pullИли scp или rsync да и много чего ещё (на самом деле нет).
Можно использовать парольную аутентификацию или извращаться, а можно воспользоваться агентом.
Часто встречаю ситуацию когда на серверах разработки код стянут по https, ты вызываешь
git pullА у тебя GIT спрашивает пароль какого-то разраба. Почему нельзя было склонить по SSH? Секурность? Нет — глу… незнание
По поводу компрометации сокета ssh-agent:
Например, под Windows, есть агент, встроенный в KeePass (в виде плагина) и он выдает запрос на каждое использование ключей.
Также есть такие интересные штуки как Krypton, про которые почему-то в статье не упомянули. (Вкратце: ключи генерируются и хранятся на мобильном устройстве в защищенном хранилище и никогда оттуда не извлекаются, это просто невозможно без прав рута и прочих хаков)
На локальной машине можно найти файл $HOME/.ssh/configА если бы мне давали рубль за каждый случай «я забыл пароль/адрес/параметр» я жил бы недалече от вас.
$HOME/.ssh/config и ключи это удобно но это сильно провоцирует забывчивость.
Ещё в конфигурационном файле вы можете использовать маски, чтобы не писать много раз одно и то-же:
В критически важных CI/CD использование комбинации
ssh-keyscan example.com >> ~/.ssh/known_hosts
Во время инициализации совместно с
StrictHostKeyChecking=yes
Позволит надежно защититься от MITM-атак
Это же совсем не так, man ssh-keyscan говорит:
SECURITY
If an ssh_known_hosts file is constructed using ssh-keyscan without verifying the keys, users will be vulnerable to man in the middle attacks. On the other hand, if the security model allows such a risk, ssh-keyscan can help in the detection of tampered keyfiles or man in the middle attacks which have begun after the ssh_known_hosts file was created.Т.е. без верификации ключа ты уязвим к MITM.
Или я что-то недопонимаю в вашем высказывании?
А ещё SSH-ключи можно записывать на хардварные носители, чтобы их не держать на машинах: https://evilmartians.com/chronicles/stick-with-security-yubikey-ssh-gnupg-macos
На схеме видно, что после обмена публичными ключами два узла могут безопасно общаться между собой через небезопасный Интернет.
Кроме того, аутентификация пользователя может производиться при помощи этой самой пары ключей.
«При помощи этой самой пары ключей» ТОЛЬКО АУТЕНТИФИКАЦИЯ и производится.
А безопасное общение узлов происходит за счёт симметричного шифрования с использованием сеансового ключа, который в свою очередь генерируется еще до аутентификации при помощи алгоритма Диффи-Хеллмана.
Белые пятна в работе с SSH