SSH: Transport, Identitäten und sichere Administration

Secure Shell ist eine Protokollfamilie für sicheren Fernzugriff über ein unsicheres Netz. SSH verbindet drei Aufgaben: Es baut einen verschlüsselten und integritätsgeschützten Transport auf, authentisiert zuerst den Server und danach den Benutzer oder Workload und multiplexiert schliesslich Shells, einzelne Kommandos, Subsysteme und Weiterleitungen als getrennte Channels. Diese Reihenfolge ist für Admins entscheidend: Ein starker Benutzerschlüssel schützt nicht, wenn der Client ihn einem nicht verifizierten Server anbietet.

SSH ist zugleich Protokoll und Control Plane. Ein Zugang kann Rootbefehle, Dateitransfer, Datenbanktunnel, Agentzugriff und Sprungwege in interne Netze ermöglichen. Die Sicherheitsbewertung darf deshalb nicht beim Listenerport oder bei PasswordAuthentication no enden. Host-Key-Verteilung, effektive Match-Policy, Schlüsselherkunft, Principals, Forwardingrechte, Quellpfad, Sessionlogging und Recovery der Vertrauensanker gehören zum selben System.

Die Erklärung folgt einer SSH-Verbindung von TCP und Versionsaustausch über Schlüsselaushandlung und Hostprüfung bis zur Benutzeranmeldung und zum Channel. Weiterleitungen, Schlüsselbetrieb, Zertifikate und Diagnose bauen darauf auf.

SSH baut aus einer unsicheren Netzwerkverbindung einen authentisierten, verschlüsselten Transport und darin getrennte Kanäle für Shell, Befehle, Dateitransfer oder Tunnels. Der Artikel folgt genau dieser Reihenfolge: Serveridentität, Schlüsselaustausch, Benutzeranmeldung, Kanäle und Betrieb.

Protokollarchitektur

RFC 4251 gliedert SSH-2 in drei Protokolle:

1. Transport Layer Protocol: Versionsaustausch, Algorithmusverhandlung, Key Exchange, Serverauthentisierung, Verschlüsselung und Integrität.
2. User Authentication Protocol: Authentisierung eines Clientbenutzers gegenüber dem Server über dem geschützten Transport.
3. Connection Protocol: Multiplexing logischer Channels für Sessions, Port Forwarding und weitere Dienste.

Die Schichten laufen über einen zuverlässigen Bytestream, gewöhnlich TCP. TCP-Port 22 ist bei IANA als ssh registriert; Reverse Proxies, Portweiterleitungen und Bastions können den tatsächlichen Pfad verändern (RFC 4251 – SSH Protocol Architecture, IANA Service Name and Port Number Registry).

Versionsaustausch und Algorithmusverhandlung

Client und Server senden zunächst Identifikationsstrings wie SSH-2.0-.... Danach tauschen sie SSH_MSG_KEXINIT mit geordneten Listen für Key Exchange, Host-Key-Algorithmus, Verschlüsselung in beide Richtungen, MAC, Kompression und Sprache aus. Die erste gemeinsame Option je Kategorie wird gewählt. Algorithmuslisten sind daher Policy und Kompatibilitätsvertrag, nicht nur Implementierungsdetail (RFC 4253 – SSH Transport Layer Protocol).

RFC 9142 aktualisiert Empfehlungen für SSH-Algorithmen. Es unterscheidet MUST, SHOULD, MAY, SHOULD NOT und MUST NOT für Implementierungen; eine produktive Policy berücksichtigt zusätzlich Compliance, Clientbestand, Hardware und Migrationsweg (RFC 9142 – Key Exchange Method Recommendations for SSH).

Konfigurationszeilen, die eine starre eigene Cipherliste festschreiben, veralten. OpenSSH kann seine unterstützten Algorithmen mit ssh -Q ausgeben und die effektiv aufgelöste Client- beziehungsweise Serverkonfiguration anzeigen. Betreiber entfernen bekannte Legacyverfahren gezielt, behalten aber einen getesteten Kompatibilitätspfad für Appliances.

Key Exchange und Session Keys

Der Key Exchange erzeugt ein gemeinsames Geheimnis und einen Exchange Hash, ohne den Sitzungsschlüssel über das Netz zu senden. Der Hash bindet Identifikationsstrings, KEXINIT-Nachrichten, Serverhostkey und algorithmusspezifische Ephemeralwerte. Der Server signiert den Exchange Hash mit seinem Hostschlüssel; der Client prüft damit Serveridentität und Schlüsselaustausch gemeinsam (RFC 4253).

Moderne Verfahren verwenden ephemeral Diffie-Hellman-Varianten und bieten Forward Secrecy für Sitzungsschlüssel. SSH kann während einer Verbindung rekeyen, etwa nach Datenmenge oder Zeit. Rekey und Connection Channels teilen denselben Transport; Probleme erscheinen daher als Freeze oder Disconnect scheinbar aktiver Sessions.

RFC 8308 definiert eine generische Extension Negotiation. OpenSSH nutzt Erweiterungen unter anderem, um Server-Signaturalgorithmen oder Hostkeyupdates bekannt zu geben (RFC 8308 – Extension Negotiation in SSH). Strict Key Exchange schützt die anfängliche Sequenz stärker gegen unerwartete Nachrichten und wurde nach der Terrapin-Analyse standardisiert (RFC 9519 – Strict Key Exchange in SSH).

Nach Versions- und Algorithmuswahl muss zuerst der Client den Server erkennen. Erst wenn der Host Key akzeptiert ist, ergibt die anschliessende Benutzeranmeldung Sinn.

Host Keys: Serveridentität vor Benutzeridentität

Der Host Key identifiziert den Server oder eine kontrollierte Servergruppe. Beim ersten Kontakt besitzt ein Client ohne vorverteilten Trust Anchor keine kryptografische Grundlage, um den angezeigten Fingerprint zu beurteilen. «Accept new» automatisiert Pinning für neue Hosts, löst aber nicht die sichere Erstverteilung.

OpenSSH speichert bekannte Schlüssel und Marker in known_hosts. Ein geänderter Schlüssel kann legitime Rotation, Neuinstallation, geänderten Load-Balancer-Pool oder einen Angriff bedeuten. Die Warnung wird nicht mit blindem Löschen der Zeile «behoben»; der neue Schlüssel wird über eine unabhängige Quelle geprüft und die Ursache dokumentiert (ssh(1) – host key verification, sshd(8)).

Trustmodelle für Hostidentität

RFC 4255 definiert SSHFP-Records; ohne DNSSEC können sie nur Hinweis, nicht alleiniger Vertrauensanker sein (RFC 4255 – SSHFP Resource Records). OpenSSH-Zertifikate binden Public Key, Seriennummer, Typ, Principals, Gültigkeit, Critical Options und Extensions durch eine CA-Signatur (IETF-Draft – OpenSSH Certificate Format).

Resolve-DnsName $env:SSH_HOST -Type SSHFP -DnssecOk
ssh-keyscan -t ed25519,rsa $env:SSH_HOST | Set-Content .\\hostkeys.candidate
ssh-keygen -lf .\\hostkeys.candidate
ssh-keygen -F $env:SSH_HOST

dig +dnssec "$SSH_HOST" SSHFP
ssh-keyscan -t ed25519,rsa "$SSH_HOST" > hostkeys.candidate
ssh-keygen -lf hostkeys.candidate
ssh-keygen -F "$SSH_HOST"

Resolve-DnsName und dig lesen DNS; ssh-keyscan sammelt angebotene Schlüssel, authentisiert sie aber nicht. ssh-keygen berechnet Fingerprints und durchsucht known_hosts. Kandidaten werden erst nach unabhängiger Verifikation übernommen.

Host-Key-Lifecycle und Rotation

Ein Server kann mehrere Host Keys für unterschiedliche Algorithmen besitzen. Private Host Keys liegen nur auf Servern oder kontrollierten Load-Balancerkomponenten; Backups und Klone dürfen nicht zu unbeabsichtigter gemeinsamer Identität führen. Bei Autoscaling eignet sich eine Host-CA häufig besser als kopierte private Host Keys.

Eine Rotation umfasst:

1. neuen Schlüssel oder neues Hostzertifikat erzeugen und schützen;
2. parallel anbieten und Fingerprint/CA-Vertrauen verteilen;
3. reale Clientkompatibilität und Hostprincipal prüfen;
4. alten Schlüssel kontrolliert entfernen;
5. Inventar, Revocation und Break-Glass-Dokumentation aktualisieren.

OpenSSH kann zusätzliche Host Keys nach erfolgreicher Authentisierung über UpdateHostKeys bekannt machen. Das erleichtert Rotation, setzt aber voraus, dass der bestehende Hosttrust bereits korrekt ist (ssh_config(5)).

Mit geschütztem Transport und bestätigtem Server beginnt die Benutzer- oder Maschinenanmeldung. Passwort, Public Key, Zertifikat und weitere Verfahren haben dabei unterschiedliche Betriebs- und Recoveryanforderungen.

User Authentication Protocol

Nach dem Transport fordert der Client den Service ssh-userauth an. RFC 4252 definiert die Methoden publickey, password, hostbased und none; Keyboard-Interactive ist in RFC 4256 spezifiziert. Der Server kann weitere Authentisierung verlangen und meldet zulässige nächste Methoden (RFC 4252 – SSH Authentication Protocol, RFC 4256 – Keyboard Interactive Authentication).

Authentisierungsmethode und Autorisierung sind getrennt. Ein gültiger Public Key kann durch authorized_keys, Directoryservice, AuthorizedKeysCommand, Zertifikatsprincipals oder PAM einem Konto zugeordnet werden. Danach bestimmen Unixrechte, sudo, SELinux/AppArmor, Windows Token und Anwendungspolicy die wirksamen Rechte.

OpenSSH AuthenticationMethods kann Kombinationen wie publickey,keyboard-interactive:pam erzwingen. Ob das zwei unabhängige Faktoren sind, hängt von Credentialquellen und Gerätebindung ab. Zwei Methoden, die beide aus demselben kompromittierten Laptopagenten kommen, bieten weniger Unabhängigkeit als ihr Syntaxbild vermuten lässt (sshd_config(5)).

Public-Key-Verfahren und Schlüsseltypen

Bei Public-Key-Authentisierung sendet der Client eine Signatur über Sessionidentifier und Authrequest; der private Schlüssel verlässt den Client nicht. Der Server prüft Public Key, Signatur und Autorisierung. RFC 8332 definiert RSA-Signaturen mit SHA-2 für SSH; der Keytyp ssh-rsa bezeichnet historisch auch SHA-1-Signatursemantik und darf nicht mit jeder Verwendung eines RSA-Schlüssels gleichgesetzt werden (RFC 8332 – RSA Keys with SHA-2 Signatures).

RFC 8709 standardisiert Ed25519 und Ed448 für SSH. OpenSSH unterstützt zusätzlich FIDO/U2F-basierte sk--Schlüssel, bei denen der private Schlüssel an einen Security Key gebunden ist und optional Benutzerpräsenz oder -verifikation verlangt (RFC 8709 – Ed25519 and Ed448 for SSH, OpenSSH FIDO/U2F support).

Die Wahl folgt Client-/Serverkompatibilität und Bedrohungsmodell. Schlüssellänge allein entscheidet nicht über Sicherheit: private Speicherung, Passphrase, Agentzugriff, Gültigkeit, Principal, Revocation und Autorisierungsoptionen sind ebenso wichtig.

ssh-keygen -t ed25519 -a 64 -f $env:USERPROFILE\\.ssh\\id_admin_ed25519
ssh-keygen -lf $env:USERPROFILE\\.ssh\\id_admin_ed25519.pub
Get-Service ssh-agent
ssh-add -l
ssh-add -T $env:USERPROFILE\\.ssh\\id_admin_ed25519.pub

ssh-keygen -t ed25519 -a 64 -f "$HOME/.ssh/id_admin_ed25519"
ssh-keygen -lf "$HOME/.ssh/id_admin_ed25519.pub"
ssh-add -l
ssh-add -T "$HOME/.ssh/id_admin_ed25519.pub"
ssh-keygen -y -f "$HOME/.ssh/id_admin_ed25519" | diff - "$HOME/.ssh/id_admin_ed25519.pub"

ssh-add verwaltet Identitäten im Agenten und kann Signierfähigkeit eines Public Keys testen. Get-Service zeigt den Windows-Agentdienst. Private Schlüsseldateien und Agentensockets erhalten minimale ACLs; Beispiele erzeugen keine zentralen CA- oder Hostschlüssel.

authorized_keys als Policyobjekt

Eine Zeile in authorized_keys kann vor dem Key Optionen tragen. from=, command=, restrict, no-port-forwarding, no-agent-forwarding, no-X11-forwarding, no-pty, permitopen= und environment= begrenzen die Nutzung. restrict setzt ein defensives Optionsbündel; explizite Freigaben können folgen (sshd(8) – AUTHORIZED_KEYS FILE FORMAT).

Ein Schlüssel für Backup oder Deployment erhält keinen generischen Shellzugang. Er wird an Quellnetz, erzwungenes Kommando und benötigte Forwardingziele gebunden. Wrapper validieren Argumente als strukturierte Eingabe und verwenden keine ungeprüfte Shellkonkatenation.

authorized_keys ist verteilte Konfiguration. Inventar umfasst Fingerprint, Besitzer, Zweck, Zielkonten, Quelle, Ablauf, letzte Nutzung und Widerruf. Verwaiste Schlüssel sind langlebige Credentials ohne zentrale Sicht.

OpenSSH-Zertifikate und Principals

OpenSSH-Zertifikate sind keine X.509-Zertifikate. Eine SSH-CA signiert einen Public Key mit Seriennummer, Key ID, Typ, Principals und Gültigkeitsfenster. User Certificates authentisieren Benutzer gegenüber Servern; Host Certificates Server gegenüber Clients. Critical Options müssen verstanden werden, sonst wird das Zertifikat abgelehnt; Extensions gewähren Funktionen wie PTY oder Forwarding (IETF-Draft – OpenSSH Certificate Format).

Zertifikate verkürzen Credentiallebensdauer und zentralisieren Issuance, beseitigen aber keine Autorisierung. Server legen mit TrustedUserCAKeys und Authorized Principals fest, welche CA und Principals für welches Konto gelten. Clients binden eine Host-CA in known_hosts mit @cert-authority an Namensmuster.

ssh-keygen -L -f $env:USERPROFILE\\.ssh\\id_admin_ed25519-cert.pub
ssh-keygen -lf $env:USERPROFILE\\.ssh\\id_admin_ed25519-cert.pub
ssh -G $env:SSH_ALIAS | Select-String 'hostname|user|identityfile|certificatefile|proxyjump'
ssh -vvv $env:SSH_ALIAS

ssh-keygen -L -f "$HOME/.ssh/id_admin_ed25519-cert.pub"
ssh-keygen -lf "$HOME/.ssh/id_admin_ed25519-cert.pub"
ssh -G "$SSH_ALIAS" | grep -E '^(hostname|user|identityfile|certificatefile|proxyjump) '
ssh -vvv "$SSH_ALIAS"

grep und Select-String filtern nur die effektive Clientkonfiguration. Debugausgabe von ssh -vvv kann Benutzernamen, Pfade, Zielinfrastruktur und angebotene Fingerprints enthalten und wird als sensitives Diagnoseartefakt behandelt.

ssh-agent und Agent Forwarding

Ein Agent hält private Schlüssel oder Signierhandles entsperrt und beantwortet Signaturanfragen über einen lokalen Socket. Prozesse mit Zugriff auf diesen Socket können den Agenten missbrauchen, ohne den Private Key zu exportieren. Passphrase und Hardwarekey begrenzen daher nicht jede Agentenkompromittierung.

Agent Forwarding reicht den Agentenkanal an einen entfernten Host weiter. Root oder ein kompromittierter Prozess auf diesem Host kann während der Session Signaturanfragen stellen. OpenSSH warnt ausdrücklich vor diesem Risiko; ProxyJump transportiert die Verbindung durch eine Bastion, ohne den Agentensocket dort bereitzustellen (ssh(1) – -A and -J).

Wenn ein Ziel nur über einen Jump Host erreichbar ist, sind bevorzugte Modelle:

• ProxyJump/ProxyCommand ohne Credentialablage auf der Bastion;
• kurzlebige SSH-Zertifikate mit zielbezogenen Principals;
• separater Schlüssel pro Vertrauensraum;
• kontrolliertes Session Brokering mit Audit, falls Interaktivität zentral vermittelt werden muss.

Nach erfolgreicher Anmeldung öffnet SSH logische Channels innerhalb derselben Verbindung. Shell, einzelner Befehl, SFTP und Port Forwarding teilen dadurch Transport und Identität, bleiben aber getrennte Operationen.

Connection Protocol und Channels

Nach erfolgreicher Authentisierung öffnet SSH logische Channels. RFC 4254 definiert Windowing, Channeldaten, Requests und Typen. Eine Session kann ein PTY, eine Shell, ein einzelnes exec-Kommando oder ein Subsystem wie SFTP anfordern. TCP Forwarding öffnet direct-tcpip- oder forwarded-tcpip-Channels (RFC 4254 – SSH Connection Protocol).

Multiplexing erlaubt mehreren Clientverbindungen, einen bestehenden Transport zu teilen. Das reduziert KEX- und Authkosten, vergrössert aber die Wirkung eines kompromittierten Control Sockets. ControlPath, Berechtigungen, Persistenz und Zielbindung werden explizit gesetzt.

Keepalives besitzen verschiedene Ebenen: TCPKeepAlive prüft den TCP-Pfad, ServerAliveInterval/ClientAliveInterval verwenden SSH-Nachrichten. Sie verhindern keine Anwendungshänger und können durch aggressive Werte Sessions bei kurzen Netzunterbrüchen beenden.

Port Forwarding und Vertrauensgrenzen

Local Forwarding (-L) öffnet einen Listener auf der Clientseite und verbindet vom Servernetz zum Ziel. Remote Forwarding (-R) öffnet einen Listener auf Server- oder Gegenseite. Dynamic Forwarding (-D) bietet einen SOCKS-Proxy. Unix-Socket-/Streamlocal-Forwarding ergänzt TCP.

Forwarding kann Segmentierung umgehen. Ein Benutzer ohne Shellprivilegien kann über eine erlaubte Weiterleitung dennoch interne Admininterfaces oder Datenbanken erreichen. Server steuern dies mit AllowTcpForwarding, PermitOpen, PermitListen, GatewayPorts, Match-Blöcken und Authorized-Key-Optionen (sshd_config(5)).

Test-NetConnection $env:BASTION_HOST -Port $env:SSH_PORT
ssh -J $env:BASTION_ALIAS -N -L 127.0.0.1:8443:$env:INTERNAL_HOST:443 $env:TARGET_ALIAS
Get-NetTCPConnection -LocalPort 8443 -State Listen
ssh -O check $env:TARGET_ALIAS

nc -vz "$BASTION_HOST" "$SSH_PORT"
ssh -J "$BASTION_ALIAS" -N -L "127.0.0.1:8443:$INTERNAL_HOST:443" "$TARGET_ALIAS"
ss -lntp 'sport = :8443'
ssh -O check "$TARGET_ALIAS"

Test-NetConnection und nc prüfen den TCP-Pfad zur Bastion. Get-NetTCPConnection und ss bestätigen den lokalen Listener. Der -N-Tunnel führt kein Remotecommand aus; Autorisierung und Ziel-TLS bleiben eigenständige Grenzen.

SFTP, SCP und Dateirechte

SFTP ist ein binäres Dateitransferprotokoll, das üblicherweise als SSH-Subsystem läuft. Es ist nicht FTP über SSH. OpenSSH kann internal-sftp ohne externes SFTP-Serverbinary ausführen und über ChrootDirectory plus ForceCommand internal-sftp auf Dateitransfer begrenzen (sftp(1), sftp-server(8)).

Die scp-CLI verwendete historisch das SCP/RCP-artige Remoteprotokoll und verwendet in modernen OpenSSH-Linien standardmässig SFTP; -O erzwingt das Legacyprotokoll. Wildcards, Remote-Shellverarbeitung und Serverkompatibilität unterscheiden sich (scp(1)). Runbooks nennen daher CLI, Protokollmodus und gewünschte Dateimetadaten explizit.

Dateitransferautorisierung umfasst Chrootbesitz, Zielpfade, UID/GID beziehungsweise Windows-ACLs, Umask, Symlinks, Quota und atomare Ablage. Upload in ein Mail- oder Automationsverzeichnis benötigt häufig eine Quarantäne-/Renamegrenze statt direkter Verarbeitung teilweise geschriebener Dateien.

Serverseitige Policy und Match-Blöcke

sshd_config wird von oben nach unten ausgewertet; für jedes Schlüsselwort gilt grundsätzlich der erste erhaltene Wert. Match ändert den Geltungsbereich nach Benutzer, Gruppe, Host, Adresse, LocalAddress, LocalPort oder RDomain. Include-Dateien, Distributiondefaults und Kommandozeilenoptionen können die sichtbare Hauptdatei ergänzen (sshd_config(5)).

Eine belastbare Baseline legt fest:

• erlaubte Benutzer/Groups und Quellnetze;
• benötigte Authmethoden und Break-Glass-Ausnahme;
• Root-/Administratorzugriff und Privilege Escalation;
• Forwarding, Agent, X11, PTY und Subsysteme;
• MaxAuthTries, LoginGraceTime, Session-/Startlimits und Keepalives;
• Host Keys, Algorithmen und Rekey;
• AuthorizedKeys/Principals-Quellen;
• Logging, Banner und Umgebungsannahme;
• Match-spezifische Abweichungen.

Pauschale «Härtungslisten» können Appliances aussperren oder wirkungslos sein, wenn ein später angenommener Matchwert anders greift. Entscheidend ist die effektive Konfiguration für eine konkrete Verbindung.

sshd.exe -t
sshd.exe -T -C user=$env:SSH_USER,host=$env:SSH_HOST,addr=$env:CLIENT_IP
Get-NetTCPConnection -LocalPort $env:SSH_PORT -State Listen
Get-WinEvent -LogName OpenSSH/Operational -MaxEvents 100

sshd -t
sshd -T -C "user=$SSH_USER,host=$SSH_HOST,addr=$CLIENT_IP"
ss -lntp "sport = :$SSH_PORT"
journalctl --unit ssh --unit sshd --since '-60 minutes' --no-pager

sshd -t validiert Syntax und Schlüssel, sshd -T -C gibt die effektive Konfiguration für Testparameter aus (sshd(8)). Get-WinEvent und journalctl lesen die Plattformlogs. Ein erfolgreicher Reload und eine zweite getestete Adminsession gehen dem Schliessen der bestehenden Session voraus.

Brute Force, Rate Limits und Netzgrenzen

Internetexponierte SSH-Dienste erhalten automatisierte Loginversuche. Quellfirewall, VPN/Zero-Trust-Zugang, Bastion, AllowUsers/AllowGroups, starke Authentisierung und kurze Credentiallebensdauer reduzieren die Angriffsfläche. Ein anderer Port verringert Lograuschen, ändert aber weder Authentisierung noch Verwundbarkeit.

Perimeter-Blockingtools können wiederholte Versuche drosseln; sie verarbeiten untrusted Logdaten und benötigen eigene Allowlist-, IPv6-, NAT-, Lockout- und Recoveryregeln. OpenSSH MaxStartups begrenzt nicht authentisierte Parallelverbindungen probabilistisch, PerSourceMaxStartups und PerSourcePenalties können Quellverhalten berücksichtigen. Kapazität und DoS-Risiko werden unter realen Proxy-/NAT-Verhältnissen getestet (sshd_config(5)).

Logging, Audit und Sessionnachweis

SSH-Logs belegen gewöhnlich Verbindungsquelle, Benutzer, Authmethode/Fingerprint, Sessionstart/-ende und ausgewählte Subsystemereignisse. Sie enthalten nicht automatisch jedes ausgeführte Shellkommando. Shell History ist benutzerkontrolliert und kein manipulationsgeschütztes Audit.

Für privilegierte Administration werden korreliert:

• Quellidentität, Gerät und Zugriffsentscheidung vor SSH;
• Bastion-/Proxyhop und Zielhost;
• Host-Key-/CA-Entscheidung des Clients;
• Benutzerprincipal, Authmethode, Keyfingerprint oder Zertifikatserial;
• Session-/Channeltyp, Start, Ende und Exitstatus;
• sudo-/Windows-Privilege-Ereignisse und Zielsystemaudit;
• Filetransferpfad, Hash oder Change-Ticket bei sensiblen Deployments.

Session Recording verändert Datenschutz, Geheimniserfassung und Betriebsrisiko. Passwörter, Tokens, Mailinhalte und Private Keys dürfen nicht unkontrolliert in Transcripts gelangen. Aufbewahrung, Zugriff und Manipulationsschutz werden vor Aktivierung definiert.

Windows OpenSSH

Microsoft stellt OpenSSH Client und Server als Windowsfeatures bereit. Der Server verwendet den Dienst sshd, die Konfiguration unter %ProgramData%\ssh\sshd_config, Windowskonten und ACLs; Logs können im Kanal OpenSSH/Operational erscheinen (Microsoft Learn – OpenSSH overview, Microsoft Learn – OpenSSH Server configuration).

Windows-Administratorschlüssel können je Konfiguration in einer zentralen administrators_authorized_keys-Datei liegen, deren ACL strikt sein muss. Shell, Subsysteme, DefaultShell-Registrywert und Pfadauflösung unterscheiden sich von Unix. Ein portables Clientkommando bedeutet nicht identische Serverautorisierung.

Backup, Recovery und Break Glass

SSH-Recovery umfasst nicht nur sshd_config:

• Host Keys oder Host-CA plus geschützte private Schlüssel;
• User-CA, Zertifikatsissuer, Principals und Revocationlisten;
• Authorized Keys/Commands und ihre Directory-/Config-Management-Quelle;
• Serverpolicy, Include-Dateien, PAM/SSSD/AD- und MFA-Abhängigkeiten;
• Firewall, Bastion, DNS/SSHFP und Zeitquelle;
• Break-Glass-Konto mit offline geprüftem Credential;
• Out-of-Band-Konsole, falls Netzwerk-SSH ausfällt;
• Auditlogs und Schlüssel-/Zertifikatsinventar.

Das Wiederherstellen desselben privaten Host Keys bewahrt die Serveridentität, kann aber nach einer Kompromittierung gefährlich sein. Recovery entscheidet deshalb zwischen Kontinuität und Neu-Enrollment mit Rotation. Ein Restoretest verwendet eine isolierte Zieladresse, prüft Hostprincipal, Authmethoden, Match-Policy, Privilege Escalation und Logkorrelation.

Die Diagnose liest den Verbindungsaufbau in Reihenfolge: TCP, Versionsaustausch, Key Exchange, Host Key, Benutzerauthentisierung und Channelöffnung.

Diagnose nach Protokollphase

SSH verläuft in klaren Phasen. Wer zuerst feststellt, ob TCP, Schlüsselaushandlung, Hostprüfung, Benutzeranmeldung oder Channel betroffen ist, vermeidet ungezielte Änderungen an Schlüsseln und Serverkonfiguration.

Ein Permission denied (publickey) liegt nach erfolgreichem Transport und Hosttrust. Ein Timeout vor dem Banner ist kein Schlüsselproblem. Phasenorientierte Diagnose verhindert, dass Credentials oder Algorithmuslisten ohne Evidenz geändert werden.

Technische Geschichte

Tatu Ylönen entwickelte das ursprüngliche SSH 1995 als Ersatz für unverschlüsselte Fernzugriffs- und Dateitransferwerkzeuge. SSH-1 und SSH-2 unterschieden sich grundlegend; die IETF SECSH Working Group standardisierte die SSH-2-Architektur später in RFC 4251 bis 4254 (OpenSSH – History, RFC 4251).

OpenSSH entstand im OpenBSD-Projekt aus freiem SSH-Code und wurde portabel auf andere Betriebssysteme gebracht. Es vereinte Client, Server, Schlüsselwerkzeuge, Agent, SCP und SFTP und prägte zahlreiche De-facto-Erweiterungen wie die eigene Zertifikatsform (OpenSSH Project).

Die Kryptografie entwickelte sich von älteren Diffie-Hellman-, DSA-, RSA/SHA-1-, CBC- und separaten MAC-Kombinationen zu Curve25519/ECDH, Ed25519, RSA/SHA-2 und AEAD-Verfahren. Gleichzeitig verschob sich Betriebsvertrauen von manuell verteilten Einzelkeys zu Hardwareauthentikatoren, Host-/User-CAs, kurzlebigen Zertifikaten und identitätsbasierten Bastions. Die Protokollschichten blieben erkennbar; Trust- und Lifecyclebetrieb wurden umfangreicher.

Admin-Checkliste auf einen Blick

Die Checkliste fasst Verbindungsweg, Hostvertrauen, Benutzerrechte, Schlüsselbetrieb und Protokollierung zusammen. Sie eignet sich für Freigabe und regelmässige Überprüfung eines SSH-Zugangs.