Unable to login through terminal as Pi user on fresh image

[OfficialMuffin]

Upon fresh installation of NextcloudPi v1.50.3, using the default username and password pi and raspberry, I am unable to login. The terminal shows an error This account is currently unavaliable. A workaround is to activate NextcloudPi and change the Pi users password through the NextcloudPi panel. I shouldn't have to do this right? Perhaps I should of imaged the SD card with Raspberry Pi Imager and changed the Pi users password there. However, I imaged the card with BalenaEtcher instead.

[DorkForce]

I've found myself in pretty much the same situation. I downloaded a fresh image from Github, used BalenaEtcher to image the card, and when I turn on the RPI, it reaches

Debian GNU/Linux 11 nextcloudpi tty1

nextcloudpi login:

I have of course tried pi / raspberry, but I find the same message, This account is currently not available, and it goes back to the same login prompt. I was unfamiliar with the Raspberry Pi Imager you, OfficialMuffin, mentioned, and I'm less sure about using the workaround. I'll try the other imager and report back here.

[DorkForce]

No luck on that, even making sure to set the RPI user/pass before imaging. :(

[DorkForce]

I tried again, searched around some more, and found that this is intended behavior. It's certainly NOT user-friendly that this isn't clearly documented, but I found that I had to make sure that SSH + all the bells & whistles in Raspberry Pi Imager were enabled. At the very least, I would recommend that it be advised NOT to use BalenaEtcher, and talk about setting those options in RPImager.

[OfficialMuffin]

I think that on first boot, at least ask the pi user for a new password. I swear this used to be the case unless I'm mistaken.

[ghost]

Seems the install does something to the user pi. Because of the use of Debian Bullseye. I used the curl install on a working system, and not able to login anymore. "This account is currently not available"

seems i solved it by using the web NCP config and re-activate SSH under networking and set a new password for the user pi. like already mentioned. If you use Raspberry PI imager you should also be fine, as long as you change the SSH setting before writing the image to sd card or usb stick. More info is found here https://www.youtube.com/watch?v=VpO6f1oLSa4

[jetcha]

Having the same issue here, can you share exactly what settings you have done in Raspberry Pi Imager? It seems like changing the SSH setting alone does not solve the issue.

[omarmaciasmolina]

I have the same issue. I've tried to change de username and activate ssh but it didn't work. I'll keep trying...

[OfficialMuffin]

I have the same issue. I've tried to change de username and activate ssh but it didn't work. I'll keep trying...

Try the workaround I mentioned.

[omarmaciasmolina]

I don't know how acces to NextcloudPI panel without login... I've used RaspberryPi Imager

[DorkForce]

I believe these were my settings:

Set hostname: nextcloudpi.local
Enable SSH? Yes
 - Use password authentication
Set username and password? Yes
 - Username: pi
 - Password: _I put a custom password here_
Configure wireless LAN? Yes
 - SSID: _my ssid_
 - password: _my wifi password_
 - Wireless LAN country: US
Set local settings? Yes
 - Time zone: America/Chicago
 - Keyboard layout: US

[DorkForce]

After I booted up with those settings, then I used another computer in my LAN to access nextcloudpi.local

[theCalcaholic]

The default login has been disabled for security reasons. Use the NCP activation page to get access and after that use the ssh setting to enable the ncp or pi user.

The reason for this is, that you are not required to login with the pi user at all when setting up NCP. If you don't do it, anyone with physical access can just use the default credentials to get access to your server. To prevent this security flaw, all users are disabled by default until reenabled via admin UI

[turanix]

The default login has been disabled for security reasons. Use the NCP activation page to get access and after that use the ssh setting to enable the ncp or pi user.

The reason for this is, that you are not required to login with the pi user at all when setting up NCP. If you don't do it, anyone with physical access can just use the default credentials to get access to your server. To prevent this security flaw, all users are disabled by default until reenabled via admin UI

This is a lot of nonsense. The administrator can disable it if he wants. It's useless for you developers to disallow it. You are in the business of development. The administrator is responsible for the operation. Instead, document it more...

[turanix]

cannot access the server at all. neither ssh nor browser. The Raspberry imager has been configured.

it makes no sense...

[victor-rays]

If you decide to create the user with the Raspberry pi imager or the userconf.txt file the install scripts no longer sets a nologin shell for such a user, that and the references for pi user has been removed.

The pi user has been removed, not only in the install scripts and the other scripts but from the Raspberry Pi OS itself now.

https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/

It has become law in some countries to not allow default username and passwords be shipped in software for consumer IoT devices because people don't change them, then open their instances to the internet without proper security precautions, leaving them completely open for exploitation and has caused a lot of issues with IoT devices

EU has also implemented a standard disallowing this practice for IoT devices, it has not yet become law but at this point it just seems like a matter of time

ETSI EN 303 645 (2020-06) The first implementation of this standard

https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf

ETSI TS 103 848 V1.1.1 (2022-03) The latest one at the time of writing this post

https://www.etsi.org/deliver/etsi_ts/103800_103899/103848/01.01.01_60/ts_103848v010101p.pdf

Some articles that wrote about it

https://securityledger.com/2019/02/eu-calls-for-end-to-default-passwords-on-internet-of-things/

https://www.tuvsud.com/en-us/resource-centre/stories/etsi-en-303-645-cybersecurity-for-consumer-internet-of-things

[OfficialMuffin]

I understand that default passwords are a thing of the past now. However, it should be documented better in the installation instructions on how to access NCP through SSH upon first installation.

[OfficialMuffin]

I understand that default passwords are a thing of the past now. However, it should be documented better in the installation instructions on how to access NCP through SSH upon first installation.

[victor-rays]

Yes for sure, if you have the time to rewrite the docs let me know your username on the forum and I'll add you to the group so you can make changes.

The documentation is all written by volunteers and we're not that many right now and most of us are pretty busy at the moment, that's why the documentation on the forum isn't fully updated

[OfficialMuffin]

I'd be happy to contribute to the documentation 😁

[victor-rays]

That's great! 🥳 Thank you for helping out 🙏🙇

Is your username on the forum the same as here on GitHub → @OfficialMuffin ?

[OfficialMuffin]

That's great! 🥳 Thank you for helping out 🙏🙇

Is your username on the forum the same as here on GitHub → @OfficialMuffin ?

Yes it is :)

[victor-rays]

Alright, I've sent you a group invite :)

It should give you access to the drafts category and edit rights for the docs in the documentation category after you accept. There's also a wiki group chat room on matrix & telegram if you want to join that

https://t.me/NCP_Wiki_Team

https://matrix.to/#/#NCP_Wiki_Team:matrix.org

Thank you again for helping out 🙏🙇

[OfficialMuffin]

Thanks! @ZendaiOwl

[coolriderhd]

Disabling root with /sbin/nologin is a nonsense. you should change the sshd_config from this "#PermitRootLogin yes" to "PermitRootLogin no" or better "PermitRootLogin prohibit-password". Disabling root the way you did don't let administrators to do theyre job. And in case of crash, you have no more solution because you can't access console either

[coolriderhd]

Disabling root with /sbin/nologin is a nonsense. you should change the sshd_config from this "#PermitRootLogin yes" to "PermitRootLogin no" or better "PermitRootLogin prohibit-password". Disabling root the way you did don't let administrators to do theyre job. And in case of crash, you have no more solution because you can't access console either

[OfficialMuffin]

@coolriderhd Duplicate comment

[theCalcaholic]

Disabling root with /sbin/nologin is a nonsense. you should change the sshd_config from this "#PermitRootLogin yes" to "PermitRootLogin no" or better "PermitRootLogin prohibit-password". Disabling root the way you did don't let administrators to do theyre job. And in case of crash, you have no more solution because you can't access console either

The change primarily addresses physical access, not ssh access.

You still have sudo, and using the -s flag isn't difficult either, so I don't see how that would prevent admins from getting elevated permissions

[coolriderhd]

In most cases, you won't have physical access to the machine (most machines are VMs and console access is backup access). So what you do about it is irrelevant. On the other hand, I would like to see you successfully demonstrate your sudo -s access with /sbin/nologin set. For my part, when I tried to recover my access through this (I have a few years of practice on this subject), I was never able to connect. Apparently you don't know that /sbin/nologin affects all connections to the server and not just SSH connections.

[theCalcaholic]

@coolriderhd What you are saying is not true for the NCP community, where the majority of users are hosting at home on their own hardware, often singleboard computers (without virtualization). That's the scenario we need to be aware of here.

/sbin/nologin affects all interactive sessions that are created for users and it can be overwritten with the -s flag to sudo or su

[coolriderhd]

@theCalcaholic My bad, I tried with sudo -i not -s. My apologies for my previous message.

However I did a fresh install from scratch with the install.sh script. Unfortunately, at the end of the installation, sudo was not correctly configured, so sudo -s did not work either. After configuring the sudo, it works perfectly.

But you should add in the last lines a warning that sudo must be configured before leaving the root session.