All right. Thank you. Also sorry for this switch up. I had a demo prepared that I wanted
to show really life. There is an emergency solution, so I will show the slides. Anyways,
let's get started. Thank you for your interest in a simple thing, like SSH logins. I did
not expect this, but yeah, let's get started. So just a brief few words for the motivation
where I'm coming from and why I'm doing this. We are providing and working at the research
campus, imagine a university like environment, we provide compute infrastructure and
computer resources to researchers and scientists. This is a rather large number of users.
They basically log in to a batch compute system as far as we are concerned for this talk. It's a
bunch of Linux servers and they need to authenticate them securely. So how can we do this?
Probably you've followed many talks of this track. Two obvious things are certificates and tokens
because of certain properties they have like for example a limited validity period which
are way better than other things like a password for example or also as many of you probably
know public keys with SSH. Just a brief question to see who I'm talking to. Can you raise
your hand if you're using SSH certificates for logging in? Okay, that's quite quite a few. And
are you also as a sus admin deploying SSH service with this kind of setup? Okay, still. Okay,
all right. So then maybe a few new aspects I hope are still there for you as well but let's get started.
So I can basically skip this. This would have been my demo lab unfortunately a bunch of containers.
We could see interactively all the things. Now please close your eyes for a brief moment for the
conclusion. Okay, thank you. And slides of last resort. So this is where we are. I wanted
to get it going with logging in by a password. Everybody knows this really. The demo was set up to
have a cheat sheet for myself so I could copy the commands and then underneath you see what was
happening. But basically, USAH to the machine, right, then you get initially the question to
you trust this host, whatever that means. But it shows you the fingerprint of the host so you can
cryptograph correctly more as identified a host. And typically you would write this to a known
host file so that the next time you connect you recognize the host and also you'll know if
something is wrong, these key changes and you'll know you're not connecting to the same machine.
All right, so this is what I did here. And then I was demonstrating the known host file that
lists those keys. That's pretty easy. So I skip over this. The pub key probably many of you also
know or use. I think this is, I guess, one of the most used authentication methods. So basically,
if you connect with a public key, there is no password prompt. So again, we see the fingerprint
and we say yes, we trust the host. But then there's no prompt for a password. We'll love it indirectly
and that's fine. How does this work? Well, you generate your public private key pair on your client.
You copy the public key to the server. Then basically, your private key is allowed to authenticate
to the server. One thing that you can do in the SSH server configuration, you can see in the middle
here. So basically, I've disabled the password authentication because of case, I say I have
stronger authentication methods. Typically, here you would have this line, the public key is also
the authorized key file in the user's home. But you can also disable this and then use an authorized
key command. This is more or less any command that you can run. You can provide it several arguments.
And here you can hear what I'm doing. I'm using Carn IDM as an identity provider
to fetch the key from my users. So in the example, you can see also I fetch the public key for the
public key user. I get a result that's literally the same string that is in the public key file
the user has in the home. And if I try it for another user, I don't get any keys so they can't
connect or it's different key and they need to have the matching private key. The nice thing about
the solution like this is of course, you can have the central life oftentimes this is done also
with SSH. You can look it up in LDAP for example. You can use attributes in LDAP or Active Directory,
to store those keys. The nice thing is you don't have to distribute them. You can deny the
users to bring in their own keys and then not being able to manage this. And if you know something
happened with this user, you can disable it or remove the key from the central location and
in all places the access is disabled. So far I think these are the most common use cases
or the most common methods for authentication and the next step is certificate.
So for certificates, I mean I guess many of you have already thought like yeah it would be nicer
and better to set up the service certificates. For example, because they have a limited lifetime,
you can do other things with certificates as well and generally you can use them in a way that it's
less of a problem than losing the private key file on the client home directory.
This might become a sum with the SSH, open SSH tools, SSH keychain of course you can do it,
but the actual problem that you have as an administrator is distributing the certificates right
how do you get them to the user. There are some tools, step SSH, one component which is a
certificate authority with an API really and you can configure it so that you can authenticate
to that CA through for example, open ID Connect. And this is very convenient because
when you do this, first of all, okay you have to run some tool. So some tool which is not the
SSH client, but basically it will do most of the work for you, it will either show you the URL
or open the browser directly if you're running it locally, get back to the process that is running here
and then you have a token which you can use to get a certificate from the CA.
And again with that certificate, you can just log in without using a password that was the
initial intent. Also note here, we are not seeing any question for authenticating the host or
for trusting the host. So something apparently has been done here, maybe we have connected to it before
or something else. All right, in the example here, you can also see the certificate is directly added
to the agent, so there's not even a file written on the host. I did a last here on the on the
top SSH directory, but yeah, it's added to the agent. But now I wanted to have a look what's actually
in this certificate for this reason I do the same thing again, just not adding it to the agent,
but writing it to a file. And then I can use SSH key gen to look at the certificate and see what's
actually the content of that. And while the public privately is more or less just in opaque string,
here we have some actual information. We have a certificate authority, so there is a central,
like this is how certificates work, right? You'll trust the CA that the certificates the CA produces
are good. The other important thing is the validity period, so in this example it's not exactly
24 hours, but this is something you can you can change for shorter or longer. For SSH, it would be
fine depending on your certificate use case, but if you just need to log in once, it can be five
minutes, right? You just need to get a third log in and then you don't need it anymore.
The other interesting things are that you have the principles added to the certificate,
which means the users basically on the server side that this certificate can authenticate as.
So in this example, the third user, the local user as well, but it could also be rude or some
other user for example, and there are other extensions that allow you to switch certain SSH features
on or like agent forwarding or port forwarding that might be interesting.
All right, yes. On the server side, this is quite easy because I just verify against the user CA,
so I have the public key of the user CA and then I can verify all the certificates without any further
specific information. That's rather easy to deploy because it's just one file really and that's it.
Some were there, I forgot why I was not asked for the host keys because for the server,
I can also have a certificate and then I can do the same vice versa. On the client, I have a
known host line that really trusts the CA for even a wild card of service, so I have one line to trust
a bunch of machines, my whole infrastructure, it needs to be. And open pub key SSH, that's basically
also using certificates. Again, you have a tool that you will have to call to generate the certificate.
In this case, you don't need an external CA, you just talk to your ID provider, get a token,
and then generate a certificate locally. When we connect to the server, it really works the same
as with certificates you're logging without a password, but the interesting thing is
one thing first, the validation of the certificate here happens the same as with public
key authentication, so I will get into y in a moment, but basically we are checking some
meta information on the certificate and not the actual certificate because we also are not talking
to trust the CA, so we are just using the certificate as a transport medium. And you can see here
why, obcasses H, I think this 0.12 was released last week, where the editors inspect command,
which is really nice, because I will skip over that, but you can of course manually also dissect
the certificate with SSH teacher and check you and so on, decode the JSON, the JSON, which is
somewhere in the extensions here. So it's a certificate you see, but there are no principles,
there's no validity period, there's no CA, there's nothing really, except this open pub key extension.
And this extension is actually the ID token that you got from the ID provider.
And this token is what's being verified on the server side, so nobody cares about the
certificate, we just look at the token and then check what's in the token to make sure if you
to see if you can lock in or not. I will not find this in the screenshots here,
on the server side, you have basically you do the validation using this authorized keys command,
and then config wise, you can configure several ID providers on the server side,
and you can have also a mapping file where you can map, let's say, identities from a given ID provider
to local user names. The nice thing is that you can mix and match this and there are also additional
plugins that allow you to look at other attributes of the token as well, like, for example,
the groups that are in the token or other claims. All right, that would have been a nice demo,
I guess, but maybe next time, I was really worried about the containers not coming together and
so on and then it's something which I thought was solved, but okay. All right, I have a quick conclusion
overview kind of, so I was saying I was looking at this for our use case of many users on many
machines, and this open pub key, it's really, really cool that basically you can process the whole
chase and on the server, and you can come up with hundreds of ideas. I think it's really cool
if you need to set something up where there is no central infrastructure, where maybe you need to
improvise some solution and provide access to different users. It's easy to create an app in Google
or GitHub or whatever and then authenticate against that and then map your users onto the system.
What I didn't show in detail was what's missing here and what the certificates provide is also
the host validation, and that's actually something that is really nice. So I will decide for the
certificates. I had to get over myself also to accept that you need a third party tool in practice
really to make this happen for end users so that it comes usable. Yeah, that's really it for me.
I will go with the certificates, but if you're interested, I can only recommend to check out the
open pub key. That's it. Thank you. Maybe there is still time for questions.
Okay, please. I was wondering, giving you an experience, how do you deal with the same reports
certificates, where obviously when there's a long-distance session, the next invocation, the next attempt,
you see how wrong will be evaluated, right? So is there some solution around that to
let's say keep the user out because you've just, you know, you've managed this. So kicking out no,
sorry, yes, I repeat the question. What about the question is, how to handle
a certificate revocations or if the credentials can compromise with ongoing sessions?
I have no solution for ongoing sessions. I would really rely, in this case mostly, on the short
lifetime of a certificate and then for the next run. Sorry? Is there a way to do host verification
with open pub key, not that I know of? Because it's not using the certificate as a certificate,
right? It's just a transport medium, really. What I have prepared in the demo was actually
SSHFP, that's DNS records that hold the fingerprints, but for that to really work, you need the
NSF and that's not really available in most places. Back, please. I use step CA.
If I set up my own CA, hell no. I use step, I mean, in kind of, because with this tool step CA,
it's really easy. Basically, it bootstrap the CA and then you have so-called provisionals,
which are ways to to generate certificates and to authenticate to the CA. So there's a token
based one that you could use, for example, during host deployment. There is one that uses
the almighty connect, which I'm using in this example, there are different ways,
based on that. That is a really hard question that I don't have an answer to.
I'm really done for time for more questions. Okay.
Maybe then outside. Thank you.