We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Theo: The Authorized Keys Manager

00:00

Formal Metadata

Title
Theo: The Authorized Keys Manager
Subtitle
How to manage easily and securely ssh accesses to your servers
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In this talk I will explain why and how we decided to write Theo and how Theo will help you to secure your servers' accesses. Please note that this talk was originally scheduled to be given on Saturday at 18:40. The talk originally in this slot, The brief case for User-space Network Stacks (DPDK and friends) by Ray Kinsella will now take place on Saturday at 18:40. Theo is a 3 components software (a server, an agent and an administrative CLI) that you can use to replace - or to put aside - of all the $HOME/.ssh/authorized_keys in your organisation. Managing access to your servers could be a time-wasting and error-prone task, even in small organisations: you need to add the public keys of new team member, clean up them when a member leaves, update them when people generate new ones. With Theo you'll be able to control all accounts' public keys and configure which servers and which OS users they can access.
Key (cryptography)Server (computing)ComputerLoginLaptopMatrix (mathematics)Computer fileError messageFormal verificationData managementCAN busAxiom of choiceConfiguration spaceOnline helpComputer configurationPhysical systemComponent-based software engineeringCommon Language InfrastructureComputer-generated imageryGroup actionLocal ringEvent horizonStandard deviationKey (cryptography)RoutingLaptopComputer fileServer (computing)DatabaseSpeech synthesisCache (computing)Configuration spaceDiscounts and allowancesMultiplication signLibrary (computing)Client (computing)Physical systemComputer configurationData structurePhysicalismMultilaterationPresentation of a groupMobile appLoginWordConnected spaceRepresentational state transferNeuroinformatikParameter (computer programming)Matrix (mathematics)Data storage deviceGoodness of fitEvent horizonMusical ensembleFlow separationMessage passingPublic-key cryptographyError messageVirtualizationMedical imagingInstallation artCASE <Informatik>RadiusConnectivity (graph theory)Right angleProcess (computing)Open setLocal area networkLocal ringFile systemConfiguration managementSoftware developerGroup actionSequelScatteringService (economics)Electronic signatureComputer animation
Gastropod shellServer (computing)Scripting languageElectronic signatureFormal verificationCommon Language InfrastructureKey (cryptography)Public key certificateSlide ruleVirtual machineToken ringClient (computing)String (computer science)AuthenticationUniform resource locatorVariable (mathematics)Integrated development environmentMIDILocal GroupGroup actionSoftware developerLoginConfiguration spaceExecution unitPoint (geometry)Public-key cryptographyAuthorizationGroup actionElectronic signatureDemo (music)Directory serviceSystem administratorScripting languageCASE <Informatik>EmailClient (computing)Server (computing)Token ringUniform resource locatorFunction (mathematics)Gastropod shellBitKey (cryptography)DigitizingSoftware developerMultiplication signMedical imagingSoftware testingFormal verificationVariable (mathematics)Single-precision floating-point formatSign (mathematics)Configuration spaceDifferent (Kate Ryan album)Virtual machineMereology2 (number)Default (computer science)Volume (thermodynamics)CodeLatent heatPublic key certificateCommon Language InfrastructureMobile appDot productSlide rule
Point cloudComputer animation
Transcript: English(auto-generated)
Welcome, good afternoon, my name is Michele and I will talk to you about Tio, this tool I wrote with some friends, and you can find it on GitHub. So let's start.
Okay, I'm a dad, first of all, full-stack developer, and I'm an avid music listener, I live in Milan, I'm born in Milan, I still live in Milan. So let's start with some words I will use during the speech. So when you hear host, it's the computer you want to connect to through SSH, so where
SSH is running. User is the login name, operating system user you want to connect to via SSH, and with account is whoever connects physical person or virtual account, basically it's
the private key owner. So why? I use several laptops, and I manage several servers, and I work with different teams. So what happens when a new laptop or new desktop has to be activated, an old laptop
or desktop has to be dismissed, or we are going to install a new server, or a new member joins our team, or a current member leaves the team. Well, you need to update your authorized keys everywhere.
Of course if you use it, then, and if you don't, I think you should. So, I hate doing this kind of stuff myself or some other teammates, because it's very error prone. Files are scattered in several places, so it's full matrix of user and host.
At the same time it's critical but monkey world. I mean, you have to do the same things over and over, so you have to copy and paste or SSA key copy around your servers, and if you, I forget to add the key, someone
will complain, she can do her job, and at the same time, if you forget to remove a key, someone will have access to the host while she shouldn't. So at the same time you miss the full picture. I mean, did I forget to add the key in some host or user, and there's no way to verify
it, but checking everything. So the other question is, who can access this host, maybe with this user? You have to cut the authorized key files and remember each key was the owner of each
public key. And so I want a single place to manage all of this stuff. Then what? Okay, we can rely on configuration management, Ansible, Puppet, Chef, or whatever you can
choose, or since OpenSH is 6.2, which is quite old, five years old, a new option is available, it's called authorized keys command.
How many of you know this command, this option? Okay, and authorized keys command supports fetching authorized keys from a command standard route beside or instead of the file system, and okay, I got it, I want this, and thanks
to Gianni, which is here, that had him here there. So the idea is to store accounts, public keys, and permission in a single place and serve them through HTTPS to each host.
So from whatever client you SSH with a username, the US user, to the host, the host fetches these authorized keys from an external server and it pass host name and the user. So like this, get authorized key, host name and user.
The server, Tio in this case, looks up for the key, which are authorized for the user, a.user in the example on host server one. If it finds any, it returns them to the host, like a normal authorized key files.
So this is Tio. Tio does exactly this, has three components. The first one is the two server, where you will store the public keys, the accounts, and the permissions. Then we have a Tio agent, Tio agent is the command that SSH will run when a new
connection is requested, and then we have this Tio click, which is the command tools you use to add new accounts, remove accounts, and add permission and so on.
So let's start with the fourth one, Tio server. So it's already available as a Docker image, I'm sorry, it's not. It's in the Docker app as Tio app slash Tio, and you can use SQL library or MariaDB or MySQL database to store data.
It supports caching where user host authorized keys, so if the cache for this couple user host is already in cache, it doesn't have to query the database. You can use memcached already, as you prefer, and it's written in Node.js.
Tio server exposes several REST APIs for manipulating what? Accounts for sure, groups, authorized keys, and permission. And it's consumed by Tio click.
Exposed is also an endpoint for fetching authorized keys, and it's consumed by the Tio agent. So Tio agent is easy to use because as a self-installed feature, you can execute it as a first time passing the parameters you want, and it will update the shhd config,
and it will create the structure it needs. Keeps a per local, per user, local copy of the authorized keys in the event that
the Tio server is unreachable. So if Tio agent is unable to reach Tio server, it will use, if present of course, the local copy. So it's the last time he was able to fetch the authorized key for that user.
Tio agent can verify authorized key signatures, and discount them if are not valid. We will return on this later. And it's written in Go. We wrote an agent, yes, but it can be replaced by a shell script that cools Tio server,
because it's just HTTPS. It could be slightly harder if you enable the signature verification, because you have to, it's not enough using core. Okay, then Tio click is already available as an npm package.
The npm package name is Tio app dash cli. It supports authorized key signatures, and it's written in OJS of course. So what is authorized case signing? The problem we told is we need to avoid unauthorized keys to be returned to shd.
So Tio cli and Tio agent both support a way to sign Tio cli signs, and to verify, Tio agent verifies each keys. When you set up Tio cli, you can create a certificate with a private key,
and when it uploads the public key to the Tio server, it attaches also the digital signature of the key. Tio agent, on the other side, when it downloads the authorized keys,
it receives also the digital signatures, and it verifies it using the public key. Right now, these slides will help you to go through the demo.
And the first thing we do is to generate some tokens we will use for administration, so used by Tio cli and for Tio agent. In this case, we will use the first one for the Tio cli and the other two for Tio agent.
We just run Tio server as a docker image. We will see we just pass a local directory as a volume, and we will pass the admin token and the client token.
We will say to docker which port we want to expose, and we'll run it. For Tio server, it's enough. With Tio cli, we have to install it. I install it globally with NPM.
I will export two variables I need, Tio URL and Tio token, which this one is the admin token used before. We can also store these variables in these two different places, for user in dot Tio. Okay, this is a mistake. This is still enough.
Slash in the home directory is dot Tio, enough, not Tio cli. And or in a system-wide ATC Tio cli env. The first thing to do is using Tio cli is to create a new account.
We just have to add a name and an email. An email, of course, must be unique. After that, we can add the public key.
In this case, I will use my own public key in my own directory. As you can see, by the output to the first account, the first account we created is assigned this public key. Then we can create another account here.
And also, I will put the same public key and do the same for the third account. At this point, I'm going to create a group. A group is a way to assign the same permission to a group of users.
So first, I create a group, and then I will add some users, some accounts to the same group.
Now I can assign permission to the group. So I can say the group that all the accounts of the group developers are granted to log in as user node to the host test server.
At the same time, I can add a permission to a single account, of course. So in this case, I will say that the accounts is op.a at example.com is granted to SACHS user admin on test server.
You can have a quick overview using the common groups get developers, and it will list all the accounts that are in this group, and the permission of the group. The same thing you can do it for a single account,
and it will return all the public keys associated with this account, and all the groups is into. And at the same time also, the permissions. And that's all. Now we have to configure TEO agent.
The easiest way is to download from GitHub. You can download the last test binary, and after you downloaded it, you have to add the execution bit. Then you can create a specific user.
In this case, I have no shell, so it's been false. It has no login. And at this point, you can use this install feature. And with this command, you say, OK, install me. Don't ask me anything.
Do the default. Add this URL as TEO server, and use this token to connect it. You have to reload SACHS after that. Before logging out from the server,
I suggest to check that everything is working, so you can execute. It's done. OK, sorry. That's all. But basically, after you do that, you should be able to log in from your token machine using the key to the users. You defined it before.
So that's it.