Wait, so there's a shortage of IPv4 addresses and people have issues with NAT (including CGNAT) traversal all the time, yet somehow lots of Raspberry Pis end up on the Internet?
I'm sure it happens but it's hard for me to imagine someone knowledgeable enough to port forward 22 and possibly other ports across their NAT to a Raspberry Pi but not knowledgable enough to realize that enabling themselves to access the Pi over the Internet with the default username and password also enables the same ability for everyone else.
Absolutely! I distinctly remember when i was learning to develop with PHP, and i specifically chose the mysql over mysqli extension (it was at the time mysql was starting to get deprecated because it was vulnerable to SQL injections and what not) because "I don't care about security, it's just a blog I'm developing, nobody would even know it exists".
I still remember the day a young me discovered shodan.io for the first time. before that day, I had no idea just how quick and easy it was for strangers to scan the entirity of the internet and just naively assumed that there was no way anyone could find me or my devices amongst the vastness of the internet. needless to say that was a turning point for me and my security posture when it comes to anything internet-related.
I honestly still can't imagine it, and I was playing with this kind of stuff in my teens as well. Changing default passwords is part of early setup fun, and nothing spoils the fun as much as unwanted visitors in your network. I can imagine being distracted enough to actually forget about it, sure, but I can't imagine outright neglecting to do it because "fun".
I dunno, Im sure there are lots of people who have opened things up so their xbox/ps/whatever works properly (or just enabled DMZ for everything) - and just added the Pi as they would do for those.
Don't underestimate people's laziness. I've seen Pis with the default password being setup in internal networks and then exposed to the Internet (either via an actual public IP or via a port forwarding) without any change. There was even at least one case where the use left the thing like that after my remarks about security, saying it was just a temporary setup and that nobody would find it anyway...
there is a shortage, while there are plenty of IPv4 addresses. It is an interesting duality.
But just search for "raspberry pi hosting" on your favorite search engine. There are tons of companies providing hosting on Pis, as crazy as it sounds and those come with IPs (but for a semi professional hosting place hopefully with different credentials ... but given how cheap many of those are it's more hope than expectation)
If a distro configures sshd to use UPnP out of the box is deliciously evil. It wouldn't surprise me after some of the shenanigans I've seen through the years.
Hehe, I once logged into someone else’s pi by accident because I was not on the WiFi network I expect. The person had his Google credentials in a script in his home folder.
Still, it’s nice that you can get it online so wails but it was obviously not a good idea. Some software they sets WiFi and user info while flashing would be nice.
When it scans an ip address, it engages with different forms of communication protocols expected of the port, ie it talks email protocols on the email ports and web browser protocols on the web server ports.
Now its possible to change the agent name of software running behind a port, and Shodan almost certainly have some rules which throws up results as per their criteria.
Maybe you should ask their support dept for a comment to your specific question? support@shodan.io
fail2ban wouldn't help as he used the default password, it would have let him in. All you have to do is change the password or force key only logins (which is what most security conscious people do)
It is. If you really want to get after the password scans, iptables and connection tracking. After N number of new connection requests, drop for X minutes.
Any IPs that are trusted, put ahead of that logic.
Remember Watch Dogs, where you tunnel from device to device to device in order to gain access to stuff normally out of reach? I remember I thought it being too unrealistic.
Now, it's just an IoT/outdated device software thing.
LG, Samsung, or some other brand of dishwasher that happens to be inside Korea? /hj
In more serious discussion, I'm still unconvinced of the benefits of connecting your appliances to the internet considering that appliance makers are more likely to just abandon the "smart" part while the hardware is still in full working order.
An old firm I worked for had their router switch in the toilet. Not literally /in/ the toilet you understand, but above it, on a shelf. Was that really the only solution they could come up with, I wonder?
Just yesterday I've been flashing Raspberry OS to a micro SD card. Not succeeding with Balena Etcher, I opted to use the RPi imager tool, which did work (which might be an issue not in any way related). After that I added the `ssh` file to the boot partition and tried connecting to it via SSH. Providing username pi and password raspberry, connecting fails with invalid password, no matter how many times I tried. Searching all over the internet for whether the password was different nowadays, but coming up with zip, frustrated, I went to bed.
Reading this today it hits me that this change might just be the cause.
If that turns out to be the case, there should really be some indication in the RPi imager tool.
There are/were issues with using the rpi-imager [1] under Windows, which would result in the configuration information not being written to the memory card. They claimed to have fixed it, but it never worked for me.
Instead, I downloaded a live Linux dist, kde-neon [2], wrote that to a USB stick with rufus [3], booted my PC with that, and imaged under Linux. Only then did it work.
Wait, is this an update to the OS, or an update to the installer?
If I upgrade my existing Pis, are the currently in-use `pi` users (which have non-default passwords) going to be removed?
About half the article makes it sound like it's an OS update, but the other half makes it sound like an installer update, and there's a big difference between those two scenarios.
> There are also mechanisms to preconfigure an image without using Imager. To set up a user on first boot and bypass the wizard completely, create a file called userconf or userconf.txt in the boot partition of the SD card; this is the part of the SD card which can be seen when it is mounted in a Windows or MacOS computer.
> This file should contain a single line of text, consisting of username:encrypted- password – so your desired username, followed immediately by a colon, followed immediately by an encrypted representation of the password you want to use.
> To generate the encrypted password, the easiest way is to use OpenSSL on a Raspberry Pi that is already running – open a terminal window and enter
echo 'mypassword' | openssl passwd -6 -stdin
> This will produce what looks like a string of random characters, which is actually an encrypted version of the supplied password.
If you enable ssh or configure wifi settings using the Raspberry Pi Imager it creates the shell script firstrun.sh on the fat partition. This script is launched using the systemd.run option set in cmdline.txt. This script will enable the ssh service, copy over wifi settings to the ext4 partition, change cmdline.txt so it is no longer run and then reboot the pi. You could take this script and extend it to do anything you would like including copying over ssh keys.
All I did was quote the article. If you want to be a pedant, you need to take it up with the Raspberry Pi Foundation. I don't think a one-word answer here on HN, is going to do a thing.
Perhaps. But supplying a one-word correction which requires you to already understand the context fully to be able to interpret it, is difficult to see as anything but pointless pedantry, despite trying.
The only people to understand the comment, are the ones it won't help.
For all other kind of early sys admin tasks for a headless system you can mount the image to your Linux workstation and chroot into it using binfmt_misc and qemu-static. https://wiki.debian.org/RaspberryPi/qemu-user-static seems to describe it. (I haven't used those instructions, but my own 10 year old cheatsheet.)
I have used qemu-static a lot to work with ARM images and it works surprisingly well. That was before arm64 was a thing, but unless someone tells me the opposite I would not assume it makes a difference. The only thing that I remember not working is strace(1) because ptrace(2) is unimplemented. But even for that there is a special qemu option to get something similar.
What I've done for this in the past is create buildroot images that grabbed all the dynamic data from the first FAT partition (you can get it with blkid although on the Pi you can probably just hard code it.)
The BBC article that the submitted article cites says of the law requiring this:
> Included within its scope are a range of devices, from smartphones, routers, security cameras, games consoles, home speakers and internet-enabled white goods and toys.
> But it does not include vehicles, smart meters and medical devices. Desktop and laptop computers are also not in its remit.
Wouldn't an RPi be considered to be a desktop computer?
I mean, if you're in my LAN you almost certainly got there via my desktop, so you can just keylog my desktop or grab my private keys. So, again, who cares? Not having a default password adds zero security to my RPi.
Is a significant fraction of RPis really deployed to the public internet with default passwords?
I'm pretty sure the law discourages default passwords. I don't see anything wrong with default users, especially on systems which are usually single-user.
Didn't you hear? Every system has to be designed with full multiuser authentication capabilities. Never mind your threat model or lack thereof. We're all IBM customers now.
This is good because I always ended up removing the defualt user and creating another or just using root.
You can always mount the SD card partition and put your ssh key into /root to log in with that. An improvement could be to also load ssh key from the /boot partition so also windows/mac users could do that easily.
By the way using root with an ssh key is fine and not a problem in terms of security.
I don't know, I seem to be in the minority according to the comments here, but I like my default credentials, thank you very much. I have tons of gear laying around, some of which is collecting dust in a drawer, and if the default creds don't work I might be in a bind because I'm not organized enough to "do it right". These devices are not open on the internet, obviously, and per my threat model, anything on my local lan is deemed safe.
More importantly perhaps, I am willing (and actually want) to have the freedom to do this, and to take responsibility for any problems I might cause for myself.
This issue is part of a more general ethical conundrum spanning many areas of life: How much should people be protected from themselves? I guess my personal answer is, not a lot.
If they had simply removed the default password entirely without removing the default user both groups would be satisfied. It's not clear to me why they removed both.
One of the minor things I like the most about Raspbery Pi is it has the default user.
Since the days desktop OSes (i.e. Windows 2000 Professional) first started to demand the user to name themselves and sign-in (which didn't protect their data anyway and still doesn't protect today as Windows Home doesn't include BitLocker) I hated this useless complexity. I in fact met many hundreds of PC users and just a minuscule fraction of them (also of those sharing a PC among a number of family members) used an actual multi-user set-up.
Linux seemingly did this from the very first day because it's non-PC Unix legacy.
Once I tried Raspberry Pi I felt a pleasant relief: it never asked (although allowed) me to personalize it and just worked. I didn't have to invent a nickname nor expose my real name. It was just a handy tool like in good old days when you didn't have to connect your oven to WiFi.
PS: I do understand how useful the OS's multi-user mechanism is to limit what untrusted app instances can do.
That's an interesting solution. Good luck, future Raspberry Pi users! I know this will make it a little more difficult for the less technical to get their Pi units set up.
I can confirm that I have dozens of public Linux servers with SSH exposed and user `pi` is constantly being attempted for login. I ban them all immediately and automatically.
The FS is not encrypted. So just plug the SD card into another computer and edit the password file to replace the encrypted password with a null string.
Or just boot into rescue mode ( e when it asks which kernel you want to boot with, and append init=/bin/bash ; on newer OSes there's a special systemd rescue mode but no idea if it's present on Raspbian).
We've been doing this with pictures of Mariusz Pudzianowski (a Polish weightlifter), most people learned to set up their screen lockers pretty quickly. Definitely more effective than spamming people with reminders about security policy. Fun times.
Our trick was to use the unlocked account to message everyone on the general slack channel that we would bring donuts the next morning. The account owner was expected to commit to that.
What a great trick. You make an (effectively) inconsequential oversight, now you have to work for free for hours to days (pizza and drinks for 50-ish people was the worst I've seen), that's so clever. The best part has always been when they try to harass people into complying, especially the low-paid people with kids. /s
I'm glad I haven't worked at a place that had such informal "policies" in a while. There have been a few attempts by twenty-something engineers with no commitments to establish such rules, but the culture wasn't that toxic, so they (politely) got told to shut up, and that was that. People's desktop background still get changed sometimes, but respecting people's boundaries goes a long way to make work bearable for everyone. And even with desktop background pranks, if in the slightest bit unsure, communicate beforehand and accept a "no". And don't do what one guy at another company did and use a homophobic meme right before their victim's demo call with an important customer, or you deserve everything that happens afterwards.
It is not an inconsequential oversight. Most people will at least have sessions open to internal/private systems, sometimes sensitive credentials. And part of the teams will go see clients with their company laptops. You absolutely do not want people to be careless about leaving their computers unlocked.
Hence the "(effectively)" in front of inconsequential. This isn't something that will definitely and automatically result in a lot of damage, it usually won't cause any damage at all (especially if people work on desktop machines in an office that opens to a small number of badges). It may be a vector for a critical breach if enough stars align, and there happens to be an attacker nearby that is motivated, capable and willing to take the risk, and the machine is completely unobserved for long enough, but for most people, that's going to be pretty rare. Setting a short non-overridable screensaver delay is still a good idea, and screen locking should be part of security trainings and all that. It's one possible vector for deep penetration and should be treated accordingly.
But if you're effectively harassing people out of a part of their salary, I'd expect the reason to be something truly overridingly critical, and in all settings where I've seen this sort of rule instituted, it was far from that – and if it were, why would you resort to bottom-up hazing to control that risk? That disincentivizes actually improving security (by giving people another pretext to depend on uncompromised user machines), oversights absolutely will still happen and any damage that actually does occur will be hidden and conceiled even harder, since now you've created an emotional link to public shaming and people respond to that viscerally.
It was a grassroots honor thing, a game between willing participants. It was not a policy nor was it enforced. Not bringing in donuts would not penalize you in any way. There was no harassment, if you didn't manifest interest you wouldn't be picked on or left out of other (social|professional) activities. I honestly feel there was nothing toxic in the slightest in the practice, just good clean office fun.
Also, nothing was said about having to bring donuts for _everybody_. A single box of a dozen fresh assorted donuts left on the kitchen counter would do it. You'd then announce donuts to be available on a first come first serve on the same Slack channel and leave the hungriest ones fend for themselves in the hallways.
I remember a colleague had every document and a lot of stuff she was working on littered on her desktop. Nearly every little bit of desktop real estate was occupied.
Once, when again she left for lunch without locking her computer, a colleague of ours got up, made a Screenshot of her desktop, put everything on her desktop into the download folder and replaced the background with the screenshot. When she returned from lunch she was very quickly irritated that her computer had stopped working, as she could no longer click any of her files and programs.
It was a blast. And she never let her computer unlocked again.
At my old workplace, it was called being "Donut'ed". You'd email or message "donuts" from the victim's computer, and they were meant to bring in donuts that week.
The mail thing was a long tradition, until HR stepped in to explain that technically it fitted under taking over a coworker's machine and mail account, and was off bound (e.g. clicking the wrong popup, or auto-completing the mail to the wrong address would turn the joke into more complicated things)
The pi is meant to be setup to a TV or monitor with a keyboard and mouse for a full interactive login. You need some way for a human to type in authentication.
Of the 20 or RPis I’ve used over the years, I think only my first one ever got plugged into a keyboard and display. All the others were setup with ssh only.
If there's no password login doesn't prompt for one (you immediately get a shell after entering the user name) and ssh won't let you login. Removing the password is the correct default for interactive login on GNU/Linux unless you set up PAM.
Yeah default users are fine, but the basic architecture of Linux (and, to my knowledge, all operating systems) means that there’s no meaningful way to create a user without creating a password, so you can’t have a default user without a default password.
It feels like a continuation of the anti-self-determination trend of putting rounded corners and foam padding on everything. No passwords allowed on github, no running x program as root, make it as hard as possible to add unapproved browser extensions, etc. and now the raspberry pi has to be less convenient to set up to protect people who don't care enough to know what they're doing from themselves. I hate it.
"Let's irritate everyone by denying them making their own choices so we can be protected from the mistakes of stupid people" is pretty much the definition of paternalism.
They aren't making this change for fun, they are making it to comply with UK law. So if anything, blame governments for forcing nanny laws on everyone, but don't blame raspberry pi
Why does the RPi still have its own OS? The major linux distros have been doing this for years in their installers/disk images. It seems like just about every week they announce a feature that already works everywhere else. Its sorta like all the "I got a ssh server running on my Pi articles". Not at all noteworthy, except for the fact that the machine is by default quite dysfunctional.
So it was yet another reason for the RPi foundation to stop being stupid, and just conform their firmware to SystemReady, and post their fixes upstream. All these custom hoops they keep jumping through to duplicate what every other OS/firmware already supports just speaks to bad mgmt. So, yah they are the most successful Arm sbc vendor, and this all made sense 10 years ago when none of the distro's had working arm ports and there wasn't much in the way of standard arm system architecture. Those days are long gone, and the people clinging to them are just sticking their head in the sand. Particularly since 3rd parties have basically done 3/4 of the work for them and ported a full blown UEFI/ACPI environment to the darn thing.
So, they need to put on the big boy pants and stop playing the NIH game.
Because it's not aimed at the general purpose computer market?
The OS -- the features, the documentation, the learning focus, the ease-of-use planning, the designed support for school and code clubs -- is part of the product.
It's not just a little cheap linux box for nerds; it has a different focus.
Also the hardware itself is different, is it not? It has (for example) no battery-backed clock. It has connectors other distros cannot be expected to support (CSI for example).
They achieve all of this with their own slice of Debian; it's as close to being standard as is sensible.
They also provide a tool -- pi-gen -- to allow you to roll your own distro off the main; it's quite effective.
And they have a mainline OS (Ubuntu) if you want that.
But if you really want a tiny SBC without their OS platform -- buy one.
"The OS -- the features, the documentation, the learning focus, the ease-of-use planning, the designed support for school and code clubs"
It reminds me of the class a family member took recently where they were learning basic shell scripting using c-shell on a bunch of 15 year old Solaris machines. Interesting, but also somewhat harmful because they now have to translate what they have learned to linux/macos/etc should they actually get a job/etc that involves any shell scripting because bash tends to be the default.
Similarly with the RPi, the install process needs custom tools, instructions, and images because the normal distro install process (which are overwhelmingly UEFI based) simply don't work. So they are basically teaching everyone how to perform actions that any students that go into IT related fields will need to relearn.
And there isn't an argument that they are making it simpler either, since its entirely possible to create ubuntu/etc disk images as well while still burying a proper boot/etc interface in the firmware.
So, as I said earlier what they are doing made sense 10 years ago but today looks out of place vs what everyone else is doing.
PS: And as far as the hardware, normal distro's don't seem to have problems with missing RTCs (they all enable NTP AFAIK), and none of the interfaces on the board are that weird. Mainline Linux supports GPIO, and MIPI/CSI, etc.
If those don't work on the RPi in mainline, that is where the foundation should be focusing, in order to land their drivers upstream, or provide binary packages for the main distos (or both as some vendors do). They aren't special in this regard, they are only special because instead of doing what everyone else does, they created a custom linux distro.
But why, if you have a choice would you diverge. Why not install bash on the solaris machine.
Same with the pi, which despite your insistence its only a teaching tool, I suspect that is actually a small fraction of their sales. The compute modules and their carriers make that point along with the popular HATs.
As do a few other posters on this forum noting how they show up on the internet connected to peoples various IoT devices. Pi holes, Kodi boxes, cheap security cameras, on and on. Pretty much everyone I know in IT has a few of them they are using for those purposes or sitting in their junk boxes. One guy I knew literally purchased thousands of them because he was running a little hobby security business and they are great (cheap!) little security cameras given a PoE hat and a camera.
The number of students I know with them? Two, both of which were getting CS/etc style degrees, and I purchased for them to play around with. High schoolers/etc zero. Despite asking quite a number of them on the robotics teams/etc. Frankly, they aren't very good IoT devices either, wemos/arduino/etc are far more approachable if all you want to learn how to do is blink a led, or connect a moisture sensor to the internet.
So, at least where I live and the people I talk to, they are basically hacker devices.
> But why, if you have a choice would you diverge. Why not install bash on the solaris machine.
You diverge because you're designing a product and you want to. (The Raspberry Pi desktop, for example, is available to run on non-linux platforms; there is a continuum for them.)
There are plenty of Ubuntu-based Linux distros with diverging requirements; which ones do you not approve of?
They have their own intent to develop a distro with a particular focus; so does Raspberry Pi.
If you disregard intent as a factor, sure; there's no justification for any of those distros. But then if you disregard intent as a factor there's no inherent justification for _any_ distros at all.
> So, at least where I live and the people I talk to, they are basically hacker devices.
OK. But we should probably stipulate that the Foundation intends them to also be used by people who want to learn computing on a very low budget, and that is why they have chosen to create their own (reconfigurable) OS.
This doesn't answer the question of why RPi has its own OS, but I don't want to have to run an installer every time I put an OS on a RPi's SD card. I just want to write a disk image, `touch /boot/ssh` on it (so ssh gets enabled on first boot), and then have a fully-functioning system to ssh into.
8ish years ago, I wrote a script to search out Pis with port 22 opened to the internet with default un and pw. Let it run overnight.
The next morning I checked the log and it found thousands of Pis that I could have just logged into with root privileges if I wanted.
Never trust users.