TL;DR
Editérsyncalgunos directorios desde/home/ubuntu(establecidos en777) de un servidor remoto a mi nueva instancia AWS EC2. Ahora no puedo accederssha él por unPermission denied (publickey)error.
Estoy en el proceso de migrar mi entorno de producción de SoftLayer a AWS.
Tenía rsyncvarios directorios en EC2 (EBS) y, en el proceso, transfirí algunos directorios de la /home/ubuntu/instancia EC2 anterior a la actual /home/ubuntu/.
Mi rsynccomando (en destino) se veía así.
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/
Los archivos se transfirieron exitosamente. Cuando intenté sshingresar a mi EC2 la próxima vez, obtuve Permission denied (publickey)el siguiente registro con la ssh -vopción: (He enmascarado información privada como IP con {} en el registro a continuación)
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).
Me topé conestePregunta pero sin ayuda. También encontréestehilo en el foro de AWS.
Seguí los pasos enumerados:
Publicado por: mary@AWS:
¿Podría verificar los permisos en el directorio /home/ubuntu/.ssh y los archivos que contiene en esta instancia?
Para verificar los permisos, puede detener la instancia y desconectar el volumen raíz (tome nota del dispositivo al que está conectado). Luego adjunte el volumen a otra instancia en un dispositivo disponible. Cree un punto de montaje, como /fixroot, si es necesario y monte el dispositivo en este punto de montaje. Una vez montado, vaya a /fixroot/home/ec2-user y verifique el directorio y los permisos del archivo. El directorio .ssh debe permitir rwx para el usuario (propietario) y los archivos deben ser legibles solo por el usuario.
Otra cosa que debe verificar mientras esté allí es que el archivo conocido_hosts no tenga entradas duplicadas para el cliente desde el que intenta conectarse.
Una vez que haya hecho esto, puede desmontar el volumen y separarlo de la instancia. Luego, vuelva a adjuntarlo a la instancia original del dispositivo que anotó en el primer paso e inicie la instancia.
Así como
Publicado por: yromanenko:
Resulta que fueron los permisos relajados en la carpeta home/ubuntu en lugar de ssh. Pude solucionarlo desconectando el volumen raíz y arreglando los permisos. El siguiente video fue muy útil para guiarme a través de los pasos:
http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4
Generé una nueva t2.microinstancia y seguí Marylos pasos de para confirmar los permisos y yromanenkola resolución a configurar 755en el /home/ubuntudirectorio.
¡Volví a conectar el dispositivo EBS problemático al primer EC2 /dev/sda1y solo intenté fallar con el mismo Permission denied (publickey)error!
En consecuencia, ahora recibo el mismo error en la t2.microinstancia secundaria. :(
¡Cualquier ayuda sería apreciada!
Respuesta1
Tuve este problema exacto. Estaba usando una instancia de Amazon EC2 para poder crear otra e identificar las diferencias. La máquina averiada tenía permisos de /home/user 777, la máquina no averiada tenía 700. Por alguna razón inexplicable, rsyncing a /home/user cambia los permisos de /home/user a 777. Aparentemente, SSH requiere que /home/user sea 700 por razones de seguridad. Esto también explica por qué sus tortugas bajan por completo, rsync nuevamente y se rompe nuevamente.
Si tiene la suerte de tener acceso al directorio de alguna otra manera,
chmod 700 /home/user
lo arregla.
En el futuro, rsync a un subdirectorio de /home/user.