Set Up SSH Keys on Ubuntu 20.04

---

Setting ssh authorized_keys seem to be simple, but it hides some traps I’m trying to figure.

— SERVER —

In /etc/ssh/sshd_config, set passwordAuthentication yes to let the server temporarily accept password authentication

— CLIENT —

consider Cygwin as Linux emulation and install & run OpenSSH

1. Generate private and public keys (client side)
# ssh-keygen

Here pressing just Enter, you get default two files, «id_rsa» and «id_rsa.pub«, in ~/.ssh/, but if you give a name_for_the_key, the generated files are saved in your current working directory.

If the server still asks for a password then you gave something. To Enter passphrase: when you’ve created keys (so it’s normal).

If ssh is not listening on the default port 22, you must use ssh -p port_nr.

— SERVER ——

4. Modify file /etc/ssh/sshd_config to have

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncomment if case)

5 Set permissions on the target machine

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also turn off pass authentication,

6. Ensure ownership and group ownership of all non-root home directories are appropriate.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user

7. Consider the excellent http://www.fail2ban.org

8. Extra
SSH tunnel to access a MySQL (bind = 127.0.0.1) server

SSH public key authentication. ssh authorized_keys. ssh with key. ssh key login. linux enable ssh public key authentication. generate ssh key and add ssh key to server. ssh login with private key without password using authorized_keys. add public key to server. how to ssh with private key. Linux login without password. create ssh key. ssh add key. ssh keygen. login to linux server using ssh key. where are ssh keys stored. ssh use public key centos. rhel ssh public key authentication. rhel ssh key exchange. login to linux server without password centos.

PSSH is a utility to perform SSH from one server to multiple client nodes in parallel and perform certain task as defined. By default PSSH has -A argument using which the tool will prompt for password which will be used to connect to all the target host.

But we can also configure PSSH to use SSH public key authentication. You can login to multiple Linux server using SSH Key, either with passphrase or password less (without password).

-A
--askpass
         Prompt for a password and pass it to ssh.  The password may be used for either to unlock a key or  for  password
         authentication.   The  password  is transferred in a fairly secure manner (e.g., it will not show up in argument
         lists).  However, be aware that a root user on your system could potentially intercept the password.

In OSX (Linux), how do I get to the SSH keys with my root directory?

asked Feb 20, 2011 at 3:08

But for Linux ssh files (public rsa, authorized keys, etc) are stored in ~/.ssh

So for root they would be /root/.ssh/

Not sure if this is the same for OSX though.

answered Feb 20, 2011 at 3:30

answered Feb 21, 2011 at 0:13

1 gold badge20 silver badges32 bronze badges

So -let’s start there first:

Once complete if you were to browse to your terminal and then once it is opened simply type

you should be able to view your ssh keys

If you wish to copy the SSH key to another linux/nix based system simply use scp

scp ~/.ssh/id_dsa.pub (or whatever name you gave it) www.servernameorIPaddress.com:/root/.ssh/authorized_keys2

I would suggest always using the -d option when doing the keyGen simply because RSA keys are generally not used in Version 2 of SSH.

I hope that helps — if not feel free to ask for clarification and I will help you along.

—- one last note —-

If you are looking to use ROOT on your system — this link may help you a little bit: http://snowleopardtips.net/tips/enable-root-account-in-snow-leopard.html

answered Feb 20, 2011 at 4:10

1. There is no OSX(Linux) maybe you mean OSX(Unix).

2. There is no .ssh folder under root on OSX. You have to create it under /var/root.

   mkdir /var/root/.ssh
   

You can place your private key there.
In case you get a warning about «UNPROTECTED PRIVATE KEY FILE!», you need to change permissions to your key.

chmod 600 id_rsa

Will look like this.

bob:.ssh root# ls -lah 
total 16
drwxr-xr-x  4 root  wheel   128B Apr  5 14:57 .
drwxr-x---  9 root  wheel   288B Apr  5 14:54 ..
-rw-------  1 root  wheel   1.7K Apr  5 14:54 id_rsa
-rw-r--r--  1 root  wheel   197B Apr  5 14:57 known_hosts

answered Apr 5, 2018 at 12:14

3 silver badges11 bronze badges

In my project, I have to install some package remotely. If I have to login in debian, I say:

$ ssh root@remotehostname
root@remotehostname's password: 

it logs in successfully.

I have login in ubuntu in directly using

 $ root@remotehostname
 root@remotehostname's password:

it is throw error message in

Permission denied, please try again.

How to solve this problem?

33 gold badges235 silver badges226 bronze badges

asked Aug 23, 2013 at 5:47

Reegan Miranda

6 gold badges43 silver badges55 bronze badges

check the /etc/ssh/sshd_config whether the configure PermitRootLogin yes below # Authentication:. If not yes, it doesn’t permit login as root.

you can change it to yes.

Then, restart ssh service to apply the changes:
sudo service sshd restart

26 silver badges37 bronze badges

answered Aug 23, 2013 at 6:10

Ubuntu documentation says:

By default, the Root account password is locked in Ubuntu.

It also says:

It talks at length about why it’s been done this way.

---

Enabling the root account:

sudo -i

To enable the Root account (i.e. set a password) use:

sudo passwd root

Use at your own risk!

Logging in to X as root may cause very serious trouble. If you believe
you need a root account to perform a certain action, please consult
the official support channels first, to make sure there is not a
better alternative.

Do not enable the root account. Do not set a password for the root account.

A better way is to allow root login using public key authentication, not with password. The reasoning is explained in the Debian mailing list archives.

1. Open /etc/ssh/sshd_config and check if PermitRootLogin is set to yes. If not, then set it to yes and restart ssh with sudo service ssh restart

2. Create the .ssh directory in root’s home if it doesn’t exist and make sure it has strict permissions:

   sudo -i mkdir -p .ssh
   sudo -i chmod 700 .ssh
   

3. Create a public/private key pair in the system you want to login from.

5. Append your public key to .ssh/authorized_keys of root, and make sure the file has strict permissions:

   cat id_rsa.pub | sudo -i tee -a .ssh/authorized_keys
   sudo -i chmod 600 .ssh/authorized_keys
   

With this setup you should be able to login as root using your private key.

If you have previously enabled the root account, make sure to disable it now:

sudo passwd -l root

answered Aug 30, 2013 at 12:12

29 gold badges224 silver badges235 bronze badges

ssh user@remotehostname
user@remotehostname's password:

and then do what you want using sudo or get a root shell the recommended way:

user@remotehostname$ sudo su
Password:
root@remotehostname#

and then do your housekeeping. Instead of ‘sudo su’ you also could use ‘sudo -i’, which is equivalent, or ‘sudo -s’, that keeps the current environment.

See Ubuntu Sudo/Root documentation

answered Sep 1, 2013 at 19:42

1 gold badge8 silver badges3 bronze badges

edit your /etc/sshd_config doing:

sudo /etc/sshd_config

search for line having PermitRootLogin into Authentication Section and uncomment PermitRootLogin or set PermitRootLogin yes. Or simply add this line to the end of file:

PermitRootLogin yes

Next you’ll gonna restart ssh daemon doing

/etc/init.d/ssh restart 

service ssh restart

sudo command

sudo su

to continue session under your root account

answered Aug 26, 2013 at 18:26

1 silver badge2 bronze badges

ssh -l user localhost "sudo whoami"

root

So long as:

All that is different was the word sudo was added before carrying out the command

If there are security issues with keys etc then you could take a look at a language called expect — using an expect script you will be able to ssh / telnet what ever it is to a remote host and send passwords etc accordingly

answered Aug 26, 2013 at 18:41

V H

2 gold badges28 silver badges48 bronze badges

answered Aug 30, 2013 at 3:46

8 silver badges19 bronze badges

1. Edit sshd_config file vi /etc/ssh/sshd_config
2. Comment out #PermitRootLogin without-password under Authentication:
3. insert below PermitRootLogin yes
4. Save the file.
5. Restart the ssh service service ssh restart

answered Oct 28, 2014 at 8:17

1 bronze badge

By default, the Root account password is locked in Debian based systems like Ubuntu:

sudo -i;

Now set the password for root account:

sudo passwd;

Simply adding a password for root is not enough.

Incoming ssh connections need to be enabled as below:

PermitRootLogin without-password

PermitRootLogin yes

Then restart SSH:

sudo service ssh restart;

Finally Restart the system:

sudo reboot;

answered Feb 8, 2016 at 12:28

Pratik Patil

3 gold badges31 silver badges31 bronze badges

1. Edit the
   /etc/ssh/sshd_config file and change the line that says “PermitRootLogin forced-commands-only” to “PermitRootLogin without-password”.

2. Restart the sshd server with “service sshd restart”.

SSH your machine using root with your keypair

answered May 19, 2018 at 11:57

Ali Azhar

19 silver badges14 bronze badges

Configure Host Based Authentication for Host

On Client side (ssh_config)

On the client or source host, this file must be configured and in addition at least one host key must exist under /etc/ssh:

• /etc/ssh/ssh_config — allow clients to request host-based authentication

Enable below values in /etc/ssh/ssh_config on the client trying host key authentication to all machines:

Host *
   EnableSSHKeySign yes
   HostbasedAuthentication yes

ssh-keysign is disabled by default and can only be enabled in the global client configuration file /etc/ssh/ssh_config by setting EnableSSHKeysign to yes

-rw-------. 1 root root        668 Dec  4 12:12 ssh_host_dsa_key
-rw-r--r--. 1 root root        613 Dec  4 12:12 ssh_host_dsa_key.pub
-rw-r-----. 1 root ssh_keys    227 Jul 20 16:30 ssh_host_ecdsa_key
-rw-r--r--. 1 root root        162 Jul 20 16:30 ssh_host_ecdsa_key.pub
-rw-r-----. 1 root ssh_keys    387 Jul 20 16:30 ssh_host_ed25519_key
-rw-r--r--. 1 root root         82 Jul 20 16:30 ssh_host_ed25519_key.pub
-rw-------. 1 root root        988 Dec  4 12:12 ssh_host_key
-rw-r--r--. 1 root root        653 Dec  4 12:12 ssh_host_key.pub
-rw-------. 1 root root       1679 Dec  4 12:13 ssh_host_rsa_key
-rw-r--r--. 1 root ssh_keys    405 Dec  4 12:13 ssh_host_rsa_key.pub

Next restart the sshd service to activate the changes

[root@rhel-7 ~]# systemctl restart sshd

5 simple methods to test ssh connection in Linux & Unix

On Server side (sshd_config)

Three files on the server or target host must be modified to get host-based authentication working:

• /etc/ssh/shosts.equiv
• /etc/ssh/ssh_known_hosts — hold the identities of the clients
• /etc/ssh/sshd_config — turn on host key authentication
• /root/.shosts — Only required to enable login for root user using key

Enable Host based authentication in /etc/ssh/sshd_config by modifying the below values

[root@rhel-8 ~]# egrep ^'HostbasedAuthentication|IgnoreRhosts' /etc/ssh/sshd_config
HostbasedAuthentication yes
IgnoreRhosts no

[root@rhel-8 ~]# cat /etc/ssh/shosts.equiv
rhel-7.example.com      root

Here /usr/libexec/openssh/ssh-keysign is used by ssh to access the local host keys and generate the digital signature required during host key authentication. They should be owned by root, readable only by root, and not accessible to others.

Next allow a public key for the client and append the keys to /etc/ssh/ssh_known_hosts using ssh-keyscan

[root@rhel-8 ~]# ssh-keyscan  rhel-7.example.com >> /etc/ssh/ssh_known_hosts
# rhel-7.example.com:22 SSH-2.0-OpenSSH_7.4
# rhel-7.example.com:22 SSH-2.0-OpenSSH_7.4
# rhel-7.example.com:22 SSH-2.0-OpenSSH_7.4

Since we have selected default key type, this command will get the public host key from the client node /etc/ssh/ssh_host_ecdsa_key.pub and append the same to /etc/ssh/ssh_known_hosts on the server node to enable host key authentication.

Verify the content of your ssh_known_hosts file, the content should be same as /etc/ssh/ssh_host_ecdsa_key.pub from the client node

[root@rhel-8 ~]# cat /etc/ssh/ssh_known_hosts
rhel-7.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINMVXhySksiT4SiRUJ4uDyjWb0MAQ79biNYSFReELxqt
rhel-7.example.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAmATinLkAUc6xcbdVOeNVaUS2LeWyKwks/CBZqMfk+Z7odrPwOiVcCpjz2eoQENWzKnQO7UxR2TzQuTls4n4Zk=

Below is the content from client node

[root@rhel-7 ssh]# cat /etc/ssh/ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAmATinLkAUc6xcbdVOeNVaUS2LeWyKwks/CBZqMfk+Z7odrPwOiVcCpjz2eoQENWzKnQO7UxR2TzQuTls4n4Zk=

[root@rhel-8 ~]# cat ~/.shosts
rhel-7.example.com root

Next restart the sshd service to activate the changes

[root@rhel-8 ~]# systemctl restart sshd

[root@rhel-7 ~]# ssh -v rhel-8.example.com
..
debug1: Authentications that can continue: 
debug1: Next authentication method: 
..
debug1: Authentication succeeded (hostbased).

..
debug1: Sending env LANG = en_US.UTF-8

[root@rhel-7 ~]# ssh -v rhel-8.example.com -l deepak
..
debug1: Authentications that can continue: 
debug1: Next authentication method: 
..

..

So our host key authentication is working as expected..

Why are SSH keys good?

• You don’t need a password to login to a server, which is a big time
  saver and productivity booster.
• Authentication becomes about «this is WHO may access something»
  rather than «here is the code to access it, we have no idea who
  knows it though».
• It removes the need to share server passwords
  • Better security practice
  • Easier auditing of exactly who used a server
• It enables the ability to grant temporary access to servers, and
  precisely control when it is revoked and from whom.
• Private keys can be protected with a passphrase, without which they
  can’t be used.
• Using SSH keys to control server access is a lot more secure since
  you can disable server password login entirely, thus kiboshing any
  chance of brute force attacks
• SSH keys can be used to support automatic connections between
  servers for backups, starting jobs, etc, without the need to store a
  password in plain text

Install PSSH

You can get PSSH rpm from EPEL repository

[root@centos-master ~]# rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Retrieving https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:epel-release-7-11                ################################# [100%]

Next you can install PSSH using yum

[root@centos-master ~]# yum install pssh

Perform parallel SSH (PSSH)

Now we are all setup with SSH public key authentication and we can execute PSSH without the need of giving any password. Additionally I am using some more SSHD options with PSSH to disable password based login and select passphrase based authentication.

[root@centos-master ~]# pssh -i -H "centos-client-1 centos-client-2" -l root -x "-o StrictHostKeyChecking=no -o GSSAPIAuthentication=no -o PreferredAuthentications=publickey -o PubkeyAuthentication=yes" hostname
[1] 23:07:10  centos-client-2

[2] 23:07:10  centos-client-1

As you see I did not use «-A» and yet the PSSH tool was able to connect to all the provided host without prompting for any password.

Once you are done, you must manually kill the PID created by ssh-agent. You can use kill -9 <PID of ssh-agent>

How to enable SSH access & configure network in rescue mode (CentOS/RHEL 7/8)

Lastly I hope the steps from the article to generate SSH Key pair and configure SSH public key authentication using PSSH with authorized_keys in RHEL/CentOS 7 Linux was helpful. So, let me know your suggestions and feedback using the comment section.

Steps to Creating SSH Keys on Ubuntu 20

1. Create the Key Pair

ssh-keygen

To create an SSH key on Linux, use ssh-keygen. This will generate an RSA key pair that is 3072-bit long by default.
You can also pass in the -b 4096 flag to create a larger 4096-bit key.

Output
Generating public/private rsa key pair.
Enter file in which to save the key (/your_home/.ssh/id_rsa):

To save the key pair into the .ssh/ subdirectory in your home directory, press enter. You can also specify an alternate path.

Output
/home/your_home/.ssh/id_rsa already exists.
Overwrite (y/n)?

You will not be able to authenticate using the previous key if you overwrite the key on the disk. Be cautious about selecting yes, as the changes cannot be reversed.

Output
Enter passphrase (empty for no passphrase):

The output is shown below —

Your identification has been saved in /your_home/.ssh/id_rsa
Your public key has been saved in /your_home/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host
The key's randomart image is:
+---[RSA 3072]----+
|                .|
|               + |
|              +  |
| .           o . |
|o       S   . o  |
| + o. .oo. ..  .o|
|o = oooooEo+ ...o|
|.. o *o+=.*+o....|
|    =+=ooB=o.... |
+----[SHA256]-----+

Public key authentication is a secure method of logging in to a remote server using an SSH key pair. You can use the public key on the server to authenticate with the private key on the client machine. Add the private key on your server for SSH-key-based authentication to log in, as shown in the next steps.

2. Copy the Public Key to the Ubuntu Server

We will copy the public key to the Ubuntu host using a utility called ssh-copy-id.

If you do not have ssh-copy-id on the client machine, use the alternate methods shown below-

• Copy via password-based SSH
• Manually copy the key

Copying the Public Key Using ssh-copy-id

The ssh-copy-id tool is added in many operating systems by default. You should already have password-based SSH access to your server.

The syntax is shown below —

ssh-copy-id username@remote_host

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

It shows that your local computer does not recognize the remote host. As it is the first time you connect to a new host. Type in yes and then press ENTER to continue.

Output
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@203.0.113.1's password:

Type in the password and press ENTER. The utility will connect to the account on the remote host using the password. It will then copy the contents of the ~/.ssh/id_rsa.pub key into a file. It will be located in the remote account’s home ~/.ssh directory called authorized_keys.

Output
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'username@203.0.113.1'"
and check to ensure that only the key(s) you wanted were added.

Now the id_rsa.pub key has been uploaded to the remote account. You can move on to the next steps.

Copy the Public Key Using SSH

If you have password-based SSH access to an account on your server, upload your keys with the SSH method.

Use the cat command to read the contents of the public SSH key on our local computer. You can then pipe it through an SSH connection to the remote server.
Ensure that the ~/.ssh directory exists on the other side and has the correct account permissions.

Output the content into a file called authorized_keys within this directory. You can use the >> redirect symbol to append the content instead of overwriting it. It allows you to add keys without removing the previously added keys.

The full command is shown below:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

The local computer does not recognize the remote host. It will happen the first time you connect to a new host. Type yes and press ENTER to continue.

Output
username@203.0.113.1's password:

After adding your password, the content of the id_rsa.pub key will be copied to the end of the authorized_keys file. You can move to the next step if you have done it correctly.

Manually Copy the Public Key

If you do not have password-based SSH access to your server, you can complete the process manually.

Append the content of your id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote machine.

cat ~/.ssh/id_rsa.pub

The key’s content will be displayed like this —

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

Ensure that the ~/.ssh directory exists once you have access to your account on the remote server.

mkdir -p ~/.ssh

echo public_key_string >> ~/.ssh/authorized_keys

Ensure that the ~/.ssh directory and authorized_keys file have the right permissions:

chmod -R go= ~/.ssh

The command removes all “group” and “other” permissions for the ~/.ssh/ directory.

chown -R sammy:sammy ~/.ssh

3. Authenticating to the Ubuntu Server Using SSH Keys

ssh username@remote_host

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

It shows the local computer does not recognize the remote host. Type in yes and then press ENTER to continue.

If you did not add a passphrase for the private key, you are logged in immediately. Otherwise, you will be prompted to enter the passphrase that you had previously created. After authenticating, a new shell session will open with the configured account on the Ubuntu server.

After the key-based authentication, you can secure the system by disabling the password authentication.

4. Disable Password Authentication

The password-based authentication is still active, and the server may be at risk of brute force attacks. Ensure that you have SSH-key-based authentication configured for a non-root account on the server with sudo privileges.

Open the SSH daemon’s configuration file —

sudo nano /etc/ssh/sshd_config

Look for a directive called PasswordAuthentication. It is commented with a # at the beginning of the line. Now uncomment the line by removing the #, and set the value to no. It will disable the ability to log in via SSH using account passwords:

/etc/ssh/sshd_config
. . .
PasswordAuthentication no
. . .

Save and close the file by pressing CTRL+X. Press Y to confirm saving the file, and then press ENTER to exit nano. Restart the sshd service to activate the changes:

sudo systemctl restart ssh

Open a new terminal window and test that the SSH service is working well before closing the current session:

ssh username@remote_host

After confirming that the SSH service is working, you can close all current server sessions. The SSH daemon on the Ubuntu server now responds to SSH-key-based authentication, and the password-based logins have been disabled successfully.

Understanding SSH Keys: Setting Up, Adding, and Using Public and Private Keys

What is Secure Shell (SSH)?

Secure Shell (SSH) is a widely used network protocol for establishing secure shell access between computers.

Why is setting up an SSH key important?

Setting up an SSH key is crucial for establishing a secure connection between a client and a server.

How can I set up an SSH server on Ubuntu?

How do I add an SSH key to Bitbucket on Ubuntu?

How can I enable SSH key login?

How can I use SSH keys?

What are the default public and private key file names?

Configure Host Based Authentication per User

• deepak → Allow host key authentication and disable Public Key Authentication
• rahul → Allow Public Key Authentication and disable Host Key and password based authentication
• All other → For all other users on the system only allow password based authentication

To achieve this you can add below entry in your /etc/ssh/sshd_config

Match User deepak
        PasswordAuthentication no
        HostbasedAuthentication yes
Match User rahul
        HostbasedAuthentication no
        PasswordAuthentication no
        PubkeyAuthentication yes
Match all
        PasswordAuthentication yes

Next restart your sshd service

[root@rhel-8 ~]# systemctl restart sshd

[root@rhel-7 ~]# ssh  rhel-8.example.com -l rahul
Permission denied ().

As you see it does not supports host and password based authentication

[root@rhel-7 ~]# ssh  rhel-8.example.com
root@rhel-8.example.com's password:

You can enable debug mode and get more details on supported authentication modes.

[root@rhel-7 ~]# ssh  rhel-8.example.com -l deepak
Last login: Thu Nov 21 23:54:21 2019 from rhel-7.example.com
[deepak@rhel-8 ~]$

Configure SSH public key authentication

I have 3 nodes with me using which I will configure SSH public key authentication to login to Linux server without password

• centos-master
• centos-client-1
• centos-client-2

Here, I will generate SSH key pair on centos-master using which we will attempt to login and connect to centos-client nodes without password (using ssh public key authentication)

1. Generate SSH key pair (private and public)

The first step would be to generate private and public ssh key. Here centos-master will be my master server.

[root@centos-master ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .
Your public key has been saved in .
The key fingerprint is:
SHA256:WDIWm4i8/UhU/zjiKZrmGVcg5PZj5mzXT4aZd37Gnbs root@centos-master.example.com
The key's randomart image is:
+---[RSA 2048]----+
|  .   o          |
| + . o =         |
|  * + * o        |
| . * o = o       |
|  . B + S .      |
|   * * + =       |
|  . B = = + .. ..|
|  .B o   = o  +..|
| o=       . .o Eo|
+----[SHA256]-----+

2. Copy public key to remote Linux machine (authorized_keys)

When you connect to your remote host, SSH validates the key ID you’re providing against a list of authorized_keys. There is one utility, ssh-copy-id, which is also bundled with OpenSSH and can be used to copy the key to the remote system. It automatically copies the ~/.ssh/id_rsa.pub file by default into the remote system

[root@centos-master ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub 
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ""
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@centos-client-1's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'root@centos-client-1'"
and check to make sure that only the key(s) you wanted were added.

[root@centos-master ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub 
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
Password:

Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'centos-client-2'"
and check to make sure that only the key(s) you wanted were added.

Basics OpenLDAP Tutorial for Beginners — Understanding Terminologies & Usage

3. Configuring and Securing Login (sshd_config)

Now, since we have configured the SSH key-based authentication in the previous section, we can disable the password authentication to secure SSH logins in the SSH server configuration file. Edit the SSH daemon config file on the remote host running the SSH server and set the PasswordAuthentication directive value to no as shown here:

# vi /etc/ssh/sshd_config
PasswordAuthentication 

PermitRootLogin yes

Allow only key-based ssh login in the root account by setting the directive PermitRootLogin value as without-password as shown here:

PermitRootLogin 

After making changes in the SSH server configuration file /etc/ssh/sshd_config, restart the sshd service to bring the applied changes into effect, as shown here:

# systemctl restart sshd

What are SSH keys for?

My Lab Environment

I am using RHEL 7 and 8 Linux hosts to configure Host based authentication. Here rhel-7 will be my client using which I will initiate the SSH connection while rhel-8 will act as a server.

[root@rhel-7 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.10.10.7      rhel-8.example.com      rhel-8
10.10.10.10     rhel-7.example.com	rhel-7

I have disabled selinux for this article on both my nodes.

Tips

• SSH keys are just plain text, making them dead easy to backup in a
  Password Manager such as LastPass,
  KeePass, or
  1Password.
• SSH keys work just fine from Windows. Tools such as PuTTY and WinSCP
  support them, although you need to initially change the format of
  the private key to ppk using PuTTYGen, an ancillary PuTTY
  tool.

• • To make an ssh connection using a key not in the default
    location, use the -i flag, for example

    ssh -i ~/Dropbox/ssh-keys/mykey foo@bar.com
    

• To see more information about setting up SSH keys, type:

  man ssh
  

• 

Setting up SSH keys

Working with SSH keys involves taking the public key from a pair, and
adding that to another machine in order to allow the owner of the pair’s
private key to access that machine. What we’re going to do here is
generate a unique key pair that will be used as the identity across the
cluster. So each node will have a copy of the private key, in order to
be able to authenticate to any other node, which will be holding a copy
of the public key (as well as, in turn, the same private key).

In this example I’m going to use my own client machine to connect to the
cluster. You could easily use any of the cluster nodes too if a local
machine would not be appropriate.

SSH key strategy

We’ve several ways we could implement the SSH keys. Because it’s a
purely sandbox cluster, I could use the same SSH key pair that I
generate for the cluster on my machine too, so the same public/private
key pair is distributed thus:

If we wanted a bit more security, a better approach might be to
distribute my personal SSH key’s public key across the cluster too, and
leave the cluster’s private key to truly identify cluster nodes alone.
An additional benefit of this approach is that is the client does not
need to hold a copy of the cluster’s SSH private key, instead just
continuing to use their own.

For completeness, the extreme version of the key strategy would be for
each machine to have its own ssh key pair (i.e. its own security
identity), with the corresponding public keys distributed to the other
nodes in the cluster:

But anyway, here we’re using the second option — a unique keypair used
across the cluster and the client’s public ssh key distributed across
the cluster too.

Generating the SSH key pair

First, we need to generate the key. I’m going to create a folder to hold
it first, because in a moment we’re going to push it and a couple of
other files out to all the servers in the cluster and it’s easiest to do
this from a single folder.

mkdir /tmp/rnmcluster02-ssh-keys

Note that in the ssh-keygen command below I’m specifying the target
path for the key with the -f argument; if you don’t then watch out
that you don’t accidentally overwrite your own key pair in the default
path of ~/.ssh.

The -q -N "" flags instruct the key generation to use no passphrase
for the key and to not prompt for it either. This is the lowest friction
approach (you don’t need to unlock the ssh key with a passphrase before
use) but also the least secure. If you’re setting up access to a machine
where security matters then bear in mind that without a passphrase on an
ssh key anyone who obtains it can therefore access any machine to which
the key has been granted access (i.e. on which its public key has been
deployed).

ssh-keygen -f /tmp/rnmcluster02-ssh-keys/id_rsa -q -N ""

This generates in the tmp folder two files — the private and public
(.pub) keys of the pair:

robin@RNMMBP ~ $ ls -l /tmp/rnmcluster02-ssh-keys
total 16
-rw-------  1 robin  wheel  1675 30 Nov 17:28 id_rsa
-rw-r--r--  1 robin  wheel   400 30 Nov 17:28 id_rsa.pub

Preparing the authorized_keys file

So we’re going to copy the public key of the unique pair that we just
created for the cluster into the authorized_keys file. In addition we
will copy in our own personal ssh key (and any other public key that we
want to give access to all the nodes in the cluster):

cp /tmp/rnmcluster02-ssh-keys/id_rsa.pub /tmp/rnmcluster02-ssh-keys/authorized_keys
# [optional] Now add any other keys (such as your own) into the authorized_keys file just created
cat ~/.ssh/id_rsa.pub >> /tmp/rnmcluster02-ssh-keys/authorized_keys
# NB make sure the previous step is a double >> not > since the double appends to the file, a single overwrites.

Distributing the SSH artefacts

• id_rsa — the private key of the key pair
• id_rsa.pub — the public key of the key pair. Strictly speaking
  this doesn’t need distributing to all nodes, but it’s conventional
  and handy to hold it alongside the private key.
• authorized_keys — this is the file that the sshd daemon on
  each node will look at to validate an incoming login request’s
  offered private key, and so needs to hold the public key of anyone
  who is allowed to access the machine as this user.

To copy the files we’ll use scp, but how you get them in place
doesn’t really matter so much, so long as they get to the right place:

scp -r /tmp/rnmcluster02-ssh-keys root@rnmcluster02-node01:~/.ssh

Run the scp for all nodes in the cluster. If you’ve four nodes in the
cluster your output should look something like this:

$ scp -r /tmp/rnmcluster02-ssh-keys/ root@rnmcluster02-node01:~/.ssh
root@rnmcluster02-node01's password:
authorized_keys                                                  100%  781     0.8KB/s   00:00
id_rsa                                                           100% 1675     1.6KB/s   00:00
id_rsa.pub                                                       100%  400     0.4KB/s   00:00
$ scp -r /tmp/rnmcluster02-ssh-keys/ root@rnmcluster02-node02:~/.ssh
Warning: Permanently added the RSA host key for IP address '172.28.128.7' to the list of known hosts.
root@rnmcluster02-node02's password:
authorized_keys                                                  100%  781     0.8KB/s   00:00
id_rsa                                                           100% 1675     1.6KB/s   00:00
id_rsa.pub                                                       100%  400     0.4KB/s   00:00
$ scp -r /tmp/rnmcluster02-ssh-keys/ root@rnmcluster02-node03:~/.ssh
root@rnmcluster02-node03's password:
authorized_keys                                                  100%  781     0.8KB/s   00:00
id_rsa                                                           100% 1675     1.6KB/s   00:00
id_rsa.pub                                                       100%  400     0.4KB/s   00:00
$ scp -r /tmp/rnmcluster02-ssh-keys/ root@rnmcluster02-node04:~/.ssh
root@rnmcluster02-node04's password:
authorized_keys                                                  100%  781     0.8KB/s   00:00
id_rsa                                                           100% 1675     1.6KB/s   00:00
id_rsa.pub                                                       100%  400     0.4KB/s   00:00

Testing login authenticated through SSH keys

The moment of truth. From your client machine, try to ssh to each of the
cluster nodes. If you are prompted for a password, then something is not
right — see the troubleshooting section below.

If you put your own public key in authorized_keys when you created it
then you don’t need to specify which key to use when connecting because
it’ll use your own private key by default:

robin@RNMMBP ~ $ ssh root@rnmcluster02-node01
Last login: Fri Nov 28 17:13:23 2014 from 172.28.128.1



[root@localhost ~]#

There we go — logged in automagically with no password prompt. If we’re
using the cluster’s private key (rather than our own) you need to
specify it with -i when you connect.

robin@RNMMBP ~ $ ssh -i /tmp/rnmcluster02-ssh-keys/id_rsa root@rnmcluster02-node01
Last login: Fri Nov 28 17:13:23 2014 from 172.28.128.1



[root@localhost ~]#

Troubleshooting SSH key connections

[root@localhost .ssh]# ls -l ~/.ssh/authorized_keys
-rw-r--r-- 1 root root 775 Nov 30 18:55 /root/.ssh/authorized_keys

If you get this:

[root@localhost .ssh]# ls -l ~/.ssh/authorized_keys
ls: cannot access /root/.ssh/authorized_keys: No such file or directory

then you have a problem.

[root@localhost .ssh]# ls -lR
.:
total 12
-rw------- 1 root root 1675 Nov 22  2013 id_rsa
-rw-r--r-- 1 root root  394 Nov 22  2013 id_rsa.pub
drwxr-xr-x 2 root root 4096 Nov 30 18:49 rnmcluster02-ssh-keys

./rnmcluster02-ssh-keys:
total 12
-rw-r--r-- 1 root root  775 Nov 30 18:49 authorized_keys
-rw------- 1 root root 1675 Nov 30 18:49 id_rsa
-rw-r--r-- 1 root root  394 Nov 30 18:49 id_rsa.pub
[root@localhost .ssh]#

To fix this simply move the authorized_keys from
rnmcluster02-ssh-keys back into .ssh:

[root@localhost .ssh]# mv ~/.ssh/rnmcluster02-ssh-keys/authorized_keys ~/.ssh/

robin@RNMMBP ~ $ ssh -i /tmp/rnmcluster02-ssh-keys/id_rsa root@rnmcluster02-node01
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/tmp/rnmcluster02-ssh-keys/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /tmp/rnmcluster02-ssh-keys/id_rsa

Another one that has bitten me twice over time — and that eludes the
troubleshooting I’ll demonstrate in a moment — is that SELinux gets
stroppy about root access using ssh
keys. I always
just take this as a handy reminder to disable selinux (in
/etc/selinux/config, set SELINUX=disabled), having never had cause
to leave it enabled. But, if you do need it enabled you’ll need to hit
the interwebs to check the exact cause/solution for this problem.

So to troubleshoot ssh key problems in general do two things. Firstly
from the client side, specify verbosity (-v for a bit of verbosity,
-vvv for most)

ssh -v -i /tmp/rnmcluster02-ssh-keys/id_rsa root@rnmcluster02-node01

You should observe ssh trying to use the private key, and if the server
rejects it it’ll fall back to any other ssh private keys it can find,
and then password authentication:

[...]
debug1: Offering RSA public key: /tmp/rnmcluster02-ssh-keys/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: password

Quite often the problem will be on the server side, so assuming that you
can still connect to the server (eg through the physical console, or
using password authentication) then go and check /var/log/secure where
you’ll see all logs relating to attempted connections. Here’s the log
file corresponding to the above client log, where ssh key authentication
is attempted but fails, and then password authentication is used to
successfully connect:

Nov 30 18:15:05 localhost sshd[13156]: Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
Nov 30 18:15:15 localhost sshd[13156]: Accepted password for root from 172.28.128.1 port 59305 ssh2
Nov 30 18:15:15 localhost sshd[13156]: pam_unix(sshd:session): session opened for user root by (uid=0)

Now we can see clearly what the problem is — «bad ownership or modes
for file /root/.ssh/authorized_keys«.

/usr/sbin/sshd -D -d -p 2222

Now on the client retry the connection, but pointing to the port of the
interactive sshd instance:

ssh -v -p 2222 -i /tmp/rnmcluster02-ssh-keys/id_rsa root@rnmcluster02-node01

When you run the command on the client you should get both the client
and host machine debug output go crackers for a second, giving you
plenty of diagnostics to pore through and analyse the ssh handshake etc
to get to the root of the issue.

How login to Linux server works without password?

Secure Shell relies on a technology called public-key cryptography. It works similarly to a safe deposit box at the bank: You need two keys to open the box or at least multiple layers of security/checks have to be crossed. In the case of public-key cryptography, you need two mathematical keys: a public one and a private one.

The actual process of encrypting data and sending it from one person to the next requires several steps. We’ll use the popular “Alice and Bob” analogy and go through the process one step at a time as they both try to communicate in a secure manner with one another.

Host Based authentication vs Public key based authentication

Host based authentication is different compared to SSH Public Key Authentication in terms of configuration, although in the backend both perform secure connection using public host key authentication.

Below I have consolidated a list of comparison and difference between Host Key Authentication vs Public key Authentication

How to create windows undetectable payload — technowlogger

More details on SSH Public Key Authentication (with and without password) in Linux

Create ssh authenticating agent (ssh-agent)

However, we did still have to enter the password we set on the private SSH key. If you have to do this each time you want to connect to a remote host, it defeats the purpose of setting up key-based authentication. SSH agent, a small daemon that keeps unlocked private SSH keys in memory.

Tutorial: Encrypt, Decrypt, Sign a file with GPG Public Key in Linux

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA, Ed25519). ssh-agent is usually started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

[root@centos-master ~]# eval `ssh-agent` ssh-add /root/.ssh/id_rsa
Agent pid 4696
Enter passphrase for /root/.ssh/id_rsa:
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)

Verify the process status

[root@centos-master ~]# ps -ef | grep ssh-agent
root      4696     1  0 21:32 ?        00:00:00 
root      4699  4004  0 21:32 pts/0    00:00:00 grep --color=auto ssh-agent

Troubleshooting Host Key Authentication

While configuring host based authentication I faced some error:

userauth_hostbased mismatch: client sends rhel-7.example.com, but we resolve 10.10.10.10 to rhel-7

 
Solution:
This occurs because we have disabled UseDNS directive which is why the sshd_config fails to resolve hostname. Once you enable this directive in sshd_config, this should be fixed.

Lastly I hope the steps from the article to configuring and understanding host based authentication vs Public key Authentication on RHEL/CentOS 7 and 8 Linux was helpful. So, let me know your suggestions and feedback using the comment section.

References:
Host Based Authentication Wiki

Summary

An SSH key is a secure and efficient way to authenticate and connect to a remote server, such as during an ubuntu server ssh setup. It ensures that commands typed in the terminal are sent securely via an encrypted channel. With SSH, you can run commands on remote machines, create tunnels, forward ports, etc. It supports authentication mechanisms such as password and public-key-based.

We looked at how to add SSH keys on Ubuntu 20.04, which involves steps like allowing SSH access (ubuntu allow ssh) and configuring the settings (ubuntu config ssh). To get your SSH key in Linux, you can use the command get my ssh key linux. If you encounter any issues related to host bits being set in Ubuntu (has host bits set ubuntu), it’s essential to address them for a successful connection.

To generate an SSH key pair (how to gen ssh key), you can use tools like ssh-keygen. This process will also show you how to make a public key for authentication purposes. Once you’ve created your keys, setting up ssh key authentication becomes straightforward.

Security Considerations

To further harden your SSH server, you should:

• Change its port from the default 22 to something with a 5-digit number (less than 65536, due to the port number being a 16-bit value)
• Disable password-based SSH login for all users (not only root)
• Use strong keypairs with 2048-bit or 4096-bit private keys. Always use RSA, not the weaker algs such as DSA.
• Set strong passwords for all sudoers as well as root.