☰

Einrichten von SFTP unter Amazon Linux 2 mit SSH-Schlüsseln, Benutzertrennung (SFTP vs. SSH), unterschiedlichen Ports und Benutzerverzeichnisbeschränkungen

tag-icon • tag-icon amazon-ec2 sftp ssh-keys amazon-linux amazon-linux-2
Einrichten von SFTP unter Amazon Linux 2 mit SSH-Schlüsseln, Benutzertrennung (SFTP vs. SSH), unterschiedlichen Ports und Benutzerverzeichnisbeschränkungen

TDLR: Bei mir gibt es ein Dilemma: Abhängig von den Berechtigungen für das Home-Verzeichnis des Benutzers kann ich entweder die SSH-Authentifizierung oder die Benutzerverzeichnisbeschränkungen zum Laufen bringen, aber nicht beides.

Übrigens möchte ich wirklich meinen eigenen SFTP-Server einrichten. Bitte empfehlen Sie mir nicht, den AWS Transfer-Dienst oder eine Alternative auszuprobieren. Danke.

Hier ist der relevante (vom Standard geänderte) Inhalt in /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Port 22
Port 2299
Match Group sftpusers LocalPort 2299
  ChrootDirectory /sftp-data/%u
  ForceCommand internal-sftp
Match Group sftpusers LocalPort 22
  DenyGroups sftpusers
Match LocalPort 2299  Group *,!sftpusers
  DenyUsers *

Ich möchte, dass Port 22 wie SSH funktioniert, aber nur für Nicht-SFTP-Benutzer. Für SFTP-Benutzer in der Gruppe „SFTPUsers“ möchte ich, dass Port 2299 nur als SFTP und nicht als SSH funktioniert. Für Nicht-SFTPUs möchte ich den Zugriff auf Port 2299 verweigern.

Ok, also habe ich einen Benutzer „user1“ mit dem Home-Verzeichnis /sftp-data/user1 und der Shell /sbin/nologin erstellt. Ich habe /sftp-data/user1/.ssh/authorized_keys erstellt und das mit dem öffentlichen SSH-Schlüssel gefüllt. /sftp-data gehört root mit 700 Berechtigungen. /sftp-data/user1/.ssh und darunter gehören user1, und /sftp-data/user1/.ssh/authorized_keys hat die Berechtigung 600. Der Besitz/die Berechtigungen von /sftp-data/user1 werden hier in Frage gestellt. Mehr dazu weiter unten.

Ich habe die Benutzergruppe sftpusers erstellt und user1 zu dieser Gruppe hinzugefügt. Der integrierte ec2-user, den Sie mit AWS erhalten, ist jedoch kein Mitglied dieser Gruppe. Der Test mit ec2-user hat gut funktioniert: Der Zugriff über ssh, Port 22, funktionierte wie immer, aber kein Zugriff auf Port 2299.

Interessant wurde es beim Testen mit Benutzer1. Benutzer1 hat keinen Zugriff auf Port 22 – das ist großartig! Da Benutzer1 /sftp-data/user1 besitzt, ist die Authentifizierung mit dem öffentlichen SSH-Schlüssel auf Port 2299 erfolgreich, der Benutzer wird jedoch sofort abgemeldet und diese Nachricht wird in /var/log/secure gespeichert:

Sep  2 19:21:38 ip-192-168-0-25 sshd[10369]: Accepted publickey for user1 from <ip-address redacted> port 61110 ssh2: ECDSA SHA256:<sha redacted>
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: bad ownership or modes for chroot directory "/sftp-data/user1" [postauth]
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session closed for user user1

Klar, das macht Sinn. Chroot erfordert, dass /sftp-data/user1 root gehört, mit Berechtigungen 700. Wenn das so ist, schlägt die SFTP-Authentifizierung (SSH-Schlüssel) fehl.

Sep  2 19:41:00 ip-192-168-0-25 sshd[11693]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redacted> failed, status 22

Übrigens ist eic_run_authorized_keys ein Wrapper, den AWS um die Standard-SSH-Authentifizierung legt, um AWS Instance Connect zu aktivieren.

Für zusätzliche Anerkennung... wenn das obige Problem nicht herausfordernd genug ist, können Sie sich ein Schema ausdenken, mit dem ich bestimmten SFTP-Benutzern Zugriff auf bestimmte Projektverzeichnisse und nur diese geben kann, ohne für jedes Projekt eine Gruppe zu erstellen? Ein Link vom Home-Verzeichnis jedes Benutzers zu einem Projektverzeichnis wäre fantastisch.

Zusätzliche von @anx angeforderte Informationen:

# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

Ich habe die DEBUG-Protokollierung für sshd aktiviert. Wenn ich die ChrootDirectory-Direktive verwende, /sftp-data/user1 dem Root gehört und die SSH-Authentifizierung fehlschlägt, sehe ich Folgendes in /var/log/secure:

debug1: Autorisierte Schlüssel '/sftp-data/user1/.ssh/authorized_keys' konnten nicht geöffnet werden: Berechtigung verweigert

PS zeigt mir deutlich, dass Root den SSHD-Prozess ausführt.

Antwort1

Ihr ChrootDirectoryist /sftp-data/user1, das root gehören muss. Und es ist:

# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

Zu diesem Zeitpunkt hat der SSHD den Benutzer jedoch bereits in Benutzer1 geändert und die Berechtigungen gelöscht, sodass Benutzer1 nicht in Verzeichnisse auf niedrigerer Ebene wechseln kann. Dazu benötigt das Verzeichnis Suchberechtigung ( a+x).

chmod a+x /sftp-data/user1

Jetzt kann Benutzer1 in Unterverzeichnisse wechseln und das .sshVerzeichnis sollte lesbar sein.

Antwort2

Ich denke, das ist in erster Linie ein Problem mit den Ordnerberechtigungen. Ich denke, dass /sftp-data/user1/.sshund die darunter liegenden Verzeichnisse Eigentum von sein müssen user1, aber es klingt, als ob sie Eigentum von sind root. Versuchen Sie Folgendes als root:

Überprüfen Sie, ob der öffentliche Schlüssel /sftp-data/user1/.ssh/authorized_keyskorrekt ist. Danach müssen Sie meiner Meinung nach möglicherweise die folgenden Berechtigungen ändern:

chmod 700 /sftp-data/user1/.ssh
chmod 600 /sftp-data/user1/.ssh/authorized_keys
chown root:sftpusers /sftp-data
chown -R user1:user1 /sftp-data/user1/.ssh

Starten Sie SSH neu, dann kann es meiner Meinung nach losgehen.

verwandte Informationen