personal blog
git clone git://
Log | Files | Refs | README

commit e29308e51963210ad377201b854701826360e8a2
parent 3b862722c60af9564e63382dfaf20ebbcb005237
Author: pyratebeard <>
Date:   Sat, 16 Dec 2023 22:28:08 +0000


Mentry/ | 30++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/entry/ b/entry/ @@ -53,7 +53,7 @@ Host key verification failed. Phew, now we can contact our sysadmin and make sure we're not being intercepted. -Or, as is more likely, we remove the "offending" line and reconnect +Or, more presumably, we remove the "offending" line and reconnect ``` ssh-keygen -f ~/.ssh/known_hosts -R ``` @@ -67,7 +67,7 @@ For SSH, a CA is actually just another SSH key pair. You then sign a hosts publ ssh-keygen -t ed25519 -C -f hostca-key ``` -Now I have _hostca-key_ and _hostca-key.pub_. I am using ED25519 instead of RSA or ECDSA. +Now I have _hostca-key_ and _hostca-key.pub_. I prefer using ED25519 instead of RSA or ECDSA. The public key is the entity we want to trust, so we add that to our _known_hosts_ file, prefixed with `@cert-authority` and the domain your servers are in ``` @@ -89,7 +89,7 @@ cat >> << EOF rsync # method 3 -ssh-keyscan | grep ed25519 +ssh-keyscan | grep ed25519 | tee ``` Now we can sign the host public key using our CA private key @@ -99,15 +99,15 @@ ssh-keygen -s hostca-key -h -I -n, * `-s` sign - tells `ssh-keygen` which key to sign with * `-h` host cert - indicates we're creating a host cert (not a user cert) * `-I` unique identifier - an identifier used for logging -* `-n` principals - hostname(s) certificate is valid for, good practice to user short hostname and FQDN +* `-n` principals - hostname(s) certificate is valid for, good practice to use short hostname and FQDN * `-V` validity - length of time the certificate is valid for, in this example it is 52 weeks -* confirm new server key cert +This command will produce a certificate (`[key name]`). To confirm the new server key cert details incant ``` ssh-keygen -L -f ``` -* copy new key cert to server +Once the certificate has been generated it needs to be put on the server it is for, usually in the /etc/ssh directory ``` # method 1 (on server) cat >> /etc/ssh/ << EOF @@ -118,12 +118,16 @@ cat >> /etc/ssh/ << EOF rsync server:/etc/ssh/ ``` -* on server add following to _/etc/ssh/sshd_config_ +So that SSH knows to use a certificate add the following to _/etc/ssh/sshd_config_ and reload the SSH service ``` HostCertificate /etc/ssh/ ``` -* reload ssh daemon +If every server in the environment is signed with the same CA then only one line is needed in _known_hosts_, the `@cert-authority` entry. New servers can be signed and users won't have to accept any fingerprints because they will already be trusted. Systems can be rebuilt, or keys regenerated, and it won't cause any impact to users. + +If you're an admin of a shared Linux system, or are able to manage users' workstations, then drop the `@cert-authority` line into _/etc/ssh/ssh_known_hosts_ for it to work system-wide without bothering the users. + +TK if CA is compromised - does changing host cert cause a warning on the user's end? ## user * create user ca key @@ -191,17 +195,7 @@ CertificateFile /path/to/ ``` * now no longer need authorized_keys file on server -* only one line in known_hosts, or /etc/ssh/ssh_known_hosts * must have dns resolv on greyskull (and nublar for lxc) * must have short name in ssh/config on nublar for lxc * must have cert-auth known host on nublar for lxc - - -aliases.zsh -lxst=lxc-unpriv-start -lxat=lxc-unpriv-at - -environment.zsh -export DOWNLOAD_KEYSERVER="hkp://" -