SSH unter Linux für Ihre Server konfigurieren, ohne alles neu einzugeben

Wenn Sie mehrere Maschinen verwalten, landen die gleichen SSH-Optionen schnell in der Historie: Benutzer, Port, privater Schlüssel, manchmal ein Sprung. Die Datei ~/.ssh/config ersetzt diese endlose Zeile durch einen kurzen Namen, beispielsweise ssh preprod.

Sie müssen den Server nicht ändern. Diese Konfiguration lebt auf Ihrem Rechner und sagt dem OpenSSH-Client, wie er jede Maschine erreichen kann. Sie verhindert vor allem, dass der falsche Schlüssel oder der falsche Port verwendet wird, wenn sich mehrere Umgebungen ähnlich sehen.

Erstellen Sie einen Eintrag pro Server

Erstellen Sie den Ordner, falls er nicht existiert, und öffnen Sie die Konfigurationsdatei:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/config

Fügen Sie dann einen Block pro Maschine hinzu. Hier ist preprod nur ein lokales Alias. Ersetzen Sie die Adresse, das Konto, den Port und den Schlüsselpfeil durch Ihre Werte.

Host preprod
    HostName 192.0.2.44
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_preprod
    IdentitiesOnly yes

Sie können dann ssh preprod ausführen. HostName enthält den echten DNS-Namen oder die IP-Adresse, User das entfernte Konto und Port den SSH-Port. IdentityFile wählt den erwarteten privaten Schlüssel aus. Mit IdentitiesOnly yes bietet der Client nicht alle vom SSH-Agenten geladenen Schlüssel an, was unnötige Versuche auf einem Server, der Authentifizierungen einschränkt, vermeidet.

Wenn Sie bereits einen Schlüssel verwenden, überprüfen Sie zuerst, ob er gut geschützt ist. Ein privater Schlüssel darf von anderen Konten auf Ihrem Rechner nicht lesbar sein:

chmod 600 ~/.ssh/id_ed25519_preprod
chmod 600 ~/.ssh/config

Der Leitfaden für das Erzeugen eines SSH-Schlüssels unter Ubuntu behandelt die Erstellung des Schlüsselpaares. Kopieren Sie niemals einen privaten Schlüssel auf den Server. Nur der öffentliche Schlüssel gehört in ~/.ssh/authorized_keys auf der Distanzseite.

Fügen Sie am Ende der Datei gemeinsame Einstellungen hinzu

Eine Datei config kann mehrere Host-Blöcke enthalten. Der OpenSSH-Client behält den ersten gefundenen Wert für die meisten Optionen. Stellen Sie daher die spezifischeren Server nach oben und die allgemeinen Werte an das Ende.

Host production
    HostName prod.example.net
    User deploy
    IdentityFile ~/.ssh/id_ed25519_production
    IdentitiesOnly yes

Host backup
    HostName backup.example.net
    User backup
    Port 2201
    IdentityFile ~/.ssh/id_ed25519_backup
    IdentitiesOnly yes

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

Der Block Host * gilt für alle Aliase. Er eignet sich für wirklich gemeinsame Einstellungen, hier das regelmäßige Senden eines Signals, um eine eingefrorene Verbindung zu erkennen. Vermeiden Sie es, einen Schlüssel oder einen Benutzer hinzuzufügen, wenn Ihre Server nicht alle dasselbe Konto verwenden.

Sie können auch Hosts zusammenfassen, die derselben Regel folgen, mit einem Muster wie Host *.intra. Halten Sie die Ausnahmen über diesem Block. Ein mehrdeutiges Alias oder eine zu früh platzierte allgemeine Regel führt oft zu überraschendem Verhalten.

Überprüfen Sie die Konfiguration, bevor Sie sich verbinden

Der folgende Befehl zeigt die endgültige, für ein Alias berechnete Konfiguration an, ohne eine Sitzung zu öffnen. Er ist sehr praktisch nach einer Änderung:

ssh -G preprod | grep -E '^(hostname|user|port|identityfile|identitiesonly) '

Überprüfen Sie, ob hostname, user und port tatsächlich der gewünschten Maschine entsprechen. Achten Sie auch auf den zurückgegebenen Pfad für identityfile. Wenn Sie gerade einen Schlüssel verschoben haben, könnte SSH noch auf die alte Datei verweisen.

Testen Sie dann einfach:

ssh preprod
ssh -v preprod

Die Option -v zeigt die Verbindungsschritte und die gelesenen Konfigurationsdateien an. Veröffentlichen Sie diesen Output nicht in dieser Form in einem Ticket oder Chat: Er kann Ihre Hostnamen, Konten und lokalen Pfade offenbaren.

Wenn die Konfigurationsdatei nicht ausreicht

Ein SSH-Alias löst die Wiederholung von Optionen. Er behebt nicht einen Server, der Ihren Schlüssel ablehnt, einen geschlossenen Port oder einen geänderten Hostfingerabdruck. Wenn die Authentifizierung Sie oft erneut nach Ihrer Passphrase fragt, verwenden Sie ssh-agent, anstatt das Passwort des Schlüssels zu entfernen.

Um einen internen Dienst über einen Bastion zu erreichen, behalten Sie einen separaten Eintrag mit ProxyJump und testen Sie ihn separat. Der SSH-Tunnel erfüllt ein anderes Bedürfnis: Er transportiert einen lokalen oder entfernten Port, ersetzt jedoch nicht die Konfiguration eines Hosts.

Schützen Sie ~/.ssh mit chmod 700 ~/.ssh.
Schützen Sie die Datei config und jeden privaten Schlüssel mit chmod 600.
Überprüfen Sie das Alias mit ssh -G alias_name vor der ersten Verbindung.
Testen Sie jeden neuen Server mit seinem Alias und behalten Sie dann die gemeinsamen Optionen in einem Host *-Block, der am Ende der Datei steht.

Die offizielle Dokumentation ssh_config(5) beschreibt jede Direktive. Nehmen Sie sich zwei Minuten Zeit, um die Ausgabe von ssh -G zu überprüfen, bevor Sie ein Alias auf einer Produktionsmaschine verwenden: Es ist schneller, als herauszufinden, warum SSH den falschen Schlüssel gewählt hat.