Можно ли настроить sudo на облачном сервере без пароля?

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

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

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

Разъяснения

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

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

Продолжайте 1

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

Продолжайте 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Относительно продолжения 2:

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

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

Вы можете иметь лучшее из обоих миров: 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. Поэтому, если вы хотите быть очень осторожным, вы можете сохранить отдельный файл author_keys с отдельным ключом SSH, который вы добавляете в свой агент, только когда вам нужно выполнить sudo:

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

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

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

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

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

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

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

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

Разрешить только пользователям SSH, которым это требуется, используйте AllowUsersпараметр и explicity, чтобы указать, каким учетным записям требуется доступ по SSH. Это по умолчанию заблокирует все другие учетные записи от SSH.

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

Суть этого состоит в том, чтобы не дать скомпрометированной учетной записи поставить под угрозу вашу машину. то есть. если учетная запись Салли взломана, и Салли может использовать 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 не работает, Джон также получает эти перестановки.

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

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

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

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

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

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

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

Со страницы руководства sudoers :

timestamp_timeout

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

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

Defaults timestamp_timeout=60

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

Другие ответы здесь великолепны и касаются большинства важных моментов. Одна вещь, о которой я не упомянул, это тот факт, что любой вид аутентификации, который вы делаете при входе в систему, может быть захвачен удаленным злоумышленником, который уже установил точку опоры в вашей учетной записи. Они могут изменить ваши файлы входа в оболочку или PATH для установки кейлоггера, чтобы им отправлялось все, что вы вводите, включая ваш пароль sudo. Они могут добавить взломанный двоичный файл sudo в вашу PATH для сбора вашего пароля. Они могут перехватить соединение агента ssh обратно на вашу подключающую машину, чтобы победить pam_ssh_agent_auth и сами стать пользователем root, как только вы подключитесь. Таким образом, с точки зрения абсолютной безопасности, я не вижу разницы между использованием пароля для sudo и нет. Это, конечно, делает его более сложной атакой,

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