Home | Android |     Share This Page
SSHelper : 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

(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.

Home | Android |     Share This Page