0

This might be a stupid question but I have to ask it anyway:
I already did setup an ssh public key for my client machine A. I copied the public key to the remote server, everything works fine, I can log in from machine A.

Now I also want to access that server from another machine and following best practices, I wanted to generate another key for client machine B, rather than using the key from machine A again. Of course I can generate the key pair but I'm not able to copy that new public key to the server because client machine B has no access to server, only A has.

The only solution I see at the moment seems to be taking the new public key on a USB stick to client machine A and copy it to the server from there, but that seems to be a little tedious and not very practical when n machines are located rather far from each other.

What is the right approuch to do that?

The client and the server are both running Linux.

antimatter
  • 15
  • 3

3 Answers3

1

Well, you WILL have to transfer the public key to the remote server somehow.

However since the public key is not confidential (hence the name), feel free to copy it on an USB stick, upload it somewhere, put it in a note, etc...

Just make sure the key you add on the server is indeed the one you uploaded from your client!

mhutter
  • 111
  • 4
1

I usually move ssh keys by copy and paste. but you can also send them via email, http, netcat, etc, they're just text.

If you can get the public key for machine C onto machine B you can then ssh from B to A and install the key for C

Jasen
  • 826
  • 6
  • 12
0

Not sure there is a right approach, you still need to access the server somehow and since the machine A is only access point for now, you still need to get it physically at least once as well as other n machines. So, why not to collect all pubkeys to the USB stick and move it to machine A to spread to the server's users' home .ssh config dirs?

Without USB stick there are some options also.

Var #1. Temporary enable password login on server from machine A. Generate keypairs and copy pubkeys to server from machines B, C, D, etc. just in normal way. Disable password login to server.

Var #2. If even temporary password login is considered as a security flaw, create a temporary user on server that has access nothing but its home directory, enable password login for this user only. Generate keypairs and copy pubkeys to server from machines B, C, D, etc. to this user's home directory. Pubkey is not a confidential and its potential hidjaking is considered to be a safe situation, however its spoofing is not, so you may consider encrypting or signing it somehow (gpg). Login to server from machine A, spread pubkey to server's users, disable the temporary user used.

Var #3. If the ssh server reboot is not an option, you could make machine A to be a temporary ssh server and use it as a intermediate station to copy ssh pubkeys to the real server.

Var #4. Use another communication channel (another remote server, maybe even public one, e-mail, etc.). Once again, pubkey is not a confidential, but make sure to sign them to protect from spoofing.

Nick
  • 126
  • 5