71–80 of 90 posts
I think a lot of people in the comments are missing the fact that public keys are by default intended to be public . This is an explicit and intended property of private-public key cryptography. Your public keys are not a security boundary and setting `IdentitiesOnly` in your SSH configuration does not do anything to strengthen your security posture.
Before SSH-ing into untrusted hosts, make sure you understand what SSH agent-forwarding and X11-forwarding are. Also, maybe don't trust the SSH config defaults on whatever host you're on at the moment. You can explicitly set defaults yourself in your `~/.ssh/config` or similar.
>SSH agent-forwarding and X11-forwarding Are they enabled by default when running SSH?
* github.com * sourcehut (sr.ht) * gitlab.com * codeberg.org * ...
published ssh keys & changes, to verify (offline) ssh signed commits, verify, encrypt mails, exchchange secure data (age-enc).
You can use this app:
[] https://github.com/paepckehh/gitkeys
If you want your own repos public keys tracked / monitored / archived, just leave a star:
I have been circumventing this issue purely by accident it seems. I have always had ssh-keygen write out the keys to a custom path like ~/.ssh/keys/$service/$key{,.pub} and configured each host's "identity" manually with the ssh config file. I never did this for security purposes or anything, I just thought it made more sense than the default behavior.
I learned about this when I encountered a server with an aggressive fail2ban that wouldn't let me log in because I had too many ssh keys. It apparently counted every wrong key as an auth attempt, so it blocked me before my ssh client tried the right key. Since then I've used IdentitiesOnly=yes
IdentityFile ~/.ssh/some.key
Before SSH-ing into untrusted hosts, make sure you understand what SSH agent-forwarding and X11-forwarding are. Also, maybe don't trust the SSH config defaults on whatever host you're on at the moment. You can explicitly set defaults yourself in your `~/.ssh/config` or similar.
And how to configure your ssh agent to confirm with you on each use. See `-c` in `ssh-add(1)`, and make sure you're using an agent that supports it (GNOME's Seahorse doesn't, gpg-agent does, macOS's ssh-agent doesn't make can be made to via some AppleScript).
Because my ssh agent confirms each key use, I enable agent forwarding on every ssh connection without fear.
Not sure about other systems, but this isn't the default on Debian. I, at least, start every day by running `ssh-add ~/.ssh/id_whatever_service_I_want_to_auth_to`, because it doesn't do it by itself, and I was too lazy to configure it. For the same reason, the party trick didn't work here, since I haven't had to commit anything today yet ...
Earlier quoted context omitted.
The downside is that if you use a large range of servers, you will have to configure them to tell SSH what identities to use. This can be cumbersome if you ssh by alias (e.g. 'foo' rather than 'foo.yourcompany.com'). If you only SSH into servers you trust (a sensible practice) then the benefit is marginal.
Note that it does accept wildcards so you can do rules for *.mycompany.com You can also use placeholders for keys, so for example I have a ssh config like: Host *.mycompany.com # Employer specific yubikey stuff Host *.mydomain.com IdentityFile ~/.ssh/keys/id_primary Host * IdentitiesOnly yes IdentityFile ~/.ssh/keys/%r@%h # uses ~/.ssh/keys/git@github.com for github for example I originally started doing this because…
IdentityFile ~/.ssh/keys/%h