Secure Shell Ubuntu professionell absichern

Secure Shell, kurz SSH, ist das unumstößliche Fundament für den sicheren Fernzugriff auf Ubuntu-Systeme. In der Praxis ist es das A und O für eine professionelle Serveradministration, denn es sorgt für eine authentifizierte und verschlüsselte Kommunikation über potenziell unsichere Netzwerke. Jeder Befehl, jede Datei – alles ist geschützt. Für jedes Unternehmen ist ein sauber konfigurierter Secure Shell auf Ubuntu daher schlichtweg Pflicht.

Warum SSH das Rückgrat Ihrer Ubuntu-Server-Sicherheit ist

Früher, in den "wilden Westen"-Zeiten des Internets, verließ man sich auf Protokolle wie Telnet oder FTP. Ihre größte Schwäche war fatal: Passwörter und Daten wurden im Klartext übertragen. Jeder im selben Netzwerk konnte mit einfachsten Mitteln mitlauschen und Zugangsdaten abgreifen. Ein Albtraum aus heutiger Sicht.

Genau hier hat SSH angesetzt und die Spielregeln von Grund auf verändert. Es baut von der ersten Sekunde an einen verschlüsselten Tunnel auf. Jeder Tastendruck, jede Dateiübertragung, jede einzelne Anmeldung wird mit starken kryptografischen Verfahren abgeschirmt. Das macht SSH zur ersten und wichtigsten Verteidigungslinie gegen Lauschangriffe und Man-in-the-Middle-Attacken.

Die Evolution vom offenen Scheunentor zum digitalen Tresor

Der Wechsel von Telnet zu SSH war ein echter Meilenstein für die Netzwerksicherheit. Man kann es sich so vorstellen: Telnet war wie eine Postkarte, die jeder lesen konnte. SSH hingegen ist ein versiegelter, gepanzerter Kurierbrief. Diese Analogie macht klar, warum heute kein Administrator, der seinen Job ernst nimmt, mehr unverschlüsselte Protokolle für den Serverzugriff verwenden würde.

Die folgende Tabelle stellt die Sicherheit der Protokolle direkt gegenüber und zeigt, warum SSH heute der alternativlose Standard ist.

SSH im direkten Sicherheitsvergleich

Merkmal	SSH (Secure Shell)	Telnet	FTP (File Transfer Protocol)
Datenübertragung	Vollständig verschlüsselt (Befehle, Daten, Passwörter)	Unverschlüsselt (Klartext)	Unverschlüsselt (Klartext, auch Passwörter)
Authentifizierung	Starke Methoden (Public-Key, Passwörter, Kerberos)	Einfache Passwort-Authentifizierung	Einfache Passwort-Authentifizierung
Schutz vor Angriffen	Hoher Schutz vor Lauschangriffen & Man-in-the-Middle	Keinerlei Schutz	Keinerlei Schutz
Integritätsschutz	Ja, stellt sicher, dass Daten nicht manipuliert wurden	Nein	Nein
Typische Nutzung	Sicherer Shell-Zugriff, Tunneling, SCP/SFTP	Veralteter, unsicherer Terminalzugriff	Veralteter, unsicherer Dateitransfer

Die Gegenüberstellung macht es deutlich: In puncto Sicherheit gibt es zu SSH keine Alternative.

SSH wurde bereits 1995 entwickelt und hat sich seitdem als unverzichtbarer Standard etabliert. Das gilt besonders für Ubuntu-Server in deutschen Unternehmen. Aktuelle Zahlen belegen das eindrucksvoll: 87 % der deutschen KMU setzen auf SSH für ihre Serververbindungen. Da Ubuntu mit einem Marktanteil von 42 % unter den Linux-Distributionen führt, ist diese Kombination allgegenwärtig. Besonders in regulierten Branchen, die NIS-2-konform sein müssen, sind die Anforderungen hoch: Hier sichern 98 % ihre Verbindungen mit modernen ED25519-Schlüsseln. Diese basieren auf elliptischen Kurven, sind kryptografisch stärker und obendrein rund 30 % schneller als die älteren RSA-Schlüssel. Einen guten Einstieg in die technischen Hintergründe bietet das Wiki von UbuntuUsers.de.

Weit mehr als nur ein Login-Tool

Wer SSH nur als Ersatz für ein Login-Terminal sieht, unterschätzt seine wahre Stärke. Es ist das Schweizer Taschenmesser für sichere Operationen im Netzwerk.

• Sichere Dateiübertragungen: Protokolle wie SCP (Secure Copy Protocol) und SFTP (SSH File Transfer Protocol) laufen über SSH und machen den Dateitransfer sicher.
• Automatisierung und Konfigurationsmanagement: Tools wie Ansible oder Puppet nutzen SSH als Transportmittel, um Konfigurationen sicher auf hunderten oder tausenden Servern gleichzeitig auszurollen. Das ist die Basis für moderne DevOps-Prozesse.
• Port-Weiterleitung (Tunneling): SSH kann den Netzwerkverkehr anderer Anwendungen sicher durch einen verschlüsselten Kanal leiten. So lassen sich ältere, unsichere Dienste quasi "huckepack" absichern.
• Anbindung an Cloud-Plattformen: Der Zugriff auf virtuelle Maschinen in Umgebungen wie der IONOS Cloud läuft standardmäßig über SSH. Ohne geht in der Cloud so gut wie nichts.

In einer Unternehmensumgebung ist ein nicht gehärteter SSH-Zugang wie eine unverschlossene Eingangstür zum Serverraum. Es ist nicht die Frage, ob jemand versucht, hineinzukommen, sondern wann.

Für Unternehmen, die Regularien wie die NIS-2-Richtlinie oder die ISO 27001 erfüllen müssen, ist eine professionell konfigurierte und gehärtete SSH-Umgebung eine zentrale Anforderung. Diese Standards verlangen nachweisbare Sicherheitsmaßnahmen, eine lückenlose Protokollierung und die konsequente Durchsetzung starker Authentifizierungsmethoden. Ein sauberes SSH-Konzept ist also nicht nur eine technische Best Practice, sondern ein wesentlicher Baustein für die Compliance. Wie das konkret aussieht, erfahren Sie in unserem Leitfaden zur NIS-2 Umsetzung in Deutschland.

OpenSSH-Server auf Ubuntu installieren und die Weichen richtig stellen

Jede sichere SSH-Implementierung fußt auf einer sauberen Installation und einer von Anfang an durchdachten Konfiguration. Die Basis für einen Secure Shell auf Ubuntu zu legen, ist zum Glück kein Hexenwerk, aber die Details machen am Ende den Unterschied für die Sicherheit und Stabilität des Systems aus. Anders als die Server-Variante bringt Ubuntu Desktop von Haus aus keinen SSH-Server mit – also packen wir es an.

Die Installation selbst ist in wenigen Augenblicken erledigt. Mit dem richtigen Befehl landet das openssh-server-Paket direkt auf Ihrer Maschine.

sudo apt update
sudo apt install openssh-server -y

Dieser Befehl macht mehr als nur installieren: Er sorgt auch dafür, dass der SSH-Dienst künftig bei jedem Systemstart automatisch geladen wird. Darum müssen Sie sich also nicht mehr kümmern.

Läuft alles? Den SSH-Dienst überprüfen und verwalten

Nach der Installation ist es eine gute Praxis, direkt den Status des Dienstes zu prüfen. Das gibt einem sofort die Sicherheit, dass alles wie erwartet funktioniert. Ein kurzer Befehl reicht, um zu sehen, ob der SSH-Server auf Anfragen wartet.

sudo systemctl status ssh

Die Ausgabe sollte Ihnen ein active (running) entgegenlächeln. Falls nicht, keine Panik: Mit sudo systemctl start ssh starten Sie ihn manuell und mit sudo systemctl enable ssh sorgen Sie dafür, dass er auch zukünftig automatisch startet. Denken Sie dran: Jede Konfigurationsänderung, die wir später vornehmen, wird erst nach einem Neustart des Dienstes aktiv. Das erledigen Sie ganz einfach mit sudo systemctl restart ssh.

Die folgende Grafik zeigt wunderbar, warum wir uns überhaupt die Mühe machen und auf SSH setzen, statt auf alte Protokolle wie Telnet.

Man sieht auf einen Blick: SSH wurde von Grund auf für Sicherheit mit Verschlüsselung und Integritätsschutz entwickelt. Telnet hingegen schickt Daten ungeschützt durchs Netz – ein Sicherheitsrisiko, das heute absolut inakzeptabel ist.

Das Herzstück: Die Konfigurationsdatei sshd_config anpassen

Jetzt wird es interessant, denn die eigentliche Magie findet in der zentralen Konfigurationsdatei des SSH-Servers statt: /etc/ssh/sshd_config. Hier definieren Sie die Spielregeln für jeden, der anklopft. Bevor Sie auch nur eine einzige Zeile ändern, tun Sie sich selbst einen Gefallen und legen Sie eine Sicherungskopie an.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Dieser simple Schritt hat mich schon mehr als einmal davor bewahrt, mich versehentlich aus meinem eigenen System auszusperren. Wenn eine neue Konfiguration mal nicht funktioniert, können Sie einfach die Sicherung zurückspielen.

In dieser Datei steuern Sie praktisch alles – von erlaubten Authentifizierungsmethoden bis hin zu den spezifischen Benutzern, die sich überhaupt anmelden dürfen. Öffnen wir die Datei mal mit einem Texteditor wie nano, um die ersten wichtigen Anpassungen vorzunehmen.

sudo nano /etc/ssh/sshd_config

Ein Tipp aus der Praxis: Jede Zeile, die mit einem # beginnt, ist ein Kommentar und wird ignoriert. Um eine Einstellung zu aktivieren oder zu ändern, müssen Sie dieses # am Zeilenanfang entfernen und den Wert anpassen.

Für eine solide Grundsicherung konzentrieren wir uns zunächst auf ein paar wenige, aber extrem wirksame Parameter.

• Root-Login verbieten: Suchen Sie die Zeile PermitRootLogin. Stellen Sie sicher, dass der Wert auf prohibit-password oder, noch besser, direkt auf no gesetzt ist. Das ist eine der wichtigsten Härtungsmaßnahmen überhaupt, die wir später noch genauer besprechen.

• Den Standard-Port ändern: Als Nächstes werfen wir einen Blick auf den Port-Parameter. Standardmäßig lauscht SSH auf Port 22. Den Port zu ändern ist zwar keine Allzweckwaffe, aber es reduziert das Rauschen durch automatisierte Angriffe und Scans drastisch. Suchen Sie die Zeile #Port 22, entfernen Sie das # und ändern Sie die Portnummer auf einen Wert über 1024, zum Beispiel Port 2222.

Sobald Sie Ihre Änderungen vorgenommen haben, speichern Sie die Datei und schließen den Editor. Und ganz wichtig: Nicht vergessen, den SSH-Dienst neu zu starten, damit Ihre neue Konfiguration auch geladen wird.

sudo systemctl restart ssh

Mit diesen ersten Schritten haben Sie bereits eine robuste Basis für Ihren SSH-Zugang geschaffen. Sie haben den Dienst nicht nur installiert, sondern auch gelernt, wie man ihn steuert und mit ersten wichtigen Anpassungen von Anfang an ein gutes Stück sicherer macht.

Passwörter abschaffen: Der Umstieg auf schlüsselbasierte Authentifizierung

Ganz ehrlich: Passwörter sind oft das größte Einfallstor für Angreifer. Selbst wenn Sie sich eine komplexe Passphrase ausdenken, können hartnäckige Brute-Force-Angriffe diese knacken – automatisierte Skripte, die tausende Kombinationen pro Minute durchprobieren. Der Wechsel zur schlüsselbasierten Authentifizierung ist deshalb kein optionaler Luxus, sondern ein grundlegender Schritt, um Ihren Secure Shell auf Ubuntu wirklich professionell abzusichern.

Das Prinzip ist einfach: Statt etwas zu verwenden, das Sie wissen (ein Passwort), nutzen Sie etwas, das Sie besitzen – einen privaten, kryptografischen Schlüssel. Diese Methode ist um ein Vielfaches sicherer und macht Brute-Force-Angriffe praktisch unmöglich. Ein Angreifer müsste schon Ihren privaten Schlüssel in die Finger bekommen, was deutlich schwieriger ist als ein Passwort zu erraten.

Ein modernes Schlüsselpaar erzeugen

Als Erstes erzeugen wir ein Schlüsselpaar auf Ihrem lokalen Rechner, also Ihrem Arbeits-PC oder Laptop, nicht auf dem Server selbst. Dieses Paar besteht aus einem privaten Schlüssel, den nur Sie besitzen und geheim halten, und einem öffentlichen Schlüssel, den Sie auf dem Server hinterlegen.

Aus der Praxis empfehle ich den modernen und performanten Algorithmus ED25519. Er bietet Top-Sicherheit bei kürzeren Schlüsseln, was die Authentifizierung spürbar beschleunigt. Öffnen Sie einfach ein Terminal auf Ihrem Client und führen Sie diesen Befehl aus:

ssh-keygen -t ed25519 -C "ihr_kommentar_hier"

• -t ed25519: Legt den Algorithmus fest.
• -C "…": Fügt einen optionalen Kommentar hinzu. Sehr praktisch, um den Schlüssel später zuzuordnen – zum Beispiel mit Ihrer E-Mail-Adresse oder einer Gerätekennung wie „MacBook Pro Max“.

Sie werden nun nach einem Speicherort und einer Passphrase gefragt. Die Passphrase ist quasi ein Master-Passwort für Ihren privaten Schlüssel und sollte unbedingt vergeben werden. Sie verschlüsselt Ihren Schlüssel zusätzlich.

Ein SSH-Schlüssel ohne Passphrase ist wie ein Hausschlüssel, den man unter die Fußmatte legt. Sicherer als keine Tür, aber bei Weitem nicht optimal. Die Passphrase sorgt dafür, dass selbst bei einem Diebstahl Ihres privaten Schlüssels dieser nicht sofort verwendet werden kann.

Danach finden Sie im Verzeichnis ~/.ssh/ auf Ihrem Rechner zwei neue Dateien: id_ed25519 (der geheime, private Schlüssel) und id_ed25519.pub (der öffentliche Teil).

Den öffentlichen Schlüssel sicher auf den Server bringen

Jetzt muss Ihr öffentlicher Schlüssel auf den Ubuntu-Server. Nur so kann der Server Sie später wiedererkennen. OpenSSH liefert dafür ein geniales kleines Werkzeug namens ssh-copy-id, das den Prozess automatisiert und dabei auch gleich die korrekten Dateiberechtigungen setzt – eine häufige Fehlerquelle bei der manuellen Einrichtung.

Führen Sie auf Ihrem lokalen Rechner Folgendes aus. Ersetzen Sie dabei benutzer durch Ihren Nutzernamen und server_adresse durch die IP oder den Hostnamen Ihres Servers:

ssh-copy-id benutzer@server_adresse

Sie werden ein letztes Mal nach Ihrem Passwort gefragt, um die Verbindung für den Kopiervorgang herzustellen. Im Hintergrund packt das Tool den Inhalt Ihrer id_ed25519.pub in die Datei ~/.ssh/authorized_keys auf dem Server und kümmert sich um die Berechtigungen. Wenn Sie tiefer in die Materie einsteigen wollen: Wir haben einen umfassenden Leitfaden, wie Sie einen SSH-Schlüssel erstellen und verwalten.

Passwort-Logins endgültig den Riegel vorschieben

Der Schlüssel ist übertragen, der Login per Key funktioniert – jetzt kommt der wichtigste Schritt. Wir schalten die passwortbasierte Anmeldung komplett ab. Ab diesem Moment wird Ihr Server wirklich dichtgemacht.

Verbinden Sie sich erneut mit Ihrem Server (diesmal sollte keine Passwortabfrage mehr kommen) und öffnen Sie die Konfigurationsdatei sshd_config als root:

sudo nano /etc/ssh/sshd_config

Suchen Sie die folgenden Zeilen. Entfernen Sie das # am Anfang, falls es da ist, und passen Sie die Werte an:

• PasswordAuthentication no
• PubkeyAuthentication yes
• ChallengeResponseAuthentication no

Die erste Zeile ist die entscheidende, sie verbietet alle interaktiven Passwort-Logins. Die zweite stellt sicher, dass die Schlüssel-Authentifizierung explizit erlaubt bleibt. Die dritte schaltet weitere passwortähnliche Abfragen ab.

Speichern Sie die Datei und starten Sie den SSH-Dienst neu, damit die Änderungen greifen:

sudo systemctl restart ssh

Ganz wichtiger Tipp aus der Praxis: Öffnen Sie ein neues Terminalfenster und testen Sie den Login, bevor Sie Ihre bestehende Verbindung schließen. So stellen Sie sicher, dass Sie sich nicht versehentlich ausgesperrt haben.

Diese Konfiguration ist mehr als nur eine gute Angewohnheit – sie hat messbare Auswirkungen. Eine Studie ergab, dass 71 % der KMU OpenSSH für ihre Cloud-Verbindungen nutzen. Seitdem die Public-Key-Authentifizierung konsequenter umgesetzt wird, sank die Rate erfolgreicher Passwort-Angriffe um 68 %. Angesichts zehntausender SSH-Angriffe monatlich allein in Deutschland sinken erfolgreiche Einbrüche durch diese sshd_config-Anpassung um über 80 %.

Den SSH-Server bombenfest machen: Härtung für Profis

Okay, die passwortbasierte Anmeldung ist Geschichte – ein wichtiger erster Schritt. Aber jetzt geht es ans Eingemachte. Die Standardkonfiguration von OpenSSH ist ein guter Startpunkt, aber für eine professionelle Umgebung, in der Compliance und Sicherheit an erster Stelle stehen, müssen wir deutlich nachlegen. Unser Ziel ist es, die Angriffsfläche des Servers systematisch und gezielt zu verkleinern.

Jede Standardeinstellung, die wir belassen, und jeder unnötige Zugang ist eine potenzielle Einladung für Angreifer. Indem wir diese Türen proaktiv schließen, machen wir es Angreifern nicht nur schwerer, sondern fast unmöglich, überhaupt einen Fuß auf den Server zu bekommen.

Root-Login? Ein absolutes No-Go

In der Linux-Welt gibt es eine goldene Regel: Melde dich niemals direkt als root an. Das gilt umso mehr für den Fernzugriff über SSH. Ein direkter Root-Login hebelt wichtige Sicherheitsmechanismen wie die sudo-Protokollierung aus und ist das primäre Ziel automatisierter Angriffe.

Dem schieben wir jetzt einen endgültigen Riegel vor. Öffnen Sie die SSH-Konfigurationsdatei, am besten mit Ihrem bevorzugten Editor:

sudo nano /etc/ssh/sshd_config

Suchen Sie nach der Direktive PermitRootLogin. Selbst wenn hier schon prohibit-password steht, gehen wir einen Schritt weiter und verbieten den Login komplett.

PermitRootLogin no

Diese kleine Änderung hat eine massive Auswirkung. Sie zwingt jeden Administrator, sich zuerst mit seinem persönlichen, unprivilegierten Konto anzumelden. Erst dann können bei Bedarf über sudo erweiterte Rechte erlangt werden. Der entscheidende Vorteil: Jeder kritische Befehl wird sauber protokolliert und ist einer Person zuordenbar.

Raus aus der Schusslinie: Den Standard-Port ändern

Weltweit lauscht jeder SSH-Server standardmäßig auf dem TCP-Port 22. Das wissen natürlich auch die Angreifer. Unzählige Bots scannen das Internet pausenlos nach offenen Ports mit der Nummer 22, um Brute-Force-Angriffe zu starten. Dank unserer Key-Authentifizierung würden diese Versuche zwar scheitern, aber sie erzeugen unnötigen Lärm in den Logfiles und verbrauchen wertvolle Server-Ressourcen.

Nehmen wir den Angriffs-Bots also einfach ihre Zielscheibe.

1. Finden Sie in der sshd_config die auskommentierte Zeile #Port 22.
2. Entfernen Sie die Raute (#) am Anfang, um die Direktive zu aktivieren.
3. Ändern Sie die Portnummer auf einen freien, nicht standardisierten Wert über 1024. Nehmen wir als Beispiel Port 2288.

Tipp aus der Praxis: Bevor Sie jetzt den SSH-Dienst neu starten, müssen Sie den neuen Port in der Firewall freigeben. Wer das vergisst, sperrt sich unweigerlich selbst aus. Wie das mit UFW geht, zeige ich Ihnen gleich im nächsten Schritt.

Zugriffskontrolle: Nur für geladene Gäste

In einem Unternehmen sollte der SSH-Zugang streng reglementiert sein. Hier gilt das „Principle of Least Privilege“ – jeder bekommt nur die Rechte, die er für seine Arbeit unbedingt braucht. Die sshd_config gibt uns dafür die passenden Werkzeuge an die Hand.

• AllowUsers: Hiermit definieren Sie eine Positivliste von Benutzernamen, die sich per SSH anmelden dürfen. Alle anderen werden blockiert, selbst wenn sie einen gültigen Schlüssel besitzen.
  AllowUsers adminuser supportuser

• AllowGroups: Noch besser und oft einfacher zu verwalten ist die Beschränkung auf bestimmte Gruppen. Das skaliert wunderbar, wenn neue Teammitglieder dazukommen.
  AllowGroups ssh-admins devops

Fügen Sie eine dieser beiden Direktiven einfach am Ende Ihrer sshd_config hinzu. Für die meisten Teams ist AllowGroups die flexiblere und zukunftssichere Wahl.

Die Firewall als Türsteher: UFW gezielt einsetzen

Eine Firewall ist Ihre erste und wichtigste Verteidigungslinie. Ubuntu bringt mit der Uncomplicated Firewall (UFW) ein erfreulich einfaches, aber mächtiges Tool mit. Wir nutzen es nicht nur, um unseren neuen SSH-Port freizuschalten, sondern können den Zugriff bei Bedarf sogar auf feste IP-Adressen einschränken.

Überprüfen Sie zuerst den Status von UFW:

sudo ufw status

Sollte die Firewall inaktiv sein, aktivieren Sie sie. Aber Vorsicht! Der wichtigste Schritt zuerst: Erlauben Sie den SSH-Zugriff, bevor Sie die Firewall scharfschalten, sonst ist der Server für Sie nicht mehr erreichbar.

sudo ufw allow 2288/tcp
sudo ufw enable

Damit ist der Zugriff auf Ihren neuen SSH-Port 2288 von überall aus möglich. Um die Sicherheit weiter zu erhöhen, können Sie den Zugang auf eine vertrauenswürdige IP-Adresse (z. B. Ihre Firmen-IP) beschränken:

sudo ufw allow from 203.0.113.100 to any port 2288 proto tcp

Mit dieser Regel ist ein SSH-Login nur noch von der IP-Adresse 203.0.113.100 aus gestattet.

Nach all diesen Änderungen an der Konfiguration ist es Zeit, Bilanz zu ziehen. Die folgende Tabelle fasst die wichtigsten Parameter für eine gehärtete sshd_config noch einmal zusammen.

Wichtige Direktiven zur SSH-Härtung in der sshd_config

Eine Übersicht der wichtigsten Parameter in /etc/ssh/sshd_config, deren empfohlene Werte und der daraus resultierende Sicherheitsgewinn.

Direktive	Standardwert	Empfohlener Wert	Sicherheitsgewinn
PermitRootLogin	prohibit-password	no	Verhindert direkten Root-Login vollständig und erzwingt die nachvollziehbare sudo-Nutzung.
Port	22	Ein Wert > 1024 (z. B. 2288)	Reduziert die Sichtbarkeit für automatisierte Scans und senkt das "Grundrauschen" an Angriffen.
PasswordAuthentication	yes	no	Deaktiviert Passwörter und erzwingt die kryptografisch weit überlegene Schlüssel-Authentifizierung.
AllowUsers / AllowGroups	Nicht gesetzt	Eine Liste von Benutzern/Gruppen	Limitiert den Zugriff auf einen klar definierten, autorisierten Personenkreis (Least Privilege).
LogLevel	INFO	VERBOSE	Erhöht die Detailtiefe in den Logdateien, was bei der Analyse von Vorfällen entscheidend ist.

Diese Direktiven sind das Fundament einer sicheren SSH-Konfiguration.

Wenn Sie alle Anpassungen in der /etc/ssh/sshd_config vorgenommen haben, speichern Sie die Datei. Führen Sie danach unbedingt einen Syntax-Check durch:

sudo sshd -t

Erscheint hier keine Fehlermeldung, ist alles in Ordnung. Jetzt können Sie den SSH-Dienst neu starten, um Ihre gehärtete Konfiguration zu aktivieren:

sudo systemctl restart ssh

Herzlichen Glückwunsch! Mit diesen Maßnahmen haben Sie die Sicherheit Ihres Secure Shell auf Ubuntu auf ein professionelles Niveau gehoben und die Angriffsfläche drastisch reduziert.

SSH-Zugriffe überwachen und verdächtige Aktivitäten protokollieren

Eine gehärtete Konfiguration ist ein starker Schutzwall, aber echte Sicherheit braucht mehr als nur eine gute Abwehr – sie braucht Wachsamkeit. Sie müssen jederzeit wissen, was auf Ihren Systemen passiert. Ein lückenloses Monitoring von SSH-Zugriffen ist deshalb kein optionales Extra, sondern ein zentraler Pfeiler jeder professionellen Sicherheitsstrategie und eine klare Anforderung für Compliance-Standards wie NIS-2.

In diesem Abschnitt widmen wir uns der Protokollierung und der automatisierten Abwehr von verdächtigen Aktivitäten. So stellen wir sicher, dass Ihr Secure Shell auf Ubuntu nicht nur sicher konfiguriert ist, sondern Ihnen auch genau verrät, wer anklopft.

Mehr Details bitte: Das Logging-Level anpassen

Standardmäßig schreibt der SSH-Dienst auf Ubuntu seine Ereignisse in die Datei /var/log/auth.log. Die Voreinstellung (LogLevel INFO) ist aber für eine ernsthafte Analyse im Ernstfall oft zu oberflächlich. Um wirklich tiefe Einblicke zu bekommen, schrauben wir die Detailtiefe hoch.

Öffnen Sie dazu einfach noch einmal die SSH-Konfigurationsdatei:

sudo nano /etc/ssh/sshd_config

Suchen Sie die auskommentierte Zeile #LogLevel INFO und ändern Sie diese auf LogLevel VERBOSE. Wichtig ist, dass Sie die Raute (#) am Anfang entfernen, um die Direktive auch wirklich zu aktivieren.

LogLevel VERBOSE

Diese kleine Änderung hat eine große Wirkung: Der SSH-Dienst protokolliert jetzt deutlich mehr Informationen. Dazu gehören Details zum verwendeten Schlüssel bei einem erfolgreichen Login, dessen Fingerprint und zusätzliche Daten bei fehlgeschlagenen Versuchen. Speichern Sie die Datei, starten Sie den Dienst mit sudo systemctl restart ssh neu, und Ihre Logs werden sofort aussagekräftiger.

Aus der Praxis: Ein höherer Log-Level ist entscheidend für die Forensik. Ohne detaillierte Protokolle ist es bei einem Sicherheitsvorfall fast unmöglich, die Schritte eines Angreifers nachzuvollziehen oder festzustellen, wie weit er ins System vorgedrungen ist.

Die Protokolle im Blick: Fehlgeschlagene Logins aufspüren

Mit dem aktivierten VERBOSE-Logging können wir nun gezielt nach verdächtigen Mustern suchen. Die erste Anlaufstelle ist immer die Datei /var/log/auth.log. Der Klassiker unter den Angriffen auf SSH-Server ist der Brute-Force-Versuch, bei dem ein Angreifer in rasender Geschwindigkeit unzählige Benutzernamen und Passwörter ausprobiert.

Für eine schnelle manuelle Prüfung können Sie diese fehlgeschlagenen Versuche einfach mit grep herausfiltern:

grep "Failed password" /var/log/auth.log

Sehen Sie hier eine Flut von Einträgen von derselben IP-Adresse, haben Sie es mit ziemlicher Sicherheit mit einem automatisierten Angriff zu tun. Das ist gut für eine Momentaufnahme, aber im Alltag brauchen wir eine Lösung, die das automatisch und rund um die Uhr für uns erledigt.

Fail2Ban: Der automatisierte Türsteher

Hier kommt Fail2Ban ins Spiel – ein Tool, das meiner Meinung nach auf keinem Server fehlen darf. Fail2Ban ist ein cleveres Intrusion-Prevention-Framework, das Logdateien in Echtzeit überwacht. Es erkennt verdächtige Muster, wie eben jene wiederholten fehlgeschlagenen Anmeldeversuche, und sperrt die IP-Adresse des Angreifers kurzerhand über die Firewall (UFW).

Die Installation ist schnell erledigt:

sudo apt update && sudo apt install fail2ban -y

Nach der Installation ist Fail2Ban sofort aktiv und hat den SSH-Dienst bereits im Visier. Die Konfiguration läuft über sogenannte „Jails“. Um die Standardeinstellungen sauber zu überschreiben, ohne dass sie beim nächsten Update verloren gehen, erstellen wir eine lokale Kopie:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Öffnen Sie nun die neue Datei jail.local mit einem Editor Ihrer Wahl und suchen Sie den Abschnitt [sshd]. Hier passen Sie die Regeln für Ihren Server an:

[sshd]
enabled = true
port = 2288
maxretry = 3
findtime = 300
bantime = 3600

• enabled: Stellt sicher, dass der SSH-Schutz aktiv ist (true).
• port: Ganz wichtig: Passen Sie diesen Wert an Ihren geänderten SSH-Port an, in unserem Beispiel also 2288.
• maxretry: Die Anzahl der erlaubten Fehlversuche. Drei ist ein guter, strenger Wert.
• findtime: Der Zeitraum (in Sekunden), in dem die maxretry-Versuche erfolgen müssen, um eine Sperre auszulösen. 300 Sekunden (5 Minuten) ist hier ein gängiger Wert.
• bantime: Die Dauer der Sperre in Sekunden. 3600 Sekunden (eine Stunde) ist ein guter Start.

Nachdem Sie die Datei gespeichert haben, starten Sie Fail2Ban neu, damit die neuen Regeln geladen werden:

sudo systemctl restart fail2ban

Das war's schon! Ab sofort überwacht Fail2Ban Ihre auth.log und sperrt automatisch jeden, der innerhalb von fünf Minuten dreimal vergeblich versucht, sich anzumelden. Eine simple, aber extrem wirksame Methode, um Brute-Force-Angriffe im Keim zu ersticken.

Die Bedeutung einer lückenlosen Überwachung wird oft unterschätzt. Laut einem BSI-Bericht werden über 60 % der Sicherheitsvorfälle durch unbemerkte, nicht protokollierte Zugriffe erst ermöglicht. Die Konfiguration mit LogLevel VERBOSE ist hier der erste Schritt. Der Einsatz spezialisierter Tools wie Auditd kann die Erkennungsrate verdächtiger Aktivitäten sogar um bis zu 45 % steigern. In Kombination mit SSH-Keys, die das Brute-Force-Risiko bereits um über 90 % reduzieren, entsteht ein robustes Verteidigungssystem.

Für eine noch tiefere Analyse des Systemverhaltens und der Endpunktsicherheit empfiehlt es sich, über spezialisierte Lösungen nachzudenken. Erfahren Sie mehr über die Vorteile von Endpoint Detection and Response (EDR) in unserem weiterführenden Artikel.

Typische Fragen aus der Praxis zur SSH-Härtung auf Ubuntu

Selbst nach einer sorgfältigen Konfiguration bleiben oft ein paar Fragen offen. In der Praxis tauchen immer wieder dieselben Überlegungen auf, wenn es darum geht, den Secure Shell auf Ubuntu wirklich wasserdicht zu machen. Hier klären wir die gängigsten Punkte, damit Sie Ihre Serverumgebung noch robuster aufstellen und typische Fallstricke elegant umschiffen können.

Macht es wirklich Sinn, den SSH-Port zu ändern?

Kurz und knapp: Ja, aber nicht als alleinige Maßnahme. Es ist ein wichtiger Baustein in einer mehrschichtigen Verteidigungsstrategie. Natürlich ist ein geänderter Port kein unüberwindbares Hindernis – ein Angreifer mit genug Zeit und Willen könnte das gesamte Netzwerk nach offenen Ports scannen.

Der eigentliche Clou liegt woanders: Sie entziehen sich dem permanenten „Grundrauschen“ des Internets. Unzählige automatisierte Bots scannen rund um die Uhr gezielt den Standard-Port 22. Wenn Sie Ihren SSH-Dienst auf einen unüblichen Port wie 2288 legen, laufen diese plumpen Angriffsversuche einfach ins Leere.

Ein geänderter Port ist wie eine unscheinbare, unbeschriftete Tür in einer langen Gasse. Die meisten Einbrecher suchen nach der großen, offensichtlichen Eingangstür. Nur wer es gezielt auf Sie abgesehen hat, wird auch die versteckten Zugänge suchen.

Richtig wirkungsvoll wird diese Taktik erst im Zusammenspiel mit Fail2Ban und einer restriktiven Firewall (UFW). Ihre Logdateien bleiben dadurch deutlich sauberer, was die Erkennung echter, gezielter Angriffe ungemein erleichtert. Ganz nebenbei spart Ihr Server auch noch Ressourcen, weil er sich nicht ständig gegen sinnlose Brute-Force-Attacken wehren muss.

Wie manage ich SSH-Schlüssel für ein ganzes Team, ohne den Verstand zu verlieren?

Sobald mehr als eine Handvoll Leute oder Systeme Zugriff brauchen, wird die Verwaltung von SSH-Schlüsseln schnell zum Albtraum. Manuell Schlüssel auf Dutzende Server zu kopieren, ist nicht nur mühsam, sondern auch extrem fehleranfällig.

Für Unternehmen haben sich daher ein paar Strategien bewährt:

• Zentralisierte authorized_keys: Halten Sie eine Master-Version der authorized_keys-Datei in einem sicheren, versionierten Repository (z. B. Git). Das schafft Transparenz und Nachvollziehbarkeit.
• Konfigurationsmanagement-Tools: Werkzeuge wie Ansible, Puppet oder Chef sind Gold wert, um Schlüssel automatisch und konsistent auf Ihrer gesamten Serverflotte zu verteilen. Ein git push ins Repository kann so einen automatisierten Rollout-Prozess anstoßen.
• Wasserdichter Offboarding-Prozess: Definieren Sie glasklar, was passiert, wenn jemand das Team verlässt. Der öffentliche Schlüssel eines ehemaligen Mitarbeiters muss sofort von allen Systemen entfernt werden. Automatisierung ist hier der einzige Weg, um das zuverlässig sicherzustellen.

Was ist der Unterschied zwischen RSA-, ECDSA- und ED25519-Schlüsseln?

Die Wahl des Algorithmus hat direkte Auswirkungen auf Sicherheit und Performance. Hier ist der schnelle Überblick aus der Praxis:

• RSA: Der Klassiker und lange Zeit der De-facto-Standard. RSA ist sicher, braucht für ein hohes Sicherheitsniveau aber recht lange Schlüssel (z. B. 4096 Bit), was die Authentifizierung einen Tick verlangsamen kann.
• ECDSA: Basiert auf elliptischen Kurven und bietet bei deutlich kürzeren Schlüsseln eine vergleichbare Sicherheit wie RSA. Eine gute, moderne Alternative.
• ED25519: Der modernste und heute klar empfohlene Algorithmus. Er nutzt eine spezielle elliptische Kurve (Curve25519), die als besonders sicher und resistent gegen bestimmte Angriffsarten gilt. Oben drauf ist er auch noch deutlich performanter als RSA und ECDSA, was sich bei vielen Verbindungen durchaus bemerkbar macht.

Unsere klare Empfehlung: Wenn Sie heute neue Schlüssel erstellen, nehmen Sie ED25519. Es bietet die beste Kombination aus Sicherheit, Leistung und moderner Kryptografie.

Kann ich SSH-Zugriffe auf bestimmte Befehle beschränken?

Ja, unbedingt! Das ist eine extrem mächtige Funktion, um das Prinzip der minimalen Rechtevergabe (Least Privilege) in die Tat umzusetzen. Stellen Sie sich vor, ein Automatisierungsserver muss ein Backup-Skript auf einem anderen System aufrufen. Dieser Server braucht dafür keine vollwertige Shell – das wäre ein unnötiges Sicherheitsrisiko.

Sie können den Zugriff direkt in der authorized_keys-Datei auf dem Zielserver einschränken. Fügen Sie dazu einfach die Option command="..." vor dem eigentlichen Schlüssel ein:

command="/usr/local/bin/backup-script.sh" ssh-ed25519 AAAA... backup-server@example.com

Meldet sich nun jemand mit dem zugehörigen privaten Schlüssel an, wird keine interaktive Shell gestartet. Stattdessen führt der SSH-Server ausschließlich den Befehl /usr/local/bin/backup-script.sh aus und beendet die Verbindung danach sofort. Das ist eine saubere und sichere Methode, um automatisierten Prozessen genau die Rechte zu geben, die sie brauchen – und keinen Deut mehr.

---

Benötigen Sie professionelle Unterstützung bei der Absicherung Ihrer IT-Infrastruktur oder bei der Umsetzung von NIS-2- und ISO-27001-Anforderungen? Die Deeken.Technology GmbH ist Ihr zertifizierter Partner für umfassende IT-Sicherheit und Cloud-Lösungen. Kontaktieren Sie uns noch heute, um Ihre Systeme zukunftssicher zu machen: https://deeken-group.com.