5 ms·

OpenSSH 7.4 released

118 points by nnx 10y ago

erelde 10y ago
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)
- diggan 10y ago
  https works as well: https://www.openssh.com/txt/release-7.4 https://www.openssh.com/txt/release-7.4 Maybe submitter here on HN just put http. Would be better if it did the redirect automatically though.
  - erelde 10y ago
    Yes it would certainly be better :) Thank you, I didn't think to manually check as I assumed it would have redirected me.
    - Tepix 10y ago
      It does redirect for me, thanks to HTTPS everywhere ;-)
  - aargh_aargh 10y ago
    Observation: their CA is Let's Encrypt
  - MrRadar 10y ago
    Their TLS configuration is very strict. Only TLS 1.2 with only ECDHE + ChaCha20 or AES-GCM cipher suites. A lot of clients can't talk to it (including IE 11 on Windows 7 and 8), so it makes sense that they still offer non-encrypted connections: https://www.ssllabs.com/ssltest/analyze.html?d=openssh.com https://www.ssllabs.com/ssltest/analyze.html?d=openssh.com.
- rahrahrah 10y ago
  It would be if you were using HTTPS Everywhere.
  - erelde 10y ago
    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)
    - bandrami 10y ago
      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.
    - rahrahrah 10y ago
      You should use HTTPS Everywhere everywhere.
- Esau 10y ago
  Not directed at you personally - but I wish people would stop fetishizing https. Not everything needs to be encrypted.
  - quesera 10y ago
    Everything needs to be encrypted.
  - aaronmdjones 10y ago
    HTTPS is about more than just confidentiality (encryption), though. There's also authentication (the party serving the traffic to you is the party you asked for) and integrity (the traffic has not been modified since it was sent). This prevents all kinds of undesirable behaviour; like your ISP injecting JavaScript ads into the webpages you view. Confidentiality is just a nice little side-benefit.
Tepix 10y ago
It's good to see support for obsolete features and weak crypto being removed. Does anyone know why there is no support for Curve448 being added? There is a draft RFC at https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-00 https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-00 describing this, together with SHA-512. Previous versions of OpenSSH have already supported the privately defined "curve25519-sha256@libssh.org" key exchange protocol.
newman314 10y ago
Openssh is one of the pieces of software that I would argue needs to be kept up to the latest and greatest regardless of the original version shipped by the distro. I would similarly push for latest version of OpenSSL but that's harder to get right.
- Fnoord 10y ago
  Right now distros who backport, such as Debian, need to very carefully read changelogs and decide what and what not to backport. Quite a daunting task.
  - newman314 10y ago
    I get that. My argument is for a small subset of software tools, to be considered to be sufficiently critical that updates are prioritized because compromise of said tools would have outsized consequences.
Bugseverywhere 10y ago
Nice
spudlyo 10y ago
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 https://bugzilla.mindrot.org/show_bug.cgi?id=1424 [1]: https://github.com/spudlyo/metassh https://github.com/spudlyo/metassh
- drvdevd 10y ago
  I mostly jumped to the bottom of the bug discussion thread there, but there doesn't seem to be much opposition to adding this, just comments deferring this to other releases. Are they just requesting that patch submitters do some extra work to get it in there?
  - spudlyo 10y ago
    I think they've been wanting to get this patch into OpenSSH for years, but for whatever reasons it just never happened. I assumed it was a community patch, but it was actually written by Darren Tucker, who is an OpenSSH dev. There was some conversation about if it was appropriate to pass on certain signals, but that's about it. After Darren cleaned up some client UI issues that bugged him, he even suggested that we might see the patch in 5.4.
bandrami 10y ago
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.
- slasaus 10y ago
  > 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.
  - xoa 10y ago
    I disagree with bandrami in this case, but I don't think this is quite right either because you focused on an instance-specific goal rather then universal principle: >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. There is plenty of software where secure usage is not a concern and that's fine. Rather, it would be better to say that as programmers we have the job to ensure that our software is as fit for primary expected purpose as possible, and in particularly lacks any surprising gotchas. Sometimes within a given program's core purpose there are decisions that can only be properly made as part of deployment/usage and those are appropriately left to the sysadmin/user, but if something is directly contrary to core purpose then it's always worth questioning whether it needs to change. In the case of OpenSSH in particular the core purpose is in fact secure links. We've all long had an insecure very fast virtual terminal system if we wanted it and it's called Telnet. There is no reason that any available built-in mode of OpenSSH crypto should ever be insecure. Asking to have obsolete methods generally considered to no longer be reliable to be "left up to the sysadmin" would be like asking it to have rot13 as a sysadmin option: completely contrary to the purpose and expected function of the program. Not just in security but in software in general any extra switches carry both developmental load (more code to go wrong), deployment load (more possibilities to make mistakes) and cognitive load, so they should always be considered to have inherent negative value and then asked to justify themselves, not considered to stick around forever by default.
rahrahrah 10y ago
Hey guys, crypto-noob here. Who needs this? I have a ssh server on my ubuntu, do I need to update OpenSSH? Also, I have openssl installed (for some reason), is that the same thing?
- djmdjm 10y ago
  The ssh server on your Ubuntu machine is probably OpenSSH. If you're keeping your machine up to date with Ubuntu's security updates then you can let them take care of it. OpenSSL is separate software, but it provides a cryptography library that OpenSSH (usually) uses. You will need it installed.
  - rahrahrah 10y ago
    It's unfortunate timing that just today I got the message that I could no long get updates for Ubuntu 15, and pressing me to update to Ubuntu 16
    - angry-hacker 10y ago
      Research about Ubuntu (or any distribution) long term releases (LTS) to avoid that situation in the future :)
      - rahrahrah 10y ago
        TY

118 points by nnx 10y ago

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)

diggan 10y ago
https works as well: https://www.openssh.com/txt/release-7.4 https://www.openssh.com/txt/release-7.4 Maybe submitter here on HN just put http. Would be better if it did the redirect automatically though.
- erelde 10y ago
  Yes it would certainly be better :) Thank you, I didn't think to manually check as I assumed it would have redirected me.
  - Tepix 10y ago
    It does redirect for me, thanks to HTTPS everywhere ;-)
- aargh_aargh 10y ago
  Observation: their CA is Let's Encrypt
- MrRadar 10y ago
  Their TLS configuration is very strict. Only TLS 1.2 with only ECDHE + ChaCha20 or AES-GCM cipher suites. A lot of clients can't talk to it (including IE 11 on Windows 7 and 8), so it makes sense that they still offer non-encrypted connections: https://www.ssllabs.com/ssltest/analyze.html?d=openssh.com https://www.ssllabs.com/ssltest/analyze.html?d=openssh.com.
rahrahrah 10y ago
It would be if you were using HTTPS Everywhere.
- erelde 10y ago
  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)
  - bandrami 10y ago
    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.
  - rahrahrah 10y ago
    You should use HTTPS Everywhere everywhere.
Esau 10y ago
Not directed at you personally - but I wish people would stop fetishizing https. Not everything needs to be encrypted.
- quesera 10y ago
  Everything needs to be encrypted.
- aaronmdjones 10y ago
  HTTPS is about more than just confidentiality (encryption), though. There's also authentication (the party serving the traffic to you is the party you asked for) and integrity (the traffic has not been modified since it was sent). This prevents all kinds of undesirable behaviour; like your ISP injecting JavaScript ads into the webpages you view. Confidentiality is just a nice little side-benefit.

Tepix 10y ago

It's good to see support for obsolete features and weak crypto being removed. Does anyone know why there is no support for Curve448 being added? There is a draft RFC at https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-00 https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-00 describing this, together with SHA-512. Previous versions of OpenSSH have already supported the privately defined "curve25519-sha256@libssh.org" key exchange protocol.

newman314 10y ago

Openssh is one of the pieces of software that I would argue needs to be kept up to the latest and greatest regardless of the original version shipped by the distro. I would similarly push for latest version of OpenSSL but that's harder to get right.

Fnoord 10y ago
Right now distros who backport, such as Debian, need to very carefully read changelogs and decide what and what not to backport. Quite a daunting task.
- newman314 10y ago
  I get that. My argument is for a small subset of software tools, to be considered to be sufficiently critical that updates are prioritized because compromise of said tools would have outsized consequences.

Bugseverywhere 10y ago

Nice

spudlyo 10y ago

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 https://bugzilla.mindrot.org/show_bug.cgi?id=1424 [1]: https://github.com/spudlyo/metassh https://github.com/spudlyo/metassh

drvdevd 10y ago
I mostly jumped to the bottom of the bug discussion thread there, but there doesn't seem to be much opposition to adding this, just comments deferring this to other releases. Are they just requesting that patch submitters do some extra work to get it in there?
- spudlyo 10y ago
  I think they've been wanting to get this patch into OpenSSH for years, but for whatever reasons it just never happened. I assumed it was a community patch, but it was actually written by Darren Tucker, who is an OpenSSH dev. There was some conversation about if it was appropriate to pass on certain signals, but that's about it. After Darren cleaned up some client UI issues that bugged him, he even suggested that we might see the patch in 5.4.

bandrami 10y ago

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.

slasaus 10y ago
> 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.
- xoa 10y ago
  I disagree with bandrami in this case, but I don't think this is quite right either because you focused on an instance-specific goal rather then universal principle: >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. There is plenty of software where secure usage is not a concern and that's fine. Rather, it would be better to say that as programmers we have the job to ensure that our software is as fit for primary expected purpose as possible, and in particularly lacks any surprising gotchas. Sometimes within a given program's core purpose there are decisions that can only be properly made as part of deployment/usage and those are appropriately left to the sysadmin/user, but if something is directly contrary to core purpose then it's always worth questioning whether it needs to change. In the case of OpenSSH in particular the core purpose is in fact secure links. We've all long had an insecure very fast virtual terminal system if we wanted it and it's called Telnet. There is no reason that any available built-in mode of OpenSSH crypto should ever be insecure. Asking to have obsolete methods generally considered to no longer be reliable to be "left up to the sysadmin" would be like asking it to have rot13 as a sysadmin option: completely contrary to the purpose and expected function of the program. Not just in security but in software in general any extra switches carry both developmental load (more code to go wrong), deployment load (more possibilities to make mistakes) and cognitive load, so they should always be considered to have inherent negative value and then asked to justify themselves, not considered to stick around forever by default.

rahrahrah 10y ago

Hey guys, crypto-noob here. Who needs this? I have a ssh server on my ubuntu, do I need to update OpenSSH? Also, I have openssl installed (for some reason), is that the same thing?

djmdjm 10y ago
The ssh server on your Ubuntu machine is probably OpenSSH. If you're keeping your machine up to date with Ubuntu's security updates then you can let them take care of it. OpenSSL is separate software, but it provides a cryptography library that OpenSSH (usually) uses. You will need it installed.
- rahrahrah 10y ago
  It's unfortunate timing that just today I got the message that I could no long get updates for Ubuntu 15, and pressing me to update to Ubuntu 16
  - angry-hacker 10y ago
    Research about Ubuntu (or any distribution) long term releases (LTS) to avoid that situation in the future :)
    - rahrahrah 10y ago
      TY