Ich habe eine AWS-Instanz mit einem der Ubuntu Server-AMIs gestartet, mich erfolgreich mit dem Standardbenutzer (Ubuntu) und der Schlüsseldatei angemeldet, einige Dinge installiert, einige Benutzer hinzugefügt, die Verbindung getrennt und es ein paar Wochen lang vergessen.
Heute habe ich festgestellt, dass ich mit denselben Anmeldeinformationen, die beim ersten Mal in Ordnung waren, keine SSH-Verbindung mehr herstellen kann:
$ 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
Also habe ich die Instanz gestoppt, das Volume abgetrennt und das Volume an eine Instanz angeschlossen, bei der ich mich anmelden kann. Dadurch kann ich das Volume mounten, auf die Dateien zugreifen und die SSH-Konfiguration und Protokolle studieren.
So habe ich festgestellt, dass das Benutzerkonto aus irgendeinem Grund gesperrt ist:
$ 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.
Als ich another_user erstellte und die Schlüsselauthentifizierung einrichtete, die SSH-Passwortanmeldung deaktivierte, vergaß ich, ein nicht leeres Passwort dafür anzugeben. Das könnte also ein Grund sein, warum dieser Benutzer gesperrt ist. Wie auch immer, ich suche jetzt nach einer Möglichkeit, den Benutzer Ubuntu zumindest vorübergehend zu entsperren, um zu sehen, ob das das SSH-Zugriffsproblem behebt. Aber wie Sie sehen, kann ich keine Systembefehle verwenden, ich muss dazu in der Lage sein, indem ich die Systemdateien direkt bearbeite.
Antwort1
Es genügte, ein Zeichen in einer Datei zu ändern, um die Benutzeranmeldung ubuntuwieder zu ermöglichen:
$ cd /path/to/mounted/volume
$ sudo nano etc/shadow
# Searh for the row that starts with "ubuntu:!"
# Change the "!" to "*", save, exit
Nachdem ich das Volume wieder an die defekte Instanz angeschlossen und diese hochgefahren hatte, konnte ich mich nun normal mit dem Benutzer Ubuntu anmelden. Ich habe immer noch keine Ahnung, warum dieser Benutzer automatisch gesperrt wurde. Was den anderen Benutzer betrifft, der erstellt wurde, gehe ich davon aus, dass er gesperrt wurde, weil er ein leeres Passwort hatte, aber ich habe keine Referenz, um das zu beweisen.