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

ssh-keygen systemd service fix #14

Open
lejenome opened this issue Jan 12, 2015 · 7 comments
Open

ssh-keygen systemd service fix #14

lejenome opened this issue Jan 12, 2015 · 7 comments

Comments

@lejenome
Copy link

Sorry, I don't want to make anyone day bad, but just a note for systemd users.
they can either mask the default ssh-keygen service which is named sshdgenkeys.service on ArchLinux:

ln -s /dev/null /etc/systemd/system/sshdgenkeys.service

or a better solution, is to create a custom service to override the default one and to rm bad keys and generate the other secure keys. I'm using this solution and that's my custom service /etc/systemd/system/sshdgenkeys.service

@pirj
Copy link

pirj commented Jan 19, 2015

What is wrong with keeping the keys while leaving only the ed25519 and rsa HostKey items in sshd_config? You can also make dsa and ecdsa world readable so that sshd ingore it.

@stribika
Copy link
Owner

I don't think you should make them world readable, they have to be kept private. When you look at them later, you may not know how long they were readable and who, if anyone, actually read them. I'd move them somewhere else instead where no one can read them.

@pirj
Copy link

pirj commented Jan 20, 2015

You should make ecdsa and dsa world readable as most simple option to prevent sshd from using them. Even if they happen to be turned on in sshd_config, they won't even be used.
Keep ed25519 and rsa 600.

@stribika
Copy link
Owner

If you make them world readable, you must never use them again. The only reason I can see for keeping them is if you want to re-enable them later without changing your old fingerprint. But you will have to create new ones at that point because any user on your system may have read them.

mv may even be simpler than chmod but that's not the point. Don't make your private key public.

@pirj
Copy link

pirj commented Jan 21, 2015

The whole point of making them world readable is that they won't be re-generated. Do you get this simple reason for keeping them?
In case they were used previously, they (ecdsa, dsa) MUST be re-generated and made world readable after that. Does it feels unsafe to you and why?
Moving them somewhere else won't make the trick. Removing them will trigger their creation on next system start on some systems, and in case you forgot to disable them in sshd_config, ecdsa and dsa have the chance to be in the process. But not when they are world readable.
In addition to making them world readable, it's also possible to wipe out their contents. Pretty sure this trick will work.

@lejenome
Copy link
Author

The whole point of this systemd service is that :

  • when I setup a new Linux box and sync my configs and units, if I miss to disable these keys. this service will do this for me. And It will insure that rsa key is 4096 bits
  • If I make any misconfiguration on openssh on future or regenerate these weak keys, this service will fix it when enabling/restarting sshd.

But keeping these keys word readable, even it works, is still not recommended and any future misconfiguration or mistake may be even more dangerous.

@stribika
Copy link
Owner

Creating empty world readable files are fine. This is somewhat similar to the broken symlink trick that used to be there but I removed it since the regenerated config files are not used.

34efeba

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

3 participants