Release v14.7.4

See merge request gitlab-org/gitlab-shell!663

- Update crypto module to fix RSA keys with old gpg-agent

gitlab-sshd: Update crypto module to fix RSA keys with old gpg-agent

See merge request gitlab-org/gitlab-shell!662

When we put gitlab-sshd in production, we noticed a number of clients
using RSA keys would fail to login. The server would report:

```
ssh: signature "ssh-rsa" not compatible with selected algorithm "rsa-sha2-512"
```

This is reproducible on Ubuntu 18.04, which ships gpg-agent v2.2.4 and
OpenSSH v7.6. That version of gpg-agent does not support
`rsa-sha2-256` or `rsa-sha2-512`, but OpenSSH does. As a result,
OpenSSH specifies `rsa-sha-512` as the public key algorithm to use in
the user authentication request message, but gpg-agent includes an
`ssh-rsa` signature. OpenSSH servers tolerates this discrepancy, but
the Go implementation fails because it expects a strict match.

This commit pulls in
https://gitlab.com/gitlab-org/golang-crypto/-/merge_requests/9 to fix
the problem.

Relates to:

1. https://github.com/golang/go/issues/53391
2. https://gitlab.com/gitlab-org/gitlab-shell/-/issues/587

Changelog: fixed

Set BUNDLE_FROZEN to true

Closes #562

See merge request gitlab-org/gitlab-shell!659

To follow rubygems' security adisory
https://github.com/rubygems/rubygems.org/security/advisories/GHSA-hccv-rwq6-vh79:

Upgrade Gemfile.lock to use bundler to v2.3.15

See merge request gitlab-org/gitlab-shell!658

This is just to minimize the versions of bundler used for development.
The GDK runs `support/bundle-install` in this directory to obtain the
version of bundler needed.

This relates to https://gitlab.com/gitlab-org/gitlab/-/issues/364373.

Release v14.7.3

See merge request gitlab-org/gitlab-shell!657

- Ignore "not our ref" errors from gitlab-sshd error metrics

Ignore "not our ref" errors from gitlab-sshd error metrics

See merge request gitlab-org/gitlab-shell!656

If a client requests a ref that cannot be found in the repository,
previously gitlab-sshd would record it as part of its service level
indicator metric. This is really an application error between the
client and the Git repository, so we exclude it from our metrics.

Relates to
https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/15848

Changelog: fixed

Release 14.7.2

See merge request gitlab-org/gitlab-shell!655

- Exclude disallowed command from error rate

Exclude disallowed command from error rate

See merge request gitlab-org/gitlab-shell!654

Release 14.7.1

See merge request gitlab-org/gitlab-shell!652

- Log gitlab-sshd session level indicator errors !650
- Improve establish session duration metrics !651

Calculate session start after the connection is established

See merge request gitlab-org/gitlab-shell!653

Improve establish session duration metrics

See merge request gitlab-org/gitlab-shell!651

Before we took into account the time a user takes to authenticate
Now it only measures the time between a connection established and
a command started to being executed

It's still can be controlled by a user, but it's something we can
measure and restrict if necessary

Log gitlab-sshd session level indicator errors

See merge request gitlab-org/gitlab-shell!650

In production, we saw gitlab-sshd error metrics rise, but it was not
clear why. We now log a message every time we encounter a session
error that affects the service level indicator counter.

Document gitlab-shell on GitLab SaaS

See merge request gitlab-org/gitlab-shell!625

Release v14.7.0

See merge request gitlab-org/gitlab-shell!648

- Abort long-running unauthenticated SSH connections !647
- Close the connection when context is canceled !646

Abort long-running unauthenticated SSH connections

See merge request gitlab-org/gitlab-shell!647

The config option is basically a copy of LoginGraceTime OpenSSH
option.

If an SSH connection is hanging unauthenticated, after some period
of time, the connection gets canceled. The value is configurable,
the server waits for 60 seconds by default.

Close the connection when context is canceled

See merge request gitlab-org/gitlab-shell!646

When graceful shutdown timeout expires, the global context is
canceled. All the operations dependent on it are canceled as well.

Unfortunately, some of the operations doesn't respect the context.
For example, SSH connection initialization.

In this case, we need to manually close the connection.
One of the options is to wait for ctx.Done() and close the connection

Release v14.6.1

See merge request gitlab-org/gitlab-shell!645

- Return support for diffie-hellman-group14-sha1 !644

Return support for diffie-hellman-group14-sha1

See merge request gitlab-org/gitlab-shell!644

It seems that a lot of users rely on this, let's return it and
deprecated later to make the migration less disruptive

Release 14.6.0

See merge request gitlab-org/gitlab-shell!643

- Exclude Gitaly unavailable error from error rate !641
- Downgrade auth EOF messages from warning to debug !641
- Display constistently in gitlab-sshd and gitlab-shell !641
- Downgrade host key mismatch messages from warning to debug !639
- Introduce a GitLab-SSHD server version during handshake !640
- Narrow supported kex algorithms !638

Exclude Gitaly unavailable error from error rate

See merge request gitlab-org/gitlab-shell!641