Failure connecting through jump server with alias in configuration for target host

[cyberduck]

142adc1 created the issue

Hi,

I've read that Cyberduck can use configuration data from ~/.ssh/config in order to connect to SFTP servers. Specifically, I need this because I need to connect via a bastion server (Proxyjump option).

From the wiki page, I really can't understand how to configure a new connection which will use the config info. Should I use the Host value from the config file as the server's nickname in Cyberduck? Or as the server's nickname?

Thank you in advance for your help…

[cyberduck]

@dkocher commented

Please make sure to run the current snapshot build of [milestone:7.7 7.7] as version 7.6.2 does not yet have this feature. The bookmark configuration refers to the target host in the internal network. We should find a ProxyJump directive in the OpenSSH configuration ~/.ssh/config matching the hostname in the bookmark.

[cyberduck]

@dkocher commented

Refer to Connect via SSH tunnel through bastion server.

[cyberduck]

142adc1 commented

Hi!

Thanks for your reply. I got version 7.7.0 (33716) running but the bastion connection still isn’t working for me. I think I may be misunderstanding part of the terminology. Allow me to explain my setup:

.ssh/config:

Host Winnie
	[various settings]
	HostName winnie.address.com

Host RedCapNew
	[settings]
	HostName redcap.address.com
	ProxyJump Winnie

When I use ssh, I can just ssh RedCapNew and everything works fine.

Cyberduck fails without errors—which is what I’d expect from an app trying to connect to RedCapNew directly, without a bastion…

In Cyberduck, I’ve entered redcap.address.com in the Server: field of the bookmark. Is this correct, in order for CyberDuck to match with the config file? Or should I use the Host value in Cyberduck (as opposed to HostName) ?

Thanks again for your help,

—Marco

[cyberduck]

f943cfb commented

Hello.

I'm also using version 7.7.0.
SFTP via bastion using ProxyJump failed.

~/.ssh/config

Host bastion
  User username
  Hostname 14.XXX.XX.XX
Host targetserver
  User username
  Hostname 192.YYY.Y.YYY
  ProxyJump bastion

/var/log/secure on bastion

Nov 13 16:18:31 bastion sshd[3056]: Accepted publickey for username from ZZZ.ZZ.ZZ.ZZZ port 63928 ssh2
Nov 13 16:18:31 bastion sshd[3056]: pam_unix(sshd:session): session opened for user username by (uid=0)
Nov 13 16:18:31 bastion sshd[3097]: subsystem request for sftp
Nov 13 16:18:32 bastion sshd[3097]: error: connect_to targetserver: unknown host (Name or service not known)

Cyberduck is trying to connect to "targetserver", it should connect to 192.YYY.Y.YYY.

I added "192.YYY.Y.YYY targetserver" to /etc/hosts in bastion and it worked.
But I don't think that's a good idea.

Thank you.

[cyberduck]

@dkocher commented

Replying to [comment:3 mbaciarello]:

In Cyberduck, I’ve entered redcap.address.com in the Server: field of the bookmark. Is this correct, in order for CyberDuck to match with the config file? Or should I use the Host value in Cyberduck (as opposed to HostName) ?

You should enter RedCapNew as the hostname to allows to lookup this in your /.ssh/config.

[cyberduck]

@dkocher commented

Replying to [comment:4 ApplePedlar]:

/var/log/secure on bastion

Nov 13 16:18:31 bastion sshd[3056]: Accepted publickey for username from ZZZ.ZZ.ZZ.ZZZ port 63928 ssh2
Nov 13 16:18:31 bastion sshd[3056]: pam_unix(sshd:session): session opened for user username by (uid=0)
Nov 13 16:18:31 bastion sshd[3097]: subsystem request for sftp
Nov 13 16:18:32 bastion sshd[3097]: error: connect_to targetserver: unknown host (Name or service not known)

Cyberduck is trying to connect to "targetserver", it should connect to 192.YYY.Y.YYY.

Thanks for reporting this. We will try to reproduce.

[cyberduck]

142adc1 commented

Cyberduck is trying to connect to "targetserver", it should connect to 192.YYY.Y.YYY.

I can reproduce this error, which is actually reported by Cyberduck in my case. After entering the Host value in the Server: field I finally connected to the bastion, then an alert from Cyberduck came up:

Nodename nor servname provided, or not known. The connection attempt was rejected. The server may be down, or your network may not be properly configured.

I'd say it looks as though Cyberduck entered the Host instead of HostName in the ssh call…

[cyberduck]

@ylangisc commented

In 685cd8c.

[cyberduck]

33574fc commented

Hi,

The feature is still not working for me. I am running Version 7.7.1 (33788) on macOS 11.0.1.

I have set ~/.ssh/config as follows:

Host ServerA
        HostName        ServerA.address
        User            UserX

Host ServerB
        HostName        ServerB.address
        ProxyJump       ServerA
        User            UserY

If I do ssh ServerB from Terminal, everything is working fine.

In Cyberduck, I add a new bookmark using SFTP protocol and set the field "Server:" to "ServerB". It automatically autocompletes the field "Username:" correctly. Then, when I try to connect, it gives me an error Connection failed saying the following:

-DNS lookup for ServerB.address failed. DNS is the network service that translates a server name to its Internet address. This error is most often caused by having no connection to the Internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing access to the network.*

Thank you for your help.

-EDIT:* Could it just be related to the fact that the user in the bastion host is different from the user in the target host? It is not a problem in the config file, since it is working from command line. It also works in Cyberduck when trying to connect to a different remote machine where the user has the same name as that of the bastion host.

[cyberduck]

142adc1 commented

Version 7.7.2 is working fine for me. Not sure if it's in the official release or beta update channel, so in case you want to try it:

Preferences → Update → … check for updates in → Snapshot Builds

I'd close the ticket but trac doesn't show version 7.7.2 in the popup menu, yet…

[cyberduck]

33574fc commented

Thank you, version 7.7.2 is also working for me. I did not notice it because it is not in the official channel yet.

However, the password of the jumphost server is not saved (even if Add to keychain is checked). I tried both password and public key authentications.

I also tried by adding another bookmark with the jumphost only. In that case the password is correctly saved for the access to the jumphost, but when I connect to the target server via the jumphost, it is asked again every time. Is that expected?

[cyberduck]

142adc1 commented

Confirmed, in my case it's mandatory pub key auth, and Cyberduck fails to store the passphrase in Keychain even though the checkbox is ticked and UseKeychain is 'yes' in the bastion host's config.

As a workaround, I had to set the passphrase to my private key to null (ssh-keygen -p), but I can't recommend this because it's relatively insecure.

[cyberduck]

@dkocher commented

The latest snapshot builds with version 7.7.2.x do not have any additional changes regarding SSH jump host support. The DNS error if we cannot resolve the target host (ServerB.address) in the above example should still be reproducible. We will see that we can add a fix to skip trying to resolve addresses that are only reachable from the jump host.

[cyberduck]

@dkocher commented

Replying to [comment:13 ioemilio]:

However, the password of the jumphost server is not saved (even if Add to keychain is checked). I tried both password and public key authentications.

I can confirm this is not currently working as expected and credentials for jump hosts are not saved. As a workaround, set a private key to be used for authenticating with the jump host in the OpenSSH configuration using IdentityFile.

[cyberduck]

@ylangisc commented

In 0c1cd16.

[cyberduck]

@dkocher commented

Can you please try if still see this issue with the current snapshot build
by updating from within Cyberduck in ''Preferences → Update →
Automatically check for updates in → Snapshot Builds''.

[cyberduck]

33574fc commented

It looks like it is working now (with build 33825), and also the password field is already correctly filled in. Thank you!

[cyberduck]

142adc1 commented

Confirmed working… Thanks for the outstanding support.