[
https://issues.apache.org/jira/browse/SSHD-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072144#comment-15072144
]
Alon Bar-Lev commented on SSHD-618:
-----------------------------------
---------- Forwarded message ----------
From: Lyor Goldstein <[email protected]>
Date: 21 December 2015 at 18:23
Subject: RE: [GitHub] mina-sshd pull request: [SSHD-618] Support restricting
server host...
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
This the wrong way to do this. You will have to wait until I return, however if
you want to get started here is the way to go:
- Define SignatureFactoriesManager interface that has get/setSignatureFactories
factories methods
- Remove the definitions of these methods from their current interface and make
that interface extend the new one.
- Define UserAuthPubkeyFactory and its created UserAuthPublicKey instances as
implementing this interface (both client and server side)
- Overwrite each factory's create function to set the created
UserAuthPublicKey's signature factories with its own.
- Overwrite the default factory instance setter to throw
UnsupportedOperationException if invoked
- In each UserAuthPublicKey (client or server) instance use a
resolveSignatureFactoried method that checks if the set ones are not
null/empty..
If null or empty the use the session's factories
- Write a unit test - e.g. in the ServerTest class that demonstrates this
capability.
There are a lot more details, so if you cannot figure them out your pull
request will not do the necessary job.
> Support restricting server host key algorithms
> ----------------------------------------------
>
> 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
>
> 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:
> protected byte[] sendKexInit() throws IOException {
> - String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> + //String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> + //String resolvedAlgorithms = "ssh-rsa";
> + String resolvedAlgorithms = "ecdsa-sha2-nistp256";
> 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)
