7
Nativer SSH-Client in Windows und RSA-Schlüssel
Hallo,
seit heute verwirrt mich der native SSH-Client von Windows 11. Ich nutze ihn seit es ihn in Windows 10 gibt, um mich mit verschiedenen SSH-Linux-Servern zu verbinden. Ich nutze dabei zwei Arten der SSH-Verbindung:
Bisher habe ich immer zwei Schlüsselpaare gebraucht: RSA und Ed25519
RSA nutze ich für die C#-Programme, während Ed25519 für die Windows-Kommandozeile. Der Grund dafür ist, dass SSH unter Windows kein RSA für die Absicherungen von SSH-Verbindungen mittels Schlüsselpaare unterstützt, so dass ich auf Ed25519 ausweiche.
Nun hatte ich heute die Aufgabe, mich auf einen anderen Linux-Server zu verbinden. Dazu wollte ich wie immer, den ersten Schlüsselpaar (RSA) generieren:
Dabei stellte ich fest, dass meine SSH-Bibliothek (SSH.NET) mit dem Schlüssel nichts anfangen konnte, da neuerdings ssh-keygen seit irgendwann standardmäßig das neue Format für RSA generiert. Damit kann SSH.NET noch nicht umgehen und bricht mit einer Fehlermeldung ab, sobald man ein neu generiertes Schlüsselpaar verwendet. Daher habe ich bei der Erstellung das alte Format“ (PEM) erzwungen:
Damit funktioniert meine Bibliothek wieder.
Ich habe den öffentlichen Schlüssel zum Server übertragen und mich gleich mit SSH über die Windows-Kommandozeile unter Verwendung des neuen Schlüssels mit dem Server verbunden. Dabei war mir erst aufgefallen, dass ich die Erstellung des zweiten Schlüsselpaares (Ed25519) für die Kommandozeile vergessen hatte und mich mit dem RSA-Schlüssel erfolgreich authentifizieren konnte – nun bin ich verwirrt.
Seit wann kann man RSA-Schlüssel mit dem nativen SSH-Client von Windows verwenden?
Ich habe danach gegoogelt, konnte aber nichts brauchbares finden.
Danke und lG
René
seit heute verwirrt mich der native SSH-Client von Windows 11. Ich nutze ihn seit es ihn in Windows 10 gibt, um mich mit verschiedenen SSH-Linux-Servern zu verbinden. Ich nutze dabei zwei Arten der SSH-Verbindung:
- Von der Kommandozeile aus, um über ein Terminalfenster den Linux-Server zu administrieren und
- in selbst entwickelten C#-Programmen, um auf Server-Ressourcen zuzugreifen.
Bisher habe ich immer zwei Schlüsselpaare gebraucht: RSA und Ed25519
RSA nutze ich für die C#-Programme, während Ed25519 für die Windows-Kommandozeile. Der Grund dafür ist, dass SSH unter Windows kein RSA für die Absicherungen von SSH-Verbindungen mittels Schlüsselpaare unterstützt, so dass ich auf Ed25519 ausweiche.
Nun hatte ich heute die Aufgabe, mich auf einen anderen Linux-Server zu verbinden. Dazu wollte ich wie immer, den ersten Schlüsselpaar (RSA) generieren:
ssh-keygen -t rsa -b 4096Dabei stellte ich fest, dass meine SSH-Bibliothek (SSH.NET) mit dem Schlüssel nichts anfangen konnte, da neuerdings ssh-keygen seit irgendwann standardmäßig das neue Format für RSA generiert. Damit kann SSH.NET noch nicht umgehen und bricht mit einer Fehlermeldung ab, sobald man ein neu generiertes Schlüsselpaar verwendet. Daher habe ich bei der Erstellung das alte Format“ (PEM) erzwungen:
ssh-keygen -t rsa -b 4096 -m PEMDamit funktioniert meine Bibliothek wieder.
Ich habe den öffentlichen Schlüssel zum Server übertragen und mich gleich mit SSH über die Windows-Kommandozeile unter Verwendung des neuen Schlüssels mit dem Server verbunden. Dabei war mir erst aufgefallen, dass ich die Erstellung des zweiten Schlüsselpaares (Ed25519) für die Kommandozeile vergessen hatte und mich mit dem RSA-Schlüssel erfolgreich authentifizieren konnte – nun bin ich verwirrt.
Seit wann kann man RSA-Schlüssel mit dem nativen SSH-Client von Windows verwenden?
Ich habe danach gegoogelt, konnte aber nichts brauchbares finden.
Danke und lG
René
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5109098239
Url: https://administrator.de/contentid/5109098239
Ausgedruckt am: 27.11.2024 um 22:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
AFAIK schon immer. Und schon immer war RSA der default bei ssh-keygen auch unter Windows. Es wundert mich eher, dass es bei Dir mal nicht ging.
Liebe Grüße
Erik
Zitat von @temuco:
Seit wann kann man RSA-Schlüssel mit dem nativen SSH-Client von Windows verwenden?
AFAIK schon immer. Und schon immer war RSA der default bei ssh-keygen auch unter Windows. Es wundert mich eher, dass es bei Dir mal nicht ging.
Liebe Grüße
Erik
1
AFAIK schon immer. Und schon immer war RSA der default bei ssh-keygen auch unter Windows. Es wundert mich eher, dass es bei Dir mal nicht ging.
Ja, "ssh-keygen" – ich meine "\Windows\System32\OpenSSH\ssh.exe"
Z. B.
ssh -i "pfad\rsa-schlüssel" user@host ssh -i "pfad\Ed25519-schlüssel" user@host
Danke für den Link – sehr interessant. Das beantwortet aber meine Frage nicht.
Ich verwende RSA für die C#-Bibliothek, da diese Ed25519 noch nicht kann und bis vor einiger Zeit konnte die Windows-Implementierung von SSH (SSH.exe) nichts mit dem RSA-Schlüssel anfangen, daher bis gestern Ed25519 für Windows. Und wie ich bereits beschrieb, merkte ich gestern aus reinem Zufall, dass SSH.exe nun doch mit RSA umgehen kann. Ich weiß aber nicht, seit wann. Es wäre interessant gewesen, es zu erfahren.
Nochmals vielen Dank und einen erfolgreichen Tag!
René
Ich verwende RSA für die C#-Bibliothek, da diese Ed25519 noch nicht kann und bis vor einiger Zeit konnte die Windows-Implementierung von SSH (SSH.exe) nichts mit dem RSA-Schlüssel anfangen, daher bis gestern Ed25519 für Windows. Und wie ich bereits beschrieb, merkte ich gestern aus reinem Zufall, dass SSH.exe nun doch mit RSA umgehen kann. Ich weiß aber nicht, seit wann. Es wäre interessant gewesen, es zu erfahren.
Nochmals vielen Dank und einen erfolgreichen Tag!
René
Moin,
Schon klar. Das war so gemeint: Warum sollte MS einen key im Standard generieren, der dann mit dem eigenen Client nicht geht.
Das kann ich so nicht bestätigen. Ich hatte noch nie Probleme, mich von einer Windows-Kiste mit einem Linux-Server per ssh und RSA-key zu verbinden.
Liebe Grüße
Erik
Zitat von @temuco:
Ja, "ssh-keygen" – ich meine "\Windows\System32\OpenSSH\ssh.exe"
AFAIK schon immer. Und schon immer war RSA der default bei ssh-keygen auch unter Windows. Es wundert mich eher, dass es bei Dir mal nicht ging.
Ja, "ssh-keygen" – ich meine "\Windows\System32\OpenSSH\ssh.exe"
Schon klar. Das war so gemeint: Warum sollte MS einen key im Standard generieren, der dann mit dem eigenen Client nicht geht.
Z. B.
Das hat bis heute nie funktioniert, daher musste ich einen Ed25519-Schlüssel nutzen:
ssh -i "pfad\rsa-schlüssel" user@host ssh -i "pfad\Ed25519-schlüssel" user@host Das kann ich so nicht bestätigen. Ich hatte noch nie Probleme, mich von einer Windows-Kiste mit einem Linux-Server per ssh und RSA-key zu verbinden.
Liebe Grüße
Erik
1
Danke Erik. Es bleibt mir ein Rätsel, warum das bei mir so der Fall war.
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread als erledigt zu markieren!
