---
title: SSH ACCESS Dokumentation
description: 
published: true
date: 2026-02-24T08:29:18.034Z
tags: 
editor: markdown
dateCreated: 2026-02-24T08:29:18.034Z
---

# SSH-Schlüssel & Server-Sicherheit – Vollständige Dokumentation

> **Systemumgebung:** Debian-basierter Server (Debian 12 / Ubuntu 22.04+)
> **Protokoll:** OpenSSH (Server und Client)
> **Einsatz:** Sichere Authentifizierung, verschlüsselte Fernwartung, Git-Zugang, automatisierte Prozesse

---

## Inhaltsverzeichnis

1. [Überblick und Funktionsweise](#1-überblick-und-funktionsweise)
2. [SSH-Server installieren und absichern](#2-ssh-server-installieren-und-absichern)
3. [SSH-Schlüsselpaare erstellen](#3-ssh-schlüsselpaare-erstellen)
4. [Schlüssel auf den Server übertragen](#4-schlüssel-auf-den-server-übertragen)
5. [Passwort-Authentifizierung deaktivieren](#5-passwort-authentifizierung-deaktivieren)
6. [Benutzer verwalten](#6-benutzer-verwalten)
7. [SSH-Client-Konfiguration](#7-ssh-client-konfiguration)
8. [Verbindung herstellen und nutzen](#8-verbindung-herstellen-und-nutzen)
9. [SSH-Agent und Schlüsselverwaltung](#9-ssh-agent-und-schlüsselverwaltung)
10. [Mehrstufige Absicherung (Hardening)](#10-mehrstufige-absicherung-hardening)
11. [Fail2Ban – Brute-Force-Schutz](#11-fail2ban--brute-force-schutz)
12. [SSH für Dienste (Gitea, Rsync, SFTP)](#12-ssh-für-dienste-gitea-rsync-sftp)
13. [SSH-Tunneling und Port-Weiterleitung](#13-ssh-tunneling-und-port-weiterleitung)
14. [Schlüssel rotieren und widerrufen](#14-schlüssel-rotieren-und-widerrufen)
15. [Fehlerbehebung](#15-fehlerbehebung)
16. [Schnellreferenz – Befehle auf einen Blick](#16-schnellreferenz--befehle-auf-einen-blick)

---

## 1. Überblick und Funktionsweise

### Was ist SSH?

SSH (Secure Shell) ist ein kryptographisches Netzwerkprotokoll für die sichere Kommunikation zwischen zwei Rechnern. Es verschlüsselt die gesamte Verbindung und ersetzt unsichere Protokolle wie Telnet und rlogin.

### Warum Schlüssel statt Passwörter?

| Eigenschaft | Passwort | SSH-Schlüssel |
|---|---|---|
| Brute-Force-Anfälligkeit | Hoch | Praktisch unmöglich |
| Länge der Authentifizierung | 8–30 Zeichen | 256–4096 Bit |
| Automatisierung möglich | Unsicher (Passwort im Skript) | Sicher (Agent oder Schlüsseldatei) |
| Phishing-Gefahr | Ja | Nein |
| Mehrere Server | Gleiches Passwort = Risiko | Ein Schlüssel, viele Server |
| Widerrufen | Passwort auf jedem Server ändern | Schlüssel aus `authorized_keys` entfernen |

### Wie funktioniert die Schlüssel-Authentifizierung?

SSH-Schlüssel arbeiten mit asymmetrischer Kryptographie. Es gibt immer ein Paar aus zwei Schlüsseln:

- **Privater Schlüssel** (`id_ed25519`): Bleibt ausschließlich auf dem Client. Wird niemals übertragen. Vergleichbar mit einem physischen Hausschlüssel.
- **Öffentlicher Schlüssel** (`id_ed25519.pub`): Wird auf den Server kopiert. Vergleichbar mit einem Schloss, das nur der passende Schlüssel öffnen kann.

### Ablauf der Authentifizierung

```plantuml
@startuml

skinparam shadowing false
skinparam roundCorner 10

actor "Client\n(Benutzer-PC)" as client
participant "SSH-Server\n(Debian)" as server

client -> server : 1. Verbindungsanfrage
server -> client : 2. Server-Identität (Host Key)
client -> client : 3. Host Key prüfen (known_hosts)
server -> client : 4. Zufällige Challenge senden
client -> client : 5. Challenge mit privatem Schlüssel signieren
client -> server : 6. Signatur zurücksenden
server -> server : 7. Signatur mit öffentlichem\nSchlüssel verifizieren
server -> client : 8. Zugriff gewährt

@enduml
```

**Schritt für Schritt:**

1. Der Client baut eine TCP-Verbindung zum SSH-Server auf (Standard: Port 22)
2. Der Server sendet seinen Host Key zur Identifikation
3. Der Client prüft, ob er diesen Server kennt (Datei `~/.ssh/known_hosts`)
4. Der Server sendet eine zufällige Challenge (Zufallsdaten)
5. Der Client signiert diese Challenge mit seinem privaten Schlüssel
6. Die Signatur wird an den Server zurückgesendet
7. Der Server prüft die Signatur mit dem öffentlichen Schlüssel aus `authorized_keys`
8. Stimmt die Signatur, wird der Zugriff gewährt – ohne dass der private Schlüssel jemals übertragen wurde

### Unterstützte Schlüsseltypen

| Typ | Befehl | Sicherheit | Empfehlung |
|---|---|---|---|
| **Ed25519** | `ssh-keygen -t ed25519` | Sehr hoch (256 Bit) | **Empfohlen** – schnell, sicher, kurze Schlüssel |
| **RSA** | `ssh-keygen -t rsa -b 4096` | Hoch (4096 Bit) | Gut für ältere Systeme |
| **ECDSA** | `ssh-keygen -t ecdsa -b 521` | Hoch | Alternative zu Ed25519 |
| DSA | – | Veraltet | **Nicht verwenden** |

> **Empfehlung:** Ed25519 ist der moderne Standard. Es bietet die höchste Sicherheit bei kleinster Schlüsselgröße und bester Performance. RSA-4096 nur verwenden, wenn ältere Systeme Ed25519 nicht unterstützen.

---

## 2. SSH-Server installieren und absichern

### 2.1 OpenSSH-Server installieren

```bash
# Installation
sudo apt update
sudo apt install -y openssh-server

# Dienststatus prüfen
sudo systemctl status ssh

# Autostart aktivieren
sudo systemctl enable ssh
```

### 2.2 Aktuelle Version prüfen

```bash
sshd -V
# oder
ssh -V
```

### 2.3 Grundkonfiguration (sshd_config)

Die Hauptkonfiguration des SSH-Servers liegt in `/etc/ssh/sshd_config`. Vor der Bearbeitung eine Sicherungskopie erstellen:

```bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config
```

Empfohlene Basiskonfiguration:

```bash
# ===========================================================
#  /etc/ssh/sshd_config – Sichere Grundkonfiguration
# ===========================================================

# ---- Netzwerk ----
Port 22                              # Standard-Port (Änderung siehe Abschnitt 10)
AddressFamily inet                   # Nur IPv4 (inet6 für IPv6, any für beide)
ListenAddress 0.0.0.0               # Auf allen IPv4-Interfaces lauschen

# ---- Protokoll und Schlüssel ----
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# ---- Authentifizierung ----
PermitRootLogin prohibit-password    # Root nur mit Schlüssel (oder: no)
PubkeyAuthentication yes             # Schlüssel-Authentifizierung aktivieren
PasswordAuthentication yes           # Vorerst ja – nach Schlüssel-Setup: no
PermitEmptyPasswords no              # Leere Passwörter niemals erlauben
ChallengeResponseAuthentication no   # Interaktive Authentifizierung deaktivieren

# ---- Schlüsseldatei ----
AuthorizedKeysFile .ssh/authorized_keys

# ---- Sicherheit ----
MaxAuthTries 3                       # Maximale Anmeldeversuche pro Verbindung
MaxSessions 5                        # Maximale gleichzeitige Sitzungen
LoginGraceTime 30                    # Sekunden bis zum Login-Timeout
ClientAliveInterval 300              # Keepalive alle 5 Minuten
ClientAliveCountMax 2                # Nach 2 fehlenden Keepalives trennen

# ---- Weitere Sicherheitsoptionen ----
X11Forwarding no                     # X11-Weiterleitung deaktivieren
AllowTcpForwarding yes               # TCP-Weiterleitung erlauben
AllowAgentForwarding yes             # Agent-Weiterleitung erlauben
PrintMotd no                         # Message of the Day deaktivieren
PrintLastLog yes                     # Letzten Login anzeigen
UsePAM yes                           # PAM verwenden

# ---- Logging ----
SyslogFacility AUTH
LogLevel INFO                        # INFO oder VERBOSE für mehr Details

# ---- Zugriffsbeschränkung (optional) ----
# AllowUsers admin deployer          # Nur bestimmte Benutzer erlauben
# AllowGroups ssh-users              # Nur bestimmte Gruppen erlauben
# DenyUsers root testuser            # Bestimmte Benutzer blockieren

# ---- SFTP ----
Subsystem sftp /usr/lib/openssh/sftp-server
```

### 2.4 Konfiguration prüfen und anwenden

```bash
# Konfiguration auf Syntaxfehler prüfen (IMMER vor dem Neustart)
sudo sshd -t

# Bei Erfolg: Dienst neu starten
sudo systemctl restart ssh

# Status prüfen
sudo systemctl status ssh
```

> **Warnung:** Vor dem Neustart des SSH-Dienstes sicherstellen, dass eine alternative Zugriffsmöglichkeit besteht (z. B. Konsole, zweite SSH-Sitzung), falls die Konfiguration fehlerhaft ist.

---

## 3. SSH-Schlüsselpaare erstellen

### 3.1 Auf dem Client-Rechner (Benutzer-PC)

Die Schlüsselerzeugung geschieht **immer auf dem Client**, niemals auf dem Server.

#### Ed25519 (empfohlen)

```bash
ssh-keygen -t ed25519 -C "benutzer@firma.de"
```

Interaktive Ausgabe:

```
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/benutzer/.ssh/id_ed25519): [Enter]
Enter passphrase (empty for no passphrase): [Starke Passphrase eingeben]
Enter same passphrase again: [Wiederholen]
```

#### RSA-4096 (für ältere Systeme)

```bash
ssh-keygen -t rsa -b 4096 -C "benutzer@firma.de"
```

#### Mit benutzerdefiniertem Dateinamen

```bash
ssh-keygen -t ed25519 -C "benutzer@firma.de" -f ~/.ssh/firma_server
```

Dies erzeugt:
- `~/.ssh/firma_server` (privater Schlüssel)
- `~/.ssh/firma_server.pub` (öffentlicher Schlüssel)

### 3.2 Parameter erklärt

| Parameter | Beschreibung |
|---|---|
| `-t ed25519` | Schlüsseltyp (ed25519, rsa, ecdsa) |
| `-b 4096` | Schlüssellänge in Bit (nur für RSA/ECDSA) |
| `-C "kommentar"` | Kommentar (üblicherweise E-Mail-Adresse) |
| `-f /pfad/datei` | Ausgabedatei für den Schlüssel |
| `-N "passphrase"` | Passphrase nicht-interaktiv setzen |

### 3.3 Passphrase – Ja oder Nein?

| Szenario | Passphrase | Begründung |
|---|---|---|
| Tägliche Arbeit | **Ja** (mit SSH-Agent) | Schutz bei Diebstahl des Rechners |
| Automatisierte Prozesse | Nein (oder Agent) | Skripte können keine Passphrase eingeben |
| Hochsicherheitsumgebung | **Ja** (immer) | Maximaler Schutz |

> **Empfehlung:** Immer eine Passphrase verwenden und den SSH-Agent nutzen (siehe Abschnitt 9), damit die Passphrase nur einmal pro Sitzung eingegeben werden muss.

### 3.4 Erstellte Dateien prüfen

```bash
# Schlüsseldateien anzeigen
ls -la ~/.ssh/

# Erwartete Ausgabe:
# -rw-------  1 benutzer benutzer  419 Jan  1 12:00 id_ed25519        (privat)
# -rw-r--r--  1 benutzer benutzer  105 Jan  1 12:00 id_ed25519.pub    (öffentlich)

# Öffentlichen Schlüssel anzeigen
cat ~/.ssh/id_ed25519.pub

# Schlüssel-Fingerprint anzeigen
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
```

> **Berechtigungen sind kritisch:** Der private Schlüssel muss die Berechtigung `600` haben (`-rw-------`). SSH verweigert die Nutzung bei zu offenen Berechtigungen.

### 3.5 Schlüssel auf Windows erstellen

#### Windows 10/11 (integriertes OpenSSH)

```powershell
# PowerShell öffnen
ssh-keygen -t ed25519 -C "benutzer@firma.de"

# Schlüssel liegen in: C:\Users\BENUTZERNAME\.ssh\
type $env:USERPROFILE\.ssh\id_ed25519.pub
```

#### PuTTYgen (PuTTY)

1. **PuTTYgen** öffnen
2. Schlüsseltyp: **EdDSA** (Ed25519) oder **RSA** (4096 Bit)
3. **Generate** klicken und Maus bewegen
4. **Passphrase** eingeben
5. **Save private key** (.ppk-Datei)
6. Öffentlichen Schlüssel aus dem oberen Textfeld kopieren

> **Hinweis:** PuTTY verwendet ein eigenes Schlüsselformat (.ppk). Für OpenSSH-kompatible Schlüssel unter Windows am besten das integrierte `ssh-keygen` verwenden.

---

## 4. Schlüssel auf den Server übertragen

### 4.1 Methode 1: ssh-copy-id (empfohlen)

Der einfachste und sicherste Weg:

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server-ip
```

Dieser Befehl:
1. Verbindet sich per Passwort mit dem Server
2. Erstellt `~/.ssh/authorized_keys` falls nicht vorhanden
3. Fügt den öffentlichen Schlüssel hinzu
4. Setzt korrekte Berechtigungen

Ausgabe:

```
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'benutzer@server-ip'"
and check to make sure that only the key(s) you wanted were added.
```

### 4.2 Methode 2: Manuell kopieren

Falls `ssh-copy-id` nicht verfügbar ist:

```bash
# Öffentlichen Schlüssel anzeigen und kopieren
cat ~/.ssh/id_ed25519.pub

# Auf dem Server (per Passwort-Login):
ssh benutzer@server-ip

# Verzeichnis und Datei erstellen
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

# Öffentlichen Schlüssel einfügen und speichern

# Berechtigungen setzen
chmod 600 ~/.ssh/authorized_keys
```

### 4.3 Methode 3: Per Pipe (einzeilig)

```bash
cat ~/.ssh/id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
```

### 4.4 Verbindung mit Schlüssel testen

```bash
# Verbindung testen (sollte ohne Passwort funktionieren)
ssh benutzer@server-ip

# Bei mehreren Schlüsseln: Schlüssel explizit angeben
ssh -i ~/.ssh/id_ed25519 benutzer@server-ip

# Verbose-Modus für Debugging
ssh -v benutzer@server-ip
```

### 4.5 Korrekte Berechtigungen (Server-Seite)

SSH ist sehr streng bei den Dateiberechtigungen. Falsche Berechtigungen führen zur Ablehnung der Authentifizierung.

| Pfad | Berechtigung | Oktal |
|---|---|---|
| `/home/benutzer` | `drwxr-xr-x` | 755 (oder strenger) |
| `/home/benutzer/.ssh` | `drwx------` | **700** |
| `/home/benutzer/.ssh/authorized_keys` | `-rw-------` | **600** |

```bash
# Berechtigungen reparieren (auf dem Server)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $(whoami):$(whoami) ~/.ssh
```

---

## 5. Passwort-Authentifizierung deaktivieren

Nachdem alle Benutzer ihre SSH-Schlüssel hinterlegt haben, sollte die Passwort-Authentifizierung deaktiviert werden.

### 5.1 Voraussetzungen prüfen

Vor der Deaktivierung sicherstellen:

- [ ] Mindestens ein Benutzer kann sich per SSH-Schlüssel anmelden
- [ ] Der Administrator hat einen funktionierenden Schlüssel
- [ ] Ein Notfallzugang besteht (Konsole, KVM, IPMI)
- [ ] Alle regulären Benutzer haben ihre Schlüssel hinterlegt

### 5.2 Testen (in einer zweiten Sitzung!)

```bash
# Erste SSH-Sitzung offen lassen!
# In einem neuen Terminal testen:
ssh -o PreferredAuthentications=publickey benutzer@server-ip

# Funktioniert? → Weiter mit Schritt 5.3
# Fehler? → Schlüssel-Setup prüfen, NICHT die Passwort-Auth deaktivieren
```

### 5.3 Passwort-Authentifizierung deaktivieren

```bash
sudo nano /etc/ssh/sshd_config
```

Folgende Zeilen ändern:

```bash
# Passwort-Authentifizierung deaktivieren
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# Root-Login nur mit Schlüssel (oder komplett deaktivieren)
PermitRootLogin prohibit-password
# Alternativ, um Root-Login komplett zu verbieten:
# PermitRootLogin no
```

Zusätzlich in `/etc/ssh/sshd_config.d/` nach Override-Dateien suchen:

```bash
# Prüfen, ob Override-Dateien existieren
ls -la /etc/ssh/sshd_config.d/

# Falls ja: Auch dort PasswordAuthentication auf no setzen
# Debian 12 hat oft eine Datei 50-cloud-init.conf
sudo grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
```

> **Wichtig:** Auf Debian 12 und Ubuntu 22.04+ können Dateien in `/etc/ssh/sshd_config.d/` die Hauptkonfiguration überschreiben. Alle Dateien dort prüfen.

### 5.4 Konfiguration anwenden

```bash
# Syntax prüfen
sudo sshd -t

# SSH-Dienst neu starten
sudo systemctl restart ssh

# In einem NEUEN Terminal testen (altes Terminal offen lassen!)
ssh benutzer@server-ip

# Passwort-Login sollte jetzt fehlschlagen:
ssh -o PreferredAuthentications=password benutzer@server-ip
# Erwartete Ausgabe: Permission denied (publickey).
```

---

## 6. Benutzer verwalten

### 6.1 Neuen Benutzer mit SSH-Zugang anlegen

#### Schritt 1: Linux-Benutzer erstellen (auf dem Server)

```bash
# Benutzer erstellen
sudo adduser neuerbenutzer

# Oder ohne interaktive Fragen:
sudo useradd -m -s /bin/bash -G ssh-users neuerbenutzer
sudo passwd neuerbenutzer
```

#### Schritt 2: SSH-Verzeichnis vorbereiten (auf dem Server)

```bash
# SSH-Verzeichnis erstellen
sudo mkdir -p /home/neuerbenutzer/.ssh
sudo touch /home/neuerbenutzer/.ssh/authorized_keys

# Berechtigungen setzen
sudo chmod 700 /home/neuerbenutzer/.ssh
sudo chmod 600 /home/neuerbenutzer/.ssh/authorized_keys
sudo chown -R neuerbenutzer:neuerbenutzer /home/neuerbenutzer/.ssh
```

#### Schritt 3: Öffentlichen Schlüssel hinzufügen

```bash
# Öffentlichen Schlüssel des Benutzers eintragen
# (den Schlüssel vom Benutzer anfordern – NUR den öffentlichen Schlüssel!)
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... benutzer@firma.de" | \
  sudo tee -a /home/neuerbenutzer/.ssh/authorized_keys
```

Oder der Benutzer überträgt seinen Schlüssel selbst (solange Passwort-Auth noch aktiv ist):

```bash
# Auf dem Client des neuen Benutzers:
ssh-copy-id neuerbenutzer@server-ip
```

### 6.2 Sudo-Rechte vergeben

```bash
# Benutzer zur sudo-Gruppe hinzufügen
sudo usermod -aG sudo neuerbenutzer

# Oder: Spezifische sudo-Rechte definieren
sudo visudo -f /etc/sudoers.d/neuerbenutzer
```

```
# Volle sudo-Rechte
neuerbenutzer ALL=(ALL:ALL) ALL

# Eingeschränkte Rechte (nur bestimmte Befehle)
neuerbenutzer ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart gitea
```

### 6.3 SSH-Zugangsgruppe erstellen

Für eine feinere Kontrolle, wer sich per SSH anmelden darf:

```bash
# Gruppe erstellen
sudo groupadd ssh-users

# Benutzer hinzufügen
sudo usermod -aG ssh-users admin
sudo usermod -aG ssh-users neuerbenutzer
```

In `/etc/ssh/sshd_config`:

```bash
# Nur Mitglieder der Gruppe ssh-users dürfen sich per SSH anmelden
AllowGroups ssh-users
```

```bash
sudo systemctl restart ssh
```

> **Wichtig:** Bei Verwendung von `AllowGroups` oder `AllowUsers` sind **nur** die genannten Benutzer/Gruppen zugelassen. Alle anderen werden blockiert.

### 6.4 Benutzer-SSH-Zugang entziehen

```bash
# Methode 1: Schlüssel aus authorized_keys entfernen
sudo nano /home/benutzer/.ssh/authorized_keys
# → Zeile mit dem Schlüssel löschen

# Methode 2: Benutzer aus der SSH-Gruppe entfernen
sudo gpasswd -d benutzer ssh-users

# Methode 3: Benutzer komplett sperren
sudo usermod -L benutzer            # Konto sperren
sudo usermod -s /usr/sbin/nologin benutzer  # Shell entfernen

# Methode 4: Benutzer löschen
sudo userdel -r benutzer            # Inklusive Home-Verzeichnis
```

### 6.5 Alle SSH-Schlüssel eines Benutzers anzeigen

```bash
# Schlüssel auflisten
sudo cat /home/benutzer/.ssh/authorized_keys

# Anzahl der Schlüssel zählen
sudo grep -c "^ssh-" /home/benutzer/.ssh/authorized_keys

# Fingerprints aller Schlüssel anzeigen
while IFS= read -r key; do
    echo "$key" | ssh-keygen -l -f - 2>/dev/null
done < /home/benutzer/.ssh/authorized_keys
```

### 6.6 Mehrere Schlüssel pro Benutzer

Ein Benutzer kann mehrere Schlüssel hinterlegen (z. B. für verschiedene Geräte):

```bash
# Datei authorized_keys – ein Schlüssel pro Zeile:
ssh-ed25519 AAAAC3... benutzer@laptop
ssh-ed25519 AAAAC3... benutzer@desktop
ssh-rsa AAAAB3...     benutzer@altes-geraet
```

---

## 7. SSH-Client-Konfiguration

### 7.1 Konfigurationsdatei (~/.ssh/config)

Die Datei `~/.ssh/config` vereinfacht SSH-Verbindungen erheblich. Statt langer Befehle genügt ein kurzer Alias.

```bash
nano ~/.ssh/config
```

```bash
# ===========================================================
#  ~/.ssh/config – Client-Konfiguration
# ===========================================================

# ---- Globale Einstellungen ----
Host *
    # Verbindung aufrechterhalten
    ServerAliveInterval 60
    ServerAliveCountMax 3
    # Schlüssel zum Agent hinzufügen
    AddKeysToAgent yes
    # Nur den angegebenen Schlüssel versuchen
    IdentitiesOnly yes

# ---- Produktiv-Server ----
Host server
    HostName 192.168.1.100
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

# ---- Produktiv-Server (alternativer Name) ----
Host prod
    HostName server.example.de
    User deployer
    Port 2222
    IdentityFile ~/.ssh/deploy_key

# ---- Gitea-Server ----
Host gitea
    HostName git.example.de
    User git
    Port 22
    IdentityFile ~/.ssh/id_ed25519

# ---- Staging-Server ----
Host staging
    HostName staging.example.de
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    # Über Bastion-Host verbinden (ProxyJump)
    ProxyJump bastion

# ---- Bastion-Host (Jump-Server) ----
Host bastion
    HostName bastion.example.de
    User jumpuser
    Port 22
    IdentityFile ~/.ssh/bastion_key
```

### 7.2 Verbindung mit Alias

```bash
# Statt:
ssh -i ~/.ssh/id_ed25519 -p 2222 deployer@server.example.de

# Einfach:
ssh prod
```

### 7.3 Wichtige Config-Optionen

| Option | Beschreibung | Beispiel |
|---|---|---|
| `HostName` | Tatsächliche Adresse (IP oder Domain) | `192.168.1.100` |
| `User` | Benutzername auf dem Server | `admin` |
| `Port` | SSH-Port | `2222` |
| `IdentityFile` | Pfad zum privaten Schlüssel | `~/.ssh/id_ed25519` |
| `IdentitiesOnly` | Nur den angegebenen Schlüssel verwenden | `yes` |
| `ProxyJump` | Über einen anderen Server verbinden | `bastion` |
| `ForwardAgent` | SSH-Agent weiterleiten | `yes` |
| `LocalForward` | Lokalen Port weiterleiten | `8080 localhost:80` |
| `ServerAliveInterval` | Keepalive-Intervall (Sekunden) | `60` |
| `AddKeysToAgent` | Schlüssel automatisch zum Agent hinzufügen | `yes` |

### 7.4 Berechtigungen der Config-Datei

```bash
chmod 600 ~/.ssh/config
```

---

## 8. Verbindung herstellen und nutzen

### 8.1 Einfache Verbindung

```bash
# Standard
ssh benutzer@server-ip

# Mit bestimmtem Schlüssel
ssh -i ~/.ssh/mein_schluessel benutzer@server-ip

# Mit anderem Port
ssh -p 2222 benutzer@server-ip

# Verbose (für Debugging)
ssh -v benutzer@server-ip       # Stufe 1
ssh -vv benutzer@server-ip      # Stufe 2
ssh -vvv benutzer@server-ip     # Stufe 3 (maximal)
```

### 8.2 Einzelnen Befehl ausführen

```bash
# Befehl auf dem Server ausführen, ohne interaktive Shell
ssh benutzer@server-ip "uptime"
ssh benutzer@server-ip "df -h && free -m"
ssh benutzer@server-ip "sudo systemctl status nginx"
```

### 8.3 Dateien übertragen (SCP)

```bash
# Datei zum Server kopieren
scp datei.txt benutzer@server-ip:/home/benutzer/

# Datei vom Server herunterladen
scp benutzer@server-ip:/var/log/syslog ./syslog-backup.txt

# Verzeichnis rekursiv kopieren
scp -r ./mein-projekt benutzer@server-ip:/home/benutzer/projekte/

# Mit anderem Port
scp -P 2222 datei.txt benutzer@server-ip:/tmp/
```

### 8.4 Dateien übertragen (Rsync über SSH)

Rsync ist effizienter als SCP, da es nur Änderungen überträgt:

```bash
# Verzeichnis synchronisieren
rsync -avz -e ssh ./projekt/ benutzer@server-ip:/home/benutzer/projekt/

# Mit Fortschrittsanzeige und Kompression
rsync -avz --progress -e ssh ./backup/ benutzer@server-ip:/backup/

# Mit anderem Port und Schlüssel
rsync -avz -e "ssh -p 2222 -i ~/.ssh/deploy_key" ./deploy/ deployer@server-ip:/var/www/
```

### 8.5 SFTP (Interaktiver Dateitransfer)

```bash
sftp benutzer@server-ip
```

Wichtige SFTP-Befehle:

| Befehl | Beschreibung |
|---|---|
| `ls` | Dateien auf dem Server auflisten |
| `lls` | Dateien lokal auflisten |
| `cd verzeichnis` | Auf dem Server wechseln |
| `lcd verzeichnis` | Lokal wechseln |
| `get datei` | Datei herunterladen |
| `put datei` | Datei hochladen |
| `mkdir verzeichnis` | Verzeichnis erstellen |
| `rm datei` | Datei löschen |
| `exit` | SFTP beenden |

---

## 9. SSH-Agent und Schlüsselverwaltung

### 9.1 Was ist der SSH-Agent?

Der SSH-Agent ist ein Programm, das private Schlüssel im Arbeitsspeicher hält. So muss die Passphrase nur einmal eingegeben werden, und der Agent stellt den Schlüssel bei Bedarf bereit.

### 9.2 SSH-Agent starten und Schlüssel hinzufügen

```bash
# Agent starten (falls nicht bereits aktiv)
eval "$(ssh-agent -s)"
# Ausgabe: Agent pid 12345

# Schlüssel hinzufügen (Passphrase wird einmalig abgefragt)
ssh-add ~/.ssh/id_ed25519

# Alle Schlüssel im Standard-Verzeichnis hinzufügen
ssh-add

# Geladene Schlüssel anzeigen
ssh-add -l

# Alle Schlüssel aus dem Agent entfernen
ssh-add -D
```

### 9.3 SSH-Agent automatisch starten

#### Methode A: Über die Shell-Konfiguration

```bash
nano ~/.bashrc
```

```bash
# SSH-Agent automatisch starten
if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null
    ssh-add ~/.ssh/id_ed25519 2>/dev/null
fi
```

#### Methode B: Über systemd (Linux Desktop)

```bash
mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/ssh-agent.service
```

```ini
[Unit]
Description=SSH-Agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target
```

```bash
systemctl --user enable ssh-agent
systemctl --user start ssh-agent

# In ~/.bashrc hinzufügen:
echo 'export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"' >> ~/.bashrc
```

### 9.4 Zeitlimit für Schlüssel setzen

```bash
# Schlüssel für 8 Stunden im Agent halten (danach automatisch entfernen)
ssh-add -t 28800 ~/.ssh/id_ed25519

# Standardzeit beim Agent-Start setzen (1 Stunde)
eval "$(ssh-agent -t 3600 -s)"
```

### 9.5 Agent-Forwarding (Schlüssel auf dem Server nutzen)

Agent-Forwarding erlaubt es, den lokalen SSH-Agent über eine SSH-Verbindung hinweg zu nutzen – z. B. um vom Server A auf Server B zuzugreifen, ohne den privaten Schlüssel auf Server A abzulegen.

```bash
# Verbindung mit Agent-Forwarding
ssh -A benutzer@server-a

# Auf Server A: Verbindung zu Server B funktioniert,
# weil der Agent vom lokalen Rechner weitergeleitet wird
ssh benutzer@server-b
```

In `~/.ssh/config`:

```bash
Host server-a
    HostName 192.168.1.100
    User admin
    ForwardAgent yes
```

> **Sicherheitshinweis:** Agent-Forwarding nur zu vertrauenswürdigen Servern aktivieren. Ein kompromittierter Server könnte den weitergeleiteten Agent missbrauchen.

---

## 10. Mehrstufige Absicherung (Hardening)

### 10.1 SSH-Port ändern

Das Ändern des Standard-Ports (22) reduziert automatisierte Angriffe erheblich:

```bash
sudo nano /etc/ssh/sshd_config
```

```bash
Port 2222    # Beliebiger Port zwischen 1024 und 65535
```

```bash
# Firewall-Regel anpassen (BEVOR SSH neu gestartet wird!)
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp

# SSH neu starten
sudo sshd -t && sudo systemctl restart ssh

# Verbindung testen
ssh -p 2222 benutzer@server-ip
```

> **Wichtig:** Nach dem Ändern des Ports die Firewall-Regel **vor** dem SSH-Neustart anpassen, sonst sperrt man sich aus.

### 10.2 Root-Login deaktivieren

```bash
# In /etc/ssh/sshd_config:
PermitRootLogin no
```

Stattdessen als normaler Benutzer anmelden und `sudo` verwenden:

```bash
ssh admin@server-ip
sudo -i    # Root-Shell öffnen
```

### 10.3 Zugriff auf bestimmte Benutzer beschränken

```bash
# In /etc/ssh/sshd_config:

# Nur diese Benutzer dürfen sich anmelden:
AllowUsers admin deployer

# Oder: Nur Mitglieder dieser Gruppe:
AllowGroups ssh-users
```

### 10.4 Idle-Timeout konfigurieren

```bash
# In /etc/ssh/sshd_config:
ClientAliveInterval 300     # Alle 5 Minuten Keepalive senden
ClientAliveCountMax 2       # Nach 2 fehlenden Antworten trennen
                            # → Timeout nach 10 Minuten Inaktivität
```

### 10.5 Kryptographische Algorithmen einschränken

Nur moderne, sichere Algorithmen zulassen:

```bash
# In /etc/ssh/sshd_config:

# Schlüsselaustausch
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org

# Verschlüsselung
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# MAC (Message Authentication Code)
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com

# Host-Schlüsseltypen
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
```

> **Hinweis:** Bei sehr alten Clients können eingeschränkte Algorithmen zu Verbindungsproblemen führen. In dem Fall schrittweise einschränken.

### 10.6 Banner und MOTD

```bash
# Warnbanner vor dem Login anzeigen
sudo nano /etc/ssh/banner.txt
```

```
==========================================================
  AUTORISIERTER ZUGANG ERFORDERLICH
  Unbefugter Zugriff wird strafrechtlich verfolgt.
  Alle Sitzungen werden protokolliert.
==========================================================
```

```bash
# In /etc/ssh/sshd_config:
Banner /etc/ssh/banner.txt
```

### 10.7 Firewall (UFW)

```bash
# UFW installieren und konfigurieren
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp        # SSH (oder der geänderte Port)
sudo ufw allow 80/tcp        # HTTP
sudo ufw allow 443/tcp       # HTTPS
sudo ufw enable
sudo ufw status verbose
```

### 10.8 Übersicht: Härtungsmaßnahmen

| Maßnahme | Priorität | Schwierigkeit |
|---|---|---|
| Schlüssel-Authentifizierung | **Kritisch** | Einfach |
| Passwort-Auth deaktivieren | **Kritisch** | Einfach |
| Root-Login deaktivieren | **Hoch** | Einfach |
| Fail2Ban installieren | **Hoch** | Einfach |
| Firewall (UFW) | **Hoch** | Einfach |
| SSH-Port ändern | Mittel | Einfach |
| AllowUsers/AllowGroups | Mittel | Einfach |
| Kryptographie einschränken | Mittel | Mittel |
| Idle-Timeout setzen | Niedrig | Einfach |
| Banner anzeigen | Niedrig | Einfach |

---

## 11. Fail2Ban – Brute-Force-Schutz

### 11.1 Installation

```bash
sudo apt install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
```

### 11.2 Konfiguration für SSH

```bash
sudo nano /etc/fail2ban/jail.d/ssh.local
```

```ini
[sshd]
enabled = true
port = ssh                       # Oder den geänderten Port: 2222
filter = sshd
logpath = /var/log/auth.log
backend = systemd

# Nach 3 fehlgeschlagenen Versuchen sperren
maxretry = 3

# Für 1 Stunde sperren (in Sekunden)
bantime = 3600

# Innerhalb von 10 Minuten
findtime = 600

# Wiederholte Sperren verlängern (optional)
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400          # Maximal 24 Stunden
```

### 11.3 Fail2Ban verwalten

```bash
# Status anzeigen
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Gesperrte IPs anzeigen
sudo fail2ban-client get sshd banip

# IP manuell entsperren
sudo fail2ban-client set sshd unbanip 192.168.1.50

# IP manuell sperren
sudo fail2ban-client set sshd banip 203.0.113.100

# Fail2Ban-Log anzeigen
sudo tail -f /var/log/fail2ban.log
```

### 11.4 Eigene IP vor dem Sperren schützen

```bash
sudo nano /etc/fail2ban/jail.d/ssh.local
```

```ini
[sshd]
# Eigene IPs niemals sperren
ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24 10.0.0.0/8
```

---

## 12. SSH für Dienste (Gitea, Rsync, SFTP)

### 12.1 SSH-Zugang für Gitea

Gitea nutzt SSH für Git-Operationen. Der System-SSH-Server leitet Git-Befehle an Gitea weiter.

```bash
# Gitea muss dem Systembenutzer 'git' oder 'gitea' zugeordnet sein
# Der Benutzer 'gitea' wurde bei der Gitea-Installation erstellt

# SSH-Schlüssel werden über die Gitea-Weboberfläche verwaltet
# Gitea aktualisiert die authorized_keys automatisch
cat /home/gitea/.ssh/authorized_keys
```

Benutzer hinterlegen ihre SSH-Schlüssel in Gitea unter **Einstellungen → SSH/GPG-Schlüssel** (nicht direkt auf dem Server).

### 12.2 Eingeschränkte SSH-Schlüssel (Command-Restriction)

Schlüssel können auf bestimmte Befehle beschränkt werden:

```bash
# In authorized_keys: Schlüssel mit Einschränkung
command="/usr/local/bin/backup.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3... backup@server
```

Der Schlüssel kann nur den Befehl `/usr/local/bin/backup.sh` ausführen – keine interaktive Shell, kein Port-Forwarding.

Weitere Einschränkungsoptionen:

| Option | Beschreibung |
|---|---|
| `command="befehl"` | Nur diesen Befehl ausführen |
| `no-port-forwarding` | Port-Weiterleitung verbieten |
| `no-X11-forwarding` | X11-Weiterleitung verbieten |
| `no-agent-forwarding` | Agent-Weiterleitung verbieten |
| `no-pty` | Kein Terminal zuweisen |
| `from="192.168.1.*"` | Nur von bestimmten IPs erlauben |
| `environment="VAR=wert"` | Umgebungsvariable setzen |

### 12.3 SFTP-Only-Benutzer (ohne Shell-Zugriff)

Für Benutzer, die nur Dateien übertragen dürfen:

```bash
# Benutzer erstellen
sudo adduser --shell /usr/sbin/nologin sftpbenutzer
sudo usermod -aG sftp-users sftpbenutzer

# Gruppe erstellen (falls nicht vorhanden)
sudo groupadd sftp-users
```

In `/etc/ssh/sshd_config` am Ende hinzufügen:

```bash
# SFTP-Benutzer ohne Shell-Zugang
Match Group sftp-users
    ChrootDirectory /home/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no
```

```bash
# Verzeichnisberechtigungen für Chroot (root muss Eigentümer sein!)
sudo chown root:root /home/sftpbenutzer
sudo chmod 755 /home/sftpbenutzer

# Upload-Verzeichnis, in das der Benutzer schreiben darf
sudo mkdir /home/sftpbenutzer/upload
sudo chown sftpbenutzer:sftpbenutzer /home/sftpbenutzer/upload

sudo systemctl restart ssh
```

### 12.4 Deploy Keys (für automatisierte Prozesse)

Deploy Keys sind SSH-Schlüssel ohne Passphrase, die für automatisierte Prozesse (CI/CD, Backups) verwendet werden:

```bash
# Deploy Key erstellen (ohne Passphrase)
ssh-keygen -t ed25519 -C "deploy-key@server" -f ~/.ssh/deploy_key -N ""

# Schlüssel mit Einschränkungen in authorized_keys eintragen
echo 'command="/opt/scripts/deploy.sh",no-pty,no-port-forwarding ssh-ed25519 AAAAC3...' \
  | sudo tee -a /home/deployer/.ssh/authorized_keys
```

---

## 13. SSH-Tunneling und Port-Weiterleitung

### 13.1 Lokale Port-Weiterleitung (Local Forward)

Zugriff auf einen entfernten Dienst über einen lokalen Port:

```bash
# Lokaler Port 8080 → Server-Port 80 (Webserver)
ssh -L 8080:localhost:80 benutzer@server-ip

# Jetzt erreichbar: http://localhost:8080

# Zugriff auf eine Datenbank hinter dem Server
ssh -L 5433:localhost:5432 benutzer@server-ip
# PostgreSQL lokal auf Port 5433 erreichbar
```

### 13.2 Remote Port-Weiterleitung (Remote Forward)

Einen lokalen Dienst über den Server erreichbar machen:

```bash
# Server-Port 8080 → Lokaler Port 3000
ssh -R 8080:localhost:3000 benutzer@server-ip

# Der Dienst auf localhost:3000 ist nun über server-ip:8080 erreichbar
```

### 13.3 Dynamische Port-Weiterleitung (SOCKS-Proxy)

```bash
# SOCKS5-Proxy auf Port 1080
ssh -D 1080 benutzer@server-ip

# Browser-Proxy auf localhost:1080 konfigurieren
# → Gesamter Datenverkehr wird über den Server geleitet
```

### 13.4 Tunnel im Hintergrund

```bash
# Tunnel im Hintergrund starten
ssh -f -N -L 8080:localhost:80 benutzer@server-ip

# -f : In den Hintergrund wechseln
# -N : Keinen Befehl ausführen (nur Tunnel)

# Tunnel finden und beenden
ps aux | grep "ssh -f"
kill PID
```

### 13.5 In der Config-Datei

```bash
# In ~/.ssh/config
Host db-tunnel
    HostName server.example.de
    User admin
    LocalForward 5433 localhost:5432
    LocalForward 6380 localhost:6379
```

```bash
# Tunnel starten
ssh -N db-tunnel
```

---

## 14. Schlüssel rotieren und widerrufen

### 14.1 Wann Schlüssel rotieren?

| Ereignis | Maßnahme |
|---|---|
| Mitarbeiter verlässt das Team | Schlüssel sofort widerrufen |
| Gerät verloren oder gestohlen | Schlüssel sofort widerrufen |
| Schlüssel kompromittiert | Alle betroffenen Schlüssel sofort rotieren |
| Regelmäßige Rotation | Alle 12 Monate empfohlen |
| Schwacher Schlüsseltyp (DSA, RSA < 2048) | Sofort durch Ed25519 ersetzen |

### 14.2 Neuen Schlüssel erstellen und alten ersetzen

```bash
# 1. Neuen Schlüssel erstellen (auf dem Client)
ssh-keygen -t ed25519 -C "benutzer@firma.de-2025" -f ~/.ssh/id_ed25519_neu

# 2. Neuen Schlüssel auf den Server übertragen
ssh-copy-id -i ~/.ssh/id_ed25519_neu.pub benutzer@server-ip

# 3. Testen, ob der neue Schlüssel funktioniert
ssh -i ~/.ssh/id_ed25519_neu benutzer@server-ip

# 4. Alten Schlüssel vom Server entfernen
ssh benutzer@server-ip
nano ~/.ssh/authorized_keys
# → Alte Schlüsselzeile löschen

# 5. Lokal den neuen Schlüssel als Standard setzen
mv ~/.ssh/id_ed25519 ~/.ssh/id_ed25519_alt
mv ~/.ssh/id_ed25519_neu ~/.ssh/id_ed25519
mv ~/.ssh/id_ed25519_neu.pub ~/.ssh/id_ed25519.pub
```

### 14.3 Schlüssel widerrufen (sofort)

```bash
# Auf dem Server: Schlüssel aus authorized_keys entfernen
sudo nano /home/benutzer/.ssh/authorized_keys
# → Die Zeile mit dem Fingerprint des widerrufenen Schlüssels löschen

# Fingerprint des zu widerrufenden Schlüssels prüfen
ssh-keygen -l -f /home/benutzer/.ssh/authorized_keys
```

### 14.4 Alle Sitzungen eines Benutzers sofort beenden

```bash
# Alle SSH-Sitzungen eines Benutzers finden
ps aux | grep "sshd:.*benutzer"

# Sitzungen beenden
sudo pkill -u benutzer sshd

# Oder einzeln per PID
sudo kill PID
```

### 14.5 Host Keys rotieren

Falls der Server kompromittiert wurde, müssen auch die Host Keys erneuert werden:

```bash
# Alte Host Keys sichern
sudo cp /etc/ssh/ssh_host_* /etc/ssh/backup/

# Neue Host Keys generieren
sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -A

# SSH neu starten
sudo systemctl restart ssh
```

> **Hinweis:** Nach der Rotation der Host Keys müssen alle Clients ihren Eintrag in `~/.ssh/known_hosts` aktualisieren. Beim nächsten Verbindungsversuch erscheint eine Warnung.

Client-seitig den alten Host Key entfernen:

```bash
ssh-keygen -R server-ip
# oder
ssh-keygen -R server.example.de
```

---

## 15. Fehlerbehebung

### 15.1 Verbose-Modus verwenden

```bash
# Client-seitig: Detaillierte Verbindungsinformationen
ssh -vvv benutzer@server-ip
```

Typische Hinweise in der Ausgabe:

| Meldung | Bedeutung |
|---|---|
| `Offering public key: ...` | Client bietet Schlüssel an |
| `Server accepts key: ...` | Server akzeptiert den Schlüssel |
| `No more authentication methods` | Kein Schlüssel wurde akzeptiert |
| `Permission denied (publickey)` | Schlüssel-Auth fehlgeschlagen |
| `Connection refused` | SSH-Dienst nicht erreichbar |

### 15.2 Häufige Probleme und Lösungen

#### Problem: „Permission denied (publickey)"

```bash
# 1. Berechtigungen auf dem Server prüfen
ssh benutzer@server-ip  # Falls Passwort-Auth noch aktiv
ls -la ~/.ssh/
# authorized_keys muss 600 sein, .ssh muss 700 sein

# 2. Berechtigungen reparieren
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $(whoami):$(whoami) ~/.ssh

# 3. Ist der Schlüssel in authorized_keys vorhanden?
cat ~/.ssh/authorized_keys

# 4. Server-Log prüfen
sudo tail -50 /var/log/auth.log | grep ssh

# 5. SELinux/AppArmor-Kontext prüfen (falls aktiv)
restorecon -rv ~/.ssh
```

#### Problem: „Connection refused"

```bash
# SSH-Dienst prüfen
sudo systemctl status ssh

# Port prüfen
sudo ss -tlnp | grep sshd

# Firewall prüfen
sudo ufw status

# SSH-Dienst starten
sudo systemctl start ssh
```

#### Problem: „Host key verification failed"

```bash
# Der Server hat einen neuen Host Key (z. B. nach Neuinstallation)
# Alten Eintrag entfernen:
ssh-keygen -R server-ip

# Oder die gesamte known_hosts-Datei bereinigen:
nano ~/.ssh/known_hosts
# → Zeile mit dem betroffenen Server löschen
```

#### Problem: „WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"

Diese Warnung bedeutet, dass der Host Key des Servers sich geändert hat. Das kann auf eine Neuinstallation hindeuten – oder auf einen Man-in-the-Middle-Angriff.

```bash
# Wenn die Änderung erwartet ist (Neuinstallation, neue IP):
ssh-keygen -R server-ip

# Wenn unerwartet: NICHT verbinden und den Server-Administrator kontaktieren
```

#### Problem: „Too many authentication failures"

```bash
# Tritt auf, wenn der Client zu viele Schlüssel anbietet
# Lösung: Schlüssel explizit angeben
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 benutzer@server-ip

# Dauerhaft in ~/.ssh/config:
Host server
    IdentitiesOnly yes
    IdentityFile ~/.ssh/id_ed25519
```

#### Problem: Schlüssel hat Passphrase, Automatisierung schlägt fehl

```bash
# SSH-Agent starten und Schlüssel laden
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Prüfen, ob der Schlüssel geladen ist
ssh-add -l
```

### 15.3 Server-seitiges Debugging

```bash
# SSH-Server im Debug-Modus auf einem alternativen Port starten
sudo /usr/sbin/sshd -d -p 2222

# Vom Client aus verbinden
ssh -p 2222 -v benutzer@server-ip

# Die Server-Konsole zeigt detaillierte Informationen
```

### 15.4 Authentifizierungslog prüfen

```bash
# Letzte Anmeldeversuche anzeigen
sudo tail -100 /var/log/auth.log | grep sshd

# Fehlgeschlagene Anmeldungen
sudo grep "Failed" /var/log/auth.log | tail -20

# Erfolgreiche Anmeldungen
sudo grep "Accepted" /var/log/auth.log | tail -20

# Alle SSH-bezogenen Einträge (systemd)
sudo journalctl -u ssh --no-pager -n 50
```

---

## 16. Schnellreferenz – Befehle auf einen Blick

### Schlüsselverwaltung

```bash
# Schlüssel erstellen
ssh-keygen -t ed25519 -C "kommentar"
ssh-keygen -t rsa -b 4096 -C "kommentar"

# Schlüssel auf Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server

# Fingerprint anzeigen
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

# Passphrase ändern
ssh-keygen -p -f ~/.ssh/id_ed25519

# Öffentlichen Schlüssel aus privatem ableiten
ssh-keygen -y -f ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.pub
```

### SSH-Agent

```bash
eval "$(ssh-agent -s)"              # Agent starten
ssh-add ~/.ssh/id_ed25519           # Schlüssel hinzufügen
ssh-add -l                          # Geladene Schlüssel anzeigen
ssh-add -t 3600 ~/.ssh/id_ed25519  # Schlüssel mit Zeitlimit
ssh-add -D                          # Alle Schlüssel entfernen
```

### Verbindungen

```bash
ssh benutzer@server                  # Verbinden
ssh -p 2222 benutzer@server         # Anderer Port
ssh -i ~/.ssh/key benutzer@server   # Bestimmter Schlüssel
ssh -v benutzer@server              # Debug-Modus
ssh benutzer@server "befehl"        # Remote-Befehl
```

### Dateitransfer

```bash
# SCP
scp datei benutzer@server:/pfad/    # Upload
scp benutzer@server:/pfad/datei .   # Download
scp -r verz benutzer@server:/pfad/  # Verzeichnis

# Rsync
rsync -avz -e ssh quelle/ benutzer@server:/ziel/
```

### Tunnel

```bash
ssh -L lokal:host:remote user@srv   # Lokaler Tunnel
ssh -R remote:host:lokal user@srv   # Remote Tunnel
ssh -D 1080 user@srv                # SOCKS-Proxy
ssh -f -N -L 8080:localhost:80 u@s  # Hintergrund-Tunnel
```

### Server-Administration

```bash
# Dienst
sudo systemctl start ssh
sudo systemctl stop ssh
sudo systemctl restart ssh
sudo systemctl status ssh

# Konfiguration
sudo sshd -t                        # Syntax prüfen
sudo nano /etc/ssh/sshd_config      # Bearbeiten

# Logs
sudo tail -f /var/log/auth.log
sudo journalctl -u ssh -f

# Fail2Ban
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip IP
```

### Berechtigungsreferenz

```bash
# Client-Seite
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519          # Privater Schlüssel
chmod 644 ~/.ssh/id_ed25519.pub      # Öffentlicher Schlüssel
chmod 600 ~/.ssh/config              # Config-Datei

# Server-Seite
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R benutzer:benutzer ~/.ssh
```

### Wichtige Dateipfade

```
Client-Seite:
~/.ssh/
├── id_ed25519                # Privater Schlüssel
├── id_ed25519.pub            # Öffentlicher Schlüssel
├── config                    # Client-Konfiguration
└── known_hosts               # Bekannte Server-Fingerprints

Server-Seite:
/etc/ssh/
├── sshd_config               # Server-Hauptkonfiguration
├── sshd_config.d/            # Zusätzliche Konfiguration (Override)
├── ssh_host_ed25519_key      # Server-Host-Key (privat)
├── ssh_host_ed25519_key.pub  # Server-Host-Key (öffentlich)
├── ssh_host_rsa_key          # RSA-Host-Key (privat)
└── banner.txt                # Login-Banner (optional)

Benutzer (Server):
~/.ssh/
└── authorized_keys           # Erlaubte öffentliche Schlüssel
```

### Ablauf: Neuen Benutzer einrichten (Zusammenfassung)

```bash
# 1. Auf dem CLIENT: Schlüssel erstellen
ssh-keygen -t ed25519 -C "name@firma.de"

# 2. Auf dem SERVER: Benutzer erstellen
sudo adduser neuerbenutzer
sudo usermod -aG ssh-users neuerbenutzer

# 3. Schlüssel übertragen (Client → Server)
ssh-copy-id neuerbenutzer@server-ip

# 4. Testen
ssh neuerbenutzer@server-ip

# 5. Optional: sudo-Rechte vergeben
sudo usermod -aG sudo neuerbenutzer
```

---

> **Letzte Aktualisierung:** *24.02.2026*
> **Autor:** *Administrator*
> **Version:** 1.0