Für einen Kunden muss ich zur Archivierung die Weiterleitung von Splunk Frozen Buckets in einem AWS S3 Bucket via sftp umsetzen.
In der AWS sind die Buckets folgendermassen organisiert:
Der root / ist die unterste Ebene auf der man keine Aktionen durchführen kann darauf sitzt der Bucket, in dem einer oder mehrer Benutzter Ordner und Dateien anlegen können. Der Bucket ist nach der Erstellung gänzlich leer
Das vorkonfigurierte sftp subsystem bei Linux oder OpenBSD lässt es zu sich verhältnismässig normal auf dem Betriebssystem zu bewegen
Aufbau eines sftp Servers der dem in der AWS so ähnlich wie möglich ist. Das ganze auf OpenBSD basis, weil mir mehrere eigene Server mit OpenBSD im Internet zur verfügung stehen.
Austausch und erweiterung der /etc/ssh/sshd_config:
# override default of no subsystems
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Match User splunk_auditlog_user
AllowTcpForwarding no
ChrootDirectory /home
ForceCommand internal-sftp -d /splunk_auditlog_user
AuthorizedKeysFile /etc/ssh/splunk_auditlog_user_authorized_keys# override default of no subsystems
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
Match User splunk_auditlog_user
AllowTcpForwarding no
ChrootDirectory /home
ForceCommand internal-sftp -d /splunk_auditlog_user
AuthorizedKeysFile /etc/ssh/splunk_auditlog_user_authorized_keysSubsystem sftp /usr/libexec/sftp-server wurde von mir auskommentiert
Subsystem sftp internal-sftp regelt das man kein eigenes chroot mit den ganzen Devices aufbauen muss.
Es gibt noch elegantere Lösungen mit Match Group das ist hier aber nicht nötig.
Das nur sftp zugelassen ist wird durch das ForceCommand sichergestellt. Abweichend von der AWS lässt es auch kein scp mehr zu. Was aber halb so wild ist, da dieses beim Kunden auch irgendwie unterbunden wurde.
Das authorized_keys file wurde ausgelagert, damit das Home Verzeichnis von splunk_auditlog_user ganz leer ist.
Die Trennung zwischen ChrootDirectory und dem wahren User home ist dem umstand geschuldet, das man unterschiedliche Ordnerrechte hat.
Neu laden der sshd_config lässt sich bei OpenBSD mit rcctl restart sshd durchführen... in einem älteren Post zum aufbau eines ssh vpn wurde auch mal zu pkill -9 sshd geraten, das ist alledings im verhältnis eine Holzhammer methode.
Hier wurde erst die Gruppe sftp angelegt (was eigentlich unnötig war, stört aber auch nicht) group add sftp
der User einfach mit useradd -m -G sftp splunk_auditlog_user und das Ordner Skelett im nachhinein gelöscht.
Auf die schnelle hab ich keine offizielle Option gefunden um user ohne Skelett Anzulegen.
-k - lässt das Homefolder leer gibt aber die Ausgabe useradd: can't open source . files dir ``-': No such file or directory
-k \root\bin (was ein leerer ordner war) was den Homefolder auch leer lässt gibt aber die Meldung useradd: No "dot" initialisation files found zurück.
OpenBSD in der Grundinstallation legt Benutzer mit seiner Namenseigenen Gruppe und den Unixrechten rwxr-xr-x also 755an. Ebenso wie den /home Ordner. Das sorgt dafür, dass wenn mehrer Benutzer vorhanden sind, bei o.a. Konfiguration alles offen da liegt. Und ggf. vom sftp user gelesen werden könnte. Will man nicht wirklich.
Das "root" Verzeichnis für chroot braucht wie beim BS selbst als Benutzer:Gruppe immer root:wheel oder wie auch immer das beim Linux der Wahl sein mag.
Durch setzen des ChrootDirectory auf /home sind Benutzer und Gruppe schonmal richtig gegeben. Sollte man erst einmal dafür sorgen, dass nicht jeder Benutzer angezeigt wird, wenn der SFTP Benutzer mal cd .. macht. Das in /home reinwechseln lässt sich nicht verhindern. Das Listen der User in dem Ordner oder zu sehen in welchem Ordner man sich befindet, schon. Durch chmod 751 /home gegeben ist. Allerdings verhindert das noch nicht das wechseln und ggf durchstöbern fremder Dateien. Dazu müssen die Rechte des Benutzers entsprechend angepasst werden. Ob es ein Problem darstellt /home/_sysupgrade ebenfalls auf 750 zu setzen ist mir nicht bekannt, kann es mir aber gerade nicht vorstellen.
Um sowas dauerhaft umzusetzten muss man wahrscheinlich die umask in der useradd config anpassen
Im nachhinein betrachtet wäre ein ChrootDirectory %h mit ForceCommand internal-sftp -d /%u sicher besser gewesen.