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.

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

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

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.

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.

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.

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.

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

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

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

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.

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

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

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

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
}

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

• stribika
  Secure Secure Shell
• Andris Raugulis
  ssh-audit
• Max Horn
  SSH implementation comparison
• Piratenpartei Sachsen-Anhalt
  Tutorial: Mit FileZilla per SFTP und Public Key connecten
• Universität Bremen
  WinSCP: Public Key Authentication konfigurieren
• Linux Audit
  OpenSSH security and hardening
• Pinboard-Links zum Thema SSH