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

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

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

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

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

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

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

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

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

No LDAP, Kerberos or any other nightmare technologies

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

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

Вот он какой ынтырпрайз прошивок видеокамер на расте...

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

неудобно: речь идет не о наших серверах и больше одного ключа туда класть очень неудобно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для атких вещей есть chef/puppet/ansible, для самых ленивых salt-ssh https://docs.saltstack.com/en/latest/topics/ssh/ очень рекомендую.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да, это было очень неявно проговорено.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

крайне редко

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

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

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

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

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

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

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

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

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

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

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

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

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

аж прослезился