11

These is my scenario:

  • Host C is not accessible from A.
  • Host B is accessible from A.
  • Host C is accessible from B.
  • Both B and C have ~/.ssh/id_rsa.pub (from A) in authorized_keys
  • B does not have the private key (~/.ssh/id_rsa), since it would be a security risk (the key is personal).
  • since B doed not have the private key, it is not possible to login to C from it

How can I use the key in host A to login to host C? Is this possible? I fear not.

(similar but different to this question)

EDIT

What I would need is a way to provide, on-the-fly (stdin or similar), the private key to the ssh hop in B, without it ever touching the filesystem in B. Is this possible?

blueFast
  • 4,200
  • 13
  • 37
  • 54
  • make ssh tunnel over host B. – Ipor Sircer Oct 09 '18 at 10:45
  • You say "B does not have the private key (~/.ssh/id_rsa), since it would be a security risk". Why? Are there multiple users that connect to _the same_ account in B? Is it feasible to create multiple accounts in B (one for user) so to have private keys in B, too? – Daniele Santi Oct 09 '18 at 10:47
  • @MrShunz not to the same user, but several users can become root ... – blueFast Oct 09 '18 at 10:51
  • @IporSircer cool! How? Beware: private key is not in host B. – blueFast Oct 09 '18 at 10:51
  • @IporSircer that's what I thought at first, but if I understood correctly, he cannot connect from B to C via keys. – Daniele Santi Oct 09 '18 at 10:58
  • I don't understand why the answer from the linked question doesn't also apply. Just use agent forwarding. – bodgit Oct 09 '18 at 11:01
  • @MrShunz: that's why he should create a tunnel on host B to host C, then he can ssh from A to C via the created tunnel and using private key on host A. – Ipor Sircer Oct 09 '18 at 11:04
  • @IporSircer sure! But if he can already connect from B to C then it's a non-issue. That's the solution proposed on the linked answer. That's why I assumed he _cannot_ connect from B to C, quoting the OP "since B does not have the private key, it is not possible to login to C from it". – Daniele Santi Oct 09 '18 at 11:08
  • Making ssh tunnel to port 22 of host C doesn't mean it's connected. It's only a portforward where he can make ssh connection from host A to host B directly. Type `man ssh` to know more about ssh tunnels. Tunnel only tries to connect to host C, when he start using the tunnel. He can forward also port 80 or any other. It's only a portforward, not an authenticated connection. – Ipor Sircer Oct 09 '18 at 11:14

3 Answers3

10

If you are using a recent version of OpenSSH you can simply type:

ssh -J B C

If you are using a slightly older version without -J support you can use a slightly more elaborate syntax:

ssh -o ProxyCommand='ssh -W %h:%p B' C

If you need this every time you ssh from A to C it can be useful to add an entry in your .ssh/config file looking like this (in recent versions):

Host C
   ProxyJump B

Or like this (in slightly older versions):

Host C
   ProxyCommand ssh -W %h:%p B

Using either of the above you can simply type ssh C to open the connection. This is particular useful when you are using ssh indirectly through one of the many tools which utilize ssh for their transport. Not all of these tools provide a straightforward way to pass command line flags to the ssh command.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • 3
    You can also automate this by creating ~/.ssh/config (on A), and adding an entry for `Host C` with the option `ProxyJump B` (or `ProxyCommand ssh -W %h:%p B` as appropriate). Then `ssh C` will do the right thing. – Gordon Davisson Oct 09 '18 at 19:16
  • @GordonDavisson That's a good point and particular useful in case you aren't invoking `ssh` directly but rather indirectly through another tool which uses `ssh`. – kasperd Dec 07 '18 at 15:08
0

I stumbled on this question while looking for the same thing. The solution here with keys looks like:

ssh -o ProxyCommand="ssh -i /path/proxy.pem -W %h:%p user@proxy_host" -i /path/target.pem user@target_host

I can't take credit here though, as this solution is from another question, but I have verified that this approach works.

Bradley Forney
  • 246
  • 2
  • 5
0

That's rather easy. Just use agent forwarding (-A option on ssh).

Sample:

#On machine A use
ssh -A user@<machine_B>
#Then on machine B use
ssh -A user@<machine_C>

No need for copying private keys all over the place. -A forwards only any SSH Agent requests over to the first machine in the chain, so a private key on machine A can be used as long as you don't switch users on intermediate machines.

If you change your user on machine B (e.g. with a su foo to user foo), the agent forwarding does not work any longer, as the next connection is done as user foo with it's own keys.

Marcel1980
  • 101
  • This will give B access to use any keys in that agent for as long as the connection stays open. There are methods to combine it all into a single command being invoked on A without agent forwarding, which means they will be more secure and usually also more convenient. – kasperd Oct 09 '18 at 12:25
  • But just if someone impersonates that user on B. Didn't know about -J, so good point, but does this allow for using different usernames on B than on C? Sometimes we have servers with differing usernames but same keys (e.g. admin_server and admin_poi or something along this line) – Marcel1980 Oct 09 '18 at 12:34
  • I think you can use a syntax like `-J user@hostname` (the machine I am on at the moment has a too old version of ssh to have `-J` so I can't test it right now). – kasperd Oct 09 '18 at 12:38