SSH Key Authentication

[dmtrTm]

Hello!
when will ssh key authentication be implemented?

[abulka]

Presumably this is why I get prompted for a password each time, even though I have set up the ssh keys and created entries in ~/.ssh/config.

[allanrbo]

It actually already supports key auth via an authentication agent. So, by running the ssh-add somekey command before FilesRemote on Mac/Linux, or running for example pageant.exe beforehand on Windows. The reason I personally use this type of ssh key auth is because it allows me to have password protected private keys that I only need to unlock once when I reboot my PC.

Does this satisfy your needs @dmtrTm and @abulka , or do you specifically need it to load keys listed in .ssh/config? Or alternatively, would a CLI flag with a path to a key file be good enough? (easier than parsing the .ssh/config file...)

Really appreciate your feedback, thanks!

(Apologies for the delayed response. Hadn't email notifications for this repo turned on till now.)

[allanrbo]

Hi @dmtrTm and @abulka . I have added functionality to use the keys configured in .ssh/config in version 1.4 available now. Hope this will be useful!

[dmtrTm]

Hi, @allanrbo !
Tried cli-flag, works great! Thank you very much for the development!

[abulka]

Thanks for adding this - great!

I no longer get prompted for a password when connecting to an ip address on my local network, and can even add the handy text host name specified in ~/.ssh/config as an entry to filesremote, and it connects OK.

However attempting to connect to a remote ip address by host name gives me

Failed to resolve hostname myplace (gethostnbyname failed)

I checked and my ~/.ssh/config has an entry

Host myplace
  HostName 104.xx.xx.xx
  User root

Note that I can ssh myplace using the terminal OK. And filesremote does connect ok with the ip address entry root@104.xx.xx.xx, and SSH works (no password prompting). But not with the host entry myplace.

Clue: I did notice when attempting to connect using the entry myplace that andy@myplace:22 appears on the filesremote titlebar - which is not right, it should be pulling out the User root from my ~/.ssh/config, should it not? So I tried helping things along and creating a fileremote entry root@myplace which then correctly? displays on the titlebar as root@myplace:22 when connecting, but still fails to connect with the above error message.

[allanrbo]

I think I understand the problem. The integration I did with the .ssh/config file thus far is quite minimal. It just checks if the host name given to FilesRemote in the "Connect to SSH/SFTP server" dialog (or the host CLI param) matches a Host-line in .ssh/config. If so, then it uses the IdentityFile from there.

But I realize now that what I have implemented is kind of wrong, because the Host-line could be any arbitrarily chosen name. As you said, it's just a handy text host name. Not necessarily a true DNS name or Samba host name. I guess that's what the HostName-line is for. It just happened to be that in my personal config I always chose to put DNS names in the Host-lines, and didn't have any HostName lines.

So, said differently, currently FilesRemote can only be given IP addresses or resolvable DNS names. Not "aliases" defined in .ssh/config. Though if it happens to be that there's a Host-section in the .ssh/config that matches this IP or DNS name, then it will use the IdentityFile from there.

This also explains why it is not taking the username from your .ssh/config. It's currently only the IdentityFile it's taking from there. If you connect FilesRemote to a hostname without giving a someuser@, then it will default to the currently logged in user on your local machine. But it's a good idea to pull the username from there too. There might be many other params too that would make sense to pull from there. Will need to think about where to draw the line - hoping it won't be a can of worms :-)

I will try to make time soon to align better with how the openssh client behaves. Have opened issue #4 to track this.

Till then, here's a suggestion for a workaround:

Make an entry like this in your .ssh/config:

Host 10.0.0.42
    IdentityFile ~/ssh/somekey

And then a matching entry in the "Favorite hosts": root@10.0.0.42. Or if you connect from the command line rather than the connection dialog window, then do filesremote root@10.0.0.42.

Thanks for taking the time to explain your use case. I value your feedback!