Conversation

Notices

1. Embed this notice
   Miakoda (hellomiakoda@pdx.social)'s status on Thursday, 09-Apr-2026 21:38:36 JST Miakoda

   I have what I fear may be a stupid #Linux question...
   If I set up an ssh key, upload it to the server, and then disable password login...
   When I want to ssh from another machine? How would I then upload that key to the server?

   • Embed this notice
     Miakoda (hellomiakoda@pdx.social)'s status on Thursday, 09-Apr-2026 22:09:06 JST Miakoda

     in reply to

     • Juan R. Loaiza

     @juanrloaiza Ok, so that does work the way I'd thought.
     Then... is there good reason not to sync ~/.ssh between my laptops?

   • Embed this notice
     Juan R. Loaiza (juanrloaiza@hcommons.social)'s status on Thursday, 09-Apr-2026 22:09:08 JST Juan R. Loaiza

     in reply to

     @hellomiakoda As others pointed out, you can use the same private key in both machines A and B, or you can generate a new key pair for machine B, and use machine A to ssh into the target and add B's public key. Then you can use B's private key to ssh into the target and keep separate keys for A and B.

   • Embed this notice
     Miakoda (hellomiakoda@pdx.social)'s status on Thursday, 09-Apr-2026 22:11:01 JST Miakoda

     in reply to

     • Juan R. Loaiza

     @juanrloaiza Also trying to grok the whole ssh agent in KeePassXC as an option. Last time I messed with it, I broke shit. BUT... the instructions I'm looking at have a step I don't remember seeing last time, so maybe that's why.
     Also last time I also attempted to use SecretService... and I'm wondering if THAT is actually what broke shit

   • Embed this notice
     Kat S (kats@chaosfem.tw)'s status on Thursday, 09-Apr-2026 22:18:24 JST Kat S

     in reply to

     @hellomiakoda Not a stupid question at all; it's a common enough challenge to overcome.
     I've been known to pull the following old-sysadmin dirty hack:

     • 0n the workstation that's already set up, open ssh sessions to the server and the new machine respectively
     • cat the private key on the new machine
     • Open ~/.ssh/authorized_keys on the server in a text editor
     • Copy-paste from one terminal to the other, using swipe-and-middle click (method may vary between distributions).
     • Save that file.
     • Test that you can connect from the new machine, and adjust/edit as necessary.
     • Once you know it's working, clear or exit the terminal on the new machine.

     Of course, this assumes the new machine has ssh running and that it accepts the key from your first workstation.

     Failing that, Manu's sneakernet solution is pretty reliable.

   • Embed this notice
     Miakoda (hellomiakoda@pdx.social)'s status on Thursday, 09-Apr-2026 22:55:22 JST Miakoda

     in reply to

     • Jason Stuart

     @JSCybersec I'm trying to set it up for local machines that don't really need the extra security, so that I can learn and understand this overlooked section of Linux knowledge

   • Embed this notice
     Jason Stuart (jscybersec@infosec.exchange)'s status on Thursday, 09-Apr-2026 22:55:23 JST Jason Stuart

     in reply to

     @hellomiakoda So the private key portion you use to authenticate against the public key portion which is uploaded to the server is supposed to be the portable secured portion. Basically that would be secured on a hardware token or encrypted USB. And you'd be able to move that from machine to machine but never copying the private key to a foreign machine.

     So what is your use case, I might be able to add more clarity if I understand how you're planning to use it.

     EDIT: Just re reading this and I've confused myself now. So even I need to re-read how it works LOL.

   • Embed this notice
     Miakoda (hellomiakoda@pdx.social)'s status on Friday, 10-Apr-2026 15:34:10 JST Miakoda

     in reply to

     • Jason Stuart

     @JSCybersec Yeah, I did know keys can have a password to decrypt the key.
     See, I thought there was some master list of pub keys in the server. I didn't realize it was under ~/.ssh.
     So if a key is compramised, that's where I remove it from. Ooooh, is that why the keys have user@client in them?! So I can find which one is what?!

   • Embed this notice
     Jason Stuart (jscybersec@infosec.exchange)'s status on Friday, 10-Apr-2026 15:34:11 JST Jason Stuart

     in reply to

     @hellomiakoda Okay, so on each machine you want to connect to you add the publickey portion into the authorized_keys file for the user you're connecting as. Then the machine you're connecting from has to have the private key in the ssh profile (usually under the user home directory ~/.ssh

     Then when you connect to the machine using your key.

     So say on "remote" machine I am user bob and on local machine I'm user bobmcbobberson.

     On remote machines bob profile I open the authorized_keys file under the bob/.ssh folder and add my (bobmcbobberson) public key text into it)

     Then on my local machine I ssh into the remote machine -> ssh bob@remotemachine

     Depending on your key you might need to type a password to open the private section which will authenticate against the remote machine. If it prompts you for a password to connect to the remote machine then password auth is still enabled