0

I'm wanting to use all key-based authentication for connecting to multiple servers. Some of these - like my VirtualBox playground network - have no password on the keys, some like for my public facing have very strong passwords on the keys. Between 2 desktop systems, a laptop, and occasional use of a live cd/dvd I need some way to keep the keys identified (I've got 7) and be able to transfer them to a fresh OS if I've booted from a live disk.

The questions -

What is a safe method of transferring keys from some source to whatever machine I've booted from a live image (some of our labs and classrooms are set up for network book of Mint 18 iso) and don't have my file(s) on a USB drive to sneaker-net it over?

Any hints on naming schemes that aren't blatantly bad (ie, hostname or function mail.example.com.id_rsa or webserver.id_rsa) ? I've been using internal hostnames (property tag or vmid) but I think there is probably a better method...

ivanivan
  • 4,955
  • Do you mean that you want to ssh into one of your servers from a live disc that you've booted to? – Nasir Riley Feb 09 '18 at 23:55
  • @NasirRiley Yes, once in a blue moon I need to get from my classroom computer to my desktop, or to a VPS, etc for demo purposes. When I plan on doing this, I can bring my keys with me. When it is a on the moment thing though I'd like some method of retrieval. – ivanivan Feb 10 '18 at 00:40
  • I'll have an answer for you in a few minutes. – Nasir Riley Feb 10 '18 at 00:46
  • I'm not sure what you are asking here. I organise my keys in ~/.ssh, and then listed in ~/.ssh/config. Are you asking how to transfer them from a remote network? And what is "blatantly bad" about naming them by hostname? – Sparhawk Feb 10 '18 at 00:49
  • @Sparhawk - when you add a new key, how do you propagate the private part to the other machines you work from? And by naming the key file the same as the hostname is for gives someone who has gone to the trouble of getting the key in the first place the name of his next target to attack. – ivanivan Feb 10 '18 at 00:54
  • You could store them somewhere on a network that is accessible by a "master password" or key (or both). I understand that naming them after the hostname makes it obvious which is which, but I have keys and hostnames all connected via ~/.ssh/config anyway. I also use a non-standard port for my home server (which I save in the config file). Finally, use multiple keys in case any specific key is compromised. – Sparhawk Feb 10 '18 at 02:33
  • @Sparhawk could you expand on that - addressing the secure remote storage and retrieval (plain scp I imagine) and make it an answer please? – ivanivan Feb 10 '18 at 03:09
  • @Spathark Any information that he 'saves' would be lost between sessions and he'd have to recreate them each time. In the time that we've spent discussing this, he could have installed Linux to a USB drive and set the keys up that way and they'd be there each time. – Nasir Riley Feb 10 '18 at 04:00
  • @ivanivan Done. – Sparhawk Feb 10 '18 at 23:48

4 Answers4

2

The minute you put that private key online you have given away the kingdom.

jas-
  • 868
  • Why? If you have a server, then your private key is "online" anyway. You just have to log in to get it. – Sparhawk Feb 10 '18 at 23:47
  • That's not the same thing and you know it. Those who have access to the private keys on the server already have access to the server anyway. Your answer puts them in a network location or a different computer which can be accessed by people who aren't supposed to have access to the server. – Nasir Riley Feb 11 '18 at 14:54
1

If you don't want to physically carry around all your keys, then your only option is to store them remotely. If you have access to a server (or any remote computer), you could store the keys on this computer, access this single computer with a key/password, then retrieve your other credentials.

For example, if you have a master key at /media/storage/master.key, you can copy a remote key with

rsync --rsh='ssh -i /media/storage/master.key' user@remote:/path/to/second.key /local/path

Alternatively, you could just ssh to your server, then (from this server) ssh to your second server. Even simpler, just ssh via multiple hosts. Either of these latter options has the added advantage of only ever exposing the current system to the one master key. If it's ever compromised (and you are quick enough), you only need to worry about changing the one master key.

Sparhawk
  • 19,941
  • It's not a good idea to put ssh keys in a network location. – Nasir Riley Feb 10 '18 at 04:31
  • @NasirRiley Why? What is the other option if they OP doesn't want to physically carry them? – Sparhawk Feb 10 '18 at 04:42
  • He said that he has them on a USB so that ship has sailed. The only other option is to install Linux to an encrypted USB. It would be no different than an encrypted laptop. – Nasir Riley Feb 10 '18 at 04:51
  • @NasirRiley The way I understand it, the question says they don't have all their keys on the USB drive. – Sparhawk Feb 10 '18 at 06:38
  • If you look at the last comment that ivanivan made in response to my answer, he says this: "You are ignoring the fact that most of the time, I do have my keys with me on USB" – Nasir Riley Feb 10 '18 at 13:48
  • @NasirRiley "most". The rest of that comment suggests that they don't always have all their keys on the USB drive. – Sparhawk Feb 11 '18 at 10:09
  • He does indeed have them on a USB drive. Does the USB drive just magically disappear and reappear? Your statement that he doesn't want to physically carry them isn't true because he said that he does at times. Even though he's accepted your answer, it's still a horrible idea to store public and private keys in a network location or other computer that other people undoubtedly have access to. Besides, it'd be extremely tedious because he'll have to go through the process every time and that's assuming that he can even write them to the location where private keys are normally stored. – Nasir Riley Feb 11 '18 at 14:52
0

The filesystem on a Linux Live CD/DVD is not writeable and any data that is created is stored in memory and will hence disappear once the session ends. Even if you could create the ssh key and store it in memory, you'd have to create it each time you used the Live Disc.

A better way to achieve what you are trying to do is to install to a USB flash drive and encrypt it. That way, the filesystem will be writeable and the changes will be persistent. You can just create the key to connect to your servers be ready to go wherever you use the flash drive. It will function just like a portable computer with Linux installed.

Nasir Riley
  • 11,422
  • I won't be creating on the LiveCD - I want to retrieve them so I can ssh into some real systems. Mostly this is planned, and I have my needed keys with me on a flash drive. Sometimes though it isn't planned and something in class discussion warrants demos. For example, I shouldn't run portscans on the campus network, but I can on my home network and I have VMs set up with various services running. Being able to get to that VM network requires 3 ssh hops (campus > vps, vps -> home router, home router -> desktop) - all of which I want to use different keys for. – ivanivan Feb 10 '18 at 01:00
  • That isn't possible. The server will look to compare the key to what's in your ~/.ssh directory and you'd have no way of putting the keys there as the filesystem isn't writeable. Even if it were, the changes wouldn't be persistent because they'd be written to memory and you'd have to go through the process every time. It is far easier and sensible to just install Linux to a USB drive and then set up the keys so that everything is available whenever you plug in the drive. That does exactly what you're trying to do with a lot less hassle. – Nasir Riley Feb 10 '18 at 01:26
  • You obviously don't know how a live cd works. The r/o file system typically has an in-ram overlay. With 16gb of ram in the host machine, I routinely boot the live cd image (default Mint 18.x amd64 iso via TFTP server), open a console, install various software packages, and use it for class. – ivanivan Feb 10 '18 at 03:08
  • I know exactly how a live cd works and it will not keep the changes between sessions. Any software that you install will be kept in RAM which is volatile and will be lost between sessions or otherwise you wouldn't need to install it each time which is exactly what I said. Your ssh keys would be lost and you'd have to go through the process each and every time. Just install Linux to a USB flash drive instead of complicating things where it isn't necessary. – Nasir Riley Feb 10 '18 at 03:48
  • You are ignoring the fact that most of the time, I do have my keys with me on USB - but only when I am planning on showing off something in class ahead of time. At times, a student asks a question, the class veers off the planned area, and suddenly having one or more of my keys would be a Good Thing. – ivanivan Feb 10 '18 at 04:15
  • Why not just install Linux and the keys to that USB drive and take that with you to suit your purposes? You wouldn't need that live CD at all. – Nasir Riley Feb 10 '18 at 04:23
  • I am also hoping that the USB is encrypted. – Nasir Riley Feb 10 '18 at 04:41
0

I am not certain I understood the question, but here goes a tentative answer:

Moving private keys around is always a sensitive matter. Ideally you would want to avoid it. Protocol wise, using SSH is a good start. You also definitely want to have a password on the private keys (means they're encrypted).

If you are wondering how to move public keys to target hosts to log in to... well they're public keys so there's no risk to being captured. cat <file> | nc <host>:<port> --> nc -l -p <port> > .ssh/id_rsa.pub is only 1 option.

It is difficult to give advice to naming schemes. It's a matter of opinion. Don't bother obfuscating the names though, you're not gaining anything.

Pedro
  • 1,891
  • 1
  • 13
  • 23