Bug 1151824 - cloud-init does not disable ECDSA keys for root
Summary: cloud-init does not disable ECDSA keys for root
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cloud-init
Version: 20
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Garrett Holmstrom
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-12 10:20 UTC by Richard Chan
Modified: 2017-01-20 19:16 UTC (History)
8 users (show)

Fixed In Version: cloud-init-0.7.6-3.fc22
Clone Of:
Environment:
Last Closed: 2015-03-12 17:49:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1380257 0 None None None Never

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.


Note You need to log in before you can comment on or make changes to this bug.