Linux: SFTP-only SSH Server

Es wird ein OpenSSH Server eingerichtet, über den Benutzer nur mit dem SSH SFTP-Subsystem Datentransfers in ihrer chroot Umgebung ausführen können. Der Server soll nur Protokoll 2 unterstützen und so sicher wie möglich eingerichtet und betrieben werden. Damit und aufgrund der Verschlüsselungskapazitäten von OpenSSH ist der Server eine Alternative zu privat betriebenen FTP Servern mit oder ohne FTPS Unterstützung. Wer das Ganze bequemer und mit grafischer Administration haben möchte, kann sich MySecureShell anschauen.

Installation

sudo aptitude install openssh-server
sudo chmod 640 /etc/ssh/sshd_config

Falls man Benutzer mit PuTTY-basierten SSH-Anwendungen bedienen muss:

sudo aptitude install putty-tools

Konfiguration

Host-Schlüssel

Während der Installation werden automatisch Host-Schlüssel erstellt und die generierten Moduli für das Diffie-Hellman Group Exchange Schlüsselaustauschverfahren in der /etc/ssh/moduli Datei gespeichert. Beide Bestandteile werden neu generiert:

sudo systemctl stop ssh.service
sudo rm /etc/ssh/moduli /etc/ssh/ssh_host*
ssh-keygen -G /pfad/moduli.test -b 4096
sudo ssh-keygen -T /etc/ssh/moduli -f /pfad/moduli.test
rm /pfad/moduli
 
sudo ssh-keygen -t rsa -b 3072 -C "sub.domain.tld" -f /etc/ssh/ssh_host_rsa_key < /dev/null
sudo ssh-keygen -t ed25519 -C "sub.domain.tld" -f /etc/ssh/ssh_host_ed25519_key < /dev/null

Fingerprint

Nachdem Host-Schlüssel erstellt wurden, werden ihre Fingerprints direkt angezeigt:

The key fingerprint is:
1b:7b:9b:ee:1f:2a:40:85:c7:8d:8a:fd:a2:ba:8a:6d sub.domain.tld

Zu einem späteren Zeitpunkt kann man sich Fingerprints so ausgeben lassen:

sudo ssh-keygen -l -f /etc/ssh/ssh_host_[rsa|ed25519]_key.pub
3072 1b:7b:9b:ee:1f:2a:40:85:c7:8d:8a:fd:a2:ba:8a:6d  sub.domain.tld (RSA)
256 56:0b:a5:92:ca:cb:15:04:31:d7:7e:79:13:23:20:9a  sub.domain.tld (ED25519)

Die Fingerprint-Angaben sollte man Benutzern vorab und nach einem Austausch der Host-Schlüssel über einen sicheren Kanal mitteilen (z. B. per GnuPG verschlüsselter und signierter E-Mail, s. u.). Man kann sie auch in den Inhalt einer Bannerdatei aufnehmen.

sshd_config

allgemeine Einstellungen

Option Wert Informationen
AcceptEnv
PermitUserEnvironment
no Vom Client gesendete bzw. vom Benutzer gesetzte Umgebungsvariablen werden nicht akzeptiert.
AddressFamily inet|inet6|any IPv4, IPv6 oder beide Protokolle werden vom sshd bedient.
AllowAgentForwarding
AllowTcpForwarding
X11Forwarding
no Weiterleitungen von TCP Ports, ssh-agent und X11 Verbindungen sind verboten.
AllowGroups sftpuser Nur Mitgliedern der sftpuser Gruppe ist der Zugang zum Server erlaubt.
ClientAliveCountMax
ClientAliveInterval
n1
n2
Sendet der Client n2 Sekunden lang keine Daten, wird eine Alive-Nachricht über den verschlüsselten Kanal an den Client gesendet und das n1 Mal.
Beispiel: bei n1=4 und n2=45 wird die Verbindung zum Client spätestens nach 180 Sekunden beendet, wenn keine Antwort-Nachrichten zurückkamen.
Compression no|yes|delayed (Keine) Datenkompression oder Datenkompression erst nach Authentifizierung.
DebianBanner no Es werden keine zusätzlichen, distributionsspezifischen Versionsangaben an Benutzer ausgegeben.
LoginGraceTime
MaxAuthTries
MaxSessions
MaxStartups
n Hat sich ein Benutzer nach n Sekunden LoginGraceTime nicht authentifiziert, wird die Verbindung beendet. Pro Verbindung werden nach n/2 fehlgeschlagenen Authentifizierungsversuchen (MaxAuthTries) weitere Fehlschläge geloggt. Pro Verbindung können maximal n Sitzungen (MaxSessions) geöffnet werden und der sshd akzeptiert maximal n gleichzeitige Verbindungsaufnahmen ohne erfolgte Authentifizierung (MaxStartups).
PermitRootLogin no|forced-commands-only root kann sich nicht anmelden oder (mit einer anderen sshd Konfiguration und entsprechenden Kommandoangaben in seinem AuthorizedKeysFile) nur eine bestimmte Kommandozeile ausführen.
Port
ListenAddress
n
IP
Port und IP-Adresse, an denen der sshd lauscht. Den Standard-Port 22 sollte man ändern, um zumindest herkömmliche Anmelde- oder Einbruchsversuche unberechtigter Benutzer nach Standard-Portscans auf Port 22 zu verringern.
Protocol 2 Es wird nur das SSH Protokoll 2 verwendet.
ChallengeResponseAuthentication
GSSAPIAuthentication
HostbasedAuthentication
KerberosAuthentication
KerberosOrLocalPasswd
RSAAuthentication
für alle: no Alle Authentifizierungsverfahren, die nicht erlaubt sein sollen.
Subsystem sftp internal-sftp -l INFO -umask 0027 Auf Anfrage wird der prozessinterne SFTP-Server als Subsystem gestartet, der mit Logstufe INFO loggt und neue Daten mit einer initialen umask anlegt/speichert.
TCPKeepAlive no Keine TCP keepalive Nachrichten.
UseDNS no Keine DNS-Abfragen zur Überprüfung der Client Hostname ↔ IP Zuordnung.

Verschlüsselung

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com Symmetrischer Algorithmus des Schlüssels zur Verschlüsselung der transportierten Daten

Liste unterstützter Ciphers:
ssh -Q cipher-auth
ssh -Q cipher
HostKey
HostKey
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_ed25519_key
Es wird nur ein RSA und Ed25519 Host-Schlüssel eingesetzt, kein DSA und ECDSA Host-Schlüssel

siehe man sshd_config
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256 Schlüsselaustausch-Verfahren und -Algorithmen

Liste unterstützer Verfahren:
ssh -Q kex
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 Verwendete Message Authentication Code (MAC) Verfahren und Hash-Algorithmen zur Prüfung der Daten- bzw. Sitzungsintegrität

Liste unterstützer MACs:
ssh -Q mac

Bei der Auswahl von Algorithmen und Verfahren ist ggf. zu bedenken, welche SSH-Version und SSH-Clients Benutzer einsetzen, die den SFTP-Server aufsuchen. Hat man es z. B. nur mit Benutzern zu tun, die eine aktuelle OpenSSH Version einsetzen und in der Lage bzw. bereit dazu sind, SFTP in der Konsole zu nutzen, kann man auf Kompatibilitätserwägungen verzichten und nur die als besonders stark bzw. sicher eingeschätzten Algorithmen und Verfahren setzen. Anders sieht es aus, wenn man Benutzer mit unterschiedlichsten Clients bedienen möchte oder muss, die nur eine Auswahl der OpenSSH Algorithmen und Verfahren unterstützen.

Benutzer-Authentifizierung

Nur-Schlüssel
AuthenticationMethods publickey Liste aller Authentifizierungsverfahren, die der Benutzer erfolgreich durchlaufen muss, bevor Zugang gewährt wird.
PubkeyAuthentication
PasswordAuthentication
UsePAM
yes
no
no
Nur die Authentifizierung per Schlüssel erlaubt.
Schlüssel + Passwort
AuthenticationMethods publickey,password Liste aller Authentifizierungsverfahren, die der Benutzer erfolgreich durchlaufen muss, bevor Zugang gewährt wird.
PubkeyAuthentication
PasswordAuthentication
UsePAM
yes
yes
yes
Der Benutzer muss sich mit seinem Schlüssel und danach per Passwort authentifizieren.

Auch bei der Benutzer-Authentifizierung muss man ggf. in Betracht ziehen, mit welchen Benutzerkreisen und Systemumgebungen man es mehrheitlich zu hat. Andere Benutzer werden ihre Schlüssel auch aus Bequemlichkeit nicht mit einem Passwort geschützt abspeichern und wenn, dann vielleicht auch mit „123456“ in einer eher unsicheren Systemumgebung. In dem Fall wäre es vielleicht angebracht, vom Benutzer eine quasi „2-Factor“ Authentifizierung zu erzwingen, indem er sich mit Schlüssel und (einer ausreichend starken) Passphrase authentifizieren muss. Falls ein Angreifer z. B. per Trojaner in den Besitz der Schlüsseldatei und der Passphrase gelangt, weil die vom Benutzer im Klartext in einer „passphrase.txt“ Datei gespeichert wurde, hilft das natürlich auch nichts.

Anders schaut es aus, wenn man von Benutzern ausgeht, die Schlüssel generell mit einer starken Passphrase in einer eher geschützten Systemumgebung speichern, wo u. a. das Verzeichnis, in dem sich die SSH Schlüsseldateien und die SSH Konfiguration befinden, vor dem Zugriff durch Dritte, andere Netzwerkanwendungen usw. geschützt ist. In dem Fall kann man auf die Authentifizierung nur per Schlüssel setzen, wobei eine zusätzliche, ausreichend starke Passphrase, die nicht per Brute-Force zu berrechnen ist, auch nicht schaden kann.

SFTP Benutzer

Benutzergruppe

Zuerst wird für alle Benutzer eine Gruppe angelegt:

sudo groupadd sftpuser

Für die Gruppe wird die sshd_config ergänzt:

/etc/ssh/sshd_config
Match Group sftpuser
  ChrootDirectory %h
  AuthorizedKeysFile %h/.ssh/dateiname
  Banner /chroot/sftpuser/banner
  ForceCommand internal-sftp -l INFO -u 0027

Trifft auf einen Benutzer zu, dass er Mitglied der sftpuser Gruppe ist, wird das chroot Verzeichnis auf sein Heimatverzeichnis gesetzt. Als Name der Datei, die die öffentlichen Schlüssel der Benutzer aufnimmt, wird nicht der Standardname authorized_keys verwendet, sondern ein nicht zu erratender String aus zufälligen Zeichen als dateiname. Vor der Authentifizierung werden allen Benutzern der Inhalt der Bannerdatei angezeigt. Mit none statt der Pfadangabe wird die Ausgabe einer Bannerdatei deaktiviert. Der Benutzer kann nach der Authentifizierung nur das prozessinterne SFTP-Subystem nutzen, wobei Verzeichnisse und Dateien initial mit der angegebenen umask (-u umask) im incoming Verzeichnis angelegt und gespeichert werden. Die Benutzer können jedoch mit den enstprechenden interaktiven SFTP-Kommandos die Zugriffs- und Besitzrechte der Verzeichnisinhalte ändern.

Home-Verzeichnisse

Für die sftpuser Gruppe wird das Heimatverzeichnis erstellt:

sudo mkdir -p /chroot/sftpuser/alle/{dev,pub,incoming,.ssh}
sudo chmod 755 /chroot
sudo chmod -R 750 /chroot/sftpuser
sudo chmod 770 /chroot/sftpuser/alle/incoming
sudo chmod -R 710 /chroot/sftpuser/alle/{dev,.ssh}
sudo chown :sftpuser -R /chroot/sftpuser
sudo touch /chroot/sftpuser/alle/.ssh/dateiname
sudo chmod 640 /chroot/sftpuser/alle/.ssh/dateiname

Anlage der Benutzer

Für alle Benutzer, die ein gemeinsames Heimatverzeichnis nutzen:

sudo useradd -g sftpuser -M -d /chroot/sftpuser/alle -s /usr/sbin/nologin pseudonym
sudo passwd pseudonym

Für jeden Benutzer mit eigenem Heimatverzeichnis:

sudo cp -pR /chroot/sftpuser/alle/ /chroot/sftpuser/pseudonym/
sudo touch /chroot/sftpuser/pseudonym/.ssh/dateiname
sudo useradd -g sftpuser -M -d /chroot/sftpuser/pseudonym -s /usr/sbin/nologin pseudonym
sudo passwd pseudonym

Schlüssel und Konfiguration für Benutzer

Für den Benutzer wird ein Ed25519 und RSA Schlüssel erstellt.

Für OpenSSH >= 6.5:

ssh-keygen -t ed25519 -C pseudonym -a 1024 -f /pfad/pseudonym_id_ed25519
ssh-keygen -t rsa -C pseudonym -b 3072 -o -a 1024 -f /pfad/pseudonym_id_rsa

Für andere SSH-Anwendungen, die nicht mit dem neuen Schlüsselformat v. OpenSSH >= 6.5 umgehen können, wie z. B. PuTTY-basierte Anwendungen:

ssh-keygen -t rsa -C pseudonym -b 3072 -f /pfad/pseudonym_id_rsa
puttygen /pfad/pseudonym_id_rsa -o /pfad/pseudonym_id_rsa.ppk
puttygen -C pseudonym /pfad/pseudonym_id_rsa.ppk

In jedem Schlüssel wird das Pseudonym als Kommentar hinterlegt, so dass keine Informationen zu realen Identitäten bzw. Benutzerkennungen des Systems im Kommentar enthalten sind und die Schlüssel besser zu unterscheiden sind. Anschließend werden die Daten der öffentlichen Benutzerschlüssel in die AuthorizedKeysFile Datei übertragen:

Für alle Benutzer, die ein gemeinsames Heimatverzeichnis nutzen:

cd /pfad
sudo cat pseudonym_id_ed25519.pub >> /chroot/sftpuser/alle/.ssh/dateiname
sudo cat pseudonym_id_rsa.pub >> /chroot/sftpuser/alle/.ssh/dateiname

Für jeden Benutzer mit eigenem Heimatverzeichnis:

cd /pfad
sudo cat pseudonym_id_ed25519.pub > /chroot/sftpuser/pseudonym/.ssh/dateiname
sudo cat pseudonym_id_rsa.pub >> /chroot/sftpuser/pseudonym/.ssh/dateiname

Man kann seinen Benutzern eine für den SFTP-Server passende ssh_config Datei erstellen, die im Grunde die Konfiguration des SSH-Servers (unter Beachtung der Optionen zur Verschlüsselung) in der sshd_config widerspiegelt:

~/.ssh/ssh_config
Host sub.domain.tld
  Port nnnn  # des eigenen SSH-Servers
  User pseudonym
  AddressFamily inet|inet6
  CheckHostIP no  # wenn SSH-Server hinter dyn. IP, die öfters wechselt
  ChallengeResponseAuthentication no
  Ciphers siehe oben
  Compression no
  GSSAPIAuthentication no
  HashKnownHosts yes
  HostbasedAuthentication no
  HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ssh-rsa-cert-v01@openssh.com,ssh-rsa
  IdentitiesOnly yes
  IdentityFile ~/.ssh/pseudonym_id_ed25519
  IdentityFile ~/.ssh/pseudonym_id_rsa
  KbdInteractiveAuthentication no
  KexAlgorithms siehe oben
  LogLevel INFO
  MACs siehe oben
  PasswordAuthentication yes oder no  # s. o. AuthenticationMethods
  PreferredAuthentications publickey oder publickey,password  # s. o. AuthenticationMethods
  PubkeyAuthentication yes
  Protocol 2
  RhostsRSAAuthentication no
  RSAAuthentication no
  SendEnv 
  ServerAliveInterval 10
  StrictHostKeyChecking ask
  TCPKeepAlive no

Kontaktaufnahme

Vor der ersten Verbindung übermittelt man dem Benutzer über einen sicheren Kanal (z. B. per GnuPG verschlüsselter und signierter E-Mail) die Verbindungsdaten, seine Schlüsseldateien und ggf. die ssh_config Datei – z. B. so:

SFTP-Server: sub.domain.tld
Port: nnnn
Fingerprints:
3072 1b:7b:9b:ee:1f:2a:40:85:c7:8d:8a:fd:a2:ba:8a:6d  sub.domain.tld (RSA)
256 56:0b:a5:92:ca:cb:15:04:31:d7:7e:79:13:23:20:9a  sub.domain.tld (ED25519)

Benutzername: pseudonym
Benutzer-Passphrase: string
Schlüssel-Passphrase: string

 * die "id_*" Schlüsseldateien in ~/.ssh speichern bzw. z. B. PuTTY-Profil zuordnen
 * den Inhalt der beigefügten ssh_config in die eigene ssh_config aufnehmen.

Zur Verbindungsaufnahme:
sftp -F ~./.ssh/ssh_config sub.domain.tld
psftp -2 -i /pfad/pseudonym_id_rsa.ppk -P nnnn pseudonym@sub.domain.tld

Sofern Benutzer ihre Schlüssel selbst erstellen (sollen) und sie an den Admin des SSH-Servers senden, entfällt natürlich die Erstellung der Benutzer-Schlüssel. In dem Fall überträgt man nur die Inhalte der erhaltenen Schlüssel in die entsprechende AuthorizedKeysFile Datei und teilt dem Benutzer bis auf abweichenden Parameter (Schlüssel-Passphrase, Schlüsseldatei speichern) und eine ssh_config mit geänderten IdentityFile Angaben die Verbindungsdaten mit.

Up- und Download Verzeichnisse

Entweder können die Gruppenmitglieder bzw. einzelne Benutzer Daten direkt in das incoming Verzeichnis ihres Stammverzeichnisses hochladen und in das pub Verzeichnis kopierte Daten direkt herunterladen oder es werden andere Verzeichnisse in das pub Verzeichnis eingehängt.

Für ein Unterverzeichnis im pub Verzeichnis:

sudo chown :sftpuser -R /pfad/name/
sudo mkdir /chroot/sftpuser/[alle|pseudonym]/pub/name/
sudo mount --bind /pfad/name/ /chroot/sftpuser/[alle|pseudonym]/pub/name/
sudo mount -o remount,ro /chroot/sftpuser/[alle|pseudonym]/pub/name/

Mit dem ersten Skript werden mehrere Verzeichnisse für alle Gruppenmitglieder bzw. einen Benutzer in gleichlautende Unterverzeichnisse im pub Verzeichnis eingehängt. Mit dem zweiten Skript werden alle Unterverzeichnisse wieder ausgehängt. Über entsprechende Anweisungen in der ssh.service Systemd-Datei werden die Skripte automatisch nach Start und Beendigung des sshd ausgeführt.

#!/bin/bash
# sftpmount
 
# user="alle"
# oder 
# user="pseudonym"
userdir="/chroot/sftpuser/$user"
dirs=(/pfad/dir1 /pfad/dirN)
 
for i in "${dirs[@]}"; 
  do mount --bind $i $userdir/pub/$(basename $i)/ && mount -o remount,ro,bind,nodev,nosuid,noexec $userdir/pub/$(basename $i) ; 
done
 
/etc/cron.hourly/sftpbanner
 
exit 0
#!/bin/bash
# sftpumount
 
# user="alle"
# oder 
# user="pseudonym"
userdir="/chroot/sftpuser/$user"
pubsubdirs=(dir1 dirN)
 
for i in "${pubsubdirs[@]}"; 
  do umount $userdir/pub/$i/; 
done
 
exit 0
sudo cp /lib/systemd/system/ssh.service /etc/systemd/system/
sudo vi /etc/systemd/system/ssh.service
/etc/systemd/system/ssh.service
[Service]
ExecStartPre=/pfad/sftpmount
ExecStopPost=/pfad/sftpumount

Wichtige Kommandos

Eine kleine Auflistung der wichtigsten Kommandos, die man als Benutzer während einer SFTP-Sitzung interaktiv einsetzt:

sftp psftp Beschreibung
help help alle Kommandos anzeigen
help Kommando genauere Erklärung zum Kommando
cd pfad cd pfad in remote Verzeichnis wechseln
lcd pfad lcd pfad in lokales Verzeichnis wechseln
pwd pwd aktuellen remote Verzeichnispfad ausgeben
lpwd lpwd aktuellen lokalen Verzeichnispfad ausgeben
ls -l ls|dir remote Verzeichnisinhalt ausführlich ausgeben
lls !ls|!dir [-la] lokalen Verzeichnisinhalt ausgeben
mkdir verzeichnis mkdir verzeichnis remote Verzeichnis erstellen
lmkdir verzeichnis !kmdir verzeichnis lokales Verzeichnis erstellen
rm dateiname rm|del dateiname remote Datei löschen
rmdir verzeichnis rmdir verzeichnis remote Verzeichnis löschen
rename dateiname (alt) dateiname (neu) mv|ren dateiname (alt) dateiname (neu) remote Datei umbenennen/verschieben
put dateiname (lokal) [dateiname (remote)] put dateiname (lokal) [dateiname (remote)] Datei hochladen [und ggf. in anderem Verzeichnis/mit anderem Dateinamen speichern]
reput dateiname (lokal) [dateiname (remote)] unterbrochenen Dateiupload fortsetzen
get dateiname (remote) [dateiname (lokal)] get dateiname (remote) [dateiname (lokal)] Datei runterladen [und ggf. in anderem Verzeichnis/mit anderem Dateinamen speichern]
reget dateiname (remote) [dateiname (lokal)] unterbrochenen Dateidownload fortsetzen
!Kommando !Kommando Kommando in lokaler Shell ausführen
! / exit !Shellname / exit in lokale Shell wechseln / lokale Shell verlassen
exit|bye|quit exit|bye|quit SFTP-Sitzung beenden

Hinweis: Dateinamen mit Leerzeichen müssen mit 'dateiname' eingeschlossen werden.

Logging

Die Nachrichten des sshd und des SFTP-Subsystems sollen in einer eigenen Logdatei in einem eigenen Logverzeichnis geloggt werden.

sudo mkdir /var/log/sshd
sudo chown syslog:adm /var/log/sshd
sudo chmod 750 /var/log/sshd

Dem sshd wird eine unbenutzte Log-Instanz zugeordnet, da mit AUTH als Standard alle sshd Nachrichten in /var/log/auth.log gespeichert werden:

/etc/ssh/sshd_config
SyslogFacility LOCAL3
LogLevel INFO

Damit der prozessinterne SFTP-Server innerhalb der chroot Umgebung seine Nachrichten nach /dev/log absetzen kann und der rsyslogd die Nachrichten erhält, wird eine zusätzliche rsyslogd Konfigurationsdatei erstellt, die den rsyslogd anweist, die /dev/log Unix-Socket Datei im Stammverzeichnis der Gruppe (# oder auch eines einzelnen Benutzers) zu erstellen. Über die local3.info Selektorangabe und die Eigenschaften-Filter loggt der rsyslogd die SFTP Nachrichten in die /var/log/sshd/sftp.log Datei.

/etc/rsyslog.d/ssh-sftp.conf
$AddUnixListenSocket /chroot/sftpuser/alle/dev/log
# $AddUnixListenSocket /chroot/sftpuser/pseudonym/dev/log
 
local3.info     -/var/log/sshd/sftp.log
 
:programname,contains,"internal-sftp" -/var/log/sshd/sftp.log
& stop

Für die Rotation der Logdatei:

/etc/logrotate.d/ssh-sftp
/var/log/sshd/sftp.log {
        weekly
        missingok
        rotate 4
        compress
        delaycompress
        postrotate
                invoke-rc.d rsyslog restart >/dev/null 2>&1 || true
        endscript
}

Quota

Um die Mitglieder der sftpuser Gruppe daran zu hindern, den Plattenplatz durch Uploads vollständig zu belegen, sollte man den Speicherplatz durch Quota beschränken. Für die sftpuser Gruppe wird deshalb Journaling Quota für das /chrootfs ext4 Dateisystem eingerichtet, um den Platzverbrauch durch Uploads in das /chroot/sftpuser/alle/incoming/ Verzeichnis zu begrenzen.

In der Bannerdatei (s. o. Banner Option), die Benutzern vor der Authentifizierung angezeigt wird, kann man Benutzern Informationen mitteilen, die einem wichtig erscheinen. Dazu legt man zuerst die Bannerdatei für die sftpuser Gruppe an:

sudo touch /chroot/sftpuser/banner
sudo chown :sftpuser /chroot/sftpuser/banner
sudo chmod 640 /chroot/sftpuser/banner

Mit dem folgenden Skript erhält der Benutzer Angaben zum Hostnamen, den Fingerprints und wieviel Speicherplatz für Uploads bzgl. der Quota-Limits zur Verfügung steht. Für SFTP Clients, die keine Bannerdatei anzeigen, wird sie als welcome.txt in das incoming Verzeichnis kopiert.

/etc/cron.hourly/sftpbanner
#!/bin/sh
 
host="sub.domain.tld"
group="sftpuser"
fs="/mountpoint/"
bannerfile="/$fs/$group/banner"
quotacmd="repquota -g $fs"
belegt="$($quotacmd | grep $group | awk '{print $3}')"
soft="$($quotacmd | grep $group | awk '{print $4}')"
hard="$($quotacmd | grep $group | awk '{print $5}')"
grace="$($quotacmd | grep $group | awk '{print $6}')"
 
if [ "$belegt" -ge "$soft" ]; then
  space="$(echo 'scale=2; '$(($hard - $belegt))' / '1024'' | bc -l) MB verfügbar für $grace h."
else
  space="$(echo 'scale=2; '$(($hard - $belegt))' / '1024'' | bc -l) MB verfügbar."
fi
 
printf "Willkommen auf $host\n\nFingerprints:\n\
3072 $(ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub | cut -d ' ' -f 2) (RSA)\n 256 $(ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub | cut -d ' ' -f 2) (ED25519)\n\n Upload in incoming: $space" > $bannerfile
 
chown :$group $bannerfile && cp $bannerfile $fs/$group/alle/incoming/welcome.txt
 
exit 0

Verweise auf aktuelle Seite