I am to get access to a remote SFTP server. The admin has created a user for me, and generated a public/private key pair for me. Then he securely sent me the private key file, which I use for authentication. I believe this is not good, I should be the one to generate the key pair, and give the public key to him. But I'm not able to think of any good reason why this is bad, if I use this key only to log into that server, no other servers. Are there any such reasons?
-
17Bad security hygiene, for one. The server admin should know better, and should not be "training" users to expect to get private keys from external sources.– wmorrellJun 29, 2016 at 18:53
-
1Who else is he giving it to ? Always think, what is the worst that could happen ?– mckenzmJun 30, 2016 at 3:30
-
1I actually don't think it's that bad. An analogy below (Eric Towers) with giving the user an "initial password" which then needs to be changed immediately is good. Speaking from personal experience, explaining what keys are for the 100th time to users can be a bit tedious -- the admin is still human. Giving the private key to you is lazy -- yes, but nothing can stop you from replacing it yourself. In essence, after s/he has sent it to you, you don't need to bother the sysadmin again (unless they chose to turn off write permissions on the file...then, just annoy them).– RayJun 30, 2016 at 3:33
-
@matthiash this question fits this site but, just as an FYI, there is an Information Security site for other security questions.– topherJun 30, 2016 at 12:39
-
I'd also like to point out that this is how AWS does it as well. When you create an instance you don't upload your public key to it, a keypair is generated for you and you download the private key.– GnPJul 6, 2016 at 12:29
2 Answers
It is exactly as you say: The whole concept of public key authentication is that the private key should only be known to the owner, while the corresponding public key can be widely disseminated. The security of your authentication depends on the security of the private key, not of the security of the public key.
The fact that somebody else provides you with a private key automatically makes it compromised. (You don't know if that other admin still has a copy which can be used to impersonate you.)
-
4Let's assume the best from the server admin and assume, that he things, generating a new keypair is better, since he would not trust the user to not have a compormized private key. Maybe the server admin thinks, that the private key of the users are very old and maybe got compromized over the years. It is the same with U2F, where the consortium or the vendors do not trust the users to generate keys, this is why U2F devices come with pre-created keys! Jun 29, 2016 at 19:47
-
8
-
1You are totally right. But often admins are better with computers then with humans ,-) Jun 29, 2016 at 21:33
-
7
-
2I think you are confusing theoretical practices of a narrow example with reality and the bigger picture. You must trust the admin anyway because he has control of the system and can avoid needing to use the key altogether. Giving out private keys happens in the real world because end users either don't understand how to make one, or how to make one securely. Jun 30, 2016 at 10:55
For that key, the organization don't have non-repudiation. IE, if someone does something abusive or destructive to that system using 'your' key, the admin can't point the blame at you for being solely responsible for it. Since the person that gave it to you also had the key. It probably isn't that bad for you, since it gives you a defense, but horrible for the organization controlling the server, if something bad ever happens.
You might be able to use the write privileges you have from the provided keys, to update your authorized keys, and add your key, and remove the provided key.
-
3In fact, the Admin may be expecting the user to change their key during their first use, much as with administratively generated first passwords. Jun 29, 2016 at 20:46
-
7As a great man once said, "expect away". First-use change is often necessary for passwords, but is never necessary for public key crypto -- that's kinda the point.– womble ♦Jun 29, 2016 at 22:59
-
@EricTowers Is that even possible to require with contemporary SFTP (or even SSH, unless you are willing to cobble something together yourself) implementations?– userJun 30, 2016 at 7:56
-
This answer gives the impression that actions over sftp are signed in a log somewhere and end to end secured by that key. This simply isn't the case, an admin can tamper with actions or the logs without even using the key. Jun 30, 2016 at 11:00
-
1@marcelm: There's a reason why I said "often necessary", not "always absolutely mandatory in all circumstances no exceptions". As someone who does, in fact, regularly request (and accept) password hashes, and public keys, I know it's a much higher barrier to get someone to provide a hashed password (with a secure salt and everything) than a public key. If you have an SSH client, you have a key generation tool. The same cannot be said for something capable of calling
crypt
(2) in its many entertaining forms.– womble ♦Jun 30, 2016 at 11:10