Rtty – Access a device’s terminal from anywhere via the web | Hacker News Reader

Rtty – Access a device’s terminal from anywhere via the web

github.com

80 pointszhaojh32958 comments

> Access your device's terminal from anywhere via the web

Nah, nice try, but I'm good with ssh, key based authentication and few white-listed IPs.

It’d be nice if you could just outbound ssh from anywhere that has a browser, but sadly this isn’t the case.

What do you mean by that?

As an an example, at my work you cannot make any outbound ssh connection. The only way to get one is to apply for a specific connection , where you have to explain why you need an outbound connection, in which case they open a port for you and the remote machine you specified.

Using tools like this to get around that restriction is quite possibly the worst idea I've seen today.

corkscrew?

if it's just filtering of certain ports, you can just set your ssh port to 80 or 443

Yep, using 443 as your SSH port seems a good way of doing this. I do.

In its simplest form, yes.

Anything more sophisticated will inspect the traffic and drop SSH connections no matter the port.

At my last job we used corkscrew (https://github.com/bryanpkc/corkscrew) to tunnel ssh through HTTP proxies without needing the ssh server to use another port.

I guess if that work depends on how the proxy is set up.

I suggest learning how those filters work. Also please do respect the policies, they're usually there to protect the intellectual property and you might be unwittingly putting yourself in spotlight despite having no bad intentions.

Oh yeah I wasn't going to try and circumvent, just giving an example to elucidate

Wouldn't you have to apply for permission for the article's solution for the exact same reason?

If not, then this seems like an exfiltration risk your security people should fix.

What happens when you log into a VPN and then SSH elsewhere; that should work, right?

Corporate MITM devices, like those from Forcepoint. Or domain managed client side content filtering / endpoint protection. Basically overzealous IT security stuff. Most won't be fooled by simple stuff like just running sshd on port 443.

Edit: Though these MITM vendors will soon have fun with DNS over https and encrypted SNI. Guess they will have to resort to being browser plugins?

With the help of an additional “proxy”, you can. One such proxy software is Apache Guacamole. It doesn’t only do remote desktop, it also does SSH.

It can also be subject to MITM. If you don't control the certificate store on your device then you don't control the connection to Guacamole (or anywhere else via HTTPS).

Basically any attacker that is able to control the certificate store on your device could also just install a keylogger.

You would have to really trust whatever service is providing this ssh client. For a browser based ssh client either it's code running on your local computer (in which case, just download an ssh client) or your ssh connection is coming from some third party server that you may or may not trust.

This is something I've thought about time and again, but the security issues always seem to outweigh any potential benefit from something like the OP or similar (in my opinion).

As much as I get, "make it simple for users" and "you can always read the script being downloaded", seeing a wget piped to sudo makes me think nothing in this world will ever be secure :(

Even if it’s not piped to sudo, how many people have their personal files and documents (ie. the stuff that can’t just be re-downloaded) owned by a user other than the one they log in as?

Desktop permissions are based on protecting a user’s data from other users, not from anything that they themselves are running.

What could go wrong?

My thoughts exactly...

Haven't checked the code. Any obvious security flaws? Or is it the fact that it's not peer tested and proven?

I'm more concerned about non-obvious security flaws.

The intended use of this is "maintaining" internet of things devices.

So it's not really meant to be a secure system, think of it as a botnet CnC and this makes a lot more sense.

It's why the system is supposed to be run on OpenWRT (which most cheap IOT things are based on), it why there's not hostnames, it's why it supports hundreds or thousands of devices.

> The intended use of this is "maintaining" internet of things devices.

> So it's not really meant to be a secure system, think of it as a botnet CnC and this makes a lot more sense.

Is there anything to back this up? While the mtls initialization looks less than ideal and there's downright stupid stuff in the README like credentials in URI parameters, this doesn't look any different than the other web terminal gateways we've seen on HN over the last few weeks.

> which most cheap IOT things are based on

Most cheap IoT devices I'm aware of aren't remotely capable of running OpenWRT, do you happen to have examples for this?

Yeah, I wouldn't install this on any machine that I own or use.

I use Butterfly (https://github.com/paradoxxxzero/butterfly) with ssl client certificates for auth.

I‘m using ttyd (https://github.com/tsl0922/ttyd) behind an nginx reverse proxy with client certificates. This gives me access from locations where ports other than https are blocked.

Great tool, IMHO best web terminal app (it uses xterm.js).

This kind of tools is basically always less safe than straight SSH. This one specifically, by-passed the authenticator of your OS.

Yes, you can run `login` instead of a shell, but doing so require the tool to be executed as root, still sound bad.

I'd recommend to use a proxy that supports converting socket to Websocket(wss) and back, then you can by-pass the blockage from there. And since it's a proxy, it should not decrypt the SSH traffic.

That is an interesting idea do you know of any tool that can do the websocket to socket translation in combination with an xterm.js webpage?

Not with a webpage. But there are many two-part proxies supports Websocket or even HTTP as their back-end transport protocol.

The idea is basically:

Your SSH client <---SSH-Traffic---> Proxy front-end <----Websocket----> Proxy back-end <---SSH-Traffic---> Target SSH server

You can deploy the "Proxy front-end" inside the restricted network, and the "Proxy back-end" out side the network. After that, all you need to do it to config your SSH client to go through that proxy front-end.

There are many proxy software is capable of doing that, the GitHub keyword I believe is "socks5 websocket".

I used wetty for this: node server, but like this uses xterm.js client https://github.com/butlerx/wetty

Though only locally, not connected to the internet. Maybe I'm paranoid, since I use so much other software without auditing, but somehow I feel especially vulnerable to web terminals, aside from anyone being able to login, and public keys not being convenient on the web.

Also, the readme.md for rtty here suggests running as root.

Why not just use SSH?

because it's not hip anymore. This is for the beardy old unix guys who don't understand the whole new world in the clouds.

Perhaps it has one S too many.

Because SSH might be blocked, and not only trough port 22 blocking but firewalls sniffing traffic and blocking on OpenSSH in the connection (eg. SSH-2.0-OpenSSH_8.1).

Then this stuff would also be blocked for the exact same reason. And if it isn't, you will probably be fired for knowingly and willfully circumventing security measures.

I have gotten around this by hosting SSHD on web ports before, or going through a SOCKS proxy.

You might be on a hostile, locked down client, on a hostile network. This lets you access a *nix machine you control from no more than an internet kiosk at a hotel.

I definitely would not want to use a hostile machine to access my servers remotely, period. Sure, this will let you bypass outbound port restrictions, but it doesn't help in the slightest if every keystroke is keylogged.

Keystrokes being logged could be avoided with 2FA plus not typing in sensitive content.

That doesn't secure you against MITM from the machines. E.g. if the machine is taken over locally or remotely or there's spyware running on it, you could still end up compromised.

(I'm not saying you should do this; you probably shouldn't.)

Odd that the client is written in C, but the server in go. I'm curious as to why the author chose to do that (along with the artisan buffer implementation).

Go easily compiles to a distributable static binary, no fiddling with musl toolchains.

Probably because with C, you can control your resource better, which is important if your application is going to support low end router etc.

This might be useful as a backdoor around networks with strict rules that block SSH access, until the network admins detect and block this as well. People got fired for installing tools like this, think twice before trying with your company's servers.

Don't install remote access tools on company servers!

Anyway you could just as easily run SSH over another port, rather than using this. Unless your company is using deep packet inspection to recognise SSH traffic, but then it'd be weird to accept HTTPS traffic from a device that isn't supposed to have any.

I'm using a patched version of wetty (https://github.com/esantoro/wetty), a web-based ssh terminal.

The patches add the possibility of specifying a different target host, whereas the original wetty only allowed connecting to the host currently executing wetty.

I run it in a container, I've skimmed the source code and it disarmingly simple: it performs a forkpty call to spawn the ssh client binary and then the connection goes on as the forked process is forwarded raw characters.

Under the security POV is kinda okay as everything is tunneled via TLS and the endpoint is (at least in my installation) not advertised very much. I check the server access logs from time to time and I don't see any activity besides my accesses.

In general a web based terminal is very handy, I wouldn't dismiss such a technology so quickly and superficially.

This thread is interesting, I'll be looking for other suggestions in the comments. I'm currently using the free option of remote.it to connect to a raspberry pi behind a router, though I always have to go through the step of obtaining the connection url and random port before using something like putty.

Remote.it looks pretty interesting. They have a desktop app for macOS in beta, as well.

https://sshreach.me (disclaimer: I am the author)

I use Guacamole to achieve the same results. The Guacamole service runs on Docker on my home 'server' with Nginx in front of it giving me SSH access through the web browser to my home machines and any other SSH services that I configure.

I read the headline and imagined that someone had built a device you can leave plugged into a serial port and access remotely.

I'm old.

looooks fishy

Worst idea ever.

Just use an onion service.

Reply on news.ycombinator.com