☰

OpenSSH - sshd_config - Erlaube sftp-chroot UND normale SSH-Anmeldung mit demselben Benutzer

tag-icon • tag-icon ssh sftp
OpenSSH - sshd_config - Erlaube sftp-chroot UND normale SSH-Anmeldung mit demselben Benutzer

Hoffentlich kein Duplikat, aber ich kann hierauf keine Antwort finden ... Ich habe das hier gefunden, das oberflächlich betrachtet dasselbe zu sein scheint, aber sehr alt ist und die einzige Antwort darin beantwortet nicht die eigentliche Frage: Legen Sie Benutzer für SFTP als chroot fest, erlauben Sie Benutzern jedoch die Anmeldung über SSH.

Ich habe erfolgreich eine funktionierende ChrootDirectory-Umgebung über SFTP für Benutzer in der Gruppe „sftp_users“ eingerichtet. Es funktioniert gut, alle erforderlichen Berechtigungen und dergleichen beschränken den Zugriff nur auf SFTP, und sie können in ihren Unterverzeichnissen im ChrootDirectory schreibgeschützte Dateien verwenden. Dies ist ideal für nicht privilegierte Benutzer, da kein SSH-Zugriff zugelassen wird und nur schreibgeschützte Dateien in ihren Unterordnern im ChrootDirectory zulässig sind.

Ich hätte gerne etwas mehr privilegierte Benutzer, die SSH weiterhin normal verwenden können, bei der Anmeldung über SFTP jedoch die ChrootDirectory-Umgebung haben. Dies ist weniger ein Sicherheitsproblem, da sie als privilegiert gelten und natürlich mit ihren normalen Benutzerberechtigungen im Dateisystem in SSH surfen können. Das Problem ist, dass ich keine Möglichkeit sehe, sie zu chrooten, wenn sie sich über SFTP anmelden, ohne die SSH-Anmeldung zu verhindern. Dies dient mehr der Standardisierung und Bequemlichkeit als allem anderen, sodass sie bei SFTP einfach an ihrem Chroot-Standort ankommen, wie die Nur-SFTP-Benutzer.

Ich dachte, das würde funktionieren, wenn ich ihre Shell als Standard lasse (nicht /bin/false oder nologin). Leider können sie sich, wenn sie sich in der Gruppe sftp_only befinden, überhaupt nicht per SSH anmelden, sondern nur per SFTP. Gibt es eine Problemumgehung dafür, außer zwei separate Konten zu haben – eines, das zu „sftp_users“ hinzugefügt wird, und eines, das nicht in dieser Gruppe ist? Bisher konnte ich nur Dokumentationen zum Einschränken des SFTP-Chroots und gleichzeitigen Verboten von SSH finden, wenn sie sich in dieser Gruppe befinden.

Beispielbenutzer ist „test“. „test“ ist in der Gruppe „sftp_users“ und kann sich daher über SFTP anmelden, in seinen angegebenen Ordner („/sftp/test“) chrooten und in seinem Home-Ordner lesen oder schreiben, der unter „/sftp/test/home“ gebunden gemountet ist. Das funktioniert alles. Aber selbst wenn seine Shell in /etc/passwd immer noch auf /bin/bash eingestellt ist, kann sich „test“ nicht über SSH anmelden, wenn er zur Gruppe „sftp_users“ hinzugefügt wurde. Entfernen Sie die Mitgliedschaft in dieser Gruppe, und er kann beides tun, ist dann aber nicht unter SFTP chrooten.

Benutzer, die nicht zur Gruppe „sftp_users“ gehören, können sich weiterhin über SSH oder SFTP anmelden, werden unter SFTP jedoch nicht in Chroot-Zugriff genommen.

Gibt es eine Möglichkeit, das verwendete Protokoll abzugleichen und/oder vielleicht eine zusätzliche Übereinstimmung für eine andere Gruppe festzulegen? Ich suche nur nach dem Chroot, wenn sie sich über SFTP anmelden. Das Nicht-Chroot über SSH ist für diese Benutzer in Ordnung.

Folgendes ist meine sshd_config:

Port XXXX
#ListenAddress ::
#ListenAddress 0.0.0.0

Protocol 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 120
PermitRootLogin no
StrictModes yes

PubkeyAuthentication yes

IgnoreRhosts yes
HostbasedAuthentication no

PermitEmptyPasswords no

ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
PrintLastLog yes

ClientAliveCountMax 10
ClientAliveInterval 3600
TCPKeepAlive no

#Banner /etc/issue.net

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server -u 0027

UsePAM yes
PasswordAuthentication yes



Match Group sftp_users
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp -u 0027
  X11Forwarding no
  AllowTcpForwarding no
  PasswordAuthentication yes

Antwort1

OpenSSH unterstützt nicht das Überschreiben globaler Schlüsselwörter basierend auf dem übermittelten Befehl. Sie müssen nach einigen (Kombinationen von) Kriterien differenzieren, die OpenSSH für die MatchAnweisung anbietet.

Die verfügbaren Kriterien sind Benutzer, Gruppe, Host, LokaleAdresse, LokalerPort, RDomain und Adresse (wobei RDomain die Rdomain(4) darstellt, auf der die Verbindung empfangen wurde).

-- man 5 sshd_config

Eine häufig gewählte Option besteht darin, absichtlich eingeschränkte Dienste auf alternativen IP-Adressen anzubieten, die über alternative Domänen wie snapshot.backup.exampleund erreicht werden sftp.backup.example.

Die Kommentare zu denverknüpfte FrageErläutern Sie das Problem jedoch deutlich.

Wenn Sie denken, Siewollensftp-Zugriff chrooted für privilegierte Benutzer, Sie verstümmeln wahrscheinlich verschiedeneRollenin identischeBenutzer, und das birgt Sicherheitsrisiken. In den meisten Fällen werden Auditing- und Privilegientrennungsbedenken besser gelöst durchmit einem anderen Benutzerwas auch immer Sie dazu veranlasst hat, Chroot-Einstellungen auch für Benutzer einzurichten, die nicht darauf beschränkt sind. Wenn es zwei verschiedene Aufgaben gibt, selbst wenn sie vom selbenPerson, und eine ist sicherer, wenn sie absichtlich eingeschränkt wird. Dann richten Sie auf jeden Fall einen neuen Systembenutzer ein (z. B. einen Benutzer haben personund person-taskdie meisten Einschränkungen und Authentifizierungsmethoden teilen und nur eine davon in SSH einschränken).

Antwort2

Dieses Problem hat mich auch verwirrt: Wenn ich Chroot SFTP für Benutzer einrichte, können sie sich nicht per SSH anmelden. Mein Szenario ist etwas anders, ich muss den Benutzern eine eingeschränkte Shell-Umgebung bereitstellen, während die Benutzer weiterhin SFTP und SCP benötigen, um auf ihr Home-Verzeichnis für RW sowie ein bestimmtes öffentliches Verzeichnis zuzugreifen, z. B. /home/public für RDONLY.

Zuerst habe ich eine Jailed Shell entwickelt. Ich wollte, dass diese Shell mit OpenSSH Internal-SFTP zusammenarbeiten kann, um meine Anforderungen zu erfüllen. Dann stellte ich fest, dass dies fehlschlug, da OpenSSH Benutzern keine SSH-Anmeldung erlaubt, wenn Chroot Internal-SFTP aktiviert ist.

Also musste ich die Jailed Shell ändern, um das Home Jailed SFTP und SCP zu unterstützen. Es ist ein bisschen knifflig, dass ich ptrace-Systemaufrufe verwendet habe, um das Jailed SFTP zu implementieren. Wenn diese Informationen für Sie nützlich sind, können Sie sich auf Folgendes beziehen: https://github.com/diggerwoo/jsh.

verwandte Informationen