Change default pi user

Does anyone tried to change pi user?

Are /etc/passwd , /etc/groups and rename home folder enough? Or there is some other configuration that I must take care of?

On a Raspberry Pi? Why would you need to?

Yes there are quite a few things that assume the pi user unless you use the scripts to do the install and change the install config.

Short answer, security!

For the long answer, I must say that I have, at least 10 servers (raspberry) running at different places. For all of them I use the same user name. Exchanging files, setting permissions and other things become an easier task.

What do you suggest? I Will use a preBuild imagem.

Whilst it adds a little security, if the attacker has got as far as that Iā€™d suggest you are in a sport of bother anyway. SSH keys and only allow log in via keys is the best route Iā€™d suggest.

If it is a Pi to be dedicated to Emoncms, then yes, the prebuilt image is best.

If it is a VM then use the EmonScripts.

Noted! How to enable password for sudo?
Itā€™s a dedicated Pi, but I need NodeRed for control a lot of process.

I don not understand the question. There is no ā€˜passwordā€™ for sudo.

So it isnā€™t a dedicated Pi then (dedicated by definition is to be used for one purpose).

Installing something like NR on the EmonSD image is generally a bad idea, can cause issues with other things. Best not to.

As ā€œdelivered,ā€ thatā€™s true.
Butā€¦ Could he be asking how to change it so it asks for a password?
(Not that itā€™s going to be any more secure, but this is what I took his question to mean.)

e.g. change /etc/sudoers.d/010_pi-nopasswd

from

pi ALL=(ALL) NOPASSWD: ALL

to

pi ALL=(ALL:ALL) ALL

Maybe, but that is a question for the RPi forums Iā€™d suggest and Iā€™m not a psychic so am not about to guess the question :slight_smile:

Thatā€™s fair to say, but he asked here. Are we so pressed for time we canā€™t help the guy?

I realize we donā€™t want to be a general Linux support forum, and that answering that type of
question could be taken as an open invitation to such activity. But then again, we donā€™t want to come
across as a group of elitist snobs, do we? :wink:

No special powers needed. :wink: :grin:

Ask him if thatā€™s what he meant.

sudo passwd

and follow the prompts to set a password, although Iā€™m not sure why you would want to do this as it is actually a security risk, thatā€™s why the root user account is disabled by default. I have had need to enable the root account for tasks in the past, but I would set it, use it, then I would disable it again straight away with

sudo passwd -dl

(IIRC)

Thanks everybody.
Iā€™ve been searching for a while ways of securing my emonpi server.
Iā€™ve already enabled Mosquitto Self-signed certificate, and enabled https.

We have an emonpi placed inside the University which suffers around 10,000 attacks per day. That comes from TI.
I will not change my emonpi hostname cause it brings other connection troubles, thus there is a security leak there.

Default user as pi and no sudo password defined worries me a lot. Maybe, the topic title should be changed to securing emonpi. However, that demands a long post.

@Bill.Thomson do you see any incoming problem enabling sudo password?

@borpin I understand. I really was afraid of your interpretation of dedicated since NodeRed was enabled by default in the past.

@pb66 Iā€™m donā€™t want to use root user. I just want to add another layer of security to access system files. I mean, no password is requested when I use sudo inside my emonpi server.

What are you trying to protect against? Users with permitted access doing stuff they shouldnā€™t or from anyone else accessing the device?

If itā€™s the first one you should give each user an account without sudo privileges and never share accounts/passwords.

If itā€™s the latter you should create a public/private encrypted key and disable log-in by username, that will give a much higher level of security as general user/password brute force simply wonā€™t work.

I have many RPiā€™s inside schools all across the country and whilst I do take other measures, using a key with user account log-in disabled makes all the difference, but what made even more difference to the number of attacks was to simply change the SSH port to something unrelated to SSH eg 50123.

2 Likes

I recommend following Paulā€™s advice of using encrypted keys
and disabling username log-ins altogether.