Диалоговое окно пароля появляется, когда права доступа закрытого ключа SSH установлены на 0600

Я установил свой закрытый ключ SSH ~/.ssh/id_rsaи установил его права доступа 0600. Когда я подключаюсь к SSH-серверу, который использует мой закрытый ключ в Terminal.app через ssh, появляется диалоговое окно с просьбой ввести пароль для доступа к id_rsaфайлу:

Я вижу тот же диалог при подключении к FTP-серверу с клиентом Interarchy GUI.

Обновление: я вижу этот диалог каждый раз, когда я подключаюсь, независимо от того, проверяю ли я «Запомнить пароль в моей цепочке для ключей». Он появляется еще два раза, если нажать кнопку ОК, независимо от того, что введено в поле пароля.

Когда я ослабляю эти разрешения, скажем, 0640я больше не вижу диалоговое окно, спрашивающее меня о моем пароле, но sshпрерывается со следующей ошибкой:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ ПРЕДУПРЕЖДЕНИЕ: незащищенный частный ключевой файл! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
Разрешения 0640 для '/Users/myusername/.ssh/id_rsa' слишком открыты.
Рекомендуется, чтобы ваши файлы закрытых ключей НЕ были доступны другим.
Этот закрытый ключ будет игнорироваться.
плохие разрешения: игнорировать ключ: /Users/myusername/.ssh/id_rsa

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

Примечание: я использую Mac OS X 10.6.8.

Убедитесь, что у вас есть соответствующий id_rsa.pubили id_dsa.pubв вашем ~/.sshкаталоге.

Когда у меня был, id_rsaно не соответствовал id_rsa.pub, Mac OS X продолжал появляться в диалоговом окне и помнить, что passowrd в моей связке ключей ничего не делал.

cd ~/.ssh
ssh-keygen -y -f id_rsa > id_rsa.pub

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

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

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

Сначала запустите ssh-add -Kи проверьте, решает ли это вашу проблему.

Если не:

• Удалил файл rsa_id.pub и восстановил новый (должен быть в ~ / .ssh /):

  ssh-keygen -y -f id_rsa > id_rsa.pub

• Гарантированные разрешения были установлены на 600 как для id_rsa, так и для id_rsa.pub (должно быть в ~ / .ssh /):

  chmod 600 id_rsa*

• Запустил следующую команду:

  ssh-add -K

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

В моем случае ssh-add -Kне сработало, мне пришлось указать ключ:

ssh-add ~/.ssh/id_rsa

Для macOS 10.12 Sierra ssh-add -Kнеобходимо запускать после каждой перезагрузки. Чтобы избежать этого, создавайте ~/.ssh/configс этим контентом.

Host *
   AddKeysToAgent yes
   UseKeychain yes
   IdentityFile ~/.ssh/id_rsa

Apple добавила Technote 2449, который объясняет, что произошло.

До macOS Sierra ssh представлял диалоговое окно с запросом вашей парольной фразы и предлагал возможность сохранить ее в цепочке для ключей. Этот интерфейс был объявлен устаревшим некоторое время назад и был удален.

Редактировать: очевидно, указывать хост и ключ не обязательно. Просто добавить этого достаточно.

AddKeysToAgent yes
UseKeychain yes

Вы должны где-то ввести фразу-пароль для закрытого ключа, и OS X по умолчанию использует ssh-agent.

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

Если вы не хотите использовать ssh-agent и вместо этого у вас есть ssh-приглашение для ключевой фразы, тогда снимите значение с переменной окружения SSH_AUTH_SOCK.

Когда вы ослабляете права доступа, ключ игнорируется. Вы ничего не получите, делая это.

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

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

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

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

это сложная комбинация файлов, разрешений, местоположений и команд, поэтому на это может потребоваться время. я бы не спешил с выводом об ошибках.

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

Не должно быть необходимости восстанавливать ваши открытые ключи. Вы можете просто сделать эти две команды:

chmod 0600 ~/.ssh/id_rsa.pub
ssh-add ~/.ssh/id_rsa

По сути, вам необходимо ужесточить права доступа к файлу открытого ключа и добавить свой ключ в агент аутентификации OSX.

В последней версии macOS (10.12.2 - Sierra) это легко исправить. Просто отредактируйте ~ / .ssh / config и включите опцию UseKeychain:

Host *
UseKeychain yes

Сохранить и решить.

Эта проблема возникла в моей системе OS X 10.7.4, когда умер ssh-agent. Перезагрузка исправила проблему. (Вы можете попробовать перезапустить ssh-agent, но я не знаю, достаточно ли у меня цепочка для ключей, чтобы поднять новый сокет ssh-agent.)

1. Убедитесь, что ~ / .ssh / - это chmod 700.

2. Убедитесь, что оба файла ~ / .ssh / id * имеют формат chmod 600.

3. Запустите / Applications / Utilities / Keychain Access.app и восстановите связку ключей.

4. Выйти. (Перезагрузка не будет ужасной идеей)

5. Авторизоваться

6. Если проблема не устранена, переместите существующие файлы ~ / .ssh / id * на рабочий стол и попробуйте сгенерировать новые ключи с помощью ssh-keygen -t dsa -f ~/.ssh/id_dsa -C you@youremail.tldи посмотрите, работают ли новые ключи лучше.

Я на льве, но IIRC Snow Leopard работал так же.

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

Регенерация открытого ключа, похоже, не работает для меня (10.8) и генерация нового ключа SSH. Если я, например, запускаю git pull после блокировки цепочки ключей входа в систему, появляется диалоговое окно с запросом пароля для ключа вместо первой попытки извлечь пароль из цепочки ключей входа в систему.

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

Еще один интересный вывод: если вы копируете и вставляете содержимое файла PEM, возможно, в конце нет пропущенной черты. Так что просто не забудьте добавить последнюю строку как,

-----END RSA PRIVATE KEY-----

Я должен был сделать следующие шаги, чтобы заставить это работать.

# Change working directory
cd ~/.ssh
# Remove the old public key
rm id_rsa.pub
# Create a new public key
ssh-keygen -y -f id_rsa > id_rsa.pub
# Change permission
chmod 600 id_rsa*
# Add the key to ssh
ssh-add id_rsa
# Then finally test it (I used github)
ssh -i id_rsa.pub git@github.com

Последняя команда должна затем вывести что-то вроде: Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.

У меня такая же проблема. Я, кажется, исправил это, делая это.

1) Резервное копирование путем переименования в старые файлы id_dsa и id_dsa.pub.

2) Запустил новый кейген с пустой парольной фразой.

Работает с заданием за период запуска, отслеживая удаленный сервер, а также входя в систему из ssh в терминале.

У меня в терминале есть функция быстрой функции authme, так как в моем .bash_profile есть следующее

#~/.bash_profile    
function authme {
ssh $1 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub
}

Таким образом, быстрый authme remoteserver.com скопирует новый удаленный ключ.

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

Попробуйте и посмотрите, поможет ли это.

Это заняло не более 10 минут. Я потратил на поиски в интернете навсегда, чтобы увидеть, есть ли другие упоминания об этом. Этот сайт был единственным!

Оуайн.

У меня была похожая проблема. Оказалось, что закрытый ключ, который я использовал, был в неправильном формате. Я использовал PuTTY Key Generator на моей машине Win, и ssh на OS X ожидает другой формат - открытый формат SSH.

Оказалось, что инструмент, который я использовал для генерации этого ключа (PuTTY Key Generator), имел возможность преобразовать мой секретный ключ в формат, требуемый Open SSH.

Просто как:

1. Открытый PuTTY Key Gen
2. Загрузите свой закрытый ключ
3. Выберите «Преобразования»> «Экспорт ключа OpenSSH».

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

Пожалуйста, убедитесь, что:

1. Вы используете формат pem для своего закрытого ключа. Это потому, что Mac использует openssh клиент, который работает с pem. ppk является закрытым форматом putty и не совместим с openssh. Вы можете легко конвертировать ppk в pem, используя putty keygen, если у вас есть только ppk.
2. Права доступа к вашему файлу pem - 600. Частные ключи должны быть доступны только их владельцу. Таким образом, если разрешения предоставляют доступ для чтения кому-либо еще, это будет считаться угрозой безопасности.

Надеюсь, это должно решить проблему.

Используйте ключ .pem вместо ключа .ppk.