Configuring SSH Key Based Authentication

-

Overview

Most personal computers and many organizations running Linux servers utilize password-based authentication. This is what most of us are used to -- you enter a username and password in order to authenticate your account and gain access to a system. While straightforward and commonplace, this isn't the best solution in most cases. Today I'll be explaining why key based authentication is more convenient, more secure, and allows for automation of tasks without saving credentials in plain-text in a text file.

Key based authentication involves the use of private and public keys (public-key cryptography). The private key is stored on the client and the public key is stored on the server in a special file (~/.ssh/authorized_keys). This allows any system with the corresponding private key to login to the server where we just stored the public key.

Our steps are:
  1. Generate key pair (public / private key).
  2. Transfer public key and add it to the authorized_keys file on the remote server.
  3. Login remotely using a public/private key!

Generate Key Pair

First let's run ssh-keygen to generate the public / private key pair:


You'll then be asked where to save the key pair. I'd recommend sticking with the home directory of the user account you intend to login to -- just make sure permissions on your home directory are secure! This is followed by overwriting any existing id_rsa file present (and therefore not being able to authenticate with that key anymore if overwritten), and an optional password which encrypts the private key.


Let's confirm the presence of the keys in ~/.ssh by listing the contents of that directory using ls -l ~/.ssh.


And now we see them there!

Transfer and Add Public Key to Remote Server

There are several ways of going about moving your public key to the remote server, but today we will use ssh-copy-id. 

Type ssh-copy-id <username>@<hostname/IP> and press Enter. Yes, it really is that easy. You'll be prompted to confirm you trust the fingerprint of the host. Confirm this by typing yes and pressing Enter.


You'll be prompted to enter your password -- this is the password of the account on the remote machine. Once successful the the key will be added to the appropriate directory and file on the remote server.


Let's verify on the server that the authorized_keys file is now present under the home directory of the remote user by again entering ls -l ~/.ssh.


And there it is! Again, this is a copy of the public key we created back on the client. Note that the timestamp difference between it appearing here and me originally creating the key is only because this blog post was not done all in one evening. 😀

Finally, this is just one method to transfer the key to the remote server. You can use scp, copy-and-paste to append to an existing authorized_keys file via a terminal window, or any other secure method. 

Login Remotely! (Verifying Configuration)

Let's give it a go: ssh cody@10.0.2.5 (the IP address of the server I'm working with).


And we're authenticated! Notice the change from cody@client to cody@server without any prompt for a password.

If you run into issues at this step verify your permissions on the .ssh directory as well as the authorized_keys file. They should be 700 (rwx------) and 600 (-rw------) respectively.

Finally, once confident in this system in your environment, consider disabling password-based logins entirely.

Feel free to comment or reach out with any questions!

Additional Reading

Comments

Post a Comment

Popular Posts

Hashcat - Cracking MD5 and NTLM Hashes

-
Image
Today we'll be exploring Hashcat -- "the world’s fastest and most advanced password recovery utility". This, along with similar tools, should be used only for password recovery, pentest engagements, CTFs, etc and never for illegal purposes. I could write an entire series about the capabilities Hashcat provides, but we will cover a few basic examples for now ( besides, Hashcat does a pretty good job of that themselves ): Crack MD5 hashes using the rockyou.txt wordlist. Crack NTLM hashes using the rockyou.txt wordlist. Crack NTLM hashes using a mask attack (modified brute force). I'll be using Kali Linux as Hashcat comes pre-installed, but Hashcat can run on Windows, macOS, and other Linux distributions as well. As you'll see, I'll be using some lists of hashes I made previously. Tools to generate hashes using dozens of algorithms are available online -- just save the output as a text file if you want to follow along. Cracking MD5 Hashes Using rockyou.txt Wordl
Read more

Configuring Secure Ciphers Suites and TLS

-
Image
Hey everyone, today we're back on cipher suites. If you want a refresher of TLS and secure cipher suites overall, check out my previous post . There are many instances in which you'll need to edit cipher suites on a system -- compliance efforts, CIS benchmarks, or simply ensuring your system doesn't use insecure suites. There are a few ways to go about this and I'll detail two of them now: IIS Crypto and the Windows registry. IIS Crypto My favorite way of editing TLS versions and cipher suites is using IIS Crypto . IIS Crypto allows you to select your desired TLS/SSL version, cipher suites, and backup the registry, all with a few mouse clicks. Only downside is that it's Windows only (even the command line version). This is what IIS Crypto will look like on an unmodified Windows 10 system. Note the separate  Server Protocols  and  Client Protocols  sections. These are important to keep straight depending on what system is listening for connections and what system is
Read more