Live data from Hacker News

OpenSSH 7.4 released

openssh.com

11–20 of 43 posts

Re: OpenSSH 7.4 released

#12
post #2

Why isn't openssh.com served over https ? You'd think it would be, given where it comes from, who those people are and what it is. (tone: I'm just surprised)

It would be if you were using HTTPS Everywhere.

Weird thing is, I am in fact using it...

But their server should also redirect normal users.

EDIT: ah no, different computers. On my personal computers I have it, not on my workplace computer. (and my point remains, they should redirect traffic)

Re: OpenSSH 7.4 released

#13
I was saddened to read the release notes that state:

"OpenSSH is a 100% complete SSH protocol 2.0 implementation..."

This bug[0] calling out the fact that OpenSSH doesn't implement section 6.9 of RFC 4254 (which allows you to send signals to remote processes) has been open since 2008, complete with community submitted patches that implement that part of the protocol.

My recent pet Golang project[1] is a parallel remote command executor that uses OpenSSH, and I would really love the ability to better manage remote processes I execute via SSH.

[0]: https://bugzilla.mindrot.org/show_bug.cgi?id=1424

[1]: https://github.com/spudlyo/metassh

Re: OpenSSH 7.4 released

#14
Hm. That's more mechanism-as-policy than I like, e.g.:

Refusing all RSA keys smaller than 1024 bits

The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled

That's not really the sort of decision application programmers should be making for sysadmins.

Re: OpenSSH 7.4 released

#15
post #12

Earlier quoted context omitted.

It would be if you were using HTTPS Everywhere.

Weird thing is, I am in fact using it... But their server should also redirect normal users. EDIT: ah no, different computers. On my personal computers I have it, not on my workplace computer. (and my point remains, they should redirect traffic)

No, they should either serve the URL requested or refuse to do so. There are networks that do not allow TLS traffic, and clients that do not support it.

Re: OpenSSH 7.4 released

#16

Hm. That's more mechanism-as-policy than I like, e.g. : Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

> That's not really the sort of decision application programmers should be making for sysadmins.

As a programmer you have the right (or maybe even obligation?) to write secure software and I would argue software that's hard or impossible to use insecurely. It should live up to the standards of the time of release, not the time of the release of the first version (in case of OpenSSH that would be more than seventeen years ago).

As a sysadmin you can always decide to stick with an old version if that is what the environment you operate in demands.

I think this proactive mentality of OpenSSH is an important part of their success and why it has such a good track record from a security point of view.

Re: OpenSSH 7.4 released

#17

Hm. That's more mechanism-as-policy than I like, e.g. : Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

It's good that you have the source code so you can re-add/maintain the features you need, or can backport fixes to previous versions that have them implemented.

These changes are very good for the vast majority of users as they removes two big opportunities to silently shoot yourself in the foot.

Re: OpenSSH 7.4 released

#18

Hm. That's more mechanism-as-policy than I like, e.g. : Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

In principle I agree. Looking at the security patches there seems to be a few issues around this feature. My guess is that this feature is entering the "disable before retire" phase of its life.

Re: OpenSSH 7.4 released

#19

Hm. That's more mechanism-as-policy than I like, e.g. : Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

Unfortunately, sysadmins have resolutely refused to make the right choices, thus forcing the issue.

Re: OpenSSH 7.4 released

#20

Hm. That's more mechanism-as-policy than I like, e.g. : Refusing all RSA keys smaller than 1024 bits The next release of OpenSSH will remove support for running sshd(8) with privilege separation disabled That's not really the sort of decision application programmers should be making for sysadmins.

Unfortunately, sysadmins have resolutely refused to make the right choices, thus forcing the issue.

Since I bump back and fourth between sysadmin and programmer gigs, I don't get why a system admin wouldn't want a programmer to build their software with privilege separation? What am I missing? Having a secure system is a big deal for a system admin (these days the #1 deal), but at some point you have to rely on a programmer getting it right.
Post reply on HN