hpr-knowledge-base/hpr_transcripts/hpr1920.txt

Episode: 1920
Title: HPR1920: 21 - SSH Authentication - Keys
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1920/hpr1920.mp3
Transcribed: 2025-10-18 11:09:31

---

This is HBR Episode 1920 entitled 21 SSH Authentication, Keyes, and in part of the series Privacy and Security.
It is hosted by AYUKA and in about 19 minutes long.
The summary is, we introduce the idea of using public sash private key pairs for authentication.
This episode of HBR is brought to you by an honesthost.com.
Get 15% discount on all shared hosting with the offer code HBR15.
That's HBR15.
Better web hosting that's honest and fair at an honesthost.com.
Hello, this is AYUKA, welcoming you to Hacker Public Radio and another exciting episode
in our ongoing series and security and privacy and our little mini series here on SSH.
And what I want to do today is continue our discussion by taking a look at authentication
and in particular the use of keys because I think there's a lot to say there.
How much can I say about passwords really?
When you first try to log in to a remote server, you need to authenticate yourself.
And that means you have to demonstrate that you have rights to be on that server.
Now you can do this in several ways, the first one, password.
You authenticate to the server by typing in your password.
That's generally easy because you can remember your password or you have access to it in a password
vault like key pass or last pass.
And it means you can easily log in from any computer if you have that password knowledge.
That's still the most common authentication mechanism for SSH.
It is, however, also the least secure.
Second thing is public key. This is much more secure. It involves the creation of a key pair,
of course. It's possible to use a key pair generated by PGP or GPG in the most current versions
that they have support for it. But there's a long established method using the UNIX program SSH key
gen. And that command is SSH-DAS-KY-GEN. This is very similar to generating key pair as we
discussed earlier. You run the program, if necessary, you harvest some entropy, generate a pass
phrase to protect it and so on. There are a few other ways. One is called Kerberos and that's done
through the General Security Services API. This is a programming interface that is broader than
just Kerberos. It is supposed to encompass several possibilities. And of course, as an API,
it abstracts from the details. But the GSS API library included supports only Kerberos.
So it is not yet as general as it might become. And then finally, there's something called
Keyboard Interactive. And that the server sends one or more prompts to the client to enter certain
information. This is not compatible with all client software, however, but it could work in a terminal.
Kerberos and Keyboard Interactive, I'm not going to get into. They're really specialized
applications and I'm just mentioning them as for the sake of completeness as much as anything.
So the most common methods are either entering a password or using a public key. And like so many
things in security, there is a trade-off between security and ease of use. Passwords are the simplest
and easiest way to authenticate and everyone knows how to use one. But it is also true that
passwords can be compromised in a variety of ways. People may use a single password for everything
or they might use a password that is easily guessed, or it might be written on a sticky note hidden
under the keyboard, or it might be given to someone else to use, particularly in a corporate
environment, where many people may need to access the same resources. Since the whole idea of
using SSH is to increase the security, I don't like relying on passwords if there is an alternative.
And increasingly, public key is that alternative. Now the starting point for public key
authentication is to generate the key pair. As we saw previously in our tutorial on symmetric versus
asymmetric encryption, there are several possible algorithms that can be used, with RSA still the
most common. And the way this works is that you generate two keys such that key one will decrypt
anything that key two encrypted, and key two will decrypt anything that key one encrypted.
Arbitrarily one of these is designated as the public key and the other as the private key.
Now your algorithm is most commonly RSA, but there is also DSA, which is digital signature algorithm,
and EC DSA, which is a elliptical curve digital signature algorithm.
Now digital signature algorithm uses discrete logarithm mathematics elliptical curve uses elliptical
curve mathematics RSA uses large prime numbers. All of these are examples of what's called
a one-way algorithm, which means it uses a computation that is easy to do, but extremely difficult
to do in reverse. Right now it looks like RSA is more widely used. DSA might be slightly stronger,
but I've seen some indication that some clients don't support a large enough key length.
Liptical curve is fairly new, it's highly efficient, and I think that it may well be the way we go
forward in the future, but right now I would say stick to RSA unless you have a strong reason not to.
Your next decision is the key length, and here the default generally you're going to see is 2048,
and most of the clients I've looked at the SSH key gen programs default to that.
Now you might say what is 1024 too small? Well it's a little larger than the current record for
brute force cranking, but it's not that much larger, and so it's lifetime is pretty limited.
You know how long a lifetime does 2048 have? Do you want to stop there?
I've discovered that it really does not take a whole lot of time to create one using 3072.
Which is the next jump up. So that's been now what I use as the standard on all of mine.
Now if you want any more information on the SSH-key gen command they do have a man page,
but this will basically when you run it it'll create two files which will reside in the same
directory as your known hosts file, and that is slash home slash your username, whatever that is,
slash dot SSH, and then in that directory will be these files. Now my kabuntu it's just id underscore
rsa and just the letters id. I've seen other things that will actually put in your id name,
and you can rename it however you wish, and that's something we will talk about.
But the first one is id underscore rsa, and that's arbitrarily is your private key,
and the other is id underscore rsa dot pub, and that's your public key.
So if your system defaults to 2048 you need to use a command line switch to change it,
which is the dash b switch. Now if you consult the man page for SSH-key gen,
or I've got a link in the show notes to an online version, you can see how what the switches are,
and how to use them. I use a couple here, so let me mention that there are two key switches
that you might want to use. One of them is the dash t switch, which specifies which encryption
algorithm you're going to use. As I said, I stick with rsa. For most things that's the default,
but you can specify that. And then the dash b switch, which is the bit length,
and I usually use 3072, which is more than the default, at least on my system.
So how are we going to do this? Well here's an example of a command,
SSH-key gen, space, dash t, space, rsa, space, dash b, space, 3072.
So if you do that, you will get a key, a key pair that uses the rsa encryption algorithm,
and is 3072 bits long.
Then what will happen is you run that command, and the computer will start talking back to you,
say generating public slash private rsa key pair, then enter file in which to save the key.
Now at this point, there is a default. If you just hit the enter, it'll do that. The default is
slash home slash Kevin slash dot SSH. Now it wouldn't be Kevin for you, be whatever your login name is.
I'm looking at mine. And then the file is ID underscore rsa. I can type in anything here. I'm
going to leave it in that directory. It's going to be the same dot SSH directory. I mean,
you're just creating problems for yourself if you move it unless you've got a really good reason.
But what I can do is I can give it a different name. And there are reasons why you might want to
do that. And we will be talking about that. But that's probably going to come a little bit later.
Then enter a passphrase. And then it says in parentheses, empty for no passphrase.
This is the same issue that we have talked about with these key pairs. You might remember when we
took a look at using pgp with email if you want to encrypt or sign email, anything like that.
You've got a passphrase that you have to use that tells the computer that yeah,
you should use this and I am authorized to do it. If you leave it empty, then you've removed
a little bit of protection. So what happens is I would say don't leave it empty. Give it a good
passphrase. That is your protection here. When you type it, you won't see anything on the screen.
That's for security purposes. But then it'll say enter the same thing again. And
if they both match, fine, it'll move on. If they don't both match, you'll get an error message
saying well, they didn't match. Try again. Assuming you were successful, it'll say your identification
has been saved in. And again, this is mine. Slash home slash Kevin slash dot ssh slash id underscore rsa.
That's my private key. And your public key has been saved in slash home slash Kevin slash
dot ssh slash id underscore rsa dot pub. That's my public key. And then it will give me my key
fingerprint, which is a bunch of hexadecimal pairs. And then it will give something called a
random art image. The random art, I think there's probably a little bit of security in that
some people say they know what their random art image looks like. And so if they didn't see it,
they would be suspicious or something. I don't. To me, the random art image doesn't really do
anything. The passphrase is important. Now, one of the things you need to understand,
there's no way to recover a passphrase just as there's no way to recover your passphrase for
PGP on a email client. You know, if you lose it, you will never be able to use this again.
So make sure you remember it or you know how to store it safely. Now, I've done all of this on
Linux. I will just mention for people who want to do that. If you're a Windows user, there's
something we talked about putty as a client for SSH. There is also a program called puttygen.exe,
which works with it, which as you might guess is a key generating. And I will put a link for
some instructions on that into the show notes. And the differences your files will be in C colon
backslash users, backslash, whatever your login name, backslash.ssh, backslash, your ID name,
underscore rsa or underscore rsa.pub for the public key. So what is your key? Public key look like.
It starts with ssh-rsa and then a whole bunch of what is essentially base 64 garbage.
And then at the end, your login name and the system that you created it on.
So ssh-rsa identifies what kind of key. Now, how does this get used this public key?
Well, your public key is something that can be used to identify you. And the server can use that
to create a good connection. Now, if remember that your public key can decrypt anything your private key
creates and your private key can decrypt anything your public key creates. So what you will do eventually
is you will put this public key on the server. And that's something we're going to look at. We're
going to start looking at very quickly here. Take a look at the methods for doing that.
But you will add your public key to a file on the server called authorized underscore keys.
And when you log into that server, you will have your public key and the server will take a look
at that and say, well, all right, you gave me your public key earlier. Do they match? That's a good
thing. Then what you can do, remember that to create the connection what we want to do is we want
to ultimately switch over to a symmetric key. Now, symmetric keys are a lot more efficient computationally
than key pairs. But the big problem is that symmetric keys, how do you exchange the keys
securely? You know, both sides have to be using the same symmetric key. And it's that
exchange of keys that is the big weakness. And that's why Diffie-Hellman key exchange and all
of that was invented. It was a way of getting around the security hole and saying, okay, we have a
way of establishing a secure connection. We went into this in a lot more depth in our tutorial on
symmetric versus asymmetric encryption. But what's going to happen here is that you as a client will
come up with a symmetric key, you will encrypt it with your private key and then send it to the
server and then the server will decrypt it with your public key and then you've got a connection
established. Now, some things to keep in mind. Just as with your PGP key for email,
if you lose your key, you're in trouble. Backing up is important. If you don't back up your keys,
you may find one day you no longer have access to those remote systems. You might be able to get
new access by deleting the old keys and getting new ones added, but if you log into a lot of sites,
that will be a royal pain. Also, what happens if a computer that has your keys on it is decommissioned,
sold or compromised in some way? How secure is your access now? One recommendation is that you don't
use the same keys on different machines to help guard against this. It might seem like additional
work to create key pairs on each machine separately, but if the point is security, it just might be a good idea.
Note that when you create the SSH key pair, you are asked for a file name to save it to.
By default, my kabuntu system simply call it ID. Other systems may put in your username,
but you could create a key with the name of the remote site and do that for each site you wish to
access. And so, this is Huka for Hacker Public Radio signing off and reminding you as always to
support FreeSoftware. Bye-bye!
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how easy it really is.
Hacker Public Radio was founded by the Digital Dove Pound and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com. If you have comments on today's show,
please email the host directly, leave a comment on the website or record a follow-up episode yourself,
unless otherwise status. Today's show is released under Creative Commons,
Attribution, ShareLight, 3.0 license.