OpenSSH 7.4 released
11–20 of 43 posts
Re: OpenSSH 7.4 released
#12Why 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.
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"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.
Re: OpenSSH 7.4 released
#14Refusing 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
#15Earlier 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)
Re: OpenSSH 7.4 released
#16Hm. 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.
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
#17Hm. 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.
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
#18Hm. 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
#19Hm. 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
#20Hm. 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.