0

I found quite a few posts about migrating ssh keys to a new host, but couldn't find much about migrating from one user to another on the same host...

We are migrating a NAS share to a new platform, and in the process are introducing new generic application IDs. I have been asked to copy the ssh keys from the existing generic ID to the new one. The ID will be accessing the same hosts from the same hosts, but it will be using the new ID. What is the best practice for copying the keys so that our 100+ applications that can use this ID will not run into the whole "add this key (yes/no)" question which would cause a massive number of failures?

Tim S.
  • 147
  • 8
  • I'm confused by the question. Are you talking about the host keys (which shouldn't be an issue if you're using the same host), or the per-user public and private key pairs? – Gordon Davisson Jun 16 '18 at 06:58
  • Correct - the public/private key pair. Is it worth moving the old user IDs private keys to the new user, (along with the known_hosts file) so that they connect the same way to the same hosts? I'm thinking thats the only way to accomplish this without creating a whole new set of keys for the new user. I'm basically looking for a best-practice here, hoping that new keys aren't needed. (but again, if that's the case, so be it.) – Tim S. Jun 16 '18 at 16:41
  • Ok, I'm still confused. Are you changing the user IDs on the client side of the SSH connection, or the server side, or both? Are the applications we're talking about on the client (and needing access to server resources) or on the server (and some client runs them via some sort of automated remote connections)? – Gordon Davisson Jun 16 '18 at 20:35
  • Both -- we have a cluster of servers that execute code on those servers themselves, but also connect (usually via ssh or sftp, port 22 either way) to other hosts to remotely execute code. – Tim S. Jun 16 '18 at 21:12

2 Answers2

1

In addition to copying the keys, copy the ~/.ssh/known_hosts file, which contains identification fingerprints for all hosts to which the user has connected. If needed, you can also use the file /etc/ssh/ssh_known_hosts if you want to seed all users on a given system with pre-validated host keys.

crimson-egret
  • 3,276
  • 17
  • 20
-1

Is this what you want?

https://superuser.com/a/125326/417776

Use the -o option,

ssh -o "StrictHostKeyChecking no" user@host
YuMS
  • 1
  • No, policy dictates we cannot turn keychecking off. I want to migrate the ssh keys so that the -o option is not necessary. If it turns out that generating a whole new key is the best practice, so be it, but if there is a secure way to salvage the keys we have, I'd rather do that. We connect to hundreds of hosts with this ID. – Tim S. Jun 13 '18 at 18:58
  • Even if it were acceptable, it is, in most cases, bad security as it allows MITM attacks. – crimson-egret Jun 15 '18 at 14:36
  • Right -- I wasn't going to argue that I think it's a horrible idea -- that's the reason why it was not allowed. :) – Tim S. Jun 18 '18 at 12:55