Bug 3134 - AuthorizedKeysCommand is not executed anymore when an AuthorizedKeysFile has a matching entry
Summary: AuthorizedKeysCommand is not executed anymore when an AuthorizedKeysFile has ...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.1p1
Hardware: amd64 Linux
: P5 major
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_8_3
  Show dependency tree / graph
 
Reported: 2020-03-11 23:27 AEDT by Ganguin
Modified: 2021-10-14 01:40 AEDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ganguin 2020-03-11 23:27:26 AEDT 
The documentation says:

If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user then public key authentication continues using the usual AuthorizedKeysFile files.

Until sshd version 8.0p1 (I tested 7.6p1, 7.9p1 and 8.0p1), the behaviour was as documented:

* Execute AuthorizedKeysCommand all the time
* Fallback to AuthorizedKeysFile if AuthorizedKeysCommand does not successfully authenticate

However, with version 8.1p1 and newer (I tested 8.1p1, 8.2p1 and latest github version commit 9b47bd7b09d191991ad9e0506bb66b74bbc93d34), the order got reversed:

* Check the AuthorizedKeysFile
* Fallback to AuthorizedKeysCommand if AuthorizedKeysFile failed

As a workaround I can set AuthorizedKeysFile to none, but I lose the fallback feature that was interesting in my use case.
Comment 1 Damien Miller 2020-04-17 14:28:23 AEST 
Thanks for letting us know - the change of order was intentional, but the documentation wasn't updated to reflect it. I have fixed sshd_config.5 to match what is actually implemented.
Comment 2 Damien Miller 2021-03-04 09:53:22 AEDT 
close bugs that were resolved in OpenSSH 8.5 release cycle
Comment 3 Ahmed Sayeed 2021-10-14 01:40:20 AEDT 
[spam removed]