SSH Authentication with Public Keys
This is a well-known capability in Unix-Based System (as far I know), quite dangerous but extremely useful in testing environment on which you may trade safety for speed, if you are willing to face consequences (if something goes wrong).
SSH can allows you to authenticate via several methods, the most common is the password but it can also rely directly on public keys to perform the authentication without the need of a password. As a say, this is for testing environments, the public key should be kept in a safe place on which you can control it.
Now, let’s say that we have two machines (machineA and machineB), and I would like that “user” is capable to connect as “root” without password.
Step 1: Public key generation
On machine A, we will use the command ssh-keygen, just hit enter on every single question, use just the default values
[[email protected]]~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/machineA/.ssh/id_rsa):
Created directory '/home/machineA/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/machineA/.ssh/id_rsa.
Your public key has been saved in /home/machineA/.ssh/id_rsa.pub.
The key fingerprint is:
Now we have the pub key generated at /home/machineA/.ssh/id_rsa.pub. and the private key at /home/machineA/.ssh/id_rsa, those files are vital (specially the private key).
Step 2: Place the public key on target machine
Now use the following command on machineA:
[[email protected] ~]$ ssh-copy-id -i .ssh/id_rsa.pub [email protected]
The authenticity of host ’machineB (192.168.1.5)’ can’t be established.
RSA key fingerprint is cb:d6:45:da:44:cf:10:4a:c6:80:f5:fa:a6:10:3a:43.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’machineB′ (RSA) to the list of known hosts.
[email protected] password:
ssh-copy-id will place the key in the right place for you, but it will attempt to do a SSH connection, provide the password for this time.
Step 3: Now, test it!!
On your machineA, do the classic:
and no password will be requested
Step 4 (Optional): Propagate the keys
On your machineA, you can copy (keep the folder structure) the files /home/machineA/.ssh/id_rsa.pub. and the private key at /home/machineA/.ssh/id_rsa, to any other machine in the same network, and you can perform the ssh connection to machineB from there without password, you can feel the power now.
This example did show you the advantage of the authentication method with the public keys, but I did something evil, if you notice, the “user” on machineA, that could be any lower-level user (probably a limited user) and I’m giving a god-like power to him by placing the public key on the root user on machineB, I’m sure you notice how “exposed” is machineB to any potential damage from the “user” on machineA. “User” is now capable to use several critical commands on machineB, so you can expect nasty things if you are not careful.
In my job I follow my two golden rules:
- Don’t use it on PRODUCTION, please. If you lose the file /home/machineA/.ssh/id_rsa , look for another job.
- At all costs, do not impersonate the root user directly with the public key, use limited user account on both machines and force them to use sudo.
Latest posts by Carlos Alberto Umanzor Arguedas (see all)