ВНИМАНИЕ: Незащищенный частный ключевой файл! при попытке SSH в инстанс Amazon EC2

Я работаю над настройкой Panda на инстансе Amazon EC2. Вчера вечером я настроил свою учетную запись и инструменты, и у меня не было проблем с использованием SSH для взаимодействия с моим личным экземпляром, но сейчас мне не разрешают доступ к экземпляру Panda 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-run-instances не может найти мои ключевые файлы. Я новичок в 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

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

Поэтому я предполагаю, что вы, возможно, пытаетесь выполнить ssh с ec2-пользователем, но я помню, что в последнее время большинство AMI-файлов centos, например, используют centos user вместо ec2-user

так что, если вы, 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.

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

Решение состоит в том, чтобы сделать его читаемым только владельцем файла, то есть две последние цифры восьмеричного представления в режиме должны быть равны нулю (например, mode 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 соответственно) ,