A security update for the Raspberry Pi | Hacker News Reader

A security update for the Raspberry Pi

raspberrypi.org

58 pointsalexellisuk34 comments

I wonder if instead they could setup a fake or jailed SSH that would let you login, it would then display helpful info about how to really enable SSH and then it would kick you out?

Given that you can specify a "shell" on SSH login, it's definitely possible.

To people who might experiment with this: Be careful! A teenager me, two decades ago, changed the shell of a system account to a joke program, and I didn't know they could suspend that joke and grab a system subshell. Then again, learning one the hard way every now and then is a great way to boost your working memory.

part of this can be done with openSSH by setting the banner option in sshd_config.

"Banner The contents of the specified file are sent to the remote user before authentication is allowed. If the argument is ``none'' then no banner is displayed. By default, no banner is displayed."

You don't even need a jail for that. Just add those lines to the end of /etc/ssh/sshd_config:

  Match User pi
        AcceptEnv
        ForceCommand echo 'To enable SSH, do this and that'

EDIT: added an explicit empty "AcceptEnv".

Allowing untrusted users to run programs is a recipe for disaster. Forcecommand runs its commands using a login shell that gets a lot of information from the connecting user. It wouldn't be the first time someone found an obscure environment variable that turns this into a remote shell.

TL;DR

> put a file called ssh in the /boot/ directory with any content to enable SSH which we turned off by default to prevent unauthorized access of your devise in public network.

I wonder how many people are going to scratch their head when their headless Raspberry Pi will be unable to connect to their laptop in same way as earlier without this piece of information.

I hope running sudo apt-get update, notifies them of this critical change.

SSH off by default is a change to the image, not an update through apt.

I am not sure if this is the case with the warning telling you that you are still using the default password.

I don't run Raspbian OS in my device, so I cannot verify. But reading this created doubt in my mind.

> To update your existing Jessie image with all the bug fixes and these new security changes, type the following at the command line:

I think better implementation would be asking if one is running their device in public or private network and explaining the consequences while setting up for the first time. We are asked of same question when we connect to network for first time in Windows since last several versions. I am sure tutorials made previously will create lot of frustration among newcomers.

The situation in which you want definitely want SSH enabled on a pi is when you are running it headlessly. This is an incredibly common use case, especially for more experienced users. In such a setup there is no opportunity to ask the user anything.

There are other OS too like Arch ARM, Windows core, Ubuntu Core, Kali OS etc.

As I understand the article, they've only modified the image used to deploy a fresh Raspbian, an update won't disable the ssh.

Yes this ruins just about every Pi from scratch tutorial. The worst part is if this affects the "lite" distro which is headless. The beauty of using an image like Raspbian Lite was being able to flash, ssh (ip via DHCP), change password/hostname and done.

Speaking from my own experience, google has a real problem with indexing out-dated material.

If you can flash an sd card you can turn on SSH with the new method. All my Pi's are headless, and this is a mild inconvenience at best. Way less inconvenient than the internet falling apart because users don't know anything about security.

New method is what? I sometimes mount the Linux partition if I'm flashing from a Linux PC to edit hostname etc but this is extra hassle especially if using a Mac.

You add a file named ssh to the boot directory. This permanently enables SSH. The boot partition is fat formatted and can be edited on basically any device as a result. It's right in the linked article.

...and then deletes the file.

-> or just get angry when they reboot and cant get back in without unplugging it from whatever remote location it was plugged into and taking it home to plug into a keyboard mouse and monitor.

great for the effort. i did baulk when i first started a pi to find the defaults were so insecure. But I'm not sure the solutions are that helpful. cant we just set a root password on first boot like every other nix distro.

This is for a headless first-boot scenario. - write the file - put the SD card in your pi - it boots with ssh enabled - it deletes the file - SSH in and permanently enable SSH on boot - done

It's a bit of a hassle for anyone who knows their way around linux, but Pis are marketed toward kids & other "normals". This is what happens to products designed for everyone.

Yeah, and we definitely shouldn't be training the kids & other "normals" about security..... :|

HHHrrrmpf.

A great enhancement would be: if this file (/boot/ssh) is not empty, and ~root/.ssh/authorized_keys doesn't exist, then copy the file there and set up key-only ssh access.

Another great enhancement is a lot of ethernet speaking hardware ships with a sticker or something containing the MAC address but not the pi.

If the PI shipped with a little sticker containing the MAC address that would be quite trivial to change the username and password to the mac address as seen by /sbin/ifconfig which optimistically matches the physical sticker.

Of course there aren't many possible MAC addresses however, there are more than just one.

Another entertaining idea is if you're on a private network that can't access 8.8.8.8 or whatever then assume its safe to enable ssh by default.

Or if some sort of "what is my ip address" service returns a public ip addrs that matches /sbin/ifconfig then here be dragons and disable ssh by default.

Another fun idea is when you boot the first time sshd is enabled for.... a little while, and then blocked after some time or a power cycle. Some crontabs support a syntax like @reboot sleep 300 && block_ssh.sh where block_ssh engages a iptables rule that eats incoming ssh port packets. Or whatever time period feels right. So if you're on a public network and worried, simply boot and don't plug in for 6 minutes or whatever, and you're good. Or if you want ssh then you boot, and fast as possible log in via ssh and enable it. For the extra paranoid note its not hard with a script to ensure you get 5 minutes of working ssh only once per burning of the flash image, assuming your flash isn't in write protect mode LOL.

OH edited to add my favorite new idea, if you boot and GPIO port #something is pulled to ground, then enable SSH going forward. Sure would be nice if that GPIO pin were adjacent to gnd pin. Maybe you could code in something that flashes onboard LEDs to provide feedback.

OpenWrt does it somewhat like described. If booted unconfigured you can ssh into it as root without any password. The web interface asks for a new one as the first thing to do. I would like it if they would do the same via ssh so you immediately know someone had access before you.

I think it is the best solution because it makes you immediately notice that you might not actually want anybody to login without any password at all. And any other method has worse trade offs.

Though the actual article title and URL state "For Raspbian Pixel" the author replies in the comments that this also applies to Raspbian Jessie Lite.

https://www.raspberrypi.org/blog/a-security-update-for-raspb...

I had a wee wonder whether this could in itself be exploitable -- whether some other compromise could end up dropping a file in /boot/ssh and then waiting for a reboot to enable persistence. I guess by that point, however, you've probably already lost so that threat model likely doesn't matter.

I'm interested in whether this will make a meaningful difference, however. It probably would have been nicer if Raspbian required users to put a root password into /boot/password or similar, and then deleted that file on boot -- or mandated that users change their password on first login. My concern with this is that I suspect most tinkerers will press the "make it work" button, drop /boot/ssh in, and never bother changing the password.

Isn't it a bit overkill? it's not like you can access them from the internet if they're on the local network. No?

You could say that about almost every internet connected device. I know more than one "tech-savvy" individual who has disabled their firewall "temporarily" to get something working, and then never re-enabled it, or dropped a device in the DMZ, etc.

If you have a Pi (or several) on a private network, say, behind a NAT router, there should be no problem either way.

I guess a sufficient number of people have put Pis on the Internet, or the recent wave of IoT-DDOS attacks has spooked the Raspberry people sufficiently to make this change.

It feels like a pre-emptive precaution.. I'm sure most people running a Pi at home have no way for their SSHD port to be exposed and if they do set up NAT port forwarding they should look into how to make that more secure.

I think this change isn't really so much to improve security, as to shift the blame from them, to the owner. And I think I'd do the same thing if I were them.

Edit: we should remember IPv6 is becoming a real thing, too. If I scan my web logs, see a pi in there, with v6, I might just try to ssh into it as the pi:raspberry user. Maybe I dont even need to decide it's a pi, just try it anyways.

I don't think this is over- or under- kill. This is the correct amount of kill and done earlier than it needs to be. This is a move that is always wished for in hindsight after something bad happens.

In an alternate universe where they don't make this change and raspberry pis are included in a massive attack because of their intentionally well-known default root account is listening on a running-by-default sshd, everyone would be screaming about the raspi foundations rampant incompetence.

The only place this will sting is in un-maintained 'how to set up your new raspberry pi's SD card' tutorials.

I believe that most users who want to set up a headless pi can handle this change with no problem.

Sure, but in the age of IoT, you probably shouldn't consider your local network safe :). If your IoT lightbulb, toaster or television has UPnP-ed itself and been compromised, it may be quietly nmapping away to discover other easily exploitable widgets.

So this is why my RPi is no longer responding to SSH?

No, it's not. This applies only to the images, it's not being pushed out. This only matters if you download and flash a new image to your pi.

Reply on news.ycombinator.com