you could use socat to forward ssh connections from one host to another
after logging into first one with password or whatever...



On 27 September 2010 09:51, Nicolas Ferragu <[email protected]> wrote:
> Richard,
>
> Yes of course I could use remote command field but as I said before I
> don't want to do a command like "ssh bastion ssh target" since I'd like
> to use Putty as if I where connecting directly my target - ie I'd like
> to use the bastion in a proxy way. In another words, I don't want
> anything but telling Putty to connect to my target in the main field
> Hostname.
>
> Moreover, I don't want to deal with password's accounts since key
> exchanges are mandatory in the project.
>
> I think I gonna modify putty's code to make a direct remote command
> proxy protocol.
>
> Thanks for sharing,
> NF
>
> -------- Message original --------
> Sujet: Re: Multi Hopping by sshserver proxy with different keys
> De : Wilson, Richard <[email protected]>
> Pour : Nicolas Ferragu <[email protected]>, Stephen Dowdy
> <[email protected]>
> Copie à : "[email protected]" <[email protected]>
> Date : 24/09/2010 21:55
>
>> Nicholas,
>>
>> You might try using the PuTTY "Remote Command" field in the SSH panel to 
>> start a script on the Bastion
>
>  host that would check and see if an agent was running, and start one if
> not.
>
> I would recommend expect as the scripting language for this -- it
> emulates an interactive session and
>
>  SSH is designed to not accept passphrases and passwords as parms.
>
> You could pass the passphrase as a parm from the Windows host if your
> security allows it and
>
>  avoid storing the passphrase on the bastion host.
>>
>> HTH,
>>
>> Richard Wilson
>> Rich dot Wilson at hp dot com
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On 
>> Behalf Of Nicolas Ferragu
>> Sent: Friday, September 24, 2010 3:01 AM
>> To: Stephen Dowdy
>> Cc: [email protected]
>> Subject: Re: Multi Hopping by sshserver proxy with different keys
>>
>> Stephen,
>>
>> The problem is that my target key is on the gateway bastion host !
>> The client don't have it. Moreover, the bastion's keys are protected by 
>> passphrases and served by ssh-agent. So can't do any agentforwarding at all..
>>
>> Otherwise, I've never succeeded in having key exchange between bastion and 
>> target while netcating in a proxycommand. It's ending systematically with an 
>> interactive password prompt (not passphrase).
>>
>> Of course the "ssh -t bastion ssh -t target" works well but I don't want to 
>> do it like that because I use a putty client which won't behave 
>> ergonomically if used that way.
>> The same idea applies to your - however excellent - hackery you made with 
>> exclamation ! (I'm on Putty... Sorry for that).
>>
>> Once again this is a schematic view of what I want :
>>
>> Windows             Linux               Linux
>>   |                   |                   |
>> Putty            OpenSSH_5.6p1      Openssh any version
>>   |                   |                   |
>> Client ----------> Bastion ----------> Target
>>   \_________________/   \________________/
>>      Client's Key         bastion's key
>>        (Pagent)             (ssh-agent)
>>
>> Summarizing my needs taking a similarity view like agentforwarding :
>> I'd like to have an ssh-agent hopping.
>>
>>
>>
>> -------- Message original --------
>> Sujet: Re: Multi Hopping by sshserver proxy with different keys De : Stephen 
>> Dowdy <[email protected]> Pour : Nicolas Ferragu <[email protected]> 
>> Copie à : [email protected] Date : 23/09/2010 19:26
>>
>>> Nicolas,
>>>
>>> If i understand your request, fully...
>>>
>>> I'll give you some info for OpenSSH (which you could use via Cygwin on
>>> your windows client), but i don't know if PuTTY has similar
>>> capability. (clearly, you've discovered plink.exe can do similar
>>> things) (while this info may not apply directly to your problem, i
>>> figure it'll be of general interest)
>>>
>>> ----------------
>>> Host bastion
>>>     IdentityFile    ~/.ssh/bastionkey
>>>     User bastionuser
>>>
>>> Host target
>>>     IdentityFile    ~/.ssh/targetkey
>>>     User targetuser
>>>     ProxyCommand ssh bastion nc target 22
>>> ----------------
>>>
>>> If you have both keys on the client, a
>>>
>>>     ssh target
>>>
>>> will "do the right thing(tm)" here by finding the target directive,
>>> indirectly resolving to a bastion connection using the bastion key,
>>> then piggy-backing on the established bastion connection's netcat link
>>> to the target and applying the target key.
>>>
>>> OpenSSH 5.5 or so has a builtin 'netcat' like facility using '-W
>>> target:port', i haven't started using that yet, as my normal systems
>>> (Debian Lenny) don't have that version.
>>>
>>>
>>> Here's some hackery i have in my ~/.ssh/config file:
>>>
>>> -----------------------
>>> # Multi-(user+host) arbitrary gateway hopping
>>> #       usera%hosta!userb%hostb[!userc%hostc...]
>>> # STILL requires using '-l userd' for destination user on command line
>>> (i.e. we ignore last # user in specification # e.g.  ssh -l root
>>> sdo...@zia!root@umds0-vgw
>>> Host    *!*
>>>     GatewayPorts no
>>>     ProxyCommand
>>> $(h="%h";p="%p";ruh=${h##*\!};rh=${ruh##*\%%};ru=${ruh%%\%%*};ru=${ru:
>>> -${USER}};luh=${h%%\!*};lh=${luh##*\%%};lu=${luh%%\%%*};lu=${lu:-${USE
>>> R}};echo ssh -l ${lu} ${lh} "\`type -p netcat nc | head -1\` ${rh}
>>> 22") # h=host, p=port (expanded by openssh cmdline # ruh,rh,ru=remote
>>> user+host, remote host, remote user (successively pulled off
>>> right-hand-side) # luh,lh,lu=local user+host, local host, local user
>>> (pulled off left-hand-side) #
>>> -----------------------
>>> This directive allows you, if you use a Bourne-Shell/posix-shell to
>>> hop via an arbitrary number of [u...@]host[!...] connections via
>>> iterative deconstruction of the target specified within openssh.
>>> If you have any required keys in your client ssh-agent, they'll be
>>> appropriately applied down the chain. (be careful of shell
>>> meta-character expansion of '!' -- I chose that after initially having
>>> chosen '::' as the gateway delimiterd (DECnet style poor-mans
>>> routing), and finding that while it worked for 'ssh', it DOESN'T work
>>> for scp.  '!' works for both ssh and scp.
>>> You can use some other separator like "_", which isn't valid DNS.
>>>
>>> the \`type -p netcat nc | head -1\` is simply used to work on SLES and
>>> *ever other* linux distro, since SLES uses 'netcat' (nc on SLES is
>>> something else).  That whole thing can be replaced with simply 'nc' if
>>> you don't need to deal with SLES. (and that's the primary requirement
>>> for a Bourne-alike shell.
>>>
>>>
>>> If i'm using the "bastion" (gateway) host frequently for multiple
>>> connections (i have a number of systems that have a backend RFC1918
>>> network of compute nodes or data servers), i may use ControlMasters
>>> like:
>>>
>>> Host gw1-* gw2-*
>>>     User            blah
>>>     NumberOfPasswordPrompts 1
>>>     ConnectTimeout  60
>>>     ControlMaster   auto
>>>     ControlPath     ~/.ssh/%...@%h:%p.sock
>>>
>>> That way, i only authenticate once on the gateway host and use that
>>> ControlMaster connection as the piggyback for subsequent connections
>>> to that gateway and any hosts residing behind it.  This is mainly
>>> useful on systems where i'm required to enter a password, instead of
>>> using authorized-key trust.
>>>
>>> --stephen
>>>
>>
>> Post-scriptum La Poste
>>
>> Ce message est confidentiel. Sous reserve de tout accord conclu par ecrit 
>> entre vous et La Poste, son contenu ne represente en aucun cas un engagement 
>> de la part de La Poste. Toute publication, utilisation ou diffusion, meme 
>> partielle, doit etre autorisee prealablement. Si vous n'etes pas 
>> destinataire de ce message, merci d'en avertir immediatement l'expediteur.
>>
>>
>
>
> Post-scriptum La Poste
>
> Ce message est confidentiel. Sous reserve de tout accord conclu par
> ecrit entre vous et La Poste, son contenu ne represente en aucun cas un
> engagement de la part de La Poste. Toute publication, utilisation ou
> diffusion, meme partielle, doit etre autorisee prealablement. Si vous
> n'etes pas destinataire de ce message, merci d'en avertir immediatement
> l'expediteur.
>
>

Reply via email to