SSH für centron Cloud Server einrichten
SSH (Secure Shell) ermöglicht dir die Verbindung zu einem entfernten Cloud-Server – entweder per Kommandozeile oder mit einem GUI-Client. SSH ist ein Netzwerkprotokoll, das auch von Tools wie scp und rsync genutzt wird. Mit scp werden Dateien sicher zwischen Hosts im Netzwerk kopiert. Rsync setzt ebenfalls auf SSH, um Dateien und Verzeichnisse zwischen einem lokalen System und einem Remote-Host zu übertragen. Dabei werden nur die Daten synchronisiert, die sich seit dem letzten Lauf geändert haben. Dadurch eignet sich rsync besonders gut, um komplette Projekte effizient und ressourcenschonend zu sichern.
Dieses Tutorial zeigt, wie du SSH auf einem lokalen Host sowie auf einem entfernten centron Host konfigurierst. Außerdem wird erklärt, wie du über die centron Web Console versehentliche Aussperrungen vermeidest. Behandelt werden unter anderem folgende Punkte:
- Den lokalen SSH-Client für eine Anmeldung per Schlüssel vorbereiten
- Root-Zugriff einschränken und Passwort-Logins deaktivieren
- Einen alternativen SSH-Port verwenden, um unerlaubte Versuche zu reduzieren
- fail2ban installieren und einrichten, um Brute-Force-Angriffe abzuwehren
- SSH Agent Forwarding für Nicht-Root-Benutzer aktivieren
- SSH-Tunneling nutzen
- Dateien mit scp übertragen
- Backups mit rsync erstellen
Dieses Tutorial verwendet den OpenSSH-Kommandozeilenclient ssh, der auf den meisten Unix-ähnlichen Systemen wie macOS und Linux verfügbar ist. Unter Windows 10/11 kannst du das Windows Subsystem for Linux nutzen, um den OpenSSH-Client zu verwenden.
Für die Beispiele in diesem Tutorial lautet der FQDN des centron Servers ap1.example.com. Der lokale macOS-Host heißt imac1. Der lokale Debian-Host heißt db1.
Hinweis: Die SSH-Befehle funktionieren in macOS- und Debian-Terminal-Sitzungen gleich, sofern nicht ausdrücklich anders erwähnt.
Voraussetzungen
Du benötigst ein centron Konto. In diesem Tutorial werden macOS und Debian Linux als Beispiele genutzt, aber die Schritte funktionieren in den meisten Linux-Umgebungen mit OpenSSH identisch. Zuerst erstellst du auf deinem lokalen Host ein privates/öffentliches SSH-Schlüsselpaar und hinterlegst den öffentlichen Schlüssel in deinem centron Konto. Danach kannst du den Schlüssel beim Deployen eines centron Servers automatisch installieren lassen. Falls der Server schon existiert, kannst du den Schlüssel später hinzufügen.
Du solltest bereits vertraut sein mit:
- Dem Installieren von Kommandozeilen-Tools auf macOS über Homebrew (
brew) oder auf Linux überapt. - Der Arbeit mit einer Firewall (zum Beispiel UFW), um Ports zu öffnen oder zu schließen.
- Der Nutzung der Kommandozeile.
Hinweis: Befehle, die mit $ beginnen, werden als normaler (nicht privilegierter) Benutzer ausgeführt. Befehle, die mit # beginnen, werden als Root ausgeführt.
Lokalen SSH-Client konfigurieren
1. SSH-Schlüsselpaar erzeugen
Erstelle ein modernes SSH-Schlüsselpaar mit folgendem Befehl:
george@imac1:~
$ ssh-keygen -t ed25519 -C "hostname"
Der Kommentar mit -C ist häufig eine E-Mail-Adresse, kann aber frei gewählt werden. Wenn du hier deinen Hostnamen einträgst, kannst du später besser zuordnen, welcher Schlüssel zu welchem System gehört. Speichere für jeden Host das Schlüsselpaar unter einem eigenen Dateinamen und vergib beim Erstellen eine Passphrase. Für eine lange, sichere Passphrase kannst du pwgen verwenden:
george@imac1:~
$ pwgen -s 64 1
H7zhGFO6DeMAf1gvMCFOaWcbmlJrcE9VXI1Oj81zlBGN2GFpFhhxw8hT4qyyU4jl
Hinweis: Installiere pwgen über brew oder apt.
Vollständiges Beispiel:
george@imac1:~
$ ssh-keygen -t ed25519 -C "ap1"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/george/.ssh/id_ed25519): /Users/george/.ssh/ap1_ed25519
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/george/.ssh/ap1_ed25519.
Your public key has been saved in /Users/george/.ssh/ap1_ed25519.pub.
The key fingerprint is:
SHA256:RHQ9bSUV9TwKahLLr0crwYZvMVIcxJiFbSGO+PDKzr8 ap1
The key's randomart image is:
+--[ED25519 256]--+
| .O=+ .. ..+*|
| . o+.* . o oo.|
| o . .o.o . o .o|
| + .+o . . . .|
| o ++So . |
|. . o *+. |
| o + =.. |
|o +.o |
| o.E. ..o |
+----[SHA256]-----+
Wenn du zur Passphrase aufgefordert wirst, füge sie ein – sie wird beim Tippen nicht angezeigt. Die Dateiangabe ist optional; standardmäßig wird ~/.ssh/id_ed25519 genutzt. Erstelle für jeden Host ein eigenes Schlüsselpaar.
2. Öffentlichen Schlüssel hinzufügen
Melde dich in deinem centron Konto an. Öffne unter deinem Kontonamen den Bereich SSH Keys und klicke auf Add SSH Key. Vergib einen Namen und füge deinen öffentlichen Schlüssel (zum Beispiel ~/.ssh/ap1_ed25519.pub) in das Feld ein. Bestätige anschließend mit Add SSH Key.
Deploye einen neuen Debian-11-Server. Im Abschnitt SSH Keys wählst du deinen Schlüssel aus. centron installiert ihn automatisch für den Root-Benutzer unter ~/.ssh/authorized_keys.
Hinweis: Nach dem Start des Servers kann es ein paar Minuten dauern, bis Cloud-init abgeschlossen ist. Öffne das Fenster View Console und warte auf die Meldung, dass Cloud-init fertig ist.
Falls dein Server bereits existiert, kannst du im Tab Settings die Option Reinstall SSH Keys wählen, um den Schlüssel erneut zu installieren.
Hinweis: Dabei werden alle Daten gelöscht und das Betriebssystem neu installiert.
Alternativ kannst du ssh-copy-id nutzen, um deinen öffentlichen Schlüssel auf einem bestehenden Server zu hinterlegen. Der Schlüssel wird dabei in ~/.ssh/authorized_keys auf deinem centron Host installiert. Stelle sicher, dass ap1.example.com in deinen DNS-Einträgen oder in /etc/hosts auf deinem lokalen Rechner vorhanden ist. Gib das Root-Passwort ein, wenn du dazu aufgefordert wirst:
george@imac1:~
$ ssh-copy-id -i ~/.ssh/ap1_ed25519 root@ap1.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/george/.ssh/ap1_ed25519.pub"
The authenticity of host 'ap1.example.com (66.42.117.31)' can't be established.
ECDSA key fingerprint is SHA256:fqAViH4GleZO7oMYkr+Qu92kewU7xzZeeUSmfPDMEOA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@ap1.example.com's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'root@ap1.example.com'"
and check to make sure that only the key(s) you wanted were added.
Hinweis: Die Meldung zur Host-Authentizität erscheint beim ersten Verbindungsaufbau. Antworte mit yes, um fortzufahren. Der Beispiel-Login funktioniert nur dann ohne -i, wenn du den Standard-Identitätsnamen ~/.ssh/id_ed25519 verwendest. Wie du einen nicht-standardmäßigen Schlüssel testest, zeigt der nächste Abschnitt. Wenn du dich früher bereits per SSH verbunden hast und den Server danach neu installiert hast, kann folgende Warnung erscheinen:
$ ssh-copy-id -i ~/.ssh/ap1_ed25519 root@ap1.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/george/.ssh/ap1_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
o o o
Just delete the previous ap1 entry in ~/.ssh/known_hosts and run the command again.
3. Öffentlichen Schlüssel prüfen
Führe den folgenden Befehl aus, um sicherzustellen, dass der Login per SSH-Key funktioniert:
george@imac1:~
$ ssh -i ~/.ssh/ap1_ed25519 root@ap1.example.com
Enter passphrase for key '/Users/george/.ssh/ap1_ed25519':
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
o o o
root@ap1:~#
Die Option -i brauchst du nicht, wenn du die Standarddatei id_ed25519 genommen hast. Ohne Agent wirst du jedes Mal nach der Passphrase gefragt. Mit ssh-agent kannst du die Passphrase zwischenspeichern. Lade den privaten Schlüssel mit ssh-add in den Agent:
george@imac1:~
$ ssh-add -K ~/.ssh/ap1_ed25519
Enter passphrase for /Users/george/.ssh/ap1_ed25519:
Identity added: /Users/george/.ssh/ap1_ed25519 (ap1)
Hinweis: Unter macOS speichert -K die Passphrase im Keychain, damit sie Neustarts übersteht. Unter Linux funktioniert -K nicht. Im nächsten Abschnitt wird gezeigt, wie der Schlüssel nach der ersten SSH-Sitzung automatisch in den Agent geladen werden kann.
macOS und Debian Linux nutzen beide den ssh-agent, um private Schlüssel vorzuhalten. Auf macOS startet der Agent automatisch und ist an den Keychain angebunden. Unter Debian kannst du ihn pro Terminal-Sitzung über folgende Umgebungsanpassungen starten und beenden:
george@db1:~
$ echo 'eval `ssh-agent` > /dev/null' >> ~/.profile
george@db1:~
$ echo 'eval `ssh-agent -k` > /dev/null' >> ~/.bash_logout
Starte danach deine lokale Linux-Terminal-Sitzung neu und lade den privaten Schlüssel:
george@db1:~
$ ssh-add ~/.ssh/ap1_ed25519
Enter passphrase for /home/george/.ssh/ap1_ed25519:
Identity added: /home/george/.ssh/ap1_ed25519 (ap1)
Damit kannst du dich während dieser Terminal-Sitzung ohne erneute Passphrase-Eingabe am Server anmelden.
Alternativen SSH-Port festlegen, um unerlaubte Versuche zu verringern
Wenn du den SSH-Port änderst, sinkt meist die Zahl zufälliger Login-Versuche deutlich. Solche Versuche kannst du in /var/log/auth.log nachvollziehen:
george@ap1:~$ sudo grep sshd /var/log/auth.log | grep root
Apr 6 16:28:42 ap1 sshd[30840]: Disconnected from authenticating user root 43.133.165.86 port 48314 [preauth]
Apr 6 16:31:49 ap1 sshd[30887]: Disconnected from authenticating user root 43.133.165.86 port 48382 [preauth]
Apr 6 16:34:58 ap1 sshd[30895]: Disconnected from authenticating user root 43.133.165.86 port 48448 [preauth]
o o o
SSH ist dafür ausgelegt, auf einem privilegierten Port (unterhalb von 1024) zu laufen. Du kannst jedoch jeden freien Port wählen, der nicht von einem anderen Dienst belegt ist. Prüfe dazu /etc/services, um sicherzugehen, dass der Port ungenutzt ist. Wenn du SSH beispielsweise auf Port 522 umstellen willst, gehst du so vor:
Ist eine Firewall aktiv, erlaube Port 522:
george@ap1:~$ sudo ufw allow 522/tcp
Hinweis: In diesem Beispiel wird UFW verwendet, das auf einer frischen centron Debian/Ubuntu-Instanz standardmäßig aktiv ist.
Trage den neuen Port 522 in /etc/ssh/sshd_config ein und starte den Dienst neu:
/etc/ssh/sshd_config:
< #Port 22
---
> Port 522
george@ap1:~$ sudo systemctl restart sshd
Deine aktuelle SSH-Sitzung sollte dabei bestehen bleiben. Falls du getrennt wirst, nutze die centron Web Console, um dich erneut zu verbinden und die Anpassungen zu prüfen.
Stelle sicher, dass Port 22 keine Verbindungen mehr annimmt:
george@imac1:~
$ ssh ap1
ssh: connect to host ap1.example.com port 22: Connection refused
Passe deine lokale ~/.ssh/config so an, dass für diesen Host Port 522 genutzt wird, und teste anschließend den Zugriff:
Host ap1.example.com ap1
Hostname ap1.example.com
Port 522
User george
IdentityFile ~/.ssh/ap1_ed25519
george@imac1:~
$ ssh ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
o o o
george@ap1:~$
Wenn die Firewall aktiv ist, entferne anschließend die Freigabe für Port 22:
george@ap1:~$ sudo ufw delete allow 22
Falls du stattdessen die centron Firewall nutzt, gehst du dort nach demselben Prinzip vor.
Fail2ban einrichten, um Brute-Force-Angriffe zu begrenzen
Fail2ban arbeitet mit der auf dem Server installierten Firewall – zum Beispiel UFW – zusammen und sperrt Hosts, die in kurzer Zeit mehrere fehlgeschlagene Anmeldeversuche verursachen.
Installiere fail2ban:
george@ap1:~$ sudo apt install fail2ban
Standardmäßig ist der SSH-Schutz sofort aktiv:
george@ap1:~$ sudo fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
george@ap1:~$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
Falls du den SSH-Port geändert hast, musst du das SSH-Jail von fail2ban anpassen, indem du /etc/fail2ban/jail.local anlegst:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 72.xx.yy.zz
[sshd]
port = 522
findtime = 15m
bantime = 2h
maxretry = 3
Dieses Beispiel zeigt außerdem, wie du das Erkennungsfenster (findtime), die Sperrdauer (bantime) und die maximale Anzahl an Versuchen im findtime-Zeitraum (maxretry) anpassen kannst. Im Abschnitt DEFAULT definierst du globale Optionen, etwa IPs, die nie gebannt werden sollen. Wenn du ignoreip auf deine eigene SSH-Quell-IP setzt, verhinderst du unbeabsichtigte Aussperrungen. Starte fail2ban nach dem Speichern neu:
george@ap1:~$ sudo systemctl restart fail2ban
Hinweis: Wenn du – so wie ich – den ignoreip-Eintrag vergisst, melde dich über die centron View Console an und führe den unten genannten Unban-Befehl aus.
Auch nach einem Neustart bleiben Sperren bestehen. Mit dem Status-Befehl siehst du gebannte IPs:
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 167
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 3
|- Total banned: 29
`- Banned IP list: 36.110.228.254 208.115.245.214 67.52.195.108
Eine IP kannst du vor Ablauf der Sperrzeit mit folgendem Befehl wieder freigeben:
sudo fail2ban-client set sshd unbanip 67.52.195.108
1
Prüfe anschließend mit dem Status-Befehl, ob die IP wirklich entbannt ist. Außerdem kannst du Ban- und Unban-Verläufe im fail2ban-Log nachsehen:
root@ap1:~# egrep "Ban|Unban" /var/log/fail2ban.log | grep 67.52.195.108
2022-04-11 14:55:15,351 fail2ban.actions [35842]: NOTICE [sshd] Ban 67.52.195.108
2022-04-11 15:34:53,087 fail2ban.actions [53811]: NOTICE [sshd] Restore Ban 67.52.195.108
2022-04-11 15:47:48,050 fail2ban.actions [53811]: NOTICE [sshd] Unban 67.52.195.108
Fail2ban stellt gebannte IPs nach einem Neustart wieder her. Im Log siehst du außerdem, wann eine IP nach dem Unban-Befehl freigegeben wurde. Das Beispiel basiert auf SSH-Port 22. Nach dem Umstellen auf einen anderen Port fallen die Fehlversuche in der Praxis meist deutlich geringer aus.
SSH Agent Forwarding für Nicht-Root-Benutzer konfigurieren
Mit SSH Agent Forwarding kannst du von Server A auf Server B zugreifen, während der private Schlüssel für Server B weiterhin nur auf deinem lokalen Rechner liegt. Ein typisches Szenario ist: Du loggst dich auf Server A (den ap1 Host) ein und führst von dort einen Pull von GitHub.com aus. Die GitHub-SSH-Keys müssen nicht auf dem Remote-Server liegen, weil dieser die Authentifizierungsanfrage an den SSH-Agent deines lokalen Systems weiterleitet. Forwarding muss dafür ausdrücklich für den Remote-Host aktiviert werden. Das folgende Beispiel mit GitHub und ap1 zeigt die Einrichtung.
1. GitHub SSH-Keys erstellen und installieren
Wenn du noch keine GitHub-Keys erstellt hast, nutze:
george@imac1:~
$ ssh-keygen -t ed25519 -C "GitHub"
Speichere die GitHub-Schlüssel unter ~/.ssh/GitHub und schütze sie mit einer starken Passphrase.
Füge den GitHub-Privatschlüssel dem SSH-Agent auf deinem lokalen Host hinzu:
george@imac1:~
$ ssh-add -K ~/.ssh/GitHub_ed25519
Enter passphrase for /Users/george/.ssh/GitHub_ed25519:
Identity added: /Users/george/.ssh/GitHub_ed25519 (GitHub)
Zeige die aktuell im Agent geladenen Schlüssel an:
george@imac1:~
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMjM9PSuyKe3p4gJokzGHzY5mQXq52UDajrY9A2dRfFG GitHub
Installiere deinen öffentlichen GitHub-SSH-Key anschließend über die GitHub-Einstellungen.
Alternativen SSH-Port wählen, um unerlaubte Login-Versuche zu reduzieren
Wenn du den SSH-Port wechselst, sinkt in der Regel die Anzahl zufälliger Anmeldeversuche. Solche Versuche kannst du im Log unter /var/log/auth.log einsehen:
george@ap1:~$ sudo grep sshd /var/log/auth.log | grep root
Apr 6 16:28:42 ap1 sshd[30840]: Disconnected from authenticating user root 43.133.165.86 port 48314 [preauth]
Apr 6 16:31:49 ap1 sshd[30887]: Disconnected from authenticating user root 43.133.165.86 port 48382 [preauth]
Apr 6 16:34:58 ap1 sshd[30895]: Disconnected from authenticating user root 43.133.165.86 port 48448 [preauth]
o o o
SSH läuft standardmäßig auf einem privilegierten Port (unter 1024). Du kannst aber einen beliebigen freien Port nutzen, solange er nicht bereits von einem anderen Dienst belegt ist. Prüfe dazu /etc/services, um sicherzustellen, dass der gewünschte Port verfügbar ist. Wenn du SSH zum Beispiel auf Port 522 verlegen möchtest, gehst du so vor:
Falls deine Firewall aktiv ist, erlaube Port 522:
george@ap1:~$ sudo ufw allow 522/tcp
Hinweis: In diesem Beispiel wird UFW verwendet, das auf einer frischen centron Debian/Ubuntu-Instanz standardmäßig aktiviert ist.
Ändere den SSH-Port auf 522 in /etc/ssh/sshd_config und starte den Dienst neu:
/etc/ssh/sshd_config:
< #Port 22
---
> Port 522
george@ap1:~$ sudo systemctl restart sshd
Deine laufende SSH-Sitzung sollte dabei aktiv bleiben. Falls die Verbindung dennoch abbricht, nutze die centron Web Console, um dich wieder zu verbinden und die Änderungen zu prüfen.
Stelle sicher, dass Port 22 keine Verbindung mehr akzeptiert:
george@imac1:~
$ ssh ap1
ssh: connect to host ap1.example.com port 22: Connection refused
Passe anschließend deine lokale ~/.ssh/config an, damit für diesen Host Port 522 genutzt wird, und teste den Zugriff:
Host ap1.example.com ap1
Hostname ap1.example.com
Port 522
User george
IdentityFile ~/.ssh/ap1_ed25519
george@imac1:~
$ ssh ap1
Linux ap1 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
o o o
george@ap1:~$
Wenn eine Firewall läuft, entferne danach die Freigabe für Port 22:
george@ap1:~$ sudo ufw delete allow 22
Falls du stattdessen die centron Firewall nutzt, führst du dort dieselben Schritte durch.
Fail2ban konfigurieren, um Brute-Force-Angriffe einzudämmen
Fail2ban arbeitet mit der auf dem Server installierten Firewall – etwa UFW – zusammen und blockiert Clients, die in kurzer Zeit mehrere fehlgeschlagene Login-Versuche verursachen.
Installiere fail2ban:
george@ap1:~$ sudo apt install fail2ban
Direkt nach der Installation ist der SSH-Schutz aktiv:
george@ap1:~$ sudo fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd
george@ap1:~$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:
Wenn du den SSH-Port geändert hast, musst du das passende fail2ban-Jail anpassen, indem du /etc/fail2ban/jail.local erstellst:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 72.xx.yy.zz
[sshd]
port = 522
findtime = 15m
bantime = 2h
maxretry = 3
Dieses Beispiel zeigt auch, wie du das Erkennungszeitfenster (findtime), die Sperrzeit (bantime) und die maximale Zahl an Login-Versuchen innerhalb von findtime (maxretry) anpassen kannst. Der Abschnitt DEFAULT ist für globale Einstellungen gedacht, zum Beispiel für IPs, die nie gebannt werden sollen. Wenn du ignoreip auf deine eigene SSH-Quell-IP setzt, schützt dich das vor unbeabsichtigten Lockouts. Starte fail2ban nach dem Speichern neu:
george@ap1:~$ sudo systemctl restart fail2ban
Hinweis: Falls du – wie ich – den ignoreip-Eintrag vergisst, melde dich über die centron View Console an und führe den unten genannten Unban-Befehl aus.
Sperren bleiben auch nach einem Neustart aktiv. Mit dem Status-Befehl siehst du die gebannten IPs:
Status for the jail: sshd
|- Filter
| |- Currently failed: 2
| |- Total failed: 167
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 3
|- Total banned: 29
`- Banned IP list: 36.110.228.254 208.115.245.214 67.52.195.108
Eine IP kannst du vor Ablauf der Sperrzeit so entbannen:
sudo fail2ban-client set sshd unbanip 67.52.195.108
1
Kontrolliere den Erfolg danach mit dem Status-Befehl. Zusätzlich kannst du Ban- und Unban-Historie im fail2ban-Log prüfen:
root@ap1:~# egrep "Ban|Unban" /var/log/fail2ban.log | grep 67.52.195.108
2022-04-11 14:55:15,351 fail2ban.actions [35842]: NOTICE [sshd] Ban 67.52.195.108
2022-04-11 15:34:53,087 fail2ban.actions [53811]: NOTICE [sshd] Restore Ban 67.52.195.108
2022-04-11 15:47:48,050 fail2ban.actions [53811]: NOTICE [sshd] Unban 67.52.195.108
Fail2ban setzt gebannte IPs nach einem Neustart wieder in Kraft. Im Log erkennst du außerdem, wann eine IP nach dem Unban-Befehl wieder freigegeben wurde. In diesem Beispiel stammen die Fehlversuche vom SSH-Port 22. Nach dem Umstellen auf einen anderen Port sind solche Versuche üblicherweise deutlich seltener.
SSH Agent Forwarding für Nicht-Root-Benutzer einrichten
SSH Agent Forwarding erlaubt dir, von Server A auf Server B zuzugreifen, obwohl der private Schlüssel für Server B ausschließlich auf deinem lokalen Rechner bleibt. Ein typisches Beispiel: Du meldest dich auf Server A (den ap1 Host) an und führst von dort einen Pull von GitHub.com aus. Deine GitHub-SSH-Keys müssen nicht auf dem Remote-Server liegen, weil der Remote-Host die Authentifizierungsanfrage an den SSH-Agent deines lokalen Systems weiterleitet. Agent Forwarding muss dafür explizit pro Remote-Host aktiviert werden. Das folgende GitHub-Beispiel mit ap1 zeigt die Konfiguration.
1. GitHub SSH-Keys erstellen und installieren
Falls du noch keine GitHub-Schlüssel erzeugt hast, führe Folgendes aus:
george@imac1:~
$ ssh-keygen -t ed25519 -C "GitHub"
Lege die GitHub-Schlüssel unter ~/.ssh/GitHub ab und schütze sie mit einer starken Passphrase.
Füge den GitHub-Privatschlüssel in deinen lokalen SSH-Agent ein:
george@imac1:~
$ ssh-add -K ~/.ssh/GitHub_ed25519
Enter passphrase for /Users/george/.ssh/GitHub_ed25519:
Identity added: /Users/george/.ssh/GitHub_ed25519 (GitHub)
Liste die derzeit im Agent geladenen Schlüssel auf:
george@imac1:~
$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMjM9PSuyKe3p4gJokzGHzY5mQXq52UDajrY9A2dRfFG GitHub
Installiere deinen öffentlichen GitHub-SSH-Key anschließend über die GitHub-Einstellungen.
