Live data from Hacker News

OpenSSH 8.2

lists.mindrot.org

41–50 of 61 posts

Re: OpenSSH 8.2

#41

Earlier quoted context omitted.

No harm in it either though. Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.

What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.

My instinct is that's actually safer than a "set your password and open SSH to the world" step.

Re: OpenSSH 8.2

#42
As a (very) longtime user of SSH, are there any features in (relatively) newer releases that have changed peoples lives?

Last year I switched over to using signed SSH host keys, and for my fleet of ~150 VMs, some of which respin on a nightly basis, this has been a game changer. No longer do I need to keep a master "known_hosts" file updated and distributed across the fleet.

Re: OpenSSH 8.2

#43

Earlier quoted context omitted.

No harm in it either though. Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.

What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.

A cronjob on every one of my IoT crap devices, which sometimes stay stuffed in a shoebox without internet for years:

    @reboot root ssh-import-id gh:my-username
That way when I want to tinker with one, it will pull down my newest GitHub once it reboots and I’ll be able to login. The GitHub key is always up to date.

Re: OpenSSH 8.2

#44

Earlier quoted context omitted.

Sure. Consider the Web PKI ("SSL Certificates"). Suppose you have a web site pmf.example it is of course pretty easy to get yourself a certificate to make https://pmf.example/ work, today for free but even many years ago it was pretty affordable from several commercial vendors. The way those certificates work is they use a digital signature based on a hash algorithm, the CA uses its private key to sign the hash, and…

Very enlightening. Thank you for explaining this. Are there any resources you might recommend to someone looking to learn this stuff more in depth?

Ange Albertini's work on collisions is pretty great and he makes lots of example images and illustrations.

https://corkami.github.io/

In particular he works on/with the PoC||GTFO team and is responsible for the MD5 collision cover art in a past issue:

https://github.com/angea/pocorgtfo

For SHA-1 (and others) you might find more at his github project:

https://github.com/corkami/collisions

hth,

adric

Re: OpenSSH 8.2

#45
post #2

Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

Can this be more simply achieved using the "KexAlgorithms" and "MACs" config settings for /etc/ssh/sshd_config and ~/.ssh/config ?

Re: OpenSSH 8.2

#46
post #2

Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

Oh deer, perhaps someone at Microsoft DevOps should be told. https://developercommunity.visualstudio.com/idea/365980/supp...

This is not about RSA keys - they're still fine.

See https://news.ycombinator.com/item?id=22324492 and https://news.ycombinator.com/item?id=22324535

Re: OpenSSH 8.2

#47

Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).

I'm happy to see this, however I'd be far more excited if I thought there was a chance of it landing in the upcoming Ubuntu 20.04 release - else I'll likely be waiting impatiently until 22.04 for server-side support.

Likewise, I would be glad to see it in 20.04. According to this page, https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule, feature freeze for 20.04 is on the 27th of February so I don't see any reason why Openssh 8.2 can't make it into the LTS. Unless there are other considerations I'm not aware of.

Re: OpenSSH 8.2

#48

Notable in this release is support for generating and using keys backed by FIDO/U2F tokens (and, with supported tokens, keys fully resident in FIDO/U2F tokens that you can transport between computers).

Does anyone know whether what was raised in https://news.ycombinator.com/item?id=21419015 was addressed, as the thread didn't get updated?

Re: OpenSSH 8.2

#49
post #4
post #2

Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.

github also appears to only have RSA and DSA host keys, the latter is already deprecated

Re: OpenSSH 8.2

#50

Earlier quoted context omitted.

No harm in it either though. Unless for some reason someone imports one into their authorized_keys (which presumably would require deliberate steps not random numbskullary) in which case there is a (low) risk as they have just given a dev access to an account said dev does not know exists.

What you described is quite literally a feature in Ubuntu Server. Type in a github username during the installer to import from github.com/%s.keys to /root/.ssh/authorized_keys.

> Type in a github username

Exactly. That would be the deliberate steps I mentioned as a gate for this causing a problem. If you give it someone else's key you have a problem, though a minor one unless you've been conned into doing so by an adversary who will later scan for accounts that allow their key pair for auth.

Importing your own public key this way is not problematical at all.

Of course you might end up with people publishing their private key along with the private one, by error or because it seems convenient & they don't think things through...

Post reply on HN