openssh bugs - Sep 2024 - [Bug 3733] New: "forced command options do not match" after key error

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-bugs at mindrot.org
          Reporter: m.grosshauser at 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-ed25519 at 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.

https://bugzilla.mindrot.org/show_bug.cgi?id=3733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 3833
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3833&action=edit
Only apply authoptions if signature was successful

I think this should fix the problem

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |3708


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3708
[Bug 3708] Tracking bug for OpenSSH 9.9
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3733

--- Comment #2 from m.grosshauser at asteas.com ---
Thanks for the patch! I recompiled with the change and tested.

The error message is gone, and after trying the second key the git pull
succeeds now.

sshd log:

Sep 12 11:10:36 gitlab-test sshd-session[512145]: error: public key
ED25519-SK SHA256:LAoWkl5g/Y1/6CPfePtY4JOWU+iCbKcLdFt9AKK10YM signature
for git from 10.3.3.133 port 47296 rejected: user presence
(authenticator touch) requirement not met 
Sep 12 11:10:36 gitlab-test sshd-session[512145]: Accepted publickey
for git from 10.3.3.133 port 47296 ssh2: ED25519
SHA256:j/XSWFUCcL6fWZCgpi5Xf69Jyv8otcmBv5x5/fNDfWs
Sep 12 11:10:36 gitlab-test sshd-session[512147]: Received disconnect
from 10.3.3.133 port 47296:11: disconnected by user
Sep 12 11:10:36 gitlab-test sshd-session[512147]: Disconnected from
user git 10.3.3.133 port 47296

-----

$ GIT_SSH_COMMAND="ssh -v" git pull
...
debug1: Remote: /var/opt/gitlab/.ssh/authorized_keys:2: key options:
command user-rc
debug1: Remote: /var/opt/gitlab/.ssh/authorized_keys:2: key options:
command user-rc
debug1: Remote: /var/opt/gitlab/.ssh/authorized_keys:1: key options:
command user-rc
debug1: Remote: /var/opt/gitlab/.ssh/authorized_keys:1: key options:
command user-rc
debug1: Sending environment.
debug1: channel 0: setting env LC_TIME = "de_AT.UTF-8"
debug1: channel 0: setting env LC_MONETARY = "de_AT.UTF-8"
debug1: channel 0: setting env GIT_PROTOCOL = "version=2"
debug1: channel 0: setting env LC_ADDRESS = "de_AT.UTF-8"
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug1: channel 0: setting env LC_TELEPHONE = "de_AT.UTF-8"
debug1: channel 0: setting env LC_NAME = "de_AT.UTF-8"
debug1: channel 0: setting env LC_MEASUREMENT = "de_AT.UTF-8"
debug1: channel 0: setting env LC_IDENTIFICATION = "de_AT.UTF-8"
debug1: channel 0: setting env LC_NUMERIC = "de_AT.UTF-8"
debug1: channel 0: setting env LC_PAPER = "de_AT.UTF-8"
debug1: Sending command: git-upload-pack
'infrastructure/documentation.git'
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 3472, received 3428 bytes, in 0.1 seconds
Bytes per second: sent 36587.3, received 36123.6
debug1: Exit status 0
Already up to date.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.