☰

Se eliminaron las claves_autorizadas del directorio ssh del usuario.

tag-icon • tag-icon centos ssh
Se eliminaron las claves_autorizadas del directorio ssh del usuario.

Un usuario eliminó las claves_autorizadas del directorio ssh del usuario ec2 y ahora no puede iniciar sesión con el archivo ppk a través de PuTTY.

Todavía puedo acceder al servidor como un usuario diferente, sin embargo, ese usuario no tiene acceso sudo.

El único usuario que tiene acceso sudo es ec2-user.

Intenté cargar las claves pública y privada del archivo ppk y usar

ssh -v -i ec2-userprivate [email protected]

¿Algo más que pueda probar?

[oracle@ip-172-31-62-50 ~]$ ssh -v -i ec2-userprivate [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file ec2-userprivate type -1
debug1: key_load_public: No such file or directory
debug1: identity file ec2-userprivate-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
debug1: Authenticating to 127.0.0.1:22 as 'ec2-user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
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
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:truUDHodSW7Zjq/jaruRD7MlYmN0l2vDmxhspUDfwdE
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in /home/oracle/.ssh/known_hosts:10
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
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,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1001)

debug1: Next authentication method: publickey
debug1: Trying private key: ec2-userprivate
Enter passphrase for key 'ec2-userprivate':
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Respuesta1

La única forma de solucionar este problema es desmontar el bloque EBS, adjuntarlo a otra instancia EC2 en ejecución y agregar el archivo autorizado_keys.

  1. Cierra la instancia que necesitas arreglar.
  2. Separe el bloque EBS de su instancia.
  3. Cree una nueva instancia con la configuración predeterminada. El tipo no importa. Incluso podrías hacer esto con la instancia puntual t3.nano si realmente quisieras.
  4. Adjunte el bloque EBS a la nueva instancia EC2
  5. Inicie sesión en la nueva instancia EC2, monte el nuevo bloque EBS usando sudo.
  6. cd al directorio del usuario en el montaje y cree el archivo autorizado_usuarios con las claves públicas necesarias.
  7. Apague la instancia, desconecte el bloque EBS y luego vuelva a montarlo en la otra instancia.

información relacionada