Home / server / Questions / 1001120
In Process
James Connigan
Asked: 2020-01-31 11:22:19 +0800 CST

Removed authorized_keys from user ssh directory

  • 772

A user removed the authorized_keys from ec2-user ssh directory and now cannot log in with the ppk file though putty.

I can still access the server as a different user, however that user does not have sudo access.

The only user that has sudo access is ec2-user.

I have tried to upload the public and private keys from the ppk file and use 

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

Anything else I can try?

[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).
centos ssh

1 Answers

  1. The only way to fix this is to unmount the EBS block and attach it to another running EC2 instance and add the authorized_keys file.

    1. Shutdown the instance you need to fix.
    2. Detach the EBS block from your instance.
    3. Create a new instance with default settings. Type doesn't matter. You could even do this with t3.nano spot instance if you really wanted to.
    4. Attach the EBS block to the new EC2 instance
    5. Log into the new EC2 instance, mount the new EBS block using sudo.
    6. cd to the user's directory on the mount and create the authorized_users file with the necessary public keys.
    7. Shutdown the instance, detach the EBS block, then mount it back to the other instance.
    • 1