OpenSSH can use host certificates to verify the host (like SSL certs on a webserver). OpenSSH can also use user certificates to verify the user (like passwords or ssh keys).

Both these types of cert to be used independently of each other.

I've tested using user certificates to authorize user login, since that is what most
people do with keys. People never really verify the host identity.

It works great and it's actually very simple. This will be my new SOP going forward.

Before starting to add hosts and users you need to create a Certificate Authority (CA) - which is actually just a key pair. It's a one-liner.

Every time you create a new host, you just need to copy the same file to it - the public key of the CA. And change one line in sshd_config to allow ssh certificates.

Every time you have a new user on your team who need access to servers, you have to generate a certificate for him. It's a one liner. He will copy the certificate to his own machine. And the ssh client will automatically send the certificate when needed.

Generating certificates is the part that could be automated. You could for instance be given a certificate that expires in 5 minutes. That would allow you to login and stay logged in. But if you need to login again, you need to generate a new certificate.

@stacksofplates said in Securing SSH:

Another really good option is not letting them log directly into the systems at all and forcing them to use a config management tool. So something like Tower or a Jenkins server that logs all of the commands run and has the permissions set there.

Right. Just like the best defense is a good offense (or vice versa?) The most secure port, is a closed port. Locking down SSH, no matter how good, isn't as good as completely closing it.

Or using config management to only open it when necessary, is an "in between" step, too.

@black3dynamite said in Copy SSH public key to ssem behind a jump box:

# From your host to your JUMPBOX # Not needed if your public key is already in placed cat ~/.ssh/id_ed25519.pub | ssh jump.domain.com 'umask 0077; mkdir -p .ssh; cat >> .ssh/authorized_keys'

ssh-copy-id should do this

@JaredBusch said in VPS injected ssh keys:

Under no circumstances do I actually want anyone's key tied to the root user. It negates all accountability.

It's for pre-production setup. Not for deploying straight to production.

@DustinB3403 said in How to configure SSH Keys for Nessus:

Isn't this step redundant?

sudo mkdir /home/scan_user/.ssh sudo chown -R scan_user:scan_user /home/scan_user

As ssh-keygen will create these directories and set the ownership?

It certainly does on Fedora.

@IRJ said in Cannot SSH using public key:

RSA key working on Nessus, too. Thanks @DustinB3403 for calming me down

You're welcome.

Upgraded from 18.04.2 LTS to current. Accepted default answers for individuals packages during upgrade.

Had issue with MC and the meshcentral-data/meshcentral.db getting set with root:root perms and this caused a few errors with starting MC from meshcentral.service

Changed perms to back to <user>:<user> and all is well. Don't know what would change those perms though? Either way, all is well now.

@JaredBusch said in SSH Keys and migrating to a new device:

@wirestyle22 said in SSH Keys and migrating to a new device:

@JaredBusch Thanks. This is great

Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.

So this process is really only something that should ever happen on a profile migration.

Ya it's a big advantage to having automounted home directories or having LDAP store the keys. You can easily revoke and add another key and have it work everywhere.

Or using Kerberos instead of pub/priv keys.

I realize @JaredBusch knows this, but for others who may not.

Since the images disappeared, I added them as code.

Also, Identity Management (FreeIPA) makes it really easy to store public keys in LDAP so any system joined to IdM can verify the key.