2

Это связано с проблемой входа в систему DigitalOcean, которую я исследовал после прочтения этого вопроса на официальном сайте поддержки DigitalOcean. Я получал отклонения с моим начальным:

ssh root@$IP_DO

Из приведенной выше ссылки я сначала сузил ее до:

ssh -o "IdentitiesOnly yes" -i ~/.ssh/id_rsa root@$IP_DO

Когда я сделал выше, он попросил пароль. Я открыл свой менеджер паролей и, конечно же, достаточно, чтобы я установил ключевую фразу для этого ключа. Введите это, и я в.

(Если это имеет значение, я ввел открытый ключ, когда настраивал свою учетную запись Digital Ocean, и просто выбрал его для создания капли).

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

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

В обоих случаях DigitalO cean и VM ~/.ssh/authorized_keys показывают одно и то же:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC35MyHYQPWgHgxOffs2oI4jAJCTSldYr1tMb/LMogbTXtQW35mSsWexiwYjPIcdkkOl2Zqrt43696U1oZco90ibkFrbbXrqDGZssbaqfqk7
…

И, глядя на /etc/ssh/sshd_config

DigitalOcean:

egrep 'Authentication|PAM|Pass' /etc/ssh/sshd_config | grep -v '^#
RSAAuthentication yes
PubkeyAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM yes

uname -rv
4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017

Битнами В.М.

egrep 'Authentication|PAM|Pass' /etc/ssh/sshd_config | grep -v '^#'
RSAAuthentication yes
PubkeyAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

uname -rv
3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)

Теперь, читая далее об этом потоке, он посоветовал запустить ssh-add ~/.ssh/id_rsa . Это попросило ключевую фразу ключа.

Теперь и DigitalOcean, и VM работают без ключевой фразы, но мне любопытно, почему виртуальная машина никогда не нуждалась в ключевой фразе, а DigitalOcean это делала?

2 ответа2

0

Итак, я решил, и я уверен, что знаю, что случилось.

SSL попытается использовать удаленные public_keys, хранящиеся в авторизованных ключах, по сравнению с локальными ключами, используя систему вызова. Вы действительно не знаете или не контролируете последовательность того, что он испытывает.

~/.ssh/authorized_keys рута machine1 (VM) указали на один из моих ключей, который не был защищен парольной фразой, скажем, github. Он также имел id_rsa, но никогда не спрашивал об этом, потому что он входил до id_rsa, используя github.

~/.ssh/authorized_keys рута machine2 (Digitalocean) не содержит ссылку на мой незащищенный идентификационный ключ github , так что в итоге он попал в id_rsa. Поскольку идентификатор этого id_rsa не был загружен в ssh-agent и поскольку он защищен парольной фразой, меня спросили о парольной фразе.

Обратите внимание, что это противоречит моему утверждению, что авторизованные ключи были одинаковыми. Запись id_rsa была в обоих файлах, но на виртуальной машине Bitnami были и другие открытые ключи.

-1

Обратите внимание, что приведенная выше конфигурация DigitalOcean имеет PasswordAuthentication no where, а Bitnami - нет.

По иронии судьбы, это может быть объяснением: когда вы подключаетесь к DigitalOcean, вы должны использовать открытый ключ, и поэтому ваша локальная система предлагает вам расшифровать этот ключ.

В Bitnami вы, очевидно, используете аутентификацию по паролю, которая как-то скрыта от вас. Попробуйте "ssh -vvv ...", чтобы увидеть, что происходит, или добавьте PasswordAuthentication no на сервер Bitnami, чтобы увидеть, что происходит.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .