Bug 897

sftp://localhost/ worked on TDE 3.5.12, but is broken on my TDE 3.5.13 on wheezy.

Squeeze with 3.5.13 on more than one machine. SFTP works fine here in konqueror over LAN using sftp://username@url:port_number (url is, e.g., 192.168.0.5)

In /etc/hosts:

127.0.0.1 localhost
127.0.0.1 my_hostname

On a fresh Squeeze install it was necessary to do, before incoming connections were accepted: 

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
ssh-keygen -t rsa -f /etc/ssh/ssh_host_dsa_key
/etc/init.d/ssh restart

Keys were generated  without passphrase.

Not on my debian wheezy. 

I started wireshark to monitor lo, then I started "konqeror sftp://127.0.0.1/". wireshark did not pick any packages. I ran that test several times with different target hosts. It's always the same result: the sftp kioslave does not send any packages.

This is still broken in current R14. I have captured a log that might help with debug:

http://www.3111skyline.com/dl/dt/tde/err/sftp-kio/sftp-output.txt

This is still broken in current R14. I have captured a log that might help with debug:

http://www.3111skyline.com/dl/dt/tde/err/sftp-kio/sftp-output.txt

This bug should be fixed in GIT hash e72f492.

Please test and report back with your results!

Tim,

  Here is the latest information on isolating the reason the port information is not returned to the kioslave when talking to ssh (requiring manual entry of non-standard port in 'sftp://myhost:nonStdPort'. This is a quick recap to document the issue. The problem appears to be in kio_sftp.cpp:

    if( port > 0 )
        mPort = port;
    else {
        struct servent *pse;
        if( (pse = getservbyname("ssh", "tcp") ) == NULL )
            mPort = 22;
        else
            mPort = ntohs(pse->s_port);
    }

  Lukas Fisher (the author) originally implemented getservbyname to obtain the port in Feb. 2002 (see CHANGELOG):

2-19-2002
  - get() now emits mimetype, fixes problem with konqi not downloading file for viewing in kpart.
  - get port number using getservbyname instead of hard coding it.

  Apparently the change in ssh output that deleted a line of output has broken this part of the code. I think by simply fixing how getservbyname reads the output and telling it to read line '5' instead of line '6' now would probably fix this problem. I think this also explains why the problem you found with select() getting stuck occurs. Here are examples of the ssh output between openssh 5.0 and openssh 5.9. Note that line '5' from the 5.0 output has been deleted from ssh output in 5.9. So if the getservbyname is looking for IP and port in line '6' of the output, it will never find it because that information was already read and discarded in line '5':

===== OpenSSH_5.0p1 =====

08:10 nemesis:~> ssh -v -p 6662 archangel.3111skyline.com
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/david/.ssh/config
debug1: Applying options for archangel.3111skyline.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to archangel.3111skyline.com [192.168.6.14] port 6662.
debug1: Connection established.
<snip>

===== OpenSSH_5.9p1 =====

21:02 archangel:/dat_e> ssh -v nirvana
OpenSSH_5.9p1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/david/.ssh/config
debug1: /home/david/.ssh/config line 26: Applying options for nirvana
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to nirvana [192.168.6.17] port 6660.
debug1: Connection established.
<snip>

  So rather than nuking the code with getservbyname, I think fixing it will solve the problem as it was originally implemented by Fisher to do exactly what we need it to do now.

Tim,

  Scrap that. The getservbyname is just a lookup for the port from /etc/services. It will never get the port information from ~/.ssh/config that is needed. That must be done in some other part of the kioslave.

  We have been thinking about this thing 'bass-ackwards'. All sftp has to do is read what 'ssh' spits out upon connection. You don't care about reading any config files prior to calling 'ssh', 'ssh' takes care of that for you automagically!

  Think about it:

13:43 providence:~/tde/tmp/patch/tdebase/kioslave/sftp> ssh -v phoenix
OpenSSH_5.9p1, OpenSSL 1.0.1a 19 Apr 2012
debug1: Reading configuration data /home/david/.ssh/config
debug1: /home/david/.ssh/config line 36: Applying options for phoenix
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to phoenix [192.168.7.15] port 6630.
debug1: Connection established.

  When ssh is called, it reads BOTH /etc/ssh/ssh_config and ~/.ssh/config and acts accordingly. This means the only reason sftp://hostname fails when ssh is on a non-standard port is that the sftp:// code is NOT interpreting the ssh response correctly and is erroneously closing a perfectly good connection that ssh has established. Basically -- the sftp code just gets stuck waiting on some response that has changed in the new openssh -- doesn't know what to do with the response it gets -- and just sits there until it times out with an error.

  You will have to be the wizard that figures out where this happens, but is suspect it is in ksshprocess with the version tables that are set up at the top of the file :)

I think the issue will be in ksshprocess.h

class KSshProcess {
...
    enum SshError {
    ...
      There will be no error that is recognized
    ...
    /**
     * Get the ssh version.
     *
     * @return  The ssh version or -1 if KSshProcess does not recognize
     *          the ssh version. The returned value corresponds to the
     *          member of the SshVersion enum.
     */
    SshVersion version();
    ...
      Possible error here, but it does connect on std port 22
      so the issue must be in reading the return string on non-standard
      port only.
    ...
    /**
     * Whether a ssh connection has been  established with a
     * remote host.  A establish connection means ssh has successfully
     * authenticated with the remote host and user data can be transfered
     * between the local and remote host.  This cannot return
     * true unless the most recent call to KSshProccess::connect() returned true.
     *
     * @return True if a ssh connection has been established with a remote
     *         host. False otherwise.
     */
    bool connected() { return mConnected; }
    ...
      This looks like a likely spot where sftp is getting hung up. It
      just doesn't know it is connected for some reason.
    ...
    /**
     * Whether a ssh process is currently running.  This  only indicates
     * if a ssh process has been started and is still running.  It does not
     * tell if authentication has been successful.  This may return true
     * even if the most recent call to KSshProcess::connect() returned false.
     *
     * @return True if a ssh process started by this instance of KSshProcess
     *         is running. False otherwise.
     */
    bool running() { return mRunning; }
    ...
      Like bool connected() above, this may be where sftp is just
      confused based on the ssh response.
    ...
    bool connect();
    ...
      Same potential confusion here
    ...

  I don't know if this will help, but I thought it might at least give you a starting place to look at. We're counting on the White Wizard...

kio_sftp.cpp beginning line 607:

    // Start the ssh connection process.
    //

    int err;           // error code from KSshProcess
    TQString msg;       // msg for dialog box
    TQString caption;   // dialog box caption
    bool firstTime = true;
    bool dlgResult;

I think it skips this entire while loop because it is connected...

    while( !(mConnected = ssh.connect()) ) {
        err = ssh.error();
        kdDebug(KIO_SFTP_DB) << "openConnection(): "
            "Got " << err << " from KSshProcess::connect()" << endl;

        switch(err) {
... stuff
        default:
            infoMessage(i18n("Connection failed."));
            caption = i18n("Unexpected SFTP error: %1").arg(err);
            msg = ssh.errorMsg();
            messageBox(Information, msg, caption);
            closeConnection();
            error(ERR_UNKNOWN, msg);
            return;
        }

Then gets stuck waiting for 's >> type;' or something like that.. Because if it was executing the while loop you should at least get the default: dialog -- but that doesn't happen. IIRC, it just sits there until a timeout occurs when the remote host is on a non-standard ssh port.

Created attachment 558 [details]
Final patch applied by Tim fixing sftp_kio.cpp

This patch was uploaded to preserve its availability to other projects that use the kde3 kioslave/sftp code. It has already been applied in Trinity.

Fixed with:

http://git.trinitydesktop.org/cgit/tdebase/commit/?id=073dc86aceaa060597d7653747c3c6c14d0ed59d