9 ms·

Call for testing: OpenSSH 8.0

179 points by lelf 8y ago

cnorthwood 8y ago
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 8y ago
  > 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!
  - brylie 8y ago
    It may be important not to confuse "diligence" for "encumbrance".
  - sneak 8y ago
    The willingness to jump through outmoded and unnecessary hoops does not correlate to the quality of one's cryptographic code. In fact, many who are deliberately diligent will shy away from teams who care more about tradition than quality, in my experience.
  - geofft 8y ago
    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 8y ago
      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 8y ago
        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.
- wibble10 8y ago
  It’s part of OpenBSD who can’t use git for licensing reasons and the switch from cvs->svn isn’t really worth it. There is a git mirror on github and you can work on that and submit diffs to the mailing list if you’re worried about having to read the cvs manpage ;)
  - avar 8y ago
    Let's make something clear: They can, and they use other GPL software in the base system. They just choose not to, for (as I understand it) a combination of reasons. Being averse to relying on new GPL code, being "happy enough" with CVS (also working on OpenCVS), and CVS being a little more than just source control for them due to the likes of CVSync[1]. I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it. 1. https://www.openbsd.org/cvsync.html https://www.openbsd.org/cvsync.html
    - Crinus 8y ago
      Aren't "patches in Git" just "patches"? Git can give you a patchfile that can be applied with "patch" regardless of VCS.
      - sneak 8y ago
        from GP: "I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it." I think he means he is a contributor to the source of `git` itself, and thus is justified in saying "we" in terms of not prohibiting OpenBSD's contributors from using the software he helps develop (git).
        avar 8y ago
        Correct. Thanks!
    - simias 8y ago
- djmdjm 8y ago
  For workflows, we have good tooling based around https://github.com/yasuoka/cvs2gitdump https://github.com/yasuoka/cvs2gitdump to convert OpenBSD CVS commits to git commits in a "pristine upstream" repository (https://github.com/djmdjm/openbsd-openssh-src https://github.com/djmdjm/openbsd-openssh-src) and merge them to the portable OpenSSH repository. Merging changes from OpenBSD to portable is usually completely painless and only a hassle when merging something really large (in LoC touched) like a refactoring. It would certainly be easier for external contributors (and us) if OpenBSD used git natively but as OpenBSD was AFAIK the first open source project to expose a CVS tree of their work to the world there's a lot of legacy to overcome.
- microcolonel 8y ago
  I know the process of using CVS has prevented me from making drive-by contributions to OpenBSD. If you just have a specific change in mind, and you saw how to do it on the anonCVS browser while you were out and about, the pain of setting up the CVS and working with it is usually enough to just give up and read a book when you get home instead.
segfaultbuserr 8y ago
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!
- djmdjm 8y ago
  Unfortunately, you can't alias scp=sftp as the commandline syntax is different. I'd love someone to write a scp replacement that attempted the sftp protocol first and optionally fell back to scp if that didn't work.
  - low_key 8y ago
    This. I've been using rsync for a long time just for the resume feature even without knowing about some of the other benefits. I tend to use the flags "-avzpP"
  - pnutjam 8y ago
    Not all ssh servers enable the sftp subsystem by default.
- bArray 8y ago
  Checking out the mitigation for CVE-2019-6111 [1], how does `sftp` help? * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above. You could just do a remote `ls` and then `sftp` all the files listed to your client - nothing stopping a malicious return from `ls`? Surely it's the risk of running any kind of wild card copy? If the server is compromised then there's no telling what will be returned from such a command? 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. The protocol itself might be outdated, but surely one of the best aspects of `scp` comes from its simplicity [2]? [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 [2] https://github.com/openssh/openssh-portable/blob/master/scp.c https://github.com/openssh/openssh-portable/blob/master/scp....
ggm 8y ago
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 8y ago
  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.
  - ggm 8y ago
    I get hit by that one. but, tbf Linux and BSD differ on the behaviour of cp -r with ./thing/ and ./thing -I found references to ./thing/. worked on both. I also find the --include --exclude behaviour very confusing. does --include=* outweigh --exclude=thing and vice-versa and does this reset left to right?
  - pgeorgi 8y ago
    That's why I have cpdup (https://github.com/DragonFlyBSD/cpdup https://github.com/DragonFlyBSD/cpdup) around on all systems I use. No need to worry about rsync's special syntax.
  - mcbain 8y ago
    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.
- adrian_b 8y ago
  While you are right, at least rsync works correctly, i.e. it is able to make perfect copies of files, regardless of the files systems used at source and at destination, while scp and sftp have always lost information (file metadata) in certain cases. Any file copying program which is unable to make identical copies is garbage in my opinion. The Linux tmpfs file system is another bad example. Like scp, which can silently lose information, copying a file to a tmpfs directory, then again to a decent file system can lose file metadata.
MayeulC 8y ago
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 8y ago
  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.
  - egil 8y ago
    And that was in 2012. I reckon everybody who cares knows that openssh config uses ~/.ssh, and those who do not care will not cry if they accidently delete it.
  - MayeulC 8y ago
    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.
nn3 8y ago
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 8y ago
  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 8y ago
    You are right of course. If nothing works anymore that is by definition most secure.
    - deleted 8y ago
      [deleted]
    - danielhlockard 8y ago
      That's not at all what I said.
      - chasil 8y ago
        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.
moreentropy 8y ago
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 8y ago
  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.
- ptman 8y ago
  Sure, it would be nice. But fortunately you can use yubikeys to store keypairs that can be used with ssh. And https://github.com/Yubico/yubico-pam https://github.com/Yubico/yubico-pam can probably be used with SSH.
- old-gregg 8y ago
  You should take a look at https://github.com/gravitational/teleport https://github.com/gravitational/teleport Disclaimer: I'm one of the contributors.
gchamonlive 8y ago
It would sure help encourage testing if we could have it on AUR for easy installation on arch distros.
tabletopneedle 8y ago
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 8y ago
  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 8y ago
    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.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...) --- 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".

179 points by lelf 8y ago

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 8y ago
> 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!
- brylie 8y ago
  It may be important not to confuse "diligence" for "encumbrance".
- sneak 8y ago
  The willingness to jump through outmoded and unnecessary hoops does not correlate to the quality of one's cryptographic code. In fact, many who are deliberately diligent will shy away from teams who care more about tradition than quality, in my experience.
- geofft 8y ago
  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 8y ago
    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 8y ago
      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.
wibble10 8y ago
It’s part of OpenBSD who can’t use git for licensing reasons and the switch from cvs->svn isn’t really worth it. There is a git mirror on github and you can work on that and submit diffs to the mailing list if you’re worried about having to read the cvs manpage ;)
- avar 8y ago
  Let's make something clear: They can, and they use other GPL software in the base system. They just choose not to, for (as I understand it) a combination of reasons. Being averse to relying on new GPL code, being "happy enough" with CVS (also working on OpenCVS), and CVS being a little more than just source control for them due to the likes of CVSync[1]. I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it. 1. https://www.openbsd.org/cvsync.html https://www.openbsd.org/cvsync.html
  - Crinus 8y ago
    Aren't "patches in Git" just "patches"? Git can give you a patchfile that can be applied with "patch" regardless of VCS.
    - sneak 8y ago
      from GP: "I have patches in Git. If OpenBSD doesn't want to use it that's fine by me, and I wish them the best of luck. But let's be clear, it's not because we're telling them they can't use it." I think he means he is a contributor to the source of `git` itself, and thus is justified in saying "we" in terms of not prohibiting OpenBSD's contributors from using the software he helps develop (git).
      - avar 8y ago
        Correct. Thanks!
  - simias 8y ago
djmdjm 8y ago
For workflows, we have good tooling based around https://github.com/yasuoka/cvs2gitdump https://github.com/yasuoka/cvs2gitdump to convert OpenBSD CVS commits to git commits in a "pristine upstream" repository (https://github.com/djmdjm/openbsd-openssh-src https://github.com/djmdjm/openbsd-openssh-src) and merge them to the portable OpenSSH repository. Merging changes from OpenBSD to portable is usually completely painless and only a hassle when merging something really large (in LoC touched) like a refactoring. It would certainly be easier for external contributors (and us) if OpenBSD used git natively but as OpenBSD was AFAIK the first open source project to expose a CVS tree of their work to the world there's a lot of legacy to overcome.
microcolonel 8y ago
I know the process of using CVS has prevented me from making drive-by contributions to OpenBSD. If you just have a specific change in mind, and you saw how to do it on the anonCVS browser while you were out and about, the pain of setting up the CVS and working with it is usually enough to just give up and read a book when you get home instead.

segfaultbuserr 8y ago

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!

djmdjm 8y ago
Unfortunately, you can't alias scp=sftp as the commandline syntax is different. I'd love someone to write a scp replacement that attempted the sftp protocol first and optionally fell back to scp if that didn't work.
- low_key 8y ago
  This. I've been using rsync for a long time just for the resume feature even without knowing about some of the other benefits. I tend to use the flags "-avzpP"
- pnutjam 8y ago
  Not all ssh servers enable the sftp subsystem by default.
bArray 8y ago
Checking out the mitigation for CVE-2019-6111 [1], how does `sftp` help? * scp(1): Relating to the above changes to scp(1); the scp protocol relies on the remote shell for wildcard expansion, so there is no infallible way for the client's wildcard matching to perfectly reflect the server's. If there is a difference between client and server wildcard expansion, the client may refuse files from the server. For this reason, we have provided a new "-T" flag to scp that disables these client-side checks at the risk of reintroducing the attack described above. You could just do a remote `ls` and then `sftp` all the files listed to your client - nothing stopping a malicious return from `ls`? Surely it's the risk of running any kind of wild card copy? If the server is compromised then there's no telling what will be returned from such a command? 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. The protocol itself might be outdated, but surely one of the best aspects of `scp` comes from its simplicity [2]? [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111 [2] https://github.com/openssh/openssh-portable/blob/master/scp.c https://github.com/openssh/openssh-portable/blob/master/scp....

ggm 8y ago

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 8y ago
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.
- ggm 8y ago
  I get hit by that one. but, tbf Linux and BSD differ on the behaviour of cp -r with ./thing/ and ./thing -I found references to ./thing/. worked on both. I also find the --include --exclude behaviour very confusing. does --include=* outweigh --exclude=thing and vice-versa and does this reset left to right?
- pgeorgi 8y ago
  That's why I have cpdup (https://github.com/DragonFlyBSD/cpdup https://github.com/DragonFlyBSD/cpdup) around on all systems I use. No need to worry about rsync's special syntax.
- mcbain 8y ago
  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.
adrian_b 8y ago
While you are right, at least rsync works correctly, i.e. it is able to make perfect copies of files, regardless of the files systems used at source and at destination, while scp and sftp have always lost information (file metadata) in certain cases. Any file copying program which is unable to make identical copies is garbage in my opinion. The Linux tmpfs file system is another bad example. Like scp, which can silently lose information, copying a file to a tmpfs directory, then again to a decent file system can lose file metadata.

MayeulC 8y ago

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 8y ago
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.
- egil 8y ago
  And that was in 2012. I reckon everybody who cares knows that openssh config uses ~/.ssh, and those who do not care will not cry if they accidently delete it.
- MayeulC 8y ago
  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.

nn3 8y ago

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 8y ago
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 8y ago
  You are right of course. If nothing works anymore that is by definition most secure.
  - deleted 8y ago
    [deleted]
  - danielhlockard 8y ago
    That's not at all what I said.
    - chasil 8y ago
      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.

moreentropy 8y ago

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 8y ago
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.
ptman 8y ago
Sure, it would be nice. But fortunately you can use yubikeys to store keypairs that can be used with ssh. And https://github.com/Yubico/yubico-pam https://github.com/Yubico/yubico-pam can probably be used with SSH.
old-gregg 8y ago
You should take a look at https://github.com/gravitational/teleport https://github.com/gravitational/teleport Disclaimer: I'm one of the contributors.

gchamonlive 8y ago

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

tabletopneedle 8y ago

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 8y ago
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 8y ago
  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.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht...) --- 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".