Это - иллюстрация различия между аутентификацией и авторизацией.
Sudo является, прежде всего, инструментом для авторизации. Его задание состоит в том, чтобы определить, разрешают ли Вам выполнить команду с поднятыми полномочиями, и если Вы, для выполнения той команды. Запись как
bruno ALL = (ALL): ALL
в sudoers
файл позволяет пользователю bruno
выполнить любую команду с любым полномочием.
Для применения этого правила Sudo должен знать, что пользователь, вызывающий его, действительно bruno
. В принципе это может полагаться на механизм аутентификации системы: если можно выполнить команды как bruno
, это означает, что Вы уже прошли проверку подлинности как bruno
. Однако начиная с использования Sudo может иметь существенные последствия, Sudo требует некоторой дополнительной аутентификации: необходимо ввести пароль снова, иногда. Это означает, что, если Вы уехали, Ваша необслуживаемая консоль и прохожий добирается до команды выполнения как bruno
, они не смогут использовать Sudo: они смогли повреждать Вашу учетную запись, но не остальную часть системы.
Другое преимущество запроса пароля состоит в том, что он предупреждает Вас, что что-то необычное происходит. Например, приложение не может тихо звонить sudo
: это должно было бы попросить у Вас Вашего пароля, и неожиданная подсказка пароля предупредит Вас, что что-то плохо происходит.
На практике прося пароль каждый раз, когда Вы работаете, Sudo был бы раздражающим. Поэтому поведение по умолчанию состоит в том, чтобы пойти на компромисс: попросите пароля у каждых нескольких минут. Таким образом, прохожий или приложение могут нанести ущерб путем выполнения sudo
только если Вы сделали это в течение последних нескольких минут.
Декабрь 2019 обновления:
Как Chris Adams указал ниже, было довольно существенное изменение к Openssh за эти 6,5 лет, так как этот ответ был записан, и существует новая опция, которая намного более безопасна, чем исходный совет ниже:
* ssh(1): expand the StrictHostKeyChecking option with two new
settings. The first "accept-new" will automatically accept
hitherto-unseen keys but will refuse connections for changed or
invalid hostkeys. This is a safer subset of the current behaviour
of StrictHostKeyChecking=no. The second setting "off", is a synonym
for the current behaviour of StrictHostKeyChecking=no: accept new
host keys, and continue connection for hosts with incorrect
hostkeys. A future release will change the meaning of
StrictHostKeyChecking=no to the behaviour of "accept-new". bz#2400
Таким образом вместо установки StrictHostKeyChecking no
в Вашем ssh_config
файл, набор StrictHostKeyChecking accept-new
.
Набор StrictHostKeyChecking no
в Вашем /etc/ssh/ssh_config
файл, где это будет глобальная опция, используемая каждым пользователем на сервере. Или набор это в Вашем ~/.ssh/config
файл, где это будет значение по умолчанию только для текущего пользователя. Или можно использовать его на командной строке:
ssh -o StrictHostKeyChecking=no -l "$user" "$host"
Вот объяснение того, как это работает от man ssh_config
(или посмотрите эту более актуальную версию):
StrictHostKeyChecking
Если этот флаг будет установлен на “да”, то ssh никогда не будет автоматически добавлять ключи хоста к
$HOME/.ssh/known_hosts
файл, и отказывается соединяться с хостами, ключ хоста которых изменился. Это обеспечивает максимальную защиту против нападений троянского коня, однако, может быть раздражающим когда/etc/ssh/ssh_known_hosts
файл плохо сохраняется, или связи с новыми хостами часто устанавливаются. Эта опция вынуждает пользователя вручную добавить все новые хосты. Если этот флаг будет установлен на "нет", то ssh автоматически добавит новые ключи хоста к пользователю известные файлы hosts. Если этот флаг будет установлен “спросить”, то новые ключи хоста будут добавлены к пользователю известные файлы хоста только после того, как пользователь подтвердил то, именно это они действительно хотят сделать, и ssh откажется соединяться с хостами, ключ хоста которых изменился. Ключи хоста известных хостов будут проверены автоматически во всех случаях. Аргумент должен быть “да”, "нет" или “спросить”. Значение по умолчанию, “спрашивают”.
Можно добавить цифровой отпечаток к known_hosts каждого сервера. Для отдельного пользователя:
cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts
Проигнорируйте HostKeyChecking. Для этого я использую, например:
ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null user@example.net
Добавьте цифровой отпечаток хоста/сервера к .ssh/known_hosts
до Вашего первого подключения. Это - более безопасный путь.
ssh-keyscan
- Соберите ssh открытые ключи
Если Вы уже будете знать список хостов, то Вы соединитесь с, можно просто выйти:
ssh-keyscan host1 host2 host3 host4
Можно дать -H
опция иметь его хеширует результаты как ssh значения по умолчанию к теперь
Также можно дать -t keytype
были keytype, dsa
, rsa
, или ecdsa
если у Вас есть предпочтение относительно который тип ключа захватить вместо значения по умолчанию.
После того как Вы работали ssh-keyscan
это предварительно заполнит Ваш известный файл hosts, и у Вас не будет ssh выяснением у Вас для разрешения добавить новый ключ.
Перед попыткой выполните следующий фрагмент кода.
mkdir -p ~/.ssh
echo "Host *" > ~/.ssh/config
echo " StrictHostKeyChecking no" >> ~/.ssh/config
ps :Строго не для рабочих серверов, остерегайтесь ManInMiddle
Мне нравится ответ Тима на разовые вещи, однако, если это хост, к которому вы собираетесь подключаться на регулярной основе, я бы создал запись в вашем ~/.ssh/config (создать его, если файл не существует ).
# this example shows wildcard for IP
# you can even use more than one wildcard 10.0.*.* for example
Host 192.168.56.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
# you can even alias it, which is really useful when scp'ing/rsyncing foo:/path/to/remote
Host foo
HostName foo-long-192-10-135-55.hostname.not-going-to-remember.doh
StrictHostKeyChecking no
UserKnownHostsFile /dev/null