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

Вот не вижу, чтобы это сообщение как-то опровергало моё. Какие-то ортогональные замечания.

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

Я не зря написал про скрипт вида «сделай сам». Если ты собираешься оформлять в виде коробочного решения, без разницы, на чём оно там будет написано, пока его можно поставить, включить и пользоваться. А вот если это набор скриптов, которые надо ещё как-то настраивать и подгонять, язык важен. Насколько вероятнее у некоторого случайного девопса наличие навыков кодинга на Erlang? А на Python или Perl?

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

А если «плохой» сотрудник засунул туда еще пару своих ключей заранее?

поясню ещё раз, надеюсь получится:

1) есть проблемы в том, что бы на те сервера положить все наши публичные ключи: 1.1 админам тех серверов может не понравиться много наших ключей 1.2 админы тех серверов могут стереть ключи 1.3 админы тех серверов могут генерировать свои authorized_keys и тогда надо встраиваться в их механизацию управления этим параметром (думаю, ты догадываешься насколько это сложно) 1.4 мы можем задолбать админов тех серверов: добавьте/уберите ключ, если для этого надо дергать их

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

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

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

а если он положил руткит?

Ну так и прокся от этого не защитит. Ну разве что в нее IDS встроить. Так что только анально огараживать сервера, ставя везде rkhunter, и логируя все команды на удаленный сервер, и т.д. и т.п.

не защитит.

Но например будет известно, на какие сервера он в принципе заходил.

А если «плохой» сотрудник засунул туда еще пару своих ключей заранее?

Отфильтруй их.

Или, как вариант, хранить единый официальный authorized_keys в конторе под замком, а при изменениях (удалении сотрудника) просто копировать его на 100500 серверов. Все левые ключи будут просто затёрты официальным authorized_keys.

Теперь вижу проблему:

админы тех серверов

Технически эта проблема нерешаема в принципе. «Админы тех серверов» могут восстановить ключ уволенного сотрудника из бэкапа, или просто дать ему пароль, например. А вашу контору послать нафиг и платить за суппорт уволенному сотруднику.

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

Опять непонятно. Вы хотите без ведома владельца сервера что-то там делать, что-ли? Причём даже если владелец поменял адрес и хостнейм? Насколько я понимаю, если владельцу сервера понадобится ваше вмешательство, то он как минимум сообщит вам об изменениях IP и хостнейма.

будет известно, на какие сервера он в принципе заходил.

Ты недооцениваешь изобретательность злонамеренных персонажей.

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

Яндекс, наверное, небольшая контора.

ansible поддерживает bastion-host

https://docs.ansible.com/ansible/latest/faq.html#how-do-i-configure-a-jump-ho...

когда у тебя контейнер может шедулером подняться где угодно

А контейнеры в принципе не админят по ssh, они immutable, их надо готовить в CI-системе перед деплоем на облако, а не настраивать после.

Собствено с виртуалками та же история. Когда их много, динамически создаваемых, переезжающих между железными хостами и т.п., ими уже не управляют индивидуально. Их точно как контейнеры готовят заранее и запускают с cloud-init-параметрами. Готовят в CI-системе, тестируют и выкатывают на облако. И никаких апдейтов внутри виртуалки, только полная переналивка.

Дело же не в размере на самом деле, а в культуре. И не всегда ты можешь поменять эту культуру и инфру, приходится работать с тем что есть, так что ТС-а в принципе понять можно.

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

Еще один пятизвездочный, который

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

Видели мы «порядок», видели «бардак». Знаем что за этими словами стоит, и сколько бардака спрятано за внешним порядком и сколько порядка прикрыто внешним бардаком. Уверен, ты тоже видел.
Так что там по разультату «grep -i ssh»?

Очень философски. Что сказать хотел - непонятно.

1. Выделяете один прокси-сервер. Ну или прокси-учетку. Например на сервере proxy учетную запись agent

2. Все удаленные системы монтируете как sshfs например в /home/agent/consumers/<servername>. Например:

/home/agent/consumers/gazprom.com
/home/agent/consumers/lukoil.com
/home/agent/consumers/roga-i-kopyta.name

Итак, вы только что решили проблему с scp - просто копировать вы будете не в root@remoteserver/path/file, а в agent@proxy/home/agent/consumers/<remoteserver>/path/file, например:

junworkstation ~$ scp \
>    /git/shiproject/shit.conf \
>    agent@proxy:/home/agent/consumers/gazprom.com/etc/not-a-shit.conf

3. Настраиваете sudo так, чтобы ваши пользователи могли сделать sudo -u agent. Тогда все смогут зайти по SSH на proxy и оттуда сделать команду у клиента. Ну или просто зайти к клиенту:

junworkstation ~$ ssh jundev1@proxy
***
*** Welcome, junior!
*** Beware unstable commits!
***
jundev@proxy ~$ sudo -u agent ssh agent@gazprom.com

А потом можно сделать

alias mssh="sudo -u agent ssh"

mssh agent@gazprom.com

Всё что вам осталось - это грамотно администрировать proxy. Правда тут некуда пришить эрланг, поэтому это решение для вас не подойдёт.

ну и потом sudo можно урезать до sudo -u agent ssh и так далее. В общем, всё просто.

С вас $500 за консультацию.

Сказал ровно то же, что и ты, но про тебя. То есть сделал за тебя твою работу - саморефлексию, применил сказанное к тебе самому. Не подменил ли ты сличайно или преднамеренно, осознанно или неосознанно твой так называемый порядок бардаком, а бардак - порядком. Говорят, иногда помогает осадить зазнавшихся критиков.
Так как саморефлексия со стороны выглядит достаточно жалко и отталкивающе, поэтому лучше вернуться к обсуждаемой теме, так что там по результату «grep -i ssh».

так что там по результату «grep -i ssh»

Ожидание окончания стандартного ввода? // мимокрокодил

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

shell-script статус 5 звезд модератор. Какие модераторы, такие же содержательные темы.

предположительно похожую задачу решает https://github.com/moul/sshportal

https://github.com/moul/sshportal

По диагонали посмотрел ридми. Годно и достойно. Самое интресное это admin-shell и возможно работа с бд. Остальное (ssh-proxy, telnet, пользователи и тому подобное) думаю прямолинейная автоматизация рутины в командной строке. Ну что, есть пример, можно повторить, можно сделать что-то свое, успехов.

больше одного пользователя на сервере бывает у бородатых троглодитов, которые ещё не поняли, что 80-е закончились и заводить несколько _живых_ пользователей на одном сервере — это треш и не работает.

Ват? Серьёзно?

Так вроде задача как раз логично решается административным методом: на тех серверах заводится отдельный пользователь(о ужас!!!), ему назначаются разумные с точки зрения клиента права и authorized_keys контролируются уже вами. Но конечно же продавить админов клиента на чуть-чуть поработать - это задача малоподьёмная.

Окай.

Как бонус клиент может прибить весь ваш зоопарк одним движением, особенно если есть что-то типа chef

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

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

А условие про недоступность приватного ключа пропустили?

Б - безопасность.

разве хоть что-то может быть сравнимо по безопасности с компьютером, который лежит отключенный от всего в сейфе?

Мах - тебя как проггера я оценить не могу, не владею erlong-ом. Но дури в голове у тебя предостаточно :) Что там классики и отцы-основатели говорили про автоматизацию бардака напомнить? :)

Ну а теперь хорошие новости - никого не слушай, главная идея - рабочая!

У меня в ещё 2005 году шеф сам сделал подобное на основе openssh-server, юзеры (наш саппорт) сидели в нашем LDAP, единственное отличие было вот это: ssh usrer1@ssh-proxy - хрена вам ssh admin1@ssh-proxy - здрасте, можно сделать\удалить нового клиента, ключи прописать ssh usrer1@ssh-proxy:1001 - хрена вам, user1 к клиенту 1001 не допущен ssh usrer1@ssh-proxy:1002 - вперёд, ковать пока горячо ssh admin1@ssh-proxy:1001 - хрена вам, не admin-ское это дело - к чужому sander parsonклиенту лазать

Те куча портов и на каждом свой ssh?

Существует всего ДВА способа пустить в консоль сервера: 1. ключ (один на всех - ДЕБИЛИЗМ) 2. логин+пароль.

Все. тебе выбирать.

еще безопаснее - снять винт и рабить молотком. Никто не считает приватные данные.

Лучше иметь каждому сотруднику свой ключ для ssh. И после увольнения со всех серверов поудалять соответствующий открытый ключ.

Пожалуйста, очень прошу, прочитай ветку обсуждения

ну а сделать доступ через openvpn и не давать пробросить вовне порты кроме стандартных как это делается во всех компаниях не судьба ?

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

Может. Компьютер который не был куплен.

Компьютер который не был куплен.

В смысле, был украден или произведён самостоятельно?

А условие про недоступность приватного ключа пропустили?

Приватный ключ лежит у пользователя agent.

Принадлежит пользователю root, группе agents.

В группу agents никто не включен.

Имеет права ---.r--.--- (0040).

В /usr/local/bin лежит копия ssh принадлежащая root:agents с правами r-x.r-s.r-x (setgid).

Пользователь agent приватного ключа более не прочтёт

Но при вызове /usr/local/bin/mssh ключ прочтется.

Но только этой программой, никакой другой.

Шире используйте стандартные инструменты, в этом нет ничего сложного.

Не нормально иметь всем один ключ. Все аргументы против - от лени.

Те куча портов и на каждом свой ssh?

Нет, демон один, но слушает туеву хучу портов. Это был support engineers jump box в компании B**ware. C 2005 и до скоропостижной в 2009 :(

Но шеф был могуч! :) Он даже свой ЯП сделал - его ещё короткое время целая Toshiba Inc. юзала! Правда они быстро поняли что лучше писать на чём то, что похуже, но для чего программеров - как грязи :-)

Нет, тот которого нет.

Тред не читал, но обычно для каждого пользователя генерируется свой ssh-ключ. Публичные заливаются в authorized_keys каждого сервера. Если работник увольняется, его ключи удаляют (можно автоматизировать с помощью ansible или подобных утилит).

Почитай, там уже сказали почему не осилили сделать хорошо.