0

I have launched an AWS instance using one of the Ubuntu Server AMIs, successfully logged on with the default user (ubuntu) and key file, installed some stuff, added some users, disconnected and forgot about it for couple of weeks.

Today I discovered that I cannot ssh to it any more, using the same credentials that were ok the first time:

$ ssh -i ~/path/key.pem [email protected]
Connection closed by 1.2.3.4 port 22

$ ssh -v -i ~/path/key.pem [email protected]
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 1.2.3.4 [1.2.3.4] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /path/key.pem type -1
debug1: key_load_public: No such file or directory
debug1: identity file /path/key.pem-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 1.2.3.4:22 as 'ubuntu'
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: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:a/4u6R0qGP4SviSke0OWOOIaSjqymNvexBZDJ+yoOXc
debug1: Host '1.2.3.4' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:45
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=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:nd8gr8BrgC88h1hobmvdNMHOWNmWukYc4L0SJswVolk user@host
debug1: Authentications that can continue: publickey
debug1: Trying private key: /path/key.pem
Connection closed by 1.2.3.4 port 22

So I stopped the instance, detached the volume, and attached the volume to an instance where I am able to log on to. This allows me to mount the volume, access the files and study the ssh configuration and logs.

This is how I discovered that the user account is for some reason locked:

$ cd /path/to/mounted/volume
$ tail var/log/auth.log
Mar 15 13:10:24 sshd[1145]: Server listening on 0.0.0.0 port 22.
Mar 15 13:10:24 sshd[1145]: Server listening on :: port 22.
Mar 15 13:14:09 sshd[1430]: User ubuntu not allowed because account is locked
Mar 15 13:17:01 CRON[1440]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 15 13:17:01 CRON[1440]: pam_unix(cron:session): session closed for user root
Mar 15 13:26:07 sshd[1473]: User another_user not allowed because account is locked
Mar 15 13:26:07 sshd[1473]: Connection closed by invalid user another_user 212.93.116.117 port 36868 [preauth]
Mar 15 13:27:42 sshd[1475]: Bad protocol version identification '\377\364\377\375\006\033\033' from 212.93.116.117 port 36872
Mar 15 13:28:05 sshd[1476]: User ubuntu not allowed because account is locked
Mar 15 13:36:37 sshd[1145]: Received signal 15; terminating.

When I created another_user and set up key authentication, disabled ssh password login, I forgot to specify non-empty password for it. So it might be a reason why that user is locked. Anyway, I am now looking for a way how to unlock user ubuntu, at least temporarily, to see if that fixes the ssh access problem. But, as you see, I can not use system commands, I need to be able to do it by directly editing of the system files.

1 Answer 1

0

It was enough to change one character in one file, to enable the user ubuntu login again:

$ cd /path/to/mounted/volume
$ sudo nano etc/shadow

# Searh for the row that starts with "ubuntu:!"
# Change the "!" to "*", save, exit

After re-attaching the volume to the broken instance and booting it up, it was now possible to log on with the user ubuntu normally. I still have no idea why this user was automatically locked. Regarding the other user that was created, I assume it was locked because it had empty password, but I have no reference to prove it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .