Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- open:it:ssh [2025/04/07 13:47] – [Login über Linux-Shell] k@i
+++ open:it:ssh [2025/12/13 09:59] (aktuell) – [SSH-Zugriff auf VPN beschränken] k@i
@@ Zeile 25: / 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 37: / 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 96: / Zeile 103: @@
 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 ====