Em 14-04-2014 04:28, alexander taylor escreveu: > The problem I'm trying to solve is that casual users trying to ssh > into Github or their home / school server may not bother creating > passphrases for their private ssh keys. This happens to be true not only with casual users. You would be surprised with the vast amount of sys admins that should know better, but end up creating ssh keys with no passphrases. > This means that they are > probably relying on hardware security to keep their private key safe. Very little security here. Only thing that can help a little is disk encryption. Not that many users use it. > However, with no added effort, these keys could be cryptographically > protected under the user's Windows/Linux logon password in the same > way that your saved passwords are protected in the web browser. For > example, Chrome on linux uses any available keychain program to > encrypt saved passwords under the user's logon credential, if a > keychain program is available, and uses the Data Protection API on > Windows. > > More on Windows DPAPI: > http://msdn.microsoft.com/en-us/library/ms995355.aspx This looks like something useful. But a documentation from 2001? SHA-1 to keep things safe? Security isn't Microsoft's thing. > My idea is to add a "--protect" (e.g.) option to ssh-keygen that > encrypts the private key with the user's logon credential (windows or > linux password) instead of prompting for a passphrase. For Windows, > it can protect the file using Windows DPAPI, but for Linux I would > need to create a similar "data protection" service. This "data > protection" service is also something I want to create, with > ssh-keygen being the main motivation. The linux data protection > service would generate a master key for the user, protected on disk by > encryption under the user's password, captured by a PAM module. The > same PAM module decrypts and re-encrypts the master key when the user > changes her password. Then, the data protection service allows > ssh-keygen to encrypt the private key using the user's master key, > available only when logged on. Now, ssh can use the same service to > decrypt the key if the user is logged on (another feature I'd need to > add). If the user is not logged on, the private key is unusable. Unless this would work across all the platforms where openssh runs, I don't see that many people using, nor it getting included in openssh. > Using eCryptfs, hard-drive encryption, or simply making a passphrase > and keeping it in a keyring solve the same problem, but require more > effort by the user. On the contrary. I believe that many distributions include nowadays right on the installation process the possibility of enabling ecryptfs, luks, or even both. So it's simpler for the users now. Again not that many do actually use it. I use ssh-agent and I only need to type the key passphrase once, twice a day. All this saving me from typing 20, 30 times a password when logging in to my machines, or pushing things to my git server. > More details on my research: > https://docs.google.com/document/d/1mibuwHRJpzCFYuQJZ30Cgw6nBjyp6qod19tZnw-Rzv8/edit?usp=sharing > > Thanks for any help/insights! > > alexander taylor >
I think that your idea is doable, but you'll find that this problem is a very hard one to solve, in a portable way, across all the platforms where openssh runs on. Anyway, good luck. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
