[arch-general] Thunar sftp connection not working - access denied

[Kyle Terrien]

On 10/13/2015 10:55 AM, Friedrich Strohmaier wrote:
> Hi Kyle, *,
> 
> Am 12.10.2015 um 17:29 schrieb Kyle Terrien:
>> On 10/09/2015 05:54 PM, Friedrich Strohmaier wrote:
>>> Am 10.10.2015 um 02:23 schrieb Leonid Isaev:
>>>> On Sat, Oct 10, 2015 at 02:05:38AM +0200, Friedrich Strohmaier wrote:
> 
>>>>> Hi Folks,
> 
>>>>> since some time I cannot get thunar connect my remote servers folders via sftp.
> 
> [..]
> 
>>>> So, does sftp work from the command line?
> 
>>> yes works as expected.
> 
>>> btw. filezilla also does..
> 
>> As a workaround, you can use sshfs.  sshfs will mount a remote
>> filesystem over ssh.
> 
>> I use sshfs quite a bit with Thunar.  Thunar lists the mount as an
>> external drive.
> 
> I know about this but well, it used to work and has stopped doing so, now.
> 
> digging a bit deeper..
> It apears to be a problem of ssh-key authentification.
> 
> While trying to connect a host with exclusvive ssh-key access, journalctl tells:
> ========
> Oct 13 19:36:08 my_machine gvfsd[758]: ### SFTP: spawn_ssh: ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -l me -s strict.remote.host sftp
> Oct 13 19:36:08 my_machine gvfsd[758]: ### SFTP: handle_login #1, initial_connection = 1 - user: me, host: strict.remote.host, port: -1
> Oct 13 19:36:09 my_machine gvfsd[758]: ### SFTP: handle_login #1 - password_save: 0
> Oct 13 19:36:09 my_machine gvfsd[758]: ### SFTP: handle_login #1 - ret_val: 1
> Oct 13 19:36:09 my_machine gvfsd[758]: ### SFTP: stderr: Permission denied (publickey).
> Oct 13 19:36:09 my_machine gvfsd[758]: ** (gvfsd:758): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Zugriff verweigert
> =======
> 
> This happens connecting a host allowing password authentication:
> =======
> Oct 13 19:36:28 my_machine gvfsd[758]: ### SFTP: spawn_ssh: ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -l me -s permissive.remote.host sftp
> Oct 13 19:36:28 my_machine gvfsd[758]: ### SFTP: handle_login #1, initial_connection = 1 - user: me, host: permissive.remote.host, port: -1
> Oct 13 19:36:34 my_machine gvfsd[758]: ### SFTP: handle_login #1 - prompt: "me at permissive.remote.host's password: "
> Oct 13 19:36:34 my_machine gvfsd[758]: ### SFTP: handle_login #1 - asking for password...
> Oct 13 19:36:51 my_machine gvfsd[758]: ### SFTP: handle_login #1 - prompt: ""
> Oct 13 19:36:53 my_machine gvfsd[758]: ### SFTP: handle_login #1 - password_save: 0
> Oct 13 19:36:53 my_machine gvfsd[758]: ### SFTP: handle_login #1 - ret_val: 1
> Oct 13 19:36:53 my_machine gvfsd[758]: ### SFTP: spawn_ssh: ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -l me -s permissive.remote.host sftp
> Oct 13 19:36:53 my_machine gvfsd[758]: ### SFTP: handle_login #2, initial_connection = 0 - user: me, host: permissive.remote.host, port: -1
> Oct 13 19:36:59 my_machine gvfsd[758]: ### SFTP: handle_login #2 - prompt: "me at permissive.remote.host's password: "
> Oct 13 19:36:59 my_machine gvfsd[758]: ### SFTP: handle_login #2 - using credentials from previous login attempt...
> Oct 13 19:36:59 my_machine gvfsd[758]: ### SFTP: handle_login #2 - prompt: ""
> Oct 13 19:36:59 my_machine gvfsd[758]: ### SFTP: handle_login #2 - ret_val: 1
> ========
> 
> Any ideas?
> Is this a gvfsd bug?

Considering that CLI sftp and Filezilla work, this is probably a GVFS
related issue.

The part of the log output that sticks out like a sore thumb are the
lines that look like this:

> Oct 13 19:36:08 my_machine gvfsd[758]: ### SFTP: handle_login #1, initial_connection = 1 - user: me, host: strict.remote.host, port: -1

"port: -1" just doesn't seem right.  At best this means "use the default
port".  But you would think that if it uses the default port, then the
log would say "port: 22".

At worst, this means literally "use port -1", which means that -1 could
overflow in unsigned integer arithmetic so it is actually a really high
port.

Have you tried running the ssh commands yourself?

> Oct 13 19:36:08 my_machine gvfsd[758]: ### SFTP: spawn_ssh: ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -l me -s strict.remote.host sftp
> Oct 13 19:36:28 my_machine gvfsd[758]: ### SFTP: spawn_ssh: ssh -oForwardX11 no -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -oProtocol 2 -oNoHostAuthenticationForLocalhost yes -l me -s permissive.remote.host sftp

--Kyle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20151015/35e6ae10/attachment.asc>