Как сделать авторизацию sudo по ssh-ключу?

Question

[Unicom]

Суть во в чем:

1. Сделал юзера, дал ему sudo, запретил парольную авторизацию, запретил логин root
   
2. Каждый раз при запросе sudo спрашивает пароль
   
3. Если пароль убрать или сделать ненадежным (сейчас более 20 символов), это как говорят дырка, но а вообще нахрена козе баян и зачем при отказе от пароля при авторизации на сервере теперь мне нужно вводить пароль для подтверждения прав рута? Логика неконсистентная более чем полностью.
   

Должно быть что-то одно:

• Или отказ от авторизации по паролям и авторизация только по ключу мера достаточная и root убирать никуда не надо
  
• Или необходимо сделать консистентную авторизацию, т/е sudo должно спрашивать не пароль у пользователя, а RSA ключ у ssh клиента.
  

Есть еще вариант убрать полностью пароль у sudo но тогда какой вообще в нем смысл? Это по сути будет тот же root со ступенькой (необходимость каждый чих вводить через sudo)

Я решил пойти вторым путем и сделать авторизацию через ssh ключи, и использовать pam_ssh_agent_auth
Делал согласно этой инструкции:
mike.depalatis.net/ssh-agent-for-sudo-authenticati...

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

Какие мысли?

Comments

[Maxim Kovalenko]

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

[Unicom]

Maxim Kovalenko: Конечно не от рута. Зачем руту судо? Вопрос не сделать авторизацию по ключам на сервере. А сделать авторизацию по ключу в sudo

[Maxim Kovalenko]

Unicom: Sudo умеет только то, что подскажет man
Давайте попробуем решить житейскую задачу, которая перед вами стоит.
Сформулируйте что вам нужно сделать?

[Unicom]

Вы ошибаетесь, существуют модули PAM, в том числе и для sudo в том числе один указан в вопросе

Answer 1

[mikes]

если у тебя есть пользователь который постоянно работает с правами root то есть варианты
1. включить его в группу root
2. просто включить логин root и не париться на счет пользователя
3. в sudoers прописать нужные команды которые будут выполняться для него без запроса пароля.
4. использовать sudo -i и выполнять дальше от имени root вписав свой пароль всего лишь 1 раз.

Comments

[Unicom]

1) И что, это безопасно? Включение в эту группу избавить от sudo или от пароля для sudo
2) Миллионы инструкций говорят что это небезопасно, хотя я логики и не вижу в их доводах. По крайней мере sudo без пароля - это действительно бессмысленно. Лучше уж от root заходить по ключу
3) Это полумера. Я не знаю безопасных команд, а при администрировании может потребоваться любая в том числе и самые опасные.
4) Как вариант, но опять же неконсистентный.

[mikes]

Unicom: все что связано с правами root несет потенциальную опасность. Вы точно доверяете этому пользователю?
Попытка сделать пользователя с правами root но не сообщать ему пароль от учетки не приведет вас к успеху. если у человека есть sudo, то он может переделать все что хочет на сервере.

безопасные и не безопасные команды?? тогда vim и nano будут самыми опасными уж точно :)
пожалуй надо определится для чего сервер и что человек на нем будет делать и из этого исходить по набору доступного через sudo

[Unicom]

mikes: Сразу поясняю, на сервере (вебсервер) человек только я. Все остальные юзеры вспомогательные и доступа по ssh никуда не имеют.

[mikes]

Unicom: тогда в чем проблема с правами.. есть вы, у вас есть sudo. остальных запихнуть в chroot ssh и пусть себе правят свои сайтики

[Unicom]

mikes: нет никаких ни у кого сайтиков и нет никого кроме меня. У меня проблема - не хочу sudo с паролем, если у меня авторизация по ключам. И вообще думаю забью на все и верну рута на сервер - к черту это судо, безопасности оно не добавляет серверу где есть один администратор, а гемороя создает на порядок больше.

[mikes]

Unicom: дело ваше.. на мой взгляд что нить вроде %username% ALL=(ALL) NOPASSWD:ALL в /etc/sudoers вполне решит проблему пароля для пользователя.

[Unicom]

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

[Saboteur]

Причина - защита от дурака.
Чтобы случайно не выполнить команду от рута, работаешь под своим пользователем. Если нужно выполнить рутовую команду - тогда sudo.

Вот и все. Это как рекомендации "не работать в винде с административными правами". Все хорошо, пока не поймаешь какой-нить вирус, который с текущими правами сразу может и службу создать и драйвер поставить.

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

[Unicom]

Сергей: нет на сервере "просто работы". Там есть администрирование сервера - там для всего вообще нужен рут.

[Saboteur]

top посмотреть? df посмотреть? - для этого рут не нужен.

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

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

В общем либо у вас уникальнейшая задача, при которой sudo действительно не удобно, либо вы придумали свой велосипед, который не совпадает с best practice при которой sudo - удобно.

[Unicom]

Сергей: ну посмотрел я top, правда вот для этого я действительно не вижу необходимости идти на сервер по ssh. Я его не просто так на ночь лицезрею, значит что-то поломалось или нагрузка или еще что-то. Значит нужны рут права. Про каждый день никто не говорил. Это нужно иногда. А вы каждый день ходите top/htop смотреть?

Что за best practice? Делать пароль на пользователя коротким? Или вообще отключать этот пароль ибо раздражает каждую команду с ним вводить? Речь в вопросе про неконсистентность подхода, а она видимо вызвана тем что реально никакое sudo на сервере в обычном случае не надо. В серверном Debian 8 судо по умолчанию нет. Видимо это и есть best practice

[Saboteur]

Нагрузка должна мониториться не в ssh

если что-то поломалось, пришел, ввел sudo и работай. Если что-то ломается так часто, что надоело вводить sudo - надо чинить глобально.

Я к тому, что на большинстве серверов, где я что-либо админю, я sudo набираю ну может быть раз из 10 заходов, а захожу реже раза в неделю.

[Saboteur]

Кроме того, у вас видимо что-то сломалось, ибо после ввода пароля на sudo, в течение некоторого времени пароль не нужен. Посмотрите настройки.

Ну и если нужно много команд, sudo bash никто не отменял

Answer 2

[aol-nnov]

а как насчет

PermitRootLogin without-password

и добавить руту в authorizrd_keys свой ключ?
и не думать ни о чём?

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

Comments

[Unicom]

Вообще парольная авторизация отключена. Только ключи, неважно рута или нет.

[Unicom]

PermitRootLogin no / PasswordAuthentication no

[Unicom]

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

[aol-nnov]

Unicom: ну и? :)
если ты не разглядел, я тебе предложил альтернативу твоим суду и выкрутасам с памами и ссш-агентами. явно меньше движущихся частей тут. и настраивать проще. :)

[Unicom]

Не понял что предложил? У меня и сейчас доступ по паролям полностью закрыт. Другое дело, нужно ли действительно для администратора ходить через левого юзера и повышать права через судо? Складывается впечатление, что нет и нужно выкинуть на помойку 100% мануалов в рунете про настройку сервера и в частности SSH

[mikes]

Unicom: дело в концепции работы. ты работаешь под своим пользователем и иногда повышаешь свои привилегии. меньше шансов накосячить.

[aol-nnov]

> Не понял что предложил?
Unicom: ну как что? заход рутом через ssh по ключу же!
Если у тебя PermitRootLogin no, то ты напрямую рутом не зайдешь, даже если подложишь ему ключик в authorized_keys. С опцией, что я тебе показал - зайдешь. И только по ключу.
Что выбрать - решать тебе :)

[Владимир Олохтонов]

Unicom: работать с рутовыми правами норм, просто нужно отдавать себе отчет в том, что именно ты делаешь. В этом плане набор 20-значного пароля как раз даёт время подумать :)

[aol-nnov]

mikes: "меньше шансов накосячить." - очень, очень спорное утверждение.
если ты на автомате набираешь rm -rf, то тут уже не важно, спросили тебя пароль перед этим или нет.
Те, кто считает, что суду - защита от собственных косяков - заблуждаются :)
Это как "лучшее противозачаточное - таблетка аспирина, зажатая между колен" :-D

[mikes]

aol-nnov: ну если вы так уверены в себе :) то оно да

[aol-nnov]

mikes: "не уверен - не обгоняй" и "выпил - за руль не садись" :)) всё просто, как два байта переслать ;)

[Unicom]

mikes: на сервере не работают, сервер администрируют. Там вобщем-то без прав рута делать нечего никому.

[Unicom]

aol-nnov: уже склоняюсь к мыли забить на судо и открыть назад доступ руту. 100% безопасных инструкций по настройке сервера в рунете - хлам.

[mikes]

Unicom: я бы не был столь категоричен :)

[Unicom]

mikes: я действительно не видел ни одной инструкции где одним из первых пунктов не шло бы отключите нафиг рут, сконфигурируйте доступ по ключам, отключите пароли. Между тем следует, что это вообще взаимоисключающие пункты, т/к без рута не залогиниться и нужен другой юзер, которому нужно sudo, которое вообще нафиг на сервере не надо, т/к все равно все нужно делать от суперадмина и судо становится неконсистентной хренью в системе где вся авторизация без пароля (да, ключевая фраза к моим ключам тоже имеется но в маке за меня ее вводит сам клиент беря из связки ключей, что меня полностью избавляет от паролей и повышает секюрность, т/к эта фраза сама может являться ключом из-за своей дины). А от получить по башке табуреткой и темном углу или терморектальный метод для тех кому ДЕЙСТВИТЕЛЬНО НАДА ваших данных вообще не спасут никакие судо, руты и ключи.

Answer 3

[Юрий Чудновский]

Вообще-то ssh и sudo это совершенно разные вещи. Если хотите по ключу, то
1) впишите в /etc/hosts какое-нибудь короткое имя компу, например 127.0.0.1 me
2) положите руту ключ
3) вместо sudo -s делайте ssh root@me
Разумеется, при этом вы не сможете запускать гуёвые программы (добавьте -X).

Comments

[Unicom]

1) Разве из моих вводных не ясно что речь идет о сервере?
2) Вообще не понимаю о чем вы, почитайте пожалуйста вводные к вопросу

[Unicom]

3) И то что это разные вещи не запрещает авторизации по ключам через PAM

[Юрий Чудновский]

Unicom: если сервер - зачем вообще париться с sudo с левого пользователя (который не нужен просто на сервере), почему бы не заходить сразу ключом по ssh? Зачем городить костыли с ковырянием PAM?

[Unicom]

Юрий Чудновский: да, видимо так и сделаю. Речи сейчас идет что все без исключения инструкции по настройке говорят первым пунктом - отключите рут на сервере.

[Юрий Чудновский]

Unicom: если под "отключением" имеется в виду запрет на вход по паролю (удаление пароля, отключение входа без пароля и логина по ssh) - это нормально. По sudo из пользователя переходите в рута, проблема будет только если корень и хомяк на разных разделах и вам потребуется залогиниться рутом в физическую консоль чтобы починить упавший хомяк (когда под юзером нельзя залогиниться).
То, что ssh просит пароль - совершенно не проблема, так как 1) можно сделать sudo -s; 2) sudo запоминает credentiales на некоторое время 15-30 минут в стандартных конфигах) и не требует повторного ввода, если не оттикал таймер от последнего использования

Answer 4

[Андрей Векличев]

Мои мысли и как я делаю у себя :)
Пароль для ссш нельзя - чтоб не подобрали. Выход - используем ключи (как бы ясно)
Пароль должен быть сложный, просто потому что мало ли. Сгенерили, записали, закрыли под замок.
У админа должна быть учетка не равная root, например neroot. Чтоб не догадались. Потому что боты часто ломятся под root.
А еще порт сменить...
Сделать судо без пароля :) потому что удобно.

Ну и надо понимать, что в системе должны быть разные пользователи. Тоесть как бы root - это системный, а твой neroot будет для админа. А www-data для веб сервера. И тогда будет понятно кто что сломал и зачем ты пьяный заходил на сервер (ну это если логи есть). Как то так...