[Bug 2578] -W should honor -4 and -b

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2578

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to Marc 'Zugschlus' Haber from comment #0)
> ssh -W should honor -4 and -b options given on the same command line.

It does.  They apply to the connection from the client to the server as
they always do.

$ ifconfig enp5s0
enp5s0: [...] inet 192.168.32.1

$ ssh -b 192.168.32.1 -4 -W server:22 server
SSH-2.0-OpenSSH_7.2

$ ssh -b 192.168.32.2 -4 -W server:22 server
bind: 192.168.32.2: Cannot assign requested address
ssh: connect to host server port 22: Cannot assign requested address

> In practice, ssh -4 -W host:port will use IPv6 if host has an AAAA
> and an A record

The client sends the hostname to the server which then resolves it, so
that's dependent on name resolution config on the server side.

> and ssh -b valid.ipv4.address -W host:port will
> give "address family not supported" error if host has an AAAA and an
> A record.

A valid IPv4 address on the server or the client?  It should be on the
client.

Anyway, as to the enhancement request: we couldn't use -4/-6 or -b for
this since they already have meaning in this case.

For the IPv4 or IPv6 cases you can already resolve the address on the
client side and pass the address to connect to on the command line, eg:

$ ssh -4 -W "[fe80::5054:ff:fef6:2ea%vio0]:22" server
SSH-2.0-OpenSSH_7.2

We could potentially add something to the client to allow the
resolution on the client side although I am not convinced it's worth
doing.  What is your use case for it?

For the remote bindaddress case I don't think it's possible at all
since there's nothing in the protocol message to specify a bind
addresses for forward connections (see RFC4254 section 7.2).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.