[Bug 2218] New: ProxyCommand as both a resolver and connector

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 2218
           Summary: ProxyCommand as both a resolver and connector
           Product: Portable OpenSSH
           Version: 6.5p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: igor at mir2.org

The hostname canonicalization configuration options is still rather
limited. As that works on DNS level they are of not use if one has to
use ProxyCommand to connect over a proxy connection or through a
gateway where one uses different port numbers to connect to different
intranet names.

What would be ideal is to extend the ProxyCommand to both return the
resolved universal name for the given short name and to connect to that
universal name. For example, the proxy can first print the resolved
name on its stdout before proceeding with other data. Those other data
may be a socket if the proxy utilizes the ProxyUseFdpass option.

Another possibility is to allow an external command to serve as a
resolver. For example, for the given name such command is supposed to
returns the full name that is used for the key lookup and optionally
the ip address and port to connect to. The drawback of this is that the
proxy command may need to duplicate the functionality of a custom
resolver as to geta fully qualified form the resolver may need to
figure out what use to connect to that host.

As a custom resolver may reintroduce the rogue DHCP server problem
discussed in [1], I suppose the returned name should present on
CanonicalDomains list.

[1] -
http://blog.djm.net.au/2014/01/hostname-canonicalisation-in-openssh.html

The name returned by the custom resolver must be a subject to the same
rules that hostname canonicalization uses. Otherwise one can trivially
reintroduce a problem of that the the  that the resolver has to be
written carefully as it trivially

-- 
You are receiving this mail because:
You are watching the assignee of the bug.