Вопрос: Можно ли настроить пароль sudo` на сервере облаков?


Мне нравится идея доступа к серверам с помощью ключей, поэтому мне не нужно вводить пароль каждый раз, когда я ssh в ящик, я даже блокирую пользователя (не root) пароль (passwd -l username) так что это невозможно для входа в систему без ключа.

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

Тем не менее, у меня постоянно возникает ощущение, что это может иметь неприятные последствия для меня каким-то неожиданным образом, это просто кажется неуверенным. Существуют ли какие-либо предостережения с такой настройкой? Вы порекомендовали бы / не рекомендовали бы сделать это для учетной записи пользователя на сервере?

Разъяснения

  1. Я говорю об использовании sudo в интерактивном сеансе пользователя здесь, а не для служб или административных сценариев
  2. Я говорю об использовании облачного сервера (поэтому у меня нет физического локального доступа к машине и можно только удаленно регистрироваться)
  3. я знаю это sudo имеет тайм-аут, в течение которого мне не нужно повторно вводить пароль. Но мой концерт заключается не в том, чтобы тратить лишнее время на физический ввод пароля. Моя идея, однако, заключалась в том, что мне вообще не приходилось иметь дело с паролем, потому что я предполагаю, что:
    • Если мне нужно запомнить это вообще, это очень вероятно слишком короткое, чтобы быть безопасным или повторно использовать
    • Если я создам длинный и уникальный пароль для моей удаленной учетной записи, мне придется где-то ее хранить (локальную программу управления паролями или облачную службу) и извлекать ее каждый раз, когда я хочу использовать sudo, Я надеялся, что смогу этого избежать.

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

Последующие действия 1

Все ответы говорят, что без пароля sudo небезопасно, так как позволяет «легко» эскалацию привилегий, если моя личная учетная запись пользователя скомпрометирована. Я это понимаю. Но, с другой стороны, если я использую пароль, мы берем на себя все классические риски с паролями (слишком короткая или обычная строка, повторяющаяся через разные службы и т. Д.). Но я предполагаю, что если я отключу проверку подлинности в /etc/ssh/sshd_config так что у вас все еще должен быть ключ для входа в систему, я могу использовать более простой пароль только для sudo это легче ввести? Это правильная стратегия?

Последующие действия 2

Если у меня также есть ключ для входа в систему, root через ssh, если кто-то получает доступ к моему компьютеру и крадет мои ключи (они все еще защищены паролем с ключом ОС, хотя!), они могут также получить прямой доступ к root учетной записи, минуя sudo дорожка. Какова должна быть политика доступа к root аккаунт тогда?


56
2018-03-09 21:40


Источник


Не рекомендовал бы это вообще, потому что часто есть способы получить оболочку как пользователь (поскольку все службы подвержены нарушениям безопасности, но обычно они запускаются как пользователь, чтобы избежать полного доступа к системе), но имеют пароль для входа в систему как root предотвращает доступ неавторизованных пользователей. Если их нет, считается, что любой, кто получает доступ к вашей учетной записи пользователя каким-либо образом, имеет полный доступ к серверу. Установка пароля может быть немного, но это помогает. - piernov
См. Мои последующие вопросы - Dmitry Pashkevich
sudo никогда не должен быть без пароля. root должен быть отключен из удаленного входа в систему через SSH, порт ssh не должен быть по умолчанию (чтобы отключить гантели), и любая учетная запись, требующая sudo, должна быть ограничена только минимальными полномочиями sudo для всех, что им нужно (перезапустить службу только и т. д.), а также имеют очень сильные пароли. - SnakeDoc
@SnakeDoc Спасибо, это своего рода ответ, который я ожидал. Позаботьтесь, чтобы написать подробный ответ? Я рад узнать! - Dmitry Pashkevich
@EEAA на самом деле это довольно просто в Linux. Единственными учетными записями, которые должны быть разрешены без пароля в sudo, будут системные учетные записи, на которые невозможно войти в систему и, следовательно, не могут поднять эту учетную запись и использовать эти разрешения для вас. Установите фальшивую оболочку для учетной записи в /etc/passwd например, nologin, не задавать пароль, а затем вводить пароль в visudo. Если вы это сделаете, вы также должны убедиться, что параметр visudo предназначен только для того, что абсолютно необходимо для этой системной учетной записи, то есть заблокируйте ее до единственных команд, которые она должна когда-либо запускать. - SnakeDoc


Ответы:


Мне нравится идея доступа к серверам через ключи, так что мне не нужно   введите мой пароль каждый раз, когда я ssh в поле, я даже заблокирую свой пользовательский   (не root) пароль (passwd -l имя пользователя), поэтому невозможно войти в систему   без ключа ... Вы бы порекомендовали / не рекомендовали сделать это для   учетной записи пользователя на сервере?

Вы собираетесь отключить логины с паролем неправильно. Вместо блокировки учетной записи пользователя установите PasswordAuthentication no в вашей /etc/ssh/sshd_config,

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

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

Ответы на ваши последующие вопросы:

Но я предполагаю, что если я отключу проверку подлинности в   / etc / ssh / sshd_config, чтобы у вас все еще был ключ для входа в систему, я   может использовать более простой пароль только для sudo, который легче ввести? Является   что действительная стратегия?

Да, это правильно. Я по-прежнему рекомендую использовать относительно сильные локальные пароли учетных записей, но не смехотворно. ~ 8 символов, произвольно сгенерированных.

Если у меня также есть ключ для входа в систему через root через ssh, если кто-то получит   доступ к моему компьютеру и кражу моих ключей (они все еще защищены   OS 'keyring password хотя!), Они могли бы также получить прямой доступ   к учетной записи root, минуя путь sudo.

Корневой доступ через ssh должен быть отключен. Период. Задавать PermitRootLogin no в вашей sshd_config,

Какова должна быть политика доступа к учетной записи root?

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


46
2018-03-09 21:48



+1 должен оставить пароль ... - Chris S
+1 пароль sudo не действительно там для secutiry (насколько я вижу), но больше как проверка идиот. Не может быть причиной невыразимого хавока. - Boris the Spider
если вы потеряете свой ключ, вы закончите, если у вас нет бэкдора, но тогда и злоумышленник. единственный способ исправить потерянный ключ, если он будет выполнен правильно, - это физически физически сидеть на самом терминале. Если вам нужна защита, предоставляемые ssh-ключами, вы должны знать о подводных камнях и просто ... просто не теряйте свои ключи. - SnakeDoc
Комментарий к вашему последнему абзацу и относительно отказа в доступе в целом для любого VPS ... некоторые провайдеры VPS действительно помогут вам, если вы заблокируетесь. У меня была одна загрузка моей виртуальной машины в режим одиночного пользователя и сделать некоторые вещи для меня, когда я заперся (это происходит ... плохое правило брандмауэра lol). В зависимости от вашего хоста они могут взимать плату за услугу, они , в конце концов, уделяя особое внимание вам. Кроме того, некоторые будут делать резервные копии / снимки за небольшую цену или иногда бесплатно, что может стоить того, если вы собираетесь совершить большое, возможно, разрушительное изменение. - SnakeDoc
@DmitryPashkevich - относительно PasswordAuthentication затрагивая всех пользователей, вы всегда можете использовать Match разделы в sshd_config, чтобы включить его для определенных пользователей или групп. - Matt Thomason


Я вообще ограничиваю использование NOPASSWORD к командам, выполняемым автоматизированным процессом. Желательно иметь учетную запись службы для этих команд и ограничивать использование sudo требуемыми командами.

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

Я считаю, что мне не нужно часто вводить мой пароль. После ввода пароля вы можете запускать несколько команд, если между ними не слишком долго ждать. Тайм-аут настраивается.


10
2018-03-10 00:18





Я бы использовал это только в двух обстоятельствах:

  • Когда он является абсолютно требуется для автоматизированного сценария, который работает как конкретный пользователь
  • Для конкретных задач администратора (только для чтения, а не для тех, кто предпринимает действия для изменения системы), а затем только для конкретных пользователей, конечно

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

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

Что касается последующих мер 2:

Если у меня также есть ключ для входа в систему через root через ssh

Этого лучше избегать и по той причине, которую вы описываете. Если удаленное соединение должно иметь привилегированный доступ, войдите в систему через учетную запись службы и дайте ему достаточно контроля, чтобы выполнить свою работу через sudo. Это больше faf для настройки, конечно, поэтому многие не беспокоятся (что работает в вашу пользу, если вы это сделаете, так как есть много более низких висящих фруктов, чем вы, чтобы нападавшие проводили там время!), Так что это сводится к старый компромисс между безопасностью и удобством (про подсказка: выберите безопасность!).


8
2018-03-10 09:47



Спасибо, что обратились к моей последующей работе №2. Я все еще смущен: я стараюсь избегать входа в систему, поскольку root напрямую, но мне нужен НЕКОТОРЫЙ способ доступа к учетной записи, не так ли? Итак, как мне это сделать? С паролем, а не с ключом ssh? Но не лучше ли ключи, чем пароли? - Dmitry Pashkevich
Вы всегда можете входить в систему локально с правами администратора, но рекомендуется, чтобы прямые логины для root с удаленных хостов (через ssh или аналогичные) были полностью отключены. Если у вас есть учетная запись, которая может стать root через sudo (с паролем, конечно), вы никогда не потеряете доступ к этой учетной записи. - David Spillett


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

Я использую это в производстве более пяти лет.

Чтобы настроить его, установите модуль PAM, а затем добавьте строку в /etc/pam.d/sudo или эквивалент вашей системы:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

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

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

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

7
2018-03-12 12:34



Вау, это здорово! Так что я создаю отдельный ключ для выполнения sudo или я использую тот же, который использовался для аутентификации SSH? - Dmitry Pashkevich
Это потрясающе. Если бы я мог, я бы поднял вас несколько раз. - nyuszika7h
Вы можете использовать тот же ключ, что и для обычной проверки подлинности SSH, или для дополнительной безопасности, вы можете временно добавить ключ, который вы используете для sudo-ing для вашего агента аутентификации SSH. Для этого потребуется указать другой файл, кроме ~/.ssh/authorized_keys, вы можете управлять другим файлом, ~/.ssh/authorized_keys_sudo например, или /etc/ssh/authorized_keys_sudo, - obscurerichard


Поскольку вы спросили, вот мой общий совет о том, как обратиться к sudo вопрос.

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

Правильно настроенная Sudo не будет использовать ALL=(ALL) ALL но скорее чем-то более ограниченным тем, что конкретно требуется пользователю. Например, если вам нужен пользователь для входа в систему и перезагрузки застрявшего сервиса, им, вероятно, не потребуется установка нового программного обеспечения или выключение сервера, изменение правил брандмауэра и т. Д.

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

Как я защищаю свои боксы:

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

Запретить вход в root через SSH с помощью AllowRootLogin no в вашем sshd_config. Это не позволяет кому-то из грубых форсировать ваш корневой аккаунт. Как правило, хорошей практикой никогда не позволять кому-либо напрямую входить в учетную запись root / администратора по причинам аудита, а также по безопасности. Если вы разрешаете вход root напрямую, вы не знаете, кто вошел в систему, кто у них есть пароль, и т. Д. Но если кто-то войдет в учетную запись Jimmy, то повысит их права на root, у вас есть идея, с чего начать аудит поиска (и счет учетной записи для сброса).

Только разрешить пользователям SSH, которые этого требуют Использовать AllowUsers настройка и объяснение указывают, для каких учетных записей нужен SSH-доступ. По умолчанию блокируются все остальные учетные записи из SSH.

Редактируйте Sudoers с помощью visudo и разрешите только команды, которые нужны пользователю. Есть много подробных руководств о том, как это сделать, поэтому я не буду здесь останавливаться. Вот стартер: http://ubuntuforums.org/showthread.php?t=1132821

Суть этого заключается в том, чтобы предотвратить скомпрометированную учетную запись, угрожающую вашей машине. то есть. если учетная запись Sally будет взломана, и Салли может использовать sudo только для перезапуска веб-сервера, и злоумышленник может повеселиться, перезапустив ваш веб-сервер в цикле, но по крайней мере они не могут rm -rf /your/webserver/directory или открыть все порты брандмауэра и т. д.

Установите правильные правила брандмауэра, которые разрешают только порты, необходимые для работы вашего окна. Как правило, вы хотите отказаться от всего и разрешить явно то, что вам нужно. Есть много достойных iptables, и другой брандмауэр запускается в сети, вот тот, который я использую (это основной стартер):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Также ключевым является сильный пароль. Даже если вы используете SSH-ключи для удаленного доступа, вам все равно потребуется пароль для использования Sudo. Это случай, когда sudo может обеспечить некоторую дополнительную безопасность. Если кто-то должен был украсть ваши ключи ssh, им все равно не удастся сделать что-либо значимое на вашем поле, если им еще нужно перевести пароль вашей учетной записи, чтобы использовать sudo. Пароли не должны быть словом, а скорее фразой. Подумайте о предложении и используйте это. Это, как правило, даст вам нечто большее, чем 8 символов, обеспечивая множество энтропии, но также легче запомнить, чем какой-то случайный пароль. Разумеется, хорошие методы работы с паролями говорят о том, что используют случайный пароль, созданный машиной, для того, чтобы обманывать инструменты для взлома, такие как John the Ripper, которые будут копироваться через большинство кодовых фраз и паролей. Нет, изменение E с 3 не работает, Джон тоже получает эти перестановки.


5
2018-03-10 19:54



Спасибо за всесторонний ответ! Я определенно должен использовать все эти советы для защиты своих ящиков. Я все равно соглашусь с ответом EEAA, хотя это немного более специфично для того, что я просил. - Dmitry Pashkevich
@DmitryPashkevich, все в порядке, у EEAA есть хороший и подходящий ответ. Вы попросили меня подробно изложить мой комментарий выше, поэтому я и сделал. Не беспокойся :) - SnakeDoc
Что касается sudo su - и вариации, sudoreplay может пригодиться. - nyuszika7h


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

За то, чего вы пытаетесь достичь. Я бы сказал, привыкнуть к вводу пароля. Безопасность удобнее здесь. Кроме того, если вам действительно нужен root-доступ, вы можете использовать sudo и он будет кэшировать учетные данные на некоторое время, так что, если вы запустите несколько команд sudo в строке, он будет запрашивать пароль только в первый раз. Так что это не такое большое неудобство, как вы думаете.

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


3
2018-03-10 03:18





Однажды я был укушен паролем sudo. Это был сценарий оболочки, какой-то установщик, который Судо от моего имени в отличие от, вы знаете, просто требуется sudo или ошибка.

Imaging набирает «make» и скрипт, выполняющий часть «sudo make install» для вас, без установки или отображения базового пути, и сценарий, являющийся настолько braindead, в первую очередь, что вы не уверены, что они знают о / usr / local и поэтому вы начинаете проверять / usr на изменения ...

Я поклялся никогда больше не использовать NOPASSWD, а также изменил этот тайм-аут на 0.


2
2017-10-17 00:05





Если вы не будете строго отвечать на свой вопрос, другим вариантом может быть установка более длинного timestamp_timeout поэтому вам не нужно вводить пароль так часто. Это предотвратит только получение прав администратора, но уменьшит ваше раздражение.

Из Страница пользователя sudoers:

timestamp_timeout

Количество минут, которое может пройти до того, как sudo снова попросит пароль. Тайм-аут может включать дробный компонент, если минимальная гранулярность недостаточна,   например, 2.5. Значение по умолчанию - 5. Задайте для этого значение 0, чтобы всегда запрашивать пароль. Если установлено значение меньше 0, метка времени пользователя никогда не истечет. Эта   могут использоваться, чтобы позволить пользователям создавать или удалять свои собственные метки времени через «sudo -v» и «sudo -k» соответственно.

Это сообщение в блоге показывает некоторые примеры с помощью visudo для установки таймаута в минутах, например:

Defaults timestamp_timeout=60

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


1
2017-09-05 03:52



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