SSHelper : FAQ/User Feedback Page

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

[ NOTE: In SSHelper 11.2 and above, Rsync is once again operational ]

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.

Intel Atom Problem

It doesn't work on my phone. Specifically, when I run the app, I get a message which says (repeatedly) 'The server is not running. To fix this, click the "Restart" menu item". The log has entries very similar to those mentioned by reedog117 at https://forum.xda-developers.com/android/help/qa-sshelper-free-android-ssh-server-t2948604 (third message down, which is strangely numbered #4). I note that both of us have ASUS devices, I looked into this, and your device uses an Intel Atom processor. The Intel Atom isn't an ARM-family processor, it's based on the x86 family. My application uses ARM binaries so it can't be run on Android devices that use non-ARM processors. but I also found someone on the internet with an almost identical device to mine which works. That person must have a device which, in spite of how similar it sounds, has an ARM processor.

The reason my program seems like it's almost going to work is because much of it is written in Java, which runs anywhere. But the key components, those that perform the actual Secure Shell functions, are binaries that require an ARM processor.

Sorry.

Network Connection Failure in Newer Android Versions

I have been getting a number of reports of a connection failure between desktops/laptops and Android 8.0+ devices, even though a WiFi connection is clearly established.

Today I figured out what's going on. After a few minutes of no network traffic, Android prevents an established connection from responding to incoming network traffic. But if you ping from the Android device to a desktop/laptop, the connection comes to life again.

First, because an incoming ping won't work, SSHelper isn't the problem, Android is (a ping transaction doesn't require SSHelper to be installed). Second, this is apparently a power-saving scheme in recent Android versions, where the Android device stops responding to incoming connection attempts, but will come to life if an outgoing connection is attempted (a ping or a Secure Shell transaction), after which the connection will stay available for a few minutes.

This is an Android issue, not an SSHelper issue (it's caused by a recent Android policy of aggressively closing background applications), but there's a user setting that may help. In Android 8.0 go to Device Maintenance, select Battery, select Unmonitored Apps and add SSHelper to the list (other Android versions may have a similar setting). This prevents Android from killing the SSHelper background server, but it uses more battery power.

Prevent Android's "Close all" function from closing the SSHelper server

I have been getting some user feedback that the "Close All" function closes the SSHelper server in some (but not all) Android versions, in cases where the user wants the server to persist. This is something that Android does and that my program cannot independently override.

It turns out there is an easy Android setting to prevent this:

Enter the "Close All" display.
Press the three vertical dots at the upper right.
Choose the "Lock apps" menu option.
The first time this function is activated, an explanatory screen will be displayed — read and dismiss it.
In the upper-right corner of the displayed SSHelper application, a padlock appears that will display as locked or unlocked. Click it to make your choice — if it displays as locked, SSHelper's server will not be closed by "Close all."
Select "Done" at the top of the display.

How to report program errors

This is a great package; I love that you've included the unix utilities that should have included in Android.

Previous versions have always worked fine. When I rebooted after installing version 10.6 it popped up a window saying "Unfortunately sshelper has stopped". Starting it manually, and clearing the application's data and cache, produces the same result.

The phone is a Nexus 5.

I know this may not be enough information to troubleshoot the problem. If there is more information I can provide please let me know. If there are application logs please tell me how to find them... I would love to solve this, but the crash doesn't appear in the Google error reporting database. The Android development environment has an automatic crash reporting scheme that automatically reports any out-of-bounds conditions for apps installed from the Google Play Store, but I am not seeing any SSHelper reports of failures at all, from anyone, for the past 7 days.

This reporting system requires that you opt-in to sharing application error data:

On your device, go go the "Google" menu item ... three-dot menu at the upper right ... Usage & Diagnostics ... Enable (your Android version might require a different sequence of actions). Then provoke the error condition and shortly thereafter I will see the reason for it. I don't run Android 6.0.1 so I wouldn't be able to detect the error condition directly, but with a report I should be able to find and fix the problem.

I hope this helps.

Android 9 Issues

I wanted to let you know that SSHelper does not work under Android Pie (Android 9) unfortunately. Yes — for most Android devices this problem is resolved by installing/updating an SSHelper version 11.5 or above.

Installation strategy on older Android versions

That device should have worked, and unfortunately (not having a device of that vintage) I have no way to find out why it didn't. The only suggestion I have is to completely uninstall and reinstall SSHelper on that device (detailed description), so any leftovers from the prior version are removed.

Have done this. Don’t know if it helped, but wiped data before uninstalling and reinstalling. SSHelper now functioning beautifully again. Thanks! This is important and welcome news. I'll have to make sure others hear of this remedy.

I very much appreciate your report. As always, thank you! I may not always remember to say it, but this is the program that for me makes Android a properly usable environment. Just excellent. You're most welcome.

Missing Library in Android versions < 5.0

Thank you for the fast answer!

Unfortunately I have already version 12.0 installed. This is the version where I get the message

sshd: CANNOT LINK EXECUTABLE: could not load library "libandroid-support.so" needed by "/data/data/com.arachnoid.sshelper/bin/sshd"; caused by cannot locate symbol "wctomb" referenced by "libandroid-support.so"...

and which I reinstalled twice whit rebooting. Well, sorry — I just did some research and it turns out that Android versions < 5.0 don't have that required library (i.e. wtomb). Because of new requirements I need to change the specification for the Android versions my app supports.

Update: It's possible that an earlier SSHelper version from my old-versions archive may resolve this issue. Just downoad and install an earlier SSHelper version.

This comes about because for a Play Store listing Google now requires binary applications like mine to be relocatable in memory as a security measure, which means I can't include an entire support library statically linked as I did in the past, and that, in turn, means I completely rely on certain Android libraries being present, and ... wait for it ... the missing library is only available for Android versions 5.0 and newer.

I'm very sorry about this. Again, this change is forced on me by the new Google Play Store requirements.

Older SSHelper Versions

thank you so much for the excellent SSHelper! I've been using it for a number of years at a basic level without issue. I'm unsure why but today my Nexus 5 with Android 4.4.4 failed to successfully load the server V. 12.0 The msg to restart the server failed & indeed after turning off/on the device. I now have no SSHelper on the device & am unable to download from Play Store. After reading your notes I discovered Android 4.4.4 is only supported to SSHelper V. 6.8. I'd like to download this version please but haven't been able to find it (or a later version supporting 4.4.4). I now have an archive of older SSHelper versions for circumstances like this — it is located here. Just download and install an earlier version.

I'm sorry about no longer supporting Android versions pre-7.0, but changes required by the newest Android versions made this impossible.

I hope this helps.

Android Upgrade Fail

I really like SSHelper, and I've been using it for a while. I recently upgraded to Android 9 on my Samsung Galaxy S9+, and am having trouble with SSHelper.

I did the basic troubleshooting that you recommend on your site, to clear cache and data, uninstall, shut down the phone, then start and reinstall, but that didn't work.

I'm trying to SSH to the phone, but basic password auth to get things setup is not working.

[ snip log entries ]

I hope that's helpful, please let me know if there is some way to fix this, or if you need any additional info. This log entry --

2019-02-21 19:11:09 sshd: rexec of /data/data/com.arachnoid.sshelper/files/usr/bin/sshd failed: No such file or directory

— means the native-code SSH server program is not running because my program cannot find it. That in turn means the install failed or came into conflict with a older version whose data or binaries are still present. So do this:

Use the SSHelper menu item "Stop Server and Quit" to terminate the app, so the binaries can be purged.
Locate and select SSHelper under the Android Apps list, then press "Storage", to see something like this.
Select both "Clear Data" and "Clear Cache", and only then fully "Force Stop" and "Uninstall" SSHelper.
Turn off the Android device (not restart, but power down).
Turn it on again.
Reinstall SSHelper as a download from the Play Store, not a side load from any other source.

This is necessary because changes in both Android and SSHelper mean old data, and old program binaries, will cause problems during a reinstall.

Explanation: Most Android applications are just Java code with no native-code binaries. But my app is a mixture of Java and native-code binaries, and the technical requirements for those binaries have changed over the years. This means old binaries (and configuration files, and a directory tree) must be completely removed for a reinstall to succeed. This is particularly important when a new Android version is installed, a version with new technical requirements. The above procedure is required to be sure this happens.

Android 10/11 Issues

I have a Pixel 3a, and yesterday I started seeing "System update" (but actually an upgrade) notices for "Android 11: Better messaging & controls".

I am scared to download it because I really do not want SSHelper to stop working altogether. Do you have any information about whether SSHelper will continue to work in Android 11? I don't know, but I know I can get it to work with Android 10 as long as it's not compiled to the Android 10+ specifications (meaning as the current version (13.2) is now compiled). So not having an Android 11 device for testing, I can't say [readers: see below for an update].

But I do know that many other projects, including one of my all-time favorites (Termux), a first-rate project, is being abandoned for the same reasons. BTW, I have noticed since August when we corresponded, that Android seems to reset the SSHelper package back to its original state every time it starts up from a completely stopped state. In particular, these files (which I modify) are restored to their original contents:

[Deleted for brevity]

I don't exactly understand what causes that to happen. Specifically, what is causing those extra, user-created files in $HOME/../etc/ to be deleted? As I understand it, Android detects what it thinks are security compromises, and reloads the default content from the fixed-content APK file (the source file for the program). I do know that, going forward, all program content must refer to the APK's static content, not the device's storage, IOW the device storage can't contain anything that differs from the APK's original content. This is one of the reasons Termux is giving up — Termux relies on the user's ability to modify the package's contents after installation (as does my program).

But look at it this way. For the average Android user, a top priority is to be secure against hacking attempts, and requiring all program content to reside in the APK, nowhere else, is an obvious security improvement.

But it also means the Android environment can no longer be the playground that it was when Termux was written, and when my program was written. Thanks again for SSHelper! You are most welcome.

UPDATE: This correspondent later reported that SSHelper works with Android 11. So it appears my program has a reprieve for now.

Terminal Emulator Instructions

The SSHelper terminal (tab at the right) is a simple terminal emulator useful only for maintenance tasks — there are much better terminal emulators available, like Termux to name just one.

Unlike Termux, the SSHelper terminal emulator in entirely written in Java, consequently it has certain limitations when one tries to perform some operations with it, like logging onto a remote Secure Shell server from the Android device (the opposite case is easy and is the recommended approach).

To log onto a remote Secure Shell server from the SSHelper terminal emulator where a password entry is required, do it this way:

$ sshpass -p (password) ssh -tt user@server

The above gets around some technical limitations that arise when trying to run a shell session from the Java version provided with Android. Again, there are many better alternatives to this terminal emulator, and logging to the Android device is much better than logging from it.