WEBVTT 00:00.000 --> 00:18.960 All right. Thank you. Also sorry for this switch up. I had a demo prepared that I wanted 00:18.960 --> 00:29.280 to show really life. There is an emergency solution, so I will show the slides. Anyways, 00:29.280 --> 00:35.280 let's get started. Thank you for your interest in a simple thing, like SSH logins. I did 00:35.280 --> 00:42.560 not expect this, but yeah, let's get started. So just a brief few words for the motivation 00:42.560 --> 00:48.320 where I'm coming from and why I'm doing this. We are providing and working at the research 00:48.320 --> 00:54.240 campus, imagine a university like environment, we provide compute infrastructure and 00:54.240 --> 01:00.080 computer resources to researchers and scientists. This is a rather large number of users. 01:01.280 --> 01:06.800 They basically log in to a batch compute system as far as we are concerned for this talk. It's a 01:06.800 --> 01:14.640 bunch of Linux servers and they need to authenticate them securely. So how can we do this? 01:14.640 --> 01:21.280 Probably you've followed many talks of this track. Two obvious things are certificates and tokens 01:21.360 --> 01:26.240 because of certain properties they have like for example a limited validity period which 01:26.240 --> 01:32.480 are way better than other things like a password for example or also as many of you probably 01:32.480 --> 01:42.000 know public keys with SSH. Just a brief question to see who I'm talking to. Can you raise 01:42.000 --> 01:49.840 your hand if you're using SSH certificates for logging in? Okay, that's quite quite a few. And 01:49.840 --> 01:59.200 are you also as a sus admin deploying SSH service with this kind of setup? Okay, still. Okay, 01:59.200 --> 02:06.000 all right. So then maybe a few new aspects I hope are still there for you as well but let's get started. 02:06.000 --> 02:10.720 So I can basically skip this. This would have been my demo lab unfortunately a bunch of containers. 02:12.640 --> 02:18.000 We could see interactively all the things. Now please close your eyes for a brief moment for the 02:18.000 --> 02:26.000 conclusion. Okay, thank you. And slides of last resort. So this is where we are. I wanted 02:26.000 --> 02:33.040 to get it going with logging in by a password. Everybody knows this really. The demo was set up to 02:33.040 --> 02:39.520 have a cheat sheet for myself so I could copy the commands and then underneath you see what was 02:39.520 --> 02:44.560 happening. But basically, USAH to the machine, right, then you get initially the question to 02:44.640 --> 02:49.600 you trust this host, whatever that means. But it shows you the fingerprint of the host so you can 02:49.600 --> 02:56.080 cryptograph correctly more as identified a host. And typically you would write this to a known 02:56.080 --> 03:01.360 host file so that the next time you connect you recognize the host and also you'll know if 03:01.360 --> 03:06.960 something is wrong, these key changes and you'll know you're not connecting to the same machine. 03:07.040 --> 03:16.480 All right, so this is what I did here. And then I was demonstrating the known host file that 03:16.480 --> 03:25.040 lists those keys. That's pretty easy. So I skip over this. The pub key probably many of you also 03:25.040 --> 03:35.200 know or use. I think this is, I guess, one of the most used authentication methods. So basically, 03:35.360 --> 03:42.640 if you connect with a public key, there is no password prompt. So again, we see the fingerprint 03:42.640 --> 03:48.640 and we say yes, we trust the host. But then there's no prompt for a password. We'll love it indirectly 03:48.640 --> 03:54.640 and that's fine. How does this work? Well, you generate your public private key pair on your client. 03:54.640 --> 04:00.640 You copy the public key to the server. Then basically, your private key is allowed to authenticate 04:00.640 --> 04:10.320 to the server. One thing that you can do in the SSH server configuration, you can see in the middle 04:10.320 --> 04:16.160 here. So basically, I've disabled the password authentication because of case, I say I have 04:16.160 --> 04:22.080 stronger authentication methods. Typically, here you would have this line, the public key is also 04:22.080 --> 04:28.720 the authorized key file in the user's home. But you can also disable this and then use an authorized 04:28.800 --> 04:35.440 key command. This is more or less any command that you can run. You can provide it several arguments. 04:36.160 --> 04:41.840 And here you can hear what I'm doing. I'm using Carn IDM as an identity provider 04:44.080 --> 04:50.880 to fetch the key from my users. So in the example, you can see also I fetch the public key for the 04:50.880 --> 04:58.720 public key user. I get a result that's literally the same string that is in the public key file 04:58.720 --> 05:04.880 the user has in the home. And if I try it for another user, I don't get any keys so they can't 05:04.880 --> 05:09.360 connect or it's different key and they need to have the matching private key. The nice thing about 05:09.360 --> 05:14.240 the solution like this is of course, you can have the central life oftentimes this is done also 05:14.240 --> 05:20.800 with SSH. You can look it up in LDAP for example. You can use attributes in LDAP or Active Directory, 05:21.200 --> 05:26.160 to store those keys. The nice thing is you don't have to distribute them. You can deny the 05:26.160 --> 05:31.360 users to bring in their own keys and then not being able to manage this. And if you know something 05:31.360 --> 05:36.800 happened with this user, you can disable it or remove the key from the central location and 05:36.800 --> 05:45.520 in all places the access is disabled. So far I think these are the most common use cases 05:46.240 --> 05:51.840 or the most common methods for authentication and the next step is certificate. 05:53.440 --> 05:59.920 So for certificates, I mean I guess many of you have already thought like yeah it would be nicer 05:59.920 --> 06:05.840 and better to set up the service certificates. For example, because they have a limited lifetime, 06:05.840 --> 06:13.200 you can do other things with certificates as well and generally you can use them in a way that it's 06:13.280 --> 06:18.560 less of a problem than losing the private key file on the client home directory. 06:20.400 --> 06:27.520 This might become a sum with the SSH, open SSH tools, SSH keychain of course you can do it, 06:27.520 --> 06:31.520 but the actual problem that you have as an administrator is distributing the certificates right 06:31.520 --> 06:39.680 how do you get them to the user. There are some tools, step SSH, one component which is a 06:39.760 --> 06:46.400 certificate authority with an API really and you can configure it so that you can authenticate 06:46.400 --> 06:52.880 to that CA through for example, open ID Connect. And this is very convenient because 06:54.880 --> 07:02.720 when you do this, first of all, okay you have to run some tool. So some tool which is not the 07:02.720 --> 07:10.160 SSH client, but basically it will do most of the work for you, it will either show you the URL 07:10.160 --> 07:16.160 or open the browser directly if you're running it locally, get back to the process that is running here 07:17.760 --> 07:24.080 and then you have a token which you can use to get a certificate from the CA. 07:26.320 --> 07:32.240 And again with that certificate, you can just log in without using a password that was the 07:32.400 --> 07:39.600 initial intent. Also note here, we are not seeing any question for authenticating the host or 07:39.600 --> 07:45.520 for trusting the host. So something apparently has been done here, maybe we have connected to it before 07:45.520 --> 07:53.920 or something else. All right, in the example here, you can also see the certificate is directly added 07:53.920 --> 08:01.200 to the agent, so there's not even a file written on the host. I did a last here on the on the 08:01.280 --> 08:09.920 top SSH directory, but yeah, it's added to the agent. But now I wanted to have a look what's actually 08:09.920 --> 08:14.560 in this certificate for this reason I do the same thing again, just not adding it to the agent, 08:14.560 --> 08:22.560 but writing it to a file. And then I can use SSH key gen to look at the certificate and see what's 08:22.560 --> 08:29.680 actually the content of that. And while the public privately is more or less just in opaque string, 08:29.760 --> 08:35.440 here we have some actual information. We have a certificate authority, so there is a central, 08:35.440 --> 08:41.520 like this is how certificates work, right? You'll trust the CA that the certificates the CA produces 08:41.520 --> 08:49.760 are good. The other important thing is the validity period, so in this example it's not exactly 08:49.760 --> 08:58.160 24 hours, but this is something you can you can change for shorter or longer. For SSH, it would be 08:58.160 --> 09:02.160 fine depending on your certificate use case, but if you just need to log in once, it can be five 09:02.160 --> 09:06.400 minutes, right? You just need to get a third log in and then you don't need it anymore. 09:07.760 --> 09:11.760 The other interesting things are that you have the principles added to the certificate, 09:11.760 --> 09:17.760 which means the users basically on the server side that this certificate can authenticate as. 09:17.760 --> 09:27.840 So in this example, the third user, the local user as well, but it could also be rude or some 09:27.840 --> 09:35.920 other user for example, and there are other extensions that allow you to switch certain SSH features 09:35.920 --> 09:39.760 on or like agent forwarding or port forwarding that might be interesting. 09:42.800 --> 09:50.080 All right, yes. On the server side, this is quite easy because I just verify against the user CA, 09:50.080 --> 09:57.360 so I have the public key of the user CA and then I can verify all the certificates without any further 09:57.440 --> 10:03.760 specific information. That's rather easy to deploy because it's just one file really and that's it. 10:06.400 --> 10:11.760 Some were there, I forgot why I was not asked for the host keys because for the server, 10:11.760 --> 10:16.960 I can also have a certificate and then I can do the same vice versa. On the client, I have a 10:16.960 --> 10:24.240 known host line that really trusts the CA for even a wild card of service, so I have one line to trust 10:24.320 --> 10:34.880 a bunch of machines, my whole infrastructure, it needs to be. And open pub key SSH, that's basically 10:34.880 --> 10:42.880 also using certificates. Again, you have a tool that you will have to call to generate the certificate. 10:43.920 --> 10:48.960 In this case, you don't need an external CA, you just talk to your ID provider, get a token, 10:48.960 --> 10:57.520 and then generate a certificate locally. When we connect to the server, it really works the same 10:57.520 --> 11:03.520 as with certificates you're logging without a password, but the interesting thing is 11:06.240 --> 11:13.040 one thing first, the validation of the certificate here happens the same as with public 11:13.040 --> 11:19.920 key authentication, so I will get into y in a moment, but basically we are checking some 11:19.920 --> 11:24.560 meta information on the certificate and not the actual certificate because we also are not talking 11:24.560 --> 11:30.400 to trust the CA, so we are just using the certificate as a transport medium. And you can see here 11:30.400 --> 11:36.800 why, obcasses H, I think this 0.12 was released last week, where the editors inspect command, 11:36.800 --> 11:42.560 which is really nice, because I will skip over that, but you can of course manually also dissect 11:42.560 --> 11:51.600 the certificate with SSH teacher and check you and so on, decode the JSON, the JSON, which is 11:52.720 --> 11:57.920 somewhere in the extensions here. So it's a certificate you see, but there are no principles, 11:57.920 --> 12:04.800 there's no validity period, there's no CA, there's nothing really, except this open pub key extension. 12:04.800 --> 12:09.760 And this extension is actually the ID token that you got from the ID provider. 12:10.720 --> 12:15.040 And this token is what's being verified on the server side, so nobody cares about the 12:15.040 --> 12:21.680 certificate, we just look at the token and then check what's in the token to make sure if you 12:22.400 --> 12:29.840 to see if you can lock in or not. I will not find this in the screenshots here, 12:29.840 --> 12:36.400 on the server side, you have basically you do the validation using this authorized keys command, 12:37.360 --> 12:42.720 and then config wise, you can configure several ID providers on the server side, 12:42.720 --> 12:50.080 and you can have also a mapping file where you can map, let's say, identities from a given ID provider 12:50.080 --> 12:55.440 to local user names. The nice thing is that you can mix and match this and there are also additional 12:55.440 --> 13:00.960 plugins that allow you to look at other attributes of the token as well, like, for example, 13:01.040 --> 13:10.000 the groups that are in the token or other claims. All right, that would have been a nice demo, 13:10.000 --> 13:17.840 I guess, but maybe next time, I was really worried about the containers not coming together and 13:17.840 --> 13:27.040 so on and then it's something which I thought was solved, but okay. All right, I have a quick conclusion 13:27.040 --> 13:33.760 overview kind of, so I was saying I was looking at this for our use case of many users on many 13:33.760 --> 13:42.080 machines, and this open pub key, it's really, really cool that basically you can process the whole 13:42.080 --> 13:47.120 chase and on the server, and you can come up with hundreds of ideas. I think it's really cool 13:47.120 --> 13:51.440 if you need to set something up where there is no central infrastructure, where maybe you need to 13:51.440 --> 13:57.840 improvise some solution and provide access to different users. It's easy to create an app in Google 13:57.840 --> 14:02.480 or GitHub or whatever and then authenticate against that and then map your users onto the system. 14:05.040 --> 14:09.600 What I didn't show in detail was what's missing here and what the certificates provide is also 14:09.600 --> 14:16.800 the host validation, and that's actually something that is really nice. So I will decide for the 14:16.800 --> 14:23.280 certificates. I had to get over myself also to accept that you need a third party tool in practice 14:23.280 --> 14:30.640 really to make this happen for end users so that it comes usable. Yeah, that's really it for me. 14:30.640 --> 14:37.760 I will go with the certificates, but if you're interested, I can only recommend to check out the 14:37.840 --> 14:44.640 open pub key. That's it. Thank you. Maybe there is still time for questions. 14:49.200 --> 14:56.000 Okay, please. I was wondering, giving you an experience, how do you deal with the same reports 14:56.000 --> 15:02.480 certificates, where obviously when there's a long-distance session, the next invocation, the next attempt, 15:02.960 --> 15:07.680 you see how wrong will be evaluated, right? So is there some solution around that to 15:07.680 --> 15:13.280 let's say keep the user out because you've just, you know, you've managed this. So kicking out no, 15:14.320 --> 15:21.120 sorry, yes, I repeat the question. What about the question is, how to handle 15:21.120 --> 15:25.920 a certificate revocations or if the credentials can compromise with ongoing sessions? 15:26.320 --> 15:35.520 I have no solution for ongoing sessions. I would really rely, in this case mostly, on the short 15:35.520 --> 15:50.560 lifetime of a certificate and then for the next run. Sorry? Is there a way to do host verification 15:50.560 --> 15:55.200 with open pub key, not that I know of? Because it's not using the certificate as a certificate, 15:55.200 --> 16:00.560 right? It's just a transport medium, really. What I have prepared in the demo was actually 16:00.560 --> 16:06.240 SSHFP, that's DNS records that hold the fingerprints, but for that to really work, you need the 16:06.240 --> 16:16.880 NSF and that's not really available in most places. Back, please. I use step CA. 16:17.200 --> 16:29.680 If I set up my own CA, hell no. I use step, I mean, in kind of, because with this tool step CA, 16:29.680 --> 16:34.800 it's really easy. Basically, it bootstrap the CA and then you have so-called provisionals, 16:34.800 --> 16:40.560 which are ways to to generate certificates and to authenticate to the CA. So there's a token 16:40.560 --> 16:44.880 based one that you could use, for example, during host deployment. There is one that uses 16:44.960 --> 16:49.120 the almighty connect, which I'm using in this example, there are different ways, 16:49.120 --> 16:55.360 based on that. That is a really hard question that I don't have an answer to. 16:56.400 --> 16:58.960 I'm really done for time for more questions. Okay. 16:58.960 --> 17:00.480 Maybe then outside. Thank you.