Would an alternative user for SSH login survive core-updates?

Security
1

For more secure SSH access, can I…

  1. create another user “johndoe”, (# useradd -M johndoe, # passwd johndoe)
  2. login as johndoe and switch to root: (# su -)
  3. edit /etc/ssh/sshd_config:
    AllowUsers johndoe
    DenyUsers root
    DenyGroups root
    PermitRootLogin no
  4. restart the ssh service

By this, a SSH login to the system can only be done by “johndoe” who has no privileges to do anything which is good if he is hacked/bruteforced. After login, johndoe can switch to root (with root-password) and then manage whatever is needed. :metal:

If this works as described, will it persist or will I lock me out by next core-update (like alternative WUI users)? :thinking:

2

Yes you can

Yes you can

You could but it will be overwritten if the ssh package is updated at a Core Update.

However you don’t need to do anything with sshd_config.

I have created a user on IPFire, Then I have the same user (incl uid) in my PC and I create an ssh certificate for that user and add it into ```/home/user-name/.ssh/authorized_keys```` and I can then login with that certificate and I have set up sudo to allow me to carry out any root based actions.

It has worked fine for me for several years.

I have added the .ssh directory in my user home directory into the user backup definitions so that the authorized_keys file is maintained.

1 Like
3

yes, it will persist.

You may want to set up a passwordless SSH login for enhanced security and convenience. By maintaining a config file in the .ssh directory of your SSH client machine, you can simply type ssh ipfire to connect. Here’s an example of what the config file might look like:

host ipfire
     Hostname ipfire.localdomain
     user cfusco
     port 222
     VisualHostKey yes
4

Thanks for the inspiration.

But that means, what ever alternative acces you create, after a core update root is back with SSH acces, right?

Who is right?

or

:question:

5

@bonnietwin and I are talking about two different things.

The USER will persist,

/etc/ssh/sshd_config might not.

Just follow the tutorial I linked, and you will have what @bonnietwin was suggesting. If you also create a config file as I described, you will limit the typing to the minimum.

1 Like
6

Got it. :bulb:

It will work until the next core update. When this is done, all I need to do is to repeat…

…and there we are again. :white_check_mark:

7

you can do that, but you do not need to. By using the Web User Interface, you can disable any login that does not use a public/private signature key, which is way more secure setup and it will not require to keep updating the SSHD configuration file.

Screenshot 2023-08-10 at 18.06.30
Screenshot 2023-08-10 at 18.06.301108×476 26.1 KB

1 Like
8

Thank you both for helping. I’ll think about the key-alternative. However, the “core” question of this topic is well answered.

1 Like
9

Hi @rallef

I have found some earlier posts on sshd that I have written where I looked in detail in the code and have found that what I said earlier is not correct. I am at the point where relying on my memory is not always as good as I would hope. Need to go look at the code.

Any changes made to the sshd_config file are backed up by IPFire so those should stay intact.

Also the sshd_config file is not created from fresh every time that save is pressed on the ssh WUI page. Individual lines are modified. Therefore if you add additional lines those will stay there. I also believe they should stay there with a Core Update but even if they didn’t the contents are backed up and can be restored very easily to get back to what you had previously.

See previous post:
https://community.ipfire.org/t/open-external-port-into-ipfire-firewall/9300/38

5 Likes