You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Goldstein Lyor (JIRA)" <ji...@apache.org> on 2016/01/04 13:43:39 UTC

[jira] [Resolved] (SSHD-618) Allow public key authentication mechanism to use different signature factories than client/server or session

     [ https://issues.apache.org/jira/browse/SSHD-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Goldstein Lyor resolved SSHD-618.
---------------------------------
       Resolution: Fixed
    Fix Version/s: 1.1.0

> Allow public key authentication mechanism to use different signature factories than client/server or session
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: SSHD-618
>                 URL: https://issues.apache.org/jira/browse/SSHD-618
>             Project: MINA SSHD
>          Issue Type: Improvement
>    Affects Versions: 1.0.0, 1.1.0
>            Reporter: Alon Bar-Lev
>            Assignee: Goldstein Lyor
>             Fix For: 1.1.0
>
>
> In current implementation the signature factories effects all algorithms that can be used during a connection. There is no way of limiting only sever host key algorithm to be able to request a specific server key. This is required in order to connect to pre-approved server using weaker key.
> It should be possible as in rfc4253 "Algorithm Negotiation" we have two fields one for available algorithms, and another for requesting a specific set of server keys which is subset of the available algorithms.
>       name-list    kex_algorithms
>       name-list    server_host_key_algorithms
> In rfc4252 we have "Public Key Authentication Method:
> "publickey"" "Public key algorithms are defined in the transport layer specification". So client public key types are subset of kex_algorithms.
> As far as I understand if we set kex algorithms of rsa and nistp256
> and force host key algorithms of rsa, we should be able to force
> server to use weaker algorithm while client can use any of rsa and
> nistp256.
> To prove that I hacked the AbstractSession with:
> {code}
>      protected byte[] sendKexInit() throws IOException {
> -        String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = "ssh-rsa";
> +        String resolvedAlgorithms = "ecdsa-sha2-nistp256";
> {code}
> If I force ssh-rsa I receive ssh-rsa sever key as expected.
> If I force ecdsa-sha2-nistp256 I receive ecdsa-sha2-nistp256 server
> key as expected while can authenticate using client ssh-rsa key, this
> means that server and client are indeed detached.
> Adding an option to specify a list of server host key type like "ssh-rsa" or "ecdsa-sha2-nistp256" will be nice as once having a pre-approved server keys, we can enforce them easily without transformation/guessing signature algorithm.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)