Saturday, April 27, 2013

How do I set up ssh keys and turn off password access on my new Linux box?

To start off, we need to examine your local machine. Run the following command:
cat ~/.ssh/
If the above command prints "No such file or directory", then you'll need to generate an ssh key pair before continuing. If the previous command printed a bunch of funny looking letters and numbers, then you already have an ssh key pair on your local machine that we can make use of!

Okay, so if your machine doesn't already have an ssh key pair on file, we can easily create one. Enter the following command:
ssh-keygen -t rsa -C ""
You'll be prompted with the following:
Enter file in which to save the key (/Users/you/.ssh/id_rsa):
Just press enter and "~/.ssh/id_rsa" will be used (which is what we want).

Next, you'll be prompted with the following:
Enter passphrase (empty for no passphrase):
Press enter twice to generate a key pair without a passphrase.

Now, at this point, everybody should have an "~/.ssh/" file on their local machine. Next, connect to your remote machine using your password:
ssh -p your_port you@your_ip_address
Then, run the following command (to ensure you have an ".ssh" dir on file):
mkdir -p ~/.ssh
Now exit and return to your local machine:
Next, copy your public key to your remote machine:
scp -P your_ssh_port ~/.ssh/ your_user@your_ip_address:~/
Next, connect to your remote machine via username and password:
ssh -p your_port you@your_ip_address
Next, enter the following command:
cat ~/ >> ~/.ssh/authorized_keys
Then remove the source file:
rm ~/
Now, exit your remote machine:
SSH keys have now been set up! Now, with a single command you're into your remote machine:
ssh -p your_ssh_port you@your_ip_address
Boom! Time to disallow password-based ssh connections.

K, starting from within your remote machine, run the following command:
sudo nano /etc/ssh/sshd_config
Then, scroll down to the section that looks like this:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
and switch it to this:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
Save the file. Now restart the ssh daemon:
sudo /etc/init.d/ssh restart
Boom. We're done, ssh key pair connections only! Before exiting the remote machine you can validate this yourself if you'd like by walking through the following process:
  • Step 0) Make sure you have an open connection to your remote machine.
  • Step 1) Open a new Terminal window.
  • Step 2) Run the following command on your remote machine:
mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_mimic_no_machines_authed
  • Step 3) In your other Terminal window (local machine), try to ssh into your machine:
ssh -p your_ssh_port you@your_ip_address
You'll see the following output:
Permission denied (publickey).
Boom! Now das wassup!

If you're interested in what's going on process-wise, here's the skinny: By moving the location of the "authorized_keys" file on the remote machine we're mimicking your local machine not having a "machine to machine ssh key connection" with your remote box. Therefore, when we run the above ssh command, ssh first tries to connect using your machine's local ssh key pair, but gets denied because the public key counterpart is "not on file" on our remote machine (remember that we moved the "authorized_keys" file to "authorized_keys_mimic_no_machines_authed" to create this scenario). Next, ssh looks to use a password picked up from the command line and gets rejected on that due to our latest sshd config update! Woo hoo! At this point you can test connecting with your root user too if you'd like and you'll see that not even root can log in to the remote machine! Now you see why I said, "Make sure you have an open connection to your remote machine." in "Step 0" above. Let's put things back now. Run the following command on your remote machine:
mv ~/.ssh/authorized_keys_mimic_no_machines_authed ~/.ssh/authorized_keys
Now, from your other Terminal window, you can run:
ssh -p your_ssh_port you@your_ip_address
And boom you'll be good to go.

Now das wassup! You're done! You can even exit your remote machine if you want!
Lastly, if you're coming from my "How do I set up Apache virtual hosts on a Debian based Linux machine and configure to support HTTPS?" post, you can get back to it here:

No comments:

Post a Comment

About Me

My photo
I code. I figured I should start a blog that keeps track of the many questions and answers that are asked and answered along the way. The name of my blog is "One Q, One A". The name describes the format. When searching for an answer to a problem, I typically have to visit more than one site to get enough information to solve the issue at hand. I always end up on,, random blogs, etc before the answer is obtained. In my blog, each post will consist of one question and one answer. All the noise encountered along the way will be omitted.