[arch-general] Thunar sftp connection not working - access denied
Hi Folks, since some time I cannot get thunar connect my remote servers folders via sftp. Error dialog: Failed to open "/my/remote/path on my.server" access denied ssh access works as expected. I feel like it stopped working after I got this arch announce: https://www.archlinux.org/news/d-bus-now-launches-user-buses/ System: recent arch x86_64 xfce4 4.12 I didn't find anything useful by net search, so my question here: Did anyone else get hit by this? Is there likely a relation to changes in D-Bus. Any hint to nail down this one appreciated. -- Friedrich
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.
Error dialog: Failed to open "/my/remote/path on my.server" access denied
ssh access works as expected.
I feel like it stopped working after I got this arch announce: https://www.archlinux.org/news/d-bus-now-launches-user-buses/
So, does sftp work from the command line? Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi Leonid, *, 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.
Error dialog: Failed to open "/my/remote/path on my.server" access denied
ssh access works as expected.
I feel like it stopped working after I got this arch announce: https://www.archlinux.org/news/d-bus-now-launches-user-buses/
So, does sftp work from the command line?
yes works as expected. btw. filezilla also does.. -- Friedrich
On 10/09/2015 05:54 PM, Friedrich Strohmaier wrote:
Hi Leonid, *,
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.
Error dialog: Failed to open "/my/remote/path on my.server" access denied
ssh access works as expected.
I feel like it stopped working after I got this arch announce: https://www.archlinux.org/news/d-bus-now-launches-user-buses/
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. --Kyle
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@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@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? -- Friedrich
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@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@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
Hi Kyle, *, Am 15.10.2015 um 17:56 schrieb Kyle Terrien:
On 10/13/2015 10:55 AM, Friedrich Strohmaier wrote:
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..
[..]
digging a bit deeper.. It apears to be a problem of ssh-key authentification.
Log output uploaded: https://bits-fritz.de/eigene_webdateien/File/bereitstellung/messages.txt
Any ideas? Is this a gvfsd bug?
Considering that CLI sftp and Filezilla work, this is probably a GVFS related issue.
New facts but no solution.. After dbus update I restarted dbus by hand: Restarting dbus as root yields: ========= [root@myhost ~]# systemctl restart dbus PolicyKit daemon disconnected from the bus. We are no longer a registered authentication agent. ========= After new Loggin in XFCE - tataaa sftp-connection is established without issues. Cannot shutdown machine out of xfce session and have other quirks but this one works. After machine restart old behaviour is back. This tells me something's wrong with PolicyKit settings? Forgot to mention: ssh-agent running (started by keychain)
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.
most likely this isn't a problem, as successful actions also have this values.
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
I did (had to replace spaces with "=" between -oXX options and values). No result but - mmmhh - a "waiting" prompt. It appeared like opening a tunnel. Kyle, many thanks for keeping up! :o)) -- Friedrich
On 10/29/2015 06:06 PM, Friedrich Strohmaier wrote:
Hi Kyle, *,
Am 15.10.2015 um 17:56 schrieb Kyle Terrien:
On 10/13/2015 10:55 AM, Friedrich Strohmaier wrote:
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..
[..]
digging a bit deeper.. It apears to be a problem of ssh-key authentification.
Log output uploaded: https://bits-fritz.de/eigene_webdateien/File/bereitstellung/messages.txt
Any ideas? Is this a gvfsd bug?
Considering that CLI sftp and Filezilla work, this is probably a GVFS related issue.
New facts but no solution..
After dbus update I restarted dbus by hand: Restarting dbus as root yields: ========= [root@myhost ~]# systemctl restart dbus PolicyKit daemon disconnected from the bus. We are no longer a registered authentication agent. =========
Dbus is tied into almost everything nowadays. Restarting it can do all sorts of interesting things.
After new Loggin in XFCE - tataaa sftp-connection is established without issues. Cannot shutdown machine out of xfce session and have other quirks but this one works.
After machine restart old behaviour is back.
This tells me something's wrong with PolicyKit settings?
So, if PolicyKit is not registered as an authentication agent, gvfs SFTP works. I'm guessing it is falling back to some other authentication agent.
Forgot to mention: ssh-agent running (started by keychain)
Maybe ssh-agent is the fallback.
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
I did (had to replace spaces with "=" between -oXX options and values). No result but - mmmhh - a "waiting" prompt. It appeared like opening a tunnel.
Kyle, many thanks for keeping up! :o))
I would have to look up those ssh options. They could very well create a tunnel. In your log file:
Oct 30 00:22:22 my_machine gvfsd[1047]: ** (process:1315): WARNING **: Failed to setup SSH evironment: The name org.gnome.keyring was not provided by any .service files (g-dbus-error-quark, 2)
Is gnome-keyring installed? It looks like gvfs (being a GNOME application) is trying to start GNOME keyring. I switched pretty much everything to gpg-agent. In .xinitrc I have this: # Start the GnuPG agent and enable OpenSSH agent emulation gnupginf="${HOME}/.gpg-agent-info" if pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then eval `cat $gnupginf` eval `cut -d= -f1 $gnupginf | xargs echo export` export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh" else eval `gpg-agent -s --enable-ssh-support --daemon --write-env-file "$gnupginf"` fi It uses some old options that I should probably clean up, but it still starts and works. But you will need to kill it with 'pkill gpg-agent' before logging out. I only use gnome-keyring-daemon on my laptop for keeping track of Wifi passwords in NetworkManager. Feel free to look at my configuration at <https://github.com/KlipperKyle/dotfiles/blob/master/xautorun> (.xautorun is sourced by .xinitrc. Then .xinitrc calls my window manager.) If I get the chance, I might try to remove gnome-keyring-daemon and see what happens if I use gvfs. --Kyle
Hi Kyle, *, Am 02.11.2015 um 07:43 schrieb Kyle Terrien:
Am 15.10.2015 um 17:56 schrieb Kyle Terrien:
On 10/13/2015 10:55 AM, Friedrich Strohmaier wrote:
> On Sat, Oct 10, 2015 at 02:05:38AM +0200, Friedrich Strohmaier wrote:
>> since some time I cannot get thunar connect my remote servers folders via sftp.
[..]
Is this a gvfsd bug?
Considering that CLI sftp and Filezilla work, this is probably a GVFS related issue.
It definitly is :o)) https://bugs.archlinux.org/task/46398 [..]
Is gnome-keyring installed?
No, don't use it.. ssh-agent is running fine - gvfsd doesn't get the environment and thus can't see this. [..] So workaround is in place an one more vote set for the mentioned bug. Thanks for Your help. -- Friedrich
participants (3)
-
Friedrich Strohmaier
-
Kyle Terrien
-
Leonid Isaev