131–140 of 159 posts
Earlier quoted context omitted.
Why does ssh-keygen include unnecessary information by default?
Because it helps usability when the user is editing ~/.ssh/authorized_keys - if the default is not changed, the key comment has some context, so finding the right key is easier. I strip comments from my SSH keys too for the same reason you do. But most people don't seem to care and there is a reason for the default.
Earlier quoted context omitted.
That you should be doing anyways, shouldn't you?
You certainly can, it's almost certainly unnecessary though. SSH keys are not like passwords, compromise of a server with your pubkey in no way effects the security of your private key. Many people will post pubkeys online so they're easy to add to new servers.
Earlier quoted context omitted.
If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.
If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example. Admitted…
[1] https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
Earlier quoted context omitted.
No, this is a completely unnecessary piece of information that ssh is unnecessarily jamming into the pubkey. What possible use does including the hostname of the generating machine serve for public key authentication? Today it's my hostname. Tomorrow ssh-keygen (with default arguments) could start including more sensitive information, like the IPv6 address of my machine that's open to the internet and its exact OS ve…
First, this field is important. It's not used for authentication in any way, as it's just an optional comment, ignored by sshd otherwise. It's not an information for sshd, though: it's information for human user . Without this comment you don't have an easy way to tell where the keys come from. Second, if you don't trust ssh-keygen, why the heck do you use it in the first place?
Earlier quoted context omitted.
If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.
If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example. Admitted…
https://github.com/Lattyware.keys - GitHub leave it blank:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW Gareth Latty (gitlab.com)
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi Gareth Latty (gitlab.com)
Earlier quoted context omitted.
First, this field is important. It's not used for authentication in any way, as it's just an optional comment, ignored by sshd otherwise. It's not an information for sshd, though: it's information for human user . Without this comment you don't have an easy way to tell where the keys come from. Second, if you don't trust ssh-keygen, why the heck do you use it in the first place?
I didn't say I don't trust it, just that I don't trust that it won't leak private info when using the default arguments.
I wish this whole SSH business would be less complicated...
The defaults are actually fine; don’t worry. You don’t need to set a passphrase for your key, you don’t need to run an agent. Just ssh-keygen -t ed25519 and paste your public key into ~/.ssh/authorized_keys. `-t ed25519` is optional.
That's highly questionable advice. The passphrase is like two factor auth, it protects you if your private key ends up in someone else's hands. That's a risk you have to weigh up.
Earlier quoted context omitted.
If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example. Admitted…
It's worth noting both GitHub and GitLab strip the comment off the keys. https://github.com/Lattyware.keys - GitHub leave it blank: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW https://gitlab.com/latty.keys - GitLab add a generated comment: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyX…
Earlier quoted context omitted.
If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example. Admitted…
It's worth noting both GitHub and GitLab strip the comment off the keys. https://github.com/Lattyware.keys - GitHub leave it blank: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGAx5F7iJTDwbPrdhrTtVdQRtozcRDvGNuU7BB+4+mHi ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyXPLL27v9vvE1+p1XOiW https://gitlab.com/latty.keys - GitLab add a generated comment: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIL6WfINFFvzT+Z+l5sYq9zJoyX…