Re: Broken SSH Key Parsing

On Mon Aug 31, 2026 at 8:39 PM UTC, Magnus Hagander wrote:
> On Mon, 31 Aug 2026 at 22:25, Tristan Partin <tristan(at)partin(dot)io> wrote:
>
>> On Mon Aug 17, 2026 at 7:53 PM UTC, Magnus Hagander wrote:
>> > On Mon, 17 Aug 2026 at 18:08, Tristan Partin <tristan(at)partin(dot)io> wrote:
>> >
>> >> On Tue Aug 11, 2026 at 8:08 PM UTC, Tristan Partin wrote:
>> >> > Hey folks,
>> >> >
>> >> > I just got access to a Git repository on postgresql.org, so I started
>> >> > going through the motions of adding an SSH key to my profile. I was
>> >> > unable to add my key as-is, so I figured that I would flag the issue.
>> My
>> >> > public SSH key looks something like this:
>> >> >
>> >> > ecdsa-sha2-nistp256
>> >>
>> AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDPYnw8WWCrgL0sXijK7BY1Qz7KJlQZNe+ErNNwmfqazAd/CuTNNdENj21R6iR2CsjoEZ1prFcj/hPDV/j4nf7s=
>> >> email(at)example(dot)com (hostname)
>> >> >
>> >> > Accordingto to SSH key documentation[0], an SSH key is composed of
>> >> > 3 components:
>> >> >
>> >> > A B C
>> >> >
>> >> > A: The key type
>> >> > B: Base64-encoded public key
>> >> > C: An optional comment
>> >> >
>> >> > The problem with this key in particular is the comment. If I remove
>> >> > `(hostname)` from the key, postgresql.org will accept the key. I have
>> >> > a suspicion that we are probably incorrectly validating the key. Some
>> >> > pseudocode that would illustrate my hypothesis:
>> >> >
>> >> > keys = []
>> >> > for t in text.splitlines():
>> >> > sections = t.split(" ")
>> >> > if len(sections) < 2 or len(sections) > 3:
>> >> > raise ValueError("Invalid SSH key format")
>> >> >
>> >> > keys.append(OpenSSHKey(sections[0], sections[1],
>> >> sections[2] if len(sections) == 3 else None))
>> >> >
>> >> > I am happy to investigate this further if I can get read access to the
>> >> > postgresql.org site.
>> >> >
>> >> > I find my current comment format, including the hostname, to be useful
>> >> > when identifying the email and machine the key belongs to. I'll work
>> >> > around it for now.
>> >> >
>> >> > [0]: https://sshref.dev/#intro_legc_pub
>> >>
>> >> Here is a patch to improve things a bit. We should probably add some
>> >> unit tests for this
>> >>
>> >
>> >
>> > Wouldn't it be safer to just cut the options if they are included? If we
>> > don't then we have to also audit every downstream consumer of the keys
>> > through the authentication system so they know how to deal with those
>> keys,
>> > since we're chagning the exchanged format there, since as it is now we
>> just
>> > pass it straight through.
>>
>> Sounds reasonable. How are these SSH keys consumed? Do they just make
>> their way into a Git server config somewhere?
>>
>
> It's a couple of different ones as well but fundamentally yes,that's how
> they work.

What are your thoughts on reworking the UI/UX for saving SSH keys on
postgresql.org? I'm thinking we could take a more GitHub-like approach.
User adds one key at a time instead of the \n deliminated text entry
that we currently have. I think it would make it easier to understand
which SSH key is causing a failure. Additionally, I think it would make
the validation process a bit nicer.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)