Bug 197929 - Nautilus/gnome-vfs sftp:// doesn't handle first time login
Nautilus/gnome-vfs sftp:// doesn't handle first time login
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gnome-vfs2 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks: 176344 198694
  Show dependency treegraph
 
Reported: 2006-07-07 09:44 EDT by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-09 18:15:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gnome-vfs-increase-sftp-timeout.patch (408 bytes, patch)
2006-07-07 09:44 EDT, Bastien Nocera
no flags Details | Diff

  None (edit)
Description Bastien Nocera 2006-07-07 09:44:03 EDT
+++ 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)
Gecko/20040510 Galeon/1.3.14

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
established.
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".
Access denied.

AND leaves running ssh processes forever it seems(not zombies)



Version-Release number of selected component (if applicable):
gnome-vfs2-2.6.0-8

How reproducible:
Always

Steps to Reproduce:
1. Open Nautilus.
2. Connect to a host with sftp:// that you never contacted
   before.

    

Actual Results:  
Error messages and leaving running processes as described above.


Expected Results:  
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.

Additional info:

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 alexl@redhat.com 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
Comment 1 Bastien Nocera 2006-07-07 09:44:05 EDT
Created attachment 132050 [details]
gnome-vfs-increase-sftp-timeout.patch
Comment 2 Bastien Nocera 2006-07-07 09:45:56 EDT
This is the upstream bug for doing this properly:
http://bugzilla.gnome.org/show_bug.cgi?id=346888
Comment 3 Alexander Larsson 2006-07-26 13:20:53 EDT
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
2.8.0 unfortunately.

I'm not sure how the timeout is related to this though. Bastien, could you
explain more?
Comment 4 Bastien Nocera 2006-08-21 08:04:15 EDT
Hmm, I'm not sure the original description of the bug is exactly the one
encountered. The problem was:

---8<---
- 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
---8<---

And it should actually give an "Access denied" error.

This was already fixed upstream with:
http://cvs.gnome.org/viewcvs/gnome-vfs/modules/sftp-method.c?r1=1.29&r2=1.30

We just don't get to see the error because it doesn't wait long enough for the
whole output to show.
Comment 5 Alexander Larsson 2006-08-22 08:23:21 EDT
Ok. Then the patch looks ok to me.
Comment 7 RHEL Product and Program Management 2006-10-09 18:05:28 EDT
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.
Comment 8 RHEL Product and Program Management 2006-10-09 18:15:08 EDT
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.