Діалогове вікно пароля з'являється, коли для дозволів приватного ключа SSH встановлено 0600

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

Я бачу той самий діалог, коли я підключаюся до FTP-сервера з клієнтом Interarchy GUI.

Оновлення: це діалогове вікно я бачу щоразу під час підключення, незалежно від того, чи не встановлено прапорець "Запам'ятати пароль у моїй брелоку". Він з’являється ще два рази, якщо натиснути кнопку ОК, незалежно від того, що введено у полі пароля.

Коли я розслаблюю ці дозволи, скажімо, 0640я більше не бачу діалогового вікна, у якому запитують мене про пароль, але sshпереривається із такою помилкою:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ ПОПЕРЕДЖЕННЯ: Незахищений приватний ключовий файл! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
Дозволи 640 для '/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

Після цього мені більше не запропонували ввести пароль свого приватного ключа. Це здається, що фактично поставив пароль приватного ключа в правильному розташуванні брелока для ОС X 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-агент за замовчуванням.

Якщо ви хочете використовувати ssh-агент, але хочете уникнути діалогового вікна gui, ви можете використовувати ssh-add, щоб додати пароль до агента, а потім ssh, як зазвичай.

Якщо ви не хочете використовувати ssh-агент і замість цього мати ssh-підказку для парольної фрази, вимкніть змінну середовища SSH_AUTH_SOCK.

Коли ви послабите дозволи, ключ ігнорується. Ви нічого не отримаєте, зробивши це.

Якщо ви хочете використовувати ключ, не вводячи пароль кожен раз, у вас є два варіанти.

Якщо ви встановите прапорець "Запам'ятати пароль у моїй брелоку", вам не доведеться вводити пароль кожен раз: він буде зберігатися у брелок з усіма вашими іншими паролями. Це рекомендований варіант.

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

якщо ви додали свій приватний ключ до каталогу source / / .ssh, і ви ввели ssh-add -K, щоб додати його до брелка, і у вас є вміст вашого відкритого ключа скопійований у .ssh / autoriziran_keys (для правильності акаунт) файл на цільовому сервері діалогове вікно відключається.

це складне поєднання файлів, дозволів, розташувань та команд, щоб це зайняло час. я б не поспішав з висновком про помилок.

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

Не потрібно регенерувати ваші відкриті ключі. Ви можете просто виконати ці дві команди:

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

В основному вам потрібно посилити дозволи на файл відкритого ключа, і вам потрібно додати свій ключ до агента автентифікації OSX.

В останній версії macOS (10.12.2 - Сьєрра) це просте виправлення. Просто відредагуйте ~ / .ssh / config та увімкніть параметр UseKeychain:

Host *
UseKeychain yes

Зберегти та вирішити.

Ця проблема виникла в моїй системі OS X 10.7.4, коли помер ssh-агент. Перезавантаження усунула проблему. (Ви можете спробувати перезапустити ssh-агент, але я не знаю, чи Keychain досить розумний, щоб забрати новий ssh-агент.)

1. Будьте впевнені, що ~ / .ssh / є chmod 700.

2. Будьте впевнені, що файли ~ / .ssh / id * обидва chmod 600.

3. Запустіть / Програми / Утиліти / 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-агент, мені буде запропоновано ввести пароль брелока для входу, який потім отримує пароль ключа 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 хвилин. Я витратив гугл назавжди, щоб побачити, чи є якісь інші згадки про це. Цей сайт був єдиним!

Owain.

У мене була подібна проблема. Виявилося, що приватний ключ, який я використовував, був у неправильному форматі. Я використовував PuTTY Key Generator на своїй машині Win, а ssh на OS X очікує іншого формату - Відкрити формат SSH.

Виявилося, що інструмент, який я використовував для генерації цього ключа (PuTTY Key Generator), мав можливість конвертувати мій ключ priv у формат, необхідний Open SSH.

Простий як:

1. Відкрийте PuTTY Key Gen
2. Завантажте свій приватний ключ
3. Виберіть Конверсії> Експорт ключа OpenSSH.

Збережений файл містить оригінальний приватний ключ у відповідному (OpenSSH) форматі.

Переконайтесь, що:

1. Ви використовуєте формат pem для свого приватного ключа. Це тому, що Mac використовує opensh клієнт, який працює з pem. PPK є фірмовим форматом putty і не сумісний з openssh. Ви можете легко конвертувати ppk в pem за допомогою putty keygen, якщо у вас є лише ppk.
2. Дозволи на ваш файл pem - 600. Приватні ключі мають бути доступними лише їх власникові. Отже, якщо дозволи дозволяють отримати доступ до читання будь-якому іншому, це вважатиметься загрозою безпеці.

Це, сподіваємось, вирішить проблему.

Використовуйте ключ .pem, а не ключ .ppk.