Skip to content

cc_ssh.py: Add configuration for controlling ssh-keygen output#1083

Merged
TheRealFalcon merged 1 commit into
canonical:mainfrom
dermotbradley:quiet-ssh-keygen
Oct 27, 2021
Merged

cc_ssh.py: Add configuration for controlling ssh-keygen output#1083
TheRealFalcon merged 1 commit into
canonical:mainfrom
dermotbradley:quiet-ssh-keygen

Conversation

@dermotbradley
Copy link
Copy Markdown
Contributor

@dermotbradley dermotbradley commented Oct 26, 2021

Proposed Commit Message

cc_ssh.py: Add configuration for controlling ssh-keygen output

When ssh host keys are generated during initial boot the full output of
ssh-keygen, including the randomart for the key, is displayed on the
console for each of the generated key types, which takes up a large
amount of screen output (17 lines per key type).

With this change ssh-keygen output is still displayed by default.

Setting ssh_quiet_keygen to True will prevent ssh-keygen output from
appearing. If only the fingerprints of the host keys should be
displayed then this can be achieved using the existing
emit_keys_to_console and/or ssh_fp_console_blacklist settings.

Additional Context

Test Steps

Checklist:

  • My code follows the process laid out in the documentation
  • I have updated or added any unit tests accordingly
  • I have updated or added any documentation accordingly

@TheRealFalcon
Copy link
Copy Markdown
Contributor

@dermotbradley , the behavior change looks good, but I'm hesitant to make this default. We have people that scrape the console log for user/connection details, and I wouldn't be surprised if this included key output. Requiring a cloud-config change would still be breaking backwards compatibility, and I don't see a compelling reason this change needs to be default behavior. What do you think about making the default False?

@dermotbradley
Copy link
Copy Markdown
Contributor Author

dermotbradley commented Oct 26, 2021

@TheRealFalcon

@dermotbradley , the behavior change looks good, but I'm hesitant to make this default. We have people that scrape the console log for user/connection details, and I wouldn't be surprised if this included key output.

This is regarding SSH host key generation, not user key generation. I would be amazed is anyone is scraping the VisualArt output, for the key fingerprints they can be separately (also) displayed via the emit_keys_to_console option.

Requiring a cloud-config change would still be breaking backwards compatibility, and I don't see a compelling reason this change needs to be default behavior. What do you think about making the default False?

I seem to remember seeing someone on IRC recently complaining about the size of the output produced - indeed 17 lines are written for each host key type generated so with the minimum "typical" secure set of ED25519 & RSA only that's 34 lines of output.

However I don't mind changing the default to False as I can set it otherwise in my own image creation scripts.

When ssh host keys are generated during initial boot the full output of
ssh-keygen, including the randomart for the key, is displayed on the
console for each of the generated key types, which takes up a large
amount of screen output (17 lines per key type).

With this change ssh-keygen output is still displayed by default.

Setting ssh_quiet_keygen to True will prevent ssh-keygen output from
appearing. If only the fingerprints of the host keys should be
displayed then this can be achieved using the existing
emit_keys_to_console and/or ssh_fp_console_blacklist settings.
@dermotbradley dermotbradley changed the title cc_ssh.py: Do not show ssh-keygen output by default cc_ssh.py: Add configuration for controlling ssh-keygen output Oct 27, 2021
@dermotbradley
Copy link
Copy Markdown
Contributor Author

@TheRealFalcon The setting's default value has been changed.

Copy link
Copy Markdown
Contributor

@TheRealFalcon TheRealFalcon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants