LINUX.ORG.RU

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

 , , ,


0

3

https://github.com/flussonic/ssh-proxy

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

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

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

Мы решили попробовать сделать ssh-proxy, организованный на подобие гитозиса: публичные ключи сотрудников лежат в папке, приватный лежит на сервере.

Можно залогиниться как ssh root/clientserver@sshproxy.company.com и тогда сразу попадешь на root@clientserver

Сейчас реализовано: 1) авторизация сотрудников по публичным ключам 2) проксирование текстовых команд

Не реализовано:

1) разграничение прав, кому куда ходить можно и не можно 2) тунеллирование, scp, sftp. Этого вообще нет из коробки в эрланге, надо будет допиливать ему stdlib 3) ещё кучи чего наверное

Будет ли это полезно и интересно кому-нибудь ещё?

★★★★★

Последнее исправление: max_lapshin (всего исправлений: 2)

раздают всем приватный ключ

Это в какой шаражке так делают?

beastie ★★★★★
()

Создать проблему - решить проблему.
Молодцы.
Только нормальные люди не раздают приватных ключей.

Deleted
()

ну это просто эпичный ънтрпрайз на коленке

anonymous
()

Поддерживаю вышеотписавшихся:

Создать проблему - решить проблему.

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

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

No LDAP, Kerberos or any other nightmare technologies

Правильно, лучше поделку на эрланге накатить

deadNightTiger ★★★★★
()
Последнее исправление: deadNightTiger (всего исправлений: 1)

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

aedeph_ ★★
()
Ответ на: комментарий от Harald

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

Deleted
()
Ответ на: комментарий от deadNightTiger

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

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от intelfx

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от aedeph_

Раздавать приватные ключи - это же просто дебилизм.

полностью поддерживаю

fsb4000 ★★★★★
()
Ответ на: комментарий от max_lapshin

Не понимаю, в чём проблема сделать ssh-keygen столько раз, сколько у вас пользователей, собрать паблик ключи, запихнуть их все в authorized_keys и забыть? Тут вы выбираете, что вам удобнее-держать множество ключей или один на всех, но менять его у всех, когда кто-то увольняется.

Pyzia ★★★★★
()
Ответ на: комментарий от Pyzia

неудобно то, что:

1) надо держать список всех-всех серверов, куда мы так или иначе логинились 2) оповещать хозяев этих серверов, что это за ключи и что их надо не удалять

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

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

какая-то странная позиция

Harald ★★★★★
()
Ответ на: комментарий от Harald

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

Изредка некоторые особо прошаренные домашние юзеры заводят себе на одном домашнем ноутбуке два аккаунта, но это огромная редкость.

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

Так что наличие в /home больше одной папки в том смысле, в каком это затевалось — это уже огромная редкость

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

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

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

anonymous
()
Ответ на: комментарий от Deleted

потому что мы даем свой публичный клиентам

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

Оооу, ну если на _чужой_ сервак нужно водить аж 45 человек, тогда ваш вариант с одним ключём на всех единственно правильный и других я тут не вижу, хотя если некоторые сотрудники особо неблагожелательны, можете сделать ключ для них в порядке исключения, пара-тройка лишних ключей никого ж не смутит? Вообще говоря, не совсем понимаю, о каких неприятных проблемах после увольнения сотрудника идёт речь? Вам сложно выкинуть в общий чат ссылку на внутренний фтп с новым ключем и сказать «пацаны, теперь юзаем этот ключ»? Как небольшой костылёк можно настроить доступ на сервера только с вашего айпи.

Pyzia ★★★★★
()
Ответ на: комментарий от max_lapshin

но речь идёт о серверах, для которых много живых юзеров - это нормально

Harald ★★★★★
()
Ответ на: комментарий от Pyzia

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

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

max_lapshin ★★★★★
() автор топика

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

Это где такие кретины водятся? Подскажи, чтобы обходить стороной.

Deleted
()
Ответ на: комментарий от max_lapshin

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

А мужики-то не знают.

Если конкретно в твоей шаражке не умеют в права доступа, это не значит, что во всём остальном мире так же.

shell-script ★★★★★
()
Ответ на: комментарий от max_lapshin

Изредка некоторые особо прошаренные домашние юзеры заводят себе на одном домашнем ноутбуке два аккаунта, но это огромная редкость.

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

morse ★★★★★
()
Ответ на: комментарий от Pyzia

да, но это требует наличия достоверного списка серверов, на которые это было разложено. Этот список заранее недостоверен и неполон.

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от morse

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

Это называется решать административный вопрос техническими средствами - заранее проигрышная тактика.

ya-betmen ★★★★★
()
Ответ на: комментарий от max_lapshin

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

shell-script ★★★★★
()
Ответ на: комментарий от max_lapshin

Этот список заранее недостоверен и неполон

И вот наконец-то мы неспешно подобрались к вашей истинной проблеме.

Pyzia ★★★★★
()
Ответ на: комментарий от ya-betmen

т.е. вы предлагаете отменить пароли и шифрование? Давайте решать административный вопрос административными методами?

Вы знаете, что 50-е года уже закончились

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

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

А мужики-то и не знают.

aedeph_ ★★
()
Ответ на: комментарий от max_lapshin

В любые года 45 человек с рутовыми доступами на неизвестном количестве серверов - это бардак и полное отсутсвие какой-либо безопасности и отказоустойчивости.

shell-script ★★★★★
()

сама эта штука мне непонятно, нужна ли, а вот как пример написания ssh proxy отлично

конечно, есть минус, что эрланг, но суть понять всё равно можно. Всяко лучше, чем bash

да там и кода немного

stevejobs ★★★★☆
()
Ответ на: комментарий от max_lapshin

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

morse ★★★★★
()
Ответ на: комментарий от Pyzia

И вот наконец-то мы неспешно подобрались к вашей истинной проблеме.

ну как бы это проблема любых on premise клаудов, т.е. проблема половины современного ынтерпрайзного мира

stevejobs ★★★★☆
()
Ответ на: комментарий от max_lapshin

Что же вы будете делать, когда один из ваших сотрудников случайно (или не очень) пропотеряет ваш драгоценный приватный ключ в чужие недобрые руки? Актуализируете, наконец, список серверов по списку злобных клиентов?

anonymous
()
Ответ на: комментарий от stevejobs

не донесешь ты эту проблему.

Тут пока тусуется школота типа morse с одним старым десктопом на фрибсд на весь класс.

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

т.е. вы предлагаете отменить пароли и шифрование?

Где именно я это предложил? Давай ссылку.

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

ya-betmen ★★★★★
()
Ответ на: комментарий от max_lapshin

Часто в маленьких командах раздают всем приватный ключ

дурной? Читать умеешь? Приватный ключ не выдается.

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

AnDoR ★★★★★
()
Ответ на: комментарий от AnDoR

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

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

В большой конторе невозможно даже составить список существующих серверов

Ути какие мы ынтерпрайзные.

Скажи, пожалуйста, что ты жирно троллишь. Ты написал в одном треде столько, что как будто хочешь совершить «цифровое самоубийство».

Deleted
()
Ответ на: комментарий от max_lapshin

крайне редко

Откуда у тебя информация о частоте и редкости?

и только для тех серверов, которые под контролем того, кто контролирует LDAP.

Разумеется. В больших конторах других не должно быть.

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

5к железных хостов - это много или мало?

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

AnDoR ★★★★★
()
Ответ на: комментарий от AnDoR

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

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

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

Я про бардак и говорю.

AnDoR ★★★★★
()
Ответ на: комментарий от max_lapshin

например, у меня была такая же проблема как у тебя, но с другим продуктом - с ansible, который управляет нашим самописным клаудом на уровне конфигурации. Мне нужно админить клауд, и его конфиг динамический, и пермишены динамические.

я это делал копированием-удалением файлов ключей на уровне Энсибла (один человек - один ключ), но есть проблема - код должен быть маниакально чистый и надежный, иначе легко создать уязвимость

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от max_lapshin

В больших конторах новые серваки появляются после согласования, введения в общую инфраструктуру(в том числе с подключением к LDAP'у и какому-нибудь ансиблу или аналогу). А выдачей прав доступа занимается специальный отдел. А для rw-доступа даже без рутовых прав на отдельные серваки(например, на прод) ещё и двухфакторная аутентификация используется. Не надо созданный тобой бардак транслировать на окружающих.

shell-script ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.