-
Notifications
You must be signed in to change notification settings - Fork 406
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
Support for password on private keys #209
Comments
Yeah I just saw that, that's sad. For an OpenWRT used as a bastion host for example It would be an absolute banger. |
This shouldn't be too difficult to implement, and would be a major improvement. |
The dbclient should have a cmdline option to pass an env.var which contains the password for decrypting the key. in cli-runopts.c:
in common-runopts.c
I also changed some .h files and did some initialisation, but I think that is obvious... But probably the libtomcrypt contains better ways to encrypt and decrypt the keys and that should be used. For my quick hack I used a standalone program to encode the dropbear keys with a password using the same logic. |
I'm sorry to disagree. My arguments are these:
If the author chooses to add this functionality, I beg of you to at least make it optional/removable. |
Not everyone uses openwrt, it is about if you use a dbclient you are able to put a password on the ssh keys for security. |
This isn't a request for a new crypto algorithm which will require a lot of code. This request can, with a certainty, use crypto already imported into every dropbear build (every build needs AES, for example). So we're looking at an implementation cost of a couple hundred bytes if done with an eye to economy. It will probably take more space for the text used in user messages than for the code. As such, this seems to be a pretty low impact addition. Incidentally, looking through the 18k or so of text build into the binary, I see many places where some clever reuse could save quite a bit of space. |
I'd be inclined to use a proper password hashing method for encrypted keys. Otherwise most passwords will be brute-forceable by GPU unless they're a diceware passphrase or similar. A short password is false security. If implementing good password hashing then it probably makes sense to just implement OpenSSH's newer private key format which uses bcrypt. |
libtom/libtomcrypt#587 adds support for OpenSSH encrypted keys, could be used once merged. |
Attached tar file which contains patch files for dbclient and dropbearkey which supports encrypted keys. Maybe this helps... |
@mkj, libtom/libtomcrypt#587 was merged recently. |
Feature request
I noticed that I cannot put a password on a private key.
Would be nice in the future if that was somehow possible.
Have a nice 2023 everyone !
The text was updated successfully, but these errors were encountered: