docs
docs copied to clipboard
Improve documentation on changing hostname and SSH keys
If you expect to change the hostname and SSH host keys, SSH in for the first time without updating your local known_hosts
file:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i insecure_ssh_key [email protected]
To change the hostname:
hostnamectl set-hostname hostname.domain.com
To regenerate the host keys and insert your new hostname into the key descriptions:
rm /etc/ssh/ssh_host_*key*
reboot
You'd think systemctl restart sshd
would be a better choice, there, but an ExecStartPre
line in sshd.service
runs /usr/bin/ssh-keygen -A
and generates more files than either sshd-keygen
or whatever's happening during reboot.
One such file is /etc/ssh/ssh_host_ed25519_key
, which features in the journal:
May 21 06:30:57 hostname.example.com systemd[1]: Started Generate sshd host keys. May 21 06:30:57 hostname.example.com coreos-cloudinit[2947]: 2014/05/21 06:30:57 Authorized SSH keys for core user ... May 21 06:30:59 hostname.example.com systemd[1]: Starting system-sshd.slice. May 21 06:30:59 hostname.example.com systemd[1]: Created slice system-sshd.slice. May 21 06:30:59 hostname.example.com systemd[1]: Starting OpenSSH per-connection server daemon (10.128.185.54:49631)... May 21 06:30:59 hostname.example.com systemd[1]: Started OpenSSH per-connection server daemon (10.128.185.54:49631). May 21 06:30:59 hostname.example.com sshd[4955]: Could not load host key: /etc/ssh/ssh_host_ed25519_key
… so, maybe -A
is a good idea and should be introduced to sshd-keygen.service
, assuming /usr/lib/coreos/sshd_keygen
takes the same arguments as /usr/bin/ssh-keygen
.
I'm having trouble figuring out your intent from your code, here. Why have two ways of generating SSH host keys? Why run only one of them at boot, only to log errors due to it not being as comprehensive as the other?
sshd-keygen.service predates sshd.service being able to do this or ed25519 being supported. Will clean all this up soon.
Ok, cool. It'll just be a doc-fix, then.
@marineam bump
To which doc page should this fix be attached?