Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authorized_keys not synced after change it on the host #9

Open
acblbtpccc opened this issue Jan 19, 2025 · 1 comment
Open

authorized_keys not synced after change it on the host #9

acblbtpccc opened this issue Jan 19, 2025 · 1 comment

Comments

@acblbtpccc
Copy link

Hi! I really appreciate this repo as it simplifies the process of bastion sshd setup and user management.

I noticed that when the container starts, it copies the authorized_keys file to "%h/.ssh/authorized_keys". However, after adding new public keys to the authorized_keys file on the host, the changes are not automatically synchronized (which is understandable given the current copy-on-start behavior), so I need to rebuild the container to make the changes take effect.

After considering the SSH_USER and permissions, I tried an alternative approach by:

  1. Using "AuthorizedKeysFile /authorized_keys %h/.ssh/authorized_keys" in sshd config
  2. Mounting this configuration file through sshd_config.d/extra.conf

This solution allows:

  • Direct modification of the host's authorized_keys file and changes could take effect without container restart, so no SSH connection interruption

I'd like to know if:

  1. Is there any potential issue with this approach, like I missed something so that my authorized_keys file is not synced by default?
  2. Is the current non-sync behavior intentional like a feature?

Thanks!

@jaydrogers
Copy link
Member

If it works, use it 😃

In my use case, I needed to deploy these keys in a multi-node swarm environment -- so mounting from the hosts isn't an option.

I think your approach is fine. You could add "read only" mounts to make it more secure so your container cannot edit the file either.

Thanks for sharing your approach!

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

No branches or pull requests

2 participants