Ich habe vor Kurzem einen Server (mit RHEL AS 5) vom OpenSSH 4-Server auf einen OpenSSH 5.2-Server aktualisiert.
Seit dem Upgrade kann ein Kunde keine SCP-Dateien mehr von der Maschine aus durchführen. Er verwendet einen SSH-Client vonhttp://ssh.com/. Ich kann mit OpenSSH problemlos Dateien per SCP vom und zum Computer senden.
Wir verwenden die „Public-Key-Authentifizierung“ und sie können weiterhin per SSH auf die Maschine zugreifen, jedoch nicht auf SCP-Dateien.
Gibt es eine bekannte – offensichtliche – Ursache für solche Inkompatibilitäten? Wenn nicht, wie kann ich dieses Problem genauer untersuchen?
Hier ist ein Protokoll von der Clientseite:
user@srv/home/user> /usr/local/bin/scp -v [email protected]:/home/cdr/test .
scp:SshAppCommon/sshappcommon.c:133: Allocating global SshRegex context.
scp:Scp2/scp2.c:499: Received error "SSH_FC_OK"., msg: Globbing successful.
scp:Scp2/scp2.c:564: Starting transfer...
scp:/home/cdr/test
scp:SshFCTransfer/sshfc_transfer.c:3018: File list has 2 files.
scp:SshFCTransfer/sshfc_transfer.c:2567: Not yet connected, or connection down, waiting...
scp:SshFileCopy/sshfilecopy.c:940: Connecting to remote host. (host = xxx.xxx.xxx.51, user = cdr, port = NULL)
scp:Scp2/scp2.c:1679: argv[0] = /usr/local/bin/ssh2
scp:Scp2/scp2.c:1679: argv[1] = -l
scp:Scp2/scp2.c:1679: argv[2] = cdr
scp:Scp2/scp2.c:1679: argv[3] = -v
scp:Scp2/scp2.c:1679: argv[4] = -x
scp:Scp2/scp2.c:1679: argv[5] = -a
scp:Scp2/scp2.c:1679: argv[6] = -o
scp:Scp2/scp2.c:1679: argv[7] = clearallforwardings yes
scp:Scp2/scp2.c:1679: argv[8] = -o
scp:Scp2/scp2.c:1679: argv[9] = passwordprompt %U@%H's password:
scp:Scp2/scp2.c:1679: argv[10] = -o
scp:Scp2/scp2.c:1679: argv[11] = nodelay yes
scp:Scp2/scp2.c:1679: argv[12] = -o
scp:Scp2/scp2.c:1679: argv[13] = authenticationnotify yes
scp:Scp2/scp2.c:1679: argv[14] = xxx.xxx.xxx.51
scp:Scp2/scp2.c:1679: argv[15] = -s
scp:Scp2/scp2.c:1679: argv[16] = sftp
debug: Connecting to xxx.xxx.xxx.51, port 22... (SOCKS not used)
debug: Ssh2/ssh2.c:2121: Entering event loop.
debug: Ssh2Client/sshclient.c:1403: Creating transport protocol.
debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:83: Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1444: Creating userauth protocol.
debug: client supports 2 auth methods: 'publickey,password'
debug: Ssh2Common/sshcommon.c:559: local ip = xxx.xxx.xxx.35, local port = 56985
debug: Ssh2Common/sshcommon.c:561: remote ip = xxx.xxx.xxx.51, remote port = 22
debug: SshConnection/sshconn.c:1930: Wrapping...
debug: Ssh2/ssh2.c:899: Opening /dev/tty for queries.
debug: Remote version: SSH-2.0-OpenSSH_5.2
debug: Ssh2Transport/trcommon.c:1306: Remote version has rekey incompatibility bug.
debug: Ssh2Transport/trcommon.c:1308: Remote version is OpenSSH, KEX guesses disabled.
debug: Ssh2Transport/trcommon.c:1647: lang s to c: `', lang c to s: `'
debug: Ssh2Transport/trcommon.c:1712: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/trcommon.c:1715: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression none
debug: Remote host key found from database.
debug: Ssh2Common/sshcommon.c:317: Received SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/sshcommon.c:367: Received SSH_CROSS_ALGORITHMS packet from connection protocol.
debug: server offers auth methods 'publickey,password,keyboard-interactive'.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/nsdau187" to candidates
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_a" to candidates
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1535: adding keyfile "/devapp_users/nsdtest/.ssh2/id_dsa_1024_b" to candidates
debug: Constructing and sending signature in publickey authentication.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:772: ssh_client_auth_pubkey_send_signature: reading /devapp_users/nsdtest/.ssh2/nsdau187
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1751: Public key authentication was successful.
debug: Ssh2Common/sshcommon.c:285: Received SSH_CROSS_AUTHENTICATED packet from connection protocol.
debug: Ssh2/ssh2.c:650: Returning user input stream to original values.
debug: Ssh2Common/sshcommon.c:829: num_channels now 1
scp:SshFCTransfer/sshfc_transfer.c:130: Source file is "raw", and it needs to be parsed.
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: bad VERSION
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
scp:SshFCTransfer/sshfc_transfer.c:1319: No connection yet. Waiting...
[...] same until the user presses Ctrl+C
user@srv/home/user> debug: SshConnection/sshconn.c:405: EOF from channel stream
debug: Ssh2ChannelSession/sshchsession.c:1721: received exit status : 0
debug: Ssh2Common/sshcommon.c:803: num_channels now 0
debug: Got session close with exit_status=0
debug: destroying client struct...
debug: Ssh2Client/sshclient.c:1478: Destroying client.
debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki != NULL, user_pki = NULL)
debug: SshConnection/sshconn.c:1982: Destroying SshConn object.
debug: Ssh2Client/sshclient.c:1540: Destroying client completed.
debug: SshAuthMethodClient/sshauthmethodc.c:88: Destroying authentication method array.
debug: SshAppCommon/sshappcommon.c:146: Freeing global SshRegex context.
debug: SshConfig/sshconfig.c:555: Freeing pki. (host_pki = NULL, user_pki = NULL)
Und hier die Einträge aus dem Serverlog
Jun 3 07:22:36 localhost sshd[19898]: Accepted publickey for cdr from xxx.xxx.xx.x port 53119 ssh2
Jun 3 07:22:36 localhost sshd[19900]: subsystem request for sftp
Jun 3 07:22:58 localhost snmpd[8500]: netsnmp_assert index == tmp failed if-mib/data_access/interface.c:467 _access_interface_entry_save_name()
Jun 3 07:23:58 localhost last message repeated 4 times
Bearbeiten: „Subsystem sftp internal-sftp“ ist in der Konfigurationsdatei bereits aktiviert und ich kann problemlos Dateien per SFTP vom Server herunterladen.
Bearbeiten: Der Versuch ohne die Schlüssel durch Angabe eines Benutzernamens/Passworts funktioniert auch nicht. Die Rückkehr zur älteren Version funktioniert, also machen wir das jetzt.
Übrigens haben wir diese Zeile vermutet
debug: SshTtyFlags/sshttyflags.c:354: Not a tty. (fd = 0)
könnte bedeuten, dass die Shell etwas sendet, das auf der SSH-Konsole angezeigt wird, aber SCP durcheinanderbringt, aber über SSH scheint nichts gesendet zu werden (und .bashrc scheint sauber zu sein) und ich kann den entschlüsselten SCP-Verkehr nicht anzeigen, um festzustellen, ob etwas falsch gesendet wird.
Antwort1
Was bedeutet „SCP-Dateien können nicht ausgeführt werden“ noch? Welche Fehlermeldung wird angezeigt?
Überprüfen Sie Ihre Protokolle (/var/log/syslog, /var/log/messages, /var/log/daemon.log), um festzustellen, ob der SSH-Server Fehler ausgibt. Sie sollten ziemlich aussagekräftig sein. Mit den Protokollen und dem Kundenfehler sollten wir in der Lage sein, das Problem einzugrenzen.
Bearbeiten
Die von Ihnen geposteten Protokolle weisen auf das wahrscheinlichste Problem hin:
scp:Scp2/scp2.c:1679: argv[16] = sftp
...
scp:SshFileXferClient/sshfilexferc.c:981: ssh_file_client_receive_proc: fehlerhafte VERSION
Sieht so aus, als würde dieses Ding versuchen, das SFTP-Protokoll statt direkt SCP zu verwenden. OpenSSH deaktiviert standardmäßig das SFTP-Subsystem. Ich weiß nicht, wann diese Änderung vorgenommen wurde, aber es klingt wahrscheinlich. Fügen Sie dies zu Ihrer sshd_config hinzu und sehen Sie, ob sich dadurch etwas ändert:
Subsystem sftp internes-sftp
Antwort2
Es gibt viele potenzielle Probleme. Haben Sie zunächst die Protokolle auf Ihrem Server untersucht, um zu sehen, ob es Hinweise gibt? Ist es möglich, dass das Upgrade eine Einstellung geändert hat, die der Client entweder nicht verwenden kann oder die nicht für die Verwendung eingestellt ist? Benötigt Ihr Server jetzt beispielsweise SSH2, aber der Client verwendet nur SSH1?
Protokolldateien liefern wahrscheinlich die Antwort. Wenn der SCP-Client Protokolle erstellen kann, könnte das ebenfalls hilfreich sein.
Antwort3
Dies könnte etwas mit der behobenen OpenSSH-Schlüssel-Sicherheitslücke zu tun haben. Alle anfälligen Schlüssel wurden auf die schwarze Liste gesetzt und sollten neu erstellt werden. Prüfen Sie einfach, ob die zwischengespeicherten Fingerabdrücke Ihres Servers gelöscht werden können. Wenn dies erledigt ist, sollte der Client dem Benutzer den neuen Fingerabdruck zeigen und ihn fragen, ob er ihn akzeptiert. Der Grund, warum SSH funktionieren könnte, ist, dass die App den Benutzer gefragt haben könnte, ob er den neuen Schlüssel akzeptiert, oder dass der erste Kontakt nach dem Upgrade hergestellt wurde.
Antwort4
Ich habe dasselbe Problem bei der Verwendung des SSH-Clients festgestellt. Das Dibug-Protokoll zeigt ... FileTransferWin/filetransferwin.c:217: Fehler SSH_FC_OK empfangen, Fehlermeldung „Keine zu übertragenden Dateien“.
Nach stundenlangen Experimenten habe ich verstanden, dass SSH keine Dateien aus Ordnern überträgt, die ein Sonderzeichen im Namen haben, z. B. „Files to (Transfer)“. Nachdem ich den Ordnernamen in „Files_to_Transfer“ geändert hatte, funktionierte es problemlos.