Мне нравится идея доступа к серверам с помощью ключей, так что мне не нужно вводить пароль каждый раз, когда я ssh в ящик, я даже блокирую своего пользователя (не root) пароль (passwd -l username) так что это невозможно войти без ключа.
Но все это ломается, если мне нужно ввести пароль для sudo команды. Так что у меня возникает соблазн создать без пароля sudo чтобы привести все в соответствие с логином без пароля.
Тем не менее, у меня все еще есть внутреннее чувство, что это может иметь неприятные последствия для меня каким-то неожиданным образом, это просто кажется каким-то небезопасным. Есть ли предостережения при такой настройке? Вы бы рекомендовали / не рекомендовали бы делать это для учетной записи пользователя на сервере?
Разъяснения
sudo здесь в интерактивном сеансе пользователя, а не для служб или административных скриптов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 - для учетных записей служб, где процессы должны иметь возможность запускать команды через sudo программно. В таких случаях убедитесь, что вы явно занесли в белый список только конкретный команды, которые необходимо запустить для учетной записи. Для интерактивных учетных записей вам следует всегда оставьте пароли включенными.
Ответы на дополнительные вопросы:
Но я предполагаю, что если я отключу аутентификацию по паролю в / etc / ssh / sshd_config, чтобы у вас все еще был ключ для входа в систему, я могу использовать более простой пароль только для sudo, который легче вводить? Это действенная стратегия?
Да, это правильно. Я по-прежнему рекомендую использовать относительно надежные пароли локальных учетных записей, но не слишком надежные. ~ 8 символов, генерируется случайным образом.
Если у меня также есть ключ для входа в систему как root через ssh, если кто-то получит доступ к моему компьютеру и украдет мои ключи (хотя они все еще защищены паролем связки ключей ОС!), Они также могут получить прямой доступ к учетная запись root, минуя путь sudo.
Должен быть отключен рут-доступ по ssh. Период. Устанавливать PermitRootLogin no в твоем sshd_config.
Какой тогда должна быть политика для доступа к учетной записи root?
У вас всегда должны быть средства для получения внеполосного доступа к консоли вашего сервера. Некоторые поставщики VPS предоставляют это, как и поставщики специализированного оборудования. Если ваш провайдер не предоставляет реальный доступ к консоли (например, EC2), вы, как правило, все равно можете восстановить доступ, используя процесс, подобный тому, что я описываю в этот ответ.
Я обычно ограничиваю использование NOPASSWORD к командам, выполняемым автоматизированным процессом. Желательно иметь учетную запись службы для этих команд и ограничить использование sudo необходимыми командами.
Разрешение NOPASSWORD для общих команд позволяет любому, кто получает доступ к вашему идентификатору пользователя, выполнять любые команды. Это может произойти из-за компрометации ваших учетных данных, но может быть так же просто, как кто-то сидит за вашим столом, когда вы на секунду отойдете.
Я обнаружил, что мне не нужно так часто вводить пароль. После ввода пароля вы можете запустить несколько команд, если не будете слишком долго ждать между ними. Тайм-аут настраивается.
У вас может быть лучшее из обоих миров: 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
Я бы использовал это только в двух случаях:
По умолчанию большинство sudo конфигурации не будут спрашивать вас снова некоторое время в том же сеансе (если вы откроете новую оболочку, которая не имеет никакого эффекта). Вы можете до некоторой степени контролировать это поведение с помощью timestamp_timeout настройка.
Без пароля sudo не так опасно, как без парольной фразы ssh ключи, поскольку удаленному злоумышленнику в первую очередь нужны ваши учетные данные, но если они проникли, каким-то образом скомпрометировав ваш закрытый ключ (или если они физически локальны для вас, и вы оставили себя авторизованным и разблокированным в то время как вдали с машины), то запрос пароля - ценная дополнительная защита между ними и привилегированным доступом.
Относительно последующих действий 2:
Если у меня также есть ключ для входа в систему как root через ssh
Этого тоже лучше избегать по той причине, которую вы описываете. Если удаленное соединение должно иметь привилегированный доступ, войдите в систему через учетную запись службы и предоставьте ему достаточно контроля, чтобы выполнять свою работу через 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 / администратора в целях аудита, а также в целях безопасности. Если вы разрешаете вход root напрямую, вы не знаете, кто вошел в систему, от кого они получили пароль и т. Д. Но, если кто-то входит в учетную запись Джимми, а затем повышает свои права до root, вы лучше понимаете, с чего начать аудит поиска (и чью учетную запись сбросить).
Разрешить доступ к SSH только тем пользователям, которым это необходимо Использовать AllowUsers в настройке и явном виде указывается, каким учетным записям требуется доступ по 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 подряд, он запросит пароль только в первый раз. Так что это не такое уж большое неудобство, как вы думаете.
Также, если вы вводите много команд с привилегиями root и не хотите постоянно помещать sudo перед ними, вы можете либо su или sudo -s получить рут-оболочку. Вы вводите свой пароль один раз, и все.
Однажды меня укусило sudo без пароля. Это был сценарий оболочки, какой-то установщик, который позвонил в 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 один раз, а не сразу.
Таким образом, я считаю, что единственный способ полностью предотвратить получение скомпрометированной учетной записи пользователя root, если у вас есть доступ sudo, - это удалить доступ sudo от себя или никогда не использовать его. Если вы не согласны, дайте мне знать, я бы хотел ошибиться!