Home | Android |     Share This Page
SSHelper : FAQ/User Feedback Page

Reader inquiries and comments about SSHelper

Copyright © 2015, Paul LutusMessage Page

Android 5 External storage Issue | Choose Network Interface | Mobile Network Server Issue | Locked out! | Oreo Upgrade Problem

(double-click any word to see its definition)

Android 5 External storage Issue
i really enjoy your open source software, but after upgrading to android 5, i'm having trouble writing to the external SD card. could you please implement using the ACTION_OPEN_DOCUMENT_TREE intent to fix this? Because it's an action, not a permission, ACTION_OPEN_DOCUMENT_TREE can't be used to solve a Linux/Unix filesystem problem, the kind of filesystem that SSHelper supports. Let me explain.

One of my goals for SSHelper was to make the Android filesystem appear as much as possible like an industry-standard filesystem, so that standard Linux platform tools would work as expected, from any local or remote network locations that require and expect normal Linux/Unix filesystem behavior.

The Android ACTION_OPEN_DOCUMENT_TREE method (and other similar approaches) will only work in a Java program written specifically for Android, but because it's an Android-specific action, it doesn't work with normal native-code Linux tools like rsync and sftp (examples of protocols that SSHelper supports). This means there's no general solution to Google's apparent corporate goal of gradually eliminating those aspects of Android that resemble the open, cooperative environment of Linux.

Let me add an editorial comment. Over time Google has changed Android to handicap and sometimes eliminate usability and flexibility features, with the goal of keeping users (a) online, and (b) looking at Google's ads and providing behavioral feedback. Features that support large storage devices, which would make it unnecessary to be continuously online, or that simplify cooperation between platforms (the idea behind SSHelper), are gradually being handicapped and/or eliminated.

Android devices made by Samsung and others still support external storage devices, and those devices are becoming larger over time. By contrast, Google-branded Android devices don't accept external storage devices, and Android itself is being changed to prevent transparent, reliable access to external storage in those devices that have it, all to support the corporate goal of keeping you online, interacting with Google.

Ever wonder why your Android device can't contain more media or programs, can't accept an external storage device, or can't read/write from/to an existing storage device that contains your personal data? Ever wonder why Google apps stop working when you're offline? These limitations aren't accidental, they're by intent.

⚫    ⚫    ⚫

This is a classic example of an environmental conflict between predator and prey. You (the prey) want a device that can contain a lot of data, that can easily communicate with other devices and platforms, and that meets your needs. Google (the predator) wants you online, looking at ads and providing behavioral feedback. In the natural world, predators can't do anything they please, because some of those choices might kill off all the prey (which kills off the predator). The result is that over time both predator and prey evolve so that both get some part of what they want. These well-understood evolutionary rules apply to corporate behavior just as in nature.

Because the Android platform is open-source, and because anyone can build and sell an Android device, at some point in the future someone is going to create a device that doesn't have the kinds of hardware/software limitations we're discussing (Google), and that isn't loaded with crapware and automatically cancels its warranty if you look at it cross-eyed (Samsung), and that responds to a typical user's needs. That device will probably cost more than present offerings, but maybe intelligent shoppers will weigh the increased cost against increased usability.

I won't hold my breath.
Choose Network Interface
Hi Paul,

Is there any way to restrict the new version of sshelper to only listen on the Wifi interface?
Yes, there is — if necessary, disable other network interfaces. When adding this feature, initially I had hoped to have a way for the SShelper configuration to choose a specific network interface, but current and future Android versions don't allow individual apps to choose interfaces this way. What Android does is allow the device's user to choose which network interfaces are active, for all apps, not just mine.

If you have multiple interfaces and the wrong interface is chosen as the default, then disable any that might interfere with your preference — but this is not usually necessary. If for example you have a cell phone with a mobile interface and a wireless interface, Android is going to prefer the wireless interface, which means SSHelper will use that interface (SSHelper always uses the preferred, default interface). In such a case, that's just fine, because SShelper cannot meaningfully offer services on the mobile interface, because the mobile network only offers local, not Internet, addresses.

I made this architectural change because there are now any number of Android devices that aren't remotely like a cell phone with a wireless interface. One example is a TV set-top-box that has neither a mobile nor a wireless interface, but an Ethernet interface. This change is meant to make SSHelper useful for such a device, as well as remain open to future networking modes that can't even be predicted at present.

I hope this helps.
Mobile Network Server Issue
First of all, thanks for your app. Cue heavenly voices.

I have read the user feedback page SSHelper Network Interface section and the about freeware page, and I hope you like Oxford commas because I tend to use them a lot.

I would like to lobby, if you like, for a "don't use these interfaces" kind of functionality, in contrast to "choose these interfaces" discussed on the User feedback page. Or "restrict source IP" as an alternative, see final paragraph.

Your app provides a very elegant way to back up multiple phones. I would however quite like to avoid running sshd exposed to the open internet and was surprised to find this was not configurable, which you allude to already.

The logic is as follows (I hope it counts as logic):
- the internet is untrusted;
- in android, the mobile network is the open internet;
- sshd on the internet is asking for undesirable attention;
- changing the listening port will help but invisibility is best;
- a wifi network is not the open internet;
- sshd on wifi that typically be invisible to the internet, except by explicit exception (port forwarding at the wifi access point for example);
- a set top box eth interface would almost always be connected to a LAN arguably identical in function to a wifi network with identical local behaviour;
- not choosing the active interface is fine;
- the user chooses the active interface;
- but users aren't very reliable;
- could you possibly add a configuration item: [listen on any active network;accept wifi;accept mobile;accept blah enumerated interfaces not invented yet] where in lieu of accept all, the default is deny? - even better would be to accept only specific wifi networks, if that is even possible.

I'm fairly careful but have already found myself accidentally listening on the mobile interface.
You must understand that SSHelper cannot perform a "server" transaction on a public mobile phone connection. It can only receive data by that route — the phone companies provide a way to download content via SSH, and perform locally initiated transactions, but not offer publicly visible server functions from a mobile phone. More below. I have installed SSHelper on my wife's phone because it's such a good solution and although she's careful it's harder to ensure the phone remains suitably unexposed.

An alternative mechanism that would achieve much the same thing would be to restrict connections to a source subnet and mask (or whitelist, or FQDN?), and drop private nets if your listening IP is the internet? This would also be useful to control inbound internet connections where that connectivity was desirable.

I hope these suggestions and line of reasoning are of value and can be used by you to add functionality to your app rather than restrict it.
Okay, if this were an issue, I would provide a way to block server responses from a remote contact probe via any connection that resulted from a mobile cellular network connection — that would solve the security issue. But the mobile cellular network already provides that — the network provides an IP in a special local-only address range, which means the IP address is not publicly visible, and exposes no ports at all.

Initiating a connection to a remote site is possible, but that's also possible for any network connection the device can establish, so this is no different. Responding to a connection initiated elsewhere is not possible.

Think about this from the cellular network provider's perspective. Allowing an individual to offer a public server of any kind would be a security nightmare. That is why the cellular networks only provide IP addresses (primarily) in two set-aside ranges — and (or similar IPV6 address ranges) — ranges that cannot take part in remotely-initiated transactions. By design, these IP ranges aren't publicly accessible on the wider network.

Here's the crux of the issue:
... and drop private nets if your listening IP is the internet? SSHelper always responds to contacts initiated from the network, but if the IP range is local-only, a remote contact from the public cellular network is not possible — the cellular network makes sure of that. From the perspective of the cellular network, cell phones are not visible — they don't expose any ports, they only initiate connections to ports exposed by other servers.

At home, one can connect to a wireless router and configure the router to forward a port which makes the device visible to the wider world, but for a cell-network-provided mobile data connection, that's not possible — the network prevents it.

Before adding the ability to cooperate with any network connection the Android device might provide, I had to think this through, and I did. The reason the ability exists is to avoid second-guessing my users about the nature of their connections. As it turns out, for a locally established connection or a cellular network connection, the same IP address ranges are used, so I realized I couldn't create a way to block a specific connection that someone might need to use in some future scenario I couldn't anticipate.

Finally, in recent Android versions, the user gets to decide which network connection to use when more than one is available. And in that case, SSHelper can't unilaterally choose a connection other than the one the user chooses for the device as a whole — that's not possible.

I hope this explains the issue. I will have to add an explanation of this issue to my documentation, because I see its ramifications are not self-evident.

Thanks for writing.
Locked out!
Thank you so much for creating SSHelper, it saved some of my precious data I believed lost on my phone. I broke my phone - diplay went black and touch didn't work. No USB debugging/adb possible, everything was locked down. I tried 100 different FTP/SFTP apps, but all of them require an additional press of "Start" to start the server after the app starts - which I can't without touch.

Here SSHelper saved me. I installed it remotely via PC, unlocked the phone using the fingerprint sensor, started SSHelper with voice command and voila - I could access my data.

That was such a revelation, I was absolutely desperate. Thank you so much, may the force (or at least some quantum field fluctuations) be with you.
You're most welcome — I'm glad SSHelper was able to resolve this problem for you.

BTW it's an interesting technical account, one that I might not have anticipated. It's always nice to have command-line access when things get difficult.

Thanks for giving me this feedback.
Oreo Upgrade Problem
Thanks for producing this (SSHelper). I've been using it for years.

Has any one else seen problems like this? Recently retired, I can put in any amount of work that will help to debug or help to fix. I'm looking for any hints that might help identify the problem for now.

Thanks for any help



I recently updated my wife's phone to Oreo. After the upgrade I could not ssh into it. This broke her automatic photo backup that I do with ssh and rsync. I'm currently working with a fresh reinstall of the SSHelper app on her phone.

When I look at the log on her phone it seems similar to the log from my phone (which works) in its start up log items but it records nothing about connection attempts.
Yes, I'm aware of this problem and I'm eager to fix it, but I can't act on it until one of my four Android devices gets updated to Oreo. And because my app uses native-code ARM-processor binaries, I can't run the program in a desktop Android emulator either — it has to be a real Android device.

I'm very sorry about this — it arises because as time passes, Google has increased the restrictions on code executed by native binaries. I think I can fix it, but not without a real Android device running Oreo.

Thanks for your report, and again, I'm very sorry about this problem, which I'm powerless to fix until I get updated.

Home | Android |     Share This Page