I was a bit surprised to see that on my https://meta.sr.ht/keys page,
there is a way to see anybody's public ssh keys at
https://meta.sr.ht/%7Eusername.keys
Recommended key hygiene says that one should create a new key for every
client system that you work on. With this, the key comments (name) can
reveal quite a lot about the systems in use by a sr.ht user. I know that
the key name can be changed, but in my view the names should be for *my*
use, not the world at large.
In short, the set of ssh keys I use are business between me and the ssh
server(s) that I want to connect to. Not anybody else's business.
This argument does not apply to PGP keys, and being able to get a user's
public PGP keys is a nice feature.
Hi
Agree with Greg
It's a snippet of information that I would not have expected would be
discoverable.
---
Mike Lake
On 2020-03-05 12:37, Greg Hewgill wrote:
> I was a bit surprised to see that on my https://meta.sr.ht/keys page,> there is a way to see anybody's public ssh keys at> > https://meta.sr.ht/%7Eusername.keys> > Recommended key hygiene says that one should create a new key for every> client system that you work on. With this, the key comments (name) can> reveal quite a lot about the systems in use by a sr.ht user. I know > that> the key name can be changed, but in my view the names should be for > *my*> use, not the world at large.> > In short, the set of ssh keys I use are business between me and the ssh> server(s) that I want to connect to. Not anybody else's business.> > This argument does not apply to PGP keys, and being able to get a > user's> public PGP keys is a nice feature.
Also, shouldn't be a surprise, because "A list of your SSH public keys
is available to the public via" is written right on the page where those
keys were submitted, right next to "Add key" button.
On Wed Mar 4, 2020 at 6:00 PM PST, Victor Goff wrote:
> On Thu, Mar 05, 2020 at 01:37:02AM +0000, Greg Hewgill wrote:> It is similar on github: https://github.com/username.keys> and gitlab: https://gitlab.com/username.keys
And on Launchpad. Ubuntu Server's installer even lets you import keys
from Launchpad or Github to help get your user account setup.
-Zach
On Wed, Mar 04, 2020 at 11:07:00PM -0500, Zachary King wrote:
> On Wed Mar 4, 2020 at 6:00 PM PST, Victor Goff wrote:> > On Thu, Mar 05, 2020 at 01:37:02AM +0000, Greg Hewgill wrote:> > It is similar on github: https://github.com/username.keys> > and gitlab: https://gitlab.com/username.keys> > And on Launchpad. Ubuntu Server's installer even lets you import keys> from Launchpad or Github to help get your user account setup.> > -Zach
Public keys are public, and the attack is probably going to be addressed to RSA
rather than that specific key, at which point, when broken, it won't matter.
On Thu, Mar 05, 2020 at 04:06:19AM +0000, Greg Hewgill wrote:
> March 5, 2020 5:00 PM, "Victor Goff" <keeperotphones@gmail.com> wrote:> > > It is similar on github: https://github.com/username.keys> > and gitlab: https://gitlab.com/username.keys> > I notice that github does not expose the key comment (name) in this case.
I wasn't sure if Github had done that or if I had just not added it in.
Sometimes I will make a comment sometimes I won't. The `.ssh/config` file has
the key named there, so keep track of them that way, rather than what is on the
server.
I'm not too opposed to having my public SSH keys out in the open, but I
do disagree with the key comments/names of the keys in public as they
contain information that I do not wish to give out as Greg mentioned
before. GitLab scrubs the names of the keys (I can confirm as my work
uses a private GitLab instance).
Also, I did a bit of digging around, and the "A list of your public ..."
message near the "Add key" button is quite recent [1] as I did not
remember reading such a comment before today.
Regards,
Kunal
---
[1]:
https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/1fe10c31a6f42744b5240a33d279ac46c700ee75
On Thu, Mar 05, 2020 at 03:30:44PM +1100, Kunal Sareen wrote:
> I'm not too opposed to having my public SSH keys out in the open, but I> do disagree with the key comments/names of the keys in public as they
The name combination, I think that is something that was given with the key, you
control that information. That said, perhaps delete the key and submit it (or a
new one) with only the information you would like to share publicly?
> contain information that I do not wish to give out as Greg mentioned> before. GitLab scrubs the names of the keys (I can confirm as my work> uses a private GitLab instance).
My github doesn't have the informatoin, my gitlab keys (multiple) have them and
don't have them depending on what I ended up submitting.
> > Also, I did a bit of digging around, and the "A list of your public ..."> message near the "Add key" button is quite recent [1] as I did not> remember reading such a comment before today.
I only signed up a couple of weeks ago, so I do not remember it not being there.
On Thu, Mar 05, 2020 at 03:30:44PM +1100, Kunal Sareen wrote:
> I'm not too opposed to having my public SSH keys out in the open, but I> do disagree with the key comments/names of the keys in public as they> contain information that I do not wish to give out as Greg mentioned> before. GitLab scrubs the names of the keys (I can confirm as my work> uses a private GitLab instance).> > Also, I did a bit of digging around, and the "A list of your public ..."> message near the "Add key" button is quite recent [1] as I did not> remember reading such a comment before today.> > Regards,> Kunal> ---> [1]:> https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/1fe10c31a6f42744b5240a33d279ac46c700ee75
Correction, I signed up 23 days ago, I just don't remember not seeing that
message. But I wasn't looking at the service seriously until about 2 weeks ago.
This issue has been discussed before. As some have pointed out, your SSH
public key is a _public_ key. It's tautological. Your public keys are
not private. We also expose your email address, in git logs, and so does
GitHub and Gitlab and the git repo you pushed to some random server with
cgit. This is a collaborative platform and these things are by design.
On Thu, Mar 05, 2020 at 12:39:09AM -0500, Drew DeVault wrote:
> This issue has been discussed before. As some have pointed out, your SSH> public key is a _public_ key. It's tautological. Your public keys are> not private. We also expose your email address, in git logs, and so does> GitHub and Gitlab and the git repo you pushed to some random server with> cgit. This is a collaborative platform and these things are by design.
The message appears to be in response to me, though it is definitely in
agreement when what I stated about it being public... I realized that I was
submitting public keys, and that they are meant to be exposed to whatever
degree, and since they are public keys, that degree is up to and including
"public".
Definitely no argument here about design or expectations, and no surprise that
it is treated as public information.
On Wed Mar 4, 2020 at 5:39 PM PST, Victor Goff wrote:
> ... perhaps delete the key and submit it (or a new one) with only the> information you would like to share publicly?
This is probably the easiest way to handle it. You don't have to do
anything special, just delete the last part of the public key when you
paste it into meta.sr.ht.
> > Also, I did a bit of digging around, and the "A list of your public ..."> > message near the "Add key" button is quite recent [1] as I did not> > remember reading such a comment before today.>> I only signed up a couple of weeks ago, so I do not remember it not> being there.
I don't know how often things get deployed, but the commit that added
that was made 17 days ago:
https://git.sr.ht/~sircmpwn/meta.sr.ht/commit/1fe10c31a6f42744b5240a33d279ac46c700ee75
March 5, 2020 6:39 PM, "Drew DeVault" <sir@cmpwn.com> wrote:
> This issue has been discussed before. As some have pointed out, your SSH> public key is a _public_ key. It's tautological.
To be clear, I cannot object to the *key* part of the public key
being made public. However, the *comment* part, which is a name
that is meaningful to me only, should not be exposed in the public
list of keys. In order to be meaningful to me, the name is likely
to expose some aspect of my client setup, and I don't want to remove
that or substitute the actual machine names/locations with code
words.
I would be happier if the public list of keys omitted the name part.
On Thu, Mar 05, 2020 at 06:56:09AM +0000, Greg Hewgill wrote:
> March 5, 2020 6:39 PM, "Drew DeVault" <sir@cmpwn.com> wrote:> > > This issue has been discussed before. As some have pointed out, your SSH> > public key is a _public_ key. It's tautological.> > To be clear, I cannot object to the *key* part of the public key> being made public. However, the *comment* part, which is a name> that is meaningful to me only, should not be exposed in the public> list of keys. In order to be meaningful to me, the name is likely> to expose some aspect of my client setup, and I don't want to remove> that or substitute the actual machine names/locations with code> words.> I would be happier if the public list of keys omitted the name part.
RFC 4716[1] specifically states:
> The comment header contains a user-specified comment. The comment> SHOULD be displayed when using the key.
The RFC is informational only, not standards specifying... but it is
clearly the intention that the comments are public as well as the key.
The information mentioned in the RFC suggests that there be an allowance
for private headers as well, but I don't think I would submit a public
key with truly confidential information, even in "private headers"
especially in cleartext.
[1]: gopher://fnord.one:65446/0/Mirrors/RFC/rfc4716.txt