News

All news

A security update for Raspbian PIXEL

The more observant among you may have spotted that we’ve recently updated the Raspbian with PIXEL image available from Downloads. With any major release of the OS, we usually find a few small bugs and other issues as soon as the wider community start using it, and so we gather up the fixes and produce a 1.1 release a few weeks later. We don’t make a fuss about these bug fix releases, as there’s no new functionality; these are just fixes to make things work as originally intended.

However, in this case, we’ve made a couple of important changes. They won’t be noticed by many users, but to those who do notice them and who will be affected by them, we should explain ourselves!

Why have we changed things?

Anyone who has been following tech media over the last few months will have seen the stories about botnets running on Internet of Things devices. Hackers are using the default passwords on webcams and the like to create a network capable of sending enough requests to a website to cause it to grind to a halt.

news

With the Pi, we’ve always tried to keep it as open as possible. We provide a default user account with a default password, and this account can use sudo to control or modify anything without a password; this makes life much easier for beginners. We also have an open SSH port by default, so that people who are using a Pi remotely can just install the latest Raspbian image, plug it in, and control their Pi with no configuration required; again, this makes life easier.

Unfortunately, hackers are increasingly exploiting loopholes such as these in other products to enable them to invisibly take control of devices. In general, this has not been a problem for Pis. If a Pi is on a private network in your home, it’s unlikely that an attacker can reach it; if you’re putting a Pi on a public network, we’ve hoped that you know enough about the issues involved to change the default password or turn off SSH.

But the threat of hacking has now got to the point where we can see that we need to change our approach. Much as we hate to impose restrictions on users, we would also hate for our relatively relaxed approach to security to cause far worse problems. With this release, therefore, we’ve made a couple of small changes to improve security, which should be enough to make it extremely hard to hijack a Pi, while not making life too difficult for users.

What has changed?

First, from now on SSH will be disabled by default on our images. SSH (Secure SHell) is a networking protocol which allows you to remotely log into a Linux computer and control it from a remote command line. As mentioned above, many Pi owners use it to install a Pi headless (without screen or keyboard) and control it from another PC.

In the past, SSH was enabled by default, so people using their Pi headless could easily update their SD card to a new image. Switching SSH on or off has always required the use of raspi-config or the Raspberry Pi Configuration application, but to access those, you need a screen and keyboard connected to the Pi itself, which is not the case in headless applications. So we’ve provided a simple mechanism for enabling SSH before an image is booted.

The boot partition on a Pi should be accessible from any machine with an SD card reader, on Windows, Mac, or Linux. If you want to enable SSH, all you need to do is to put a file called ssh in the /boot/ directory. The contents of the file don’t matter: it can contain any text you like, or even nothing at all. When the Pi boots, it looks for this file; if it finds it, it enables SSH and then deletes the file. SSH can still be turned on or off from the Raspberry Pi Configuration application or raspi-config; this is simply an additional way to turn it on if you can’t easily run either of those applications.

rconf

The risk with an open SSH port is that someone can access it and log in; to do this, they need a user account and a password. Out of the box, all Raspbian installs have the default user account ‘pi’ with the password ‘raspberry’. If you’re enabling SSH, you should really change the password for the ‘pi’ user to prevent a hacker using the defaults. To encourage this, we’ve added warnings to the boot process. If SSH is enabled, and the password for the ‘pi’ user is still ‘raspberry’, you’ll see a warning message whenever you boot the Pi, whether to the desktop or the command line. We’re not enforcing password changes, but you’ll be warned whenever you boot if your Pi is potentially at risk.

warn

Our hope is that these (relatively minor) changes will not cause too much inconvenience, but they will make it much harder for hackers to attack the Pi.

Is there anything I need to do to protect my Pi?

We should stress at this point that there’s no need to panic! We are not aware of Pis being used in botnets or being taken over in large numbers; your own Pi is almost certainly not currently hacked.

It’s still good practice to protect yourself to avoid problems in future. We therefore suggest that you use the Raspberry Pi Configuration application or raspi-config to disable SSH if you’re not using it, and also change the password for the ‘pi’ user if it’s still ‘raspberry’.

To change the password, you can either press the ‘Change Password’ button in Raspberry Pi Configuration, or type passwd at the command line, and follow the prompts.

cpass

This issue has caused quite a lot of discussion at Pi Towers. The relaxed approach we’ve taken thus far has been for very good reasons, and we’re reluctant to change it. However, we feel that these changes are necessary to protect our users from potential threats now and in the future, and we hope you can understand our reasoning.

How do I get the updates?

The latest Raspbian with PIXEL image is available from the Downloads page on our website now. Note that the uncompressed image is over 4GB in size, and some older unzippers will fail to decompress it properly. If you have problems, use 7-Zip on Windows and The Unarchiver on Mac; both are free applications which have been tested and will decompress the file correctly.

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

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install -y pprompt

and then reboot.

Please note that installing this update on an existing Raspbian install will not change the status of SSH on that machine; if SSH is enabled, installing the update leaves SSH enabled, and vice-versa.

223 comments

Hey there!

Just a word of warning, I know that some people have been exploiting Raspberry Pi’s because mine got taken over once. It was only connected to the internet for just 24 hours and was still taken over by someone in a foreign country (even though I changed the default password).

So everyone should be taking this seriously.

“word of warning”…
There seems to be only two options: the new password is a very easy one, OR, you did something wrong.
Could you give a better description of what happened?

Thanks for this. It’s a very good move. It is a pity though that the user is not forced to change the default password on first boot. The would greatly improve security going forward.

This is probably good enough. If you’re enabling ssh, you probably know what you’re doing. I haven’t tested, but I wonder where the prompt is; on the console?

* Prompt for password change at boot when SSH enabled with default password unchanged

http://downloads.raspberrypi.org/raspbian/release_notes.txt

It’s shown as a text block at the end of the boot scroll, so it’s immediately above the cursor when login is complete.

Great work guys. Good to see companies actually being proactive about Mirai and other such botnets. Hopefully your move will encourage other companies working in the IoT space to secure their devices.

If I run the above three commands on a headless Pi, where I have logged in using SSH with certificates, will I still be able to log in again after the reboot?

Yes – this does not change the configuration of a working Pi; it merely changes default behaviour of a clean image.

Don’t need to worry. Locked down SSH for my Raspberry pi server by doing 2 things. One: SSH by default is closed off to the outside world. 2: If they do get access to my server’s SSH port by any means, They cant log in as Pi. Its disabled. Read here:
https://www.cyberciti.biz/tips/openssh-deny-or-restrict-access-to-users-and-groups.html

has this been verified? Mine’s is on top of a 25m telecoms mast and I would hate to have to physically retrieve it.

+1 very good idea.

Some thoughts :-

Forced password change for the pi user (and ideally username change too) would dramatically help.

What would be even better would be for the /boot/ssh file to contain a password which is then set for the Pi user.

If you could also enable adding an authorized_keys file to the boot partition, and then install the keys for the pi user and reconfigure ssh to only allow key based login that’d help too.

“What would be even better would be for the /boot/ssh file to contain a password which is then set for the Pi user.”

That was suggested but I vetoed it from a usability point of view – it makes it far too easy to set the password on a running system to something unknown, by having a typo in the file, for example.

How about /boot/ssh-password

If it exists you reset the pi-password and delete the file (as leaving passwords around is bad)?

I understand why you vetoed that, perhaps we could have it so you can put an SSH Key in there though :)

disagree with simon’s note https://www.raspberrypi.org/blog/a-security-update-for-raspbian-pixel/#comment-1265929 – it is always easy for a user to typo themselves out of a system. This is nothing different. With great power goes ‘some’ responsibility.

suggestion re: pi default password:
– you know what the hashed password in /etc/shadow is in your image as delivered
– if a “pi-password” file exists in /boot (I’d suggest cleartext, not hashed), on bootup hash it and change the pi account password to that, then delete the file
– but only do this ‘once’ per imaging. If they try to reset the pi password (or break in) by trying this subsequently, do not run the ‘set the pi password’ sequence again.

I’d also like to know if you have added the wpa_supplicant.conf copying code to the ‘lite’ image. It worked great in the pixel image, but many of us don’t run that huge image, preferring to start with raspbian lite and build ‘up’

Default user/pass could just be pi/pi, that would _have_ to set of some worries in most peoples minds that such a short password should be changed.

Good points but I think we should move away from the idea of sticking config files in /boot.

The files are in the current locations for good reasons.

/boot is easily accessible from any other machine to configure your Pi as it’s a FAT filesystem. On a headless Pi it’s the only plausible way to communicate with the Pi to alter it’s configuration until ssh is up.

So this change is good, for new users they’ll get a secure Pi with a screen and keyboard and needn’t know. More sophisticated users who want to do everything headless *really* should be able to write a file to configure ssh. But it still gives a high probability of machines with a default username and password existing – hence why I’d like to force a password change if you log in over ssh. Compromise 50,000 and you can DDOS the vast majority of providers, get 1m (two months sales) and you can probably wipe out any ISP or hosting provider you like.

Like it or not, Raspberry Pi is a risk to other internet users because (until today) they were default vulnerable and shipped in quantity.

One million pi sold in two months? That’s six million per year. Those figures are ludicrous. Total sales since release is about ten million over several years. The temporary spike of the pi 2 sales it’s not a continuing trend. Histrionic fantasy does nothing for security, but it’s sure good theater! Kind of reminds me of the TSA security theater.

The figures Peter quotes are real – Pi sales have been on a consistent upward curve since launch, and we are selling between 300,000 and 400,000 a month at the moment. We hit 10 million in September, and 11 million before Christmas – you do the sums!

Ludicrous perhaps – but accurate. No histrionic fantasy here at all: we’re selling around one million every two months at the moment with no signs of a slowdown.

Amen to that!

>If you could also enable adding an authorized_keys file to the boot partition, and then install the keys for the pi user and reconfigure ssh to only allow key based login that’d help too

That would be really handy, I like this idea.

I don’t agree with this move. In the previous setup, one could prepare a raspberry pi running raspbian using only an Ethernet Cable. Now it is required to have access to a HDMI ou HDMI/VGA setup and a keyboard/mouse to setup the raspberry. The rapsberry Pi is not only to be used as a front-end device. Most of the time it is used as a back-end device. In this situations you must make the initial setup using a monitor and keyboard/mouse.
Unfortunately this option is for the benefit of security but creates dificulties in the initial setup.

How were you setting up your SD card before?

“So we’ve provided a simple mechanism for enabling SSH before an image is booted.

The boot partition on a Pi should be accessible from any machine with an SD card reader, on Windows, Mac, or Linux. If you want to enable SSH, all you need to do is to put a file called ssh in the /boot/ directory. The contents of the file don’t matter: it can contain any text you like, or even nothing at all. When the Pi boots, it looks for this file; if it finds it, it enables SSH and then deletes the file. SSH can still be turned on or off from the Raspberry Pi Configuration application or raspi-config; this is simply an additional way to turn it on if you can’t easily run either of those applications.”

Did you even read the post?

FVEY: Yes. Ok. Its an option. But from my point not the solution.
Disabling stuff just because people don’t worry about security is not the solution. Teach people that changing the default password is a requirement would be a better option.

Except it’s not. Most people use easy to crack passwords and the username is most likely still going to be ‘pi’.

Any solution that relies on teaching people the “right” way to do something is doomed to failure. If we could teach people not to click on every damn link in every damn email, we wouldn’t have spear-phishing, the current method of choice for pwning corporate executives.

I think this is a measured and intelligent response. Anyone who is technically adept enough to SSH and execute commands at the CLI is adept enough to touch a file on an SD card before plugging it into the RPi. Kudos, guys.

So hows it any different from setting any Linux server?

By default SSH is not enabled and you have to install it, either manually after install or during the install process.

Still need to use a monitor and keyboard for this.

Another option would be to use the serial console and set your Pi up that way and then reboot

Hi use PiBakery. You can prepare the raspberry from there including hostname, password, set ssh or input your WiFi for that matter.

I use it for my Zeros all the time.

Agreed!

Thank you for the information.

Good idea, but more could be done – in addition to Pete’s comment, forcing a new account to be setup for remote access and disabling ssh access for ‘pi’ prevents an attacker from knowing one half of the credentials for brute force guesses.

If you want to set it up the pi over ssh (as per Joao), the pw/user setup/disabling could it be implemented as a run-once item on first login. (If you miss the chance to do it, you re-flash the SD card, or go to HDMI/keyboard).

I find disabling SSH rather annoying. I normally use Rpi in headless mode and after the update I’ll need to drag out a monitor etc ao set the Sh back on again. A right pain.I understand the security issue bit it is still annoying.
The file solution (file SSH in boot directory ) is a help but on the next boot ssh is disabled.

Please read the post properly! SSH is not disabled on the next boot. The presence of the /boot/ssh file toggles SSH on – it is not turned off again unless the user uses raspi-config or Raspberry Pi Configuration to do so.

`/boot/` what directory is that? When you follow the published directions you get a SD card, with a root directory named XXXX (what ever you choose upon setting up the SD card with the SDFormatter tool.) There is no /boot/ folder in the NOOBS download. There are directories entitled defaults, os, and overlays. When you are creating your SD card, where, exactly where, does the `ssh` file belong? Many thanks for all the work on the project!

The /boot/folder isn’t visible on a NOOBS card – use Etcher (from http://etcher.io) to flash the standard Raspbian PIXEL image – not the NOOBS image – to an SD card. The /boot/ partition will be visible on the resulting SD card as the only thing mountable by Windows.

Securitywise the Pi out of the box is not prepared for being attached to the internet.

Making it secure takes much much more than this disabling SSH.
E.g. forcing to change the default password at first boot would be much more effective to protect the Pi from the bad bad internet world. Or even nag and nag everytime about it!
I guess most of the successful attacks are based upon logging is as pi. The user pi should not even be present with root privs on an internet connected pi.

I am amazed how much attacks are done on my wordpress sites seeing the logs, and I work hard to protect the sites, by keeping uptodate, and having security plugins.
A strong password is just the first step of the defense!

Maybe some community member with knowledge and educational skills should write a simple to follow step by step or application, “Pi secure for dummies”, on making a Pi secure.

And with easy to follow I mean not the usual hocus pocus of lines and lines Linux/Unix commands.

This seems a reasonable step that still allows headless installation.

Some of these comments exemplify why stronger control methods are necessary. The article clearly says how to enable SSH and remain headless, yet people can’t seem to read. These are exactly the same subset of people who will connect a Pi with defaults and lax security to the internet. This is why we can’t have nice things.

Agree – I was about to post something similar. The first thing I learned about writing software (in the 1970’s) was that USERS DO NOT READ THE DOCUMENTATION.

I’m with you. A lot want to enable ssh, but touching a file in /boot is a major issue.

sigh. I mean

If you want to enable on ssh (and know how to use it), touching a file should _not_ be a major issue.

Re turning interfaces on/off.
Are there any measured power saving figures available for disabling:
Camera, spi, serial & 1-wire.
I’m surprised Bluetooth and/or WiFi are not in that configuration screen! (I do realise they have to have there own set up screen but on/off would be useful to all be in one place)

Hi,
those questions are better off asking on the pi forums – they are off-topic for this front page blog article.
Texy

I prefer the way ARMbian http://www.armbian.com/ do.
They left active the SSH service but force the user to change the default root password and create a personal account with sudo capabilities.

ARMbian seem to have a different target audience – three out of the four screenshots on their homepage are of text consoles.

So is serial disabled by default now also? Can we have an easy way of enabling serial, since it is the only way to set up a Jessie Lite image headless over wifi.

Serial is disabled by default on the Pi3 because it requires the core frequency to be fixed at 250MHz (unless you use an overlay to disable Bluetooth and switch the UARTs back).

Just add “enable_uart=1” to config.txt to bring it back.

I’m a heavy user both in terms of headless and desktop – I run Cotswold Raspberry Jam where I duplicate 50 custom images of Raspbian for each of our events (150 attendees).

I think these changes are reasonable and workable. The presence or not of /boot/ssh is probably the best ease vs. security tradeoff we could have hoped for.

I think there is possibly still an argument to be had over enforced password change (or rather, enforced user selection of a password upon first install).

My suggestion is that this could be handled by the NOOBS installer rather than Raspbian. We know for *certain* that anyone setting up via NOOBS is *not* a headless user. Whereas you cannot make this assumption with a direct Raspbian image – I’ve done lots of headless Raspbian installs with the full desktop distro (although obviously not as many as I’ve done with Lite).

In related news, the custom Cotswold Raspberry Jam image of Raspbian (download torrent via http://www.cotswoldjam.org/index.php/archives/539 ) already does a few first-boot things over and above what vanilla Raspbian does. At first this was just to expand the filesystem, but now that’s handled by the vanilla Raspbian, we also use the presence of /boot/1stboot.txt to indicate that the system should set a (hopefully) unique hostname (based on the last 4 digits of the SD card ID). So instead of the hostname for all 20-50 Raspberry Pis at our events all being raspberrypi, they become rpi-1eFD, rpi-a7e9 etc. This means we can use zeroconf/avahi/bonjour to individually address any Pi on the WiFi network.

Now as well as using these images for our tutorials, we flog Class 10 uSD cards for a fiver, making a whopping quid or two profit towards our expenses. My concern is that all these images have the raspberry password.

So what I’m wondering is, can I do something similar to /boot/ssh and our existing /boot/1stboot.txt to trigger a DESKTOP dialogue box to prompt the user to set a custom password at first boot?

To do this, either I have a hacky Bash script with Zenity or similar, or (ideally) there is some kind of commandline option I can pass to the preferences app that would take it straight to the change password prompt.

I know that raspi-config already supports similar “shortcut” commandline options, because until recently we used raspi-config –expand-rootfs to trigger filesystem expansion.

Excuse me thinking aloud.

imho, this would be a first approach
Use an original card image on two microsdcards.
One card keep as it is on a desk.
One card boot o a Pi and run:
sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install -y pprompt
Turn off the Raspberry Pi with the booted card.
Take the card and put it on the desk.
On the desk there are now two cards original and updated.
Put each on USB microsd adapters.
Boot a Linux on a computer.
Insert both adapters in USB ports.
Open Two terminals, on one:
cd /media/…/(originalcard)
sudo ncdu
on the other one:
cd /media/…/(updatedcard)
sudo ncdu
Navigate, see what files changed, check /media/…/(updatedcard)/var/cache/apt/archives/pprompt…deb with dpkg querries and .deb archive extraction.
Good luck.

And add sources repository and get sources for packages in current directory with apt-get source packagenames

Andrew, you might want to have a look at the GitHub repository for my pprompt project at https://github.com/raspberrypi/pprompt

The current version just uses Zenity to prompt the user to change their password, but this is a simplification of the original, which is a dialog that popped up on launch both asking the user to change the password and givin them boxes in which to enter the new one.

If you look through the history, you’ll find a GTK application for password change and some startup scripts and services which may do exactly what you want; if not, they might be tweakable to do so without very many changes.

Thanks Simon. These are great examples and code that will be useful here.

Simon, having had a play with this I’m a bit concerned that uninstalling pprompt does NOT remove the desktop nor SSH-MOTD warning about the default password.

To reproduce:
Boot Raspbian Pixel
Enable SSH in the RPi config
Reboot
Note the SSH password warning on the desktop – good
SSH into the Pi
Note the password warning on the SSH welcome message – good
sudo apt-get remove pprompt
Reboot
Note the SSH password warning is still on the desktop – bad
SSH into the Pi
Note the password warning on the SSH welcome message – bad

I’ll see if I can figure out how to raise a bug on Github.

We have an extremely valid use case for retaining the original password without a warning message – we duplicate >60 SD cards for workshops at Cotswold Raspberry Jam and we have loads of legacy workshop PDFs/print-outs/books which specify the default password.

I have no problem with pprompt being the default. I am happy to spin my own custom Raspbian image (I do that already). But uninstalling pprompt should remove the warning message please.

Thanks for all your work – it really is wonderful; if you’re near Cheltenahm on Sat 28 Jan, do pop by and see Cotswold Raspberry Jam where we typically have 150 attendees, mostly children & parents.

Might I suggest adding some prominent text to this effect on the Raspbian/NOOBS download page? I got caught out by this today – I was setting up a new Pi Zero as an ethernet gadget and trying to get a Windows PC talking to it so there were a few things that might have been wrong. Took me a while before I realised that ssh might no longer be enabled, I had to hook it up to a screen to see what was happening.

Of course, I now know I could have done the thing with the ssh file but the download page is probably the best place to highlight this change.

Just a thought on this – why not a PAM or similar solution on login which gives a warning of default password as well (along with the motd)? Would be pretty easy to enable.

Out of interest, what does the “detect /boot/ssh” routine do such that the preference is remembered across boots? Is it as simple as “systemctl enable sshd” and the image shipping with it disabled, or is it doing something more complex (what?) please?

It does exactly the same thing as the SSH setting in raspi-config – update-rc.d ssh enable && invoke-rc.d ssh start

The presence of the file is effectively just used as a switch to make the same setting as the user would when they enable SSH in raspi-config.

Lovely, thanks Simon. Nothing weird, new nor unusual that I have to worry about.

Yes, believe it or not, we do *try* to avoid inconveniencing people any more than we absolutely have to… ;)

95% of my Raspberry Pi usage is over SSH.. this just doesn’t make sense for Jessie Lite. Are you going go only apply this change to Pixel?

Yes, we are doing it for both Jessie Lite and Jessie with PIXEL.

Please read the entirety of the post above before panicking – it does not prevent use of Jessie Lite over SSH; it merely requires one additional step when preparing a new SD card. It makes no difference to existing installations.

Simon, I think you should add a “TL;DR summary” to the top of the post, as people do not seem to be reading the entire post. ;)

– SSH will be disabled by default on new Raspbian images going foward
– If you need SSH enabled on new Raspbian image after the change (for headless access), DO NOT PANIC and add single file to the SD card (read below for details)
– Current installations will not have SSH disabled after applying the updates
– A new warning to change the default password if SSH is enabled

I’m not so sure: I’m quite enjoying punishing those with poor reading comprehension by (temporarily) raising their blood pressure.

Quite right – it took me a couple of hours to write; I don’t think expecting people to put in five minutes reading it is unreasonable… ;)

Simon,

I can understand this change for the Universal rated GUI-bundled version, but this will just be confusing for people on Lite.

While we’re talking boot-up hacks, what would be far more useful for Jessie Lite is being able to place a file called /boot/i2c for headless i2c configurations. I’ve also tried placing a wpa_supplicant.conf in /boot/ but it is never picked up on Jessie Lite. I can’t mount the Linux partition on a Mac to edit this.

Yes! The “wpa_supplicant.conf in boot” hack not working on Lite is rather inconvenient. It’s seems strange to me that this small(?) bit of functionality was not included since Lite seems prone to be used headless.

Awsome. I agree with Peter, password should be changed on first boot.

You guys are doing a great job.

Thanks for all the effort!

All goes well untel I do sudo apt-get install -y pprompt
The message is cannot find pprompt package

Thats a great step ahead! The option to still enable ssh without a display is great!

Please also consider to disable sudo without retyping the password. This way an already logged in user cannot execute all root commands. That is the first thing that I always change when using raspbian. this is a “no go” to me.

It’s a step in the right direction. I have always raised an eyebrow to the security of the RPi.

But it is a very complex and fast moving subject so I will not make any suggestions. What I knew a few months ago may not be now applicable.

Only the foundation is best placed to implement the security as they have more resources and more brains than someone regurgitating what they read on stack exchange a year ago.

A good friend once said, “if a security strategy is not inconvenient then it’s not secure.”

Thanks for the update and being open. :)

Someone should update the SSH enabling on the download page or the installation page. Unless you read this blog, you have no idea this functionality exists.

A good compromise between security and usability.

You have about the same number of people complaining it doesn’t go far enough as you have complaining it’s going to impact usability – which feels about right when implementing a controversial change.

I have impression that people are not reading as 1/4 of the comments are wrong assumptions (and in the end complains) to a rather clear post. The solution is going to the good direction. As addition it will be also possible after the detection of this file and only default password is still present, forcible change to be happen or differently the ssh be disabled again. Again only if the default password is still there

Simon and I were just discussing a new first line to this post, possibly surrounded by blink tags, saying “READ THE WHOLE THING BEFORE YOU COMMENT, PLEASE”.

blink tags – now that takes me back.
Can you find a use for marquee in there as well to finish of the retro 1990s feel :-)

Same thoughts here – the post is very clear

As it happens, I discovered the disabled ssh before I saw the post, having grabbed the new image last night and put it on a Pi this morning. So I was going to complain about needing a mouse/keyboard to enable ssh, but then read (actually read) Simon’s post. I think the /boot/ssh solution is a very good one, and means that I still don’t have to remember where my spare USB keyboard is :-)

Dave

Hi, what does pprompt do? And does it really need to be installed.

I asked as I updated earlier today (UK) before this announcement in the usual check (had to dist-upgrade to get a Raspberry-mods-something-ish part) and it still works fine.

pprompt installs the prompt which is displayed on desktop launch if SSH is enabled and the default password is ‘raspberry’. It’s standalone – you don’t need to install it if you don’t want it.

The equivalent functionality for the CLI is built into raspberrypi-sys-mods and is automatically installed when you do a dist-upgrade.

Thanks,
I’ve seen the CLI one as it was there after I rebooted after the update, I use SSH.
I’ll leave the desktop one out :)
School setups, so not changing from the default pi password, I assume the nag goes away after a few reboots?

The nag will persist for as long as you have a default password and SSH enabled. It’s not particularly intrusive on the CLI – just a message above the prompt. It’s a dialog shown at desktop launch – ‘sudo apt-get purge pprompt’ will remove it if people really want to stick with the default password on an SSH-enabled install – but then again, that is something you *really* shouldn’t do!

It would make sense on enabling ssh to first do an update on the ssh server package to ensure that the most up to date version is being enabled before exposing it to the internet.

I also second the suggestion to allow advanced users to add ssh-keys to the /boot partition. This should then disable password access to ssh. You really have to get away from password authentication.

Thanks, Simon!

I spoke to Simon when Pixel was first released when I found the bug about disabling Bluetooth not being remembered on next reboot. I didn’t see that fix listed in the release notes – but maybe that’s because it was one of those small fixes that get lumped into “various”?

Can someone tell me if it’s working now?

Yes, that’s under “various” – the fix has been available in apt for a while now.

Thanks you for doing that so quickly

Hi Simon,

This is an excellent step forward to improve the security of The Raspberry Pi eco system. Security is now a very crucial issue as some 10M are out in the wild which will present a very tempting target to hostile actors. The work around of installing a file named ssh in the /boot directory is an excellent compromise on ease of use and security and can easily be installed when creating the card

At any time ssh is potentially exposed to the internet then it is absolutely crucial that access is protected by using ssh-keys. Passwords only provide a very limited level of protection and cannot be relied upon to keep the system safe. The sudo command needs to be tightened up to require a password for each utilisation. There are now enough competent users out there to help beginners to come to terms with the additional level of security now required in view of the much higher level of hostile hacking.

Intel CPUs have been rendered insecure as they have an ARM based CPU built in, which is used as a Machine Management Unit ans can see all transactions. This means the Raspberry Pi can be an excellent system for secure communications and now just really needs a tight secure minimalist Debian install modeled on the TAILS version with fully functioning TOR in a user friendly Jessie light type install.

Ultimately the turn of events in the world and the fact that some people may use Raspberry Pis in countries that oppress person freedoms will mean that need for security will overcome convenience of ease of use which could leave owners exposed to state sanctions.

Richard

11m actually – but the rest of your point stands!

AWESOME!

Hmm, I do not like this.
(1) I set up the SD cards for my school workshops like this:
Burn an vanilla raspbian image to sd cards on a win computer (usually in train when travelling to work).
(2) plug the sd cards in one target raspi with a fixed IP address (by modifying my local DHCP server this is easy to achieve, you see that this step is done at home)
(3) start an ant-script on my workstation which uses ssh to access the target. It waits till target is booted, creates root user, copies login keys, manages the environment with raspi-config (script access), updates the libraries and copies all the tutorials and software for the class. Takes some time, but is completely unattended. And also ‘halt’s the raspi at the end.

I use this procedure as in school we collected many different SD cards with different sector count and a plain copy did not work always.

With this new setup, there are additional manual steps needed. Arggh. If you need to do such stuff 20+ times you really get bored.

As someone earlier proposed, would it be possible to have this ssh switched off only in noobs, and leave raspbian as is?

No, I’m afraid this is the way things are going to be from now on. Yes, there are going to be cases like yours where this causes additional work, but we have considered that and have had to make a judgement call as to whether the risk of Pis being hijacked via SSH is more significant than the small amount of additional work this causes some people. We think it is, so this is how the Raspbian image is going to be from now on. In your case, the time taken to create the /boot/ssh file is trivial compared to that of copying the Raspbian image to a card in the first place; you could, for example, write a simple script to both flash the image and create the file in one step.

As others have pointed out, most Linux distros do not enable SSH by default – all we are doing is coming into line with them.

I’d suggest you create the first SD card image as now, but then remount that SD card on the machine you use for creating the image, create the /boot/ssh file, and then create a new Raspbian image from that SD card.

That way your 20+ images still take the same time except the first. And you only need to tweak the first image when you download a new Raspbian image. So mostly… no change in process!

Perhaps I don’t know the correct trick, but whenever I flash a image file to a sdcard and then try to re-create a image, the resulting image is the full size of the SD card. The process I use to create a new (and small) image file with the ssh file already in place is to use a program called guestfish (to get it use ‘sudo apt-get install libguestfs-tools’). Once it is installed type the following commands:

$ sudo guestfish -w -a /2016-11-25-raspbian-jessie-lite.img
> run
> mount /dev/sda1 /
> touch /ssh
> exit

The resulting image file will stay small and can be used as normal.

Hope this helps.

Netboot is your solution. No SD cards any more.

My Pi3 boots from a USB flash drive, if I update using the commands shown above will that mess up my system and stop it booting from the flash drive?

I tried updating it once before and lost everything and had to start again!

Given that the USB boot drivers are still (I believe) an experimental feature of the kernel and not part of the released version, then yes, updating using the commands above will probably remove USB booting from your kernel. So in your case, I’d wait until USB boot is in the main kernel before updating.

Correction, the USB boot drivers are *not* in the kernel, but in the start.elf and bootcode.bin on the /boot (FAT) partition.
See https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md for all the details.
So just save your existing start.elf and bootcode.bin somewhere and restore them after the apt-get update/dist-upgrade.

Thank you for the correction! It’s not an area I’m particularly involved in – I just knew it was related to the files that are modified by rpi-update, which do include bootcode.bin and start.elf in addition to the kernel.

I believe you should still make headless-dedicated images available for advanced users – with the mention “do not use if you don’t know what you are doing”. While I do connect my Pi to my TV, I don’t even have a single keyboard at home at the moment. I only ever communicated with my Pi through SSH. If you remove that, I just can’t set it up.

You would be AMAZED how many people who don’t know what they’re doing do things marked “advanced” or “don’t use if you don’t know what you’re doing”.

Please read the whole post: you can set up SSH when you set up your SD card.

We already make three images available – standard Raspbian, Raspbian Lite, NOOBS. Every additional image we add to this set means a further set of actions we need to to do to maintain and update them whenever we release. Furthermore, if we did make an SSH-enabled image, it is inevitable that someone will get confused and download it by mistake, and a certain law says that that person will be the one who puts it on a Pi outside a firewall because they thought it was safe…

If other people want to take our images and create custom versions with SSH enabled, that’s up to them. We will not be shipping images with SSH enabled from now on, whether for expert users or not.

Of course, because the “advanced: do not use unless you know what you are doing” image must be the best one and therefore the right one to use for fancy stuff like a putting it on the public internet, right?

Unfortunately, that is exactly the thought process that some people would follow! “This is the advanced one – it must be the best one, so I’ll use it…”

This.
Makes.
Perfect.
Sense.

How long does it take to type: touch /boot/ssh

What do you mean? Windows doesn’t have the touch utility? Sheesh! :-)

Windows does, however, have “create new file” as a trivial right-click operation in any directory… ;)

Actually, there is a Windows Powershell command-let that’s the equivalent of touch:

New-Item e:\boot\ssh -ItemType file

would do the trick assuming your SD card is the e:\ volume in a Windows computer.

Powershell is not even needed, a regular Windows command prompt will do. Type exactly including the double-quotes:

type nul > “e:\boot\ssh”

Or for even lazier people, click Start menu -> Run and type:

cmd /c type nul > “e:\boot\ssh”

This seems quite a reasonable step.

It would be interesting to know though the percentage of people who have forwarded port 22 to their pi in their router but not managed to change the default password.

Keep in mind that not everyone is behind a router though.
On university campuses here they assign public IP-addresses to end-user devices directly.

(The MAC addresses of your computers/devices do are registered against your student account, so they know who to yell at if you or your devices are causing trouble.
Something that would be more difficult if NAT was used instead of public IPs)

Agreed; seems a good compromise; easy for an somebody who wants to configure SSH on a headless system, but invisible to people who don’t want it, or don’t even know about it.

Just for interest: with regard to this comment:

//
It would be interesting to know though the percentage of people who have forwarded port 22 to their pi in their router but not managed to change the default password.
//

I did an experiment for a few weeks; where I allowed SSH traffic through my router into my Pi – I actually changed the authentication to client-certificate rather than password ; but I also ran ‘sshguard’. http://www.sshguard.net/ [ which logs attacks and takes action [auto-firewalls] if it believes the threat to be sustained enough ]

After checking the logs – it was a shock to see how many bots had tried getting in (and hopefully failing!) – using default well-known usernames – ‘oracle’, ‘cisco’, ‘banana’ – and ‘pi’. [easily 5-10 attacks per day, every day]

I used a various IP->GEO tools to plot the attacks on a map of the World; this was also very suprisingly diverse and interesting.

At my work I run a terminal server that my users connect to using thin clients (about 35 of which are raspberry pi 3s).

there is an unadvertised open RDP port for so users can connect from home, it is amazing to see how many attempts there are from across the globe. They are all bouncing off my fairly strict account lockout policy and the server logs them.

So many of them have a generic ADMINISTRATOR as their attempted username but you do see some attempts at using PI even though its not SSH.

a wild gess

About 85% :)

I think this is a very good idea.

Most of my pi’s are run headless, but it’s really not going to be much of an effort to add a single file to the SD after writing the image.

In fact I always have to go in and add “hdmi_force_hotplug=1” to /boot/config.txt just in case I ever want to plug in a monitor while they are running, so it’s just a small extra step to remember.

Good work to all, a very sensible response.

There is a duty of care requirement towards end users and supplying inexperienced users with a computer and Operating System that is so insecure that it can be easily compromised is not an acceptable situation. It may cause some aggravation and a small amount of extra work but overall it is for the public good as in Pro Bono Publico:) Anyway a lot more security settings should be tweaked prior to images being rolled out for classroom of group use.

This can only be seen as a first step in a process of securing the Raspnerry Pi. If it becomes evident that the now, as I have been told:), 11M in use are easily hacked then the Raspberry Pi brand image will be heavily compromised. So far so good but this situation cannot continue for ever. It is time to enhance the reputation of the Raspberry Pi by driving up standards in security and resistance to hacking.

It could be a good time to start a Bug Hunters competition to clamp down on security issues. The speedy resolution of the Dirty COW problem is a shinning example of the how well the Raspberry Pi team works and so bodes well for the future.

Richard

Okay, as a networking professional (despite my tablet typing skills ;-) ), this is a great step forward. I like the idea of being able to set a password by adding a temp file to boot as an initialization option. I would also like the ability to set ssh to listen on alternate TCP port with a parameter in that ssh file. The way hackers sit there and bang on every ssh port they find is insane. The other thing that would be nice is a gui interface for ipchains or what ever firewall system would be useful. A good way to encourage secure thinking in design is to make access to security easy.

+1 for this, I also once made the mistake of leaving a Pi connected with default user/pw, this change will save some systems to be sure.

A suggestion to ease the transition for grumpy users:
in the download image, you could change the default ListenAddress in /etc/ssh/sshd_config from 0.0.0.0 to 192.168.0.0. That should stop almost all IoT-attacks on an unmodified vanilla Pi. And if that file /boot/ssh exists revert back to 0.0.0.

Latest image worked fine till I tried to install my printer using cups (as user pi). Chromium returned: This site can’t be reached 10.10.69.150 refused to connect.
It did work with the first edition of Pixel. After as root I could not get Chromium started ?!?.

Suggestion for inclusion in raspi-config: toggle sound to hdmi port

Ok, localhost:631 works.

Toggling sound to the HDMI port has always been in raspi-config – it’s under Advanced Options -> Audio.

For those who find this /boot/ssh file too unconvenient: Since you´ll be using some kind of software to flash your cards, this is a good time to try Pi Bakery:

https://www.raspberrypi.org/blog/pibakery/

“Behind the scenes, PiBakery creates a set of scripts that run when the Raspberry Pi is powered on (either just the first time, or every time it is powered). These scripts can be used to set up and connect to a WiFi network, and activate SSH.”

You can even have it change your password on first boot. Problem solved.

This sounds like a very nice solution. :)

Windows cannt access /boot partition, if you use NOOBS, because Windows can only access first FAT partition…

If you use NOOBS, you must have a keyboard and screen attached to the Pi, so you can turn SSH on and off via the standard applications in Raspbian.

…but then, if you use NOOBs you’d have to have a keyboard and screen attached (at least initially) to do *anything*, so not an issue.

Perhaps impossible, but wouldn’t the obvious solution have been to restrict SSH access to local network only?

Also, people calling for passwordless sudo to be removed, how is that going to help? Someone who guessed the password to get in, won’t have any trouble repeating that password to elevate?

@Simon:
You are in the right position and you may change how raspbian works and probably influence other distros as well. A more serious approach to distro security might involve utilities like fail2ban on ssh as well. Fail2ban might be light and simple to setup, easy to understand for everyone and a good tool for a basic diagnostic even for a novice user. Installing a Snort/like tool in a default image might be daunting for an average user where security is not his primary goal but fail2ban might be a good idea to understand if you’ve been targeted/scanned from someone else.
Hope it helps.

Cheers
Ben

Oh so many “experts” unable to read an entire post…
Thanks for the good sense update, RPi team.

Agreed :)

That’s the internet for ya! LoL ;-)

I have sympathy for Simon and the Pi team who have made a distro right at the user end of user-friendly in the spectrum. I also some sympathy for the end users. Some.

The harsh reality is if you run a system, or if you create one like the Pi team have, the security of the device, and the responsibility in its usage affects people beyond the device only. We all have a hand to play in making devices and the global use of networks and the internet reasonably safe. Welcome to any new system admin’s reading! With power comes responsibility! :)

Can’t comment the team highly enough to steering a course that has an eye and a care for all angles and in navigating and making good choices.

And yes, users have to read the notes. I hate to quote RTFM at anyone – its a foul thing in many ways, but at the same time, people have to read core notes and there is a case of simpler but no simpler.

Thanks as ever to all the Pi team for their remarkable and generous time and efforts!

So how do I enable ssh access now on a Raspberry Pi that is network booting (https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md)?

I’ve always been a bit worried about the default pi userid and password, as well as the ssh server being enabled by default, although both have been a convenience when teaching newbs about NOOBS and all other wonderfulness that is the Pi universe. I doubt that many have been putting their Pii on public WiFi networks for extended periods of time that don’t require a userid and password (e.g., how long do most people with lives spend on their Pi connected to open WiFi in fast food places, etc.?). Most people probably haven’t been doing things like banking and other potentially-risky activities on their Pi, either.

However, the advent of built-in WiFi on the Pi 3B and laptop-style peripherals such as the NexDock will eventually change that behavior without much thought (and none on the part of the naive), so the /boot/ssh file and pprompt solution is both simple and elegant – I believe it was Einstein who said things should be as simple as possible … but no simpler.

As for Read The Freakin’ Manual (RTFM that’s Suitable For School – SFS :) welcome to my world. Trying to convince people that installing IoT door locks, other home automation devices, and the associated hubs without changing the default userid and passwords is very difficult, not to mention WiFi hubs (do some war-driving around to see just how many open hotspots are still Out There). The exceptions are those who have suffered something like identity theft where their bank accounts were drained, their tax refund was stolen, credit instruments (up through mortgages) were taken out using their personally-identifying info, etc.

Keep up the great work – we’re enjoying each step forward, even if they’re coming way too slowly (no rest for the weary here, so the beatings will continue until morale improves – highly suggested for those there who are working less than our 18-hour SillyCon Valley startup hours here :)

Perhaps changing some default options:

1- in /etc/ssh/sshd_config
from
PermitRootLogin without-password, to PermitRootLogin no
PermitEmptyPasswords yes, to PermitEmptyPasswords no
This will prevent any root access to your PI other from
the console or sudo command while logged in via another
regular user (“pi” by default)
2- In your router NEVER redirect port 22 to your PI directly
instead use port forwarding from another port like 12000
to 22. Currently only the first 1024 are allocated to
something. You can go up to 65535, there is room to
spare.
3- force a password change of the “pi” account at first boot

Another option that helps a lot is to disable the “ping from wan” option in your router.

In my case and others i have implemented this, it caused the attacks on the routers to drop down by 95%

I noticed that Jessie Lite now installs wpa_supplicant.conf from /boot. Thanks for the nice update!

Ah yes, that’s great.

Question? How am I supposed to put a file called “ssh” in the /boot/ folder on Windows? The only partition visible is the 68MB one with the cmdline.txt etc? Putting the “ssh” file in the root, or even creating a sub-folder, and placing a file with that name does not appear to enable SSH.

I can ping the pi just fine, find it via bonjour at raspberrypi.local, but anytime I try to Putty into it, I get “Connection Refused”.

So far the only fix appears to be hooking it up to a Monitor and Keyboard, which is not very convenient for being “Headless”.

Using Jessie Lite on Pi Zero as Ethernet Gadget.

So, I just booted up a LiveCD of Linux, too access the Linux Partition, created the “ssh” file in the /boot/ folder, put it back in my Pi0, and I am still getting “Connection Refused” when trying to Putty/SSH into it.

The partition containing cmdline.txt *is* the boot partition – just put a file called ssh into the same directory as cmdline.txt.

Can I put other files in this directory for convenience? Like my /home/user dir, /bin dir, or inittab, for example. :P

Pi with the latest Raspbian image and postfix installed keep sending me the following email when user successfully login. Anyway to disable it?

*** SECURITY information for ***

Kai
See my previous comment
the short of it is
if you are using a different user id for ssh
then moved the file in /etc/profile.d/sshpass.sh
this is what I did
sudo mv sshpasswd.sh sshpass.sh-12-8-16
because i wasn’t sure but that cleared the “SECURITY” message

This is a very very bad “solution”. :-(((

Care to explain why? (or should we just take your words for it?)

I respect the reasons for this change, but shouldn’t you put a message about this on the download page???

I’ve just wasted nearly five hours trying to figure out how to enable SSH on a headless setup… Countless people with countless solutions relating to countless versions of Raspbian, and none of them worked… Needless to say this was NOT a good introduction to Raspberry Pi for me… A two minute job turned into a whole day’s work.

It is always good practice to look for and read any explanatory notes when a new version of any software is made available.

In this case the blog from Simon carried a full and detailed explanation for the reason for the new version and also a comprhensive guide as to how best to manage the new features.

New versions are not released on a whim and it means that installers need to research any changes to endure there is no negative impact existing installations.

Richard

Richard,

I’m not new to Linux, but I am new to Raspberry Pi and Raspbian. When 99% of the literature states that SSH is enabled by default, it’s not unreasonable to expect that to be the case. When most of the remaining 1% is either people with networking issues, even more so.

This blog post is entitled “A Security Update For Raspbian Pixel”. As I said I’m new to Raspbian and for starters I’m not using Pixel, I’m using the lite install as it’s a headless box. Secondly, being new to Raspbian, I did click through to the installation guide, just in case there might be something untoward I should be expecting. There was no mention of any changes.

My Pi had just arrived, and I’d done considerable research beforehand to ensure it wouldn’t be a problem setting this up headless as I’m currently in a developing country and getting access to random peripherals isn’t quite as easy as it is elsewhere in the world. I have a laptop, an ethernet cable, and a router.

The fix was simple enough when you know what to do, but other than this post, I’m yet to see mention of this change anywhere. If it wasn’t for a stackexchange post that isn’t yet indexed by Google, that I only came across because I was searching by date then I might have spent the next day digging through init scripts trying to figure out what was going on.

I am not going to be the only one who will be tripped up by this. The solution is quite simply to make an important change like this obvious during the transition period. This blog post is three down now, and the top two are about coding and robotics competitions.

When you run into an issue with a product not doing what everyone else says it does, is the company blog the first place you turn to?

I spent an entire day trying various things, and searching google because of this change to SSH being disabled, and it wasn’t until I told google to look at the last month, that I found this blog post.

Even then, all attempts at putting the SSH file, whether on the FAT or ext4 partition still resulted in “Connection Refused” when trying to access via Putty.

It wasn’t until I found a post in the forums about adding the some code to the /etc/rc.local file (Which I had to access via a LiveCD, since Windows doesn’t understand Ext4).

===========================
if [-e /boot/ssh ]; then
/bin/systemctl enable sshd
/bin/rm /boot/ssh
/sbin/shutdown -r now
else
/etc/init.d/ssh start
fi
===========================

Anthony,

I was concerned to read your comments above – you should absolutely not have had to access the /etc/rc.local file; that is the entire purpose of the process we have implemented to enable ssh based on a file in the /boot/ partition.

I have just downloaded the Jessie Lite image on my Mac at home, copied it to a card, added the ssh file to the boot partition (accessible from my Mac) and booted it on a Pi 3 – ssh was enabled as expected and I was able to connect to it. The mechanism we have implemented therefore definitely works on the Jessie Lite image – I am therefore somewhat puzzled as to why you were unable to connect.

The Pi Zero does not have any networking hardware – out of interest, when you were connecting via PuTTY, how were you connecting your Pi to the network? I suspect the problem lies in your network connection rather than an SSH issue.

Simon,

Does the ssh file in the FAT partition only work on 1st time boot? If the pi booted once, to find out I can’t access SSH, then I add the file later, does it work?

As that is the only thing I can think of that might be different.

The Pi0 is USB OTG Ethernet Gadget, communication is accomplished with Bonjour via the Host Machine which is using ipv6 for the raspberrypi.local address that I put into putty.

Simon,

I appear to have identified the issue, and it was because the “ssh” file wasn’t added to the FAT partition before the first boot…

e.g. the following command in the cmdline.txt is not re-executed?

quiet init=/usr/lib/raspi-config/init_resize.sh

The ssh file does not have to be added before first boot; on any boot, the presence of the file is checked and SSH is enabled if it is present.

The command line you quote above resizes the file system on first boot (and does only run once), but it’s got nothing to do with enabling SSH.

Simon,

Well all I know is I tried to load it up as normal, got it recognized as a usb Ethernet device, but then was blocked from SSH. I don’t know if anything else I tried to get it to work before I found a post on the forum (after restricting google to “last month”) I made trying to get it to work might have affected the “ssh” file from functioning and enabling it in my headless pi0 installation.

Eventually the only thing able to get access to it was modifying the rc.local file.

I’ve gone back and tested pre and post 1st boot, and ssh does enable like designed… now I’m just kicking myself for not starting over which would have saved me a bunch of frustration, on the upside, I learned what the rc.local file is for.

Also would be nice if there was a “change log” posted on the Downloads page.

Sorry, just saw the release notes link >.<, so you can scratch that last comment.

None of the /boot/ssh worked. Adding your script to /etc/rc.local did the trick. Thanks a lot

I think the point made was that the release notes, directly linked from the download page have specific instructions regarding this aspect.

Granted, it’s a problem that most internet search will return information that is no longer true… details of implementation and policies change all the time for any distribution and more generally software.

I for one hope that one day any search that tells me that the default password on the pi is ‘raspberry’ will be seen as a remnant of a prehistoric era where the pi was an open book. I can’t wait for that day to come.

As I said I’m happy with the change, I’m not arguing that.

Quite honestly I didn’t even see the link to the release notes on the download page. Reading it now it does indeed make note of the change, but why isn’t that mentioned in the INSTALLATION GUIDE link on the same page?

Simon Long for what it’s worth I was hacking up the rc.local file as well, in an attempt to get SSH enabled, because apparently this very important change has been relegated to single line in a 169 release notes document, and an obscurely titled blog post.

Don’t get me wrong, I appreciate everyone’s work, but this is a huge (and GOOD and important) change that is NOT made obvious, and there WILL be others tripped up and pissed off, yet it’s so easy to fix…

I understand people’s concern over documentation, but to put the other side of the case…

We always provide release notes on the download page. With every major release, we also provide a comprehensive guide to the changes in a blog post, and all previous blog posts are archived on the site for future reference and can be found with the search facility. Yes, this isn’t perfect, but it’s more than many other Linux distros do – if you can find a Linux distro which always has complete, accurate and up-to-date documentation, please let me know, as I believe such things to be as rare as pink unicorns… In the open-source world, it is an unfortunate fact that documentation is generally the lowest priority task. (Frankly, in engineering in general, it tends to be the lowest priority task!) When we make changes such as this, hundreds of online resources that are written by third-parties become out of date, but there is nothing at all we can do about that. We can (and will) update the resources on our site, but this takes time – in the interim, the blog post and release notes should provide adequate information for most users. (Assuming they actually take the time to read them – but again, while we can take a horse to water…)

Please also bear in mind that the core purpose of our Raspbian image is to provide an environment for our educational mission. SSH is not hugely relevant in schools – most simply use the image as is on local machines. The majority of our users would not have needed to know about this change anyway. Further, this change was specifically designed not to break SSH for anyone already using it – the only people who needed to know about the SSH change are those downloading the latest image and trying to use SSH on it, and they should really have read the release notes and/or the blog. It’s hard to know what else we could have done to inform people who didn’t read either of those.

As one final avenue of assistance, even those who didn’t read them and were struggling as a result would have had a rapid response if they had posted a query on our forums, which are read by my colleagues and myself, particularly immediately after a release.

You _should_ put a message about this on the download page. People is loosing a lot of (life-) time, if You change something essential and you do not mention it. If not: it’s really frustrating for everyone, even for the experienced user. You should put a message about this on the download page! Just be user friendly. Thank you.

You should give a warning about the default password every time a user logs in until it’s changed.

fail2ban should be part of raspbian.

As Yvan T. proposes change /etc/ssh/sshd_config
(PermitRootLogin without-password -> PermitRootLogin no
PermitEmptyPasswords yes -> PermitEmptyPasswords no)

_You should_ write a security doc_. The security doc should be on the download site. The security doc should be on the raspberry homepage.
You’re right: You have a responsability! Thank You!

A yet you still don’t automatically find and apply security updates… I can’t believe I have to point *the Pi people* at https://wiki.debian.org/UnattendedUpgrades

Automated updates would not be appropriate where, in a lot of cases, there is no link to the internet, the line speed is very restricted or the cost of data is very high in relation to the local level of disposable funds.

20 RasPis in some remote classroom all updating independently would swamp the link and be very expensive in data charges.

What is a good suggestion the the first world may not translate well into the third.

Richard

Install aptcacherNG. Download updates once, distribute to all. One line change on each device to add the Acquire Proxy line to apt.conf. Works flawlessly.

If systems are remote/offline, then the master can be updated when it is internet connected and then physically transported and used to update all the others.

It goes without saying that they all need the same or very similar install options and packages, otherwise an end point will try to fetch something that the master itself does not have in it’s cache. And that will clearly fail.

But it is easy to install those packages on the master, to ensure that updating the master will fetch those needed files into the cache. Yes, point the master apt.conf at itself so it caches it’s own downloads. I do this to pre fetch kernels, etc onto the master before distribution to the end point nodes.

For the scenario with remote classrooms where every Pi has identical config, then it is ideal.

(And for those of us unfortunate enough to have to maintain ms systems, wsusofflineupdate is the equvalent. Seriously, it has no equal).

+1 for automatic updates

Following the recent Raspbian update, I have uploaded an SSH file to my server to be downloaded and copied into the /boot/ directory. This SSH file is a simple txt file, containing only ssh, and is intended for others to download and use whenever they install Raspbian for the first time (as per the instructions here: https://www.raspberrypi.org/blog/a-security-update-for-raspbian-pixel/).

When testing the SSH file, I get different results. The test procedure includes formatting the SD card, copying Raspbian onto it, copying the downloaded SSH file to the /boot/ directory, booting the Raspberry Pi and logging in via SSH. Sometimes logging in via SSH works, other times I get the error message Connection closed by port 22.

The SSH file gets deleted when the connection is closed and sometimes the SSH file doesn’t get deleted even after the connection was successful.

Why does it sometimes log in successfully and at other times the connection closes? Is there a solution to the error?

This is cross-posted from raspberry.stackexchange: http://raspberrypi.stackexchange.com/questions/58410/adding-ssh-text-file-to-enable-ssh-but-having-difficulties-logging-in-via-ssh

I can’t say for sure, but when you try to connect, are you allowing sufficient time for the SSH keys to be generated first? The Pi generates its SSH keys when first booted – until the keys are generated (which takes several seconds), SSH connections will fail.

Try testing having made sure you do not attempt to connect for a minute or so after boot, just to make sure the keys have finished being generated.

Thank you very much Simon! These seems to do the trick!

I am using rspi3, purchased it 5 days back.

firstly wanted to use this headless, as suggested above placed ssh file(extensionless) at /boot/ directory, as iam using windows in my PC, i have placed ssh file at a place when i opened the memory card.

The file is getting deleted after 1st boot, but still i get a message from putty saying “connection refused”

I have left it powered ON for almost 30 mins and then tried, but no improvement.

Purchased the pi with lots of hopes to explore thing… Its been an test to my patience :(

Please help….

Exact same issue. Windows 10. Connection refused. Enable file extensions on windows and simply add a ssh file (not a folder) to the same directory as cmdline.txt.

Secondly i tried connecting my pi to HDMI display, even this time i failed, no display of home screen i am able to see on the screen.

Process i followed, connected HDIM cable,power supply to pi board.
This is second post after by previous:

I have changed 3 TVs and two HDMI cables, but i failed accessing the GUI.

NOTE:

After installing the OS i am able to ping my pi on 192.168.137.1 , by this i assume my OS installation happened properly.

Please help me, what process i need to adopt to ssh or see the display….

just installed raspbian pixel on my pi 2 . Enabled ssh from raspi-config . Cannot login to ssh on putty, says connection refused. Is anyone else facing this issue?

After doing dist-upgrade of Raspbian-Jessie-Lite-05-27-2016 on my rpi3 to the latest ssh is working but I lost the onboard wifi. iwconfig doesn’t see it yet external usb wifi dongles seem to work. does anyone know how to fix this problem?

You make nothing more secure with that!
my suggest is after 1. ssh login the user need to set a new secure passwd.

Yes, we do.

By disabling SSH completely, SSH cannot be used to remotely log into and control the Pi. Can you please explain how that isn’t more secure than having SSH enabled with a default user id and a default password, in which case it is trivial to access a Pi remotely on a public network?

Just curiosity, but how did you implement the messages “SSH is enabled and the default password…”? I’ve checked the pam.d files but I didn’t find anything out of the ordinary. Did I miss something in the PAM configuration?

It’s not currently in the PAM files (although we are planning to move it into a PAM module at some point to get round the remaining problem with passwordless sudo). At present, the scripts are in /etc/profile.d/sshpasswd.sh (for the CLI message) and /etc/xdg/lxsession/LXDE-PI/sshpwd.sh (for the GUI prompt).

Thank you very much for your replay.

Wouldn’t it be nice if the “ssh” file would be the public ssh key for the initial login, instead of it just enabling an insecurely configured ssh daemon?

and as far as usability goes: the /boot sector could easily be re-written if the key gets lost (assuming physical access).

Hi just wanted to let you know on this subject when I upgraded my raspberry lite Raspbian GNU/Linux 8
I was getting a Security notification every time I ssh’d into the system. My raspberry is headless and I use ssh to administer most of it
The difference is I don’t use the “pi” user after I set up
a new raspberry. I change the pi user password then add a new user and ssh’d with that one. .
I finally found the file that generated this SECURITY alert
notice that read “: a password is required ; TTY=pts/1 ; PWD=/home/”my_new_user_name” ; USER=root ; COMMAND=/bin/grep -E ^pi: /etc/shadow ”
in /etc/profile.d/sshpass.sh
I moved it to another file name and that cleared the false
SECURITY alert. I appreciated your the effort to protect the default installation on a complex system. I just shutter when I here the word “upgrade”.

If you do use xrdp, you can either keep using it or disable it and before enabling RealVNC.

The process will take longer than a normal update, as there’s a lot of extra stuff bundled in. For more details about the update and what’s included, read the Raspbian Pixel announcement

Greetings!

I created a fresh install and did the apt update apt dist-upgrade, rpi-update, rebooted, and now no keyboard, no mouse, and lxde style desktop with what looks like default debian artwork.
Help!

I have exact the same problem like jr3us. I upgraded my raspberry pi 3b on friday evening. This removed my pixel desktop back to the lxde desktop. And my local mouse and keyboard is inaccesible since this time. Really bad!
I can access my raspberry pi via vnc, there mouse and keyboard wirks fine. When I use the command lsusb, I can see my local mouse and keyboard. When i use Ctrl+Alt+F1, then I can use my local keyboard, but I loose keyboard control in vnc. Tests with disable vnc brought no solution.
How can I get back control to my local mouse and keyboard again?

I recently bought a new RPi3, and before I brought it up, I happened on a USENET news post by a Pi user who discussed the problem of hackers attacking Pis by using the ‘pi’ user and default password. His solution, which I adopted, was to create an actual user with real password before ever connecting the unit to the ‘Net, then eliminating the ‘pi’ user entirely. This is what I did. There is no ‘pi’ user on my unit now, and everything works fine, as far as I can see, so at least that threat is out of the way.

Indeed: that’s what we always recommend people do. Sadly, a lot of people don’t listen to recommendations, though, hence these changes!

Ok. So i finally got SSH to work.
Sort of….
First boot is via DHCP, and i get a ip in my DHCP scope.
I can SSH into it from both CLI and via putty.
I then set a static ip by addding

interface eth0
static ip_address=192.168.3.2/24
static routers=192.168.3.1
static domain_name_servers=8.8.8.8

to the /etc/dhcpcd.conf.
Reboot gives me the desired ip 192.168.3.2
I can SSH from cli, but NOT from putty!!???
“Network error. Connection refused”

What the blazes am i missing here???

Did you add the blank SSH file to the root of the SD card?

Anyone have this working under windows 10?
I add the blank SSH file but still get connection refused. Looks as though the file is removed on boot as well.

I have the same problem on Mac. The file gets removed on boot every time

Hi
I tried the magic /boot/ssh file to activate the SSH server on first boot.
It works fine but there is a major unwanted side effect : the expand_rootfs is executed bringing my file system to the size of the SD Card what I DO NOT WANT as i want to keep my backup image as low a possible for my application.

Any tips ?

That’s nothing to do with this change; it’s been standard behaviour in the image we ship for the last couple of releases. We appreciate it will cause problems for a few users like yourself, but that’s set against the large number of people who report problems due to running out of space as a result of not having manually expanded their card after flashing.

tried creating a file called ssh. Didn’t work. Turns out every time i insert the sd card into my pi the ssh file deletes itself. What am I doing Wrong?? I’ve been trying to get this to work for weeks

The file is supposed to delete itself when you boot the Pi, but ssh should be enabled as a result; if the file is being deleted, then it is being detected correctly and ssh is being turned on. If you still can’t connect, there is something else wrong in your SSH setup – some people have had problems because they didn’t wait long enough after first boot for the SSH keys to be generated.

Try taking a clean image, adding the /boot/ssh file, booting it, wait a couple of minutes, try to connect.

Thanks for the security fixes. I love Raspberry Pi ?

Great security update for PIXEL. ?

Would be a Nice feature if we in the SSH file we now have to make, could put in:

Ip
Subnet
Gateway

An easy way to set static configuration in case DHCP isen’ needed

Been trying all day to figure this out.
Tried adding the blank ssh file and still the connection is refused.

Seems like after reading some posts under this article there is some kind of bug adding the file from Windows 10. Right?

Solved it by downloading a old image. It’s not worth the hours of troubleshooting this.

Make sure the machine you use to create the ssh file is not creating it with a hidden extension – turn off the hiding of known extensions on your host machine while you create it.

Also, make sure you allow sufficient time after the first boot for the SSH key generation to complete – particularly on older models of the Pi, this can take tens of seconds.

Hi,

yes. No extensions. Tried creating it thru conext menu and thru command prompt. Didn’t work.

Also I had it on for a whole night, didn’t solve it.

Tried this on another Windows 10 computer, had the same problem with generating the SSH key/file there to. “Connection refused”

My quick fix with an older image from september worked flawless :)

So many people, including me have a hard time getting SSH to work. They probably try a lot of things from a lot of different sources that possibly make the Pi insecure again. I too cannot log in on my Pi.
– ssh file: no luck
– monitor/keyboard attached and ssh enabled: no luck
– waited for the keys to be generated; 1/5h enough?: no luck
Every time agein connection refused

What do I need to do? Open up every possible door on my firewall or on the Pi? Eventualy I’ll manage. But I doubt that the Pi will be more secure…

Please, before making such changes, please test your “solution”.

If you have indeed connected a keyboard and mouse and used them to enable SSH via raspi-config or the GUI, and you are still unable to connect, then the problem is almost certainly elsewhere in your network. Certainly if you reboot having enabled SSH via the GUI, launch the GUI Raspberry Pi Configuration application again, and it indicates that SSH is enabled, then the SSH service is running on your Pi.

As for your comment about testing – do you honestly think we release software without testing it? We tested this (comparatively small) change extensively before release, and never had a problem connecting to the Pi afterwards.

I tried a friends computer, also Windows 10. Didn’t work, connection refused. Then we tried it thru Ubuntu instead and it worked without any problems.

With all the issues about SSH I forgot to mention that my Wifi (SUB stick) wasn’t working either.
A reflashed a working Pi with the latest image. Then I couldn’t get the wifi up. Flashed again with the september image and everything went without a hickup.

We made no changes at all to wi-fi or networking between the September image and the 1.1 PIXEL release. Other than SSH being off by default, networking support is identical between those two releases.

With the latest version I couldn’t get the wifi up or the SSH connection working. When using the exact same instructions on the september version things were working within minutes.

Perhaps this has nothing to do with what the Raspbian folks changed (all credits for the hard work!), but the result is that -in my situation- it just didn’t work. Both the wifi nor SSH. I’ll switch to the forum the have this one sorted out.

Anyway, I just installed the previous version and ran an apt-get update/upgrade.

My apologies for the harsh language of my previous post. I got a bit frustrated after the struggle.

So how do I disable this new warning on bootup? My pi isn’t connected to the internet and I just want a clean desktop instead of nag messages.

Either change the default password, or disable SSH – if you are using SSH with the default password, you are leaving a security hole that may at some point be exploited; you may not be connecting to the Internet now, but that doesn’t mean you won’t connect to it in future in an unsafe configuration.

To uninstall the prompt:

sudo apt-get purge pprompt

Note that the package name has a double P at the start. pprompt not prompt.

You *must* use purge rather than remove, otherwise the file under /etc/ does not get uninstalled (see closed bug #1 which drove Simon and I round the bend for a couple of hours).

Today, for the first time I had installed the new Pixel system. There is a bug. The time dont actualize. The time system is the time of distro creation. Google and youtube dont enter.

I’ve created a script to enable the SSH server on Raspbian .img image files – without having to write the SD card first. Make sure you read the blog article above and understand the security risks.

http://aoakley.com/articles/2016-12-05-raspbian-enable-ssh.php

The headless install section:

“put a file called ssh in the /boot/ directory.”
I think should have read “Put SSH file in BOOT partition” (this worked for me.)!!

Yes, I agree. Please make it clear that the file should be in the boot partition itself, as I initially put it in the /boot directory of the second partition (to no avail of course)

The /boot directory of the second partition is a link to the boot partition anyway!

Apparently not anymore.

I downloaded and installed the image from January 11, 2017 and was unable to ssh on first boot despite creating an ssh file in the /boot directory using Ubuntu. After trying for twenty minutes I checked the SD card to find the ssh file intact. However, I noticed that the 23 files and one directory in the root directory of the boot partition are absent from the boot directory on the root partition – only the ssh file I placed there was present. When I placed the ssh file into the root directory of the boot partition, ssh was able to connect.

Hi… I have a RPi3 and I installed Raspbian Jessie and then update and upgrade it. Next I turn off it, but if I want to turn on it doesn´t start or boot. Only Jessie gives me this problem. Help me please !! Red led is on and green led is switching

This one post worked for me
Once you’ve flashed the raspbian os onto the sd card run this command on Run:
cmd /c type nul > “F:\ssh”

change the drive letter as it shows in your system.
Now, when i did this on a class 10 samsung sd card i waited for around 20 min before connecting the RPi through Putty and it worked fine.
I suggest waiting longer for a card of lower read/write speeds.
Hope this helps and thank you Mite for the solution.

Small comment: you don’t need a third party program to unzip the 4GB img file on a Mac. The venerable tar command works just fine: “tar -zxvf jessie-lite.img”

Hi..

I a newbie to the Raspberry Pi and I normally use apt-get upgrade but I see you use dist-upgrade. What’s the difference from apt-get upgrade and apt-get dist-upgrade

Many thanks

Declan

upgrade only upgrades packages which already have a version installed on your system.
dist-upgrade will make other changes, including removing conflicting packages and installing new dependent packages if required.

upgrade will do all that is needed some of the time; sometimes dist-upgrade is necessary. We tend to recommend dist-upgrade as it means the upgrade is more likely to work first time.

After installing raspian pixel unable to access ssh even if I set ssh to active.How to fix that.

Speaking of security, what are good ways to lock down a Pi that must be available for others to have physical access? What keeps them from plugging-in a monitor & keyboard to access everything on the SD card? What keeps them from pulling the SD card & plugging it into a different device to access all the files on the card? Yes, I’m a noobie, so please forgive me.

im having an issue with after the upgrade NOT being able to turn wi-fi off. in other words. I can still click the menu icon and see the AP list and turn off wi-fi is STILL an option. as far as I’m concerned, its as if the option “Turn Off Wi-Fi” doesn’t do anything at all.

While I understand the reason this was done, this solution is super sucky for those of us with monitor-free pis.

Might I suggest making ssh a 3-way switch, between “Off”, “On”, and “ssh enabler”. The ssh enabler would allow authentication to, say, pi@raspberrypi using the MAC address as a password, and would then reconfigure the pi to real ssh (probably after forcing password setting). The MAC address is easily discovered locally by pinging the Pi and looking at ARP tables, but inaccessible and to those on the ‘net. This would provide a way to “bootstrap” ssh access, without having to disconnect the Pi, take it somewhere else, wire it up and boot it, reconfigure for ssh, shutdown, take it back down where it was, wire it back up, and finally get back to what we were trying to do.

You did read all the post, right?

Including the bits about a) us not turning SSH off on existing installs, and b) being able to turn it on by putting a file in the boot partition of any new install, which you can do at the same time as you flash the image to the SD card, on the same machine that you use to do that.

There is no need to disconnect the Pi, take it elsewhere, wire it up to a monitor etc – we have specifically and deliberately provided an easy way to enable SSH for people in your situation. Is there some reason why the method we have implemented doesn’t work for you?

Comments are closed

News

Related posts

Introducing PIXEL

Naughty or Nice

N Days of Christmas

Next Post

Kosovo's First Pi Wars

Previous Post

Virtual Forest

Share this post

223 comments

wallarug

Manoel

Peter Jones

David

Raspberry Pi Staff Simon Long — post author

FVEY

JOHN Anderson

Raspberry Pi Staff Simon Long — post author

HSF3232

ian smith

Raspberry Pi Staff Simon Long — post author

Matt

vince

David

@heeedt

Jim Myers

Raspberry Pi Staff Simon Long — post author

David

Joao Alves

FVEY

Joao Alves

FVEY

Petiepooo

@heeedt

Colin Moores

Jessie

Nigel Trewartha

Raspberry Pi Staff Simon Long — post author

Zip Zit

Raspberry Pi Staff Simon Long — post author

StephenD

Ben Factor

Milliways

David

David

Chris Evans

Texy

Raspberry Pi Staff PhilE

Raspberry Pi Staff PhilE

Silviu

Silviu

Raspberry Pi Staff Simon Long — post author

Tex

oatmaster

Raspberry Pi Staff Simon Long — post author

Raspberry Pi Staff Simon Long — post author

Alex Ellis

Raspberry Pi Staff Simon Long — post author

Raspberry Pi Staff Simon Long — post author

Ed

Jan

NicoHood

richard

aaron

Alex

David Akerman

Bsimmo

Raspberry Pi Staff Simon Long — post author

ben

Raspberry Pi Staff Simon Long — post author

Grim

Don M

Raspberry Pi Staff Simon Long — post author

Don M

Pete

Raspberry Pi Staff Simon Long — post author

Peter Ryan

Silicon Jim

BlackKnight_Uk