OpenEnergyMonitor Community

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





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


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.


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