Score:0

Unable to ssh using ProxyJump but it works with ssh -J

cn flag

My question is: How do I set up a bastion host for ssh on AWS using an ubuntu instance?

I can do the following with success:

root@e183d80cdabc# ssh -J [email protected] [email protected]
Last login: Sat Sep  4 13:14:17 2021 from 10.240.0.30
==> SUCCESS! ==> ubuntu@ip-10-240-0-20:~$

But it fails when I try the ~/.ssh/config file approach. Commands used:

# ssh 10.240.0.20
# ssh [email protected]
# ssh -i ~/.ssh/id_rsa [email protected]

ssh: connect to host 10.240.0.20 port 22: Connection refused

My ~/.ssh/config looks like this:

root@e183d80cdabc# cat $HOME/.ssh/config
Host bastion
  HostName 54.170.186.144
Host remote
  HostName 10.240.0.20
  ProxyJump bastion

I am running ubuntu on AWS as follows:

ubuntu@ip-10-240-0-30:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

I have tried adding the User ubuntu field but this does not help.

My /etc/ssh/ssh_config on the server looks like this:

Host *
    ForwardX11Trusted yes
    IdentityFile ~/.ssh/id_rsa
    Port 22
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

UPDATE I am now using the verbose option i.e.

root@e183d80cdabc# ssh -vvv 10.240.0.20
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 2: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 10.240.0.20 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.240.0.20 [10.240.0.20] port 22.
debug1: connect to address 10.240.0.20 port 22: Connection refused
ssh: connect to host 10.240.0.20 port 22: Connection refused

It appears not to be using any jump host (i.e. it skips the bastion) and is going directly, and FAILS.

Any ideas greatly appreciated! Thank You

=========================================================

UPDATE: 2021-09-04-15-44 - with SOLUTION Thanks all, I have marked as answer, below.

The correct config does not use HostName, as the matching is done on Host. I was also able to include a wildcard on the ip address, which is what I was really after.

ssh config

root@e183d80cdabc# cat $HOME/.ssh/config
Host bastion
  HostName 63.33.206.201
  User ubuntu
Host 10.240.0.*
  ProxyJump bastion
  User ubuntu

And voila!

# ssh 10.240.0.20
...
ubuntu@ip-10-240-0-20:~$
anx avatar
fr flag
anx
Don't copy ssh *private* keys, keeping them securely stored locally is the whole *point* of this mechanism.
in flag
When it doubt run ssh with extra verbosity `ssh -vvv ... remote`.
cn flag
Thanks anx --> verified today that I do not need to copy the private key anywhere - it works with the -J commandline without copying. But it still does not work with the simple command ssh <ip address> along with the ~/.ssh/config file containing all of the paramters (including "User ubuntu")
cn flag
Thanks zoredache - updated with -zzz output above.
anx avatar
fr flag
anx
I'll edit out the dangerous parts of your question.. feel free to dedicate a separate question to those, but I am fairly certain duplicates already exist for those.
Score:3
fr flag

The matching is done on Host stanza, not on HostName.

Try:

ssh ubuntu@remote
cn flag
Yipee! This is the answer, thanks a million Tomek! Please see my update @ 2021-09-04-15 (in the original question above) which adds additional support for using a specific IP address and a wildcard to include the subnet range Great work, thanks!
Score:3
fr flag
anx

The difference between your command line

ssh -J [email protected] [email protected]

and what I recommend you do to reference your configuration

ssh remote

is that the latter has neither IPs nor the user to login to on both machines in the command line - you have to edit your ssh configuration to include all the information you are no longer passing on the command line:

# $HOME/.ssh/config
### The Bastion Host
Host bastion
  HostName 54.170.186.144
  User ubuntu

### The Remote Host
Host remote
  HostName 10.240.0.20
  User ubuntu
  ProxyJump bastion

Update: While yes, in theory you can configure your Host stanzas to match IP addresses, I recommend against doing so.

If a host is not directly reached with a certain IP address, then it should be referred to by name - just imagine what happens when you have the same (private) IP space assigned to multiple hosts, you could not possibly assign the correct ProxyJump configuration for each.

Another reason where using addresses to refer to hosts is unfavourable is hosts reachable via multiple address families: If a host is reachable through IPv4 and IPv6, you probably want your ssh connection remain protocol-agnostic and only add a flag when you really mean to limit (automatic) choices.

cn flag
thanks anx. Yes, unfortunately the above gives exacy the same i.e. does not work. Thanks for your response!
cn flag
Please see final answer - the issue is to do with matching - adding the User field alone will not help - it needs to match the correct config. I was using HostName and should have used host to do the match. Thanks for your help anx!
anx avatar
fr flag
anx
@Banoona Yes, you should refer to hosts by how they are called in the `Host` line in your config. But I also believe those should be (ideally: canonical *host*) names, not addresses.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.