Anybody experiencing this?
On my laptop with M5 / Factory and KDE4 4.6 RC1 and RC2 fish:// and sftp:// are not working in Dolphin and Konqueror. On the server side I see a connection has been established, yet Dolphin & Konqueror are not aware of it, remote folders are not being displayed.
It was OK for me earlier (fish://)
Can’t check right now, it’ll be early morning now before I can double check
fish:// Confirmed working on RC2
Re: sftp://
I have issues with it on all Distros. In all cases, it’s communicating, in that the Password box opens (as I have a Password for Access as well), but then the connection fails.
Eg:
http://thumbnails24.imagebam.com/9088/13971190873799.jpg](http://www.imagebam.com/image/13971190873799)
That’s a image from a while back and a Gnome machine doing sftp.
However ssh in the terminal, in all cases, works fine.
fish:// Confirmed working on RC2
Re: sftp://
I have issues with it on all Distros. In all cases, it’s communicating, in that the Password box opens (as I have a Password for Access as well), but then the connection fails.
For me it’s the other way round. In RC2, both dolphin and konqueror, fish:// ends up in limbo whereas sftp:// works as expected. No problems in 4.5.5.
Current situation:
sftp:// returns a password failure
fish:// does not appear to connect at all.
Did you try cleaning out .ssh of the known hosts file to re-stablish the link to the server?
This results in the question to accept the key, so a connection is made. But that’s where it stops, remote directory is not loaded. Firewall is OFF, BTW.
Looks like the kio_fish does not work for some reason. It’s the same on the Factory LiveCD’s. SSH based connections in GNOME work perfect.
I still have not finiished exhaustive tests – connections in both directions with combinations of openSuSE-11.3 and Factory. (and have coincidentally uncovered a bug in a rented host). At the moment it seems that the failure is in password authentication; using passwords fails for both sftp:// and fish://, whereas public key authentication (without a passphrase) works. I will try public key with a passphrase / authorized_keys next. When attempting password aurhentication the process goes into limbo (eternally attempting to connect) whether the proferred password is correct or incorrect…
