Community discussions

MikroTik App
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 08, 2018 4:29 pm

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:
/user add name=test group=read password=PASSWORD_HERE
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:
[admin@router] > /file print where name=teste.id_rsa.pub
 # NAME                   TYPE                        SIZE CREATION-TIME
 0 teste.id_rsa.pub       ssh key                      399 feb/08/2018 12:24:36
Import it:
/user ssh-keys import public-key-file=teste.id_rsa.pub user=test
Check if everything worked:
[admin@router] > /user print where name=test                                Flags: X - disabled
 #   NAME             GROUP             ADDRESS            LAST-LOGGED-IN
 0   test             read
[admin@router] > /user ssh-keys print where user=test
Flags: R - RSA, D - DSA
 #   USER                       BITS KEY-OWNER
 0 R test                       2048 test@hostname
Now, remove the user:
/user remove test
Verify that the ssh key still there:
[admin@router] > /user print where name=test
Flags: X - disabled
 #   NAME             GROUP             ADDRESS            LAST-LOGGED-IN
[admin@router] > /user ssh-keys print where user=test
Flags: R - RSA, D - DSA
 #   USER                       BITS KEY-OWNER
 0 R test                       2048 test@hostname
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.
Last edited by rarylson on Thu Feb 08, 2018 5:13 pm, edited 2 times in total.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Feb 08, 2018 4:49 pm

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.
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 08, 2018 5:14 pm

Hi @mrz. Thanks for your response. But what do you think about the pros/cons arguments at the end of the post?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Feb 08, 2018 5:42 pm

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.
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 08, 2018 6:40 pm

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.
debug1: Offering RSA public key: /Users/rarylson/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:3PHg1D1kaICUQkuOfGbduuwmf29MVqhrpqgelYmuFeY
debug3: sign_and_send_pubkey: RSA SHA256:3PHg1D1kaICUQkuOfGbduuwmf29MVqhrpqgelYmuFeY
debug1: Authentication succeeded (publickey).
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:
[admin@router] > /user print where name=test
Flags: X - disabled
 #   NAME             GROUP             ADDRESS            LAST-LOGGED-IN
[admin@router] > /user ssh-keys print where user=test
Flags: R - RSA, D - DSA
 #   USER                       BITS KEY-OWNER
 0 R test                       2048 test@hostname
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):
[admin@router] > /user print where name=test
Flags: X - disabled
 #   NAME             GROUP             ADDRESS            LAST-LOGGED-IN
[admin@router] > /user ssh-keys print where user=test
Flags: I - invalid, R - RSA, D - DSA
 #    USER                       BITS KEY-OWNER
 0 IR *8                         2048 test@hostname
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Wed Feb 14, 2018 7:57 pm

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):
:foreach counter=i in=[/user ssh-keys find] do={
    :local user [/user ssh-keys get $i user]
    :if ([:len [/user find name=$user]] = 0) do={
        :local keyowner [/user ssh-keys get $i key-owner]
        :put "Key $keyowner has invalid user: $user"
        /user ssh-keys remove $i
    }
}
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.
 
User avatar
docmarius
Forum Guru
Forum Guru
Posts: 1222
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

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

Wed Feb 14, 2018 8:45 pm

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.
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 15, 2018 2:42 am

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).
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Feb 15, 2018 12:39 pm

Why would you want to share the key between multiple users?
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 15, 2018 4:07 pm

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.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7042
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Feb 15, 2018 4:56 pm

Ok, that clears it up.
In future versions we will make changes to delete assigned ssh-keys when user is removed.
 
rarylson
just joined
Topic Author
Posts: 18
Joined: Thu Aug 20, 2015 6:02 pm
Location: Brazil
Contact:

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

Thu Feb 15, 2018 7:17 pm

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.
 
User avatar
docmarius
Forum Guru
Forum Guru
Posts: 1222
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

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

Thu Feb 15, 2018 8:12 pm

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

Who is online

Users browsing this forum: Bing [Bot], gigabyte091, h1ghrise, HugoCar, menyarito and 71 guests