OpenSSH: remove ECDSA keys

[gfrancesco]

Maintainer: @tripolar @SibrenVasse ?
Environment: (OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07 branch git-20.087.56959-ed1fc63) Feroceon 88FR131 rev 1 (v5l)
OpenSSH v8.0p1-1

Description:

This was triggered by the fact that the init script recreates ECDSA keys at every boot if they are deleted.

packages/net/openssh/files/sshd.init

Lines 11 to 21 in ecb4acf

	for type in rsa ecdsa ed25519
	do
	# check for keys
	key=/etc/ssh/ssh_host_${type}_key
	[ ! -f $key ] && {
	# generate missing keys
	[ -x /usr/bin/ssh-keygen ] && {
	/usr/bin/ssh-keygen -N '' -t $type -f $key 2>&- >&-
	}
	}
	done

But opens to (IMHO) some other issues:

• ECDSA keys are based on NIST elliptic curves that are considered problematic in terms of security, resilience and vulnerability to malfunctioning RNG. See:
  https://security.stackexchange.com/a/46781
  http://safecurves.cr.yp.to/
  https://wiki.archlinux.org/index.php/SSH_keys#ECDSA
  https://www.benhup.com/freebsd/openssh-configuration-with-elliptic-curve/
  https://stribika.github.io/2015/01/04/secure-secure-shell.html
  http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
• From the code above, the RSA key is generated with the standard 3072 bits length (it's the default length in the current version of OpenSSH), which is fine for now, but most recent reports recommend 3072 bits good only for near term protection (https://www.keylength.com/en/3/).
  In addition, if we run ssh-keygen with a specific key length it's easier for the user looking at the source of the init script to be aware of the key length in use, as opposed to check the key itself or find the man page of the OpenSSH version in use.

Proposed changes:

• ECDSA can be removed from the init script ssh-keygen automatic key generation routine. IMHO it has no reason to be used at all: it has less compatibility than RSA and less performance and security than Ed25519. In any case nothing stops the user to manually generate ECDSA keys if needed, they just won't be generated automatically by the init script. I don't know if they are also generated when OpenSSH is installed though.
• Increase the key size of RSA keys generated by ssh-keygen in the init script, there should be little practical performance impact since it is only used once per SSH connection to authenticate the host. I can double check on that and perform a quick and dirty benchmark if needed.

Feel free to point out anything I might have missed. In case it is needed, I can submit a PR with the above changes.

[neheb]

The initial reason for adding it back (yes this was the case before) is that OpenSSH needed to be patched as it complains about missing ECDSA key in the syslog.

edit: ah NVM I have ECDSA and DSA confused. These two commits:

ea11921
9fdba25

it has less compatibility than RSA and less performance and security than Ed25519. 

And less compatibility than ed25519. ed25519 is not supported by JuiceSSH (Android App) but ECDSA is. ed25519 is also an OpenSSH extension and not an IETF standard.

In any case, I remember looking at this a long time ago. RSA was faster to use for clients but slower for use by servers (difference was signing and verification I think).

[gfrancesco]

And less compatibility than ed25519. ed25519 is not supported by JuiceSSH (Android App) but ECDSA is.

So is RSA, that is my point actually. However I looked again into JuiceSSH and host-key algorithms and I have to agree with you. It only supports ssh-rsa that uses SHA-1, which is broken since years. With OpenSSH 8.2, released a couple of weeks ago, they finally announced deprecation of ssh-rsa in favor of rsa-sha2-256/512 but JuiceSSH can't use them.
https://www.openssh.com/txt/release-8.2

True that ed25519 is not an IETF standard, but I don't see it as big problem given the demonstrated improved security and performance. Within SSH it is supported in a couple of implementations since many years (almost 10 actually) and it's known that IETF processes are quite slow to react (there are WIP drafts to deprecate sha-1 and md5 as we write, while those algorithms being broken for at least 5 years).

In any case, I remember looking at this a long time ago. RSA was faster to use for clients but slower for use by servers

What do you mean with that?

In any case, I do have to agree that, everything considered, it's better to go for an ECDSA + NIST curve than relying on RSA with a SHA-1 host-key algorithm for compatibility (es. JuiceSSH). Sorry for bothering.

[tripolar]

But who cares about JuiceSSH? JuiceSSH seems to be deprecated and ECDSA too. I will remove ECDSA.

[tripolar]

remove in 45c0fde

[neheb]

But who cares about JuiceSSH? JuiceSSH seems to be deprecated and ECDSA too. I will remove ECDSA.

Deprecated by what?

[gfrancesco]

Didn't notice till now, but there are no updates in the last 3 years. They are not answering emails and no plans to include ed25519, I'll look for another client for Android. On this path it will eventually break Android APIs and auto deprecate itself..

https://twitter.com/JuiceSSH/status/828213005955526656

[tripolar]

But who cares about JuiceSSH? JuiceSSH seems to be deprecated and ECDSA too. I will remove ECDSA.

Deprecated by what?

Didn't notice till now, but there are no updates in the last 3 years.

[gfrancesco]

If of any interest, Termius looks like a better choice. Actively maintained, support for ed25519 is included and you can harden the client configuration by importing a ~/.ssh/config file (premium feature).
It's reported in the official Raspberry Pi docs as SSH solution for Android and it's based on libssh2, tracking its latest release atm.