SSH-Schlüsselaustausch von Cygwin zu Ubuntu schlägt fehl

2105
alyssackwan

Ich versuche SSH von Windows / Cygwin auf Ubuntu. Ich verwende kein PuTTY. Stattdessen verwende ich Cygwin ssh, was OpenSSH sein sollte. Ich habe ssh-user-config auf dem Windows-Computer verwendet, um meine Schlüsselpaare zu generieren: RSA1, RSA2 und DSA. Ich verwende keine Passphrasen für die Tasten. Wenn ich renne:

ssh -vvv zzzz@zzzz.zzz

Ich bekomme:

OpenSSH_5.6p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /c/Documents and Settings/zzzz/.ssh/config debug2: ssh_connect: needpriv 0 debug1: Executing proxy command: exec corkscrew corporate.proxy.zzz 8080 zzzz.zzz 22 debug1: permanently_drop_suid: 101684 debug3: Not a RSA1 key file /c/Documents and Settings/zzzz/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /c/Documents and Settings/zzzz/.ssh/id_rsa type 1 debug1: identity file /c/Documents and Settings/zzzz/.ssh/id_rsa-cert type -1 debug3: Not a RSA1 key file /c/Documents and Settings/zzzz/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /c/Documents and Settings/zzzz/.ssh/id_dsa type 2 debug1: identity file /c/Documents and Settings/zzzz/.ssh/id_dsa-cert type -1 ssh_exchange_identification: Connection closed by remote host

Ich verwende Korkenzieher auf meinem Windows-Computer, um durch die Unternehmensfirewall zu gelangen. Ich glaube nicht, dass das etwas mit diesem Problem zu tun hat.

Wenn es darauf ankommt, ist der Zielserver eine Slicehost Ubuntu 10.04 (Lucid) -LTS-Instanz. Ich gehe davon aus, dass auch OpenSSH ausgeführt wird. Sollten die von Cygwin OpenSSH generierten Schlüssel nicht mit Ubuntu kompatibel sein?

Der private Schlüssel (~ / .ssh / id_rsa) sieht folgendermaßen aus:

-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEA0tASFawZdtNVXYg7ms6z1R2YiPcuBUgMt0loZSbmCzovuHG6 2wrU5SIiaSpPlQbsVJXjOcCzNhn8wujXo0J/RiOge7MnSmCKAaWtRc7cidh9qO13 nh8IL9TC94Cj+bPBSC5fYewc+B92WBnG2YmKRD8OxEc7KaHtchqhfsz9IzHPHKl4 r6PhIuevAymYT3YMMWF+yjmECrwIS/7nw1mSn4qUDYMU+t6dbhO+Sw/hfYvvzCMI ILZKF5WTN7zNO5Sl1VS1BHxB0mb2Yg+BpmjQ8iEPoUuqUA+LA3+A1jVFBjrtFCoZ 1ARKO6GwE1PfFIgepuzu4msdOu4NHH+HwsZj/wIDAQABAoIBAQDSbG4gw9AHE5s5 6SnVtE08hHYlANUm4GwQ520UymcE/ed0K9FfosgujovafSlCj86F/7b3hqlbb0Ul KFVV2KJB2H3v+ztUulgGnOD/tSPdVALaA25Knp8FX1HcysLiE9LxwZfjnlKsOHtg JRqfOPKSfH643IDpZYAlTP+2GdbysI016ZxBajRJfl6vkd8LVqnX682LFNlQv7aQ L/hnPZYWmwDtlFZE6ZWqex/kYQksDsqthYOf4chY8kvpLqIkquCniq7nLC3hDHSl 6peUtuoq0eoNO3G3PHbvkoMz02V15PdADZeA9yr33T+hDP2aRgFqMfBthA3lFphX +XV8I2BBAoGBAO0IP5TocnMpyVERRBNlobBSxk66XeMCWvZPfKapeHTLZjSaIgh5 1R9WSD2jmtRTpDONSwigbniwB4Yb+nELsITI7i3jp3s/MQMQgaqXJgMwEyCYChji Va2P1kP/ijKHsoDc0Il6KWgDkyqw2l2KU0w46esCEl6izM+I7O6PAw2lAoGBAOOu s2QQTT1Om8iN7hpSp8nLjJvDdWy6Q2zHKrd6KEHY1Xrvrgy/5xtldx66DNbDT647 9nShyh5A2UOBx6NV8PG7zWjoz28E8O1EWGiEIxgDIFrMn6aU9hOA9gYOprcqbpL0 fWGVYBy8dF2hinLUC9OGUw7F/+mLHqbuY12aOoHTAoGAUixJ3pW3F7Wk1TXnI9JX +4i2txRk+A4Y+ssTq7OUzui0xgepRMb326VN5hCR3IoioryZBqSXp79e3F9Ws1oa F+6Qo9gId/GwTB+s1DcSNoi0GNicp4PPsBvtbCVrA5mHiKUEpqRzNlwG6QXmrgcG WaZhcdeGBsjpuAkAGrP5mwECgYBmsAZsnQWZHvkX7Rt0d88BLnLOVcuCLEf4qaNU eR3rBNbTyYHgcjTToGGnVBYyToiDdrvjQo0cM/dJgSD/Q+WVwTQVmtrjoYDgIjEV gnMpg092ZE+lHA4YIdPUS4tZlSOl1+sstehRTZXWHOOKgqSK1Exln1uag4phk6bx MnwszQKBgQDVvg8QbHOVL82ZpqfoTmBY3+ZNrOHMlo8hH4X40veAhjKaSyAZw1qx BEJVNgHT/UZkM10kAYtRNsmp0CFPyAY9rTy9ekEKfht6HSO10j8Nzv3v+zI0DEx9 /2+0vcPQZyKVHz//VJPQ5g084l22qMdLCDqVWkZbfgVJkjH45LIY5w== -----END RSA PRIVATE KEY-----

Aktualisieren:

Also bin ich nach Hause gekommen und habe mir /var/log/auth.log angesehen (danke Rob !). Beim Verbinden bekomme ich nur:

sshd[2421]: Did not receive identification string from 999.999.999.999

Wenn ich sshd im Debug-Modus ausgeführt habe, bekomme ich nur Folgendes:

sshd[2423]: debug1: sshd version OpenSSH_5.3p1 Debian-3ubuntu4  sshd[2423]: debug1: read PEM private key done: type RSA  sshd[2423]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048  sshd[2423]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048  sshd[2423]: debug1: private host key: #0 type 1 RSA  sshd[2423]: debug1: read PEM private key done: type DSA  sshd[2423]: debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024  sshd[2423]: debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024  sshd[2423]: debug1: private host key: #1 type 2 DSA

Die genannten Blacklist-Dateien existieren nicht.

2

1 Antwort auf die Frage

0
Rob

Die id_rsa-Schlüsseldatei muss einen Header-Block enthalten, der den Typ identifiziert. Es scheint, dass das beschädigt ist. Sie sollten wahrscheinlich versuchen, den Schlüssel mit dem Befehl keygen neu zu erstellen.

Der Header für meine von cygwin generierte Schlüsseldatei sieht folgendermaßen aus:

----- BEGIN RSA PRIVATE KEY ----- Proc-Type: 4, ENCRYPTED DEK-Info: AES-128-CBC, 48818Cxxxxxxxxxxxxxxxxxxxxxxxxxx
Ich habe versucht, mit ssh-keygen auf dem Windows / Cygwin-Computer erneut ein RSA2-Schlüsselpaar zu generieren, aber es hat noch keinen Header-Block. Ist dies ein Problem mit Cygwins OpenSSH? alyssackwan vor 13 Jahren 0
Was ist der genaue Befehl, den Sie ausgeführt haben? Verwenden Sie Cygwin 1.7? Rob vor 13 Jahren 0
Mein Cygwin-Setup ist 2.721. Ich verwende den Spiegel ftp://mirror.cs.vt.edu. Cygwin selbst ist 1.7.7-1. Und openssh ist 5.6p1-2. Mein Befehl war "ssh-keygen -t rsa". alyssackwan vor 13 Jahren 0
Anscheinend enthält Ihr Home-Ordner (/ c / Documents and Settings / zzzz /) Leerzeichen. Die Cygwin-FAQ schlägt vor, dass (zusätzlich zu Leerzeichen im Benutzernamen) Leerzeichen im Stammordner pat Probleme verursachen können. http://cygwin.com/faq/faq-nochunks.html#faq.setup.name-with-space Rob vor 13 Jahren 0
Vielen Dank für all Ihre Hilfe dazu. Ich habe einen symbolischen Link von / home zu meinem ~ erstellt und mein / etc / passwd mit dem Pfad ohne Leerzeichen aktualisiert. Ich bekomme genau dieselbe Debug-Spur, mit der Ausnahme, dass mein Home-Pfad anders ist. alyssackwan vor 13 Jahren 0
Was ist der Header in ~ / .ssh / id_rsa? Achten Sie darauf, Ihren privaten Schlüssel nicht wirklich zu posten. Die Fehlermeldung besagt, dass "----- BEGIN" gefunden wurde. Rob vor 13 Jahren 0
Es ist zu lang für einen Kommentar, also habe ich ihn im Original gepostet. Ich werde einfach ein neues Paar generieren. Danke noch einmal! alyssackwan vor 13 Jahren 0
Sie haben Ihren gesamten privaten Schlüssel gepostet, sodass Sie sicher sein sollten, einen neuen zu generieren. Sie sollten auch die Datei auth.log des Remote-Servers auf Fehler überprüfen, wenn Sie versuchen, sich mit dem Schlüssel anzumelden. Rob vor 13 Jahren 1
Ich wäre nicht zu voreilig, die Schlüssel zu tadeln. Ich verwende cygwin, ssh, mit den gleichen Versionen wie Sie, jedoch über ein lokales Netzwerk. Mein privater Schlüssel sieht wie Ihr aus (kein Header). Der Pfad zu meinem Schlüssel enthält Leerzeichen. Meine Debug-Ausgabe sieht ziemlich ähnlich wie die Ihre, mit Ausnahme der Zeile 3, in der Sie einen "ausführenden Proxy-Befehl ..." ausführen. Ich habe "Herstellen einer Verbindung zu (meinem lokalen Debian-Computer) - Port 22. Meine nächste Zeile ist" Verbindung hergestellt. Es folgen die gleichen key_type- und key_read-Fehler, die Sie beim Lesen der id_dsa-Identitätsdatei sehen. Mein Setup funktioniert. W_Whalley vor 13 Jahren 0
Ich habe ein Schlüsselpaar verwendet, das ich in meinem MBP mit der rechten Kopfzeile erstellt hatte. Immer noch die gleiche Nachricht, obwohl der Header offensichtlich da ist ... alyssackwan vor 13 Jahren 0
Melden Sie sich mit einem Kennwort oder dem Web-Terminal-Client in Ihrem Slice-Manager bei Ihrem Slice an. Führen Sie dann den Befehl sudo tail -f / var / log / auth.log aus. Drücken Sie dann mehrmals die Eingabetaste, um Leerzeilen zu erhalten. Versuchen Sie nun über ein anderes Terminalfenster (Cygwin erneut öffnen), sich mit der Taste anzumelden. Fehler, die die Anmeldung verhindern, sollten im Protokoll angezeigt werden. Wenn sie nicht klar sind, poste sie hier. Rob vor 13 Jahren 0
Wenn Sie `ssh-keygen -t rsa` auf einem Unix-Computer (Ubuntu) ausführen, wird kein spezieller Header generiert. Ich verwende auch einen anderen privaten Schlüssel ohne Header, um mich ständig bei VPS-Servern anzumelden. Das kann also nicht die Antwort sein. Chloe vor 6 Jahren 0

Verwandte Probleme