As you can imagine, SSH keypairs – combinations of private and public keys – are vital elements of your digital identity as a sysadmin or a developer. And since they can be used for accessing source code repositories and for deploying changes to production environments, you usually have more than one SSH key. That’s why it’s important to know how to inspect SSH key fingerprints.

SSH Key Fingerprints

Key fingerprints are special checksums generated based on the public SSH key. Run against the same key, ssh-keygen command will always generate the same fingerprint.

Because of this property, you can use SSH key fingerprints for three things:

1. Identify SSH key – fingerprint will stay the same even if you rename the file
2. Confirm integrity of the SSH key  – if you get the same fingerprint from your private SSH key, you can be sure it’s still valid and intact
3. Validate identity of the SSH key – same fingerprint means you’re dealing with the same key (that you or your solution trusted for specific functionality)

How to Check SSH Fingerprint of a Key

ssh-keygen command takes the identity (SSH key) filename and calculates the fingerprint.

You can start by changing directory into .ssh and checking if you have any SSH keys there already. If not, you should generate a new SSH key.

greys@server:~$ cd .ssh
greys@server:~/.ssh$ ls -la
total 24
drwx------  3 greys greys 4096 Feb 17 21:11 .
drwxr-xr-x 15 greys greys 4096 Feb 17 21:13 ..
-rw-------  1 greys greys 1766 Feb 17 21:11 id_rsa
-rw-r--r--  1 greys greys  394 Feb 17 21:11 id_rsa.pub

Let’s run ssh-keygen to confirm the fingerprint of the id_rsa keypair:

greys@server:~/.ssh$ ssh-keygen -l -f id_rsa
2048 SHA256:z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI no comment (RSA)

Check Fingerprint of the Private SSH Key

By default this command looks for the public key portion (id_rsa.pub file), so it’s not a very good test of integrity or identity of the private key. There is a very real possibility that you have one private key and a separate public key, that are not related to each other.

That’s why for checking the private key you must take it a step further and copy private key (id_rsa) into some other directory where you can use ssh-keygen again:

greys@server:~/.ssh$ cp id_rsa ..
greys@server:~/.ssh$ cd ..

this time, because there’s no public key file found nearby, the ssh-keygen command will have to open private key. And if it’s passphrase protected (as it always should be), you’ll be asked for the SSH key passphrase:

greys@server:~$ ssh-keygen -l -f id_rsa
Enter PEM pass phrase:
2048 SHA256:z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI no comment (RSA)

Old-school SSH fingerprints

If you’ve been using Linux/Unix for more than a couple of years, you probably noticed that ssh-keygen now shows you a different looking fingerprints: they used to be these semicolon-delimited sequences like this:

06:6e:bc:f4:4e:03:90:b7:ba:99:8d:a5:71:1e:dc:22

… instead they now are shown as this:

z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI

The reason for this is that by default fingerprints are shown as SHA256 sequences, while in the past they were MD5.

In order to show the SSH fingerprint in MD5 format, just specify this in the command line:

greys@server:~$ ssh-keygen -l -E md5 -f id_rsa
Enter PEM pass phrase:
2048 MD5:06:6e:bc:f4:4e:03:90:b7:ba:99:8d:a5:71:1e:dc:22 no comment (RSA)

See Also

• How To: Generate SSH key
• How To: Change SSH key passphrase
• SSH port
• SSH port forwarding
• SSH
• Important SSH server configuration options

SSH is such an integral part of everyday Linux/Unix life now, that it makes sense to use it for as many remote access and automation tasks as you can. As you probably know, you shouldn’t be using password SSH authentication unless you have a pretty good reason to do so. By default, always use SSH keys. Today I’ll show you how to generate SSH keys.

Generate SSH key with ssh-keygen

ssh-keygen is a standard utility supplied with SSH package. If you have ssh command on your system, you probably have the ssh-keygen command as well.

Without any command line options, ssh-keygen will ask you a few questions and create the key with default settings:

[greys@rhel8 ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/greys/.ssh/id_rsa):
Created directory '/home/greys/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/greys/.ssh/id_rsa.
Your public key has been saved in /home/greys/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Seu7UBogeX+g9+iv01CDJqiXAby740JKZGrZtu1T3oQ greys@rhel8
The key's randomart image is:
+---[RSA 2048]----+
|. |
|.. . |
| .+.o ... |
| +oo.+oooo |
|+.+o.o+.S. |
|o*oo ..E . |
|=.o o *o= |
|oo . +.o.o |
|o.. ..+++. |
+----[SHA256]-----+
[greys@rhel8 ~]$

Specify SSH key size for ssh-keygen

Most likely you’ll have your preferences for SSH keys and it is much easier to just specify them when running the ssh-keygen command.

This is how one can generate 4096-bit key, for example:

[greys@rhel8 ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/greys/.ssh/id_rsa): /home/greys/.ssh/rsa-4k
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/greys/.ssh/rsa-4k.
Your public key has been saved in /home/greys/.ssh/rsa-4k.pub.
The key fingerprint is:
SHA256:4rf1AGIc99L57/xC1PWu7pJpwhkn5YCmZQqua/XdmGA greys@rhel8
The key's randomart image is:
+---[RSA 4096]----+
| |
| .|
| . .. .o|
| .. o=o... . o|
| . .=*S ++ . . |
| ooEo oo.o . .|
| o o.o.=o=.+ . |
| o ..+o=o=oo |
| ... . o.=*o.|
+----[SHA256]-----+

See Also

• SSH
• SSH port
• SSH command
• SSH port forwarding
• Change SSH key passphrase

Good news, everyone!

Starting yesterday, GitHub allows free accounts to have unlimited number of private repositories. The number of collaborators for such repos is limited to 3, but this is still a massive improvement and something I’ve personally been faiting for. There’s just too many little things in a sysadmin’s life that could benefit from git tracking but won’t justify a premium price tag.

Updated GitHub pricing

This is how pricing looks now:

How To Create a Private Repository in GitHub

Assuming you already have a GitHub account and you’re logged in, creating new repository is fairly straightforward:

Previously, selecting the Private type of repo would show a pop-up asking for paid upgrade of your account, but as you can see on the screenshot above, this is not the case anymore!

Once you click the Create Repository button, you should see your brand new repo:

Adding your SSH key to GitHub repository

If you haven’t done this yet, now would be the time to access Settings in your profile (open URL https://github.com/settings/profile in another browser tab) and go to the SSH and GPG keys section there.

This will let you upload your existing SSH key that you later can use for accessing your GitHub repositories:

As seen on the screenshot, you provide some title to the SSH key and then copy-paste the whole key (I’m not including it in the screenshot fully).

The good sign that your key is added should be something that shows it like this:

Connecting to your GitHub repo using SSH

Going back to your GitHub repository, in the top right section you should see a green button called Clone or download. If you click it, you’ll see a window with URL to your private repo. Don’t forget to click the Use SSH there and you should see something like this:

Copy this onto your Linux/Unix desktop and run this in the command line:

greys@maverick:~/proj/unixtutorial/github $ git clone [email protected]:greys/unixtutorial.git
Cloning into ‘unixtutorial’…
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

You should see a new subdirectory created in your location:
greys@maverick:~/proj/unixtutorial/github $ ls
unixtutorial

and if you change into that directory, it would contain your private GitHub repository copy – which at this early stage only has the README.md

file:greys@maverick:~/proj/unixtutorial/github $ cd unixtutorial/
greys@maverick:~/proj/unixtutorial/github/unixtutorial $ ls
README.md

That’s it! Hope you like the good news about free private GitHub repositories and stay tuned for more news and Unix/Linux How-To’s!

See Also

• ssh command
• Change passphrase to your private SSH key

I’m installing VirtualBox on one of my remote Linux servers and installed the software from their repository that deploys all the additional packages required by VirtualBox.

Still, when I first started the graphical interface (VirtualBox Manager), most of text appeared as funny characters that can’t really be read:

This is a common problem when you’re trying to run a graphical (X11) application on a server without graphics system like Xorg. As you probably guess, the problem is to do with fonts.

Specifically, it’s a problem of your remote Linux server not having any fonts installed, because Xorg (graphics system) was never installed on it (servers usually have server-specific version of distro or at least a package selection that disables desktop related things).

Once we install standard fonts package like this:

greys@s5:~ $ sudo yum install xorg-x11-fonts-Type1
...
Installed:
 xorg-x11-fonts-Type1.noarch 0:7.5-9.el7

Dependency Installed:
 libXfont.x86_64 0:1.5.2-1.el7 libfontenc.x86_64 0:1.1.3-3.el7 ttmkfdir.x86_64 0:3.0.9-42.el7 xorg-x11-font-utils.x86_64 1:7.5-20.el7
...

… restarting application will result in a normal window with quite readable fonts:

See Also

• X11 forwarding in MacOS
• VirtualBox
• KVM virtualization
• Hardware Virtualization
• MacOS

Quite recently I came across a very interesting issue: while configuring passwordless SSH (it’s public key based, so depending on you have it configured it may not be completely passwordless) access to some of my VPS servers, I found that the same keypair just wouldn’t work on one of the servers.

Not only that, but the behaviour was quite bizzare: upon my first attempt to connect the public key would get rejected and a regular password would be requested by the ssh session. But once I successfully logged in with my password, any subsequent ssh connections would happily authenticate by my public key and would let me in without a problem.

Those of you using home dir encrypiton in Ubuntu are probably smiling right now! 🙂 But becase I have never consciously configured or used this feature, it took me a good few hours to troubleshoot the issue and come up with the fix.

Why public-key based SSH doesn’t work with encrypted home directories

The answer is quite simple: before your server can decide whether you are providing a valid and trusted SSH key, it must read your public key stored in your homedir. But if your homedir is encrypted, this becomes a classical chicken-and-egg scenario – until you log in and therefore decrypt your homedir the server won’t gain access to your public key. Only you wouldn’t be needing the public key by then, would you?

Store your authorized SSH keys outside your encrypted home directory

If you happen to like your homedir encryption AND would like to use public/private key SSH authentication,  there is a way out: you need to store your authorized keys outside of your encrypted homedir.

The usual access restrictions and directory/file permissions still apply, so the only thing you’re changing is moving your authorized keys outside of the encrypted homedir on your server. This way things will work exactly as you expect: you authenticate with your private key and this results in your automatically mounted and decrypted homedir.

Here are the steps to make this happen. You’re going to need superuser privileges for my scenario because it caters for all the users on your Ubuntu server, not just one account that belongs to you (use sudo to become root).

Step 1: create a directory structure for your authorized keys.

First, the main directory, I created it under /var – seems quite a safe choice since this directory is unlikely to grow and is equally unlikely to get removed by accident.

# mkdir /var/openssh

Perfect! Now we need to create user-specific directories, just to keep this dir really tidy. My username is “greys“, so here is the directory:

# mkdir /var/openssh/greys
# chown greys /var/openssh/greys

Step 2: copy existing authorized keys file into new location

(you must log in as your username for this, otherwise the homedir will stay encrypted)

$ cp /home/greys/.ssh/authorized_keys /var/openssh/greys

Step 3: update SSHd config with new location for authorized_keys file

You’re going to do this as root once again:

# vi /etc/ssh/sshd_config

update the value of the AuthorizedKeysFile so that it looks like this:

AuthorizedKeysFile        /var/openssh/%u/authorized_keys

Step 4: Restart SSH service

# service ssh restart
ssh start/running, process 3708

That’s it! Give it a try and let me know how it worked out.

Recommended books:

[AMAZONPRODUCTS asin=”1590594762″]

See also

• ssh – secure shell
• How To Enable Secure Shell service in Ubuntu
• Passwordless SSH
• Changing passphrase to your SSH key

SSH (Secure SHell) is possibly the best way to remotely access a Unix system – it’s very secure thanks to automatic encryption of all the traffic, and it’s also quite universal because you can do all sorts of things: access remote command line shell, forward graphics session output, establish network tunnels, set up port redirections and even transfer files over the encrypted session.

Today I’m going to show you how to get started with SSH in Ubuntu.

Installing SSH server in Ubuntu

By default, your (desktop) system will have no SSH service enabled, which means you won’t be able to connect to it remotely using SSH protocol (TCP port 22). This makes installing SSH server one of the first post-install steps on your brand new Ubuntu.

The most common SSH implementation is OpenSSH. Although there are alternative implementations (closed source solutions and binary distributions maintained by various Unix and Unix-like OS vendors), OpenSSH is a de-facto standard in the secure transfers and connections industry. That’s exactly what you want to install.

Log in with your standard username and password, and run the following command to install openssh-server.

You should be using the same username that you specified when installing Ubuntu, as it will be the only account with sudo privileges to run commands as root:

ubuntu$ sudo apt-get install openssh-server
[sudo] password for greys:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  rssh molly-guard openssh-blacklist openssh-blacklist-extra
The following NEW packages will be installed:
  openssh-server0 upgraded, 1 newly installed, 0 to remove and 75 not upgraded.
Need to get 285kB of archives.
After this operation, 782kB of additional disk space will be used.
Get:1 http://ie.archive.ubuntu.com jaunty/main openssh-server 1:5.1p1-5ubuntu1 [285kB]
Fetched 285kB in 0s (345kB/s)
Preconfiguring packages ...
Selecting previously deselected package openssh-server.
(Reading database ... 101998 files and directories currently installed.)
Unpacking openssh-server (from .../openssh-server_1%3a5.1p1-5ubuntu1_i386.deb) ...
Processing triggers for ufw ...
Processing triggers for man-db ...
Setting up openssh-server (1:5.1p1-5ubuntu1) ...
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ... 
* Restarting OpenBSD Secure Shell server sshd                           [ OK ]

Public and Private keys in SSH

As you can see in the sample output above, the installation procedure created 2 sets of keys – SSH2 RSA keypair and SSH2 DSA keypair. The reason for this is that OpenSSH relies heavily on the public and private key (PPK) infrastructure.

The concept behind PPK is pretty cool: SSH allows you to create keypairs. They are generated to the maximum randomness achievable on your system. Keypairs can be created for your server or for your individual uses.

The idea is that public keys are shared with other servers, and they later can be used as a unique identificator to confirm your true identity. When you’re connecting to another server, it uses your public key to encrypt a short message and the secure session will only be established if on your side you have a private key that allows decrypting the message. No other system or user can decrypt the message because only you would have the private key. That’s why it’s called private – don’t ever share it with anyone.

As an additional security measure, when you’re generating personal keypairs you’ll be asked to supply a passphrase so that even if someone steals your private password they won’t be able to use it without knowing your passphrase.

Verifying your SSH server works

While you’re still on your local desktop session, you can use the ps command to confirm that SSH daemon (sshd) is running:

ubuntu$ ps -aef | grep sshd
root     24114     1  0 15:18 ?        00:00:00 /usr/sbin/sshd

Now that you see it’s there, it’s time to try connecting:

ubuntu$ ssh localhost

Since this is the first time you’re trying to connect using SSH, you’ll have to answer yes to the following question:

The authenticity of host 'localhost (::1)' can't be established.RSA key fingerprint is 18:4d:96:b3:0d:25:00:c8:a1:a3:84:5c:9f:1c:0d:a5.Are you sure you want to continue connecting (yes/no)? yes

… you’ll then be prompted for your own password (remember, the system treats such connection request as if you were connecting remotely, so it can’t trust you without confirming your password):

Warning: Permanently added 'localhost' (RSA) to the list of known hosts.greys@localhost's password:

.. and finally you’ll see the usual Ubuntu (Jaunty in this example) banner and prompt:

Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686

The programs included with the Ubuntu system are free software;the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.

To access official Ubuntu documentation, please visit:http://help.ubuntu.com

Last login: Fri May 15 15:18:34 2009 from ubuntu

ubuntu$

That’s it, providing you have your networking configured and you know your IP address or hostname, you can start connecting to your Ubuntu box from remote systems, using the same command. Enjoy!

Recommended books:

See also:

• • Passwordless SSH

• Unix commands
• Using apt-get behind proxy
• List installed packages in Ubuntu