Bug 197929

Summary: Nautilus/gnome-vfs sftp:// doesn't handle first time login
Product: Red Hat Enterprise Linux 4 Reporter: Bastien Nocera <bnocera>
Component: gnome-vfs2Assignee: Alexander Larsson <alexl>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-09 22:15:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 176344, 198694    
Attachments:
Description Flags
gnome-vfs-increase-sftp-timeout.patch none

Description Bastien Nocera 2006-07-07 13:44:03 UTC
+++ 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 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 13:44:05 UTC
Created attachment 132050 [details]
gnome-vfs-increase-sftp-timeout.patch

Comment 2 Bastien Nocera 2006-07-07 13:45:56 UTC
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 17:20:53 UTC
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 12:04:15 UTC
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 12:23:21 UTC
Ok. Then the patch looks ok to me.

Comment 7 RHEL Program Management 2006-10-09 22:05:28 UTC
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 Program Management 2006-10-09 22:15:08 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.