31–40 of 69 posts
>How would you look at someone using a single key for their car, house, safe, work place, and so on? One key to rule them all? Honestly, I would be jealous.
Sure, but as soon as you've got to leave the car key at the shop for the car inspection, you might rethink that approach.
Earlier quoted context omitted.
> but I very much doubt that, because I didn't authorize my security key to log into this server, never mind any other afterwards. What? This server pulls your public key from github and allows your client to connect to it. If you have forwarding turned on this server can INDEED connect to every server you are connected to.
No it cannot, not until I touch my security key. I'm not a novice in these matters and I just tested it again. To connect to one server I have to touch my security key and then to connect to another one from it immediately afterwards I need to touch my security key again. Otherwise nothing happens and it just times out. Even when using something like ssh -J user@server1 user@server2 I need to touch it two separate ti…
SSH public keys are called public keys because they're totally safe to distribute anywhere. That's rather the entire point of asymmetric cryptography. So I guess I don't really understand the problem being solved here. And yes, I would very much love to have a single key that worked for my house, car, safe deposit box, etc. One that isn't my smart phone, of course.
SSH public keys are called public keys because they're totally safe to distribute anywhere. That's rather the entire point of asymmetric cryptography. So I guess I don't really understand the problem being solved here. And yes, I would very much love to have a single key that worked for my house, car, safe deposit box, etc. One that isn't my smart phone, of course.
SSH public keys are called public keys because they're totally safe to distribute anywhere. That's rather the entire point of asymmetric cryptography. So I guess I don't really understand the problem being solved here. And yes, I would very much love to have a single key that worked for my house, car, safe deposit box, etc. One that isn't my smart phone, of course.
It all depends on your threat model, I guess.
> Did you know that ssh sends all your public keys to any server it tries to authenticate to? Never really thought about it. Feels kind of "leaky", even if necessary.
Not a big deal at all considering that they're public keys, there's no security concern there. Feels weird, but it's like going into a building that requires a badge and showing proof that you actually own several keys, then the building guard telling you he needs X key to enter since that's the one they know, and it's authorized. All your public keys in your GitHub account are accessible through a link, just .keys>
Really like the approach here. In the past, I've typically managed my SSH keys by naming them as id_ like so, then tinkering with the ssh_config to make use of them. Never thought of using the token approach, though, definitely makes things simpler to work with.
The config file already does this, this is just a shortcut with %h and the file system structure. You literally start an entry with "Host " follwed by "User" and "IdentifyFile". There's even a bash autocomplete rule for it so you can tab through your servers "ssh ". It won't send all the keys to the server if you organize this way (which doesn't really matter anyway, since they are PUBLIC KEYS). It resolves to a pref…
Having a public key doesn't teach an observer your private key, and so they can't impersonate you, but it does allow the observer to distinguish you from others. If you would like to prevent observers from correlating identity this way (most famously if you use a public key for GitHub and also other things) you will want to explicitly forbid your SSH client from offering to prove identities other than the one you know will be used.
The setting in OpenSSH (which you can enable for individual Hosts) is IdentitiesOnly yes
Your proposed configuration will choose to try the file named, but it will not tell the remote server that you don't have any other identities, for that you need IdentitiesOnly. The default is no, although I guess it's possible you have overridden that to "Yes" previously and then forgotten.
My googling skills are failing me. Can anyone help explain what the "(1)" after SSH means? I guess I always thought it was a footnote marker or something (mainly I just ignored it when I saw it) but I'd love to know what it means.
The "ssh(1)" means "read about ssh in man page section 1".
Section 1 is for general commands.
https://en.wikipedia.org/wiki/Man_page
Pages are traditionally referred to using the notation "name(section)": for example, ftp(1). The section refers to different ways the topic might be referenced.
1 General commands
2 System calls
3 Library functions
4 Special files such as devices /dev
5 File formats and conventions
6 Games and screensavers
7 Miscellaneous
8 System administration commands and daemonsEarlier quoted context omitted.
GitHub advises against this[0]: > You may be tempted to use a wildcard like `Host *` to just apply [ForwardAgent yes] to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established. [0] https://docs.github.com/en/developers/overview/usi…
Just tried this $ ssh whoami.filippo.io and it prints this You have SSH agent forwarding turned (universally?) on. That is a VERY BAD idea. For example, right now this server has access to your agent and can use your keys however it likes as long as you are connected. ANY SERVER YOU LOG IN TO AND ANYONE WITH ROOT ON THOSE SERVERS CAN LOGIN AS YOU ANYWHERE. but I very much doubt that, because I didn't authorize my sec…
Note that although it's likely yours always requires a presence check (e.g. touch sensor), OpenSSH does not by default tell FIDO authenticators that it insists on UP (User Present) and so they are entitled (but few do since WebAuthn always asks for UP) to allow the signature to proceed immediately without a presence check so long as they don't set the UP bitflag in their signed response.
I think Fillipo's server can tell the client "I want UP" to check this, but I'm not sure and if few people do that I bet somebody already made a client which gets it wrong.
[[ Because the flags are signed, even though UP is a single bit flag you can't forge it ]]