73

I'm supposed to be accessing a server in order to link a company's staging and live servers into our deployment loop. An admin over on their side set up the two instances and then created a user on the server for us to SSH in as. This much I'm used to.

In my mind now what would happen is I would send them my public key which could be placed inside their authorized keys folder. Instead however they sent me a file name id_rsa which inside the file contains -----BEGIN RSA PRIVATE KEY----- over email. Is this normal?

I looked around and can find tonnes of resources on generating and setting up my own keys from scratch, but nothing about starting from the private keys of the server. Should I be using this to generate some key for myself or?

I would ask the system admin directly but don't want to appear an idiot and waste everybody in-between us' time. Should I just ignore the key he sent me and ask them to put my public key inside their authorized folder?

  • 6
    I wouldn't call it normal or sane, but since you have the private key (assuming they already added it as authorized) you can use it as you would use any other private key. You don't need the corresponding public key, but if you want to, you can always generate it: askubuntu.com/a/53555/158442 – muru Dec 7 '16 at 3:38
  • 34
    Getting -----BEGIN RSA PRIVATE KEY----- over e-mail is the next scary thing after seeing a user named '); DROP DATABASE;-- in your username table. – Dmitry Grigoryev Dec 7 '16 at 13:46
  • 62
    @DmitryGrigoryev nothing scary about seeing '); DROP DATABASE;-- as a username in your database table - it shows you've been escaping user input correctly – HorusKol Dec 7 '16 at 21:55
  • 19
    You most certainly can not 'use it as you would use any other private key'. This one is not private. Ergo it cannot possibly fulfill the function for which it was created. It should be thrown away and the UNIX admin severely chastised. @muru – user207421 Dec 7 '16 at 22:22
  • 7
    Anyone who has this private key has access to the new servers. Presumably the admin has access anyway without needing the key, seeing as s/he was able to set up the server, so there's no additional threat of unauthorized access by him. However, since this is your key he can now reliably impersonate you. There's also the chance that someone other than you reads the email, and then they can impersonate you as well. – immibis Dec 7 '16 at 22:25
116

In my mind now what would happen is I would send them my public key which could be placed inside their authorized keys folder.

What's "in your mind" as what should now happen is correct.

Email is not a secure channel of communication, so from a standpoint of proper security, you (and they) should consider that private key compromised.

Depending on your technical skill and how diplomatic you want to be, you could do several different things. I would recommend one of the following:

  1. Generate your own key pair and attach the public key to an email you send to them, saying:

    Thanks! Since email isn't a secure distribution method for private keys, could you please put my public key in place, instead? It's attached.

  2. Thank them and ask them if they object to you installing your own keypair, since the private key they have sent should be considered compromised after having been sent over email.

    Generate your own keypair, use the key they sent you to log in the first time, and use that access to edit the authorized_keys file to contain the new public key (and remove the public key corresponding to the compromised private key.)

Bottom line: You won't look like an idiot. But, the other admin could be made to look like an idiot very easily. Good diplomacy could avoid that.


Edit in response to comments from MontyHarder:

Neither of my suggested courses of action involves "fixing things without telling the other admin what he did wrong"; I just did so subtly without throwing him under the bus.

However, I will add that I would also follow up (politely) if the subtle clues weren't picked up:

Hello, I saw you didn't respond to my comment about email as an insecure channel. I do want to be confident that this won't happen again:

Do you understand why I'm making this point about the secure handling of private keys?

Best,

Toby

  • 9
    +1 Best answer. And I'd add: be particularly careful as this sysadmin has proven to be incompetent. Better have your back covered when (and not if) he/she will screw up the server for good. – dr01 Dec 7 '16 at 6:53
  • 2
    Thanks. I used some delicate phrasing and sent my public key across. It all looks resolved but I'll deauthorize the key he sent me now. – Toby Dec 7 '16 at 8:28
  • 27
    It's not that the other admin "could be made to look like an idiot". It's that the other admin did something idiotic. I can only think of one scenario under which a private key should be shared between machines, and that's where a pool of servers are accessed via the same name (round-robin DNS resolution etc.) and must present the same SSH Host Key so that automated processes will accept that they are that name. And in that case, the same person would be an admin of all of the servers, and would handle the transfers without an outside party being involved. – Monty Harder Dec 7 '16 at 18:27
  • 21
    @zwol At my job, we have a "no blame" philosophy that understands we'll make mistakes, but makes it a high priority to not make the same mistake twice. But in order to not make the same mistake twice, you have to know it's a mistake, which is why I can't up-vote the answers suggesting the OP just fix things without telling the other admin what he did wrong. I chose to call the mistake 'idiotic' rather than calling the admin names precisely for the reason you outline. (But I'm not certain your concluding parenthetical articulates a meaningful distinction.) – Monty Harder Dec 7 '16 at 19:48
  • 8
    @LightnessRacesinOrbit, I suspect you may have an incomplete understanding of the meaning of "diplomacy." Have you tried clearing it up in a good dictionary, such as the Webster's Third New International Dictionary? – Wildcard Dec 8 '16 at 3:32
34

Should I just ignore the key he sent me and ask them to put my public key inside their authorized folder?

Yes, that's exactly what you should do. The whole point with private keys is that they are private, meaning only you have your private key. Since you received that key from the admin, he also has it. So he can impersonate you any time he wants.

Whether the key was sent to you via a secure channel or not is irrelevant: even if you have received your private key in person, that wouldn't change anything. Though I agree with the comments that e-mailing sensitive cryptography keys is the cherry on the cake: your admin doesn't even pretend there's some kind of security policy in place.

  • 6
    And since the OP has no way to know how secure is the admin's machine (from the story, presumably very insecure), he should assume that the private key is (or will be) also leaked to other people. Sending a private key via email is just a bonus fact for infosec cluelessness. – dr01 Dec 7 '16 at 12:29
  • 1
    You can assume that an admin who is able to create users won't need your private key to impersonate you. – Max Ried Dec 7 '16 at 14:43
  • 3
    @MaxRied That may be hard to do with proper security logs in place. With your private key he doesn't even need to mock up the logs. It's like having the ability to reset your password vs. knowing your password. – Dmitry Grigoryev Dec 7 '16 at 14:55
  • @DmitryGrigoryev He could always add another key to your authorized_keys file... – Max Ried Dec 7 '16 at 15:45
  • 4
    @MaxRied I was referring to /var/log/secure or similar, I'm pretty sure the space trick won't fool this one. – Dmitry Grigoryev Dec 7 '16 at 17:24
14

To me it looks like the admin generated a private/public key pair for you, added the public key to the authorized_keys and send you the private one. This way you only have to use this private key for your ssh sessions with the server. No need to generate a key-pair yourself or to send the admin a public key to your possibly corrupted (always think worst case :P) private key.

However, I would not trust the private key sent to you via unencrypted mail.

My approach would be: use the private key to log in once, add your own public key to the authorized_keys on the server (replacing the original public key) and throw away this email-private-key. You may then thank the admin, that he/she/it provided you with the private key but you would prefer such information/keys not to be send via email (/at all).

  • 3
    @Toby The only reason I can imagine for them sending the private key is that they don't understand the tools they are using. And you can use -i on the command line to choose which private key to use. – kasperd Dec 7 '16 at 8:43
  • 18
    @kasperd The reason I can imagine is an overworked sysadmin who has decided that the risks of sending a private key over email are outweighed by the hassle of trying to explain to less-tech-savvy users how to properly generate a key pair and send the public key back. – mattdm Dec 7 '16 at 12:52
  • 1
    Great point that you can fix this yourself. Better to do it yourself right away than waiting for the admin to install the public key for a new keypair. Avoiding using the no-longer-secret private key doesn't help anything; it just gives any potential eavesdroppers longer to use it before you can get in and remove it from authorized_keys (after adding + testing your own). – Peter Cordes Dec 7 '16 at 14:15
  • 4
    @mattdm That... is entirely logical, yet frightening. A person who can't generate a key pair and send me the public key probably isn't going to do much better with a private key I give him. – Monty Harder Dec 7 '16 at 18:32
  • 1
    @mattdm, fair enough but as I was the one to ask him to do all of this I find it hard to believe he thought I don't know how to connect in with ssh. If anything the steps he took was more confusing as I only know the basic common way of using public keys. :x – Toby Dec 8 '16 at 1:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.