New Raspbian release "2016-11-25"

[ShiftPlusOne]

So I am using a headless RPi as a Samba server on my local network. I have deleted the pi user (using userdel if I remember correctly). I configured SSH to run on an uncommon port, and use key authentication. I then port-forwarded the machine. A couple of days ago I updated the Pi and when I connected to it this morning (from a remote location) I got the warning message about the pi password being set to default. I panicked and immediately shutdown the pi after logging in.

I'm confused because as far as I know, the pi account doesn't even exist anymore. Is this just a little semantic mix-up, or did the pi account somehow get reinstated? If so, I'm guessing I should assume the machine is compromised?

By the way, RPi is my introduction to Linux. I don't know much...yet. So any advice would be helpful.

No need to panic. An upcoming update will address the false positives.

Also, good job securing SSH properly (a password change alone is the bare minimum). Hope you've used fail2ban as well.

[bensimmo]

Could you give the maintainer a nudge to update https://www.raspberrypi.org/documentati ... te-access/
Also at some point could they add an advanced setup to include, for example, the above methods for enhancing SSH security if allowing external network access.

For people like me who come along

Maybe also add more of the advanced security info to the others as well, like VNC, etc.

I know it is probably out there on a Google search, but you've started it so teach us good techniques with regards to Pi setups.

[HawaiianPi]

No need to panic. An upcoming update will address the false positives.

I just tested the fix for spl23 and it seems to have worked, at least for my situation (locked pi account).

Didn't try deleting the pi account, but I could try that later if it will help (busy today, but I could try it tonight).

[marioscube]

Since you've run BRANCH=next rpi-update to get the USB/PXE bootcode then that MUST be re-run that whenever the apt-get stuff updates the kernel. That's obvious and there's nothing the RPF folks have done wrong with that one. You'll also need to remove /boot/.firmware_revision or rpi-update will terminate without making any updates.

When the USB/PXE bootcode is out of beta and part of the regular mainstream kernel then you may have something to moan about.

@DougieLawson
Thank you for providing me with this useful information! I did some copying and pasting of files and everything works again.
If those few lines of information were made available somewhere in the documentation that came with the SECURITY update (and I've learned those are the updates you should do) I would have had no reason to moan at all.

[njspix]

No need to panic. An upcoming update will address the false positives.

Great, thank you. Just to double-check...can I be 99.9% sure this is a false positive? I don't want to power up the RPi on my local network if there's a chance it's compromised. Then again, I don't want to have to drag it out, connect it to the TV, and all that just to confirm something people more knowledgeable than me already know.

[Martin Frezman]

As described above, you should just remove ('rm') the file:

/etc/profile.d/sshpassword.sh

[spl23]

No need to panic. An upcoming update will address the false positives.

Great, thank you. Just to double-check...can I be 99.9% sure this is a false positive? I don't want to power up the RPi on my local network if there's a chance it's compromised. Then again, I don't want to have to drag it out, connect it to the TV, and all that just to confirm something people more knowledgeable than me already know.

Deleting the pi user will result in a false positive - if you have deleted the pi user, then by definition your system is safe. This is fixed in the update that HawaiianPi has kindly tested for us - we'll release the fix on Monday.

[DaHai8]

I was one of the collection, and I stand behind the decision. We have a responsibility to protect our users....

So you shut one door and opened another?
Adding Adobe Flash support - a product Google has cut off in its browser, and even Adobe is abandoning as unsafe - yet you now include it in your Rasbian release?

You don't have any responsibility to protect your users from themselves. You have a responsibility to educate your users and help them make better decisions. You're not their mother. You should have required a password change rather than disable an interface. You took away the car instead of teaching them to drive.

Most of the recent DDOS attacks came from IP Cameras that never had their default passwords changed. What if those vendors decided to turn off web access to help 'protect' their users? No, that would have been stupid. They made the smart choice and required a password change in their new versions. You should have done the same.

Consistancy and education is the key to better security, not knee jerk reactions and after-the-fact announcements. Epic lazyness. (Yes, I'm pissed. You have no idea how much work I have to do now because you followed the mantra "There's never enough time to do it right, but there's always enough time to do it over". So you just slapped in a quick fix and will address it properly 'later'...Grrrrr)

[spl23]

I was one of the collection, and I stand behind the decision. We have a responsibility to protect our users....

So you shut one door and opened another?
Adding Adobe Flash support - a product Google has cut off in its browser, and even Adobe is abandoning as unsafe - yet you now include it in your Rasbian release?

Yes, we have included Adobe Flash. We are fundamentally an educational charity, and Scratch is one of the most widely-used programs on Pi for education. Scratch 2 requires Flash to run - don't blame us for that, blame the MIT MediaLab who made that decision - so in order to offer a program that is very important to a large section of our user base, we need to provide Flash support. The Flash plugin is disabled by default and only launched on user request when required; it does not constitute a security issue except under very specific circumstances.

Epic lazyness. (Yes, I'm pissed. You have no idea how much work I have to do now because you followed the mantra "There's never enough time to do it right, but there's always enough time to do it over". So you just slapped in a quick fix and will address it properly 'later'...Grrrrr)

You're right - I have no idea how much work you have to do now as a result of this change, but I can't imagine it is really as much as you are suggesting. On existing installations, nothing has changed even if you pull the latest updates - SSH still works, we are not forcing password changes; we are advising a password change, nothing else. On new installations, we have added the requirement to add a single file (to a partition accessible from the machine used to create the SD card) if you wish to enable SSH from a new image. I genuinely cannot see how either of these result in the huge amounts of work you are claiming.

As for a quick fix - no, this was a carefully considered decision when our team discussed all the possible options to address the security issue on Pi. By disabling SSH by default, there is no longer an easy way to gain remote access to a Pi. A forced password change does not prevent remote access, as an attacker can simply brute-force the password when the account name is known, particularly if a user chooses a weak password. The majority of users do not use SSH, so removing the default SSH access closes the route of attack without the impact on our core education market of behaviour such as password nag screens and compulsory password changes, which are not helpful in a classroom environment.

[levelcrow]

Good decision.

I think it symbolizes the transition from the Raspberry Pi as a toy to something more.

In the past 4 years, the Raspberry Pi has advanced in application to the point where security can matter and a good proportion of its userbase is not tech savvy. It's a good sign, it's the mark of a commercial success as opposed to a toy or a niche product.

You don't need much computing power to allow for most productive work in the K-12 grades. Web browsing, office suite, and perhaps an image manipulation program are all that are needed. I wonder if as the Raspberry Pi software and hardware continues to improve, it will go from an educational tool for teaching about computers to the actual computers used in education.

That would be awesome, considering that a lot of schools out there can't afford a computer lab. The Raspberry Pi Foundation would go from a computer science education mission to an education mission with a computer science focus.

[pi-anazazi]

Flash due to Scratch? REALLY?

You should really consider an "Educational Edition" of Raspian, besides one for "other" users. Like Jessie light with a GUI and ssh and root user and no password-less sudo. tbc...


RE: How much work to do. Simply imagine somebody has deployed 20 or 30 headless raspis all around the country/world with ssh as the service channel. And now you...

[bensimmo]

Flash due to scratch and many other educational programs, until they get updated for HTML5 or other.

Why should they split it isn't the aim of the RPF, it's more work for them.
I assume there is nothing to stop others making some Raspbian images with a more 'advanced user' setup and distributing it ?

[bensimmo]

Flash due to Scratch? REALLY?

You should really consider an "Educational Edition" of Raspian, besides one for "other" users. Like Jessie light with a GUI and ssh and root user and no password-less sudo. tbc...


RE: How much work to do. Simply imagine somebody has deployed 20 or 30 headless raspis all around the country/world with ssh as the service channel. And now you...

and they they haven't altered anything for them.
SSH will still be working as before.

[ShiftPlusOne]

Flash due to Scratch? REALLY?
You should really consider an "Educational Edition" of Raspian, besides one for "other" users. Like Jessie light with a GUI and ssh and root user and no password-less sudo. tbc...

That already exists. https://github.com/debian-pi/raspbian-ua-netinst
If you don't like that, roll your own (look up debootstrap).

RE: How much work to do. Simply imagine somebody has deployed 20 or 30 headless raspis all around the country/world with ssh as the service channel. And now you...

And now we what? All those pis will continue to work as they always have. Maybe they'd want to remove the new .sh file, but that's a single command.

[spl23]

I assume there is nothing to stop others making some Raspbian images with a more 'advanced user' setup and distributing it ?

Nothing whatsoever - some people already do that. We're not stopping anyone doing whatever they like in the way of customisation of Raspbian. If our image isn't what some people need, then they are at liberty to roll their own. I'd far rather they did that than keep complaining about how our image doesn't meet their particular requirements...

Just for the record - the primary focus of the image shipped by the Raspberry Pi Foundation is to support the Foundation's educational aims. We hope that many other people will also find it useful; many of the aims of the image in terms of included functionality and usability are generally applicable - but the inclusion of certain features, including Flash, is driven by what the Foundation need.

[ShiftPlusOne]

Nothing whatsoever - some people already do that. We're not stopping anyone doing whatever they like in the way of customisation of Raspbian. If our image isn't what some people need, then they are at liberty to roll their own. I'd far rather they did that than keep complaining about how our image doesn't meet their specific requirements...

To add to that, we publish our source packages and the scripts we use to create out images. Anyone can reproduce our images and modify them as they like.

[pi-anazazi]

RE: How much work to do. Simply imagine somebody has deployed 20 or 30 headless raspis all around the country/world with ssh as the service channel. And now you...

And now we what? All those pis will continue to work as they always have. Maybe they'd want to remove the new .sh file, but that's a single command.[/quote]

As I understood people updated and afterwards ssh was gone. What is true now?

And: I'm not able to built own images. Sorry. Far beyond my capabilities.

[spl23]

As I understood people updated and afterwards ssh was gone. What is true now?

You understood incorrectly.

Updating an existing image leaves SSH in exactly the same state on that image as it was prior to the update. The change is just that SSH is disabled (rather than enabled) by default on *new* images.

Contrary to popular belief in some quarters, we are not completely stupid. Nor are we completely insensitive to the requirements of our users.

[Martin Frezman]

Yes, the problem is not that existing setups stop working - unless your work flow is to always re-install. I know that sounds weird, but I get the impression that a lot of old-timers have their work-flow setup like that, and are worried that those new installs will be "broken". Also, if you are using NOOBS, then part of the NOOBS philosophy is that you can (and will, at some point) re-install your OS via the NOOBS interface. If you do that, it will, indeed, be broken.

But the lesser problem is real. The lesser problem is that this weird message starts showing up every time you log in (and, in fact, it makes the login slower). This causes people to panic and/or start threads on support boards, wasting people's time, etc, etc. While not as bad as the first problem (the one that actually breaks things), it is still a cost.

Yes, I understand that this will all eventually go away and be but a bad memory, but it still a cost. Lost productivity and all that...

[spl23]

But the lesser problem is real. The lesser problem is that this weird message starts showing up every time you log in (and, in fact, it makes the login slower). This causes people to panic and/or start threads on support boards, wasting people's time, etc, etc. While not as bad as the first problem (the one that actually breaks things), it is still a cost.

The problem with login slowing down has been identified and fixed, as have the false positive messages - the fix for these will be pushed to apt on Monday.

Yes, we didn't get this quite right on the first attempt, but in our defence, we have addressed it promptly and will have a fix available in a couple of days. We don't claim to be perfect - but we do generally do our best to promptly rectify mistakes.

[Martin Frezman]

I await the next version with bated breath...

[asandford]

Strange, some have said that it was trivial to migrate from wheezy to jessie, but now it's hard work to add a file in /boot....emptiest vessels and all that.

[HawaiianPi]

RE: How much work to do. Simply imagine somebody has deployed 20 or 30 headless raspis all around the country/world with ssh as the service channel. And now you...

And now you...

1. Ignore the security warning as a false positive because you have properly secured your deployed systems and know the warning must be a mistake.
Result of above action = no extra work whatsoever.

2. File a bug report, find out it was a false positive and do as above (while waiting for the fix).
Result of above action = a tiny bit of extra work.

3. Bitch, moan and whine on the forum about all the extra work you will have to do, only to discover that you are completely wrong.
Result of above action = no extra work that was actually necessary.

4. Check the forum for information on this issue and wait for the very quick fix due out in a few days.
Result of above action = no extra work if you already browse the forums regularly (otherwise a tiny bit of extra work).

If #4 applies to you, you could do a little extra work and thank the developers for quickly addressing the issue.
Result of above action = sadly, no extra work as I doubt many will actually bother (happy to be proven wrong here).

5. Delete the new scripts if they really annoy you, and hope no one ever changes your pi password back to raspberry.
Result of above action = a little extra work (for being too easily annoyed).

Did I miss anything?

[DaHai8]

2016-11-25:
* Prompt for password change at boot when SSH enabled with default password unchanged

Unless you changed something since yesterday (without updating the date/version of Raspbian). The above feature does NOT work.

I have enabled SSH on the Nov 25th 2016 crippled release (that I downloaded 12 hours ago) of Raspbian and booted and logged in several times over SSH and it has NEVER prompted me for a password change. It's still using 'raspberry'.

[mikerr]

"prompt" here means message - not a passwd prompt
- just a text warning message that you should change it:

Over SSH:

Code: Select all

login as: pi
pi@192.168.0.48's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Dec  3 20:17:10 2016

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

pi@raspberrypi:~ $

Under X desktop: