In the first chapter, we SSH'd to our VM using one command:

$ ssh adam@127.0.0.1 -p2222
adam@127.0.0.1's password: 
Last login: Mon Aug 6 17:04:31 2018 from gateway
[adam@localhost ~]$

In this chapter, we're going to expand on this, looking at making connecting easier with SSH key pairs; running over the security benefits of SSH; making changes to both the client and server side configuration; setting up a port forward and reverse port forward connections; learning about ProxyJump and bastion hosts, as well as setting up a temporary proxy with SSH; and finally, we're going to look at SSH agents and setting up an additional SSH server on our VM.

This chapter assumes that you have a rudimentary understanding of SSH.

As introduced in the first chapter, we're going to use Vagrant and VirtualBox for all of our work in this chapter and those going forward. This allows us to quickly provision infrastructure for testing, and saves you the manual job of creating multiple VMs each time.

I've put together the following Vagrantfile for use in this chapter:

# -*- mode: ruby -*-
# vi: set ft=ruby :

$provisionScript = <<-SCRIPT
sed -i 's#PasswordAuthentication no#PasswordAuthentication yes#g' /etc/ssh/sshd_config
systemctl restart sshd
SCRIPT

Vagrant.configure("2") do |config|
 config.vm.provision "shell",
 inline: $provisionScript...

Passwords are great, but they're also terrible.

Most people use weak passwords, and while I hope that's not you, there's always the chance that someone in your team doesn't have the discipline you do, and resorts to football99 or similar for connecting to your shared remote host.

With password access enabled, anyone might be able to connect to your server from any country by brute-forcing their way into your machine, given enough time and enough processing power.

Here's where keys come in.

SSH keys are based on...

SSH is a powerful piece of software, as we've already discussed, and while it can be used in a very simple way to enable access to your server, it is also extremely flexible.

In this section, we're going to look at common flags that are used with SSH in environments that may have different requirements.

We will be using the same Vagrant boxes as before.

As with the previous section, confirm that both of your Vagrant boxes are enabled, and connect to the first using the vagrant command:

$ vagrant ssh centos1

While it's nice to be able to manipulate SSH using command-line arguments, it's also nice to not have to bother.

If you've got a system you work on day in and day out, it can be beneficial to configure your setup with your typical arguments on a permanent basis. This is where the client-side SSH configuration file comes in.

On our example box, the default ssh_config file is located in the /etc/ssh/ directory. Open this file to have a look if you like, but don't make any changes yet.

As with the previous section, confirm that both of your Vagrant boxes are enabled, and connect to the first using the vagrant command:

$ vagrant ssh centos1

To configure...

For the last few sections, we've been focusing on the client configuration. We've tweaked our connection string on the command line and we've written a configuration file to be read automatically by SSH when connecting to our second host.

In this section, we're going to take a look at the sshd_config file, or the server-side of the configuration tango, on our second host.

We're going to make a few example and routine changes to get you familiar with the concept.

Connect to both centos1 and centos2. Doing this from outside (in separate windows, and using vagrant ssh) is best:

$ vagrant ssh centos1
$ vagrant ssh centos2

Place your Terminal...

One thing we've not mentioned yet are host keys, and the known_hosts file.

This is something that is often overlooked, so I'd like to take a few minutes to go over these otherwise-ignored treasures.

In this section, we will inspect what happens when you first SSH to a new machine, and then we will change the keys of that machine to see what problems this causes us.

Connect to centos1 and centos2 in different sessions:

$ vagrant ssh centos1
$ vagrant ssh centos2

If you're working on a fresh setup, SSH to centos2 from centos1 and accept the host key when you're presented with it.

Log back out of centos2:

[vagrant@centos1 ~]$ ssh 192.168.33.11
The authenticity...

Confirm that both of your Vagrant boxes are enabled, and connect to both using the vagrant command.

If you've previously changed the SSH configuration file, it might be an idea to destroy your boxes and re-provision them first:

$ vagrant ssh centos1
$ vagrant ssh centos2

Local forwarding is the act of mapping local TCP ports or Unix sockets onto remote ports or sockets. It's commonly used when either accessing a system securely (by requiring the user to first SSH to the box, thus encrypting their connection), or for troubleshooting problems.

In this section, we're going to start a small webserver on centos2, which we're going to connect to from centos1, first by connecting to the IP and port directly, and then by a connection to a mapped local port, utilizing port forwarding.

On centos2, run the following command:

[vagrant@centos2 ~]$ python -m SimpleHTTPServer 8888
Serving HTTP on 0.0.0.0 port 8888 ...

You've just created a small, Python...

In the previous section, we looked at the ability to forward local connection attempts to a remote machine.

In this section, we're going to look at something very similar: remote forwarding.

With remote forwarding, connection attempts made to a specified address and port on a remote machine are passed back through the SSH tunnel you've set up, and are processed on the local machine (your client).

Start on centos1.

Confirm that both...

We're going to take a look at one very new SSH option, a slightly older SSH option, and the concept of bastion hosts (or jump boxes) in this recipe.

We need three machines because we're going to use one machine as the "gateway" to another.

Set up your three VMs, preferably using the Vagrantfile at the top of this chapter.

Connect to each box, and then check that from centos1, you can ping centos2 and centos3:

[vagrant@centos1 ~]$ ping 192.168.33.11
PING 192.168.33.11 (192.168.33.11) 56(84) bytes of data.
64 bytes from 192.168.33.11: icmp_seq=1 ttl=64 time=2.54 ms
64 bytes from 192.168.33.11: icmp_seq=2 ttl=64 time=1.09 ms
64 bytes from 192.168.33.11: icmp_seq=3 ttl...

SSH is great.

I never get tired of talking about how great it is, and it would be remiss of me to not mention one of its best features: the ability to quickly and easily set up a SOCKS proxy.

In the previous sections, we forwarded individual ports, but what if we were using a bastion host to connect to a slew of different websites within a network? Would you like to add tens of lines to your SSH config file? Or manually type out each port and mapping every time?

I didn't think so.

That's where the -D flag comes in.

See -D [bind_address:]port in the SSH manual page (https://man.openbsd.org/ssh):

One thing we touched on briefly was the concept of an SSH agent.

When you SSH to a server (after setting up a key) and you're prompted for a passphrase, what you're actually doing is decrypting the private key part of your public-private key pair (the id_rsa file by default), so that it can be used to verify that you are who you say you are against the remote host. It can get tedious to do this each time you SSH to a server, especially if you're managing hundreds or thousands of constantly changing boxes.

That's where SSH agents come in. They're somewhere for your now-decrypted private key to live, once you've given it the passphrase, for the duration of your session.

Once you've got your private key loaded into your agent, the agent is then responsible for presenting the key to any servers you connect to, without...

Sometimes, it can be a requirement to run multiple SSH servers on one box. You may want to use one for regular, day-to-day activities, and the other server for backups or automation.

In this case, it's perfectly possible to run two distinct versions of the SSH server at once.

We're going to use centos2 for this, setting up a secondary SSH server on port 2020.

If you haven't already, I would advise destroying your previous Vagrant boxes and deploying new ones for this.

Once new boxes are created, connect to both:

$ vagrant ssh centos1
$ vagrant ssh centos2

Install policycoreutils-python on centos2, for semanage later:

[vagrant@centos2 ~]$ sudo yum -y install...

While I've spent this chapter describing some brilliant things that SSH is capable of and singing its praises throughout, it's worth highlighting that it's still software, and it's also constantly evolving. Because it's software, it can have bugs and unexpected behavior, though the developers behind it are some of the best, what with it being part of the OpenBSD suite of software.

If you take anything away from this chapter, make it the following:

• Use key-based authentication
• Disable root login over SSH
• Use a local SSH config file for connecting to remote machines

I'd highly recommend signing up to the various SSH mailing lists if you're a bit sad like I am, and keeping an eye out for new features that might capture your imagination. ProxyJump hasn't been around for long, and it's very handy.

I do recall instances that SSH...