Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- open:it:ssh [2024/08/15 15:25] – Externe Bearbeitung 127.0.0.1
+++ open:it:ssh [2025/12/13 09:59] (aktuell) – [SSH-Zugriff auf VPN beschränken] k@i
@@ Zeile 1: / Zeile 1: @@
 ====== SSH-Verbindungen ======
 Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke. \\
+Hinweise: https://wiki.ubuntuusers.de/SSH/ \\
 <WRAP important>
-Empfehlenswert:
+Empfehlenswerte Einstellungen für einen Server, der über das Internet erreichbar ist (z.B. ein Webserver):
-  * Direkter Login von root  untersagen
+  * Den direkten Zugang für "root" von Außen ausschließen.
-  * Zugang nur mit Schlüssel -> Login ohne Schlüssel (nur Passwort) unterbinden
+  * Den Zugang mit Passwort von Außen generell ausschließen.
-  * Optional z.B. für Webserver: Beschränkter Zugriff über SFTP auf definierten Bereich (HTML-Files …)
+  * Zugang nur mit Schlüssel.
+  * Optional z.B. für Webserver: Beschränkter Zugriff über SFTP auf definierte Bereiche (HTML-Files …)
 </WRAP>
-Hinweise: https://wiki.ubuntuusers.de/SSH/
 ===== SSH-Schlüssel =====
@@ Zeile 23: / Zeile 25: @@
 b = Schlüssellänge (hier 4096 Bit) \\
-Schlüssel liegt automatisch im (versteckten) Verzeichnis ~/.ssh/ \\
+Sofern nicht anders angegeben, liegt der neue Schlüssel automatisch im (versteckten) Verzeichnis ~/.ssh/ \\
-Den Schlüssel ohne Passwort zu generieren, vereinfacht das Login, da dann später kein Passwort mehr angegeben werden muss. Wird der private Schlüssel zu einem anderen System transferiert, z.B. per E-Mail – **keine gute Idee!** — birgt das Abhör-Gefahren.
+Den Schlüssel ohne Passwort zu generieren, vereinfacht das spätere Login, da dann kein Passwort mehr angegeben werden muss. Die 2FA wird aber empfohlen.\\
+Soll der private Schlüssel auf ein anderes Systeme kopiert werden, um ihn auch von dort nutzen zu können: Auf dem neuen System müssen die Zugriffsrechte genauso eingeschränkt werden. Anderfalls gibt es Verbindungsprobleme.\\
+privater Schlüssel: .ssh/id_rsa -rw------- Owner & Group = User \\
+öffentl. Schlüssel: .ssh/id_rsa.pub -rw-r--r-- Owner & Group = User \\
 <WRAP important>
-**Der private Schlüssel muss unbedingt vor fremdem Zugriff geschützt bleiben!**
+**Der private Schlüssel muss unbedingt vor fremdem Zugriff geschützt bleiben!** \\
+Das betrifft auch den Transfer der Dateien (USB-Stick, E.Mail, etc.) \\
+Versand per E-Mail nur mit verschlüsselter E-Mail! \\
 </WRAP>
-Es werden 2 Dateien angelegt:
+Bei der Erstellung werden 2 Dateien angelegt:
   * id_rsa (privater Schlüssel)
   * id_rsa.pub (öffentlicher Schlüssel)
@@ Zeile 35: / Zeile 43: @@
 Der öffentliche Schlüssel wird auf das entfernte System übertragen, auf das zugegriffen werden soll. \\
 Der private Schlüssel bleibt auf dem lokal System, auf dem er generiert wurde. Für jedes weitere (lokale) System sollte jeweils ein eigener Schlüssel generiert werden.\\
+Werden privater und öffentllicher Schlüssel auf einen anderen PC kopiert, kann auch von dort aus auf die Server zugegriffen werden - ohne das der öffentliche Schlüssel neu auf diese Server übertragen werden muss. \\
 Zur Übertragung auf einen Server muss der User bereits dort angelegt sein und der Zugriff ohne Schlüssel (mit Passwort) muss temporär freigegeben werden. \\
@@ Zeile 65: / Zeile 74: @@
   - Load an existing private key file
   - Save private key >> jetzt mit Endung .ppk
+===== Server konfigurieren =====
+==== SSH-Zugriffe ====
+Ggf. vorher Installieren
+  sudo apt-get install openssh-server
+  sudo nano /etc/ssh/sshd_config
+  ClientAliveInterval 1200
+  ClientAliveCountMax 3
+  PermitRootLogin no
+  PasswordAuthentication no
+  Subsystem sftp internal-sftp
+<WRAP important>
+Um sich nicht selber auszusperren: \\
+PermitRootLogin nur deaktivieren, sofern ein anderer User Zugriff hat und PasswordAuthentication nur abschalten, sofern der Zugriff mit dem Key-File auch klappt! \\
+Möglicherweise gibt es Parameter in einem Unterordner, die die Regeln überschreiben. Möglich, dass dort in einer *.conf-Datei, \\
+z.B. /etc/ssh/sshd_config.d/50-cloud-init.conf, hinterlegt ist: **PasswordAuthentication yes** \\
+Das muss dann angepasst werden.
+</WRAP>
+The **ClientAliveInterval** parameter specifies the time in seconds that the server will wait before sending a null packet to the client system to keep the connection alive. \\
+The **ClientAliveCountMax** parameter defines the number of client alive messages which are sent without getting any messages from the client. \\
+Timeout value = ClientAliveInterval * ClientAliveCountMax \\
+Beispiel: 1200 x 3 = 3600 ~ 1 Stunde. \\
+Nach Änderungen muss der SSH-Service neu gestartet werden.
+  sudo systemctl reload ssh
+==== SSH-Zugriff auf VPN beschränken ====
+> Debian 13 Server (nur IPv6 öffentlich)
+> SSH (und SFTP) ausschließlich über WireGuard-VPN (IPv4 10.8.0.0/24)
+> Firewall: UFW
+=== 🛡️ Zielbild (Soll-Zustand) ===
+  * SSH nur erreichbar über WireGuard
+  * VPN-Netz: `10.8.0.0/24`
+  * Kein öffentlicher SSH (weder IPv4 noch IPv6)
+  * UFW aktiv
+  * SSH zusätzlich hart an VPN gebunden
+=== ✅ Voraussetzungen ===
+  * Du hast Konsolenzugriff oder funktionierenden VPN-Zugang
+  * WireGuard-Interface heißt `wg0`
+  * Server-VPN-IP z. B. `10.8.0.1`
+=== 🧩 1. WireGuard prüfen ===
+  ip a show wg0
+Erwartet:
+  inet 10.8.0.1/24 scope global wg0
+=== 🧩 2. UFW installieren & Grundregeln ===
+  sudo apt update
+  sudo apt install ufw
+Default-Policies:
+  sudo ufw default deny incoming
+  sudo ufw default allow outgoing
+=== 🧩 3. WireGuard selbst freigeben ===
+(typisch: UDP 51820 – ggf. anpassen)
+  sudo ufw allow 51820/udp
+=== 🧩 4. SSH nur über WireGuard erlauben ===
+(empfohlen: Interface-gebunden)
+  sudo ufw allow in on wg0 to any port 22 proto tcp
+Alternativ:
+  sudo ufw allow from 10.8.0.0/24 to any port 22 proto tcp
+=== 🧩 5. Öffentlichen SSH entfernen (IPv4 + IPv6) ===
+Status anzeigen:
+  sudo ufw status numbered
+Du wirst sehen:
+/tcp (OpenSSH)       ALLOW IN Anywhere
+/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
+Löschen:
+  sudo ufw delete allow ssh
+oder gezielt per Nummer:
+  sudo ufw delete <NUMMER>
+=== 🧩 6. IPv6 in UFW deaktivieren (wichtig!) ===
+Da SSH nur über IPv4-VPN laufen soll:
+  sudo nano /etc/default/ufw
+Ändern:
+  IPV6=no
+Dann:
+  sudo ufw reload
+=== 🧩 7. UFW aktivieren ===
+  sudo ufw enable
+**Prüfen:**
+  sudo ufw status verbose
+**Soll:**
+/tcp     ALLOW IN    on wg0
+/udp  ALLOW IN    Anywhere
+=== 🧩 8. SSH hart an WireGuard binden ===
+👉 Das ist der entscheidende Sicherheitsanker.
+  sudo nano /etc/ssh/sshd_config
+Eintragen:
+  AddressFamily inet
+  ListenAddress 10.8.0.1
+Dann:
+  sudo systemctl restart ssh
+=== 🧪 9. Tests (Pflicht!) ===
+❌ Ohne VPN
+  ssh user@SERVER_IPV6
+➡️ **muss fehlschlagen**
+✅ Mit VPN
+  ssh user@10.8.0.1
+➡️ **muss funktionieren**
+=== 🔎 10. Finale Kontrolle ===
+  sudo ss -tlnp | grep :22
+**Soll:**
+  LISTEN 10.8.0.1:22
+❌ **nicht erlaubt**:
+.0.0.0:22
+  [::]:22
+🧠 Warum dieses Setup Best Practice ist
+| Ebene               | Schutz                              |
+| WireGuard           | Zugang nur für autorisierte Clients |
+| UFW                 | Filtert Traffic                     |
+| SSH `ListenAddress` | verhindert offenen Port technisch   |
+| IPv6 deaktiviert    | keine „stille“ Umgehung             |
+➡️ **Selbst bei Firewall-Fehlern kein öffentlicher SSH möglich**
+🧾 Kurzfassung (Merkliste)
+  - VPN zuerst testen
+  - SSH nur wg0 erlauben
+  - OpenSSH (v6) löschen
+  - IPv6 in UFW deaktivieren
+  - SSH an 10.8.0.1 binden
+==== Schutz vor Angriffen mit fail2ban ====
+[[https://schroederdennis.de/tutorial-howto/ssh-login-schuetzen-mit-fail2ban-server-absichern-anleitung-brute-force/|SSH Login schützen mit fail2ban]] \\
+[[https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-debian-11|How To Protect SSH with Fail2Ban on Debian 11]] \\
+[[https://www.howtoforge.de/anleitung/installation-und-verwendung-von-fail2ban-unter-debian-12/|Installation und Verwendung von Fail2ban unter Debian 12]] \\
+[[https://wiki.ubuntuusers.de/fail2ban/|fail2ban bei Ubuntu-Users]] \\
+fail2ban installieren
+  sudo apt update
+  sudo apt install fail2ban
+Conf-Dateien kopieren
+  sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
+  sudo cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
+nur die .local-Dateien bearbeiten
+  sudo nano /etc/fail2ban/jail.local
+Ändern (nach [sshd]) suchen: \\
+[sshd]
+  backend=systemd
+  enabled = true
+  port = ssh
+  filter = sshd
+  logpath = /var/log/auth.log
+  maxretry = 3
+Über die Zeit-Parameter in der Datei /etc/fail2ban/jail.local lässt es sich steuern: \\
+# "bantime" is the number of seconds that a host is banned. \\
+# Beispiel: Sperrung(banned) für 1 Stunde, wenn maxrtry innerhalb findtime erreicht wurde \\
+**bantime = 3600** \\
+# A host is banned if it has generated "maxretry" during the last "findtime" \\
+# Beispiel: Zeit (hier 3 Minuten). \\
+**findtime = 180** \\
+# "maxretry" is the number of failures before a host get banned. \\
+**maxretry = 5** \\
+Installieren
+  sudo apt install python3-systemd
+fail2ban neu starten
+  sudo systemctl restart fail2ban
+Autostart mit System
+  sudo systemctl enable fail2ban
+Protokoll der (temporär) verbanten IP-Adressen
+  sudo zgrep 'Ban' /var/log/fail2ban.log*
+==== Verbindungs-Protokolle ====
+Quelle: https://www.strongdm.com/blog/view-ssh-logs \\
+If you want to view ssh logs from a specific time range, you can use the since and until flags. Some examples:
+  sudo journalctl -u ssh --since yesterday
+  sudo journalctl -u ssh --since -3d --until -2d # logs from three days ago
+  sudo journalctl -u ssh --since -1h # logs from the last hour
+  sudo journalctl -u ssh --until "2024-12-20 07:00:00"
+To watch the ssh logs in realtime, use the follow flag:
+  sudo journalctl -fu ssh
+Use Ctrl-C to exit out of the log monitor.
 ===== Login =====
 ==== Login über Linux-Shell ====
-Login mit Passwort oder wenn der key im <REMOTEHOST> hinterlegt ist:
+Login mit Passwort:
   ssh <USER>@<REMOTEHOST>
-<USER>@ kann weggelassen werden, wenn entfernter <USER> mit dem lokalen Usernamen übereinstimmt.
+<USER>: Benutzername auf Remote-Host. <USER>@ kann weggelassen werden, wenn entfernter <USER> mit dem lokalen Usernamen übereinstimmt. \\
+<REMOTEHOST>: IP-Adresse des Remote-Host
-Beim ersten Login, wenn der public-key noch nicht auf dem Server ist oder dieser sich geändert hat, muss dieser im Remote-Server registriert werden. Entweder wie oben beschrieben mit (ssh-copy-id ...) oder mit folgender Methode:
+Login mit Key wenn der key im <REMOTEHOST> bereits hinterlegt ist:
-  ssh -i ~/.ssh/id_rsa <USER>@<REMOTEHOST>
+  ssh -i <KEY_PFAD> <USER>@<REMOTEHOST>
+<KEY_PFAD> z.B.: .ssh/id_rsa \\
+Standardpfad für den Key ist: .ssh/id_rsa wenn er dort liegt, kann "-i <KEY_PFAD>" weggelassen werden. \\
+i = identity_file \\
-  * ~/.ssh/id_rsa = (relativer) Pfad und Name privater Schlüssel
+Beim ersten Login, wenn der public-key noch nicht auf dem Server ist oder dieser sich geändert hat, muss dieser im Remote-Server registriert werden.
-  * <USER>@<REMOTEHOST> = User und IP# des entfernten Systems
+  ssh-copy-id <USER>@<REMOTEHOST>
 Beim ersten Login erfolgt eine Validierung mit dem Passwort des Systems. Bei Folgeaufrufen nur noch mit dem PW des SSH-Keys bzw. wenn keines vergeben wurde, ohne PW. \\
-Beim ersten Login werden die dann bekannten Hosts lokal in **~/.ssh/known_hosts** gespeichert. Gibt es Änderungen an einem Host und ggf. damit verbundene Probleme, dann kann der Host daraus, oder die ganze Datei, gelöscht werden. Wird dann beim nächsten Aufruf neu generiert.
+Beim ersten Login werden die dann bekannten Hosts lokal in **~/.ssh/known_hosts** gespeichert. Gibt es Änderungen an einem Host und ggf. damit verbundene Probleme, dann kann der Host daraus, oder die ganze Datei, gelöscht werden. Wird dann beim nächsten Aufruf neu generiert. Auf dem server wird der "neue" Key eines Users eintgetragen in der Datei .ssh/authorized_keys. Für jeden User des Server-Systems werden die Schlüssel separat in seinem Home-Verzeichnis verwaltet.
 Wurde der Schlüssel am Server geändert, oder der Server neu eingerichtet, muss er aus der lokalen Datei ~/.ssh/known_hosts ausgetragen werden. Händisch oder mit dem Befehl (IP des betroffenen Servers):
@@ Zeile 106: / Zeile 339: @@
 Verbindungsart: **Schlüsseldatei**.
-===== SSH-Zugriff am Server konfigurieren =====
-  sudo nano /etc/ssh/sshd_config
-  ClientAliveInterval 1200
-  ClientAliveCountMax 3
-  PermitRootLogin no
-  PasswordAuthentication no
-  Subsystem sftp internal-sftp
-<WRAP important>
-Um sich nicht selber auszusperren: \\
-PermitRootLogin nur deaktivieren, sofern ein anderer User Zugriff hat und PasswordAuthentication nur abschalten, sofern der Zugriff mit dem Key-File auch klappt! \\
-Möglicherweise gibt es Parameter in einem Unterordner, der die Regeln überschreibt. Möglich, dass dort z.B. in einer *.conf-Datei hinterlegt ist: **PasswordAuthentication yes** \\
-Das muss dann angepasst werden.
-</WRAP>
-The **ClientAliveInterval** parameter specifies the time in seconds that the server will wait before sending a null packet to the client system to keep the connection alive. \\
-The **ClientAliveCountMax** parameter defines the number of client alive messages which are sent without getting any messages from the client. \\
-Timeout value = ClientAliveInterval * ClientAliveCountMax \\
-Beispiel: 1200 x 3 = 3600 ~ 1 Stunde. \\
-Nach Änderungen muss der SSH-Service neu gestartet werden.
-  sudo systemctl reload ssh
 ===== Dateien kopieren über SSH =====
 Dafür __nicht__ vorab auf dem Remote-Server einloggen, sondern vom lokalen Rechner ausführen.
@@ Zeile 142: / Zeile 352: @@
 Kopieren des Verzeichnisses “foo” vom lokalen Rechner in das Verzeichnis “bar” eines entfernten Rechners.
   scp -r foo <USER>@<REMOTEHOST>:/some/remote/directory/bar
 Quelle: https://www.davidkehr.com/linux-kopieren-von-und-zu-einem-computer-per-scp-ssh/