Bug 1151824

Summary:	cloud-init does not disable ECDSA keys for root
Product:	[Fedora] Fedora	Reporter:	Richard Chan <rc556677>
Component:	cloud-init	Assignee:	Garrett Holmstrom <gholms>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	apevec, gholms, Jan.van.Eldik, mattdm, p, shardy, s, walters
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	cloud-init-0.7.6-3.fc22	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-12 17:49:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard Chan 2014-10-12 10:20:43 UTC

Description of problem:
cloud-init adds ssh_authorized_keys to the default user fedora and to root but for root it disables the keys with a prefix command that echoes the helpful message:

'Please login as the user "fedora" rather than the user "root".'

However, if the key is of type ecdsa-sha2-nistp521, it is not parsed correctly, and the prefix command is not prepended.

This means that ECDSA keys can be used to login to root.

Version-Release number of selected component (if applicable):
cloud-init-0.7.2-10.fc20.x86_64
cloud-init-0.7.5-10.el7.centos.1.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Using NoCloud datasource: In /user-data create an ECDSA and DSS key
ssh_authorized_keys:
- ecdsa-sha2-nistp521 AAAAE2.............
- ssh-dss.....

2. Boot VM instance and look at /root/.ssh/authorized_keys

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"fedora\" rather than the user \"root\".';echo;sleep 10" ssh-dss
ecdsa-sha2-nistp521 AAAAE2....

Actual results:
ssh-dss key has prefix command
ecdsa key does not have prefix command

Expected results:
all keys in /root/.ssh/authorized_keys have prefix command.

Additional info:
ecdsa-sha2-nistp521 is not in VALID_KEY_TYPES in ssh_util.py.
That file is looking for
ecdsa
ecdsa-sha2-nistp256-cert-v01
ecdsa-sha2-nistp384-cert-v01
ecdsa-sha2-nistp521-cert-v01
as valid ECDSA key types.

I think this leads to a parser error and the prefix command is not prepended.

Comment 1 Richard Chan 2014-10-12 10:37:17 UTC

This test patch fixes the problem for the three Fedora ECDSA curves.
I don't think it is viable when/if many more ECs are allowed by the legal team.
Maybe the logic should check:

Instead of 

ssh_util:312: if toks[0] not in VALID_KEY_TYPES:

or no string in VALID_KEY_TYPES is a prefix of toks[0]; since "ecdsa" is in VALID_KEY_TYPES this will catch ssh keys of ecdsa-sha2-*.



diff -u -r cloudinit.orig/ssh_util.py cloudinit/ssh_util.py
--- cloudinit.orig/ssh_util.py  2014-10-12 18:24:43.044000000 +0800
+++ cloudinit/ssh_util.py       2014-10-12 18:25:46.987000000 +0800
@@ -31,7 +31,7 @@
 DEF_SSHD_CFG = "/etc/ssh/sshd_config"
 
 # taken from openssh source key.c/key_type_from_name
-VALID_KEY_TYPES = ("rsa", "dsa", "ssh-rsa", "ssh-dss", "ecdsa",
+VALID_KEY_TYPES = ("rsa", "dsa", "ssh-rsa", "ssh-dss", "ecdsa", "ecdsa-sha2-nistp256", "ecdsa-sha2-nistp384", "ecdsa-sha2-nistp521",
     "ssh-rsa-cert-v00", "ssh-dss-cert-v00",
     "ssh-rsa-cert-v00", "ssh-dss-cert-v00",
     "ssh-rsa-cert-v01", "ssh-dss-cert-v01",

Comment 2 Garrett Holmstrom 2015-02-23 22:27:44 UTC

This should be fixed in cloud-init-0.7.6-3.fc22.  cloud-init-0.7.6-4.20140218bzr1060.fc22 will be pushed shortly with some major changes, so it may be worth testing against that instead.

Comment 3 Garrett Holmstrom 2015-02-23 22:39:10 UTC

Update:  cloud-init-0.7.6-4.20140218bzr1060.fc22 isn't going to make it into F22 due to bug 1194577.  If you're testing rawhide it will appear there, but otherwise feel free to go ahead and test cloud-init-0.7.6-3.fc22.  Sorry about the confusion.

Comment 4 Colin Walters 2017-01-20 19:16:42 UTC

The launchpad reference in this bug doesn't work - does anyone know if this was filed upstream?  I can't find it if it was.