Это в порядке для установки 'sudo' без пароля на облачном сервере?

I generally restrict use of NOPASSWORD to commands that are run by an automated process. It is preferable to have a service account for these commands, and restrict the use of sudo to the required commands.

Allowing NOPASSWORD for general commands, allows anyone who gets access to your userid to run any commands. This could result from a compromise of your credentials, but could be as simple as someone sitting at your desk when you step away for a second.

I find I don't have to enter my password that often. Once you enter your password, you can run several commands if you don't wait too long between them. The timeout is configurable.

I would only use this in two circumstances:

• When it is absolutely required for an automated script that is running as a specific user
• For specific admin tasks (read only admin tasks, not those that take action to alter the system) and then only for specific users of course

By default most sudo configurations will not ask you again for a while in the same session (if you open a new shell that doesn't have any effect). You can control this behaviour to an extent with the timestamp_timeout setting.

Password-less sudo is not nearly as dangerous as passphrase-less ssh keys, as a remote attacker needs your credentials to get in in the first place, but if they have got in by somehow compromising your private key (or if they are physically local to you and you've left yourself logged in and unlocked while away from the machine) then the password request is a valuable extra defence between them and privileged access.

Regarding follow-up 2:

If I also have a key to log in as root via ssh

This is best avoided too, for exactly the reason you describe. If a remote connection must have privileged access have it login via a service account and give that just enough control to do its job via sudo. This is more faf to configure of course so many don't bother (which works in your favour if you do, as there is plenty of lower hanging fruit than you for attackers to spend there time on!), so it comes down to the age old compromise between security and convenience (pro tip: pick security!).

У вас может быть лучшее из обоих миров: 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

In some cases it's necessary to do this. e.g. some hypervisor API's need passwordless login and passwordless sudo. But you can still restrict that without breaking.

For what you're trying to achieve. I'd say, get used to typing in a password. Security is more convenient that convenience here. Besides, if you really need root access you can use sudo and it'll cache the credentials for a little while so that if you run several sudo commands in a row it'll only prompt for the password the first time. So it's not such a big inconvenience as you suppose.

Also if you're typing in a lot of root privileged commands and don't want to put sudo on the front of them all the time you can either su or sudo -s to get a root shell. You'll enter your password once and then that's it.

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

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

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

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

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

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

Запретить вход в систему с правами root через SSH с помощью параметра AllowRootLogin no в вашем sshd_config. Это предотвратит взлом вашей учетной записи root. Это' s просто хорошая практика никогда не позволять кому-либо напрямую входить в учетную запись 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 не работает, Джон тоже получает эти перестановки.

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

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

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

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

и используйте это. Обычно это дает вам что-то длиной более 8 символов, обеспечивающее много энтропии, но также легче запоминается, чем какой-то случайный пароль. Конечно, хорошая практика паролей гласит, что нужно использовать сгенерированный машиной случайный пароль, чтобы обмануть инструменты взлома, такие как John the Ripper, которые перебирают большинство парольных фраз и паролей. Нет, замена E на 3 не работает, Джон тоже получает эти перестановки.

и используйте это. Обычно это дает вам что-то длиной более 8 символов, обеспечивая много энтропии, но также легче запоминается, чем какой-то случайный пароль. Конечно, хорошая практика паролей гласит, что нужно использовать сгенерированный машиной случайный пароль, чтобы обмануть инструменты взлома, такие как John the Ripper, которые перебирают большинство парольных фраз и паролей. Нет, замена E на 3 не работает, Джон тоже получает эти перестановки.

Джон тоже получает эти перестановки.

Джон тоже получает эти перестановки.

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

Со страницы sudoers man page:

timestamp_timeout

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

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

Defaults timestamp_timeout=60

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

.

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

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

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

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

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