AuthorizedKeysFile in match block will prevent default user login

This bug was originally filed in Launchpad as [LP: #1508543](https://bugs.launchpad.net/cloud-init/+bug/1508543)

Launchpad details

affected_projects = []

assignee = None

assignee_name = None

date_closed = None

date_created = 2015-10-21T16:26:43.269109+00:00

date_fix_committed = None

date_fix_released = None

id = 1508543

importance = low

is_complete = False

lp_url = https://bugs.launchpad.net/cloud-init/+bug/1508543

milestone = None

owner = ajacoutot-bsdfrog

owner_name = Antoine Jacoutot

private = False

status = confirmed

submitter = ajacoutot-bsdfrog

submitter_name = Antoine Jacoutot

tags = []

duplicates = []

_Launchpad user **Antoine Jacoutot(ajacoutot-bsdfrog)** wrote on 2015-10-21T16:26:43.269109+00:00_

Hi.

Consider the following sshd_config which is pretty standard with only an added "Match" block.

---------8<------------------------------------
<...>
Port 22
AuthorizedKeysFile %h/.ssh/authorized_keys
<...>
Match group foobar
AuthorizedKeysFile /etc/ssh/authorizedkeys/%u
---------8<------------------------------------

When starting an instance pre-configured with the above sshd_config (in my case AWS EC2), cloud-init will parse /etc/ssh/sshd_config to know where it should put the public key of the default "ubuntu" user. The problem is that cloud-init is not an sshd_config parser and looking at the code it just do a line-by-line parsing.

In this case, it will pick up the AuthorizedKeysFile value that is in the Match block because it's the last one in the file and will end up putting the default user key under /etc/ssh/authorizedkeys/ubuntu, preventing login into the instance because from the sshd point of view, the correct key location for that user (which is *not* part of the "foobar" group) is $HOMEDIR/.ssh/authorized_keys.

The obvious workaround is to append the default AuthorizedKeysFile at the end of the file but it would have been nice to know it beforehand ;-)
I understand that line-by-line parsing is the easy way, but in the case of ssh it is very error-prone and can lead to unexpected behaviour...

Thanks.