Попередження: незахищений приватний ключовий файл! при спробі SSH в екземпляр Amazon EC2

Я працюю над створенням Panda на екземплярі Amazon EC2. Я створив свій обліковий запис та інструменти вчора ввечері і не мав жодних проблем використовувати SSH для взаємодії з моїм особистим екземпляром, але зараз мені не дозволяють отримати дозвіл на екземпляр EC2 Panda. Початок роботи з Пандою

Я отримую таку помилку:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Я ввімкнув свій ключ до 600, щоб увійти до мого особистого примірника минулої ночі, і експериментував довго, встановлюючи дозволи до 0 і навіть генеруючи нові ключові рядки, але, здається, нічого не працює.

Будь-яка допомога взагалі була б чудовою допомогою!

Гм, здається, що якщо в каталозі дозволів не встановлено 777, скрипт запущених екземплярів ec2 не в змозі знайти мої ключові файли. Я новачок у SSH, тож я можу щось не помітити.

Я влаштував свій ключ до 600, щоб вчора ввійти в особистий приклад,

І це саме так і повинно бути.

З документації на EC2 у нас є "Якщо ви використовуєте OpenSSH (або будь-який досить параноїдальний клієнт SSH), вам, ймовірно, потрібно буде встановити дозволи цього файлу, щоб він читав лише ви." Документація Panda, яку ви посилаєте, посилається на документацію Amazon, але насправді не повідомляє про те, наскільки це важливо.

Ідея полягає в тому, що файли пар ключів схожі на паролі і їх потрібно захистити. Отже, ssh-клієнт, який ви використовуєте, вимагає захистити ці файли і читати їх може лише ваш обліковий запис.

Встановлення каталогу у 700 дійсно має бути достатньо, але 777 не зашкодить, поки файлів буде 600.

Будь-які проблеми, які виникають у вас, є стороною клієнта, тому обов'язково включіть інформацію про локальну ОС з будь-якими подальшими питаннями!

Переконайтеся, що для каталогу, що містить файли приватного ключа, встановлено 700

chmod 700 ~/.ec2

Щоб виправити це, 1) вам потрібно буде відновити дозволи до типових:

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 600 ~/.ssh/id_rsa.pub

Якщо ви отримуєте ще одну помилку: Ви впевнені, що хочете продовжувати з'єднання (так / ні)? так Не вдалося додати хост до списку відомих хостів (/home/geek/.ssh/known_hosts).

2) Це означає, що дозволи на цей файл також встановлені неправильно, і їх можна коригувати за допомогою цього:

sudo chmod 644 ~/.ssh/known_hosts

3) Нарешті, вам може знадобитися також скорегувати дозволи для каталогу:

sudo chmod 755 ~/.ssh

Це має повернути вас до роботи.

Файл приватного ключа повинен бути захищений. У моєму випадку я вже давно використовую аутентифікацію public_key, і я встановлював дозвіл як 600 (rw- --- ---) для приватного ключа та 644 (rw- r-- r--) та для папку .ssh у домашній папці ви матимете 700 дозволів (rwx --- ---). Щоб встановити це, перейдіть до домашньої папки користувача та запустіть наступну команду

Встановіть дозвіл 700 для папки .ssh

chmod 700 .ssh

Встановіть дозвіл 600 для приватного ключа

chmod 600 .ssh/id_rsa

Встановіть дозвіл 644 на файл відкритого ключа

chmod 644 .ssh/id_rsa.pub

Я також отримав ту саму проблему, але виправляю її, змінюючи свій дозвіл файлів ключів на 600.

sudo chmod 600 /path/to/my/key.pem

Посилання: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

Зберігайте свій приватний ключ, відкритий ключ, known_hosts у тому самому каталозі та спробуйте увійти, як зазначено нижче:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com

• Той же каталог , в тому сенсі, cd /Users/prince/Desktop. Тепер наберіть lsкоманду, і ви повинні побачити **.pem **.ppk known_hosts

Примітка. Вам потрібно спробувати увійти з тієї самої директорії, інакше ви отримаєте помилку, у якій відмовлено в дозволі, оскільки він не може знайти .pem файл у вашому теперішньому каталозі.

Якщо ви хочете мати можливість SSH з будь-якого каталогу, ви можете додати у ~/.ssh/configфайл наступне ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Тепер ви можете SSH на свій сервер незалежно від того, де знаходиться каталог, просто набравши ssh your.server(або те, що ви вкажете після "Host").

У Windows спробуйте використовувати git bash та використовуйте там свої команди Linux. Легкий підхід

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Змініть дозвіл на файл за допомогою команди chmod

sudo chmod 700 keyfile.pem

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

Тож я припускаю, що ви, можливо, намагаєтеся обмінятись послугами із користувачем ec2, але я пригадую, що останнім часом, наприклад, більшість центів AMI використовують, наприклад, користувач centos замість ec2-користувача

тому, якщо ви ssh -i file.pem centos@public_IPпросимо сказати мені, ви намагаєтеся ввести ssh з потрібним іменем користувача, інакше це може бути вагомою причиною того, що ви бачите таке повідомлення про помилку навіть з правильними дозволами на вашому ~ / .ssh / id_rsa або file.pem

Просто примітка для кожного, хто натрапив на це:

Якщо ви намагаєтеся зробити SSH за допомогою ключа, яким ви поділилися, наприклад:

ssh -i /path/to/keyfile.pem user@some-host

Де keyfile.pemзнаходиться приватний / відкритий ключ спільно з вами , і ви використовуєте його для підключення, переконайтеся , що ви збережете його в ~/.ssh/і chmod 777.

Спроба використовувати файл, коли він був збережений в іншому місці на моїй машині, викликав помилку ОП. Не впевнений, чи це безпосередньо пов’язано.

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

OpenSSH перевіряє це у authfile.cфункції, названій sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Дивіться перший коментар після коментаря: він робить "порозрядно і" проти режиму файлу, вибираючи всі біти в двох останніх восьмизначних цифрах (оскільки 07є восьмеричними для 0b111, де кожен біт означає r / w / x відповідно) .