0

Although openssh is awesome, I'm interested in exploring some more lightweight FLOSS alternatives to use for connecting to servers I'm administrating (and using alone). Since I only need a minimal set of features (only public-private-key authentication, only a single (secure) algorithm like ed25519) and I'm aware that feature reduction is often equivalent to a reduction in attack surface, I was thinking about using something like tinysshd or dropbear.

But from reading about it I got the impression that due to the lack of privilege separation as implemented in openssh this might be counterproductive from a security point of view.

Therefore I'd like to ask the community if currently (2020-10):

  • it is recommended to use one of the alternatives to openssh,
  • if yes: which one is preferred and why, and
  • if no: why this is (not) the case.

Also I'd like to know if it is advisable from a security point of view to use tinysshd in conjunction with tcpserver since it allows it to be run as non-root-user but needs to leave the host keys inside /etc/tinysshd/sshkeys.d readable to the user.

In addition I'd appreciate any recommendation on other alternatives except openssh, tinysshd and dropbear.

3

I would keep using openssh

Assuming a 'normal' server, with no resources problem but only about concerned about the security benefits, I would keep using openssh.

  • It has an excellent security record.

While the list of CVE is a long one, analysis shows those are -particularly for one-user servers- actually relatively minor. Those not covering DDoS mostly go along if system is configured in a specific way, an authenticated user could bypass certain setting, which may be unintended.

For a vulnerability suitable to an attacker, we would probably would need to go back 14 years, to CVE-2006-5051. And even that doesn't show a clear exploitation path.

  • Hardening features like the mentioned privilege separation

  • Well known and reviewed. Being so widespread, it has been very scrutinized. You can be sure any security issue that was missed will be promptly fixed when reported.

  • Distribution support. openssh is packaged on every distribution. The other two are available in some of them, but not in others. Even then, you can expect they would quickly patch an openssh vulnerability, which may not be so fast for less common packages. Of course, you may as well install your sshd directly from upstream (and it would provide you the latest version), but there's benefit on using packaged versions if you don't want to be separately watching new sshd releases.

Note that you can restrict openssh features (only PublicKey authentication, just certain algorigtms, etc.) so that you reduce the attack surface available to an attacker.

That said, I don't think using any of the other would be insecure, and wanting to .

PS: For your use case I don't think there's an issue with the /etc/tinysshd/sshkeys.d keys.

1
  • As a side note / emphasis OpenSSH can be configured / build in such a way as to only allow your usecase. The alternatives are in reality not really alternatives, either it’s a replacement for the shell you connect to with a drop bear linked against the openssh libs and a alternative to the shell you connect in. Or are just not reviewed like openssh / OpenSSL|Libressl is. If you want to limit openssh not by config. Build your own with build flags. – LvB Oct 6 '20 at 4:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.