Vom HostBIch kann per SSH auf verschiedene andere Hosts zugreifen (CD) ohne Verwendung eines Passworts, da ich den öffentlichen Schlüssel in die entsprechenden authorized_keys-Dateien (auf den Hosts C und D) eingefügt habe.
Vom HostAIch kann SSH hostenB(überPasswortAuthentifizierung). Sobald ich jedoch beim Host angemeldet binBICHmuss meinen Schlüssel jedes Mal authentifizierenwenn ich mich mit C und D verbinde (auch wenn das prinzipiell nicht der Fall sein sollte).
Zusammenfassend lässt sich sagen, dass ich bei einer direkten Verbindung mit Host B (z. B. Büro) kein Kennwort eingeben muss, um eine Verbindung mit C oder D herzustellen. Wenn ich eine Verbindung mit A (z. B. Zuhause) herstelle und mich dann von AI aus mit B verbinde, benötige ich, sobald ich in BI bin, Kennwörter, um eine Verbindung mit D oder C herzustellen. Ich kann das Problem teilweise lösen, indem ich das Kennwort zu einem SSH-Agenten hinzufüge (mit ssh-add), aber jedes Mal, wenn ich eine neue Shell in BI öffne, muss ich dies erneut tun.
Aktualisieren
Dank der hilfreichen Kommentare stellte sich heraus, dass das Problem folgendes ist. Wenn ich mich direkt mit B verbinde, läuft dort ein Keyring-Programm (in meinem konkreten Fall ist das Seahorse). Daher können die Passwörter aller verschlüsselten privaten Schlüssel automatisch verwendet werden. Wenn ich mich von A aus mit B verbinde, passiert dies nicht. Aus einem mysteriösen Grund ist das Programm Seahorse in B nicht aktiv, selbst wenn ich eine Remote-Sitzung (VNC / Remmina) von A nach B starte, und daher muss ich die Passwörter immer wieder manuell eingeben.
ich installierteSchlüsselanhängerund das Problem wurde gelöst.
Ich bin jedoch nicht sicher, ob es sich lohnt, einen privaten Schlüssel zu verschlüsseln, der nur für die SSH-Verbindung zu einem bestimmten Server verwendet wird.Entsteht durch die Nichtverschlüsselung der privaten Schlüssel ein konkretes Sicherheitsrisiko?Wenn jemand Zugriff auf den privaten Schlüssel hat, kann er/sie im Prinzip auch die im Schlüsselbund gespeicherten Passwörter verwenden. Daher scheint es keinen großen Vorteil zu bieten, die privaten Schlüssel zu verschlüsseln.
Antwort1
Sie haben einen Teil Ihres Problems gelöst, indem Sie keychainals Speicher für Ihre Passphrasen für Ihre SSH-Schlüssel verwendet haben. Zu Ihrer anderen Frage:
Ich bin mir jedoch nicht sicher, ob es sich lohnt, einen privaten Schlüssel zu verschlüsseln, der nur für die SSH-Verbindung zu einem bestimmten Server verwendet wird. Besteht ein konkretes Sicherheitsrisiko, wenn die privaten Schlüssel nicht verschlüsselt werden? Wenn jemand Zugriff auf den privaten Schlüssel hat, kann er/sie im Prinzip auch die im Schlüsselbund gespeicherten Passwörter verwenden. Es scheint also, dass die Verschlüsselung der privaten Schlüssel keinen großen Vorteil bringt.
Es ist nicht so, dass Ihre privaten Schlüssel unverschlüsselt bleiben, sondern dass sie nicht durch eine Passphrase geschützt sind. Daher .sshkann jeder, der Zugriff auf das Verzeichnis Ihres Home-Verzeichnisses erhält, problemlos Kontrolle über Ihre SSH-Schlüssel erlangen.
Wenn Sie damit einverstanden sind, diese Schlüssel auf einem System zu belassen, über das Sie die volle Kontrolle haben, sehe ich kein Problem darin, sie ohne Passphrase zu belassen. Ich würde auch empfehlen, einen anderen Schlüsselsatz zu generieren, den Sie auf sekundären Systemen wie diesem belassen können, oder sogar einen einzigartigen Satz nur für diesen Server, damit Sie ihn ohne große Probleme vollständig aufgeben können, falls Sie jemals feststellen, dass er kompromittiert wurde.
Was die Verwendung keychainzur Verwaltung Ihrer Schlüssel betrifft, sehe ich keinen großen Vorteil darin, Passphrasen für SSH-Schlüssel zu haben, wenn Sie keychaindiese zur Verwaltung verwenden, außer dass keychainsie nur gespeichert werden, wenn Sie sie verwenden. Wenn Sie die Schlüssel nicht oft verwenden und sorgfältig aufräumen, keychainwenn Sie fertig sind, wäre eine Passphrase von Vorteil, aber meiner Meinung nach ist es nur ein kleiner.