SSHReach.me

Client script update: quieter logs, calmer reconnects

now

We've pushed a new version of the sshreach.me client scripts. If you're on the socket or websocket client you'll see 627 in your client list; the legacy Python 3 client moves to 415. Clients that support in-place upgrades will pick it up on their own, and everyone else will see the usual prompt.

Most of what's in this release is about how the client behaves when something upstream isn't quite right. None of it changes how tunnels work day to day.

Log files that stay a sensible size

The client keeps a log next to itself, sshreachme.log. Until now it rotated once a day and otherwise just kept going — which is fine when there isn't much to say, and less fine when the client has something to say very often. A client that can't reach us will tell you so, repeatedly, and on a machine that's been struggling for a long stretch that file could reach a size nobody wants to discover on their disk.

So, two changes.

Rotation is now by size rather than by date. The log starts a new file once it reaches a few megabytes and keeps a handful of older ones, so the total is bounded no matter what happens. Every line is timestamped anyway, so nothing is lost by not having one file per day — and on a quiet client you actually end up keeping rather more history than before.

The client also collapses repeated messages. If the same line would otherwise be written over and over, it's written once, and when something different finally happens you'll see how many times the previous message repeated alongside it. The interesting part of a log is usually the moment things changed, and that moment is now easy to find instead of being buried under thousands of identical lines.

If you have old dated log files lying around from the previous scheme, the new client won't tidy them up for you. They're safe to delete whenever you like.

Reconnecting at a more sensible pace

When the client loses its connection, it retries. That's the right instinct, but it was going about it with more enthusiasm than most situations call for — and in a few corner cases it could end up retrying in a way that was never going to get anywhere.

The reconnection path has been reworked so that each attempt starts from a genuinely fresh connection, and so that failures which clearly aren't going to clear in the next few seconds are given a little more room before the next try. Brief network blips are handled exactly as quickly as they always were. If your link drops for a moment, you won't notice any difference.

Certificates

The servers your clients connect to use certificates that are renewed periodically. Renewals are routine and normally invisible, but a recent one didn't go as smoothly as it should have, and some clients had trouble connecting for a while as a result.

We've made some changes to address that.

On the client side, the script now recognises a certificate problem for what it is. A certificate that isn't accepted isn't something a client can fix by trying again immediately, so rather than reconnecting at full speed it settles into a slower rhythm and waits it out. When the certificate is sorted, the client picks up again on its own — no restart, nobody logging into anything. That last part is the one worth upgrading for: a client on this version gets itself back without you knowing there was anything to get back from.

Getting the update

If your client supports automatic upgrades it'll update itself shortly. Otherwise, download the script again from your client list and replace the one you're running. Your keys and settings are unaffected either way.

We’ve added server-side connection breakup

9 months ago

We’ve just rolled out a small but important reliability update: server-side connection breakup.

When a user clicks Disconnect, the client normally tears down the tunnel. But on unstable networks, that message might never reach the server — leaving “ghost” sessions alive until timeout.

Now, if the client fails to close the link within a short window, our servers will step in and terminate the connection from their side.

How we fixed it

We updated our server architecture so that:

• When you send the “disconnect” command from your client, the server logs that intent immediately.

• If the client connection becomes unresponsive or cannot close cleanly within a short grace period, the server forcibly tears down the session from our end.

Why this matters

• No more lingering sessions. When you say disconnect, it actually disconnects — even over flaky Wi-Fi or mobile links.

• Cleaner resource handling. Stuck sessions are cleaned up immediately.

• User experience: You no longer need to double-check or manually intervene when the network hiccups. Press “stop”, and you’re stopped.

• Future-proofing: Networks will get more heterogeneous (5G, WiFi 6E, satellite, mobile roaming). Ensuring robust disconnect semantics is a step toward better reliability under all circumstances.

This enhancement is part of the ongoing work to tighten up the edge-cases — the ones only triggered when the network does funny things. We hope you’ll notice fewer “ghost” sessions, clean cut-offs when requested, and an overall smoother experience.

Thank you for using the service and for your feedback — it helps us fine-tune features like this for real-world conditions.

 

Warm regards,

The sshreach.me team

Even more efficient client script

1 year ago

One year ago we have introduced our websocket-based python script for our users with metered connection. Websocket-based script was using only around 4MB per day as opposed to our https based script that was consuming up to 100 MB per day. The drawback was that it needed at least python 3.6 or newer to run.

We have now completely rewritten our server and also alongside changed the python client so that our new python client (version 620 and above) uses less than 1 MB per day (around ~400 kb per day)! The new client script uses less than 4x data than the previous one and almost 200 times less than the https one. 

When downloading python script for your client you can now choose between 3 python scripts:

As with the previous client the question which script to use depends on your setup. If you only have python 2.7 on your system then the answer is the obvious - use the https/python2 script.

If you have python 3 or newer, you can choose between https and sockets script version. In that case please refer to the "Which client script should I use?" question on our faq page.

Two small UI enhancements and a better logging

1 year ago

UI changes

sshreach.me now offers two small UI changes:

1. you can now see for how long the tunnel has been switched on for

2. If you have more than 50 clients you can now choose how many clients are shown per page

 

Better logging:

New client script (version 612 and above) now offer better logging in cases when ssh can not open a tunnel. When that happens a red exclamation mark will appear next to the client name.

Clicking on the exclamation mark will take you to the log page for the chosen client where all reported ssh errors will be shown:

The access for the client's log page is also available from the "Info" tab on the client list page, by clicking on the icon in the "log" row.

Part of our service was down for 24h

2 years ago

Users of our websocket-based python script could not access their clients for around 24 hours - since Jul 4, around 20:00 hours until we renewed it more that 24 hours later. Through an unfortunate series of miscommunications among colleagues, one of our subdomains had an expired certificate and we didn't notice it until it was too late. That caused our websocket-based python script to fail to connect to our server and those clients were marked as offline until we renewed the certificate. The websocket-based service is now back online and we are doing the post-mortem analysis in order to prevent such failures in the future.

We apologize to our clients who were affected by the outage.

 

Optimizing Client Python Script for Efficient Data Usage

2 years ago

In today's digital age, internet usage is a critical consideration, especially for clients with limited bandwidth. We've taken a significant step towards optimizing data consumption by developing an enhanced version of our client Python script. This new version operates within a minimal data footprint of just 4MB per day, a great improvement over the previous version that consumed over 100MB daily.

When we launched this service, the fundamental idea was that a single client script could run anywhere, regardless of the operating system and Python version. However, the downside of this approach was the substantial amount of data being transferred. Unlike the older version, which relied on the HTTP protocol, our updated Python script leverages websockets to transmit and receive data more efficiently. This transition to websockets has drastically reduced the amount of data required for seamless communication, making it an ideal solution for clients with limited internet bandwidth.

Security remains a top priority in our development process. Despite the shift to websockets, the newer version of our Python script upholds the same robust security standards as its predecessor. We've ensured that Transport Layer Security (TLS) protocol is implemented, maintaining data integrity and confidentiality during transmission.

It's important to note that the minimum Python version required to run the new script is 3.6. However, we understand that some clients may still be using older versions of Python. To accommodate them, the previous version of the client script will continue to be accessible and functional. This ensures a smooth transition for clients who have yet to update their Python installations.

For clients equipped with newer Python versions and are on a metered connection, we highly recommend using the new version of our Python script.

 

introducing new API call: delete_client

3 years ago

Dear clients,

with the introduction of new delete_client API call you can now delete your client using only your automation scripts, with no need to use our web dashboard. For details on how to use the delete_client API call please consult our documentation.

Enhanced Security: Introducing Personalized Public/Private Key Pairs

3 years ago

Introducing Annual Subscription Plans for Our Indian Customers

3 years ago

Hello to our valued Indian customers!

We have an important update regarding our payment options that we would like to share with you.

Due to recent changes in recurring payments regulated by RBI India, our Indian customers can no longer pay their monthly recurring bills. 

As much as we believe in providing flexibility and convenience through our monthly plans, to address the regulatory changes and maintain a seamless billing experience, we are delighted to introduce our new annual subscription plans. These plans allow you to subscribe and make a single payment for a year's worth of service, ensuring uninterrupted access to all the features and benefits or our service.

How to Transition to an Annual Subscription: Transitioning to an annual subscription is simple. At the end our your monthly billing period just cancel your monthly subscription, start a new annual one  and make a single payment for the entire year. Once completed, you will have uninterrupted access to our services for the duration of your subscription.

Best regards,

the sshreach.me team

Enhanced Connectivity: Introducing Dropbear SSH Support

3 years ago

Hello, valued clients!

We have upgraded our service to now support Dropbear SSH clients, enabling enhanced connectivity, especially for small and embedded platforms.

Dropbear SSH is a lightweight and efficient open-source software designed for resource-constrained devices. With this enhancement, you can establish secure SSH connections to our service, optimizing performance and resource usage.

Key Benefits:

1. Efficiency: Dropbear SSH clients are compact and have a low memory footprint, perfect for devices with limited resources.
2. Fast Performance: Enjoy quick and responsive SSH connections, even on devices with limited processing power or bandwidth.
3. Robust Security: Dropbear SSH employs strong encryption algorithms and secure protocols to ensure the safety of your data.

Getting Started: Update your client scripts to include Dropbear SSH support. Detailed instructions can be found in our documentation or in the comments section in our client script.

Sincerely,

the sshreach.me team

Older entries...