f



PuTTY/plink: Supplying public keys to second and subsequent hops on multihop link setup

I have been trying to set up a transparent multihop link through a bastion host to a destination in a remote network that does not accept connections from outside its ownnetwork.

The intention is to avoid storing any private keys on the bastion host to minimise the risks if the bastion is compromised but still use public key authentication for both hops.

I can do this using ssh on a Linux box (source.otherdomain) with a config file that looks like:
================================
ControlMaster auto
ControlPath /home/me/.ssh.tmp/%h_%p_%r

Host bastion
     Hostname bastion.example.com
     IdentityFile ~/.ssh/bastion_key
     User me

Host destination
     Hostname destination.example.com
     IdentityFile ~/.ssh/destination_key
     ProxyCommand ssh -q bastion nc -q0 %h 22
     User me

================================

with *both* the key files on source.otherdomain.

Issuing the command "ssh destination" then gets me an interactive terminal on destination.example.com.

I'd like to be able to do the same from a Windows host using PuTTY/plink.

My experiments so far seem to indicate that there is no way to "feed" the key for the destination host to the ssh session starting up on the destination.

Experimenting by running (paraphrased)
plink bastion.example.com -l me -A -v -i bastion_key.ppk -nc destination.example.com:22

Results in the following trace output (truncated and anonymised):
....
Reading private key file "bastion_key.ppk"
Pageant is running. Requesting keys.
Pageant has 2 SSH-2 keys
Pageant key #0 matches configured key file
Using username "me".
Trying Pageant key #0
Authenticating with public key "bastion" from agent
Sending Pageant's response
Access granted
Opening connection to destination.example.com:22 for main channel
Opened main channel
SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
[hangs here - exit by Ctrl/C]
Gets an error message that ssh was waiting for the right private key exchange but didn't get it.

I can't see how to tell plink (or PuTTY) the name of the private key to use for the destination host.

Am I missing something or is this a non-facility in plink/PuTTY?

Advice gratefully received.

Regards,
Elwyn Davies
0
Elwyn
6/15/2016 11:09:25 PM
comp.security.ssh 4228 articles. 0 followers. terra1024 (490) is leader. Post Follow

3 Replies
447 Views

Similar Articles

[PageSpeed] 54

> I have been trying to set up a transparent multihop link through a
> bastion host to a destination in a remote network that does not accept
> connections from outside its ownnetwork.
> 
> The intention is to avoid storing any private keys on the bastion host
> to minimise the risks if the bastion is compromised but still use public
> key authentication for both hops.
> 
> I can do this using ssh on a Linux box (source.otherdomain) with a
> config file that looks like:
> ================================
> ControlMaster auto
> ControlPath /home/me/.ssh.tmp/%h_%p_%r
> 
> Host bastion
>      Hostname bastion.example.com
>      IdentityFile ~/.ssh/bastion_key
>      User me
> 
> Host destination
>      Hostname destination.example.com
>      IdentityFile ~/.ssh/destination_key
>      ProxyCommand ssh -q bastion nc -q0 %h 22
>      User me
> 

Elwyn Davies  <elwynd@googlemail.com> wrote:
> Experimenting by running (paraphrased)
> plink bastion.example.com -l me -A -v -i bastion_key.ppk -nc
> destination.example.com:22

That looks fine so far - you've got half the job done.

The above command (perhaps minus the -v) is a perfectly sensible thing
to use as the local proxy process for the outer connection to
destination.example.com; in your subsequent trace output, everything
looks fine to me, and the initial session text of
"SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3" is just what you'd expect
from a successful connection to the destination host. This command is
behaving more or less identically to the OpenSSH command you've got
configured as 'ProxyCommand' in your .ssh/config example.

So now all you need is to run a second copy of Plink that uses this as
its proxy command, as you did for OpenSSH. If you have an up-to-date
development Plink from the master branch, you can configure this on
the command line using '-proxycmd'; otherwise you'll have to use GUI
PuTTY to create a saved session specifying that proxy setup, and then
run command-line Plink by loading that saved session by name.
-- 
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
 sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
 )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
 0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>")

0
Simon
6/16/2016 8:10:37 AM
Elwyn Davies  <elwynd@googlemail.com> wrote:
> Experimenting by running (paraphrased)
> plink bastion.example.com -l me -A -v -i bastion_key.ppk -nc
> destination.example.com:22

That looks fine so far - you've got half the job done.

The above command (perhaps minus the -v) is a perfectly sensible thing
to use as the local proxy process for the outer connection to
destination.example.com; in your subsequent trace output, everything
looks fine to me, and the initial session text of
"SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3" is just what you'd expect
from a successful connection to the destination host. This command is
behaving more or less identically to the OpenSSH command you've got
configured as 'ProxyCommand' in your .ssh/config example.

So now all you need is to run a second copy of Plink that uses this as
its proxy command, as you did for OpenSSH. If you have an up-to-date
development Plink from the master branch, you can configure this on
the command line using '-proxycmd'; otherwise you'll have to use GUI
PuTTY to create a saved session specifying that proxy setup, and then
run command-line Plink by loading that saved session by name.
-- 
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
 sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
 )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
 0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>")
0
Simon
6/16/2016 8:11:26 AM
On Thursday, 16 June 2016 09:11:27 UTC+1, Simon Tatham  wrote:
> Elwyn Davies  <elwynd@googlemail.com> wrote:
> > Experimenting by running (paraphrased)
> > plink bastion.example.com -l me -A -v -i bastion_key.ppk -nc
> > destination.example.com:22
> 
> That looks fine so far - you've got half the job done.
> 
> The above command (perhaps minus the -v) is a perfectly sensible thing
> to use as the local proxy process for the outer connection to
> destination.example.com; in your subsequent trace output, everything
> looks fine to me, and the initial session text of
> "SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3" is just what you'd expect
> from a successful connection to the destination host. This command is
> behaving more or less identically to the OpenSSH command you've got
> configured as 'ProxyCommand' in your .ssh/config example.
> 
> So now all you need is to run a second copy of Plink that uses this as
> its proxy command, as you did for OpenSSH. If you have an up-to-date
> development Plink from the master branch, you can configure this on
> the command line using '-proxycmd'; otherwise you'll have to use GUI
> PuTTY to create a saved session specifying that proxy setup, and then
> run command-line Plink by loading that saved session by name.
> -- 
> import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
>  sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
>  )(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
>  0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin@pobox.com>")

Hi, Simon.

Thanks for the pointers.  I see how I am supposed to proceed.

I have now installed the development snapshot
SSH-2.0-PuTTY_Snapshot_2016_06_03.7b9ad09
and tried it out.  OS is Windows 7 Professional with updates installed to today's date.

The command line version works with:
C:\Users\elwynd\Documents\ssh>plink destination.example.com -i destination_key.ppk -l elwynd -A -v -ssh -proxycmd "plink bastion.example.com -i bastion_key.ppk -l elwynd -A -v -nc destination.example.com:22"

Or, taking out the verbose progress messages and unnnecessary bits:
C:\Users\elwynd\Documents\ssh>plink destination.example.com -i destination_key.ppk -A -proxycmd "plink bastion.example.com -i bastion_key.ppk -l elwynd -nc destination.example.com:22"

This latter version will ask you to type in the username for the destination but the username has to be in the options in the proxycmd string.  The -A for agent forwarding is necessary in the outer plink command.

Question: Would it be possible to see the progress messages from the proxycmd?  This might be useful in some cases.

In the process of working out what I should be doing, I think I may have hit on a curiosity and a bug (or possibly two bugs):
- Pure plink command line attempt missing the -nc in the proxycmd string:
C:\Users\elwynd\Documents\ssh>plink destination.example.com -l elwynd -i destination_key.ppk -v -A -proxycmd "plink bastion.example.com -v -i bastion_key.ppk -l elwynd -A"
Starting local proxy command: plink bastion.example.com -v -i bastion_key.ppk -l elwynd -A
We claim version: SSH-2.0-PuTTY_Snapshot_2016_06_03.7b9ad09
Server version: SSH-2.0-PuTTY_Snapshot_2016_06_03.7b9ad09
Using SSH protocol version 2
Incoming packet was garbled on decryption
FATAL ERROR: Incoming packet was garbled on decryption

- Using a PuTTY session definitly seems to have hit a bug:
C:\Users\elwynd\Documents\ssh>plink destination.example.com -l elwynd -i destination_key.ppk -v -A -agent -proxycmd "plink -load bastion"
Starting local proxy command: plink -load bastion
We claim version: SSH-2.0-PuTTY_Snapshot_2016_06_03.7b9ad09
Server unexpectedly closed network connection
FATAL ERROR: Server unexpectedly closed network connection
[Popped up Windows Application error message box: Instruction referenced memory at address 0.  Ooops!]

C:\Users\elwynd\Documents\ssh>

Note: I got exactly the same crash when I forgot to enclose the -proxycmd string in quotes.

I noticed that I was unformed that:
We believe remote version has SSH-2 channel request bug
I doubt if this is a factor but I guess it might be.

Thanks for the advice.

Regards,
Elwyn
0
Elwyn
6/16/2016 6:23:44 PM
Reply: