ssh-proxy: как дать человеку доступ на сервер, не давая ему приватный ключ

а теперь представь что ты, например, Оракл. И у тебя есть куча чужих облаков больших ынтерпрайзов, в которых твои продукты, которые ты админишь по подписке за вагоны бабла. Ага, заставь Райфайзен Банк и ЦРУ подключиться к твоей лдапе, а мы попкорном пока запасёмся

проблематика стала понятнее?

Я конечно, не в Оракле (пока), но проконсультировать могу, тому що ты примрно описал чем я тут занимаюсь. Никакого бугурта! Ружья кирпичом уже не чистим.

как вы это решаете?

щаз меня из Джуга уволят за распиздяйство, к вам пойду жабу точить, расскажешь вживую :)

Для этого с одной стороны у одного большого банка(сильно больше райфайзена) есть отдел, занимающийся своими серверами со своим LDAP'ом, а с другой стороны у нас есть специальный отдел, который с ними взаимодействует. Когда мне надо попасть на сервер и что-то там сделать, делается запрос в СБ банка, там для моей персональной учётки выдаются права, я иду на сервер и делаю то, что нужно. Если в read-only-аккаунт, то по паролю или ключу, если в read-write, то ещё и через спец-токен.

Разумеется, доступ к серверам клиента идёт через шлюзовой сервер на котором среди прочего включён кейлоггер, на случай если я накосячу. Но последнее - это уже заморочки конкретного банка.

Это я тебе реальный ежедневный кейс с текущего места работы описал, даже представлять ничего не надо.

Я на ерланге не умею, чем это лучше чем

ssh -t -i user proxy@company 'ssh -i company root@clientserver'

Вот что бывает, когда программисты занимаются администрированием.

тем, что ты можешь сделать ssh proxy@company и забрать оттуда приватный ключ.

С ssh-proxy это не получится

chef/puppet/ansible

Фу

а теперь представь, что ты там не один такой мегаработник, а есть пул админов и клиентов. N админов админят M клиентов. N около двухсот, M в районе десяти тысяч.

Любой из админов может админить любого из клиентов, причём реагировать нужно моментально (работать по тикетам в хэлпдеске, каждый следующий тикет ведёт на кого-то следующего).

При этом админы доверенные не больше, чем в их трудовом договоре (любой может подняться и уйти со словами «я слишком стар для этого дерьма»), любой клиент может сделать подписку на саппорт за 10 секунд до того, как этот тикет прилетит к новому админу (новому, потому что старый уволился недавно).

Т.е. условно говоря, недоверенные там все - и работнички, и поставщики, и клиенты, и лиды. Словом, обычный ад, в смысле - клауд

Теперь сам подумай, какими характеристиками должна обладать система авторизации со стороны работодателя, ворочащего этим пулом админов и клиентов

Ну это, наверное NDA.

Но в идеальном мире у тебя есть централизованное хранилище пользователей, групп, хостов, сертификатов и ключей (например IPA). Есть Git (например) с конфигурациями где среда - это ветка. Есть система провиженинга хостов с разными правилами для разных сред - на ДЕВ хоть голыми под луной пляшите, на ПРОД вообще люди не ходят никогда, только CI/CD и зонды и провиженинг там отдельный отдельными людьми. К ней там еще всякие escrow-сервисы могут быть пристроены и централизованное шифрование носителей (вы же серверы на хостинге не храните нешифрованными).

Если надо отгрузить данные третьей стороне, то для этого всякие fractional read-only ldap есть, SAML, OIDC вот это все.

Если у тебя сотрудник ушел, то его пользователь заблокировался, а ключи со всех хостов отозвались, учетки в сторонних сервисах заблокировались.

Если у тебя есть задача контролировать хост, который контролирует кто-то еще с такими же правами, то ничего у тебя не получится в смысле консистентности. Все что ты можешь - оставить доступ 1 стороне, а вторая будет давать ей патчи конфигурации.

Один адовый сервер с 45-ю зачрутенными бесправными пользователями, которые только скрипты с ssh до нужных серверов могут запускать?

возможно имеет смысл попытаться возиться с настройками ключей ssh сервера и списком команд, которые можно запускать, но всё таки вот такой централизованный прокси пока что выглядит сильно удобнее и разумнее.

man 5 ssh_config: ProxyJump или ProxyCommand.
Это не упростит решение проблемы гиганту мысли и отцу русской демократии?

это чего-то новенькое, ещё не видел.

С ним проблема в целом ровно та же: непонятно как запретить остаться на промежуточном сервере. Но это уже близко к проблеме.

man ssh host based authentication

Есть такая поговорка «от дурной головы ногам нет покоя»

Типичный случай.

Подумал. Посмотрел по сторонам даже. Нас тут шесть этажей таких, админящих, девопсящих, пишущих софт и т.д. Это только в одном городе. Всего у конторы филиалов по всему миру разбросано несколько десятков. Часть отдела, в котором пишу софт я, сидит в том числе в других странах. Когда они к нам или мы к ним приезжаем в коммандировки, мы пользуемся с любого конторского компа своей одной и той же учёткой со всеми ранее выданными правами. Параллельно с нами некоторых клиентов сопровождают коллеги из других контор(в моём случае из Индии). И ничего, софт пилится, серваки админятся. Всегда имеется актуальный список подконтрольных серверов на внутренних порталах ответственные за доступы люди в реальном времени могут посмотреть, у кого куда есть доступ. Когда доступ был выдан, когда его заберут и т.д.

И я пока не вижу никаких неразрешимых проблем. Да, тут поддержкой инфраструктуры занимется разумеется не полтора бородатых админа, а сильно побольше народу. Но это я просто к разговору об ынтерпрайзе и больших конторах. И всё решаемо.

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

непонятно как запретить остаться на промежуточном сервере

На своем-то подконтрольном сервере, думаю, можешь навести порядок с учетками. Можно даже на эрланге.
Или городи что похожее на ldap, чтоб было правильно и загоняй все сервера под свой контроль, товарищь диктатор.

Опять санитары в карты режутся, а буйные у них свободно из палат выходят и на LOR пишут из кабинета главврача...

Сохраните это в цитатник ЛОРа, пожалуйста.

ты так и не прочитал внимательно важное условие.

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

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

Если честно, то я не специалист по настройке ssh-сервера. Но думаю (даже уверен), если ты покопаешся в манах, то быстро решишь эту проблему с запретом логина и ограниченем доступа к файловой и не только системе на прокси-сервере стандартными средствами ssh-сервера.

ForceCommand

Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client and ~/.ssh/rc if present. The command is invoked by using the user's login shell with the -c option. This applies to shell, command, or subsystem execution. It is most useful inside a Match block. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Specifying a command of internal-sftp will force the use of an in-process SFTP server that requires no support files when used with ChrootDirectory. The default is none.

Товарищи 5-звездочные, которые по делу ничего не сказали и раскритиковали чужие деловые процессы, может вы замолчите. Решается достаточно повседневная задача, только вот очень интересным способом.

да, для этого надо ведь будет наплодить на промежуточном сервере N*M промежуточных юзеров по каждой комбинации из сотрудника и клиентского сервера?

пускай рассказывают о том, как вместо одного простого демона у них в компании целый отдел из 40 бездельников выстраивает организационную систему, которая жрет по 3 дня на логин на сервер и кормит ещё 100 админов, которые поддерживают всё это.

Главное административные проблемы не вздумать решать техническими средствами!

Найди хорошего ssh-админа, пусть он тебя проконсультирует. По мне, задача решается проще, чем ты думаешь.

увы, но судя по всему нет.

IT-summa делали своё решение: https://github.com/itsumma/isolate но там по-другому решено.

а если ты вдруг узнаешь технологию, благодаря которой этим может заниматься 1 бородатый админ? Или, например - вообще никто, одни скрипты?

По делу несколько человек независимо друг от друга предложили как минимум систематизировать список серверов. За что были названы одновременно школьниками и админами из 50-ых. После чего ТС выдал гениальный поток сознания о том, что вести учёт серверов в принципе невозможно и никто так не делает.

Нет ничего сложного в том, чтобы вести актуальный список подконтрольных серверов - если кто-то дал тебе доступ на сервер, можно хоть в блокнотик записать его адрес, а можно проанализировать .ssh/know_hosts и автоматически добавить куда-нибудь, а можно и конфлюэнсе или анлоге вести учёт. С пометками, кому сервер принадлежит, что на нём крутится. В общем, тут уже на выбор.

Дальнейший анализ этого списка даст возможность подумать над тем, как организовать доступ. Возможно, не имеет смысла для каждого сотрудника держать отдельную пару ключей, а стоит разделить сервера на группы. Какие-то ключи можно делать разовыми, и отдавать клиенту публичный ключ конкретно под неё. Какие-то отдельные сотрудники, так сказать доверенные, могут иметь свои ключи для доступа к разным серверам. Возможно имеется смысл на некоторых серверах хранить несколько ключей. И если клиенты дают ТС'у рутовый доступ на свои хосты, я не думаю, что для них будет иметь большое значение один ключ лежит в файле, который надо приаппендить к authorized_keys или несколько. Разумеется, всё-равно это стоит обговорить.

На шлюзовом сервере сделать таки нормальное разграничение пользователей, разложить ключи соответсвенно. Пользователями управлять с помощью централизованного хранилища. Как уже выше писалось, пользователь уволен, учётка заблокирована, ключи отозваны. В критичных случаях стоит поставить ограничение на уровне файрволла и/или надстройки над ssh(например, что-то типа чрута и pbrun). Таким образом одни пользователи смогут ходить на какие-то сервера, другие - нет. При этом можно и закрытые ключи попрятать без проблем.

И так далее. Если хочется сделать нормально, надо подумать и, возможно, прислушаться к людям, которые что-то понимают в системном администрировании. И потом в зависимости от ситуации проектировать решение.

Сейчас ТС, повторюсь сам и повторю слова многих в этом треде, развёл у себя бардак. Придумал костыль, которым хочет бардак замаскировать, но на самом деле ничего не изменит. И просто посылает всех направо и налево, когда ему пытаются об этом сказать. В таких условиях тяжело сказать что-то «по делу», как ты выразился. А задача действительно повседневная и давно уже имеет множество решений.

Если узнаю, будет прекрасно.

видишь, Макс написал на ерланге! ^^^ :)

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

Поменяй его и все.

... Сейчас ТС, повторюсь сам и повторю слова многих в этом треде, развёл у себя бардак...

Основная решаемая задача озвучена в названии - «ssh-proxy», кстати очень актуальная. А «поток сознания» - это способы решения, которые он видит, и судя по мне, не специалисту по ssh, довольно наивные и возможно неправильные. Что говорит, что он пока на стадии поиска и накопления знаний для решения проблемы. Ты и другие критики не привели ни одной подсказки, чтоб поставить его на путь истинный, а выливаете свой «поток сознания» из своих корпоративных догм. Так как начавший тему - хозяин обсуждаемой темы, то ваш «поток сознания» более бесполезен чем его «поток сознания». Лучше бы рассказал про админстрирование ssh и проброс. Ан нет, все гнешь свою линию в чужой теме.

хороший вариант, но тогда надо перелогиниться везде и поменять везде.

Как уже писал выше: мы не можем держать актуальный список серверов везде, плюс наши же клиенты могут себе внести наш публичный ключ один раз в свои скрипты и потом его добавлять/убирать.

Просить их каждый раз поменять ключ не хочется.

Какие ещё догмы? Надо разным людям дать доступ на разные сервера с возможностью отзыва. Это называется разграничение прав доступа. Штатные способа решения этой задачи озвучены. Подробности реализации зависит от конкретной ситуации. И один ключ на всех это не решение проблемы, а маскировка.

Пока не вижу. :)

Какие ещё догмы?..

Опять поток сознания из догм. И в этом потоке сознания вывод «grep -i ssh» дает пустой результат. Отсутствие результата тоже результат, ящетаю.

А зачем что-то разрабатывать? На хосте sshproxycompany.com создаешь пользователя user-clientserver, меняешь у него шелл с /bin/bash на ssh user@clientserver, кладешь в ~user-clientserver/.ssh/id_rsa приватный ключ для доступа к user@clientserver, кладешь в ~user-clientserver/.ssh/authorized_keys публичные ключи сотрудников.

Когда сотрудник увольняется, удаляешь его публичный ключ из всех authorized_keys с хоста sshproxy.company.com.

создаешь не одного юзера user-clientserver, а очень много user-clientserver1, user-clientserver2 и т.п. по количеству возможных серверов, куда может потребоваться залогиниться.

Я немного в ужасе от того, насколько админчики в треде бывают фанатично упороты и уперты в том, как придерживаться старого подхода в софте.

Т.е. там, где программисту просто не хватило сил, времени или проблематики что бы сделать фичу и появился костыль, админ видит Великую Сермяжную Правду и готов сжечь любого, кто предложит как сделать получше.

Пользователи создаются просто как папки для наполнения их ключами. Где-то ведь все равно надо на sshproxy хранить привязку ключей к user-clientserver.

Сжигать никого не хотел, чес слово.

Спор уже какой-то больше религиозный выходит. С одной стороны у вас очевидный бардак, с другой, бардак обусловлен объективными причинами, ну и командная строка у вас, видимо, командуит и даже приносит прибыль. Очевидно, что вашему бизнесу полноценный администратор экономически не выгоден (и это нормально), достаточно того, кто просто знает, где и что лежит.

Отвечая на вопрос в стартовом посте: нет, спасибо, нам это не нужно. И я так и не понял: почему у кучи народу есть доступ по скомпрометированному ключу на кучу серверов, но при этом любая готовая система оркестрации будет «подозрительной». Ведь ваши «5000 железных серверов» вы же не вручную раскатываете, в конце концов?

Что будете делать, когда главный любитель ссш-проксей на эрланге уйдет буянить в контору на соседнем этаже?

создаешь не одного юзера user-clientserver, а очень много...

положи в home или пропиши в $PATH путь к ssh-proxy принимающий в качетсве параметра сервер, который внутри вызывает ssh root-user@$1, где $1 - имя сервера обслуживаемого сервера. На стороне клиента ssh user@proxy ./ssh-proxy server1. В настройках ssh вроде можно еще прописать белый список разрешенных команд.

как при этом сделать sftp, scp и т.п.?

По описанию идея выглядит здравой. По крайней мере, это намного лучше, чем давать всем приватный ключ. Чуть лучше, чем ручками чистить на целевых серверах authorized_keys/authorized_keys2.

Правда, есть пара «но». Первое: скрипт типа «сделай сам» на Erlang'е сразу отвратит многих. Не самый популярный язык. Второе: решение расчитано на честных людей. Рутовые права на машинах кастомеров легко дают возможность закрепиться там. И доступ через прокси с этим ничего поделать не сможет. Ну будешь ты логировать всё. Не просматривать же глазами вообще все логи.

Вопрос самому себе: и зачем я вошел в эту тему с опций ProxyJump/ProxyCommand? Найди все таки нормального ssh-админа, поговори с ним, ключевые слова для предметных вопросов к нему тут уже тебе накидали.

про эрланг уже проходили =)

громче всех про язык написания софта орут те, кто никогда в жизни ни единого патча не делал, так что это не страшно.

Будет востребовано, сделаем и deb пакет.

Рутовый доступ к кастомерам нам увы необходим, борьба с его последствиями вне плодотворной дискуссии, которую здесь старпердуны развернули. Т.е. это отдельная проблема и её не решить раскладыванием authorized_keys

дальше будешь теоретизировать? Или всё таки включишь мозг, посмотришь сырцы и поймешь, что ты своими ProxyCommand не сделаешь безопасным приватный ключ и полный спектр возможностей тунеллирования и scp?

сложно пройти по всем серверам всех клиентов и поменять там выложенные ключи.

Вот в этом большая проблема.

Так и не понял в чём проблема.

Пусть есть 100500 серверов, к которым есть доступ у вашей конторы. Пусть на 100500 серверах лежат публичные ключи всех 50 сотрудников в authorized_keys. Пусть одному «плохому» сотруднику дали пинок под зад. В чём проблема для «хорошего» сотрудника запустить что-то типа

$ for s in `cat 100500servers`; do ssh admin@${s} 'KEYS=/home/admin/.ssh/authorized_keys; mv "${KEYS}" "${KEYS}.old"; grep -v "baduser" "${KEYS}.old" > "${KEYS}"; chmod 600 "${KEYS}"' ; done

Всё, на всех 100500 тачках ключи «плохого» удалены и он не сможет залогинится ни на один из них, при этом остальные сотрудники продолжат работать как ни в чём не бывало.