SOCKS proxy connections fail with hostname-based ACLs due to local DNS resolution performed by SSHJ

Current Behaviour:

When YADE (JS7) establishes a connection through a SOCKS proxy, the underlying SSHJ library performs local DNS resolution on the target hostname before opening the SOCKS connection, and sends the resolved IP address to the proxy instead of the original hostname. HTTP proxies are not affected.

• This differs from YADE1 (JS1), which uses the JSch library. JSch implements SOCKS4 and SOCKS5 as separate code paths, and for SOCKS5 it sends the target hostname itself, letting the proxy perform DNS resolution.
• SSHJ, by contrast, uses a single unified implementation covering both SOCKS4 and SOCKS5 — the Java JDK's own public proxy interfaces don't distinguish between the two, and the JDK relies on an internal fallback for SOCKS4-only proxies. Following that same model, SSHJ always resolves the hostname locally and sends an IP, since that's the one approach guaranteed to work against either proxy type without needing to know in advance which one it's talking to.
• As a result, connections through a SOCKS5 proxy whose access control rules are written against hostnames/FQDNs (rather than IP addresses) will succeed with YADE1 but fail with YADE2, for the identical proxy configuration — even where the proxy itself is fully SOCKS5-capable and could accept a hostname. This affects any environment where SOCKS proxy access rules are maintained at the hostname level rather than IP level.

Observed error:
java.net.SocketException: SOCKS: Connection not allowed by ruleset

Hence, this is not considered a defect, but an incompatibility between YADE1 (JSch) and YADE2 (SSHJ) arising from their different underlying libraries. Reusing JSch in YADE2 is not viable, as the JSch project has been unmaintained for years.

Workaround:

No YADE-level configuration currently controls this behavior. The only interim workaround is on the network/proxy side: add the target host's resolved IP address as an additional whitelist entry alongside the existing hostname-based rule — viable only where the target's IP is static. 

Desired Behaviour:

• By default, hostname resolution behavior should match JSch's SOCKS5 handling — the hostname should be forwarded to the SOCKS proxy rather than resolved locally.
• Trade-off introduced by this change,making hostname-forwarding the default will create a new, opposite incompatibility for environments using a SOCKS4-only proxy, since SOCKS4 cannot accept hostnames at all — those users will need to switch to specifying IP addresses directly in their YADE configuration once this change ships. This is considered an acceptable trade-off, as the large majority of proxy products for the past 20+ years support SOCKS5.

Maintainer Note

• The following mechanisms are introduced to control hostname resolution:
  • File Transfer configuration (XML)
    • ProtocolFragments / ... / SOCKSProxy / ResolveHostname - boolean - default false
      • false
        • The destination hostname is passed to the SOCKS proxy without local resolution.
        • The SOCKS proxy resolves the hostname using its own DNS configuration.
        • This allows connections to hostnames that are only resolvable from the proxy's network and allows hostname-based proxy rules, such as whitelists, to be applied.
        • However, this can fail when using a SOCKS4-only proxy server, as SOCKS4 requires an IPv4 address rather than a hostname.
      • true
        • The destination hostname is resolved locally before the connection is established.
        • The SOCKS proxy receives the resulting IP address.
        • This can be required when using a SOCKS4-only proxy server, but can fail if the hostname cannot be resolved locally or if the SOCKS proxy uses hostname-based rules, such as a whitelist.
  • Environment variable
    • PROXY_SOCKS_RESOLVE_HOSTNAME - boolean - default not set (false)
      • Environment-wide setting evaluated by the YADE CLI and YADE JITL job.
      • This applies to both SOCKS proxies: the source proxy and the target proxy, if configured.
  • YADE CLI and YADE JITL job argument
    • proxy_socks_resolve_hostname - boolean - default not set (false)
      • This argument applies to both SOCKS proxies: the source proxy and the target proxy, if configured.
• Setting/Argument Scope and Precedence
  • File Transfer configuration (XML)
    • If this setting is explicitly configured, it takes precedence over the corresponding environment variable PROXY_SOCKS_RESOLVE_HOSTNAME.
    • The value is overridden when the corresponding argument is specified in the YADE JITL job or as a YADE CLI argument.
  • YADE CLI and YADE JITL job argument
    • If this argument is explicitly configured, it takes precedence over the configuration file and the corresponding environment variable PROXY_SOCKS_RESOLVE_HOSTNAME.

Patch

• A cumulative patch is available for JS7 version 2.8.4.
  • Note: The patch includes all YADE issues related to 2.8.5 that have been fixed so far
  • Download: s7_agent.2.8.4-PATCH.YADE-662.jar [ sha256 ] [ sig ] [ tsr ]
  • Applying the patch
    • Since YADE-626, YADE can be executed not only as a standalone Shell Job, but also as an integrated Java JITL Job.
    • This means the patch can/should be deployed in two locations:
      • <agent install>/lib/patches - for YADE configured as a JITL Job (com.sos.jitl.jobs.yade.YADEJob)
        • See JS7 - Patches for Agent
        • Note: The Agent instance has to be restarted to apply patch.
      • <agent install>/yade/lib/patches - for YADE configured as a Shell Job
        • Note: The Agent instance does not need to be restarted to apply the patch
  • Note YADE-662
    • Includes the described behavior of the YADE JITL job and YADE CLI arguments, including environment variable handling
    • Does not include the File Transfer configuration GUI functionality to add or modify the ResolveHostname setting.
      • The patch contains the parsing and handling of the new ResolveHostname configuration element. For example, it will work if a separate YADE configuration file is used or if the YADE JobResource is adjusted manually.