ssh module comment/spaces modifications

[trane]

Here is a proposal with certain assumptions for dealing with comments and spaces in ssh authorized keys file.

Assumptions:

• Spaces in ssh-keys are in fact not valid keys
• Spaces mean key+comment

Proposal:

1. We could throw an exception when the ssh key in question contains spaces
2. We could infer that a key with spaces is key+comment, and format the line accordingly

I believe 1 is the best way, since 2 could lead to issues where a user has both a space in the key and a comment in the yaml.

The exception would be SSHInvalidKey.

[thatch45]

What was wrong with the old way + adding an error to the return when a key has a space?

[trane]

That's what I'm suggesting. Except we should keep the new re code for ssh-key options, since that wasn't handled correctly before.

[thatch45]

I don't think an exception is the right way to go here, I think that we should still try to support spaces in the key. Since we can cut up an existing key we should be able to cut up a key passed in, and if it does not fit the bill then return a failure so the state can handle it. Also, we don't want to return exceptions back to the cli when calling a module

[trane]

I don't believe spaces are valid characters in an ssh key, according to the authorized_keys manpage spaces are only allowed in double quotes in the options before a key. There doesn't appear to be a limitation, however, in the ssh public key specification for not allowing spaces.
So a proper line in the authorized_keys file is:

{[option,]<space>}<enc><space><key><space><comment><newline>

What kind of failure should be returned for the state? Just a string?

[thatch45]

sounds perfect, because yes, no spaces are allowed in the actual key. Yes, a string should be returned adn then evaluated in states/ssh_auth.py
thanks @trane this stuff is making our ssh module very powerful!