SSH-Server

Siehe auch

Wichtige Eigenschaften von SSH:

  • Authentifizierung der Gegenstelle.

  • Die symmetrische Verschlüsselung der Datenübertragung mit sitzungsabhängigen Schlüsseln erschwert eine Entschlüsselung der Kommunikation durch Dritte massiv.

  • Manipulation der übertragenen Daten wird verhindert und ermöglicht Datenintegrität.

Änderungen an der Konfiguration des SSH-Servers sollten immer in einer zweiten SSH-Session getestet werden, um ein versehentliches Aussperren zu verhindern. In der ersten SSH-Session also Änderungen vornehmen und den SSH-Daemon neu starten, aber Test der Settings, Login, Logout usw. im zweiten Terminal vornehmen.

SSH-Server härten

Die folgenden Einstellungen lassen sich in der /etc/ssh/sshd_config vornehmen, um die Sicherheit je nach Anforderung weiter zu erhöhen oder den SSH-Server anzupassen. Nach Änderung der Einstellungen muss der SSH-Server neu gestartet werden, was auch bei laufender SSH-Session funktioniert.

AllowTcpForwarding no       # hindert Malware (aber auch alles andere) an Tunneling
ClientAliveCountMax 0       # keine KeepAlive-Messages senden
ClientAliveInterval 300     # 5 Minuten Idle-Timeout, danach Logout
HostbasedAuthentication no  # .rhosts und /etc/hosts.equiv-Dateien abschalten (SSHv2)
IgnoreRhosts yes            # .rhosts und .shosts-Dateien abschalten
LoginGraceTime 60           # Disconnect-Timeout nach erfolglosem Login
LogLevel VERBOSE            # Logging erhöhen (Pflicht für Fail2ban)
MaxAuthTries 3              # Anzahl der erfolglosen Login-Versuche, bis der Server die Verbindung trennt, von 6 auf 2 reduzieren
MaxSessions 4               # wie der Name schon sagt...
MaxStartups 10:30:60        # Maximale Anzahl von Concurrent Unauthorized Connections (start:rate%:full)
PasswordAuthentication no   # Anmeldung per Passwort abschalten
PermitEmptyPasswords no     # keine leeren Passwörter zulassen
PermitRootLogin no          # Login mit root-Rechten abschalten - Achtung, Ersatz-Benutzer sollte bereitstehen
PermitUserEnvironment no    # das Setzen von Environment-Optionen (Pfaden etc.) durch Benutzer verhindern
Port 56669                  # SSH-Port auf 56669 ändern (keine Sicherheit, aber reduziert die Anzahl der Brute-Force SSH-Loginversuche deutlich)
PubkeyAuthentication yes    # Anmeldung per Zertifikat zulassen
UsePAM yes                  # PAM nutzen
X11Forwarding no            # Tunneling von X11-Traffic per sshd-Forwarding verbieten

Wer den SSH-Port ändert, muss dies auch per SELinux erlauben:

yum -y install policycoreutils-python
dnf -y install policycoreutils-python-utils

semanage port --add --type ssh_port_t --proto tcp 56669

Änderungen an Verschlüsselungsoptionen wie Ciphers, MACs oder KexAlgorithms empfehlen wir nicht. Stattdessen sollten hier die systemweite Crypto-Policies konfiguriert werden, die auch vom SSH-Daemon verwendet werden.

Siehe auch

Benutzerzugriff auf SSH steuern

per TCP-Wrapper

Der Zugriff auf den SSH-Daemon lässt sich mittels /etc/hosts.allow und /etc/hosts.deny steuern, den sogenannten TCP Wrappers-Dateien. Der Servicename zur Steuerung lautet hier sshd. Soll der SSH-Service nur aus der Domäne linuxfabrik.ch erreichbar sein, trägt man in der /etc/hosts.deny ein:

sshd:ALL EXCEPT .linuxfabrik.ch

Die Datei /etc/hosts.allow wird zuerst gelesen. Wird kein passender Match gefunden, kommt die /etc/hosts.deny zur Anwendung. Wird wieder kein passender Match gefunden, wird der Zugriff gewährt. Die Dateien lassen sich auch einzeln entfernen.

Weil es einfacher und sehr effektiv ist, empfehlen wir, nur die Allow-Liste zu pflegen und allen anderen in der Deny-Liste den Zugriff zu entziehen.

per /etc/sshd/sshd_config
/etc/ssh/sshd_config
AllowUsers root linus@host
AllowGroups ...
DenyUsers ...
DenyGroups ...
per /etc/passwd

Um den Benutzer linus auszuschliessen, kann man diesem auf dem SSH-Host auch den Shell-Zugriff entziehen:

usermod --shell=/bin/false linus

Tipp

Es ist allgemein empfohlen, den SSH-Zugang für root abzuschalten (PermitRootLogin no). In so einem Fall erstellt man sich einen Standard-Benutzer, packt diesen in die wheel-Gruppe, loggt sich mit diesem über SSH ein, arbeitet mit sudo oder wechselt mit su - in die root-Shell.

SFTP

Es gibt des öfteren die Anforderung, einen möglichst sicheren SFTP-Server aufzusetzen. Die SFTP-Benutzer sollen dabei ausschliesslich SSH-Keys verwenden, keine interaktive Shell per SSH öffnen und ihr SFTP-Verzeichnis auch nicht verlassen dürfen. Alle anderen SSH-Logins sollen von diesen Einschränkungen nicht betroffen sein. Aus Admin-Sicht soll das ganze möglichst auch ohne Zusatzsoftware wie VSFTP oder andere auskommen, sondern mit dem SSH-Daemon umgesetzt werden.

Geht. Zunächst sicherstellen, dass eine Authentifizierung mit Public-Keys möglich ist:

/etc/ssh/sshd_config
PubkeyAuthentication yes

Eine Benutzergruppe namens sftpusers anlegen:

groupadd sftpusers

Die einzelnen SFTP-Benutzer der Benutzergruppe sftpusers hinzufügen:

usermod --groups sftpusers linus

Die SSH Public-Keys der einzelnen SFTP-Benutzer in ihren jeweiligen Home-Verzeichnissen ablegen. Anschliessend:

chown linus:linus /home/linus/.ssh/authorized_keys
chmod 0600 /home/linus/.ssh/authorized_keys

Fehlt nur noch die Konfiguration des SSH-Daemon. Folgende Einstellungen ans Ende der /etc/ssh/sshd_config packen und danach den SSH-Server neu starten:

/etc/ssh/sshd_config
Subsystem sftp internal-sftp

Match Group sftpusers
  AllowTcpForwarding no
  ChrootDirectory /home
  ForceCommand internal-sftp
  PasswordAuthentication no
  X11Forwarding no

systemctl restart sshd

Das war es schon. Der Client kann sich jetzt verbinden:

sftp linus@host
sftp> pwd
sftp> ls
sftp> cd linus

Die wichtigsten SFTP-Kommandos…

… direkt auf dem SFTP-Server:

  • pwd: Aktuelles Verzeichnis ausgeben.

  • mkdir: Verzeichnis anlegen.

  • cd: Verzeichnis wechseln.

  • get /path/to/local/file: Lokale Datei auf den entfernten Client kopieren.

  • put /path/to/remote/file: Entfernte Datei auf den SFTP-Server kopieren.

  • exit: Verbindung beenden.

… gegen den Client:

  • lpwd: „local pwd“, aktuell genutztes Client-Verzeichnis ausgeben.

  • lmkdir: Client-Verzeichnis anlegen.

  • lcd: Client-Verzeichnis wechseln.

Die „local“-Varianten bedeuten also „Ausführung auf dem Client“. Alle anderen Kommandos werden auf dem SFTP-Server ausgefuehrt, wie bei SSH auch.

Siehe auch man sftp.

Port-Foward-only User

Manchmal benötigt man einen User-Account, der nur Port-Forwarding verwenden darf, also keinen Shell-Zugriff haben soll. Dazu muss zuerst ein UNIX User erstellt werden. Der User

useradd portfwdonly

Und danach folgende SSH-Einstellungen gesetzt werden.

/etc/ssh/sshd_config
Match User portfwdonly
    # deny all
    AllowAgentForwarding no
    AllowStreamLocalForwarding no
    ForceCommand echo 'Port forwarding only account. Shell access is not allowed. Please use the "-N" option for ssh.'
    PermitTTY no
    PermitTunnel no
    PermitUserRC no
    X11Forwarding no

    # allow explicitly
    PermitOpen 127.0.0.1:3306 localhost:3306

Zu beachten ist, dass der User sowohl Port-Forwarding als auch Reverse Port-Forwarding mit den freigegebenen Ports verwenden darf.

Troubleshooting

Postponed publickey for root from 10.26.6.74 port 54321 ssh2

Die RSA-Keys stimmen, ssh-copy-id verwendet bzw. Dateiberechtigungen auf alle Keys stimmen, und SELinux motzt auch nicht? Dann liegt es daran, dass man das Schlüsselpaar auf der Client-Maschine unter einem anderen Benutzer (z.B. linus) erzeugt hat als für den Benutzer, mit dem man sich auf der Zielmaschine anmelden möchte (z.B. root). Hier hilft die explizite Angabe des zu kopierenden SSH-Keys per ssh-copy-id -i ~/.ssh/id_rsa.pub root@10.26.6.74.

Wie erhält man den SSH-Fingerprint zu einem SSH-Server?

Am einfachsten, man löscht den Eintrag in seiner ~/.ssh/known_hosts und verbindet sich neu.

Built on 2024-04-18