After adding support for rsa-sha2-256/512 on the server side some edge
cases started to arise with old clients:
1) public key authentication with gpg-agent < 2.2.6 fails because we
receive ssh-rsa as signature format and rsa-sha2-256 or rsa-sha2-512
as algorithm.
This is a bug in gpg-agent fixed in this commit:
https://github.com/gpg/gnupg/commit/80b775bdbb852aa4a80292c9357e5b1876110c00
2) certificate authentication fails with OpenSSH 7.2-7.7 because we
receive ssh-rsa-cert-v01@openssh.com as algorithm and rsa-sha2-256
or rsa-sha2-512 as signature format.
This patch is based on CL 412854 and has been tested with every version
of OpenSSH from 7.1 to 7.9 and OpenSSH 9.3.
Fixesgolang/go#53391
Change-Id: Id71f596f73d84efb5c76d6d5388432cccad3e3b1
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/506835
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CL 220037 had implemented support for host authentication using
rsa-sha2-256/512, but not client public key authentication. OpenSSH
disabled the SHA-1 based ssh-rsa by default in version 8.8 (after
pre-announcing it in versions 8.2, 8.3, 8.4, 8.5, 8.6, and 8.7) although
some distributions re-enable it. GitHub will start rejecting ssh-rsa for
keys uploaded before November 2, 2021 on March 15, 2022.
https://github.blog/2021-09-01-improving-git-protocol-security-github/
The server side already worked, as long as the client selected one of
the SHA-2 algorithms, because the signature flowed freely to Verify.
There was however nothing verifying that the signature algorithm matched
the advertised one. The comment suggested the check was being performed,
but it got lost back in CL 86190043. Not a security issue because the
signature had to pass the callback's Verify method regardless, and both
values were checked to be acceptable.
Tested with OpenSSH 8.8 configured with "PubkeyAcceptedKeyTypes -ssh-rsa"
and no application-side changes.
The Signers returned by ssh/agent (when backed by an agent client)
didn't actually implement AlgorithmSigner but ParameterizedSigner, an
interface defined in an earlier version of CL 123955.
Updates golang/go#49269Fixesgolang/go#39885
For golang/go#49952
Change-Id: I13b41db8041f1112a70f106c55f077b904b12cb8
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392394
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The server side implementation was not actually populating the
SSH_MSG_USERAUTH_INFO_REQUEST field with the
KeyboardInteractiveChallenge argument, although the client side was
deserializing it and passing it to the KeyboardInteractiveChallenge
callback.
Anyway, the first field of SSH_MSG_USERAUTH_INFO_REQUEST is "name", not
"user". Maybe the confusion was due to the first field of
SSH_MSG_USERAUTH_REQUEST being the user.
RFC 4256, Section 3.3, says this about it
One possibility is to use the name field (possibly
prefixed with the application's name) as the title of a dialog window
in which the prompt(s) are presented.
and examples include "CRYPTOCard Authentication", "Password
Authentication", and "Password Expired".
Co-authored-by: Kevin Wallace <kevin@pentabarf.net>
Change-Id: Ic6ec0dfea2122704603c44f42898a980689a15c9
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/372234
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
The server implementation looks at the HostKeys to advertise and
negotiate host key signature algorithms. A fundamental issue of the
Signer and AlgorithmSigner interfaces is that they don't expose the
supported signature algorithms, so really the server has to guess.
Currently, it would guess exclusively based on the PublicKey.Type,
regardless of whether the host key implemented AlgorithmSigner. This
means that a legacy Signer that only supports ssh-rsa still led the
server to negotiate rsa-sha2 algorithms. The server would then fail to
find a suitable host key to make the signature and crash.
This won't happen if only Signers from this package are used, but if a
custom Signer that doesn't support SignWithAlgorithm() but returns
"ssh-rsa" from PublicKey().Type() is used as a HostKey, the server is
vulnerable to DoS.
The only workable rules to determine what to advertise seems to be:
1. a pure Signer will always Sign with the PublicKey.Type
2. an AlgorithmSigner supports all algorithms associated with the
PublicKey.Type
Rule number two means that we can't add new supported algorithms in the
future, which is not great, but it's too late to fix that.
rsaSigner was breaking rule number one, and although it would have been
fine where it's used, I didn't want to break our own interface contract.
It's unclear why we had separate test key entries for rsa-sha2
algorithms, since we can use the ssh-rsa key for those. The only test
that used them, TestCertTypes, seemed broken: the init was actually
failing at making the corresponding signers rsaSigners, and indeed the
test for the SHA-256 signer expected and checked a SHA-512 signature.
Pending CVE
For golang/go#49952
Change-Id: Ie658eefcadd87906e63fc7faae8249376aa96c79
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392355
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
RFC 8332, Section 2 sets up two overlapping namespaces: public key
formats and public key algorithms.
* The formats are what we currently have KeyAlgo constants for, and they
appear in PublicKey.Type.
* The algorithms are the set of both KeyAlgo and SigAlgo constants, and
they appear in Signature.Format (amongst other places).
This is incoherent, because that means Signature.Format can be both a
KeyAlgo (like KeyAlgoECDSA256) or a SigAlgo (like SigAlgoRSASHA2256).
One solution would be to duplicate all the KeyAlgo constants into the
SigAlgo namespace, but that would be confusing because applications are
currently using KeyAlgos where they'd be supposed to use the new
SigAlgos (while we can't deprecate the KeyAlgos because they are still
necessary for the PublicKey.Type namespace).
Instead, drop the separate namespaces, and use KeyAlgos throughout.
There are simply some KeyAlgos that can't be a PublicKey.Type.
Take the opportunity to fix the stuttering SHA22565/SHA2512 names. It's
totally ok to call those hashes SHA-256 and SHA-512 without the family
infix.
For golang/go#49952
Change-Id: Ia1fce3912a7e60aa70a88f75ed311be331fd19d5
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/392354
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
If we are going to send the disconnect message and close the connection,
because we have exhausted the number of authentication attempts, don't
send the final authentication failure message. This behavior matches
that of OpenSSH.
Fixesgolang/go#51149
Change-Id: I43b2de2e854f789161cd7fd6c05876661adfb2c1
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/385236
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds support for RSA SHA-2 based signatures for host keys and certificates. It also switches the default certificate signature algorithm for RSA to use SHA-512. This is implemented by treating ssh.Signer specially when the key type is `ssh-rsa` by also allowing SHA-256 and SHA-512 signatures.
Fixesgolang/go#37278
Change-Id: I2ee1ac4ae4c9c1de441a2d6cf1e806357ef18910
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/220037
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
The ability to trigger the 'gssapi-with-mic' authentication method is
not properly gated by the presence of the GSSAPIWithMICConfig field of
the ServerConfig type. If this field is not set and a client sends a
'gssapi-with-mic' request, regardless of if the server advertises it,
the server will panic.
This issue was discovered and reported by Joern Schneewesiz, GitLab
Security Research Team.
Fixes CVE-2020-29652
Change-Id: Ie25de2766e442c8ab46680aae3ac89b0823cdeed
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/278852
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Add the diffie-hellman-group-exchange-sha256 defined in RFC 4419 to
the list of supported key exchange algorithms for ssh.
The server half is only a minimal implementation to satisfy the automated tests.
Fixesgolang/go#17230
Change-Id: I25880a564347fd9b4738dd2ed1e347cd5d2e21bb
GitHub-Last-Rev: 9f0b8d02c0c96e9baf00cdf1cf063ff834245443
GitHub-Pull-Request: golang/crypto#87
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/174257
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Previously, this would return the default error "no auth passed yet".
Not only is the new error more specific, it makes it easier to verify
the control flow of server authentication code.
Change-Id: I6c8de4e3f91da74274acbe9d87ec4f6158b4a94f
Reviewed-on: https://go-review.googlesource.com/c/142897
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix typo in error message when keyboard-interactive auth not supported by server and client requests it
Change-Id: Iedb72625852f03552481d85cce2119765cfba320
GitHub-Last-Rev: ee47092daf8c40fe3e0e166e7370556819457af6
GitHub-Pull-Request: golang/crypto#59
Reviewed-on: https://go-review.googlesource.com/c/141658
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
yet.
Since ServerAuthError returns all errors collected during the
userAuthLoop, it will always include the generic error "no auth passed
yet" (assuming the connection fails).
Change-Id: I5f6c67f3f0762b023618178d4028600d2b6c9253
Reviewed-on: https://go-review.googlesource.com/92737
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Only show the SSH banner once, even if the client attempts
authentication with the "none" type and resets the authentication
attempts.
Change-Id: I1a7aacb50abf00233ed4d06c60808aaf51a9d7be
Reviewed-on: https://go-review.googlesource.com/78544
Run-TryBot: Sam Whited <sam@samwhited.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
According to RFC 4252 section 5.4, the banner is sent between the
ssh-connection request and responding to user authentication.
Original support for server sending banner by joshua stein <jcs@jcs.org>
Fixesgolang/go#19567
Change-Id: I729b3c8e5fd2c0068609d1590b61e92f40d87ea4
Reviewed-on: https://go-review.googlesource.com/71790
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
According to RFC 4252 section 5.4, the banner is sent between the
ssh-connection request and responding to user authentication.
Original support for server sending banner by joshua stein <jcs@jcs.org>
Fixesgolang/go#19567
Change-Id: I68944a7f4711c0623759f6a59023e8e45a8781aa
Reviewed-on: https://go-review.googlesource.com/65271
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
This change breaks backwards compatibility.
MaxAuthTries specifies the maximum number of authentication attempts
permitted per connection. If set to a negative number, the server will
allow unlimited authentication attempts. MaxAuthTries defaults to 6 if
not specified, which is a backwards incompatible change. On exceeding
maximum authentication attempts, the server will send a disconnect
message to the client.
This configuration property mirrors a similar property in sshd_config
and prevents bad actors from continuously trying authentication.
Change-Id: Ic77d2c29ee2fd2ae5c764becf7df91d29d03131b
Reviewed-on: https://go-review.googlesource.com/35230
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The ssh tests currently require 127.0.0.1 to work which isn't
necessarily available everywhere. To fix the source-address tests,
support comma-separated source-address values per the PROTOCOL.certkeys
file:
Comma-separated list of source addresses
from which this certificate is accepted
for authentication. Addresses are
specified in CIDR format (nn.nn.nn.nn/nn
or hhhh::hhhh/nn).
If this option is not present then
certificates may be presented from any
source address.
Change-Id: I87536ff81ffa005c073da103021ebc0dfb12b620
Reviewed-on: https://go-review.googlesource.com/36110
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Use channels and a dedicated write loop for managing the rekeying
process. This lets us collect packets to be written while a key
exchange is in progress.
Previously, the read loop ran the key exchange, and writers would
block if a key exchange was going on. If a reader wrote back a packet
while processing a read packet, it could block, stopping the read
loop, thus causing a deadlock. Such coupled read/writes are inherent
with handling requests that want a response (eg. keepalive,
opening/closing channels etc.). The buffered channels (most channels
have capacity 16) papered over these problems, but under load SSH
connections would occasionally deadlock.
Fixes#18439.
Change-Id: I7c14ff4991fa3100a5d36025125d0cf1119c471d
Reviewed-on: https://go-review.googlesource.com/35012
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
A net.IP may be represented by both by a 4 as well as a 16 byte long
byte slice. Because of this, it is not safe to compare IP addresses
using bytes.Equal as the same IP address using a different internal
representation will produce mismatches.
Change-Id: I0d228771cf363ccfb9532f8bc2a2fc8eff61f6e9
Reviewed-on: https://go-review.googlesource.com/34450
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current behaviour of the crypto/ssh server implementation is to
remove the username from ConnMetadata if the connection is done without
authentication (NoClientAuth). This appears to be a bug.
This behaviour is different from other SSH server implementations like
for example Paramiko (Python) which keeps the username.
Additionally RFC4252 (https://www.ietf.org/rfc/rfc4252.txt) section
5 states the username has to be included in every USERAUTH message.
Change-Id: I27fa50db92eb535e90fe088453faa6f2a76ee31f
Reviewed-on: https://go-review.googlesource.com/27612
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Added support for parsing the "new" openssh private key format.
(ed25519 keys only in this format for now)
Signing and verifying functions now work with ed25519 keys.
ed25519 can now be accepted by the server to authenticate a client.
ed25519 can now be accepted by a client as a server host key.
Related documentation used:
https://www.ietf.org/archive/id/draft-bjh21-ssh-ed25519-02.txt
Change-Id: I84385f24d666fea08de21f980f78623f7bff8007
Reviewed-on: https://go-review.googlesource.com/22512
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
Run-TryBot: Han-Wen Nienhuys <hanwen@google.com>
This is done by running the key exchange and setting the session ID
under mutex. If the first exchange encounters an already set session
ID, then do nothing.
This fixes a race condition:
On setting up the connection, both sides sent a kexInit to initiate
the first (mandatory) key exchange. If one side was faster, the
faster side might have completed the key exchange, before the slow
side had a chance to send a kexInit. The slow side would send a
kexInit which would trigger a second key exchange. The resulting
confirmation message (msgNewKeys) would confuse the authentication
loop.
This fix removes sessionID from the transport struct.
This fix also deletes the unused interface rekeyingTransport.
Fixes#15066
Change-Id: I7f303bce5d3214c9bdd58f52d21178a185871d90
Reviewed-on: https://go-review.googlesource.com/21606
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
280be00 introduced custom server versions; however, at least OpenSSH
clients do not accept a server version that doesn't start with a
protocol version like "SSH-2.0-"; this is not documented in this
library, and automatically adding it in case that the user did not does
no harm.
Change-Id: Iafc23b23160a8277b10cbf29778dc64a96351bd7
Reviewed-on: https://go-review.googlesource.com/14018
Reviewed-by: Adam Langley <agl@golang.org>
The SSH server does not allow for setting a version string in the same
manner as the client. This update adds a ServerVersion member to the
ServerConfig structure which when set, causes the server to use that
member instead of the default version string. This allows building
an golang based SSH server which can present any version string
the user wishes.
It also adds an else statement to the client assignment of the
ClientVersion to avoid an allocation when using a user defined
ClientVersion.
Change-Id: I43d97cfd5a174f2c68f53c5b4e267539ef21937b
Reviewed-on: https://go-review.googlesource.com/1860
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Transport should not be a ReadWriter. It can only write packets, i.e. no partial reads or writes. Furthermore, you can currently do ClientConn.Write() while the connection is live, which sends raw bytes over the connection. Doing so will confuse the transports because the data is not encrypted.
As a consequence, ClientConn and ServerConn stop being a net.Conn
Finally, ensure that {Server,Client}Conn implement LocalAddr and RemoteAddr methods that previously were exposed by an embedded net.Conn field.
R=hanwen
CC=golang-dev
https://golang.org/cl/16610043
Edoardo Spadolini
Matt Dainty
Nicola Murino
Brad Fitzpatrick
cuishuang
Roland Shoemaker
Hans Nielsen
Sebastian Kinne
Lucas Bremgartner
yanweizhi
Han-Wen Nienhuys
mkishere
Spencer Tung
Peter Moody
Sam Whited
Tugdual Saunier
Artyom Pervukhin
Catalin Nicutar
James Myers
Heschi Kreinick
Péter Szilágyi
Sven Blumenstein
Martin Garton
Lewin Bormann
Kristopher Watts
Adam Langley
Dave Cheney
Jonathan Pittman