Skip to content

TSA offers "ssh-rsa" as host key algorithm #9212

@neumayer

Description

@neumayer

Summary

"ssh-rsa" is offered as host key algorithm by TSA for worker registration on port 2222. This seems to be flagged at least by some security scanners as "using deprecated SHA1 cryptographic settings to communicate."

This is a bit misleading and I think conflates the host key and signing algorithm used for the hashes. And I'm not sure SHA1 is even used when using go crypto even though client requests it (it might default to the sha2 versions anyway, I think I read something along these lines in some github issue, but haven't traced the code to the very end).

But I do think this will be flagged in more contexts going forward. And whether it's a false positive or not, well, either way it has to be addressed somehow.

I am guessing the particular scanner uses something like this under the hood:

nmap -Pn --script ssh2-enum-algos -sV -p 2222 tsa.example.com

This returns (for 7.13.1):

|   server_host_key_algorithms: (3)
|       rsa-sha2-256
|       rsa-sha2-512
|       ssh-rsa

And the "ssh-rsa" is what is suspicious.

I do think this can be addressed by explicitly allowing sha2-256 and sha2-512 only, this rather straight forward:

-	config.AddHostKey(signer)
+	signerWithAlgorithms, err := ssh.NewSignerWithAlgorithms(signer.(ssh.AlgorithmSigner), []string{ssh.KeyAlgoRSASHA256, ssh.KeyAlgoRSASHA512})
+	if err != nil {
+		log.Fatal("Failed to create private key with restricted algorithms: ", err)
+	}
+
+	config.AddHostKey(signerWithAlgorithms)

Problem is explained in: golang/go#52132

Results in:

|   server_host_key_algorithms: (2)
|       rsa-sha2-256
|       rsa-sha2-512

In my experiments with quickstart this causes no problems (both use the same client library so we know they support sha2-xxx).

Is it worth it if I submit a pr for this?

Theoretically there could be issues when connecting from truly ancient worker versions (that actually rely on ssh-rsa).
For that case I can imagine allowing a list of key signing algorithms as a parameter(so one could enable it explicitly), and defaulting to sha2-256 and sha2-512 only?

Context

  • RFC: concourse/rfcs#
  • Prior discussion: #
  • Depends on #
  • Part of #

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions