20

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?

matthiash
  • 311
  • 2
  • 3
  • 17
    Bad 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. – wmorrell Jun 29 '16 at 18:53
  • 1
    Who else is he giving it to ? Always think, what is the worst that could happen ? – mckenzm Jun 30 '16 at 03:30
  • 1
    I 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). – Ray Jun 30 '16 at 03:33
  • @matthiash this question fits this site but, just as an FYI, there is an [Information Security site](http://security.stackexchange.com) for other security questions. – topher Jun 30 '16 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. – GnP Jul 06 '16 at 12:29

2 Answers2

23

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.)

HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • 4
    Let'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! – cornelinux Jun 29 '16 at 19:47
  • I would make that an answer rather than leave it as comment! Because you do have a point :P – HBruijn Jun 29 '16 at 19:52
  • 8
    The admin should help the user generate and secure a private key. – Alex Jun 29 '16 at 20:06
  • 1
    You are totally right. But often admins are better with computers then with humans ,-) – cornelinux Jun 29 '16 at 21:33
  • 7
    The admin can impersonate you anyway. – user253751 Jun 29 '16 at 22:26
  • 2
    I 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. – JamesRyan Jun 30 '16 at 10:55
  • 1
    @JamesRyan The risk that an administrator will abuse that private key is indeed small as long as his administrator privileges allow much more and easier access to those systems, yes. The risk for abuse (or the value) of your private key dramatically increases when his administrator rights get revoked (he changes roles/jobs, retires) as hardly anyone immediately revokes legitimate accounts when the administrator account that created them is revoked. – HBruijn Jun 30 '16 at 14:22
10

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.

Zoredache
  • 130,897
  • 41
  • 276
  • 420
  • 3
    In fact, the Admin may be expecting the user to change their key during their first use, much as with administratively generated first passwords. – Eric Towers Jun 29 '16 at 20:46
  • 7
    As a [great man once said](https://www.youtube.com/watch?v=lllUSIUJE4M), "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 '16 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? – user Jun 30 '16 at 07: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. – JamesRyan Jun 30 '16 at 11:00
  • @womble Why is first-use change necessary for passwords? You could also ask the user to mail the admin a password (or better, a password hash) to install. Exactly like you would with a public key. – marcelm Jun 30 '16 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 '16 at 11:10
  • @womble Fair enough. – marcelm Jun 30 '16 at 11:52
  • @JamesRyan with the right level of verbosity, the fingerprint of the key is logged on incoming connections. With sufficient separation of duties, and so on logs can be sent to a location where the person issuing the keys has no ability to actually mess with the logs. I doubt that is the case in this situation, but a heavily locked down setup, **certainly CAN exist** where the person administering accounts and privileges has no ability to modify logging configuration, or the logs. – Zoredache Jun 30 '16 at 18:12