SSH-Zugang für Nicht-Administratoren

  • Use Case:

    Bisher hatte ich mein System so konfiguriert, dass ein borg backup client sich via SSH-Key einloggen kann und sich mit dem als command in der authorizedkeys-Datei eingetragenen borg serve (von borg-backup) Server verbinden kann.

    Feature-Wunsch 1:

    Als Administrator möchte ich einen Benutzer anlegen können, der uneingeschränkten SSH-Zugang hat, aber kein Administrator ist. Eventuell über eine weitere Gruppe "ssh-cli-user".

    Feature-Wunsch 2:

    Als Administrator möchte ich einschränken können, welche Benutzer überhaupt (eingeschränkten) SSH-Zugang bekommen, wenn diese kein Administrator sind. Eventuell über eine Gruppe "ssh-restricted-user".

    Feature-Wunsch 3 (Optional):

    Als Administrator möchte ich die Liste der Kommandos für Benutzer mit eingeschränktem SSH-Zugang anpassen können.

  • Feature Wunsch 1 und 2: Das sollte über die Datei /etc/ssh/sshd_config lösbar sein.

    Feature Wunsch 3: Da fällt mir gerade außer der "sudoers" Datei nichts ein. Das Problem sollte aber auch mit Hausmitteln lösbar sein. Diesen Wunsch kann ich mir nicht vorstellen, das der nicht schon mal angetragen wurde. 😉

  • karl-heinz-lnx Das mit der sshd_config hat mich auch eine Idee gebracht.

    Derzeit steht dort:

    ForceCommand /etc/ssh/force_command.sh

    Aber was ich gar nicht bedacht hatte, diese Zeile ist auch über über

    Match Group ssh-cli-user
      ForceCommand /bin/true

    überschreibbar. Ich hatte das force_command.sh angepasst:

    if id -nG "$USER" | grep -qw -E "admin|root"; then

    zu

    if id -nG "$USER" | grep -qw -E "admin|root|sshuser"; then

    dann mit den commands addgroup ssh-cli-user und usermod -aG ssh-cli-user backup-user für meine backup-user freigeschaltet.

    Im /home/backup-user/.ssh/authorized_keys, dann natürlich in diesem Fall einen ssh-public-key mit dem command="borg-serve ..." ssh-ed25519 [PUB_KEY] eingetragen.

    sudo-rechte brauche ich in diesem Fall nicht, wollte ich SSH-Zugang für bestimmte Standardbenutzer.

    Mein Request bezüglich der Kommandos bezieht sich hauptsächlich auf das force_command.sh, wo die Kommandos einfach hartkodiert wurden. Ist legitim, wenn man die Sicherheit bedenkt, aber sehr unflexibel. Vor allem wenn man eventuell weitere Tools per App Center nach installiert oder wie in meinem Fall borg backup benutzen will.

    Toll finde ich ja grundsätzlich, dass man rsync/scp/sftp für nicht Admins möglich machen will, aber mir wäre es lieber, wenn ich mir aussuchen dürfte, welche User Accounts das genau sind. scp und rsync sind zu wenig isoliert.

  • Schau mal, was nach einem Reboot von manchen Modifikationen übrigbleibt. Manchmal ist es recht schwer zu durchschauen, was da woher beim Booten zusammengebastelt wird.

    DS1522+ | DSM 7.3.2-86009U1 (Final) | 40 GB RAM | 3 x WD 14TB WD140EFGX Red Plus SHR, 2 x M.2-Samsung 980 Pro SSD 1TB SHR
    DS415+ | DSM 7.1.1-42962-9 (Final) | 8 GB RAM | 3 x WD 6TB WD60EFRX Red Raid5, 1 x SSD Intel 128GB Basic
    Ugreen NAS DPX4800Plus, UGOS 1.13.1.0105, 2x Samsung 990 EVO Plus NVMe M.2 SSD 2 TB Raid1, 3*Toshiba MG10ACA20TE HDD 20TB Raid5, 64GB RAM -> 2 x Crucial DDR5 RAM 32GB 4800MHz SODIMM

  • Um welche Datei geht es? Um die /etc/ssh/sshd_config?
    In meinem Fall hat es geholfen, unter /etc/ssh/sshd_config.d einfach eine Datei z.B. irgendwas.conf anzulegen mit allen Modifikationen gegenüber der Originaldatei, anstatt das Original zu ändern. in meinem Fall also z.B.

    Code
    PermitRootLogin yes
    PubkeyAcceptedAlgorithms +ssh-rsa


    Scheinbar werden diese Dateien bei einem Reboot auch noch durchlaufen. Seitdem klappt es auch nach einem Reboot. Diesen Hinweis habe ich eher durch Zufall gefunden.

    DS1522+ | DSM 7.3.2-86009U1 (Final) | 40 GB RAM | 3 x WD 14TB WD140EFGX Red Plus SHR, 2 x M.2-Samsung 980 Pro SSD 1TB SHR
    DS415+ | DSM 7.1.1-42962-9 (Final) | 8 GB RAM | 3 x WD 6TB WD60EFRX Red Raid5, 1 x SSD Intel 128GB Basic
    Ugreen NAS DPX4800Plus, UGOS 1.13.1.0105, 2x Samsung 990 EVO Plus NVMe M.2 SSD 2 TB Raid1, 3*Toshiba MG10ACA20TE HDD 20TB Raid5, 64GB RAM -> 2 x Crucial DDR5 RAM 32GB 4800MHz SODIMM

    Edited once, last by Benares (September 29, 2025 at 9:05 PM).

  • Aber die zugehörigen Prozesse müsste man dann auch neu starten, das wired ein ziemliches gebastel :/

    DS1522+ | DSM 7.3.2-86009U1 (Final) | 40 GB RAM | 3 x WD 14TB WD140EFGX Red Plus SHR, 2 x M.2-Samsung 980 Pro SSD 1TB SHR
    DS415+ | DSM 7.1.1-42962-9 (Final) | 8 GB RAM | 3 x WD 6TB WD60EFRX Red Raid5, 1 x SSD Intel 128GB Basic
    Ugreen NAS DPX4800Plus, UGOS 1.13.1.0105, 2x Samsung 990 EVO Plus NVMe M.2 SSD 2 TB Raid1, 3*Toshiba MG10ACA20TE HDD 20TB Raid5, 64GB RAM -> 2 x Crucial DDR5 RAM 32GB 4800MHz SODIMM

  • Für manche Anwendungsfälle ist es eventuell besser und auch sicherer, einen opensshd docker container zu verwenden. Allerdings muss man da wieder auf das Mapping der Berechtigungen achten. In meinem Fall wäre das durch aus eine Option. Ich kenne allerdings nicht die gesamte Produktpalette, ob das alle NAS-Varianten können.

    Wenn ich so etwas allerdings für mehrere Benutzer machen möchte, ist die direkte Modifikation wohl das einfachste.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!