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

58

Мне нравится идея доступа к серверам с помощью ключей, так что мне не нужно вводить пароль каждый раз, когда я вхожу 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учетной записи?

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

Ответы:

48

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

EEAA
источник
2
+1 следует оставить пароли ...
Крис С
6
+1 пароль sudo на самом деле не для безопасности (насколько я вижу), а скорее для проверки идиота. Отсутствие там может привести к неисчислимым последствиям.
Борис Паук
1
если вы потеряете свой ключ, все будет готово, если только у вас нет бэкдора, но тогда атакующий тоже. Единственный способ исправить потерянный ключ, если все сделано правильно, - это физически сидеть у самого терминала. Если вам нужна защита, которую предоставляют ssh-ключи, вы должны знать о подводных камнях и просто ... просто не теряйте свои ключи.
SnakeDoc
1
Комментарий к вашему последнему абзацу, а также о потере доступа в целом для любого VPS ... некоторые VPS-провайдеры действительно помогут вам, если вас заблокируют. У меня была одна загрузка моей виртуальной машины в однопользовательском режиме и некоторые вещи для меня, когда я заблокировал себя (это случается ... плохое правило брандмауэра, смеется). В зависимости от вашего хоста, они могут взимать плату за услугу; в конце концов, уделяя особое внимание вам. Кроме того, некоторые будут делать резервные копии / снимки за небольшую цену или иногда бесплатно, что может стоить того, если вы собираетесь совершить большое, возможно разрушительное изменение.
SnakeDoc
1
@DmitryPashkevich - что касается PasswordAuthenticationвлияния на всех пользователей, вы всегда можете использовать Matchразделы в sshd_config, чтобы включить его для определенных пользователей или групп.
Мэтт Томасон
11

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

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

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

BillThor
источник
8

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

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

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

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

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

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

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

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

Вы можете иметь лучшее из обоих миров: 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
obscurerichard
источник
Вау, это звучит здорово! Итак, я генерирую отдельный ключ для выполнения sudoкоманд или я использую тот же самый, который использовался для аутентификации SSH?
Дмитрий Пашкевич
1
Это потрясающе. Я бы проголосовал за тебя несколько раз, если бы мог.
nyuszika7h
Вы можете использовать тот же ключ, который вы используете для обычной аутентификации SSH, или для дополнительной безопасности вы можете временно добавить ключ, который вы используете для sudoing, вашему агенту аутентификации SSH. Для этого потребуется указать другой файл, чем, например ~/.ssh/authorized_keys, вы можете управлять другим файлом ~/.ssh/authorized_keys_sudoили /etc/ssh/authorized_keys_sudo.
неясный
6

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

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

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

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

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

Matt
источник
2

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

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

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

AIB
источник
1

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

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

timestamp_timeout

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

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

Defaults timestamp_timeout=60

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

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

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

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

Ян Хиндер
источник