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

[mad182]

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

[mr_toad]

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

[dirkc]

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

[taneq]

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.

[ARandomerDude]

What could go wrong?

[marcelnita]

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

[edf13]

My thoughts exactly...

[Hamuko]

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

[vsviridov]

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

[ttobias]

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.

[nirui]

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.

[atopuzov]

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

[hyperpallium]

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.

[Deukhoofd]

Why not just use SSH?

[frankzander]

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.

[Hamuko]

Perhaps it has one S too many.

[atopuzov]

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

[dTal]

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.

[archgoon]

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

[mkj]

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

[nirui]

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

[dikei]

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.

[contravariant]

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.

[znpy]

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.

[frozenwind]

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.

[perakojotgenije]

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

[cerberusss]

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

[amanzi]

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.

[billpg]

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.

[mapleboi]

looooks fishy

[crucoba]

Worst idea ever.

[eeZah7Ux]

Just use an onion service.