How to use a Private key for SSH authentication

Use a Private key for SSH authentication

What’s a private key?

Even the most complex passwords cannot match the cryptographic strength of private keys. With SSH, private keys significantly improve security by relieving users of the burden of remembering complex passwords (or worse yet, writing them down).

Let’s first Open a terminal and generate a private key.

Step 1 : Check to see if you already have an SSH key.

$ ls ~/.ssh

Output:

Step 2 : Create SSH key.

$ ssh-keygen

Output:

– The command will prompt you for a file name. By default, the ssh key pairs are stored as id_rsa and id_rsa.pub for private key and public key, respectively.

$ Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa):

To use the default filename, press ENTER and proceed.

In the next part, enter a passphrase to secure your key pairs. You can skip this by pressing ENTER.

$  Enter passphrase (empty for no passphrase):

$  Enter same passphrase again:

Step 3 : Copy public key to the remote host.

$ ls ~/.ssh

Output:

To use the SSH key pair you created, we must first copy the public key to the remote server. Fortunately, OpenSSH includes the ssh-copy-id function to do this.

$ ssh-copy-id remote_server_user@remote_server_ip

Step 4 : SSH using The Private Key.

$ ssh remote_server_user@remote_server_ip

You have now successfully utilized SSH key-based authentication. By eliminating password login, you may provide an extra degree of protection.

Conclusion

This tutorial has shown you how to create SSH key pairs and copy the keys to remote hosts. The steps mentioned above allow you to authenticate SSH sessions without using a password. Furthermore, you may control numerous servers at the same time with a single key pair.

10 thoughts on - How to use a Private key for SSH authentication

  • This is not SSH using private key, this is ssh using Public Key, you copied public key to target server.

    Private key based autentication is you copy the private key of target server into Source server and pass it with ssh command with “-i” attribule

    • Hi,
      Thank you for your response,
      As stated in the article, we are connecting using a private key we didn’t use -i attribute because we are using the key located in ~/.ssh/id_rsa
      when id_rsa file exists, the ssh command applies -i ~/.ssh/id_rsa automatically.
      I hope you found this helpful, don’t hesitate to ask .
      Best regards.

  • This is not using the private key and this is ssh using the public key as needs to be registered to a remote server, the writer surely didn’t know the difference. Using the private key to login to the ssh server means that you can use a single private key from any machine, anywhere, and still be able to login to the remote server without any registering overhead.

    • Hi,
      The public key needs to be registered on the remote server, ensuring that only the corresponding private key can gain access. While using the private key for SSH login provides convenience, it’s essential to note that this private key should be kept secure, and its compromise can result in unauthorized access.

  • Can you show me how copy the private key of target server into Source server and pass it with ssh command with “-i” attribute from Windows cmd command line or winSCP?

      1. – Navigate to your home directory on the remote host.
        – Create a new file named authorized_keys if it doesn’t already exist:
        touch ~/.ssh/authorized_keys
        – Use a text editor to open the authorized_keys file and paste your public key into it.
        – Save the file. use -i and specify private key path
  • Webhi has everything right, all those saying it is using the public key and not the private key are misunderstanding the entire concept of key based authentication (using public/private keys). The public key is tied to the private key. The public key is stored on the server and the private key is used by the client to connect (which succeeds because the public key is on the server and is tied to the private key the client is using to try and connect). If -i is not used in the ssh command the default path for the private key is used to locate the private key to be used (~/.ssh directory on Linux) and is used for the current user trying to login to the remote system. If you are using a private key for a user other than yourself -i can be used (e.g ssh -i /path/to/id_rsa someotheruser@sshsever.

    hence why it is vital to keep private ssh keys secure. For example I am a pentester and if I manage to get a private ssh key for a user and download it locally wherever I want in my file system, and as long as I know the username I can use it to login to the remote ssh server with ‘ssh -i /path/to/id_rsa username@sshserver.

    Even if there is a pass phrase for the private key this can potentially be cracked to reveal the passphrase. E.g use ssh2john on the id_rsa file to format it into a hash compatible with the popular password cracking tool john the ripper and then use john the ripper to crack the pass phrase (success in this respect depends on the strength of the pass phrase and quality of the wordlist used to try and crack it)

  • The private key should only ever be known to the individual the private key belongs to. The public key can be given to anyone, this is the whole concept of asymmetric encryption. The only thing that (in theory) can be used to decrypt something encrypted with someone’s public key is the corresponding private key.

    This can be used in a number of ways. For example if I want to send some information and I want people to know it has come from me I can encrypt it with my private key and the only thing that (in theory) can decrypt it is my public, but this is public by it’s very nature and can be shared with anyone. So, they can use my public key to decrypt it and if it works the information has come from me, as the only thing that can decrypt something encrypted with my private key is my public key (as the public and private keys are linked using very large prime numbers, which all gets a bit complex).

    On the flip side if someone wants to send me some information that they want only me to see they can encrypt it with my public key, and then the only person that can decrypt it (in theory) is me as I am the only person (or at least should be the only person) that has my private key, which is the only thing that can decrypt something encrypted with my public key.

    such is the beauty of asymmetric encryption vs symmetric encryption (same key used to encrypt and decrypt), although asymmetric encryption is slower than symmetric and a lot of the time asymmetric encryption is used to share a key and then symmetric encryption is used thereafter as it is faster (the main issue with symmetric encryption is that the other party needs to know the encryption/decryption key which you can’t just send them as it could be intercepted, but you can use asymmetric encryption as described above to send it securely!)

LEAVE A COMMENT