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 | Two IP addresses simultaneously | Rsync issues

(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 — 192.168.0.0/16 and 10.0.0.0/8 (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

Tom

DETAILS:

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.
Two IP addresses simultaneously
Thank you for your reply to my issue.

I do understand that sshelper is using the ip that android gets, and that sshelper does not pull an ip from nowhere and anywhere, etc. It does puzzle me though why in sshelper i see a different ip to what the android phone gets.

My phone gets assigned 10.0.0.18 from the access point (dhcp), as seen in the phone's wifi settings. Proxy for the connection is set to none. Everything else on the network is assigned the 10.0.0.x ip address. However, i see the ip used in sshelper is 10.1.10.1. So the 10.1.10.1 address is on a different subnet and can't see other devices. i don't know why or how sshelper is using that ip.
This may be caused by the fact that it's a cell phone, and SSHelper defaults to the IP that Android provides as the network default. Remember when you connect to a WiFi network on a cell phone that has mobile data enabled, both sources are enabled at once, but only one of them is the network default. SSHelper always chooses the default provided by Android, for the benefit of nontechnical users of my program who want it to "just work".

The remedy in your case is to disable mobile data when you're trying to interact with the local WiFi network.

I say this because cellular mobile networks always assign addresses in the non-propagating address regions (i.e. 192.168.*.*, 10.*.*.*, 172.16.*.*). Your local network is assigning addresses from one non-propagating address space (10.0.0.*), while your carrier is assigning addresses from another (10.1.*.*). Again, to find out if this is the issue, simply turn off the mobile data feature of your device.

I would add another list of options so users can choose which network source to use, but that would increase the complexity of a program that's already way too complicated for average users. In most cases, choosing the default network source is the best decision. Interestingly, in Oreo's first version, Google chose to default to the mobile network connection over the local one, and got a lot of negative blowback from this decision, which they're in the process of reversing:

http://www.zdnet.com/article/android-oreo-bug-phones-using-mobile-data-even-when-wi-fi-is-available/
i then tried a ftp app, and it works, it used the 10.0.0.18 ip. i then tried another ssh app which also works, using the 10.0.0.18 ip - just that it is cli-bsaed and more tedious to use than your wonderful app. Also, it showed a total of 3 ip addresses, but i don't understand it enough to know what those mean, where one of the 3 is 10.1.10.1. Okay, so if I changed my program so it offered you three choices anywhere you happened to be, you would have to know enough to understand why only one of the choices is the correct one, and that would require you to know a great deal about networking and how cell phones work. This is why, for the benefit of average users, I default to Android's choice, and the only problem is, sometimes Android gets it wrong. sshelper was working fine for me until several updates ago, when this started to happen. But of course, the 'fake VPN' firewall app i use has been getting upgrades too. so i don't what could have changed within all the apps on my phone - but no updates pushed for android, this i know.

Anyway, if this is some individual problem, i can understand if you don't have the time to look into it. i was hoping maybe i'm doing something wrong, or is some easy 'fix' or something. otherwise, you can ignore this.
Try disabling mobile data when you're at home. You don't want to unintentionally use up your data allocation under those circumstances anyway.

I hope this helps.
Rsync issues
My new Pixel2 arrived and I used its fancy 'transfer' mechanism to install all my apps and settings on it from my old phone.

It worked pretty well, and SSHelper transferred across fine. I was able to ssh and scp using my existing key setup - nice!

There is one problem though - rsync doesn't seem to work. When I try to use rsync I get errors like:

rsync: connection unexpectedly closed (23078 bytes received so far) [generator] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [generator=3.1.1]
I would need to see the command string you used to initiate the file transfer (it can be tricky to get just right on an Android file transfer), but I see one issue — the sender version is out of date. Responding to a lot of user feedback, I'm using the most recent rsync version (3.1.2) and there may be some incompatibilities between versions. This is just a guess.

Another issue is this one:

https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1384503

It involves using the -z or --compress flag, which is an unsolved problem in rsync, and the remedy is ... not to use the -z/--compress flag. :) According to the linked discussion, the people managing this bug have decided they're not going to try fixing it.
I don't think it's because of the transfer process (it seems to download the apps fresh from the app store), and I don't think it's related to another problem I'm having with the Pixel2 which may mean I need to get a replacement. (If you're interested, I'm having the same problem as this person: https://www.reddit.com/r/GooglePixel/comments/77h013/pixel_2_being_replaced_under_warranty/ ) I'm sorry to hear about the Pixel issues (including the fact that it can be bent) — it looks like Google might not be up to speed on designing cell phones yet. I figured you'd want to hear about this, since it's happening with the latest version from the App Store. That's all I know about the issue so far. If there's anything you need me to do to help track down this problem, please let me know. Maybe you could tell me the exact command string you used to start the file transfer. If the -z/--compress flag is being issued, try the transaction without it. Or if you can upgrade your rsync version on the source side, the outcome would be enlightening.

I hope this helps, and thanks for your bug report.

Home | Android |     Share This Page