You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is likely out of scope of the utility itself but it might be useful to document things here anyway since it'll probably affect all users of the utility.
Right now if you allow the use of authorized_keys along with kc-ssh-pam, things will not check in KeyCloak if the user is enabled or authorized to log in, potentially allowing users to bypass access controls if they've ever had access to a system in the past.
Describe the solution you'd like
My proposal (at the moment) is to document this as a potential issue, and show how to configure OpenSSH (potentially others?) so that it will only go through the password authentication and ignore authorized_keys for users (this is typically backwards from recommended practice). I'll try to write up this in a fork myself today to be reviewed so that it can be reviewed.
Describe alternatives you've considered
Longer term, and what I will look into myself is to see if there's a way to use the existing OIDC client in this library to ask KC if a user would be authorized to log in, which could then potentially be configured to be used during login with a key rather than the password and still allow things to be managed externally in KC even if password auth is not touched.
Additional context
No additional context yet.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This is likely out of scope of the utility itself but it might be useful to document things here anyway since it'll probably affect all users of the utility.
Right now if you allow the use of authorized_keys along with kc-ssh-pam, things will not check in KeyCloak if the user is enabled or authorized to log in, potentially allowing users to bypass access controls if they've ever had access to a system in the past.
Describe the solution you'd like
My proposal (at the moment) is to document this as a potential issue, and show how to configure OpenSSH (potentially others?) so that it will only go through the password authentication and ignore authorized_keys for users (this is typically backwards from recommended practice). I'll try to write up this in a fork myself today to be reviewed so that it can be reviewed.
Describe alternatives you've considered
Longer term, and what I will look into myself is to see if there's a way to use the existing OIDC client in this library to ask KC if a user would be authorized to log in, which could then potentially be configured to be used during login with a key rather than the password and still allow things to be managed externally in KC even if password auth is not touched.
Additional context
No additional context yet.
The text was updated successfully, but these errors were encountered: