I am doing remote devevelop on a remote dev machine. From the remote machine, I need to SSH to other servers and services like the Github. Everything is on the Internet. My desktop is much more secure than the remote dev machine and so I don't want to have private SSH keys lying on the remote dev machine.

The diagram looks like this:

Windows Desktop -> Remote Dev Machine -> Github/other servers.

I feel I have several options here:

  1. SSH Agent Forwarding with Yubikey authentication: ssh -A remote_dev

The problem of this approach is that my desktop ssh-agent contains a lot of keys. I want to forward only specific keys to the remote dev machine. For example, I only want the github key made available to the remote machine. But strangely, I haven't found a way to forward only specific keys.

  1. SSH Jump: On the remote dev machine, I do ssh -J my_desktop github.com

It seems safer and it probably works with Yubikey. But I need to open up SSH access to my desktop, which is a risk.

  1. Ideally, I would like the private keys that will be used on the remote dev machine to either have to be authenticated with the Yubikey, or even better, physically stored on the Yubikey. But I don't know Yubikey will work with the remote machine. Maybe some remote USB forwarding can work?

None of these seem ideal. Does anyone have ideas?


1 Answer 1


I do not recommend forwarding agents or copying keys. If you do end up doing that, consider a dedicated agent that holds just the relevant key(s).

Assuming you're using WSL or some other OpenSSH-compatible command line, you can just do ssh -J remote_dev other_server. This will connect your local system to other_server using remote_dev as a jump-box. Remote_dev will see only the encrypted traffic between your system and other_server. This lets you use your local keys and keychain with other_server. You can be more explicit and specify your local key with ssh -i /path/to/keyfile -J remote_dev other_server

To do this with a YubiKey, you should create an ed25519_sk key type (ssh-keygen -t ed25519-sk). Here's a short guide to using a YubiKey for SSH authentication and another guide for using YubiKey PIV with Windows's native SSH client for further help.

If you're using PuTTY, there is a proxy panel configuration that lets you mimic OpenSSH's -J option.

  • I may be wrong, but my understanding is that ssh -J remote_dev other_server will forward my key on the remote_dev to the other_server. This does not work, as I want to ssh from the remote server to the other_server, after I SSHed from the desktop to the remote server. The keys are on my desktop. So the command I need to run on the remote server is ssh -J desktop other_server. This is not ideal because I have to allow incoming ssh access on my desktop. Maybe ssh -i keyfile -A will forward a single key, but let me test what it actually does. Jan 11, 2023 at 7:43
  • ssh -J A B will forward the network connection from B through A to your local client, not the key/agent. B will see the connection coming from A and will not know that the connection actually comes from your local client. B will have no access to your key at all. I have edited my answer to make that more clear.
    – Adam Katz
    Jan 11, 2023 at 16:00
  • Thanks for the response. Yes, I get this. But it's not what I want. I have D -> A-> G. All my keys are on D. I am logged into A and want to go from A to G without having to install keys on A or forwarding keys from D to A. So I need to do ssh -J D G from A, but that entails me opening ports on D, which is a problem. (One use case is to fetch from github on A without having to deploy keys there). Jan 11, 2023 at 16:16
  • Ah, you actually need resources from jump host A to interact with final target G but you want to use local desktop D's keys. The only ways to do that would be to forward an agent from D through A to G or else to move your content from A to D or G. I suggest the latter, using your jump host exclusively as a tunnel.
    – Adam Katz
    Jan 11, 2023 at 16:28
  • 1
    I wouldn't copy it. I'd create a new key. You said D is more secure than A, so you're compromising the security of your key copying it to A.
    – Adam Katz
    Jan 11, 2023 at 23:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .