You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "frothga (via GitHub)" <gi...@apache.org> on 2023/03/29 15:02:39 UTC

[GitHub] [mina-sshd] frothga commented on issue #281: SshClient.connect() does not respect username parameter when a default is specified in ssh/config

frothga commented on issue #281:
URL: https://github.com/apache/mina-sshd/issues/281#issuecomment-1488799549

   The original issue above may be due to a bug in my code rather than a bug in MINA. I haven't been able to verify this yet because there are other issues with MINA which also break the resolution process. I can create separate issues if that helps to get them addressed. I'm also willing to submit a pull request to fix some these ...
   
   The comment from December 8, 2022 seems to suggest that I add code to always override values in the returned entry before using them. That means that only forms of ClientSessionCreator.connect() that take a HostConfigEntry are usable. The others are unusable because they don't have the expected behavior. An alternative would be for the implementations of those functions in MINA itself to do this task of overriding fields in the entry, given that the user provided values explicitly. For each, there is a clear no-care value (null for strings, non-positive for port).
   
   Best I can tell from the source code, values provided to resolveEffectiveHost() are only used if values in the selected config entry are no-care. IE: the config file values always override the explicitly-provided values. Simply reversing this logic would go a long way to addressing the above problem.
   
   Intercepting HostConfigEntry is fine if this is a direct connection to the host. For jump hosts, the config file processing should produce the same results as ssh command line. Unfortunately, there appear to be some semantic differences between MINA processing and ssh command-line processing. The ssh man pages specifies that each attribute is resolved individually and that the first matching entry (reading top to bottom in the file) that provides the given attribute is used. This allows wildcard entries later in the file to provide defaults, while more specific entries earlier in the file can provide overrides, on a per-attribute basis. This is apparently not how MINA handles config files. MINA selects one single "best" entry and gets all the attributes from it. Also, MINA does not seem to consider position in the config file. Both of these break the semantics of the ssh config file, making MINA behave differently on a given file that otherwise works correctly for ssh command line
 .


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@mina.apache.org
For additional commands, e-mail: dev-help@mina.apache.org