openssh and backwards compatibility

[Mike Frysinger]

the latest openssh (6.8, not yet in our tree) makes openssl support optional.  this is pretty nice:

 - smaller attack surface

 - smaller install size (drops 300k in openssh)

 - one fewer dep on openssl

the trade off is backwards compatibility.  w/out openssl, support for rsa/dsa/ecdsa is gone.  only the new ed25519 keys are supported.  these were first added to openssh-6.5 (our tree is out 6.6).  it would mean our test keys would need updating, and anything relying on rsa keys explicitly.

what else can people think of in our system would be impacted ?

-mike

[Ted Lemon]

Is what will be impacted the only issue? I would think that the other issue is that there is no fallback cipher if ed25519 turns out to have issues. Otherwise this sounds great. :}

[Richard Barnette]

On 4/29/15 12:29 AM, Mike Frysinger wrote:
> the latest openssh (6.8, not yet in our tree) makes openssl support
> optional. this is pretty nice:
> - smaller attack surface
> - smaller install size (drops 300k in openssh)
> - one fewer dep on openssl
>
> the trade off is backwards compatibility. w/out openssl, support for
> rsa/dsa/ecdsa is gone. only the new ed25519 keys are supported. these
> were first added to openssh-6.5 (our tree is out 6.6). it would mean
> our test keys would need updating, and anything relying on rsa keys
> explicitly.
>

Regarding the need to update the test keys: Isn't it more than
that? Specifically, won't this mean that any client that talks
to a device over ssh will need openssh-6.5 or later?

I checked the client systems I use most often; they're at 6.6.
However, I can imagine that there'll be users who aren't there
yet, and aren't prepared to upgrade.

I'll note that updating our test keys is itself a tricky business,
not to be undertaken lightly.

> what else can people think of in our system would be impacted ?
> -mike
>

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

--
--jrb

[Mike Frysinger]

On Thu, Apr 30, 2015 at 12:31 AM, Richard Barnette <jrbar...@chromium.org> wrote:

On 4/29/15 12:29 AM, Mike Frysinger wrote:

the latest openssh (6.8, not yet in our tree) makes openssl support
optional.  this is pretty nice:
  - smaller attack surface
  - smaller install size (drops 300k in openssh)
  - one fewer dep on openssl

the trade off is backwards compatibility.  w/out openssl, support for
rsa/dsa/ecdsa is gone.  only the new ed25519 keys are supported.  these
were first added to openssh-6.5 (our tree is out 6.6).  it would mean
our test keys would need updating, and anything relying on rsa keys
explicitly.

Regarding the need to update the test keys:  Isn't it more than
that?  Specifically, won't this mean that any client that talks
to a device over ssh will need openssh-6.5 or later?

true, since the server only supports ed25519 to establish the secure connection, the client must also understand that format.  this is orthogonal to the client keys which are used to authenticate the user.

I checked the client systems I use most often; they're at 6.6.
However, I can imagine that there'll be users who aren't there
yet, and aren't prepared to upgrade.

that's unfortunate for them then ?  we officially support Ubuntu Trusty only and that includes 6.6.  Precise is at 5.9.  if they really want to use an old system, the ssh client inside of the chroot will always be up-to-date.

I'll note that updating our test keys is itself a tricky business,
not to be undertaken lightly.

we're already discussing how to do that, and in an automated fashion

-mike

[Richard Barnette]

On 4/30/15 12:13 AM, Mike Frysinger wrote:
> On Thu, Apr 30, 2015 at 12:31 AM, Richard Barnette

[ ... ]

> I checked the client systems I use most often; they're at 6.6.
> However, I can imagine that there'll be users who aren't there
> yet, and aren't prepared to upgrade.
>
>
> that's unfortunate for them then ? we officially support Ubuntu Trusty
> only and that includes 6.6. Precise is at 5.9. if they really want to
> use an old system, the ssh client inside of the chroot will always be
> up-to-date.
>

Where misfortune falls depends on who the user is...
An important enough user could hold us up. That said, I
think in this case users with out-of-date clients can be
managed.

> I'll note that updating our test keys is itself a tricky business,
> not to be undertaken lightly.
>
>
> we're already discussing how to do that, and in an automated fashion

Ah. You'll probably want to include someone from the Lab
team in the discussion earlier rather than later.


> -mike

--
--jrb

[William Wraith IV]

I use Chromebooks in developer mode with verified boot and use ssh, ssh-agent, and occasionally the openvpn client to access linux servers in various places. I'm wondering if this change would affect me? I'm a little confused as to whether this issue only affects remote access into a Chromebook, or would also affect outgoing ssh client use, as well.

I realize I should be able to use crouton with trusty (I verified ed25519 keys work with ssh version 6.6 using trusty and crouton), but I have found that with just the ssh client and ssh agent and a few tweaks to openvpn, the Chromebook is a great box for accessing remote linux servers without having to maintain a crouton chroot.

I don't know if my use case is common or one that you would take into consideration but thought I'd ask the question, as it sounds like I'll need to figure out workarounds for a number of situations if only ed25519 keys will work with Chromebook in developer mode. For example, for servers on Amazon, the amzn distro is at 6.2. Fedora 20 is at 6.4. I did update one fedora server I have to Fedora 21, and it works fine with ed25519 keys. However, upgrading is not as easy in all my cases.

Also wondering if the openssl command would be available from developer mode by default or just not used by openssh. If openssl will not be available by default, would it be installable via dev_install?

Thanks for any clarification or advice.

[Mike Frysinger]

the thread is on the infra list, or you can just follow brbug.com/965 now

-mike

[Mike Frysinger]

yes, it would affect people running `ssh` on their local chromebook -- they could only connect to newer systems running openssh

we have a SecureShell extension already that provides full compatibility and is generally the recommended approach for sshing out of the device

`openssl` itself will still be on the device as other packages depend on it currently.  even if it were to go away, i imagine we'd make it available via `dev_install`.

-mike

[Richard Barnette]

On 4/30/15 5:25 PM, Mike Frysinger wrote:
> the thread is on the infra list, or you can just follow brbug.com/965

> <http://brbug.com/965> now

Yeah, I've been catching up on my e-mail, and found the discussion.

I've updated the bug with the caveats that I know about.

--
--jrb

[William Wraith IV]

I've used Secure Shell extension a fair amount in the past, and it works well for individual server access, but the absence of ssh-agent and agent forwarding always brings me back to ssh in development mode shell. However, I'll get in the habit of making crouton my "linux connectivity toolbox" in the hopes backward compatibility will still work there even if the built in version drops openssl support.

I guess this is pie in the sky, but it would be great to have a normal user mode application that provides an isolated, encrypted, secure "linux connectivity shell/toolbox" that doesn't compromise the security design of user mode Chromebook.

[Mike Frysinger]

to clarify, this isn't a change i'm looking at making now.  we first have to update to 6.8 (although that in and of itself isn't difficult).  we also need to resolve the testing key generation aspect (brbug.com/965) first which most likely will be a few months.  only then could we consider making this change.  at which point we're most likely thinking Q1 2016 in which case a lot more distros will have updated.  and maybe we'll get lucky and the OpenSSH guys will add non-ssl implementations for more common key formats (like RSA).

something that will happen sooner though is dropping of SSH1 support entirely (when 6.8 lands), although i suspect no one will care (as it's already been disabled in our servers via config options).

-mike