В доступе отказано (публичный ключ) Amazon Linux aws
У меня на aws запущено два экземпляра. У меня для них обоих одна и та же пара ключей. Долгое время пользовался обоими экземплярами. но сегодня я получаю сообщение об ошибке в одном экземпляре при попытке войти в систему через терминал, если я запустил эту команду.
ssh -i mypem.pem [email protected]
Permission denied (publickey).
Но если я попытаюсь войти в другой экземпляр с тем же файлом pem. Он работает, и я могу успешно войти в него.
Я перепробовал все представленные здесь решения
В доступе отказано (публичный ключ) при доступе по SSH к инстансу Amazon EC2
Попытка подключиться к экземпляру Amazon Ec2 по SSH - ошибка разрешения
Но у меня ничего не работает
Если я сделаю это
ssh -i mypem.pem [email protected] -vvv
Результат такой
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolving "52.xx.xxx.xxx" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 52.xx.xxx.xxx [52.xx.xxx.xxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file mypem.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file mypem.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 52.xx.xxx.xxx:22 as 'ec2-user'
debug3: hostkeys_foreach: reading file "/Users/myusername/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/myusername/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from 52.xx.xxx.xxx
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: mykeyhere
debug3: hostkeys_foreach: reading file "/Users/myusername/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/myusername/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from 52.70.181.239
debug1: Host '52.xx.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /Users/irfansheikh/.ssh/known_hosts:6
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: mypem.pem (0x7f9053c03750), agent
debug2: key: mypem.pem (0x0), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: bringthings.pem
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: mypem.pem
debug3: sign_and_send_pubkey: RSA
SHA256:keyhere**********
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
Что я пробовал
chmod 400 mypem.pem
Я тоже пробовал это
sudo ssh -i mypem.pem ec2-xxx-xxx-xxx-xxx.us-west 2.compute.amazonaws.com
Получил это
Please login as the user "ec2-user" rather than the user "root"
тогда я сделал это
sudo ssh -i mypem.pem ec2-xxx-xxx-xxx-xxx.us-west-2.compute.amazonaws.com -l ec2-user
я получил
Permission denied (publickey)
Если я попытаюсь войти в другой экземпляр с тем же ключом. Я могу успешно войти в систему. Пожалуйста, помогите, что здесь на самом деле пошло не так
Группа безопасности на моем экземпляре - это
А вы Когда-либо смогли войти во второй экземпляр? Если да, возможно ли, что вы сделали что-то, что изменило .ssh/authorized_keys?
Другой экземпляр имеет имя пользователя ubuntu, но у этого экземпляра есть ec2-user .. и да, я могу успешно войти в другой экземпляр
все работало нормально до ночи. когда я просыпаюсь, он перестал работать. так что нет я ничего не делал
Ответы 4
Устранение неполадок подключения к ec2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
Вы также можете попробовать тройной подробный параметр -vvv
У меня время от времени возникали одни и те же ошибки, обычно я использовал ec2-user вместо ubuntu или неправильный ключ
Вы можете попробовать вариант -vvv, как уже предлагалось, и попытаться узнать, получите ли вы дополнительную информацию о причине сбоя SSH.
Если по-прежнему неясно, единственный вариант - отсоединить том от текущего экземпляра и присоединить его к другому экземпляру EC2, смонтировать том и проверить следующие файлы журнала на наличие сообщений об ошибках:
/var/log/messages
/var/log/secure
Вы можете использовать следующие ссылки для справки о том, как отсоединить и присоединить том к другому экземпляру EC2: -
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html
При отсоединении и присоединении запоминайте имена устройств томов, например /dev/xvda или /dev/sda1. Это довольно неприятно, если вы пропустите первый раз, а затем вам снова придется повторить весь процесс отсоединения и присоединения.
Причин ошибки здесь может быть несколько. Например, если каким-то образом разрешения для папки /home/ec2-user/.ssh или любых файлов, присутствующих в ней, были неправильно установлены в последний раз перед выключением сервера, команда не сможет прочитать файлы и, следовательно, потерпит неудачу. Как правило, ошибки, зарегистрированные в файлах журнала, полезны и могут указать причину недоступности.
Одна вещь, на которую я хотел бы обратить внимание, - это то, что вы пытаетесь использовать две пары ключей: amazonec2.pem и mypem.pem. При использовании mypem.pem вы упомянули имя пользователя: ec2-user вместе с IP-адресом в команде SSH. Однако, когда вы использовали amazonec2.pem, он отсутствовал в команде!
Обратите внимание, что если имя пользователя отсутствует, команда фактически завершится с ошибкой Permission denied (publickey).. Я попытался подключиться к своему экземпляру EC2 по SSH, не упоминая имя пользователя, и это не удалось.
Надеюсь это поможет.
извините "amazonec2.pem и mypem.pem", это просто опечатка. Я использую один и тот же mypem.pem везде
Затем вам нужно проанализировать файлы журнала, что говорит вывод -vvv ssh, вы можете обновить вывод здесь, чтобы все могли видеть и помогать, если у них есть подсказка!
В моем случае я несколько раз ввел неправильную кодовую фразу. После чего я постоянно получал отказ в разрешении. Я перезагрузил свой экземпляр AWS и попробовал использовать те же учетные данные, которые работали.
Проблема связана с использованием разных открытых ключей и для решения этой проблемы: -
Просто создайте открытый ключ с вашим личным ключом, то есть файл mypem.pem, как показано ниже: -
ssh-keygen -y -f mypem.pem
Он создаст и отобразит открытый ключ для закрытого ключа. Вы просто хотите скопировать этот ключ в свой экземпляр aws, как показано ниже: -
Если вы запускаете экземпляр Ubuntu откройте файл authorized_keys и вставьте сгенерированный открытый ключ в этот файл (удалите существующее содержимое): -
vi ~/.ssh/authorized_keys
Затем попробуйте подключиться с помощью следующей команды: -
ssh -i mypem.pem [email protected]
или же
ssh -i mypem.pem [email protected]
Оба ли они экземпляра AWS Linux? В противном случае имя пользователя будет другим (например, для экземпляров Ubuntu это «ubuntu», а не «ec2-user»).