Creating and transferring SSH keys

 

Creating and transferring SSH keys

In this workshop, you will use a virtual machine (VM) as a client and another virtual machine as a server. If you're using a Windows hosting machine, you can use Cygwin, PowerShell, or the built-in Windows Bash shell as a client. (Note that PowerShell and Windows Bash Shell store keys in different locations.) If you're using a Mac or Linux hosting machine, you can use the native command-line terminal of the same machine as the client. Either way, the process will be the same. For a virtual server machine, use Ubuntu or CentOS 7. This process works the same way in CentOS 8. However, we'll be using this virtual machine for future workshops, and CentOS 8 has some special points that we'll get to later. Let's get started:

1. On the client machine, create a 384-bit elliptical curve key pair. Specify the default name and location of the file and set a password for it:

   ssh-keygen -t ecdsa -b 384
   

2. View the keys and check the permissions settings:

   ls -l ./ssh
   

3. Add your private key to your meeting keyring. When prompted, enter the password:

   exec /usr/bin/ssh-agent $SHELL
   ssh-add
   

4. Move the public key to the server's virtual machine. When prompted, enter your account password on the server's virtual machine (replace your username and IP address in the following command):

   ssh-copy-id donnie@192.168.0.7
   

5. Log in to the virtual machine server as always:

   ssh donnie@192.168.0.7
   

6. View the file created on the server: authorized_keys

   ls -l .ssh
   cat .ssh/authorized_keys
   

7. Exit the server's virtual machine and close the terminal window on the client machine. Open a new terminal window and try logging in to the server again. This time, you should be asked to enter your private key password.
8. Log out of the server virtual machine again and add your private key to the client's machine session keyring. When prompted, enter your private key password:

   exec /usr/bin/ssh-agent $SHELL
   ssh-add
   

   As long as you keep this terminal window open on the client's machine, you can log in to the server's virtual machine as many times as you want without entering a password. However, when you close the terminal window, your private key will be removed from your session keyring.

9. Keep the server virtual machine, as we will work with it in the future.

You've reached the end of the workshop – congratulations!
What we did here is good, but it's still not enough. One disadvantage is that if you switch to another client machine, you can still use the normal username/password authentication method to log in. This is not a problem, we will fix it in a few moments.

Disabling root user login

A few years ago, there was a fairly well-known case where attackers were able to install malware on a number of Linux servers somewhere in Southeast Asia. There were three reasons why it was so easy for attackers:

1. Servers connected to the Internet were configured to use username/password authentication for SSH.
2. The root user was allowed to log in via SSH.
3. Users' passwords, including the root user password, were very weak.

All of this made it easy for the malware to enter the system with a brute-force attack.

Different distributions have different default settings for root user login. In the file on your CentOS machine, you'll see this line:/etc/ssh/sshd_config

#PermitRootLogin yes

Unlike most configuration files, they define the lines commented in the default settings for the Secure Shell. So this line indicates that the root user has been allowed to log in via SSH. To change these settings, I'll remove the comment watermark and change the value to:sshd_configno

PermitRootLogin no

To apply this change, I'm restarting the SSH, known as in CentOS. In Ubuntu, this is called:sshdssh

sudo systemctl restart sshd

On the Ubuntu machine, the default settings are slightly different:

PermitRootLogin prohibit-password

This means that the root user is allowed to log in, but only through public key exchange. This setting is probably safe for most cases, if you really need to allow the root user to log in. But in most cases, you'll want to ask admin users to log in with their regular account and use it for admin needs. So, in most cases, you'll still want to change this setting.sudono

Note that if you implement a Linux instance on a cloud service like Rackspace or Vultr, the service owners will require you to sign in with a root account. The first thing you need to do is create your regular account, log in with it, then disable the root account and disable root login in . Microsoft Azure is an exception to this rule because it automatically creates an unauthorized user account for you.sshd_config

Disable login with username/password

This is what you should only do after you set up a key exchange with your client. Otherwise, your client will not be able to perform remote login.

Hands-on Workshop – Disabling Root Login and Password Authentication

For this workshop, use the same virtual machine server that you used for the previous workshop. Let's get started:

1. On the Ubuntu or CentOS server virtual machine, look for this line in the file: sshd_config

   #PasswordAuthentication yes
   

2. Remove the comment watermark, change the parameter value to and restart SSH. The line should be changed as follows: no

   PasswordAuthentication no
   

   Now, when your network bots scan the system, they will see that a brute-force SSH attack using a password is useless. As a result, they leave and leave you alone.

3. Look for one of these two lines, depending on whether your server is Ubuntu or CentOS:

   #PermitRootLogin yes
   #PermitRootLogin prohibit-password
   

   Uncomment the line and change it to the following way:

   PermitRootLogin no
   

4. Restart SSH to make new changes. In Ubuntu, you can do this as follows:

   sudo systemctl restart ssh
   

   In CentOS, this is done in the following way:

   sudo systemctl restart sshd
   

5. Try logging into the virtual machine server through the client you used in the previous workshop.
6. Try logging into the virtual machine server from another client where you didn't create a key pair. (You must not be able to log in.)
7. As mentioned earlier, keep the server virtual machine, as we will be working with it more in the future.

Now that we've explored how to create a private/public key pair on the client side and how to transfer the public key to the server, let's talk about the type of algorithms that SSH uses. After that, we'll move on to how to disable some of the older and weaker algorithms.

Configuring Secure Shell with Strong Encryption Algorithms

As I mentioned earlier, NIST's set of recommendations, the CNSA Suite, involves the use of stronger algorithms and longer keys than we previously needed. Here are the new recommendations in this table:

Algorithm	Use
RSA, 3,072 bits or more	Key Establishment and Digital Signature
Diffie-Hellman (DH), 3,072 bits or more	Key Establishment
ECDH with NIST P-384	Key Establishment
ECDSA with NIST P-384	Digital Signature
SHA-384	Integrity
AES-256	Privacy

In some other publications, you may see the NIST Suite B standard as the recommended standard for cryptographic algorithms. Suite B is an old standard that has been replaced by the CNSA Suite. Another cryptographic standard you may work with is the Federal Information Processing Standard (FIPS), which is also published by the US government. The current version is FIPS 140-2, last revised in December 2002. FIPS 140-3, which was finalized on September 22, 2019, will eventually become the new standard. U.S. government agencies that are subject to FIPS compliance have already been ordered to gradually transition to FIPS 140-3.

Understanding SSH Cryptographic Algorithms

SSH works with a combination of symmetric and asymmetric cryptography, similar to how Transport Layer Security (TLS) works. The SSH client initiates the process by using the public key method to establish an asymmetric session with the SSH server. Once this session is created, the two devices can agree on a secret code and exchange it, which they use to set up a symmetric session. (As we've already seen in TLS, we want to use symmetric cryptography for performance reasons, but we need an asymmetric session to make the secret key exchange happen.) To accomplish this process, we need four sets of cryptographic algorithms, which we will configure on the server side. These include:

1. Ciphers: These are symmetric algorithms that encrypt the data that is exchanged between the client and the server.
2. HostKeyAlgorithms: This is a list of host key types that the server can use.
3. KexAlgorithms: These are the algorithms that the server can use to perform symmetric key exchanges.
4. MAC (Message Authentication Codes): These are hashing algorithms that sign cryptographic data in transit. This will ensure the integrity of the data and let you know if someone has tampered with your data or not.

The best way to familiarize yourself with these is to view the MAN file page:sshd_config

man sshd_config

I can use any virtual machine to display these. Currently, I'm using CentOS 7 unless I mention otherwise. (Lists of default and available algorithms will vary for different Linux distributions and versions.)

Lab Hands-on – Installing and Using ssh_scan

In this section, we will use the ssh_scan tool to scan for active SSH algorithms. We will follow the step-by-step steps of installing and using this tool as follows:

Installation and use of ssh_scan:

1. Installation of Required Packages (Ruby and gem): ssh_scan is written in Ruby and presented as a Ruby gem. So, we need to install Ruby and gem first. Depending on your Linux distribution, enter the appropriate command:

   • For Ubuntu:

     sudo apt update
     sudo apt install ruby gem
     

   • For CentOS 7:

     sudo yum install ruby gem
     

   • For CentOS 8:

     sudo dnf install ruby gem
     

2. Installing ssh_scan gem: Now that we have installed Ruby and gem, we need to install the ssh_scan package. To do this, enter the following command:

   sudo gem install ssh_scan
   

3. Creating a symlink in CentOS: In most distributions, ssh_scan is installed on the way. But in CentOS, if you use it to call the command in this directory, the system won't find it, even if the path is in the root user settings. So, the solution to this problem is to create an iconic link to. Just do it in CentOS: /usr/local/bin/sudoPATH/usr/bin/

   sudo ln -s /usr/local/bin/ssh_scan /usr/bin/ssh_scan
   

4. View ssh_scan Command Options: The ssh_scan tool doesn't have a MAN page, but you can see a list of its command options using the following command:

   sudo ssh_scan -h
   

   This command will show you a guide to using the ssh_scan.

5. Scan the VM server you built and configured in previous tests.
   Replace your IP address with the one I used here. Note that the output of the page is in JSON format. Also, note that even if you haven't created the key pair on your scanner, the scan will still work on machines where username/password authentication is disabled (but of course you won't be able to log in from the scanner):

sudo ssh_scan -t 192.168.0.7

6. Repeat the scan, but save the output to .json file this time, like this:

sudo ssh_scan -t 192.168.0.7 -o ssh_scan-7.json

7. You can open the JSON file in a normal text editor or turntable, but it's best to open it in your web browser.
   Transfer the file to a device that has a desktop interface and open it in your preferred web browser. You should see something like this:
   
8. You will see a complete list of all the active algorithms. At the bottom, you'll see recommendations on which algorithms you should enable or disable. Since ssh_scan is a project of the Mozilla Foundation, it uses Mozilla's own recommendations as a policy guide. These are not the same standards that organizations like NIST recommend. Therefore, you should compare your results with standards that are applicable to your condition, such as the CNSA NIST standard, to ensure that you have enabled or disabled the right things.
9. On your host machine or a VM with a desktop interface, visit the Shodan website at https://www.shodan.io.
   Enter the word ssh in the search window and see a list of SSH servers that are exposed to the internet. Click on different IP addresses to find the SSH server that is not running on the default port 22. See a list of active algorithms for that device.
10. Scan the device, using the -p switch to scan different ports, like this:

sudo ssh_scan -t 178.60.214.30 -p 222 -o ssh_scan-178-60-214-30.json

Note that in addition to the list of active algorithms you saw on Shodan, you now have a list of weak algorithms that the owner of this device needs to disable.

11. Keep this scanner and this VM server handy, as we will be using them again after disabling some algorithms