sftp funktioniert nicht mehr (connection closed)
Hallo allerseits, seit neuestem (?) funktioniert sftp nicht mehr. Ich kann mich via ssh auf dem remote Rechner anmelden. scp geht auch und bei sftp erscheint nur connection closed das ist mir aufgefallen, als ich sshfs mal wieder benutzen wollte. Hat alles schon mal funktioniert. Localhost host: SuSE 12.3 remote host 12.2 Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am Montag, 19. August 2013, 19:58:46 schrieb Dr. Jürgen Vollmer:
(...). seit neuestem (?) funktioniert sftp nicht mehr. Ich kann mich via ssh auf dem remote Rechner anmelden. scp geht auch und bei sftp erscheint nur
connection closed (...).
Schwierig. Manchmal ist es einfach ein falscher Pfad in der sshd_config für sftp, von wegen 64-Bit oder nicht. Was sagt denn sftp -vvv? Gruß Jan -- If there is an opinion, facts will be found to support it. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Jan, Am Mittwoch, 21. August 2013, 18:17:17 schrieb Jan Ritzerfeld:
Am Montag, 19. August 2013, 19:58:46 schrieb Dr. Jürgen Vollmer:
(...). seit neuestem (?) funktioniert sftp nicht mehr. Ich kann mich via ssh auf dem remote Rechner anmelden. scp geht auch und bei sftp erscheint nur
connection closed (...).
Schwierig. Manchmal ist es einfach ein falscher Pfad in der sshd_config für sftp, von wegen 64-Bit oder nicht. Was sagt denn sftp -vvv?
sftp -v -o port=XYZ USER@DOMAIN OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug1: Connecting to DOMAIN [1.2.3.4] port XYZ. debug1: Connection established. debug1: identity file /home/...../.ssh/id_rsa type 1 debug1: identity file /home/..../.ssh/id_rsa-cert type -1 debug1: identity file /home/.../.ssh/id_dsa type -1 debug1: identity file /home/.../.ssh/id_dsa-cert type -1 debug1: identity file /home/.../.ssh/id_ecdsa type -1 debug1: identity file /home/.../.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0 debug1: match: OpenSSH_6.0 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA 1.2:3.4.... debug1: Host '[DOMAIN]:XYZ' is known and matches the RSA host key. debug1: Found key in /home/.../.ssh/known_hosts:9 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/.../.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to DOMAIN (1.2.3.4]:XYZ). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 debug1: Sending subsystem: sftp debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK Transferred: sent 2640, received 1992 bytes, in 0.1 seconds Bytes per second: sent 25285.7, received 19079.2 debug1: Exit status 127 Connection closed
Das wars, die konkreten Domainnamen, Ports etc habe ich maskiert Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
Am Donnerstag, 22. August 2013, 17:40:25 schrieb Dr. Jürgen Vollmer:
Hallo Jan,
Am Mittwoch, 21. August 2013, 18:17:17 schrieb Jan Ritzerfeld:
Am Montag, 19. August 2013, 19:58:46 schrieb Dr. Jürgen Vollmer:
(...). seit neuestem (?) funktioniert sftp nicht mehr. Ich kann mich via ssh auf dem remote Rechner anmelden. scp geht auch und bei sftp erscheint nur
connection closed
(...).
Schwierig. Manchmal ist es einfach ein falscher Pfad in der sshd_config für sftp, von wegen 64-Bit oder nicht.
Hast du kontrolliert, ob der Pfad in der sshd_config vom Remote-Host unter "Subsystem sftp" insofern korrekt ist, dass das die Datei mindestens existiert? Bei meiner 12.3 64-Bit steht auch keine 64 in dem Pfad. Bei der 12.2 64-Bit könnte es anders gewesen sein.
Was sagt denn sftp -vvv?
sftp -v -o port=XYZ USER@DOMAIN
Die vielen 'v' waren kein Vertipper. Aber okay ...
(...). debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 debug1: Sending subsystem: sftp
Das sieht gut aus. Folgendes aber nicht mehr.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK (...).
In der ~/.bashrc oder ~/.profile des Benutzer auf dem Remote-Host hast du auch nichts spezielles eingebaut?
Das wars, die konkreten Domainnamen, Ports etc habe ich maskiert
In /var/log/messages auf dem Remote-Host ist auch nichts zu finden? Im Zweifelsfall startest du den sshd auf dem Remote-Host von Hand auf einem anderen Port, wie 2222, mit "/usr/sbin/sshd -ddd -e -p 2222" und den Client mit "sftp -vvv -P 2222 USER@DOMAIN". Gruß Jan -- The first myth of management is that it exists. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Jan, Am Donnerstag, 22. August 2013, 18:14:45 schrieb Jan Ritzerfeld:
Hast du kontrolliert, ob der Pfad in der sshd_config vom Remote-Host unter "Subsystem sftp" insofern korrekt ist, dass das die Datei mindestens existiert? Bei meiner 12.3 64-Bit steht auch keine 64 in dem Pfad. Bei der 12.2 64-Bit könnte es anders gewesen sein.
das war der richtige Hinweis, der Pfad zu sftp-server war in der Config-Datei falsch. Der hat sich wohl im Laufe der Zeit geändert.... sshfs + sftp funktionieren nun wieder. Danke&Bye Jürgen -- Dr.rer.nat. Jürgen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 92 04 87 1 Fax: +49(721) 92 04 87 2 Juergen.Vollmer@informatik-vollmer.de www.informatik-vollmer.de ------------------------------------------------------------------------------- Diese EMail ist elektronisch mittels GPG / PGP signiert. Diese elektronische Unterschrift ist in einem EMail-Anhang enthalten. Leider kann die Signatur ohne die Installation entsprechender Programme weder geprüft noch angezeigt werden. Mehr dazu unter: http://www.gnupg.org oder auch http://www.pgpi.org -------------------------------------------------------------------------------
participants (2)
-
Dr. Jürgen Vollmer -
Jan Ritzerfeld