Red Hat Bugzilla – Bug 197929
Nautilus/gnome-vfs sftp:// doesn't handle first time login
Last modified: 2007-11-30 17:07:26 EST
+++ This bug was initially created as a clone of Bug #123882 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
When first ssh or sftp'ing to a host you're asked to trust the
authentication of the host, e.g.
[noselasd@nos-rh noselasd]$ ssh test.fiane.intra
The authenticity of host 'test.fiane.intra (192.168.170.99)' can't be
RSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)?
Typing sftp://test.fiane.intra/ in Nautilus when never ssh'ed to it
before gives and error:
Couldn't display "sftp://test.fiane.intra".
AND leaves running ssh processes forever it seems(not zombies)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open Nautilus.
2. Connect to a host with sftp:// that you never contacted
Error messages and leaving running processes as described above.
sftp:// ought to work on hosts never contaced before. Possibly
presenting a dialog to verify the hosts authentication just like
the sftp/ssh command line does.
Workaround is to first ssh/sftp to the host from a commandline, and
answer yes to the "Are you sure you want to continue connecting (yes/no)?"
-- Additional comment from firstname.lastname@example.org on 2004-10-15 10:38 EST --
Fixed in gnome 2.8 (in fc3).
Actually, that was fixed later on, but not in FC3 or RHEL4.
Patch (ie. upstream hack) attached
Created attachment 132050 [details]
This is the upstream bug for doing this properly:
This was solved properly in version 1.8 of sftp-method.c by using a QUESTION
callback to the user. This was first released in a stable version in gnome-vfs
I'm not sure how the timeout is related to this though. Bastien, could you
Hmm, I'm not sure the original description of the bug is exactly the one
encountered. The problem was:
- In Nautilus "File" menu select "Connect to Server"
- Select "SSH" as service type
- Insert "127.0.0.1" in "Server" box
- Click on "Connect"
- An icon "127.0.0.1" will be created on desktop but nothing else will happens
And it should actually give an "Access denied" error.
This was already fixed upstream with:
We just don't get to see the error because it doesn't wait long enough for the
whole output to show.
Ok. Then the patch looks ok to me.
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.