Я хочу использовать экземпляр Amazon ec2, но столкнулся со следующей ошибкой:
Permission denied (publickey).
Я создал свою пару ключей и загрузил файл .pem.
Учитывая:
chmod 600 pem file.
Затем эта команда
ssh -i /home/kashif/serverkey.pem [email protected]
Но есть ли эта ошибка:
Permission denied (publickey)
Кроме того, , как я могу подключиться к файловому файлу для загрузки/скачивания файлов?
Это сообщение об ошибке означает, что вы не смогли выполнить аутентификацию.
Это общие причины, которые могут вызвать это:
ubuntu - это имя пользователя для AWS-дистрибутива, основанного на ubuntu, но для некоторых других это ec2-user (или admin для некоторых дебианцев, по словам Богдана Кульбиды) (также может быть root, fedora, см. ниже )Обратите внимание, что 1. также произойдет, если вы испортили файл /home/<username>/.ssh/authorized_keys на вашем экземпляре EC2.
О 2., информация о том, какое имя пользователя вы должны использовать, часто отсутствует в описании изображения AMI. Но вы можете найти их в документации AWS EC2, маркерной точке 4.:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html
Используйте команду ssh для подключения к экземпляру. Вы укажете файл закрытого ключа (.pem) и имя_пользователя @public_dns_name. Для Amazon Linux имя пользователя - ec2-пользователь. Для RHEL5 имя пользователя либо root, либо ec2-user. Для Ubuntu имя пользователя ubuntu. Для Fedora имя пользователя: fedora или ec2-user. Для SUSE Linux имя пользователя root. В противном случае, если ec2-пользователь и root не работают, обратитесь к поставщику AMI.
Наконец, имейте в виду, что существует много других причин, по которым проверка подлинности завершилась неудачей. SSH, как правило, довольно четко говорит о том, что пошло не так, если вы хотите добавить параметр -v к своей команде SSH и прочитать результат, как объяснялось во многих других ответах на этот вопрос.
В этом случае проблема возникает из-за потерянной пары ключей. Об этом:
Вы можете выполнить следующие действия:
В общем, помните, что вы должны разрешить экземпляру EC2 принимать входящий трафик SSH.
Для этого вам необходимо создать определенное правило для группы безопасности вашего экземпляра EC2. Вы можете выполнить следующие шаги.
Надеюсь, это поможет кому-то, кто помог мне.
Вот как я решил проблему
ssh -i <key> [email protected]<ec2 ip>
Я решил проблему просто положить sudo до
sudo ssh -i mykey.pem myec2.amazonaws.com
Но правильное решение состоит в том, чтобы сначала изменить право собственности, а затем подключиться как обычный пользователь, как сказал ниже Янус Троелсен. В моем случае это будет:
chown wellington:wellington key.pem
Попробуйте использовать
sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>
ИЛИ
sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>
Другая возможная причина этой ошибки:
Если пользовательский домашний каталог доступен для записи, пользователь не может войти в систему.
(Воспроизводится по экземпляру Ubuntu.)
Вам необходимо выполнить следующие действия:
cd <path to your .pem file>chmod 400 <filename>.pem ssh -i <filename>.pem [email protected]<ipaddress.com>Если пользователь ubuntu не работает, попробуйте с ec2-user.
для микро-экземпляра ubuntu 12.04 lts мне пришлось установить имя пользователя как опцию
ssh -i pemfile.pem -l ubuntu dns
Также для некоторых ОС Debian имя пользователя admin. По крайней мере, для версий 6.5 и 7.0.
Я боролся с тем же разрешением, что я отклонил ошибку, по-видимому, из-за
key_parse_private2: missing begin marker
В моей ситуации причиной был файл конфигурации ssh текущего пользователя (~/.ssh/config).
Используя следующее:
ssh -i ~/myKey.pem [email protected]<IP address> -v 'exit'
Начальный результат показал:
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
... здесь много отладочных строк...
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Третья строка выше, где проблема была определена; однако я искал в сообщении отладки четыре строки снизу (вверху) и был введен в заблуждение. Нет проблемы с ключом, но я тестировал его и сравнивал другие конфигурации.
Мой пользовательский конфигурационный файл ssh reset хост через непреднамеренную глобальную настройку, как показано ниже. Первая строка хоста не должна быть комментарием.
$ cat config
StrictHostKeyChecking=no
#Host myAlias
user ec2-user
Hostname bitbucket.org
# IdentityFile ~/.ssh/somekey
# IdentitiesOnly yes
Host my2ndAlias
user myOtherUser
Hostname bitbucket.org
IdentityFile ~/.ssh/my2ndKey
IdentitiesOnly yes
Я надеюсь, что кто-то найдет это полезным.
Я забыл добавить имя пользователя (ubuntu) при подключении моего экземпляра Ubuntu. Поэтому я попробовал это:
ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com
и правильный путь был
ssh -i /path/my-key-pair.pem [email protected]
Это случилось со мной несколько раз. Я использовал Amazon Linux AMI 2013.09.2 и Ubuntu Server 12.04.3 LTS, которые находятся на свободном уровне.
Каждый раз, когда я запускаю экземпляр, у меня есть разрешение, которое запрещено. Я не проверял это, но моя теория заключается в том, что сервер не полностью настроен, прежде чем я попытаюсь с ним справиться. После нескольких попыток с разрешенным разрешением я жду несколько минут, а затем я могу подключиться. Если у вас возникла эта проблема, я предлагаю подождать пять минут и повторить попытку.
Вот возможные сценарии расстройства, вызывающие эту ошибку:
Если вы обедаете новый экземпляр из AMI, который вы создали из другого экземпляра (скажем, экземпляр xyz), то новый экземпляр примет только тот же ключ, что и использованный экземпляр A. Это совершенно понятно, но это запутывает, потому что во время пошагового процесса создания нового экземпляра вам предлагается выбрать или создать ключ (на последнем шаге), который не будет работать.
Независимо от ключа, который вы создаете или выбираете, только новый ключ, который вы использовали, например, XYZ, будет принят новым экземпляром.
Я боролся с этим некоторое время, пока не нашел следующее:
eb ssh
Когда вы используете это из каталога проекта, bingo-bango no muss no huss, вы находитесь в
В моем собственном случае я сделал следующее:
chmod 400 <key.pem>
ssh -i <key.pem> [email protected]_public_dns (for debian)
Сначала я использовал часть [email protected], и я получил следующее приглашение:
Please login as the user "ec2-user" rather than the user "root".
Я в Windows с WinSCP. Он отлично работает как с File Explorer, так и с PuTTY SSH Shell для доступа к моей Linux-машине Amazon EC2-VPC. Не имеет ничего общего с chmod pem file, поскольку он использует myfile.ppk преобразованный PuTTYgen из файла pem.
То же самое произошло со мной, но все, что происходило, это то, что закрытый ключ потерялся из брелка на моей локальной машине.
ssh-add -K
повторно добавлен ключ, затем команда ssh для подключения вернулась к работе.
Эта проблема может быть решена путем входа в поле Ubuntu, используя следующую команду:
ssh -i ec2key.pem [email protected]
У меня дважды были ключи и правильная строка командной строки ssh (я знаю, потому что я дублирую рабочий экземпляр Ubuntu 14.04), но просто не смог выполнить ssh в новый экземпляр, даже после ожидания 5 минут, как было предложено Уэйдом Андерсон выше.
Мне пришлось уничтожить и заново создать машину. Это произошло два раза. Поскольку я не могу получить изначально, я не вижу, что неправильно.
Итак, если у вас есть эта проблема, попробуйте это.
вы должны проверить эти несколько вещей:
У меня была такая же проблема, и она решилась после того, как я изменил имя пользователя на ubuntu. В документации AWS упоминался пользователь ec2-user, но как-то не работает для меня.
Мой закрытый ключ был настроен на разрешение 400, и в результате мне было отказано в настройке Permission, чтобы установить его на "644".
key_load_private_type: Permission denied - это конкретная ошибка, которую я получал
Решение:
Sudo chmod 644 <key.pem>
Примечание: установить значение 644 необходимо, он не работал с 400
Когда вы пытаетесь сделать
ssh -i <.pem path> [email protected]
Вы получите сообщение с текстом ec2-user.
Please login as the user "ec2-user" rather than the user "root".
Поэтому используйте
ssh -i <.pem path> [email protected]
У меня была такая же проблема, и это очень странно. Если вы считаете, что делаете все хорошо, следуйте этому: Несколько раз возникает путаница в отношении пользователя для экземпляра EC2!! Несколько раз вы получаете ec2-user, ubuntu, centos и т.д. Поэтому проверьте свое имя пользователя для мачо!!
Вход с пользователем root
ssh -i yourkey.pem (400 permission) [email protected]<ip>
Он выдает ошибку и даст вам доступное имя пользователя. затем войдите с этим пользователем.
Это основная вещь, но всегда подтверждайте, какой пользователь вы пытаетесь выполнить логин. Im мой случай был просто отвлечением. Я пытался использовать пользователя root:
ssh -i ~/keys/<key_name> [email protected]
Но был другой пользователь:
ssh -i ~/keys/<key_name> [email protected]
У меня была такая же ошибка, но в другой ситуации. для меня это случилось из-за синего после того, как много времени я смог успешно ssh на мой удаленный компьютер там. после многого поиска решения моей проблемы, где разрешены файлы. это, конечно, странно, потому что я не изменял никаких разрешений на моем компьютере или удаленном, принадлежащем файлам/каталогам ssh. поэтому из хорошего archlinux wiki вот он:
Для локальной машины выполните следующее:
$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa
Для удаленной машины выполните следующее:
$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
после этого мой ssh снова начал работать без права отказа (publicickey).
Моя проблема может быть связана с @Stepan.
По какой-то причине я не смог сделать это в своей папке Desktop на моей OS-X. Когда я делаю это в другой папке, он работает.
Мой ответ: попробуйте в другой папке, он может работать, по крайней мере, для меня.
Я смог SSH с одной машины, но не с другой. Оказывается, я использовал неправильный закрытый ключ.
То, как я это понял, - это получить открытый ключ из моего закрытого ключа, например:
ssh-keygen -y -f ./myprivatekey.pem
Что получилось, не соответствует тому, что было в ~/.ssh/authorized_keys для экземпляра EC2.