SSH Keys and migrating to a new device
-
@stacksofplates said in SSH Keys and migrating to a new device:
@JaredBusch said in SSH Keys and migrating to a new device:
I never want to have the same private key on multiple devices, so my desktop and my laptop both have their own keys with the public keys spread as needed.
I am getting a new laptop now and the old one will be decommissioned.
It would be easier to migrate my private key from old laptop to new prior to wiping the drive. because then the million places (yes an exaggeration) where I have the public key do not have to be updated.
I know how to handle it technically, but I was wanting your opinions on the matter.
If it's not all under version control, auto mounted home directories, or stored in LDAP I'd just move the key.
But I'm lazy.
Nothing under automation at all.
-
So RTFM and it seems like
ssh-copy-id
is the correct command to do this. Is that correct? I know this isn't what you're asking, but anytime something like this comes up that I haven't done I attempt to figure out how to do it.ssh-copy-id [email protected]
-
@wirestyle22 said in SSH Keys and migrating to a new device:
So RTFM and it seems like
ssh-copy-id
is the correct command to do this. Is that correct? I know this isn't what you're asking, but anytime something like this comes up that I haven't done I attempt to figure out how to do it.ssh-copy-id [email protected]
No, that adds the public key to the
authorized_keys
file. -
What you have to migrate is your
id_rsa
andid_rsa.pub
[12:39 jbusch ~]$ ls -la .ssh/ total 28 drwx------. 2 jbusch jbusch 4096 May 28 23:50 . drwxrwxr-x+ 32 jbusch jbusch 4096 Jun 28 21:38 .. -rw-------. 1 jbusch jbusch 3243 May 28 23:50 id_rsa -rw-r--r--. 1 jbusch jbusch 745 May 28 23:50 id_rsa.pub -rw-r--r--. 1 jbusch jbusch 8079 Jun 18 19:58 known_hosts
-
I think moving it is fine. It's like migrating a profile. In some big places where I have worked, your keys were kept in NFS so that no matter here you signed in from, you got your central key. I agree with not having the same key in multiple places. But shifting it from one machine to another is fine.
-
Here is how you do it assuming Fedora/Korora 25
We are assuming that the username is the same on both machines because this is a migration.
- On the new machine, start the SSH server. Since this is a laptop/desktop, it should not be running normally.
systemctl start sshd
- On the new machine, make sure you have no private key yet. There should not be anything here. If there is, you have to figure out what you are already using a private key for.
[12:53 jbusch ~]$ ls -la ~/.ssh/ drwx------. 2 jbusch jbusch 4096 May 28 23:50 . drwxrwxr-x+ 32 jbusch jbusch 4096 Jun 28 21:38 ..
- On the old machine use rsync to transfer everything.
rsync /home/jbusch/.ssh/* [email protected]:/home/jbusch/.ssh/ [email protected]'s password:
- On your new machine turn the SSH server back off
systemctl stop sshd
- Test a login from your new machine to some server
ssh 10.254.0.108 Last login: Fri Jun 30 12:53:31 2017 from 24.14.15.238 [jbusch@relay ~]$
-
@JaredBusch Thanks. This is great. I'm going to spin some VM's up on my home server and do this
-
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
-
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
I agree. And you want your keys labelled with their origination device, easier to track.
-
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
Understood. That would make administrating those devices unnecessarily difficult
-
@scottalanmiller said in SSH Keys and migrating to a new device:
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
I agree. And you want your keys labelled with their origination device, easier to track.
If you're nuking the profile after you migrate it what benefit would that give you?
-
@wirestyle22 said in SSH Keys and migrating to a new device:
@scottalanmiller said in SSH Keys and migrating to a new device:
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
I agree. And you want your keys labelled with their origination device, easier to track.
If you're nuking the profile after you migrate it what benefit would that give you?
He means on the server side.
-
@wirestyle22 said in SSH Keys and migrating to a new device:
@scottalanmiller said in SSH Keys and migrating to a new device:
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
I agree. And you want your keys labelled with their origination device, easier to track.
If you're nuking the profile after you migrate it what benefit would that give you?
That you know that that one key still represents just one device.
-
@JaredBusch @scottalanmiller OH, got it. Thanks.
-
@JaredBusch said in SSH Keys and migrating to a new device:
@wirestyle22 said in SSH Keys and migrating to a new device:
@JaredBusch Thanks. This is great
Again, you want a unique private key on every device, in order to lock things out discretely. Otherwise if you simply had the same private key everywhere, you would lose all access form every device just because your laptop was compromised and you had to lock out the public key.
So this process is really only something that should ever happen on a profile migration.
Ya it's a big advantage to having automounted home directories or having LDAP store the keys. You can easily revoke and add another key and have it work everywhere.
Or using Kerberos instead of pub/priv keys.
I realize @JaredBusch knows this, but for others who may not.