- 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

The errors happen when a client closes a connection on handshake
They can be ignored to avoid noise

When a user hits repository rate limit, Gitaly returns an error
that the request can't be handled (Gitaly unavailable)

We should avoid this error to avoid exceeding the error rate

- Use console package to format the errors in gitlab-sshd
- Suppress internal Gitaly errors in client output

Downgrade host key mismatch messages from warning to debug

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

Introduce a GitLab-SSHD server version during handshake

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

This message doesn't provide that much value, so let's just drop it.

In production, we often see SSH key scans requesting host key
algorithms that we don't support, such as `sk-ssh-ed25519@openssh.com`
or `sk-ecdsa-sha2-nistp256@openssh.com`.

These messages might be useful if someone forgets to configure a host
key that should be supported, but most of the time they are noise.

This commit downgrades these messages to DEBUG.

Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/581

Changelog: changed

Narrow supported kex algorithms

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