LWN: Comments on "OpenSSH 7.5 released"

OpenSSH 7.5 released

akostadinov — Mon, 07 Aug 2017 05:17:13 +0000

https://lists.mindrot.org/pipermail/openssh-unix-dev/2017...
https://lists.mindrot.org/pipermail/openssh-unix-dev/2017...

It looks like container use cases and running as unprivileged user will continue to be supported going forward. Just not as a single process with the old option.

OpenSSH 7.5 released

nix — Wed, 29 Mar 2017 14:03:23 +0000

sftp is just a filter (on both sides). Literally: stdin-to-stdout. sshd invokes the server side via the subsystem mechanism, but it is just a filter.

There is thus no need for another implementation (unless you want to extend or intercept it, of course, perhaps to provide sftp of something other than the filesystem): any library sshd implementation can invoke sftp-server in the same way sshd does.

OpenSSH 7.5 released

lsl — Fri, 24 Mar 2017 17:27:46 +0000

And as long as that interface is kept stable and doesn't exceed a certain threshold of complexity, this is totally fine. Calling out to ssh(1) also has the benefit of honoring local user configuration by default which is really nice.

OpenSSH 7.5 released

flussence — Fri, 24 Mar 2017 00:25:54 +0000

I hear similar complaints about GPG. The official stance AFAICT seems to be that its weird interactions with stdio *are* the library API.

OpenSSH 7.5 released

ibukanov — Tue, 21 Mar 2017 10:48:42 +0000

The things is that to use privilege separation as implemented in sshd the daemon itself has to have elevated privileges. In container applications one may want to avoid that. Surely it increases a chance of exploiting a ssh bug, but it also decreases a chance of container escape, a much greater worry.

OpenSSH 7.5 released

joib — Tue, 21 Mar 2017 10:18:46 +0000

From the horses mouth when a similar complaint was aired after the openssh 7.4 release: https://news.ycombinator.com/item?id=13213174

OpenSSH 7.5 released

NAR — Tue, 21 Mar 2017 10:16:16 +0000

There's an ssh application Erlang/OTP.

OpenSSH 7.5 released

njs — Tue, 21 Mar 2017 06:03:37 +0000

In Python there's twisted.conch and paramiko. I know at least at some point heroku was running all their git sessions through twisted.conch, so it's relatively serious.

OpenSSH 7.5 released

josh — Mon, 20 Mar 2017 20:59:42 +0000

I've also seen Thrussh (https://pijul.org/thrussh/) for this, as well as the Java implementation used in Gerrit. I don't know much about their quality or completeness, though.

OpenSSH 7.5 released

ibukanov — Mon, 20 Mar 2017 20:48:36 +0000

There are already sshd and sftp libraries if one can use Golang. For C/C++ I do not expect to seen soon a library that can in few lines of code extends the app with ssh server functionality. Any such library will be inevitably tightly coupled with an event loop and there is no standard event loop for C/C++.

OpenSSH 7.5 released

tialaramex — Mon, 20 Mar 2017 20:40:10 +0000

I'd be comfortable seeing this removed from default configuration, but it isn't helpful to remove it altogether for the reason you gave.

If poor security choices can be negotiated (old cipher, old protocol version, small key size) ordinary users who have no reason to suspect they're vulnerable may be vulnerable without knowing it. For example a 768-bit RSA key is definitely within the reach of a powerful attacker, and you might be using one somewhere without even knowing it - you have a modern SSH so you feel safe, but you are not.

So it makes sense to identify weak choices and refuse them by default.

But there ought to be a way to configure it back in until it's seriously obsolete. Done well (ie without the various intermediaries fiddling with the settings) the end user has the opportunity to switch off these defences and take a calculated risk, even perhaps doing so only for one particular connection. I have SSH public keys disabled for a particular remote system for example because apparently their implementation doesn't understand the concept of "negotiation" and having offered SSH public keys as a means of authenticating, if it actually receives one it ignores subsequent correct authentications... I have no doubt that this is presented as a "security feature" as that seems to be to preferred designation for gross failures of standards compliance that interfere with interoperability these days when selling "enterprise" (ie low quality high price tag) software.

OpenSSH 7.5 released

josh — Mon, 20 Mar 2017 20:22:29 +0000

We really need a good implementation of sshd (and sftp) in library form, not just as a standalone server.

OpenSSH 7.5 released

josh — Mon, 20 Mar 2017 20:21:53 +0000

Have you reported the devices that don't support new ciphers to the OpenSSH folks? They indicated in the past that they wanted to hear from people who had to work with such devices, and that they planned to gauge the timelines for client-side deprecation based on whether they hear from people who need such ciphers client-side.

OpenSSH 7.5 released

pizza — Mon, 20 Mar 2017 19:50:57 +0000

Removing _client-side_ support for old ciphers and key sizes is a problem too, because many of us don't have the luxury of choosing what we connect to.

OpenSSH 7.5 released

ibukanov — Mon, 20 Mar 2017 18:06:04 +0000

Removal of UsePrivilegeSeparation=no makes sshd from OpenSSH unsuitable for some container applications when sshd itself runs as non-root in a very restricted container to provide, for example, authenticated file access.

I guess time to switch to other sshd implementations for those cases.