openssh unix dev - Jan 2017 - proposed change to ssh_connect_direct()

if the remote hostname has multiple ip addresses, ssh_connect_direct
will currently loop and try each address in sequence until one works.

I'm interested in making ssh tries each address concurrently and
return success on the first one that connects. in the land of host
certs and ssh bastions, this can be incredibly effective.

are there any objects to me working up a patch to implement this?

Cheers,
peter

so I spent a bit of time looking at this and it seems like the only
way to go, at least if I want to keep it in ssh_connect_direct(), is
to use pthreads. further, it seems like getting that accepted is
something of a long shot:

https://github.com/openssh/openssh-portable/commit/328118aa798878a68398b92ba85adfb630bc5434

:)

so, approaching this from a different angle, what if I wanted to have
something else establish the tcp connection and then fork/dup2/exec
ssh and pass off the fd's for the network connection? This is how I
*sort of* understand -W to work, but that's the sshd code path, not
the client.

is something like this acceptable, at least in theory?

Cheers,
peter


On Thu, Jan 5, 2017 at 7:03 AM, Peter Moody <mindrot at hda3.com>
wrote:
> if the remote hostname has multiple ip addresses, ssh_connect_direct
> will currently loop and try each address in sequence until one works.
>
> I'm interested in making ssh tries each address concurrently and
> return success on the first one that connects. in the land of host
> certs and ssh bastions, this can be incredibly effective.
>
> are there any objects to me working up a patch to implement this?
>
> Cheers,
> peter

On Sat, Jan 7, 2017 at 2:30 PM, Peter Moody <mindrot at hda3.com>
wrote:
> so I spent a bit of time looking at this and it seems like the only
> way to go, at least if I want to keep it in ssh_connect_direct(), is
> to use pthreads. further, it seems like getting that accepted is
> something of a long shot:
Sorry, pthreads is a non-starter.

I would have thought that using non-blocking connect (ie set
O_NONBLOCK on the fds, initiate the connections then select on the set
until one succeeds) would be feasible, though.
> so, approaching this from a different angle, what if I wanted to have
> something else establish the tcp connection and then fork/dup2/exec
> ssh and pass off the fd's for the network connection?
That's how ProxyComand and ProxyUseFdpass work.  Your dialler is a
separate program so it can do whatever you like, including use
pthreads if that's your thing.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.