x/crypto/ssh: publicKeyCallback cannot handshake using ssh-rsa keys signed using the ssh-rsa-sha2-256 algorithm

[SwampDragons]

This relates to:

x/crypto/ssh: cannot sign certificate with different algorithm #36261
x/crypto/ssh: support RSA SHA-2 host key signatures #37278

What version of Go are you using (go version)?

1.14.2

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mmarsh/Library/Caches/go-build"
GOENV="/Users/mmarsh/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mmarsh/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/mmarsh/go/src/golang.org/x/crypto/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8t/0yb5q0_x6mb2jldqq_vjn3lr0000gn/T/go-build245084723=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Here's a gist containing code to reproduce this issue, provided you have an instance to connect to that's similarly set up to mine. I've got full steps to create such an instance in the gist's README.md.

https://gist.github.com/SwampDragons/8b913208add452f1b50f6f47426ac329

What did you expect to see?

I expected to be able to connect to the instance using a custom AlgorithmSigner.

I am able to connect to an instance before the crypto policy on that instance is updated to deny keys signed using the "ssh-rsa" algorithm. Note that the policy being applied does accept the ssh-rsa keys if they are instead signed with the "rsa-sha2-256" algorithm. Theoretically, I should be able to create my own AlgorithmSigner to apply this algorithm to my key.

What did you see instead?

I get denied access to the instance with an authentication error.

I have traced this to the validateKey and publicKeyCallback methods in ssh/client_auth. These methods assume that the algorithm is always the same as the key type, which is not the case in my situation.

Possible Solutions

Create a new interface, AlgorithmSignerWithAlgo, which has the method Algorithm(). When called, Algorithm() will return the type of algorithm used, so that publicKeyCallback can set this field accurately. We will also need to update the validateKey method to not return an error if the algorithm used to sign the validation request doesn't match the key type.

Here's a diff of a lightweight solution that enables users to implement their own signers that the default publicKeyCallback can use to correctly handshake: https://github.com/SwampDragons/crypto/pull/1/files

[dmitshur]

/cc @hanwen @FiloSottile per owners.

[SwampDragons]

I've opened a patchset at https://go-review.googlesource.com/c/crypto/+/240717

[SwampDragons]

Is there anything else the maintainers need from me in order to make this ready for a review?

[SwampDragons]

Hi, I know it's annoying having someone nagging at an issue, but it's been a while and having some kind of solution to this is a blocker for some people using Packer. Is there any way @hanwen or @FiloSottile could take a look at the patch I've submitted?

[jeremymcgee73]

Would love to see this reviewed, it is a blocker for me with packer.
Thanks!

[jbardin]

If I understand correctly, I think in this case the ssh client should be responsible for the signing algorithm negotiation. Because the user may not know if the server configuration will accept the legacy format or not, I don't think think we can place the burden on the user to determine the signing algorithm, plus it's kind of cumbersome since changing the algorithm for most keys isn't valid anyway. The AlgorithmSignerWithAlgo also has the drawback of not working with agent signers, which have been the most common in my experience.

It looks to me like we should be able to easily negotiate the signing algorithm while verifying the allowed public keys with the server, and pass the discovered algorithm along. We probably need to add SignWithAlgorithm to the agent signer, and have some special handling of Certificates to deal with the nist names they have wrapped around the public key types, but I think that might be a better approach to solve the issue transparently for users.

[SwampDragons]

Yeah I think that's a better approach too. This patchset was a very timid "I don't want to muck around too much inside anything or change any current behaviors without explicit interaction" approach, which I'd hoped would help get it adopted faster since it seemed pretty low risk to current users.

That said, I bet we could simply have the validateKey check determine whether the PublicKey.Type() is SigAlgoRSA ("ssh-rsa"), and if the validation fails try again with SigAlgoRSASHA2256 ("rsa-sha2-256") instead. It would be a lot less code and prevent users from having to implement this.

[jbardin]

Getting back up to speed, as RFC8332 and RFC8308 are much newer than my previous ssh work. It looks like the correct negotiation here is to implement server-sig-algs to get the supported algorithms before polling for an accepted key algorithm, to avoid auth penalties with certain server configurations. Agent usage often encounters these limits already (which is a primary use for the IdentityFile openssh option with an agent), and tripling the requests is likely to exacerbate the problem significantly.

The key types should however still be decoupled from the algorithm name, as the public key format and algorithm were only the same by coincidence and AlgorithmSigner alone can't break that association.

[mpx]

SHA-1 is (and will be) increasingly unsupported which causes golang.org/x/crypto/ssh to fail for more platforms. Eg:

• Fedora 33 (2020-10-27) disabled SHA-1 [release notes]
• OpenSSH maintainers have been warning they "will disable this signature scheme by default in the near
  future." since OpenSSH 8.2 (2020-02-14) [release notes]

Detecting the correct signature algorithm would be better than trying multiple algorithms since there are often signing limits with agents. Either raw throughput, or potentially even requiring a human interaction per signature (2nd factor).

However, perhaps we should consider simply using rsa-sha2-256 instead?

• SHA-1 is increasingly unsupported (above)
• SHA-2 has been supported by SSH servers for many years now (eg, OpenSSH 7.2 released 2016-02-29).
• Avoids a potential extra round trip to determine signature algorithms? (faster)
• Better fit with Go's Cryptography Principles?:
  • Less code / complexity
  • Uses the safer/more secure/modern algorithm without extra work from callers

golang.org/x/crypto/ssh agent code example for testing

package main

import (
    "log"
    "net"
    "os"

    "golang.org/x/crypto/ssh"
    "golang.org/x/crypto/ssh/agent"
)

func main() {
    if len(os.Args) < 3 {
        log.Fatalf("usage: %s USERNAME HOSTNAME", os.Args[0])
    }
    username := os.Args[1]
    target := os.Args[2] + ":22"

    conn, err := net.Dial("unix", os.Getenv("SSH_AUTH_SOCK"))
    check(err, "Agent Dial")
    ag := agent.NewClient(conn)

    client, err := ssh.Dial("tcp", target, &ssh.ClientConfig{
        User:            username,
        Auth:            []ssh.AuthMethod{ssh.PublicKeysCallback(ag.Signers)},
        HostKeyCallback: ssh.InsecureIgnoreHostKey(),
    })
    check(err, "SSH Dial")

    sess, err := client.NewSession()
    check(err, "SSH NewSession")
    sess.Stdout = os.Stdout
    sess.Stderr = os.Stderr

    err = sess.Run("echo good")
    check(err, "SSH Run")
}

func check(err error, msg string) {
    if err != nil {
        log.Fatalf("%s: %v", msg, err)
    }
}

$ ./test-ssh mpx fedora32
good
$ ./test-ssh mpx fedora34
2021/05/08 17:52:46 SSH Dial: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Cc @FiloSottile @katiehockman @rolandshoemaker (current maintainers)