Re: [PLUG] Sharing SSH keys between Linux hosts

On Fri, Jan 9, 2026 at 1:11 PM brent saner via plug <plug@lists.phillylinux.org> wrote:

On Fri, Jan 9, 2026 at 10:26 AM Mike Leone via plug <plug@lists.phillylinux.org> wrote:
(SNIP)
Now we're (finally!) upgrading/replacing those hosts, so I am starting clean, 2 brand new hosts. But we will configure them to use the same script, same as the previous hosts.

EL 9.x or 10.x?

10.0.

Anyway, the script relies on pre-shared SSH keys (no it can run as a cron job, no prompting for credentials). So I just want to be clear on the steps I need to do, enable the sharing of keys.

For what it's worth, there is a multitude of software that can manage SSH pubkey distribution. If you're using SSSD with AD/LDAP auth, you can even store users' SSH pubkeys in the directory itself bound to their user object and SSSD can dynamically fetch it/them at runtime directly.

We are not, but tha['s good to know, thanks!

1. I need to create an SSH key with the user who will be executing the script. Easy enough.

You'll want to use ED25519. If you're on EL10 it's the default, otherwise:

I found that out. I decided to use RSA instead. Just what I am used to.

ssh-keygen -t ed25519

- I suppose this key should have a passphrase. I don't think I used one the last time, way back when ...

Not if you want to use it in an automated fashion, no. If you do, it either needs to be "passwordless" (unencrypted) or manually (or with like. expect(1) and a secure secret storage like Vault/OpenBao or something with a systemctl --user service that starts an ssh-agent, unlocks the key, and adds it to the agent first or the like).

It's generally easier/better to just use a specific unencrypted SSH keypair for automation and using the command parameter to restrict the allowed actions for that key in the target's ~targetuser/authorized_keys. (e.g. command="/absolute/path/to/backup/script.sh" ssh-ed25519 ... on the initiator, and command="internal-sftp" on the targets.)

2. I need to copy said SSH public key over to the other host

ssh-copy-id -i .ssh/id-rsa.pub user@destination

Well, ideally ed25519, not rsa, but generally yes.
Note that the hostkey will rotate in newer versions of SSH (8.5p1+) (unless explicitly disabled) so make sure the target servers' config evaluates to apply UpdateHostKeys yes (it's the global default since, also, 8.5p1 - you only need to add Host blocks if you set UpdateHostKeys to something other than yes).

I didn't set up the host in the DMZ but I'll pass that along. It is also RH 10.0.

(Note that this is perfectly fine to do; hostkey rotation is signed by previous hostkeys, so UpdateHostKeys is generally safe to enable. It is very, very different from setting StrictHostKeyChecking to no. UpdateHostKeys must be explicitly set to yes even if StrictHostKeyChecking is set to accept-new.)

Q; The "user@destination". So this a user with the access rights to be able to access what my script will be doing (in my case, copying from that DMZ host back to this host, so that user needs access to the directories where the files will be coming from).

Using metasyntactic variables to make things more explicit here.

"DMZ" host: A
Servers to be backed up: B, C

I wasn't clear. There's no "back up", per se. Just a set of files transferred from DMZ host to internal host.

Username on A initiating the backup: foo
Username on B, C with access/permissions to the files to be backed up: bar

Thus foo@A would create a key:
ssh-keygen -t ed25519

Might as well stage the hostkeys, as well:

foo@A $ for tgt in B C ; do ssh-keyscan ${tgt} | sed -re '/^#.*$/d' >> ~/.ssh/authorized_keys ; done

This public key would then be distributed/copied into:
B:~bar/.ssh/authorized_keys
C:~bar/.ssh/authorized_keys

If you have password auth enabled still,

foo@A $ for tgt in B C ; do ssh-copy-id -i ~/.ssh/id_ed25519 ${tgt} ; done

Alternatively just copy the contents of A:~foo/.ssh/id_ed25519.pub to the authorized_keys on each host manually.

Ensure that you disable password auth now if it's enabled. :P

Then on B and C, edit ~bar/.ssh/authorized_keys and, for the pubkey for foo@A: change:

ssh-ed25519 AAAA...

to

command="internal-sftp" ssh-ed25519 AAAA...

(If you want to restrict it to a specific directory root, use command="internal-sftp -d /path/to/basedir")

So if I am user "mike" on the protected host, and I login to the DMZ host as "the-ftp-admin-acct", in the command above I would use:

ssh-copy-id "the-ftp-admin-acct@dmz-host"

(No, the DMZ won't be using FTP, it will be SFTP. It's just a user name LOL)

See above.

Q: I won't need my SSH passphrase now, right? Just the password to the account over on the other host?

If you followed the layout above exactly, foo@A does not need any password at all, whatsoever, to SFTP to B and C.

And it doesn't, I have checked.

Q: I shouldn't need to do the reverse, right? If all I am doing is going protected-host=>DMZ-host, then I don't need to ssh-copy-id from the DMZ-host to the protected-host. This is a 1 way share, for my use case.

The keypair needs to be generated on the client only.
The public key (*.pub) needs to be added to the target user's ~/.ssh/authorized_keys only.

(You technically CAN do entire host-based authentication for SSH instead of adding it to each target user's authorized_keys, but lol, don't do that.)
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug

Mike. Leone, <mailto:turgon@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>