SetUserSSHPublicKeysPlugin incorrect path for Windows Administrator user

[aacid]

Hello,
SetUserSSHPublicKeysPlugin is always populating ~/.ssh/authorized_keys with public key (if provided).
but this path is incorrect for Administrative users.
as explained here: https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement#administrative-user

authorized keys for Administrator user should be stored in C:\ProgramData\ssh\administrators_authorized_keys, not in C:\Users\username\.ssh\authorized_keys.

this bug results in inability to connect using ssh key authentication as Administrator even when correct public key was provided to SetUserSSHPublicKeysPlugin.

[savchuk1985]

I think we need a new key for cloud-init config that will contain a list of SSH keys to add to this file.

Or maybe if the user is in the Administrators group, Cloudbase-Init should append their keys directly to C:\ProgramData\ssh\administrators_authorized_keys instead of creating C:\Users\username\.ssh\authorized_keys.

[Flask]

is there an update on this? we ran into that issue with windows server 2025

[trollqaa]

temporary fix - remove from C:\programdata\ssh\sshd_config two lines

 Match Group administrators                                                    
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys 

[ader1990]

Hello,

There are people who use cloudbase-init with the OpenSSH from old times, which keeps the default unix-like path (~/.ssh/) - https://www.mls-software.com/opensshd.html. It is weird that the Windows implementation is now group based.

I would like to confirm one thing - what CloudbaseInit currently does is correct, just incomplete in the sense that if the user is part of the Administrators group, the key needs to land also in the new location.

Thanks.

[savchuk1985]

It is weird that the Windows implementation is now group based.

I agree, but unfortunately Microsoft is already doing this.

if the user is part of the Administrators group, the key needs to land also in the new location.

Exactly. Another option is to allow a choice between "traditional" and "microsoft" behavior, if one is preferred. And perhaps "both" should be the default option.