DR
Altereirsyncalguns diretórios de/home/ubuntu(definido como777) de um servidor remoto para minha nova instância do AWS EC2. Agora estou impedido desshentrar nele por umPermission denied (publickey)erro.
Estou migrando meu ambiente de produção do SoftLayer para AWS.
Tive de rsyncvários diretórios para o EC2 (EBS) e, no processo, transferi alguns diretórios da antiga /home/ubuntu/para a minha instância atual do EC2 /home/ubuntu/.
Meu rsynccomando (no destino) ficou assim.
ubuntu@[aws.remote.ec2]:~$ sudo rsync --include 'dir1' --include '*.sh' --include '.py' --include 'api_logs' --include 'database_backups' --exclude '*' -avz -e "ssh -p $portNumber" ubuntu@[softlayer.remote]:/home/ubuntu/ /home/ubuntu/
Os arquivos foram transferidos com sucesso. Na próxima vez que tentei sshentrar no meu EC2, obtive Permission denied (publickey)o seguinte log com a ssh -vopção: (Mascarei informações privadas como IP com {} no log abaixo)
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/{localuser}/.ssh/config
debug1: /home/{localuser}/.ssh/config line 1: Applying options for aws-fr-
ec2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to {aws.ec2.ip} [{aws.ec2.ip}] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem type
-1
debug1: key_load_public: No such file or directory
debug1: identity file /home/{localuser}/Documents/AWS-Files/EC2-FR.pem-cert
type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2
Ubuntu-4ubuntu2.2
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 pat OpenSSH* compat
0x04000000
debug1: Authenticating to {aws.ec2.ip}:22 as 'ubuntu'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:g3nWVGmjJYVrNrwsDJMhzbLSw0FzBOLoUx80seD9qIs
debug1: Host '{aws.ec2.ip}' is known and matches the ECDSA host key.
debug1: Found key in /home/{localhost}/.ssh/known_hosts:11
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/{localhost}/Documents/AWS-Files/EC2-
FR.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
eu tropeceiessepergunta, mas sem ajuda. Eu também encontreiessetópico no Fórum AWS.
Eu segui as etapas listadas:
Postado por: mary@AWS:
Você poderia verificar as permissões no diretório /home/ubuntu/.ssh e nos arquivos contidos nele nesta instância?
Para verificar as permissões, você pode interromper a instância e desanexar o volume raiz (anote o dispositivo ao qual ele está conectado). Em seguida, anexe o volume a outra instância em um dispositivo disponível. Crie um ponto de montagem, como /fixroot, se necessário, e monte o dispositivo nesse ponto de montagem. Uma vez montado, faça cd para /fixroot/home/ec2-user e verifique o diretório e as permissões do arquivo. O diretório .ssh deve permitir rwx para o usuário (proprietário) e os arquivos devem ser legíveis apenas pelo usuário.
Outra coisa a verificar enquanto você estiver lá é se o arquivoknown_hosts não possui entradas duplicadas para o cliente do qual você está tentando se conectar.
Depois de fazer isso, você poderá desmontar o volume e separá-lo da instância. Em seguida, anexe-o de volta à instância original ao dispositivo que você anotou na primeira etapa e inicie a instância.
Assim como
Postado por: yromanenko:
Acontece que foram as permissões relaxadas na pasta home/ubuntu em vez de ssh. Consegui consertar desanexando o volume raiz e corrigindo as permissões. O vídeo a seguir foi muito útil para me guiar pelas etapas:
http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4
Gerei uma nova t2.microinstância e segui Maryas etapas para confirmar as permissões e yromanenkoa resolução do para definir 755no /home/ubuntudiretório.
Reconectei o dispositivo EBS problemático de volta ao primeiro EC2 /dev/sda1e tentei apenas falhar com o mesmo Permission denied (publickey)erro!!
Conseqüentemente, agora estou recebendo o mesmo erro na t2.microinstância secundária. :(
Qualquer ajuda seria apreciada!
Responder1
Eu tive exatamente esse problema. Eu estava usando uma instância do Amazon EC2 para poder criar outra e identificar as diferenças. A máquina quebrada tinha permissões /home/user 777, a máquina não quebrada tinha 700. Por alguma razão inexplicável, rsyncing para /home/user altera as permissões de /home/user para 777. Aparentemente, o SSH exige que /home/user seja 700 por razões de segurança. Isso também explica por que suas tartarugas estão totalmente abaixadas, sincronizam novamente e quebram novamente.
Se você tiver a sorte de ter acesso ao diretório de alguma outra forma,
chmod 700 /home/user
corrige isso.
No futuro, faça rsync para um subdiretório de /home/user.