Secure Shell (SSH) is a remote access utility used for managing other nodes on a network. This blog post describes how to configure and exercise various SSH features.

Table of Contents

Understanding Different SSH Files

There are a handful of important SSH files to be aware of between the main, system-wide directory and the directory every end-user is allocated. Below are simple descriptions of said files.

SSH Server Configuration
Edit this file to enable, disable, or customize various settings for the local SSH server (a.k.a daemon). Some examples of parameters you might change here are the logical port SSH will listen on, whether or not root can login remotely, and authentication methods.

/etc/ssh/sshd_config

SSH Client Configuration
Edit this file to change how your SSH client interacts with other SSH servers. Some examples of parameters you might change here are the version of SSH you want to use, the file-path of your access keys, and your locale (language, cultural nuances, monetary symbols, etc.).

/etc/ssh/ssh_config

Your Private Key
A Private key is one-half of an SSH key pair. In reality, it is just a text-file containing a 1024+ character sequence. Encrypt it nonetheless using a passphrase. Failure to do so could result in someone impersonating your identity (or increasing the probability of them gaining access to other nodes on the network).

~/.ssh/id_rsa

Your Public Key
A Public key is the other half of an SSH key pair. It also just a long sequence of characters, albeit a shorter one. Your Public key is used to authenticate with remote nodes.

~/.ssh/id_rsa.pub

Authorized Keys
After successful authentication, Public keys are added to an authorized_keys file. The authorized_keys file is a list of identities, approved for continuous or repeated access. Anyone claiming to be someone on the list without providing the correct Public key is denied entry.

~/.ssh/authorized_keys

Known Hosts
Hosts possess their own SSH key pair as well. The Public key of any node or host you connect to is added to the known_hosts file. Similar to end-users, hosts can be impersonated as well. The risk here is someone convincing you they are a resource you trust (software repository, file server, etc.).

~/.ssh/known_hosts

How to Configure Public Key Authentication

Description

Asymmetric encryption uses two keys: one is called a Private key while the other is called a Public key. Whatever the Private key encrypts, the Public key can decrypt (and vice versa). There are several use-cases for choosing Asymmetric Encryption over other cryptographic methods. Take Public key Authentication for example. Using a Private & Public key pair for authentication, over a password, (1) reduces the risk of brute force attacks, (2) increases the number of access requirements, and (3) enables non-repudiation (proof a subject performed an action against an object).

General Steps

  1. Generate a key pair on the remote node
  2. Generate a key pair on the local node
  3. Copy your Public key onto the remote node
  4. Login to the remote node
  5. Disable password-based authentication

Hands-on Exercise

Scenario
thanos wants a more secure method of accessing a remote server called earth616 from his computer called titan.

Step 1: Generate a key pair on the remote node
Generate a SSH key pair on earth616.

ssh-keygen

Step 2: Generate a key pair on the local node
Generate a SSH key pair on titan.

ssh-keygen

Step 3: Copy your Public Key onto the remote node
From titan, thanos needs to copy his SSH Public key onto earth616.

ssh-copy-id thanos@earth616

Step 4: Login to the remote node
Login to earth616.

ssh thanos@earth616

Step 5: Disable password-based authentication
Open the SSH server configuration file on earth616.

sudo vim /etc/ssh/sshd_config

Add the line below

PasswordAuthentication no

Step 6: Reload the daemon

sudo systemctl reload sshd

How to Copy Files Securely

Description

Data transferred over the network as plain-text, or via un-encrypted transmissions, can be read by anyone. The utility Secure Copy (scp) uses SSH to transmit data as cipher-text, or encrypted transmissions, increasing the confidentiality of your file transfer.

Hands-on Exercise

Scenario
ironMan wants to archive some of the files on his computer (theCave) using a remote server called theAvengersTower.

Step 1: Ensure the destination is accessible
At the theAvengersTower, create a directory with restricted permissions.

mkdir -m 700 ~/backups/

Step 2: Copy the files securely
From theCave, copy the files to theAvengersTower using scp.

scp -r ~/20190402/ ironMan@theAvengersTower:~/backups

How to Encrypt a File Using SSH Key Pairs

Description

By design, Public keys are meant to be shared and Private keys are for non-repudiation. If you encrypted something using someone’s Public key, their Private key would be the only way for it be decrypted. A real-world application of this cryptographic principle is collaborating on intellectual property like a patent or trade secret within your organization.

NOTE: SSH key pairs can be used for this use-case, albeit they must be formatted according to the Privacy Enhanced Mail (PEM) standard.

How to Generate a PEM-Formatted SSH Key Pair

# change into the directory where the original SSH key pair is located
cd ~/.ssh/
# generate a new PEM-formatted Private key
openssl rsa -in id_rsa -outform pem > id_rsa.pem
# restrict access to the new PEM-formatted Private key
chmod 0600 id_rsa.pem
# generate a new PEM-formatted Public key
openssl rsa -in id_rsa -pubout -outform pem > id_rsa.pub.pem

General Steps

  1. Get their Public key
  2. Generate a one-time key
  3. Encrypt your secret file using the one-time key
  4. Encrypt the one-time key using their Public key
  5. Share the encrypted, secret file and encrypted, one-time key
  6. They decrypt the one-time key using their Private key
  7. They decrypt the secret file using the one-time key

Hands-on Exercise

Scenario
antMan used the command sentence below to create a patent. Now, he wants to (1) encrypt the patent and (2) ensure only blackWidow can decrypt it.

sudo vim patent.txt
  //  \\
 _\\()//_
/ //  \\ \
 | \__/ |

Step 1: Get their Public key
blackWidow must first share her Public key (of the PEM format; see above) with antMan. One way to do so is by creating a shared directory, copying the Public key to it, and then, sharing it via a Python 3 web server.

mkdir -m 744 /home/blackWidow/shared/
cp /home/blackWidow/.ssh/id_rsa.pub.pem /home/blackWidow/shared/
cd /home/blackWidow/shared/
python3 -m http.server --bind 192.168.8.12 8000

antMan can download the Public key blackWidow shared using wget.

wget http://192.168.8.12:8000/id_rsa.pub.pem

Step 2: Generate a one-time key
antMan must generate a one-time key for him and blackWidow to use for encrypting/decrypting the patent.

# 32 random bytes = 256-bit key
openssl rand 32 > onetime.key

Step 3: Encrypt your secret file using the one-time key
antMan must then use the one-time key to encrypt his patent.

openssl enc -aes-256-cbc -salt -in patent.txt -out patent.txt.enc -pass file:onetime.key

Step 4: Encrypt the one-time key using their Public key
Next, he must encrypt the one-time key using the Public key blackWidow shared.

openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in onetime.key -out onetime.key.enc

Step 5: Share the encrypted, secret file and encrypted, one-time key
An efficient way to share the encrypted patent and one-time key is to zip them into a single, compressed package. antMan can then share the package using his own Python 3 web server.

tar -czvf patent.tgz *.enc
mkdir -m 744 /home/antMan/shared/
cp patent.tgz /home/antMan/shared/
cd /home/antMan/shared/
python3 -m http.server --bind 192.168.8.11 8000

blackWidow can download the package antMan shared using wget.

wget http://192.168.8.11:8000/patent.tgz

After downloading the package, blackWidow will need to decompress it.

tar -xzvf patent.tar.gz

Step 6: They decrypt the one-time key using their Private key
blackWidow must use her Private key (of the PEM format) to decrypt the one-time key.

openssl rsautl -decrypt -inkey ~/.ssh/id_rsa.pem -in onetime.key.enc -out onetime.key

Step 7: They decrypt the secret file using the one-time key
Finally, she can decrypt the patent using the one-time key antMan created.

openssl enc -d -aes-256-cbc -in patent.txt.enc -out patent.txt -pass file:./onetime.key 
cat patent.txt
  //  \\
 _\\()//_
/ //  \\ \
 | \__/ |

How to Create an Encrypted Tunnel

Description

Encrypted tunnels are used to connect two networks separated by an untrusted zone. One use-case may be connecting your home network to your office from across the Internet. SSH facilitates encrypted tunnels through Port Forwarding (all data is fed through a SSH proxy prior to being sent onward). Port Forwarding can be Local or Remote. Local Port Forwarding is when the tunnel extends from SSH client to SSH server. Remote Port Forwarding extends backwards, from SSH server to SSH client.

NOTE: Gateway Ports may need to be enabled in your SSH server's configuration file in order for end-users across your network to use Remote Port Forwarding between nodes.

How to Enable Remote Port Forwarding
Use a text-editor to open your SSH server’s configuration file.

sudo vim /etc/ssh/sshd_config

Then, add the line below.

GatewayPorts yes

Hands-on Exercise

Scenario
fury needs all data destined for a web server called asgard to be temporarily tunneled (redirected) to a fall-back node called wakanda.

Local Port Forwarding
From asgard, he could execute command sentence below.

# from asgard
ssh -NL asgard:80:wakanda:4000 fury@asgard

Remote Port Forwarding
If he was at wakanda, he could swap out the first parameter (-NL) for -NR. Then, he would just need to execute the command sentence below.

# from wakanda
ssh -NR asgard:80:wakanda:4000 fury@asgard

The same effect (getting data tunneled from asgard to wakanda) is achieved. fury would just be launching the tunnel on asgard to wakanda remotely.

If firewall restrictions blocked the ports mentioned, but allowed port 22, fury could alternatively execute the command sentence below.

# from wakanda
ssh -NR 22:wakanda:4000 fury@wakanda

As long as end-users send their web traffic to the fall-back server wakanda via port 22, the SSH daemon listening to their requests will redirect them to port 4000.

How to Setup Single Sign-On Access

Description

Single Sign-On (SSO) reduces the number of times an end-user needs to authenticate. Facilitating SSO increases convenience and reduces the overall attack surface of an enterprise (less opportunities for someone to brute force login credentials).

General Steps

  1. Configure the remote server’s SSH daemon to allow SSH Agent Forwarding
  2. Configure the proxy server’s SSH daemon to allow SSH Agent Forwarding
  3. Configure your local computer’s SSH client to allow SSH Agent Forwarding
  4. Copy your public SSH key, stored on your local computer, to the proxy & remote servers
  5. Configure the SSH agent on your local computer

Hands-on Exercise

Scenario
peterParker is requesting help setting-up SSH-based, SSO access between his local computer in Queens, through a proxy server in Brooklyn, and finally, to his remote server in Manhattan.

  • The hostname of his local computer is queens
  • The hostname of his proxy server is brooklyn
  • The hostname of his remote server is manhattan

Step 1: Configure the remote server’s SSH daemon to allow SSH Agent Forwarding
On manhattan, configure the SSH daemon to allow SSH Agent Forwarding.

sudo vim /etc/ssh/sshd_config
ForwardAgent yes

Step 2: Configure the proxy server’s SSH daemon to allow SSH Agent Forwarding
On brooklyn, configure the SSH daemon to allow SSH Agent Forwarding.

sudo vim /etc/ssh/sshd_config
ForwardAgent yes

Step 3: Configure your local computer’s SSH client to allow SSH Agent Forwarding
NOTE: The name of the configuration file and setting is different for this step.
On queens, configure the SSH client to allow SSH Agent Forwarding.

sudo vim /etc/ssh/ssh_config
AllowAgentForwarding yes

Step 4: Copy your public SSH key to the proxy & remote servers
From queens, peterParker must copy his SSH Public key to brooklyn and manhattan.

ssh-copy-id peterParker@brooklyn
ssh-copy-id peterParker@manhattan

Step 5: Setup an SSH agent on your local computer
On queens, setup an SSH agent for peterParker. This can be done manually everytime peterParker wants to use SSO-based access, or it can be automated by editing his .bashrc file (which contains a list of commands that are executed at login).

Option 1: Manually setup an SSH agent everytime

eval ($ssh-agent)
ssh-add

Option 2: Automate setting-up an SSH agent by modifying his .bashrc file

sudo vim ~.bashrc
if [ ! -S ~/.ssh/ssh_auth_sock ]; then
  eval $(ssh-agent) 
  ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
fi
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
ssh-add -l > /dev/null || ssh-add

The snippet of code above says, “If a profile-specific SSH socket file does not exist, (1) load my current SSH variables and (2) create one. Then, export the new socket file’s location and update the corresponding environment variable. Finally, add my private SSH key into memory.”

How to Display Login Banners

Description

A Login Banner serves to inform authorized and un-authorized subjects about an organization’s information security policy regarding the access of an object. Verbiage included typically covers the amount of privacy/surveillance one can expect while using the object as well as what is allowed and/or prohibited. Two banners can be configured for SSH-enabled systems: the Pre-Authentication banner and the Post-Authentication banner (a.k.a the Message of the Day, or MOTD).

General Steps

  1. Create a Pre-Authentication banner
  2. Specify the banner’s file-path within the SSH daemon’s configuration file
  3. Create a Post-Authentication (Message of the Day; MOTD) banner
  4. Reload the SSH daemon

Hands-on Exercise

Step 1: Create a Pre-Authentication banner

sudo vim /etc/ssh/preAuthBanner

 ██╗    ██╗ █████╗ ██████╗ ███╗   ██╗██╗███╗   ██╗ ██████╗ 
 ██║    ██║██╔══██╗██╔══██╗████╗  ██║██║████╗  ██║██╔════╝ 
 ██║ █╗ ██║███████║██████╔╝██╔██╗ ██║██║██╔██╗ ██║██║  ███╗
 ██║███╗██║██╔══██║██╔══██╗██║╚██╗██║██║██║╚██╗██║██║   ██║
 ╚███╔███╔╝██║  ██║██║  ██║██║ ╚████║██║██║ ╚████║╚██████╔╝
  ╚══╝╚══╝ ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚═╝╚═╝  ╚═══╝ ╚═════╝ 

 You are accessing a Cyberdyne Systems (CS) Skynet Mainframe 
 that is provided for CS-authorized users only. All actions 
 will be recorded. Using this information system to defend 
             mankind is stricly prohibited. 

Step 2: Specify the banner’s file-path within the SSH daemon’s configuration file

sudo vim /etc/ssh/sshd_config
Banner /etc/ssh/preAuthBanner

Step 3: Create a Post-Authentication (Message of the Day; MOTD) Banner

sudo vim /etc/motd
 ______________________
 |                    |
     WELCOME BACK!
   We're out of milk. 
 |____________________|
         //
(\__/)  //
(•ㅅ•) //
/   づ

Step 4: Reload the SSH daemon

sudo systemctl reload ssh

References