1639 lines
43 KiB
Markdown
1639 lines
43 KiB
Markdown
---
|
||
title: SSH server access Dokumentation
|
||
description:
|
||
published: true
|
||
date: 2026-02-24T08:32:26.878Z
|
||
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
|