Вопросы Теги

как избежать ssh выяснение у разрешения?

Это - иллюстрация различия между аутентификацией и авторизацией.

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

bruno ALL = (ALL): ALL

в sudoers файл позволяет пользователю bruno выполнить любую команду с любым полномочием.

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

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

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

62
03.03.2012, 01:06
6 ответов

Декабрь 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 откажется соединяться с хостами, ключ хоста которых изменился. Ключи хоста известных хостов будут проверены автоматически во всех случаях. Аргумент должен быть “да”, "нет" или “спросить”. Значение по умолчанию, “спрашивают”.
94
27.01.2020, 19:32
  • 1
    +1, я также это для моих серверов. И только быть ясным, сообщение в вопросе появляется от ssh клиента в соединяющийся клиентский компьютер а не с сервера. –  Patkos Csaba 02.03.2012, 22:53
  • 2
    Этот ответ походит на проблему безопасности в процессе создания. –  SunSparc 15.06.2016, 23:59

Можно добавить цифровой отпечаток к known_hosts каждого сервера. Для отдельного пользователя:

cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts
12
27.01.2020, 19:32
  • 1
    Это больше не правильный способ сделать это с тех пор, когда хеширование было представлено. –  Deim0s 20.04.2015, 12:38

Проигнорируйте хост

Проигнорируйте HostKeyChecking. Для этого я использую, например:

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null user@example.net

Добавьте хост

Добавьте цифровой отпечаток хоста/сервера к .ssh/known_hosts до Вашего первого подключения. Это - более безопасный путь.

11
27.01.2020, 19:32
  • 1
    Привет. Oracle дает ssh команду, таким образом, я не имею никакого контроля над тем, как она выполняет это. –  Nicolas de Fontenay 03.03.2012, 00:49

ssh-keyscan - Соберите ssh открытые ключи

Если Вы уже будете знать список хостов, то Вы соединитесь с, можно просто выйти:

ssh-keyscan host1 host2 host3 host4

Можно дать -H опция иметь его хеширует результаты как ssh значения по умолчанию к теперь

Также можно дать -t keytype были keytype, dsa, rsa, или ecdsa если у Вас есть предпочтение относительно который тип ключа захватить вместо значения по умолчанию.

После того как Вы работали ssh-keyscan это предварительно заполнит Ваш известный файл hosts, и у Вас не будет ssh выяснением у Вас для разрешения добавить новый ключ.

27
27.01.2020, 19:32
  • 1
    я немного озадачен о, "предварительно заполнит" комментарий... known_hosts, не создается или изменяется после выполнения этого. Вы подразумеваете, что содержание может быть передано по каналу в файл для заполнения его? –  rschwieb 23.03.2018, 15:57

Перед попыткой выполните следующий фрагмент кода. 

mkdir -p ~/.ssh     
echo "Host *" > ~/.ssh/config     
echo " StrictHostKeyChecking no" >> ~/.ssh/config

ps :Строго не для рабочих серверов, остерегайтесь ManInMiddle

4
20.08.2021, 13:28

Мне нравится ответ Тима на разовые вещи, однако, если это хост, к которому вы собираетесь подключаться на регулярной основе, я бы создал запись в вашем ~/.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
0
20.08.2021, 13:28

Теги

Похожие вопросы