Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ Bender 5 days ago

I agree with you and just wanted to add that for what it's worth one can optionally limit where ssh keys are useful by adding network restrictions on the public key / server side. e.g.

    grep AuthorizedKeysFile /etc/ssh/sshd_config
    AuthorizedKeysFile /etc/ssh/keys/%u

    cat /etc/ssh/keys/bender
    from="[192.redacted]/24,[redacted]/20" ssh-ed25519 AAAAC[snip...] comment
or wherever your system is configured to look for public keys, typically /home/username/.ssh/id_dsa.pub. I use a different location. Even being really broad like adding a /16 or /8 for a home ISP is still better than allowing the entire internet. This can also be useful where machine-to-machine ssh keys are utilized one can limit the access to that network so that should keys leak the potential blast radius of damage is reduced. For example, the keys for an Ansible account can be restricted to the Primary/Secondary Ansible server IP addresses or at very least the CIDR block(s) of the network(s) they reside in. Broad restrictions are not perfect but perfect is the enemy of good or good enough.

Example use case would be that lets say a contractor from Microsoft tries one of your keys. Your restriction limits the key validity to 24.0.0.0/8 and they are coming from 207.0.0.0/8. They will be denied Authentication refused and you now have log entries that can be shared with their fraud department, the world, whomever. Obviously the tighter the restrictions the better, at the risk of requiring a static IPv4 or IPv6 address if too tight. One can always have lighter restrictions on a fall-back account that requires additional hoops to sudo / doas / su.