Currently the information on how to enable SSH is buried in a PDF file that comes in the same archive as the PiAware image, could this be added to the install instructions on the web pages? It’s a serious pain having to discover that the SSH server is disabled by default and that this is by design and not a bug, and then the magic trick needed to enable it. Also, adding an option to the “send command to device” to enable the SSH server would be useful, at the moment there’s no way to set it up headless.
Sure there is; it’s exactly the same as upstream Raspbian does it, create /boot/ssh after you’ve created the sdcard (can be done on the system you used for writing the image).
I agree that the docs are in the wrong place at the moment. If you want web-accessible instructions in the meantime, see raspberrypi.org/documentati … ccess/ssh/
Right, but you have to know that in advance. If you just flash the image and put the card back in the Pi, as has been the case with all previous versions of PiAware, you get something that looks like a config issue, software issue, coding bug, who-knows-what, when you’re expecting to be able to get in via SSH but can’t. Currently the web pages tell you how to flash the image and SSH in to configure the device, but don’t mention that you can’t actually SSH in if you’ve followed the information on the web pages. So it’d be useful to have the build and install pages tell you about the absence of SSH, and that you need to manually enable it before you can continue.
Yes, if you want to enable headless remote access you need to make sure that’s set up before you make it remote. I don’t see how that is avoidable if you start from a requirement of “remote access must be off by default”. You should definitely test remote access to a system before you make it hard to access physically.
Adding an enable-ssh command to the stats page might be an option but it gets somewhat involved since there has to be a mechanism to set the password at the same time too.
(and like i said - I agree the docs need to be brought in sync; but that is a separate thing)
You don’t need to set the password since ‘touch /boot/ssh’ doesn’t either, it’s just doing the same as what that does. I was thinking just ‘touch /boot/ssh && reboot’ as the command to send.
It seems like that would make it a little too easy to enable ssh with a default password without really being aware of the consequences.
For the target audience (90% of piaware users will not use this), I think needing physical access to the device to enable ssh is a reasonable tradeoff.
It is also exactly how upstream Raspbian does it, which is a big plus in terms of keeping things simple.
Suggesstion to Flightaware:
Add /boot/ssh file to Piaware 3.3.0 image (SD card), making ssh enabled on Piaware image by default.
That would defeat the whole point of having it disabled by default, which is that we do not want to have new installs be remotely accessible with a default password.
The majority of users install the image and don’t touch it further; they don’t know or care about ssh access and they are not going to take steps to secure the default image.
I agree with “obj”.
If you know you want SSH access, then surely it makes sense to check it is installed/available before your Pi is remote?
If you don’t know what SSH is, then it won’t matter that it is not available and hence the Pi does not have that security risk.
I agree with obj & idh. Keeping ssh disabled by default makes sense.
Suggestion for further improvement:
When ssh enabling is attempted, a caution notice appears “Enabling ssh with default password makes your Pi velnurable to access by others. If you have not yet changed the default password to something else, it is highly recommended that you change it now”
You get this on login after enabling ssh if you have not changed the default password (try it!)
Again, this is the same as upstream Raspbian does…
If you create a text file in the main sd card directory called ssh you will get ssh access just like in the good old days.
Full guide to PiAware installation here:
radioforeveryone.com/p/piawa … ation.html
I agree on the security issue, and may I kindly suggest a send command to device option to enable it? Or a checkbox like MLAT?
A “send” command sounds risky. How many people are going to click on that because “it seems interesting” 
However people want MLAT so the option is good without risk.
Unless it prompts for a secure password and the person understands what that means (oh how about “PassWord”), security is compromised. But hey, maybe they don’t know or care.
But doing the simple action that “rtlsdr4everyone” describes is going to defeat those who don’t need SSH 
- I like that as the default option since if you know how to do that, SSH may be of value.
Excellent security rules! It’s important to not weaken them.