
Call for testing: OpenSSH 8.0 - lelf
https://lists.mindrot.org/pipermail/openssh-unix-dev/2019-March/037672.html
======
segfaultbuserr
It includes an interesting comment on the scp vulnerability.

> This release contains mitigation for a weakness in the scp(1) tool and
> protocol (CVE-2019-6111) [...] _The scp protocol is outdated, inflexible and
> not readily fixed. We recommend the use of more modern protocols like sftp
> and rsync for file transfer instead._

I think it's the time to "alias scp=sftp". If the developers officially
believe that scp should be retired, let's do the switch. Both are parts of
OpenSSH and the commandline argument is almost identical.

Also, it has

> _ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange
> method, based on a combination of Streamlined NTRU Prime 4591^761 and
> X25519._

This is big. Together with XMSS signature, it means we already have a complete
suite of post-quantum cryptography (experimentally) deployed in OpenSSH! It
may be the first mass deployment of post-quantum cryptography in a major
protocol.

One month ago, I commented that the introduction of XMSS post-quantum
signature as "useless"
([https://news.ycombinator.com/item?id=19160739](https://news.ycombinator.com/item?id=19160739)),
as the decryption of key exchange is much more vulnerable than spoofing the
signature. But now NTRU+X25519 is deployed, great progress here!

~~~
MayeulC
Frankly, I had not realized scp and sftp were two distinct protocols, despite
my heavily using them. I thought sftp was an interactive client, while scp was
meant for scripting, and never really bothered to dig further. I now will,
thank you.

However, I expect plenty of people to be in the same case.

~~~
pletnes
Some servers, and some clients, only support one of them. I’ve run into
servers without sftp and subsequently stopped using it, as scp always works.

Also rsync does not exist on windows, for instance git bash has only scp
AFAIK.

~~~
0xfeba
A while ago I tried making windows' remote differential compression COM
library work in a CLI utility like rsync.

[https://docs.microsoft.com/en-us/previous-
versions/windows/d...](https://docs.microsoft.com/en-us/previous-
versions/windows/desktop/rdc/remote-differential-compression)

------
ggm
Recommending rsync as a more 'modern' replacement for SCP made me smile. Rsync
is .. idosyncratic and documented by a single codebase (not withstanding the
fine work OpenBSD people have done writing their own rsync)

~~~
johnchristopher
My pet peeve grief with rsync is that I have to double check the man page for
the trailing slash rule every time I use it. Otherwise I love it.

~~~
mcbain
My shell history is sure to show every use of ‘rsync <whatever>’ to be
preceded by ‘rsync -n <whatever>’ to make sure I have the paths correct.

------
cnorthwood
Interesting that they seem to use CVS as the canonical source control repo. I
wonder what the workflows of the dev team look like and if that tool makes it
harder for external contributors to contribute?

~~~
geocar
> and if that tool makes it harder for external contributors to contribute?

I hope so!

OpenSSH is a critical piece of infrastructure in most unix and linux
environments, so making sure external contributors do some extra diligence
seems like a good thing!

~~~
geofft
Learning CVS is not "diligence." If anything, it takes up mental space you
could be using on things like remembering to bounds-check your array accesses.

Asking contributors to learn CVS as a quality gate is like having a tech
interview process that requires beating the hiring manager at chess. Sure,
you're looking for smart people, and sure, people good at chess are usually
smart, but the correlation is so low you'll lose out on good candidates and
get candidates who are better at chess than coding.

~~~
djmdjm
We don't ask anyone to learn CVS. People send the maintainers (myself and
other) their changes (git format-patch is fine) and we integrate them.

~~~
geofft
Yeah, to be clear I think you the OpenSSH maintainers are quite responsive to
people who aren't using CVS (in particular, thank you for digging into
[https://bugzilla.mindrot.org/show_bug.cgi?id=2863](https://bugzilla.mindrot.org/show_bug.cgi?id=2863)
which didn't even have a patch!). I just want to be clear that people who look
at what you're doing and say "OpenSSH is using an obscure process, that's what
makes it high-quality" are misguided and should not implement such policies in
their own products. It's not what you're doing, and if it were, it wouldn't
work.

------
moreentropy
Would love to see FIDO2 / Webauthn in SSH. Working with PKI tokens for key
auth works but has to be set up in the client.

~~~
tialaramex
As I understand it using FIDO (including FIDO2) for SSH requires some pretty
heavy lifting at the protocol layer.

FIDO tokens only want to do two things: Provide you with a cookie and a public
key, then later as often as necessary take a cookie and give you proof they
still know the associated private key. Very narrowly conceived, on purpose.

SSH public key auth has the client start by proposing "OK, I can prove I know
key X" and then the server either says "Fine, do that then" or "No, what else
do you have?". An out of box OpenSSH server decides which to do by examining
the ~/.ssh/authorized_keys file. A FIDO token needs the _server_ to begin by
saying "OK, here's a cookie, can you prove you know the corresponding private
key?" so that it can get the cookie, otherwise it can't prove anything.

------
tabletopneedle
I was able to install the software, but there is no documentation about how to
create NTRU+X25519 keys and enable it. I checked manpages, mailing list and
tried google. How is this done?

~~~
shawnz
It looks like its a key exchange algorithm, not a host key algorithm. So you
don't make keys with it, you just tell your client and server to try using it
when connecting. You can specify it with the KexAlgorithms config property,
like for example ssh -o "KexAlgorithms=whatever". Use ssh -Q kex to see what
options are available on your installation.

~~~
tabletopneedle
Thank you!

So to help everyone (read whole post first), you should probably have the line

KexAlgorithms
sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256@libssh.org,diffie-
hellman-group-exchange-sha256

in /etc/ssh/sshd_config of server and /etc/ssh/ssh_config of client (under
"Host _" ).

(The rest of the kex recommendations are from
[https://stribika.github.io/2015/01/04/secure-secure-
shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html))

\---

However, for some reason after running "/usr/sbin/sshd -T" it said

"/etc/ssh/sshd_config line 2: Bad SSH2 KexAlgorithms
'sntrup4591761x25519-sha512@tinyssh.org'."

so I played around. It's hard for me to go back on everything I tried but a
working solution seemed to be to add the

KexAlgorithms
sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256@libssh.org,diffie-
hellman-group-exchange-sha256

line to server's "/usr/local/etc/sshd_config" and to client's
"/usr/local/etc/ssh_config" under "Host _".

You then need to start the server by running "sudo /usr/local/sbin/sshd" and
you need to use the ssh client with the binary "/usr/local/bin/ssh".

------
MayeulC
As I see a new release, I wish OpenSSH would conform to the XDG base directory
specification. I do not agree with the proposed rationale [1]

On a side note, I lost the list of applications that are not conforming to it.
I know there are a couple, and would be glad if you were to share the ones you
know about.

[1]:
[http://bugzilla.mindrot.org/show_bug.cgi?id=2050](http://bugzilla.mindrot.org/show_bug.cgi?id=2050)

~~~
upofadown
The rationale _is_ pretty strong though:

>OpenSSH (and it's ancestor ssh-1.x) have a 17 year history of using ~/.ssh.
This location is baked into innumerable users' brains, millions of happily
working configurations and countless tools.

XDG can be considered as a case of arbitrary change for weak justification.
SSH is definitely a case where people need to know exactly where the
configuration is. There is no point in including it in the not very fun "find
the config files" game engendered by XDG.

~~~
MayeulC
I agree on security issues, and making the path depend on an environment
variable/per-user config file would be opening a new can of worms.

However, an issue I have is that while you can configure that path system-
wide, there is no way to control it per-user, or with a finer-gained approach.
You can probably use mount namespaces to shadow a ~/.ssh with another config,
but that seems overkill.

I admit I have no practical use cases for this right now (though I probably
did in the past) besides "uncluttering $HOME". As for hunting the config
files, those would reside in ~/.config/ssh by default. I personally find it
more irritating when a program picks a random folder instead of conforming to
the spec (and if I set the environment variable to somewhere else, I then know
where it is). Go hunt trough
~/{.program,.program/conf,Program/conf,Documents/Program/conf,Documents/My\
Games/conf}, or countless variants I experienced. Thought it is admittedly a
much smaller problem with better-established programs such as openssh.

------
gchamonlive
It would sure help encourage testing if we could have it on AUR for easy
installation on arch distros.

------
nn3
Updating openssh has been a frustrating experience recently because of their
constant breaking of old clients.

I hope this one doesn't continue this worrying tendency.

~~~
danielhlockard
Old clients are typically broken because of security issues, or fun stuff like
disabling SSH 1 protocol.

If your clients are broken, they should be updated.

~~~
nn3
You are right of course. If nothing works anymore that is by definition most
secure.

~~~
danielhlockard
That's not at all what I said.

~~~
chasil
It is widely acknowledged that hmac-md5 remains secure (if deprecated).

There is no problem using aes128-ctr as far as I know.

Finally, diffie-hellman-group14-sha1 is not ideal, but breaking sha1 requires
vast resources.

An sshd allowing these settings can talk to very, very old versions, and the
CPU usage of these is light compared to some of the more modern
configurations.

I do have systems that are sensitive to CPU usage, and I retain these settings
there, where I am less concerned about ultimate protocol security, and more
focused on performance and a light footprint.

