I have a web server which is running on a private subnet in AWS VPC, let us call it worker.

I can access the worker VM through a Bastion VM which is in the same VPC but in a public subnet.

Then, I have another VM (public_host) in a public subnet in a different VPC which listenning to the worker VM through SSH tunnel.

inorder to make the SSH tunnel, I need to have the private keys of Bastion and worker on the public_host. I am not security expert, but I guess it is not the best practice to have private keys on the public VM.

can someone please suggest me an approach solve this weak point?

I was thinking to write the listener with the private keys included in a Go app, then compile it and deploy the compiled binaries on the public_host. Would it be considered a more secure approach?

  • 1
    Generally, public keys are shared when one host connects to another by ssh, but private keys are never shared. Are you doing something unconventional, which requires you to share private keys?
    – mti2935
    Apr 8, 2020 at 13:42

2 Answers 2


I assume you mean that public_host must contain the public/private keypair of an identity that's allowed to log into Bastion and worker? As mentioned in the comment on your question, it's unlikely you'd have the private keys of those other systems on the client system.

To address your question, there are a few things you can do to reduce risk or as alternatives:

  1. Ensure the client's keys have a passphrase defined. Now, nobody can use those keys without knowledge of the passphrase, even if they steal the keys.
  2. Store the keys elsewhere (e.g. on an individual user's system) and use SSH authentication forwarding. Anyone who has access to public_vm as root while you're logged in will be able to use those keys (since they're accessed via a pipe/socket in /tmp that root can read/write), but non-root users won't, and the keys simply won't be available at all when you're not actively logged in.
  3. On the destination host, configure the SSH server to restrict exactly what those keys can do. For example, you can force a particular key to run a specific command instead of whatever the user requests, or disallow sftp while still allowing ssh. This can reduce the risk to the server if the client's key is compromised.

It seems you are a bit mixed up in terminology, and I'm not sure I fully understand the question as it stands.

But I think your concerns are a bit exaggerated. It is normal to use SSH keys in a variety of situations. The posture of the particular machine (e.g. "public") doesn't really say whether it is suitable to hold SSH keys to access a given server. As long as any private keys are limited to appropriate users, they should be fairly safe. You could lock down access even further on the "worker" server by using an unprivileged user, and restricting the features and commands usable over SSH by modifying settings in the authorized_keys file on the server.

You must log in to answer this question.

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