| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| | |
| | |
| | |
| | | |
Refactor testhelper.PrepareTestRootDir using t.Cleanup
See merge request gitlab-org/gitlab-shell!493
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | | |
Change default logging format to JSON
See merge request gitlab-org/gitlab-shell!476
|
| | | | |
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
Geo SSH proxy push currently impossible when the only
action that happens is branch removal. This fix
works in a way that it waits for flush packet from git
and then checks pkt lines to determine is pack data is expected.
The thing is that git doesnt send pack data when only
branch removal happens. Explanation is in
https://gitlab.com/gitlab-org/gitlab/-/issues/330494
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Gitaly project now properly respects module release flow
and includes a module suffix in the package name. It requires
to re-write all non-suffixed imports with suffixed of a specific
version of tha module. With proper module versioning we don't
need to use a 'replace' directive to point to specific commit
and can use semantic versioning for the gitaly dependency.
Part of: https://gitlab.com/gitlab-org/gitaly/-/issues/3177
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Fix opentracing setup for gitlab-sshd
Closes #501
See merge request gitlab-org/gitlab-shell!473
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, opentracing (if configured) was initialized late in the
gitlab-shell process's lifespan, coming just before making a gRPC
call to Gitaly.
By moving the opentracing initialization to be at process startup, we
make it available for the whole process lifecycle, which is very useful
to gitlab-sshd, as it means we'll only call tracing.Initialize() once
on process startup, rather than once per SSH connection.
To get this working, we need to introduce a context to gitlab-sshd.
This carries the client/service name, but also carries an initial
correlation ID. The main outcome of this is that all calls to the
authorized_keys endpoint from a given gitlab-sshd process will now
share a correlation ID. I don't have a strong opinion about this either
way.
Changelog: fixed
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
Respect parent context for Gitaly calls
See merge request gitlab-org/gitlab-shell!469
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Without these changes, Gitaly calls would not be linked to a parent
context. This means that they would have an unassociated correlationID,
and Gitaly RPC calls would not be cancel()ed by parent context
cancellation.
Changelog: fixed
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This behaviour dates from when Gitaly RPCs were executed in Ruby by a
Go subprocess. It's not needed for gitlab-shell now that it's in Go,
and it's a very strange thing for gitlab-sshd. Best just to remove it.
If we wanted to retain this behaviour, we could have an `os.Chdir` call
in the gitlab-shell binary, but I just don't think it's needed.
Changelog: fixed
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
gitlab-sshd: Respect the ssl_cert_dir config
Closes #516
See merge request gitlab-org/gitlab-shell!467
|
| | |/
| |
| |
| | |
Changelog: fixed
|
| |/
|
|
|
|
|
|
|
| |
Calling finished() in `ContextWithCorrelationID` breaks opentracing,
since it expects us to call it just before exiting, and this defer
runs on function completion.
All existing users of ContextWithCorrelationID already `defer finish()`
themselves, so this call is entirely surplus to requirements.
|
| |
|
|
|
|
| |
Without this, a failure in a single session could take out a whole
connection, or a failure in a single connection could take out the
whole server.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
In this case we don't need to propagate cleanup
function. It simplifies the code.
|
| |\
| |
| |
| |
| | |
gitlab-sshd: Acceptance test for the discover command
See merge request gitlab-org/gitlab-shell!457
|
| | |
| |
| |
| |
| | |
With this, we can start to build confidence in making changes to
gitlab-sshd.
|
| |/
|
|
|
|
|
| |
Refactors introspection of execution environment to rely on
per-connection state (`gitlab-shell`) or per request (`gitlab-sshd`)
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/496
|
| |
|
|
|
|
|
|
|
| |
Previously when the gitlab-shell log was not writable, gitlab-shell
would attempt to fall back to the syslog to log an error. However,
if the syslog logger creation succeeded, gitlab-shell would panic
since `err` was `nil`.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/510
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Counter for how many times the max concurrent sessions limit was hit.
* Histogram for duration of each SSH connection.
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/121
Signed-off-by: Ben Kochie <superq@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a basic monitoring endpoint to the sshd command.
* Listen on localhost port 9122 by default.
* Integrate build/version info.
* Update example config.
https://gitlab.com/gitlab-org/gitlab-shell/-/issues/121
Signed-off-by: Ben Kochie <superq@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Use "omitempty" to allow defaults in the config file to be correctly
passed. Without this, explicitly setting an empty default like an empty
string will not work. Needed in order to allow explicitly disabling some
settings.
Related to: https://gitlab.com/gitlab-org/gitlab-shell/-/issues/121
Signed-off-by: Ben Kochie <superq@gmail.com>
|
| | |
|
| |
|
|
|
| |
This change removes session duration
information from output of 2fa_verify command
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During a SSH receive-pack request (e.g. `git push`), gitlab-shell was
incorrectly using the user returned by the `/internal/allowed` API
endpoint to make an SSHReceivePack RPC call. This caused a number of
problems with deploy keys with write access:
1. Keys that were generated by a blocked user would be denied the
ability to write.
2. Keys that were generated by user that did not have write access to
the project would also be denied.
GitLab 12.4 removed the Ruby implementation of gitlab-shell in favor of
the Golang implementation, and these implementations worked slightly
differently. In
https://gitlab.com/gitlab-org/gitlab-shell/blob/v10.1.0/lib/gitlab_shell.rb,
the Ruby implementation would always use `@who` (e.g. `key-123`), but in
gitlab-shell v10.2.0 the Go implementation would always use the user
from the API response.
Reads did not have this issue because the user/deploy key is never
passed to Gitaly for additional permission checks. Writes need this
information for the pre-receive to check access to protected branches,
push rules, etc.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/479
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Testify features sub packages `assert` and `require`. The difference is
subtle, and lost on novice Golang developers that don't read the docs.
To create a more consistent code base `assert` will no longer be used.
This change was generated by a running a sed command on all `_test.go`
files, followed by `goimports -w`.
|
| |
|
|
|
|
| |
This message happens all the time and doesn't add a lot of value.
Relates to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, gitlab-shell did not pass a context through the application.
Correlation IDs were generated down the call stack instead of passed
around from the start execution.
This has several potential downsides:
1. It's easier for programming mistakes to be made in future that lead
to multiple correlation IDs being generated for a single request.
2. Correlation IDs cannot be passed in from upstream requests
3. Other advantages of context passing, such as distributed tracing is
not possible.
This commit changes the behavior:
1. Extract the correlation ID from the environment at the start of
the application.
2. If no correlation ID exists, generate a random one.
3. Pass the correlation ID to the GitLabNet API requests.
This change also enables other clients of GitLabNet (e.g. Gitaly) to
pass along the correlation ID in the internal API requests
(https://gitlab.com/gitlab-org/gitaly/-/issues/2725).
Fixes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/474
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4498#note_397401883,
if you specify a relative path such as:
```
external_url 'http://gitlab.example.com/gitlab'
```
gitlab-shell doesn't have a way to pass the `/gitlab` to the host. For example, let's say we have:
```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
```
If we have `/gitlab` as the relative path, how do we specify what is the
UNIX socket path and what is the relative path? If we specify:
```
gitlab_url: "http+unix:///var/opt/gitlab/gitlab-workhorse.socket/gitlab
```
This is ambiguous. Is the socket in
`/var/opt/gitlab/gitlab-workhorse.socket/gitlab` or in
`/var/opt/gitlab/gitlab-workhorse.socket`?
To fix this, this merge request adds an optional
`gitlab_relative_url_root` config parameter:
```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
gitlab_relative_url_root: /gitlab
```
This is only used with UNIX domain sockets to disambiguate the socket
and base URL path. If `gitlab_url` uses `http://` or `https://`, then
`gitlab_relative_url_root` is ignored.
Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/476
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the feature requested in gitlab-org/gitlab#19672
This requires the internal api counterpart in gitlab-org/gitlab!36302 to
be merged first.
It can be used as follows:
```
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token
remote:
remote: ========================================================================
remote:
remote: Usage: personal_access_token <name> <scope1[,scope2,...]> [ttl_days]
remote:
remote: ========================================================================
remote:
censored@censored-VirtualBox:~/git/gitlab$ ssh git@gitlab-2004 personal_access_token newtoken read_api,read_repository 30
Token: aAY1G3YPeemECgUvxuXY
Scopes: read_api,read_repository
Expires: 2020-08-07
```
|
| |
|
|
|
| |
This will make it easier to tie an SSH access request to Rails API and
Gitaly requests.
|
