Ошибка разрешений при подключении к EC2 через SSH на Mac OSx

Question

Я новичок в EC2.Я создал свои учетные данные безопасности с этого сайта:

http://paulstamatiou.com/how-to-getting-started-with-amazon-ec2

Он работал отлично, я перезагрузился, и теперь, когда я пытаюсь подключиться, я получаю приглашение для входа в систему / пароль.(Который я никогда не настраивал.) После нескольких попыток я получаю эту ошибку:

В доступе отказано (publickey, gssapi-with-mic).

Что я делаю неправильно?

Answer 1

Две возможности, о которых я могу подумать, хотя обе они упомянуты в ссылке, на которую вы ссылались:

1. Вы не указываете правильный файл пары ключей SSH или имя пользователя в команде ssh, которую используете для входа на сервер:

   ssh -i [полный путь к файлу пары ключей] root @ [имя хоста или IP-адрес экземпляра EC2]

2. У вас нет правильных прав доступа к файлу пары ключей; вы должны использовать

   chmod 600 [файл пары ключей]

, чтобы гарантировать, что только вы можете прочитать или записать файл.

Попробуйте использовать опцию -v с ssh, чтобы получить больше информации о том, где именно это происходит, и напишите здесь, если вам нужна дополнительная помощь.

[Обновление]: ОК, вот что вы должны были увидеть, если все было настроено правильно:

debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: ec2-keypair
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Запускаете ли вы команду ssh из каталога, содержащего файл ec2-keypair? Если это так, попробуйте указать -i ./ec2-keypair просто для устранения проблем с путями. Также проверьте файл «ls -l [полный путь к ec2-keypair]» и убедитесь, что разрешения равны 600 (отображается как rw -------). Если ничего из этого не сработало, я бы заподозрил содержимое файла пары ключей, поэтому попробуйте воссоздать его, используя шаги, указанные в вашей ссылке.

Answer 2

Ключом для возможности подключения было использование пользователя «ec2-user», а не root. I.e.:

ssh -i [full path to keypair file] ec2-user@[EC2 instance hostname or IP address]

Answer 3

В моем случае это потому, что разрешение для моего домашнего каталога - 775, и SSH не рад этому. Должно работать после выполнения:

server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys

У меня был очень похожий опыт сегодня днем. Я настраивал django на EC2, и вдруг я больше не могу подключиться к SSH. Рад, что у меня все еще было активное соединение, поэтому я изменил /etc/ssh/sshd_config, чтобы установить:

PasswordAuthentication yes

и установите пароль для ec2-user, затем я могу войти, введя пароль.

Однако после некоторого поиска в Google я нашел эту ветку: http://ubuntuforums.org/showthread.php?t=577279. Оказалось, что во время настройки django я изменил разрешение для своего домашнего каталога, и SSH очень строго относится к этому. Таким образом, разрешение файла должно быть установлено правильно.

Answer 4

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

ssh -i test.pem ec2-32-122-42-91.us-west-2.compute.amazonaws.com

и я добавляю имя пользователя:

ssh -i test.pem ec2-user@ec2-32-122-42-91.us-west-2.compute.amazonaws.com

это работает!

Answer 5

Пометка на ответ mecca831:

ssh -v -i генерируемый-key.pem ec2-user@11.11.11.11

[ec2-user@ip-11.11.11.11 ~]$ sudo passwd ec2-user newpassword newpassword

[ec2-user@ip-11.11.11.11 ~] $ sudo vi / etc / ssh / sshd_config Измените файл следующим образом:

    # To disable tunneled clear text passwords, change to no here!
    PasswordAuthentication yes
    #PermitEmptyPasswords no
    # EC2 uses keys for remote access
    #PasswordAuthentication no

Сохранить

[ec2-user@ip-11.11.11.11 ~] $ sudo service sshd stop [ec2-user@ip-11.11.11.11 ~] $ sudo service sshd start

Вы должны бытьможет выйти и выполнить ssh следующим образом:

ssh ec2-user@11.11.11.11

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

Answer 6

+ 1

Я заметил, что для некоторых AMI, таких как Amazon Linux, ec2-user@xxx.XX.XX.XXX будет работать. Но для образа Ubuntu мне пришлось вместо этого использовать Ubuntu @. Это никогда не было проблемой с .pem, только с именем пользователя.

Answer 7

Вы уверены, что использовали правильный экземпляр? Я столкнулся с этой проблемой и понял, что примерно в 4 экземплярах Ubuntu, которые я пробовал, не было установлено SSH-серверов.

Список хороших серверов см. В разделе «Получение изображений» примерно на полпути вниз. Похоже, вы можете использовать что-то еще ... имя пользователя по умолчанию - Ubuntu на этих изображениях.

https://help.ubuntu.com/community/EC2StartersGuide

Answer 8

Примерно через полчаса поиска и отладки я смог это выяснить.В моей ситуации я использовал один и тот же pem-файл для двух разных экземпляров ec2, и он работал для одного, а не для другого.

Моим первым экземпляром, над которым он работал, был стандартный aws linux ami amzn-ami-hvm-2014.03.2.x86_64-ebs.Я просто использовал

ssh -i mypemfile.pem ec2-user@myec2ipaddress 

, и это сработало.

Затем я запустил экземпляр Fedora Fedora-x86_64-19-20140407-sda и попробовал ту же команду, но продолжал получать:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

После изменения моего имени пользователя с ec2-user на fedora все заработало!

ssh -i mypemfile.pem fedora@myec2address

Answer 9

Я смог войти, используя ec2-user

ssh -i [полный путь к файлу пары ключей] ec2-user @ [имя хоста или IP-адрес экземпляра EC2]

Answer 10

Я рекомендую не устанавливать пароль, как предполагают некоторые другие ответы. Использование файла ключей является более безопасным (никто не может угадать ваши пароли) и более удобным (после настройки файла конфигурации). Вот базовый ~/.ssh/config:

Host my-ec2-server
  HostName 11.11.11.11
  User ec2-user
  IdentityFile /path/to/generated-key.pem

Теперь вы можете просто набрать ssh my-ec2-server и все! И, как уже упоминалось в других ответах, используйте -v для получения дополнительной информации, когда ваше соединение не работает.