On September 9th, 2015 Chris L. asked…

Hello Matt and the Freedom Penguin staff! I have a question about generating RSA public and private keys under Linux. Is there a Linux/Open Source equivalent to PuTTYgen? A PuTTY GUI is available in Ubuntu GNOME 15.04 (what I am using), but is there a PuTTYgen GUI that I can install over the CLI? If not, can you give a short tutorial on how to do this in the command-line? Congratulations on the site, added to my favorites! I miss you on LAS, but I’m glad you are back with this awesome idea.

Chris (all the way from Japan)

Hi Chris!

Allow me to let you in on a little secret – I have never used PuTTY or PuTTYGen. All of my key generation has always been done in the Linux command line. Lucky for you my familiarity with the latter is going to help you overcome the former.

First, allow me to acknowledge that most documentation is convoluted. Despite interesting details being presented, often it comes across as a wall of text to Linux newcomers or those simply new to certain aspects of Linux.

On the client side, Ubuntu comes with the SSH client already installed. You can’t see it, because it’s not a GUI application. For the server (the remote computer you wish to SSH into), you’ll need to install the SSH server software.

The steps we’re going to be taking break down as follows:

1) Generate a key on your local machine.
2) Install OpenSSH Server on remote machine.
3) Send the key to your remote machine.
4) Lockdown the remote machine by removing the password authentication.

Step #1 – From your local machine, you need to create RSA keys. This provides a private key for your local machine and a public one for your remote machine.

On your local machine, in a terminal:

mkdir ~/.ssh

If it already exists that’s great, let’s make sure the permissions are correct.

chmod 700 ~/.ssh
cd ~/.ssh

Now let’s create our keys.

ssh-keygen -t rsa

This will kick out the following cryptic tidbit:

Generating public/private rsa key pair.

Let’s give the keys a name like this.

Enter file in which to save the key: (/home/USER/.ssh/id_rsa): type-something-clever-here

Next, you’re going to want to provide a pass phrase to protect the private key that resides on your local machine. This isn’t to be confused with the SSH server password or anything related. The entire purpose of this pass phrase is to protect the private key on your local machine in case of theft.

Now if you get an error like the one below, try a longer pass phrase. To do this, type ssh-keygen -t rsa and redo the process.

Error example mentioned above:
passphrase too short: have 4 bytes, need > 4
Saving the key failed:

If everything went correctly, your ~/.ssh should contain the following: somethingclever.pub and somethingclever – to see the ~/.ssh directory, browse to /home/USER/ and type Ctrl+h to make the hidden directories visible.

Step #2 – If the remote machine is a desktop PC, you’ll likely need to sit in front of it and install OpenSSH server yourself. If this is an Ubuntu Server provided by a web hosting company however, you’re most likely already set to go. Here’s a tidbit no one ever talks about. If the remote machine is a desktop PC, the SSH password is your user’s password. Same applies for the server. The difference is with the server. You may be looking at a root user. Do NOT use a root user for SSH. It’s asking for trouble and completely unnecessary. Best to follow this guide (hat tip to Digital Ocean) and setup a regular user with sudo privileges instead.

Regardless of which type of remote machine it happens to be, let’s get OpenSSH Server installed next.

sudo apt-get install openssh-server

This will install the server component and start the service up for you. If for any reason you don’t see ssh start/running or the process appearing, you can manually start up the server. If you’re root, you can forgo the sudo for each command.

Ubuntu 15.04+

systemctl restart ssh

Ubuntu 14.04

 service ssh restart

This will get the OpenSSH server running on your system. Now that we have the server running, we need to send the public key over to the remote machine from the local machine.

Step #3 – Now we need to send your public key to the remote machine. To do this, we need to enter this code from the client machine.

ssh-copy-id username@host

The host is going to be the local IP address for the remote machine. During this process, you will be prompted for a password – it will be the password for the remote machine.

Step #4 – At this point, SSH works to access the remote machine from the local one. The next step is to disable password authentication as it’s very insecure. With the public key installed on the remote machine, it’s time to allow it to handle the SSH authentication.

First, SSH into the remote machine:

ssh username@host

After entering your password again, go ahead and use the nano editor to edit your SSH config on the remote machine. Remember, if you’re NOT root, be sure to use sudo below.

nano /etc/ssh/sshd_config

Scroll down and look for #PasswordAuthentication yes
Next, change the entry accordingly:

#PasswordAuthentication yes

into this

PasswordAuthentication no

At this point, you’re ready to save the file. Type Ctrl-x. When promoted to “Save the modified buffer”, type the Y key. As it presents you with “File name to write”, just hit the enter key. This modifies your SSH configuration and ensures you will only be able to login using your SSH key.

Final words of advice

I imagine this seems like a ton of information. After all, this is all keyboard and no GUI. But once you complete it you will be shocked at how simple it really is.

The only issue you might run into could be the ufw blocking port 22 (both locally and potentially on the remote machine). Use ufw but be aware that if you can’t connect it’s either because you uploaded the public key to the wrong user, you’ve been trying to SSH to the wrong host IP or you simply have port 22 blocked some place. Another issue to consider is trying to SSH into a remote host with an encrypted directory or perhaps your remote machine’s ~/.ssh permissions are screwy. This would mean accessing the machine through other means and adjusting the permissions for the remote machine’s affected directory.

chmod go-w ~/
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/authorized_keys

I hope this is helpful and best of luck in your Linux SSH adventures!

Do you have Linux questions you’d like Matt to help with? Hit the link here and perhaps you too, can Just Ask Matt!

Matt Hartley
Freedom Penguin’s founder & talking head – Matt has over a decade working with Linux desktops, his operating system experience consists of both Windows and Linux operating platforms. In addition to writing articles on Linux and open source technology for Datamation.com and OpenLogic.com/wazi, Matt also once served as a co-host for a popular Linux-centric podcast.

Matt has written about various software titles, such as Moodle, Joomla, WordPress, openCRX, Alfresco, Liferay and more. He also has additional Linux experience working with Debian based distributions, openSUSE, CentOS, and Arch Linux.

Written by Matt Hartley

Freedom Penguin’s founder & talking head – Matt has over a decade working with Linux desktops, his operating system experience consists of both Windows and Linux operating platforms. In addition to writing articles on Linux and open source technology for Datamation.com and OpenLogic.com/wazi, Matt also once served as a co-host...
Read more


Juan B. Rodriguez

I believe one of the best suggestions with regards to ssh on Linux is to embrace the config file. It really makes your life easier. Look for it in ~/.ssh/config. If it’s not there google it and implement it.


I completely agree regarding the embracing the config file, but I’d add that a lot of the resources out there fail to explain “implied” basics like what the password actually is for the remote machine. I think this is where a combination of trial and error with having access to a mentor can go a long way. Docs are notorious for implied information without fully walking folks through the entire thing.

The goal of this piece is to remove some of the implied stuff seen elsewhere, treat the reader student and walk them through the process in easy to digest bytes — an area Google fails in from my experience.

Rob MacDonald

Great guide but I’d add the following: once you’ve generated your key and use shh-copyid you have created /.ssh/authorized_keys if it was not already present, for whatever user id you specified in the ssh-copyid command for the remote system. You can easily copy, or create, that authorized keys file on any additional systems, or scp it. ssh-copyid doesn’t always work.

As well, you should probably stress the fact that once you disable password authentication on the system it’s only going to allow connections using keys. If the keys on either end get borked, you no longer have access to the system as you disabled password authentication.

Now the part that will get me the hate. This is only useful for ‘nix to ‘nix. Why not throw in the steps for putty and putty gen on windows? It’s dead simple. Or you can install openssh for windows and create the keys there. The only real difference with doing this on windows is that you have to link your private key to your ssh client (putty). openssh creates a .ssh folder in your windows user account but ssh clients on windows doesn’t automatically look for it.

Thanks again for this guide, I ran into some issues trying to make this work and as you stated, most of the resources out there ‘assume’ a certain level of knowledge.


How about a guide where you generate the keys server side? For those with local access to the machine, like with a home desktop. This might make the process easier for those wanting to use tablets or smart phones to ssh to the desktop.

Leave a Reply