-
Notifications
You must be signed in to change notification settings - Fork 33
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
Comments
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. |
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. |
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. |
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.
|
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? |
The whole point of this systemd service is that :
But keeping these keys word readable, even it works, is still not recommended and any future misconfiguration or mistake may be even more dangerous. |
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. |
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: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
The text was updated successfully, but these errors were encountered: