It is common to secure your network setup by restricting access to your servers by placing them in internal subnets. In this case you will have a bastion host server that you must use to jump through to get to your instance. Sonic provides built-in support for a bastion host.
You can configure the settings.yml file to use a bastion host. Here’s an example:
bastion: # cluster_host mapping default: firstname.lastname@example.org prod: email@example.com stag: firstname.lastname@example.org
The configuration specifies a bastion for the specific clusters. If the cluster is not in the configuration it defaults to the default bastion host setting.
sonic ssh --cluster prod [IDENTIFER] # email@example.com used as the bastion host sonic ssh --cluster stag [IDENTIFER] # firstname.lastname@example.org used as the bastion host sonic ssh --cluster whatever [IDENTIFER] # email@example.com used as the bastion host
The settting directs the
sonic ssh to jump through the bastion host. This works completely transparently. The sonic commands are exactly the same as if there is no bastion host. Examples:
sonic ssh i-0f7f833131a51ce35
You should notice that the built up command now includes the bastion jump host.
$ sonic ssh i-0f7f833131a51ce35 uptime => ssh -At firstname.lastname@example.org ssh email@example.com uptime Warning: Permanently added '220.127.116.11' (ECDSA) to the list of known hosts. Warning: Permanently added '10.10.110.135' (ECDSA) to the list of known hosts. 18:35:18 up 1:14, 0 users, load average: 0.24, 0.07, 0.02 Connection to 18.104.22.168 closed. $
You can also specify the bastion host as a CLI option with
--bastion, though it is recommended that you configure it in a
settings.yml file so you do not have to repeatedly type it.
Pro tip: Use the <- and -> arrow keys to move back and forward.