Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/crypto: ssh/client.NewSession() fails when remote key has an exponent greater than 24b #50711

Open
bpizzi opened this issue Jan 20, 2022 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bpizzi
Copy link

bpizzi commented Jan 20, 2022

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

go version go1.17.5 linux/amd64

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="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/gedix/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build309787458=/tmp/go-build -gno-record-gcc-switches"

What did you do?

When trying to open a ssh session to a LSH server (lshd-1.4.3, secsh protocol version 2.0).

package main

import (
	"golang.org/x/crypto/ssh"
	"log"
)

func main() {
	user := "REDACTED"
	password := "REDACTED"
	host := "REDACTED"

	sshConfig := &ssh.ClientConfig{
		User:            user,
		Auth:            []ssh.AuthMethod{ssh.Password(password)},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
	}

	client, dialErr := ssh.Dial("tcp", host, sshConfig)
	if dialErr != nil {
		log.Fatalf("dial: %s\n", dialErr)
	}

	if _, sessErr := client.NewSession(); sessErr != nil {
		log.Fatalf("session: %s\n", sessErr)
	}
	defer client.Close()
}

What did you expect to see?

No error on NewSession()

What did you see instead?

2022/01/20 12:02:05 dial: ssh: handshake failed: ssh: exponent too large

OTOH, openssh client connects successfully, giving that I specifies the expected values for KexAlgorithms and HostKeyAlgorithms (setting those in Go's ssh config doesn't help).

> ssh -v [HOST]
OpenSSH_8.8p1, OpenSSL 1.1.1m  14 Dec 2021
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version lshd_1.4.3 lsh - a free ssh
debug1: compat_banner: no match: lshd_1.4.3 lsh - a free ssh
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha1 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:lWlSUxbsOy5xtg3vvLTJaI1IrmwMjgoANXnFL+8sSzI
[...]
debug1: Authentications that can continue: password,publickey
[...]
debug1: Next authentication method: password
[success]

As a workaround, I managed to successfully establish the session by changing the max bit len to 31 (instead of actually 24) in x/crypto/ssh/keys.go:353 in ParseRSA().

@gopherbot gopherbot added this to the Unreleased milestone Jan 20, 2022
@heschi
Copy link
Contributor

heschi commented Jan 20, 2022

@heschi heschi added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 20, 2022
@rolandshoemaker
Copy link
Member

Why are you using a key with such a large exponent? Is this the default in lshd, or a key you've generated yourself?

We explicitly don't support such large exponents, since they provide little to no benefit. See #3161 and https://codereview.appspot.com/5650067 for previous discussion (also https://www.imperialviolet.org/2012/03/16/rsae.html).

@bpizzi
Copy link
Author

bpizzi commented Jan 24, 2022

Hey, thanks for having a look at it.

Why are you using a key with such a large exponent? Is this the default in lshd, or a key you've generated yourself?

Actually I don't have a say on this, I'm trying to connect to a server where the key is as-is and can't be changed (its an appliance provided by a BigCorp). I not sure how the key have been generated.

We explicitly don't support such large exponents, since they provide little to no benefit. See #3161 and https://codereview.appspot.com/5650067 for previous discussion (also https://www.imperialviolet.org/2012/03/16/rsae.html).

Thanks for this, as its nice to have some background intel on how this came to be.

Do you think the decision for not handling big exponent is susceptible to being re evaluated in the regard of the present issue? Otherwise I'll move on, and at least we'll have a searchable issue here referencing for exponent too large ;)

@rolandshoemaker
Copy link
Member

Thanks for the context.

This issue has popped up sparingly in the last decade since this was first discussed. Given how rare it is, and without some serious issue with RSA that requires everyone to switch to giant exponents, I don't think we'll be reconsidering this decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants