Hacker News Reader

Comment by dolmen | Hacker News Reader

This is an interesting approach.

However the task used as an example just shows how provisionning SSH keys was insecure at that company. In fact the user should generate his private key by himself and just provide the public key to the sysadmin to inject it in the system to grant access. AT NO POINT THE SYSDAMIN SHOULD HAVE A COPY OF THE PRIVATE KEY, even temporary. So the 1Password step shouldn't even be necessary.

By the way, I'm the author of github-keygen, a tool to automate the creation of SSH keys dedicated to GitHub access, and to setup SSH settings for that context.

https://github.com/dolmen/github-keygen

View on HN

Making unskilled users manage their keys themselves doesn't sound very secure either. That's the point of moving to a script.

> In fact the user should generate his private key by himself and just provide the public key to the sysadmin to inject it in the system to grant access.

I always found this such an annoying step to implement. We've switched to certificate based authentication on SSH - no more moving around public keys. Really simplified the whole process!

Certificates have a private key and a public key, and you keep the private key secret and move the public key around, so ... how is that different, technically and organizationally?

What do you actually do, and how is it better?

There is only one public key that installed on the servers. That key is the same everywhere. You have a self-serve system that generates short-lived certs to users.

You can put the a regular SSH public key in LDAP, that’s pretty widely supported.

Can you be more specific?

What public key is installed where on the servers? What self-serve system where generating certs how and in what form do users get them and what do they do with them?

And how is the user authenticating to the self-serve system - username/password? And why can't they just do that to the SSH server?

Hey, have a look at this

https://smallstep.com/blog/use-ssh-certificates/

The company certificate is put on the server. Manually, the sysadmin generates the user key signed by certificate and sends it to them. Or the self-serve system generates it and they download it.

The user uses the SSH key as normal. The server checks that if key is signed.

The self-serve system uses the single-sign-on system for the company. The SSH server can't do SSO, maybe can do LDAP, but it is giant annoyance to set it up. A lot SSH use assumes that using key and doesn't support username/password.

Is this really the bar? Doesn't IT own every part of the work machine with the private key anyhow? I realize passwords are different but private keys sit at rest in the machine.

Reply on news.ycombinator.com