Score:0

How to setup ssh public key for another machine without access?

pk flag

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.

Score:1
us flag

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

Score:1
ru flag

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!

Score:0
cn flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.