Das Szenario hier ist, dass ich einen von AWS generierten privaten Schlüssel – einen ED25519-Schlüssel – erhalten habe und ihn mit dem in Windows 10/1809 integrierten SSH (OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5) versucht habe, und es funktioniert einwandfrei.
Ich habe denselben Schlüssel auf demselben PC, aber innerhalb von WSL Ubuntu 18.04.3 (OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7. Dez. 2017) ausprobiert und es wird angezeigt, dass der Schlüssel ein ungültiges Format hat.
Der Aufruf von ssh -v zeigt:
....snip a bit here....
debug1: Authenticating to xxxxxxxx.demo.com:22 as 'jgauthier'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fCykR67cJynMNYYYv9jEO5PhYQgcaU0WRy/xmSsTxYQ
debug1: Host 'xxxxxxxx.demo.com' is known and matches the ECDSA host key.
debug1: Found key in /home/jgauthier/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
------------------------------------------------------------------------------
NOTICE
This IT system is provided for business use in accordance with approved
Policies and Procedures. By logging in, users acknowledge their understanding
that authorized administrators monitors and stores all activity generated on
this system as appropriate for business and security operations and may
disclose such activity or information as permitted by law.
------------------------------------------------------------------------------
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: jgauthier_key.pem
Load key "jgauthier_key.pem": invalid format
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).
Hier sind die letzten relevanten Zeilen von dem, was funktioniert:
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: jgauthier_key.pem
debug1: Authentication succeeded (publickey).
Authenticated to xxxxxxx.demo.com ([nn.nn.nn.nn]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing
debug1: client_input_global_request: rtype [email protected] want_reply 0
Last login: Fri Oct 18 21:30:10 2019 from mm.mm.mm.mm
Last login: Fri Oct 18 21:30:10 2019 from mm.mm.mm.mm
[jgauthier@xxxxxxx ~]$
Irgendwelche Ideen? Ich habe es noch nicht innerhalb einer VirtualBox-VM mit Ubuntu 18.04.3 auf demselben PC oder von einem anderen Linux-System aus ausprobiert ...
Der Host, mit dem ich mich verbinde, ist CentOS 7.6. Der Server meldet
Remote protocol version 2.0, remote software version OpenSSH_7.4
wenn ich mich verbinde, falls das wichtig ist.
Ich dachte, es könnte CR/LF vs. LF sein, aber in WSL Linux habe ich die .pem-Datei manuell bearbeitet, um alle möglichen CR/LFs zu entfernen, und darauf geachtet, nach der letzten Zeile der Datei ein einzelnes LF zu hinterlassen – aber das ging nicht. Ich habe sogar einen Vergleich zwischen der Kopie in meinem Windows .ssh-Verzeichnis und der Kopie in meinem WSL ~/.ssh durchgeführt, und sie sind identisch.
Es hat etwas mit den beiden SSH-Versionen zu tun – LibreSSL 2.6.5 vs. OpenSSL 1.0.2n?