76

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?

ilkkachu
  • 138,973
Toby
  • 783
  • 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: http://askubuntu.com/a/53555/158442 – muru Dec 07 '16 at 03:38
  • 36
    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 07 '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 07 '16 at 21:55
  • 20
    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 07 '16 at 22:22
  • 8
    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. – user253751 Dec 07 '16 at 22:25
  • @EJP hence the qualifier "I wouldn't call it ... sane", an insane person can most certainly do it. – muru Dec 07 '16 at 22:48
  • @HorusKol Gee, you're ruining my joke! – Dmitry Grigoryev Dec 07 '16 at 23:28
  • 2
    @DmitryGrigoryev, it's scary if you see Database 'production' doesn't exist – Paul Draper Dec 08 '16 at 05:05
  • 1
    @DmitryGrigoryev leave that poor Bobby Tables alone ! – Aaron Dec 08 '16 at 09:01
  • @mutu You can't use it to uniquely identify yourself, or receive private information, sanely or otherise. – user207421 Dec 09 '16 at 18:38

3 Answers3

115

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

Community
  • 1
Wildcard
  • 36,499
  • 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. – dr_ Dec 07 '16 at 06: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 07 '16 at 08:28
  • 1
    I would include the specs in the mail, like, which algorithms were used, how many bits. I would put this information in parenthesis after "It's attached." – Daniel W. Dec 07 '16 at 11:28
  • Besides e-mail being insecure, isn't sharing a private key between two people a thing by itself? – mgarciaisaia Dec 07 '16 at 16:18
  • 1
    @mgarciaisaia: no. a private key should never be shared. share the public key (and only the public key) – Olivier Dulac Dec 07 '16 at 16:40
  • 28
    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 07 '16 at 18:27
  • 2
    It's an idiotic mistake, but it's the kind of idiotic mistake that everyone makes once (and hopefully never again). It does not mean that the other sysadmin is an idiot. (If you point out the mistake and they insist that they didn't do anything wrong, then it would be fair to conclude that they don't know how to do their job. But that's still not the same as being an idiot...) – zwol Dec 07 '16 at 19:21
  • 22
    @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 07 '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 08 '16 at 03:32
  • 2
    note also that depending on your threat model you may have to take into account the fact that the email could be MitM'd and the attached public key tampered with. – strugee Dec 08 '16 at 03:46
  • @MontyHarder I think not making that distinction is unfair to idiots. That's not a joke. In my experience, genuine idiots are quite aware of their own limitations, and don't take jobs they're not capable of. People who haven't learned to do their jobs properly are much more troublesome. And, in my experience, refusing to accept that there's something important one doesn't know is a characteristic failing of smart people. – zwol Dec 08 '16 at 16:03
  • 1
    @zwol You're absolutely right. that's definitely a distinction worth making. But "smart" and "wise" are orthogonal. It's possible, as you say, to be non-smart and wise enough to know it, which is harmless. The real danger is the people who aren't as wise as they are "smart" (scare quotes needed). I've been using "idiot" to mean precisely those folks, but it appears you're referring to the harmless group with that name. – Monty Harder Dec 08 '16 at 16:36
  • @MontyHarder, see edits. – Wildcard Mar 12 '17 at 05:20
33

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.

Dmitry Grigoryev
  • 7,313
  • 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. – dr_ Dec 07 '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. – bot47 Dec 07 '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 07 '16 at 14:55
  • @DmitryGrigoryev He could always add another key to your authorized_keys file... – bot47 Dec 07 '16 at 15:45
  • @MaxRied But then he'll have to explain this annoying sudo nano /home/user/authorized_keys line in the logs. – Dmitry Grigoryev Dec 07 '16 at 16:48
  • Ever tried a space in Front of a command? ;) This doesn't really convince me. – bot47 Dec 07 '16 at 16:50
  • @MaxRied What "space in Front of a command" trick are you referring to? – Dmitry Grigoryev Dec 07 '16 at 16:57
  • (offtopic!) A space in front of a command on some shells including bash will prevent that command from being recorded in history. Also, exiting bash with kill -9 $$ will also stop the Shell from saving the history. – bot47 Dec 07 '16 at 17:20
  • 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 07 '16 at 17:24
  • If the key is password protected, isn't the password the actual private thing? What can one do with a private key without knowing the password? – robsch Jun 14 '17 at 12:20
  • @robsch One can login to SSH without a password. – Dmitry Grigoryev Jun 15 '17 at 07:20
  • How? When? If the key was generated with a password, don't you have to enter it on usage? – robsch Jun 15 '17 at 07:43
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).

user204269
  • 141
  • Thank you, I ended up sending the public key I'd already made and gave instructions on how to authorize it. Looks like it's all working now. Is this sending of the private key in any way beneficial? I'm trying to understand why he did it? - Also assuming I already generated my keys, could I use a second private? Do I just rename it and dump it in the folder next to my main one? Thanks. – Toby Dec 07 '16 at 08:27
  • 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 07 '16 at 08:43
  • 20
    @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 07 '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 07 '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 07 '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 08 '16 at 01:31