[
https://issues.apache.org/jira/browse/SSHD-618?focusedWorklogId=437275&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-437275
]
ASF GitHub Bot logged work on SSHD-618:
---------------------------------------
Author: ASF GitHub Bot
Created on: 27/May/20 03:27
Start Date: 27/May/20 03:27
Worklog Time Spent: 10m
Work Description: gnodet closed pull request #22:
URL: https://github.com/apache/mina-sshd/pull/22
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 437275)
Remaining Estimate: 0h
Time Spent: 10m
> 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: Lyor Goldstein
> Priority: Major
> Fix For: 1.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
