SSH ключ спрашивает у меня пароль?

У меня есть пара открытый / закрытый ключ. Ни с одним из них не связана какая-либо парольная фраза.

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

У кого-нибудь есть идеи, как обойти это? Неправильно ли я набираю какую-то команду? Я пытаюсь подключиться к серверу ssh, который я настроил в моем файле ~ / .ssh / config (правильно, поскольку точно такая же установка работает на другом сервере) с ключом, хранящимся в ~ / .ec2 / key.ppk

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

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

Лучше всего предположить, что вы пытаетесь использовать ppkформат ключа закрытого ключа замазки ( ) с openssh, это не работает .... PuTTYgen имеет опцию экспорта для openssh, если это так.

ssh-rsa AAAAB3NzaC1y...... etc

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

Другое предположение будет, что правильный ключ не будет выбран. Вот некоторые вещи, которые я бы попробовал:

Сброс ключевой фразы с использованием ssh-keygen, как это ...

$ ssh-keygen -f ~/.ec2/key.ppk -p

Это подтвердит, если на самом деле ваш ключ уже имеет (или не имеет) парольную фразу.

Во-вторых, я бы попытался подключиться, используя подробный вывод, явно указав ваш открытый ключ:

$ ssh host -i ~/.ec2/key.ppk -vvv

Это даст вам больше представления о том, что происходит.

Вы можете запустить ssh-agent. Смотрите здесь для обсуждения.

Короткая версия, которая работала для меня (в bash):

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-rnRLi11880/agent.11880; export SSH_AUTH_SOCK;
SSH_AGENT_PID=11881; export SSH_AGENT_PID;
echo Agent pid 11881;

Я взял три строки, которые повторяются, и выполнил их. Другой способ сделать это - взять вывод -s:

$ eval `ssh-agent -s`

Затем я добавил свои учетные данные:

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/me/.ssh/id_rsa: 
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)

Теперь агент предоставляет учетные данные вместо того, чтобы мне приходилось вводить мою фразу-пароль.

Я полагаю, что ssh-agent уходит, когда оболочка закрывается, поэтому это должно быть записано в сценарии при запуске для максимального удобства. Ссылка я делил описывает сценарии , а также.

Когда вы устанавливаете свой открытый ключ, вы, вероятно, (возможно, непреднамеренно) устанавливаете его с помощью ключевой фразы.

Возможно, вам нужно начать все заново - я не использовал puttygen, но вы можете удалить (или переименовать) открытый ключ в вашем каталоге .ssh, использовать ssh-keygenдля создания нового (убедитесь, что вы не предоставили ключевую фразу), а затем отправьте public_key в файл author_keys на сервере, к которому вы пытаетесь подключиться.

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

Убедитесь, что закрытый ключ id_rsaне имеет дополнительных разрывов строк в конце, в некоторых случаях дополнительные разрывы строк заставят ssh-keygen запросить фразу-пароль, попробуйте это:

sed  '/^$/d' /path/to/key > id_rsa

тест:

ssh-keygen -yf id_rsa

Одна вещь, которую нужно проверить: если ваш файл sshd_config имеет StrictModes = yes, то каталог $ HOME или каталог $ HOME / .ssh не должны быть доступны для записи всем группам или другим файлам. В противном случае проверка подлинности не будет выполнена ни на что.

Я сделал ошибку, случайно перезаписав файл ~ / .ssh / id_rsa файлом ~ / .ssh / id_rsa.pub. Это заставит ssh запросить парольную фразу.

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

У меня плохая привычка пропустить первый или последний персонаж. Оказывается, что если вы не захватываете каждый дефис в конце своего закрытого ключа - даже если он не имеет никакого отношения к самому тексту ключа - вам будет предложено ввести ключевую фразу для закрытого ключа, пока не будет добавлен каждый символ из ключ, с которого вы скопировали (в моем случае это означало добавление одного дефиса к концу ключа.)

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

На OSX я смог просто запустить:

$ ssh-add ~/.ssh/id_rsa Enter passphrase for /Users/me/.ssh/id_rsa: `Identity added: /Users/mikekilmer/.ssh/id_rsa (/Users/mikekilmer/.ssh/id_rsa)

Пароль был сохранен приложением Keychain Access, которое находится в папке Applications> Utilities. Я только что вошел id_в поле поиска.

Попробуйте просмотреть файлы журнала на сервере. Посмотрите / var / log / auth log (например, / var / log / authlog для OpenSSH, хотя я видел, что некоторые операционные системы используют Portable OpenSSH и /var/log/auth.log) и проверьте конец этого файла.

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

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

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

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