OpenSSH 10.5/10.5p1 | Hacker News Reader

OpenSSH 10.5/10.5p1

openssh.org

117 pointsvoxadam38 comments

"[..] a security bug identified by AI tools is subsequently independently discovered by a different researcher. This suggests that adversaries who do not report bugs to OSS projects are likely to be able to discover these bugs too. Given this, the OpenSSH team will, for now, be making more frequent releases to get bugfixes into users' hands more quickly rather than batching them until the next planned release."

Meanwhile Zig developers: not even a spell check fix using AI will get accepted

> ssh(1): add a "ssh -Z user@host" mode that prints the keys that will be tried for public key authentication in the order that they will be used.

Oh, that's a nice new feature:)

I don't think there has been a single month in the last 5 years that I haven't had to figure out which public-key was used to authenticate me to a host via `ssh -vv` - often to let someone else who is failing to connect know which key to use.

The `-Z` is less useful - as I almost always know exactly which and what order the public keys are - as most of our sshd instances fail after 5 attempts - so making sure either (A) the correct ones or used or (clumsily, B) - just putting the correct one in the first five to try.

Would be a nice feature to echo which key successfully worked.

This is why I keep a ~/.ssh/config file. I store all the hosts and various connection parameters (uernames, alternate ports, keys, etc.) in that file.

Would that work for you?

So, I have this which I use about once a day:

  vis ()
  {
      vim ~/.ssh/config
  }

But - we have around 250k hosts in about 42 datacenters, some of them going back 8+ years, built by different teams - not everything has been standardized - and :

  $ wc -l ~/.ssh/config
  268 /home/shephard/.ssh/config

has lots and lots of weird IP mappings to ssh-keys that is just gross, and not something I would want to expose others to (mostly because it changes a lot behind the scenes)

So - from time to time, someone will say, "hey - the key that should be working in this datacenter/cluster isn't working, how do you get connected" - at which point I so a ssh -vvv and eyeball which one was accepted.

Being able to ask ssh just to print it out - would be awesome.

Yup, or the alternative: is authentication failing because I have too many public keys and it just stopped trying after N keys?

I do not want to confess how often I just drop in and change the order of my approximately dozen or so keys at the end of the ssh config file just to get the ones I want up to the top of the list.

Yeah, I've occasionally had to divine from verbose debug output that the remote host didn't like more than three or so public key attempts before requiring another auth type.

Glad they're not letting potential high false positive rate preclude discovery of true positives. Better to get a lot of noise with a little bit of signal, if the alternative was not get that signal at all.

Darn, still no host headers so we can reverse proxy on a single ip

> Darn, still no host headers so we can reverse proxy on a single ip

How would this be done? After the "SSH-2.0" banner, the first packet is SSH_MSG_KEXINIT and there's no space in that for a "Host" header:

* https://datatracker.ietf.org/doc/html/rfc4253#section-7.1

If we did this in SSH then I think we should do it properly and take inspiration from TLS ESNI https://datatracker.ietf.org/doc/draft-ietf-tls-esni/25/

You could wrap a TLS-connection around your SSH-connection, and then use the ALPN to indicate SSH, so that your reverse proxy knows, what to do with it.

No, AI assistance is NOT welcome in general. They mention security bug reports, so using AI like ASAN etc. is welcome.

> No, AI assistance is NOT welcome in general.

Can you cite that? I see them specifically welcoming AI security reports; I don't see any evidence that other AI submissions are not welcome.

These policies seem to be often evolving lately in many projects, but I believe OpenBSD (the project OpenSSH is contained inside) is currently skeptical of AI generated code contributions at this point in time.

For example, I found this on a Google search, here is a thread from Theo, the project leader, about LLM output and copyright, where he says they can't accept it into the tree on copyright grounds. https://marc.info/?l=openbsd-tech&m=177425035627562&w=2

Elsewhere in the thread he implies using it for a code review tool is ok

Idk if its accurate to rote project the policies of OpenBSD to OpenSSH, yes technically its a subproject but in practice stewardship and thus effective policy is pretty much all damien.

If they disagreed about something so fundamental as the attribution of copyright, it would be a serious schism, from my outside perspective it seems along the lines of something that would lead to a fork or separation between the projects.

I also just read more context on the thread and it seems like Damien Miller is in there saying much the same thing as Theo. He wrote:

> ... use of AI-written code now [will] expose us to legal risk.

This was in the context of a contribution to add (IIRC) ext4 filesystem support to OpenBSD. In this case, I was worried that the AI was just regurgitating code that was in its training corpus because how many ext4 implementations are there?

I think AI generated bugfixes and smaller features that don't duplicate fairly unique pieces of work in other projects are much less problematic from a copyright perspective at least.

The AI boosters should look for evidence that they do allow AI contributions! Why would they mention in the release notes that AI security bug reports are welcome if they allowed AI in general anyway?

They plainly, explicitly welcome it:

"Recently the OpenSSH team have received a large number of security bug reports, many of which are findings from AI models or made with AI assistance. While many AI reports are determined not to have security impact when considered in the context of a realistic threat model, we very much welcome these reports, especially when combined with human triage, analysis, test-cases and particularly when accompanied by proposed fixes."

You need to understand that they have no choice.

Attackers are going to use AI models to find bugs or 0 days quicker than those without it and of course they will not report them.

So it only makes sense to allow it and accept (valid) AI reports from reputable security researchers to keep ahead before a bug gets exploited in a vulnerable release.

As long as the submitter shows their understanding of the reported bug means and what the change is, it is fine to do so, with the reviewers gating invalid reports.

> so using AI like ASAN etc. is welcome.

AddressSanitizer is not "AI", nor does it use AI. [0]

[0] https://static.googleusercontent.com/media/research.google.c...

Yeah, I'd rather a secure OpenSSH than an AI free one. I appreciate users taking stands and drawing hard lines in the sand, but I think exemptions for large foundations of networking in general should be made, as like you said, threat actors don't care much about AI assistance and will happily use any 0-days it finds.

If you need to make exemptions for critical code because you must admit that AI is undeniably of significant utility, it's pretty foolish to still apply a blanket "hard stand" against it elsewhere.

AI is here, and it's not going anywhere. It's not going to be pretty, but the people that are going to be hit the hardest are those who cannot -- or worse, refuse to -- adapt.

I'm sympathetic -- I feel both a loss and an existential dread. I've also never, in my 30 years in my field, seen something sweep the technology space so quickly and change things so much overnight, and I see no chance of it stopping anytime soon.

I agree with you, but I can also understand the perspective of someone who thinks, (pulling this example out of my ass) that using LLMs to review if your AAA game is 'un-cheatable' may be a misappropriate of the resources required to do so.

I'm just vouching for, at a minimum, a general acceptance of LLM security audits for 'critical infrastructure' (OpenSSH, Apache, Electron, etc.) These have become bastions of the internet as we know them today and security issues that exist in these could be disastrous. It seems like LLMs have become really good at this sort of audit specifically, but maybe that's all marketing. If you are to believe the hype, though, it seems irresponsible to not be securing these such softwares with whatever tools are available...LLMs, contracted experts, bug bounties....throw it all at the wall and see what sticks.

Obviously, something like OpenBSD (OpenSSH devs) is a non-profit, and may have trouble finding the funds for the tokens for regular audits, but that's another discussion.

I'm not a native speaker, but in other languages the cited text clearly means "using AI in the manner of ASAN or similar tools".

I am a native speaker and that is how I read it as well.

Why is AI assistance not welcome?

Am I crazy to think this title is just incorrect? They say AI reports are welcome, not fixes.

They say AI reports are welcome, especially when corroborated by human triage, and/or when accompanied by fixes (unconstrained by any adjective, eg human or otherwise).

That was sloppy work on my part. Updated.

If you still have the ability to edit it, looks like there's a typo in the word "assistance"

It's just not my day.

"AI assistance" is still not welcome in general. AI security reports are.

Is that the case? I see this note focusing on AI reports in the release notes, and I've poked around the OpenSSH project more generally and don't see any indication that they don't accept or welcome other AI inputs.

I'm a terrible typist, so I can't criticize. Lately I've noticed I end up needing to edit what seems to be the majority of my comments because I notice typos shortly after posting them. Hopefully this comment isn't one of them!

Wow... What have they done to that webpage to make it that unreadable?

And why?

Ouch.

Reply on news.ycombinator.com