Issue:

After removing user, its ssh-keys are not removed together.

Description:

Consider we have a user in MikroTik that have public SSH keys (RSA or DSA) already imported. If we remove this user, its public SSH keys are kept in the system.

Maybe the expected behavior would be remove all public SSH keys together when removing the user.

Versions affected:

6.38.5(chr),6.39.1(mibspe),6.39.3(mibspe),6.40.1(mibspe)

How to reproduce:

- Create a user
- Import a public SSH key for this user
- Remove the user
- Verify that the public SSH keys were kept in the system

Detailed how to reproduce:

Create a user with the following command:
Now, upload a public key for this user. In the example, I uploaded a RSA public key (but the same fact occurs when using DSA public keys) via FTP. After the upload was completed:
Import it:
Check if everything worked:
Now, remove the user:
Verify that the ssh key still there:
Some questions:

- It's a bug? Or its the expected behavior?
- What should be the desired behavior (philosophically speaking)?

Pros e cons

Cons

There are some arguments to keep the keys:

- If we remove an interface (like a VLAN), all IPs related to that interface are kept as invalid (they should be manually deleted after if you want);
- In Linux, when we remove a user, it's authorized keys remains in the system (if we did not ask the system to remove the user home).

Pros

But I really thinks the ssh keys should be removed on user removal. SSH keys are not a configuration, but an entry in the user database related to system security. I think all entries related to a given user should be removed together when this user was removed to keep the user database consistent.

Another argument to remove the keys is that if the user was added again, the old password will not work, but the old keys will be accepted. It may cause some security problems. Let me explain with an example. Consider that an employee was fired and its user was removed (but this public SSH keys were kept in the system). Years later, a new employee (who asked for the same username) was hired. When the new user is created (even if new SSH keys were imported), the old user (fired) will regain access to the router.

Even if we consider the example of the IP that remains after the interface was deleted, it's important to note that, if we recreate the interface (with the same name of the old one), the old IP will remain inactive (it will continue to reference an invalid interface).

Also, let's consider the example of the authorized_keys in Linux (that were kept in the user home after user removal). Even in this case, if we recreate the user years latter, the new user will probably receive a new UID/GID (different from the UID/GID of the old user). So, the old user will not automatically regain access to the system.

keys are not supposed to be removed, it is different configuration part. It works the same way as anywhere else in RouterOS, for example if you remove interface it does not remove dhcp client set on that interface. The same with users and imported ssh keys.

Hi @mrz. Thanks for your response. But what do you think about the pros/cons arguments at the end of the post?

Consider that an employee was fired and its user was removed (but this public SSH keys were kept in the system). Years later, a new employee (who asked for the same username) was hired. When the new user is created (even if new SSH keys were imported), the old user (fired) will regain access to the router.

No old user will not regain access, because old user was removed. Users are linked to keys not by name but by internal ID. If you remove the user and then create new user with the same name its ID is different and will not be relinked to existing ssh keys.

Hi @mrz,

I have two considerations:

1)

I made a test with a user in a production router (version 6.39.1). I removed the user, tried to login via SSH - it failed, re-added the user, and tried to login via SSH again: the old public keys were allowed at this point.
Are you sure that "Users are linked to keys not by name but by internal ID"?

2)

After removing the user, when running /user ssh-keys print, the username (string), and not an ID that points to an invalid user (like *13), is showed.

In my example:
I think an output like the above should be the expected result (it would make clear that the key is invalid and not linked to a username):

I did the same tests again and, in all tested Mikrotiks, old users regained access when recreated. It seems that users are linked to keys by name and not by internal ID (I agree if they were linked by internal IDs, there was no problem - but it seems that it is not the case).

So, I run the following command in all MikroTiks to clean all old keys (that belongs to nonexistent users):
Now, I'll run the test in the most recent MikroTik version and I'll put the results here as soon as I have the results.

Let me just put some questions:
- Since you added the keys in a separate step, how do you expect you the router to guess you want to remove them or not together with the user? Just because you assigned them to a user at a later time? What if you want some key shared between multiple users?
- What if you don't want the keys removed?

I would say the process works as expected. You need to know what you do if you want to remove a key. If you do not, it remains there, because non-acting based on some out of control assumption should be the default behavior.

Hi @docmarius,

I'm answering your considerations bellow:

1)

Since you added the keys in a separate step, how do you expect you the router to guess you want to remove them or not together with the user?

I think both behaviors (keep or delete the keys) may make sense - there are arguments to both of the behaviors (see: "Pros e cons" in the topic description).

I think the "also delete keys linked to the removed user" is a better behavior (reasons in: "Pros" in the topic description).

However, even if the router keeps the keys, it should invalidate the association with the user to avoid the problem above (quoted from "Pros" section):

Another argument to remove the keys is that if the user was added again, the old password will not work, but the old keys will be accepted. It may cause some security problems. Let me explain with an example. Consider that an employee was fired and its user was removed (but this public SSH keys were kept in the system). Years later, a new employee (who asked for the same username) was hired. When the new user is created (even if new SSH keys were imported), the old user (fired) will regain access to the router.

If only the router invalidates the key association on user removal, I think it would be ok.

2)

What if you want some key shared between multiple users?

As I Know, I cannot share a key between multiple users, and a key belongs to a single user (all tries I did to share a key between multiple users have failed - I received an error).

PS: Just to be clear, here, a key means an entry in the /user ssh-keys prints "table".

3)

What if you don't want the keys removed?

Why someone would want to keep the keys? A key cannot be re-associated to a different user (I cannot run a command like /user ssh-keys set 0 user=testuser, for example). Once the user is removed, the only way to reuse the key is to create a new user with the same name as the old user (for me, its a security problem, as explained at "Pros" section).

Again, I think the keys could be kept intact. However, for this, the key association should be invalidated on user removal (as I explained in a reply to mrz - viewtopic.php?f=2&t=130595#p641298).

As I said:

[...] users are linked to keys by name and not by internal ID.

I agree that if they were linked by internal IDs, there was no problem - but it seems that it is not the case.

In short:

Removing the keys is a solution (my preferred solution).

Another is invalidating the key association to an already removed user. It will automatically occur when keys are linked to users by internal IDs (it doesn't happens now).

Why would you want to share the key between multiple users?

I do NOT want to share any key between users. I only replied to the docmarius consideration.

He wrote that the keys should be kept because someone could share a key between users:

What if you want some key shared between multiple users?

And I said the consideration doesn't make sense because there is not "shared keys" functionality.

Ok, that clears it up.
In future versions we will make changes to delete assigned ssh-keys when user is removed.

Hi mrz,

Thanks for your attention!

In short (after our discussions), I think you have two ways of implementing this:

1) Delete assigned ssh-keys when user is removed -> My first proposal

Or:

2) Associate ssh-keys to user via internal IDs (instead of via usernames - strings), so keys will become invalid (pointing to an invalid ID) when user is removed (similar to my proposed print command in viewtopic.php?f=2&t=130595#p641298).

I'm sure you are more capable than I to choose the best option.

Again, thanks for your attention.

Ok. That makes sense. So actually key remove on user delete is a valid option. Tnx.