Ssh Server Public Key

We will look at one more interesting SSH vulnerability reported by Qualys scanner appliance on RHEL6 servers. This one is classified as Confirmed Severity 2 (Medium) vulnerability level with PCI Vulnerable.

1. Ssh Public Key Linux
2. Ssh Server Public Key Too Small Nmap
3. Get Ssh Server Public Key
4. Ssh Server Public Key Too Small
5. Ssh Server Public Key Too Small Hp Ilo

Below is the vulnerability details from scan report

Vulnerability: SSH Server Public Key Too Small
QID: 38738
Category: General remote services
PCI Vuln: Yes
THREAT: The SSH protocol (Secure Shell) is a method for secure remote login from one computer to another.The SSH Server is using a small Public Key. Best practices require that RSA digital signatures be 2048 or more bits long to provide adequate security. Key lengths of 1024 are acceptable through 2013, but since 2011 they are considered deprecated.
IMPACT: A man-in-the-middle attacker can exploit this vulnerability to record the communication to decrypt the session key and even the messages.
SOLUTION: DSA keys and RSA keys shorter than 2048 bits are considered vulnerable. It is recommended to install a RSA public key length of at least 2048 bits or greater, or to switch to ECDSA or EdDSA.
RESULTS:

Algorithm	Length
ssh-dss	1024 bits

Basically, the scanner has identified there is a weak server host key (based on the key length) present on the system. In this case, from the Results section, the key in question is SSH-DSS which is of 1024 bits.

The solution in our environment was pretty straight forward as below:

Alternative: Export public key. If the SSH Server does not allow you to connect using password authentication, or does not allow you to upload the key, you will need to send the public key to the server administrator using an alternate method of communication. To do this, export the public key using the Client key manager.

• Since we were already using RSA key (2048 bits) on our servers, we just had to delete these DSA Key (1024 bits) because DSA Keys of 2048 bits cannot be created using ssh-keygen tool.
• Configured SSHD not to regenerate these DSA key after every sshd restart.

Let me explain below how this is done and before that some technical ssh checks/stuffs to understand before we actually tweak any ssh config on server.

• Check what version of SSH protocol is enabled on our server

1. Overview Public key authentication is a way of logging into an SSH/SFTP account using a cryptographic key rather than a password.
2. Don't forget to uncomment #AuthorizedKeysFile and to copy the public key to /.ssh/authorizedkeys (and restart). Without this, it won't work. – ivanleoncz Jan 25 '19 at 21:04 If it wasn't true in 2016, it is definitely the case in 2019 that a restart is required; reload is not sufficient.

• Check what server hostkey’s are allowed based on the config

From above command output, We have ssh_host_rsa_key and ssh_host_dsa_key enabled.

[ NOTE: hostkey – Specifies a file containing a private host key used by SSH]
[ A host key is a cryptographic key used for authenticating computers in the SSH protocol. Host keys are key pairs, typically using the RSA, DSA, or ECDSA algorithms. Public host keys are stored on and/or distributed to SSH clients, and private keys are stored on SSH servers ]

Since we now know, SSH authentication to this server can happen by using RSA and DSA hostkeys but do we really have those keys on our server ?

• Check for the actual keys under /etc/ssh/

Yes, we see them i.e., both DSA & RSA keys (public & private) available on the server.

• Check the key length(serverkey bits) of these keys by below command

Voila…!!! The above DSA key is of 1024 bits length and this is what the scanner is complaining about.

Since RSA hostkeys were being used on our servers, we just went and deleted these DSA hostkeys (both public & private)

Be aware that though we have deleted these keys, this is not yet completely fixed as these keys would be re-generated every time sshd service is restarted. So that means Qualys would identify them and report this vulnerability again.

So how do we fix this completely i.e., stop this DSA key regeneration?

Well this can be accomplished as below.

• Check for the value of “AUTOCREATE_SERVER_KEYS” parameter that is set in configuration file /etc/sysconfig/sshd for the sshd service.

Since the value is set to YES, the DSA server keys would be regenerated post sshd service restart. To stop this from happening, the below config option needs to be used i.e., we are disabling DSA key autogeneration and enabling only RSA keys.

Ssh Public Key Linux

• Below is how the config file looks post tweaking.

Once done, restart the SSHD service and check to verify for non generation of DSA keys.

We had our Qualys appliance re-scan the servers and as expected the report didn’t show up this ssh vulnerability and was successfully remediated.

-->

With a secure shell (SSH) key pair, you can create virtual machines (VMs) in Azure that use SSH keys for authentication. This article shows you how to quickly generate and use an SSH public-private key file pair for Linux VMs. You can complete these steps with the Azure Cloud Shell, a macOS or Linux host.

Note

VMs created using SSH keys are by default configured with passwords disabled, which greatly increases the difficulty of brute-force guessing attacks.

For more background and examples, see Detailed steps to create SSH key pairs.

For additional ways to generate and use SSH keys on a Windows computer, see How to use SSH keys with Windows on Azure.

Supported SSH key formats

Azure currently supports SSH protocol 2 (SSH-2) RSA public-private key pairs with a minimum length of 2048 bits. Other key formats such as ED25519 and ECDSA are not supported.

Create an SSH key pair

Use the ssh-keygen command to generate SSH public and private key files. By default, these files are created in the ~/.ssh directory. You can specify a different location, and an optional password (passphrase) to access the private key file. If an SSH key pair with the same name exists in the given location, those files are overwritten.

The following command creates an SSH key pair using RSA encryption and a bit length of 4096:

Ssh Server Public Key Too Small Nmap

If you use the Azure CLI to create your VM with the az vm create command, you can optionally generate SSH public and private key files using the --generate-ssh-keys option. The key files are stored in the ~/.ssh directory unless specified otherwise with the --ssh-dest-key-path option. If an ssh key pair already exists and the --generate-ssh-keys option is used, a new key pair will not be generated but instead the existing key pair will be used. In the following command, replace VMname and RGname with your own values:

Provide an SSH public key when deploying a VM

To create a Linux VM that uses SSH keys for authentication, specify your SSH public key when creating the VM using the Azure portal, Azure CLI, Azure Resource Manager templates, or other methods:

Get Ssh Server Public Key

If you're not familiar with the format of an SSH public key, you can display your public key with the following cat command, replacing ~/.ssh/id_rsa.pub with the path and filename of your own public key file if needed:

A typical public key value looks like this example:

If you copy and paste the contents of the public key file to use in the Azure portal or a Resource Manager template, make sure you don't copy any trailing whitespace. To copy a public key in macOS, you can pipe the public key file to pbcopy. Similarly in Linux, you can pipe the public key file to programs such as xclip.

Ssh Server Public Key Too Small

The public key that you place on your Linux VM in Azure is by default stored in ~/.ssh/id_rsa.pub, unless you specified a different location when you created the key pair. To use the Azure CLI 2.0 to create your VM with an existing public key, specify the value and optionally the location of this public key using the az vm create command with the --ssh-key-values option. In the following command, replace myVM, myResourceGroup, UbuntuLTS, azureuser, and mysshkey.pub with your own values:

If you want to use multiple SSH keys with your VM, you can enter them in a space-separated list, like this --ssh-key-values sshkey-desktop.pub sshkey-laptop.pub.

SSH into your VM

With the public key deployed on your Azure VM, and the private key on your local system, SSH into your VM using the IP address or DNS name of your VM. In the following command, replace azureuser and myvm.westus.cloudapp.azure.com with the administrator user name and the fully qualified domain name (or IP address):

If you specified a passphrase when you created your key pair, enter that passphrase when prompted during the login process. The VM is added to your ~/.ssh/known_hosts file, and you won't be asked to connect again until either the public key on your Azure VM changes or the server name is removed from ~/.ssh/known_hosts.

If the VM is using the just-in-time access policy, you need to request access before you can connect to the VM. For more information about the just-in-time policy, see Manage virtual machine access using the just in time policy.

Next steps

Ssh Server Public Key Too Small Hp Ilo

• For more information on working with SSH key pairs, see Detailed steps to create and manage SSH key pairs.

• If you have difficulties with SSH connections to Azure VMs, see Troubleshoot SSH connections to an Azure Linux VM.