omv-salt deploy run ssh is failing

Hi

I was running upgrades from the omv web interface when I couldn't apply changes to SSH. It throws an error which seems to be caused by a particular setup that I have.

The setup that is likely the root cause is: I have one user on the server that has an alias; this alias is simply another user but assigned to the same UID. This was necessary for an integration I'm running that required the username to follow a certain format and I needed that user to be the same as the existing one on the server.

So to summarize, if I do a cat /etc/passwd this is what I get:

user1:x:1000:100::/home/user1:/usr/bin/zsh
user2:x:1000:100::/home/user1:/bin/zsh

Same UID & GID, same home

Now that this is established, the error I'm getting during the omv-salt deploy run ssh is

----------
          ID: create_ssh_authorized_key_file_user2
    Function: file.managed
        Name: /var/lib/openmediavault/ssh/authorized_keys/user2
      Result: False
     Comment: Failed to change user to user2
     Started: 14:15:39.919138
    Duration: 2.171 ms
     Changes:   
              ----------
              diff:
                  New file
----------

The file is created but it appears to be owned by user1 and not user2. This in fact doesn't matter as they are effectively the same (same UID), but the check that is implemented in that stage fails.

The issue is now that I can't connect with SSH using user1 but I can with user2:

ssh user1@myhost

ssh user2@myhost

- Is there a way to either skip the application of the configuration to user2 ?

- Force the completion of the upgrade regardless of this stage failing ?

- Fix the check of "change user" to check for the UID instead of the username ?

Thanks

Sorry if I wasn't clear in my earlier post; I get that this setup is unorthodox, that's why I explained it in details.

I'm not looking for approbation or validation, I'm looking for a solution since as of right now, I have a broken SSH thanks to an upgrade path that doesn't handle this edge case and doesn't advertise an "undo" mechanism either.

For better or worse, right now, the only thing that is allowing me to connect through SSH is that alias account that I have setup and that can still connect, while the main one is blocked, so it can be either the root cause or the only salvation I have since I'm not physically close to that server at the moment.

OMV's web UI works just fine.

Both user share most groups:

user : users sudo ssh sambashare docker

alias : users sudo ssh docker

I have no need for the sambashare on the alias but that wouldn't hurt to have it I guess.

I'm not sure it was clear from my previous message but SSH works only on the alias right now, which is the more worrying part for me as deleting the alias to "fix" the upgrade path would result in not having SSH access at all if that doesn't work.

I've tested creating a new user, with the same public key. It cannot connect using public key authentication.

The home for the new user is created but the SSH connection isn't possible.

It can connect correctly.

So now I have:

ssh newuser@host

Permission denied (publickey).

ssh newuser@host

Works ok

ssh olduser@host

Connection closed by IP_ADDRESS port PORT

ssh alias@host

Works ok

On the UI I still can't apply those changes:

Due to the error while upgrading SSH's config.