ssh принуждает пользователя к пользователю ssh-add

Я пытаюсь понять, как работает этот функционал. У меня есть цифровой счет в океане. Я дал цифровому океану открытый ключ ssh для связи с любым сервером, который я раскручиваю. Как только я создал дроплет, если я пытаюсь подключиться к серверу по ssh от имени пользователя root, он не работает, но если я сделаю ssh-add и передам ему конкретный ключ, который я определил в своей учетной записи digital ocean, то он позволит мне войти в систему. Если бы я добавил другую учетную запись пользователя и вставил другой открытый ключ в этот файл selected_hosts для учетных записей, я мог бы войти в систему без использования ssh-add.

Может кто-нибудь объяснить мне, как работает этот функционал? Как заставить пользователя использовать ssh-add?

РЕДАКТИРОВАТЬ: Я сделал многословный SSH, кажется, пытается только эти ключи, но не другие ключи, которые у меня есть в моем каталоге.ssh, в том числе тот, который я настроил для цифрового океана. Я подозреваю, что это может быть частью проблемы.

debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/username/.ssh/id_dsa
debug3: no such identity: /Users/username/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/username/.ssh/id_ecdsa
debug3: no such identity: /Users/username/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/username/.ssh/id_ed25519
debug3: no such identity: /Users/username/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Источник

1 ответ

Решение

Я думаю, концептуально вы путаете идею запуска агента SSH с добавлением ключа к уже работающему агенту SSH.

Обычно рабочий процесс добавления ключа SSH в сеанс выглядит следующим образом:

  1. Выполните ssh-agent $SHELL, где $ SHELL может быть bash, zsh и т. д. как в ssh-agent bash
  2. Свяжите определенный закрытый ключ с сеансом оболочки агента, используя ssh-add
  3. Подключитесь к любому хосту, имеющему определенный открытый ключ для закрытого ключа, который вы используете в своем сеансе оболочки в authorized_hosts,

Обратите внимание, что вы можете использовать ssh-add -l в любое время, чтобы увидеть, какие ключи вы загрузили.

Таким образом, в этом случае вы можете подключиться к тому, что вы используете ssh-add добавить свой ключ в текущую сессию, которая будет автоматически проверяться при попытке через ssh через account@host

Вы можете увидеть пример этой проверки, если вы добавите флаги многословия в вашу попытку SSH, используя -v(vvv):

debug1: Offering RSA public key: /home/patrick/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279

С -v только, я получаю следующее: (добавление большего количества v увеличивает количество получаемой отладочной детализации)

debug1: Offering RSA public key: /home/patrick/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug1: Authentication succeeded (publickey).

Причина, по которой ваш первоначальный сеанс SSH не проходит без ssh-add может быть потому, что ваш ключ хранится в определенном каталоге, который по умолчанию не проверяется через SSH. Однако, когда вы выполняете ssh-add вы добавляете ключ ко всему сеансу, и SSH знает использовать его по умолчанию вместо поиска ~/.ssh или где-то еще.

Согласно справочной странице по SSH:

-i identity_file

Выбирает файл, из которого читается идентификатор (закрытый ключ) для RSA или DSA > аутентификации. По умолчанию используется ~/.ssh/identity для протокола версии 1 и ~/.ssh/id_rsa и ~/.ssh/id_dsa для протокола версии 2. Файлы идентификаторов также могут быть указаны для каждого хоста в файле конфигурации. Можно иметь несколько параметров -i (и несколько идентификаторов, указанных в файлах конфигурации).

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

Вы можете проверить эту теорию, используя -i флаг с SSH, чтобы проверить ваш ключ. Если бы вы должны были казнить ssh -i $KEYLOCATION account@host Вы должны получить успешный логин.

Дважды проверьте, что ваш файл закрытого ключа находится в ~/.ssh и с именем id_rsa или любым другим типом ключа. Наличие этого, вероятно, будет означать, что вам не нужно выполнять ssh-add в будущем.

Источник
Другие вопросы по тегам