Offer rsa-sha2-512 and rsa-sha2-256 algorithms in internal SSH

[zeripath]

There is a subtle bug in the SSH library x/crypto/ssh which makes the incorrect
assumption that the public key type is the same as the signature algorithm type.

This means that only ssh-rsa signatures are offered by default.

This PR adds a workaround around this problem.

Fix #17175

Signed-off-by: Andrew Thornton art27@cantab.net

[6543]

Is that bug reported upstream too?

[6543]

error log: https://hastebin.nl/CViInAB

[zeripath]

error log: https://hastebin.nl/CViInAB

This works on CI, running tests locally and in simple testing here. Was this on your testing?

[zeripath]

Is that bug reported upstream too?

it is but I've added a comment explaining why it's happened.

[lunny]

Could you also send a PR to upstream? Maybe they could also give some reviews.

[zeripath]

Could you also send a PR to upstream? Maybe they could also give some reviews.

This PR isn't suitable for upstream as it's a workaround. The problem is a fundamental design issue with the upstream ssh.Signer type and its use in the upstream ssh package.

The issue is that the type ssh.Signer:

type Signer interface {
	// PublicKey returns an associated PublicKey instance.
	PublicKey() PublicKey

	// Sign returns raw signature for the given data. This method
	// will apply the hash specified for the keytype to the data.
	Sign(rand io.Reader, data []byte) (*Signature, error)
}

Doesn't provide a mechanism to say what types of algorithm are supported by this Signer. Even

type AlgorithmSigner interface {
	Signer

	// SignWithAlgorithm is like Signer.Sign, but allows specification of a
	// non-default signing algorithm. See the SigAlgo* constants in this
	// package for signature algorithms supported by this package. Callers may
	// pass an empty string for the algorithm in which case the AlgorithmSigner
	// will use its default algorithm.
	SignWithAlgorithm(rand io.Reader, data []byte, algorithm string) (*Signature, error)
}

doesn't do this and nor is it wired into handshake.

It would actually need to be something like:

type TypedSigner interface {
	Signer

	// Type returns the algorithm type for this signer
	Type() String
}

or:

type MultipleAlgorithmSigner interface {
	AlgorithmSigner

	// Algorithms returns the available algorithms 
	Algorithms() []string

	// SignWithAlgorithm is like Signer.Sign, but allows specification of a
	// non-default signing algorithm. See the SigAlgo* constants in this
	// package for signature algorithms supported by this package. Callers may
	// pass an empty string for the algorithm in which case the AlgorithmSigner
	// will use its default algorithm.
	SignWithAlgorithm(rand io.Reader, data []byte, algorithm string) (*Signature, error)
}

This would then allow backwards compatibility with the current system through casting as the interface and not requiring a v2 of the module.

[6543]

Ok let me test once again ...