Ich habe eine funktionierende EC2-Instanz mit mehreren Benutzern, von denen einige in ihren Home-Verzeichnissen chrootet sind, andere nur FTP verwenden und keinen Shell-Zugriff haben usw. ec2-user ist das Hauptadministratorkonto, obwohl andere auch Root-Zugriff und vollständige SSH-Anmeldungen haben. Auf der laufenden Instanz funktioniert alles einwandfrei.
Ich kann ein Snapshot-Image der Instanz erstellen und neue Instanzen aus dem Snapshot starten. Unabhängig davon, was ich hinsichtlich des mit der neuen Instanz verknüpften Schlüsselpaars auswähle (das ursprüngliche Schlüsselpaar für den EC2-Benutzer verwenden, ein neues Schlüsselpaar erstellen oder kein Schlüsselpaar verwenden), kann ich, sobald die neue Instanz gestartet und ausgeführt wird, nicht mehr per SSH auf den Server zugreifen, indem ich den EC2-Benutzer oder einen anderen SSH-fähigen Benutzer verwende. FTP funktioniert jedoch einwandfrei.
Sicherheitsgruppen sind kein Problem, soweit ich das beurteilen kann, wird der eingehende Datenverkehr zugelassen (und es handelt sich sowieso um dieselbe Sicherheitsgruppe wie bei der ursprünglichen Instanz).
Das /var/log/secure der Login-Versuche gibt mir:
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx
sshd[1739]: debug1: do_cleanup
Es ist derselbe Fehler bei allen SSH-fähigen Benutzern. Wie Sie dem Protokoll entnehmen können, habe ich meine sshd_config auf der ursprünglichen Instanz so geändert, dass sie im Ordner /etc/ssh/keys nach den öffentlichen Schlüsseln sucht.
Ich habe die ausgefallenen Instanzen als Volumes auf der funktionierenden Instanz gemountet. Die Schlüssel befinden sich im Ordner, mit denselben Berechtigungen und denselben Schlüsselwerten, alles wie erwartet. Hier ist ls -al des Schlüsselordners (.) und der ec2-user-Datei.
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 .
-rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
Was könnte die Ursache dieses Problems sein? Ich möchte das Problem beim Speichern und Starten eines Snapshots oder beim Einrichten der ursprünglichen Instanz lösen, aber nicht die problematische Instanz mounten und manuelle Änderungen vornehmen, sodass sie zwar funktioniert, das größere Problem jedoch nicht behebt.
UPDATE: Hier sind die aktiven Einstellungen in der Datei sshd_config:
#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#...
X11Forwarding yes
#...
Subsystem sftp internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...
Antwort1
Ich vermute, dass es sich hier um ein SELinux-Problem handelt. Überprüfen Sie den Kontext des von Ihnen verwendeten Ordners. Ich gehe davon aus, dass er für die Speicherung von Schlüsseln nicht geeignet ist.
Leider habe ich keinen Zugriff mehr auf eine Redhat-Box, um den Kontext genau zu ermitteln. Versuchen Sie dennoch Folgendes:
ls -lZ /root/.ssh
Dadurch wird der Selinux-Kontext erzeugt, den Ihr neuer Ordner haben muss. Wenn ich mich richtig erinnere, sollte es so etwas wie system_u:system_r:sshd_t sein
Dann müssen wir diesen Sicherheitskontext auf Ihren neuen Speicherort für autorisierte Schlüssel anwenden:
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
Dadurch wird der richtige Kontext mit dem neuen Schlüsselstandort verknüpft. Schließlich können wir den Kontext auf den neuen Standort anwenden
restorecon -Rv /etc/ssh/keys
Antwort2
Ist die Direktive „AllowUsers“ in sshd_config gesetzt? Vielleicht ist sie auf dem Originalserver auf einen bestimmten Benutzer gesetzt und ssh wurde noch nicht neu gestartet, so dass es immer noch alle Benutzer akzeptiert?
Oh, ich habe gerade dies im Debug gesehen: „Benutzer ec2-user stimmt nicht mit Gruppenliste sftponly in Zeile 142 überein“. Überprüfen Sie sshd_config. Möglicherweise haben Sie eine Gruppe nicht zugelassen oder nur sftp zugelassen?