Files

Administrator 18a20881b0 docs: update IT_Abteilung/Security/SSH

2026-02-24 08:32:28 +00:00

43 KiB

Raw Blame History

title, description, published, date, tags, editor, dateCreated

title	description	published	date	tags	editor	dateCreated
SSH server access Dokumentation		true	2026-02-24T08:32:26.878Z		markdown	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

Überblick und Funktionsweise
SSH-Server installieren und absichern
SSH-Schlüsselpaare erstellen
Schlüssel auf den Server übertragen
Passwort-Authentifizierung deaktivieren
Benutzer verwalten
SSH-Client-Konfiguration
Verbindung herstellen und nutzen
SSH-Agent und Schlüsselverwaltung
Mehrstufige Absicherung (Hardening)
Fail2Ban – Brute-Force-Schutz
SSH für Dienste (Gitea, Rsync, SFTP)
SSH-Tunneling und Port-Weiterleitung
Schlüssel rotieren und widerrufen
Fehlerbehebung
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

@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:

Der Client baut eine TCP-Verbindung zum SSH-Server auf (Standard: Port 22)
Der Server sendet seinen Host Key zur Identifikation
Der Client prüft, ob er diesen Server kennt (Datei ~/.ssh/known_hosts)
Der Server sendet eine zufällige Challenge (Zufallsdaten)
Der Client signiert diese Challenge mit seinem privaten Schlüssel
Die Signatur wird an den Server zurückgesendet
Der Server prüft die Signatur mit dem öffentlichen Schlüssel aus authorized_keys
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

# 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

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:

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

Empfohlene Basiskonfiguration:

# ===========================================================
#  /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

# 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)

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)

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

Mit benutzerdefiniertem Dateinamen

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

# 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 ö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)

PuTTYgen öffnen
Schlüsseltyp: EdDSA (Ed25519) oder RSA (4096 Bit)
Generate klicken und Maus bewegen
Passphrase eingeben
Save private key (.ppk-Datei)
Ö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:

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

Dieser Befehl:

Verbindet sich per Passwort mit dem Server
Erstellt ~/.ssh/authorized_keys falls nicht vorhanden
Fügt den öffentlichen Schlüssel hinzu
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:

# Ö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)

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

# 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

# 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!)

# 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

sudo nano /etc/ssh/sshd_config

Folgende Zeilen ändern:

# 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:

# 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

# 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)

# 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)

# 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

# Ö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):

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

6.2 Sudo-Rechte vergeben

# 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:

# 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:

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

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

# 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

# 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):

# 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.

nano ~/.ssh/config

# ===========================================================
#  ~/.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

# 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

chmod 600 ~/.ssh/config

8. Verbindung herstellen und nutzen

8.1 Einfache Verbindung

# 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

# 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)

# 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:

# 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)

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

# 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

nano ~/.bashrc

# 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)

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

[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

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

# 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.

# 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:

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:

sudo nano /etc/ssh/sshd_config

Port 2222    # Beliebiger Port zwischen 1024 und 65535

# 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.

# In /etc/ssh/sshd_config:
PermitRootLogin no

Stattdessen als normaler Benutzer anmelden und sudo verwenden:

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

10.3 Zugriff auf bestimmte Benutzer beschränken

# 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

# 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:

# 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

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

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

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

10.7 Firewall (UFW)

# 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

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

11.2 Konfiguration für SSH

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

[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

# 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

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

[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.

# 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:

# 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:

# 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:

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

# 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:

# 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:

# 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:

# 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)

# 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

# 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

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

# 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

# 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)

# 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

# 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:

# 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:

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

15. Fehlerbehebung

15.1 Verbose-Modus verwenden

# 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)"

# 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"

# 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"

# 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.

# 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"

# 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

# 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

# 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

# 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

# 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

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

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

# 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

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

# 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

# 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)

# 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

43 KiB Raw Blame History Unescape Escape