https://bugzilla.mindrot.org/show_bug.cgi?id=3733
Bug ID: 3733
Summary: "forced command options do not match" after key error
Product: Portable OpenSSH
Version: 9.8p1
Hardware: amd64
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: sshd
Assignee: unassigned-b...@mindrot.org
Reporter: m.grosshau...@asteas.com
This happens on Ubuntu 22.04 with a GitLab installation. The problem
can be reproduced with OpenSSH 9.8p1 compiled from source.
sshd logs:
Sep 11 11:37:02 gitlab-test sshd-session[471341]: error: public key
ED25519-SK SHA256:LAoWkl5g/Y1/6CPfePtY4JOWU+iCbKcLdFt9AKK10YM signature
for git from 10.3.3.133 port 48634 rejected: user presence
(authenticator touch) requirement not met
Sep 11 11:37:02 gitlab-test sshd-session[471341]: error: Inconsistent
authentication options: forced command options do not match
Sep 11 11:37:02 gitlab-test sshd-session[471341]: Accepted publickey
for git from 10.3.3.133 port 48634 ssh2: ED25519
SHA256:j/XSWFUCcL6fWZCgpi5Xf69Jyv8otcmBv5x5/fNDfWs
-----
Here's the relevant part from authorized_keys (this file is managed by
GitLab):
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIJ5oLfHPxjSrzh1evc1YdixqaT+pmB9Uji626RrF8kb5
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
sk-ssh-ed25...@openssh.com
AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIEV497Gl3oWUsun8CSEPnjcqphlowRQIPPHdSIHj0RoTAAAABHNzaDo=
-----
Output from git is:
$ git pull -v
client_loop: send disconnect: Broken pipe
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
-----
Notes:
- The ED25519-SK (fido2-enabled key) login attempt is failing, because
the key has no-touch-required set, which is not supported by GitLab
(generally, authorized-keys options are not supported by gitlab,
including the no-touch-required option)
- After that another key is tried. Altough the key is OK, the login
fails due to the forced-commands not being identical to the first one
What I'm wondering in that case is that the forced-command option is
not reset after the failed attempt with the sk-key. Is that desired
behaviour of sshd?
--
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
