[
https://issues.apache.org/jira/browse/SSHD-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306808#comment-17306808
]
Lyor Goldstein commented on SSHD-1141:
--------------------------------------
{quote}
Should the client do that?
{quote}
Good question - on one hand, it violates RFC 4252 and may present a security
vulnerability. On the other hand, we might not want to prevent our users from
connecting to _github_. Here is what I suggest we do:
* Client remembers chosen key when it sends {{SSH_MSG_USERAUTH_REQUEST}} by
setting a session attribute (remember to clear it regardless of whether
authentication eventually succeeds or not)
* When it receives {{SSH_MSG_USERAUTH_PK_OK}} it checks if the echoed key
matches the selected one.
* If yes, then all is well. if not, then it consults a +configuration
{{Property}}+ whether to be strict (default) or not.
* If strict mode - then fail the authentication attempt (with an appropriate
log message)
* Otherwise, check if the echoed key is of the +same "type"+ (RSA in this
case). If not, then (obviously) fail the attempt, otherwise issue a log warning
and proceed (as the current code does).
> Implement server-sig-algs
> -------------------------
>
> Key: SSHD-1141
> URL: https://issues.apache.org/jira/browse/SSHD-1141
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Ian Wienand
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Mina sshd should implement server-sig-algs to report signature algorithms.
> Without the daemon sending server-sig-algs, clients fall back to ssh-rsa per
> RFC8332
> {quote}When authenticating with an RSA key against a server that does not
> implement the "server-sig-algs" extension, clients MAY default to an
> "ssh-rsa" signature to avoid authentication penalties.
> {quote}
> Some distributions, notably Fedora 33, have set default system policy to
> disallow insecure algorithms such as ssh-rsa. They thus can not find a
> suitable signature algorithm and fail to log in. Quite a high level of
> knowledge is required to override the default system cryptography policy, and
> it can be quite confusing because the user's ssh-key works in many other
> contexts (against openssh servers, etc.). For full details see discussion in
> SSHD-1118.
> For example, connecting to a recent openssh server I see something like
> {quote}debug1: kex_input_ext_info:
> server-sig-algs=<ssh-ed25519,sk-ssh-ed25...@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp...@openssh.com>
> {quote}
> I believe that Mina SSHD does support these more secure signature algorithms,
> but because they aren't reported the client won't use them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
