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?
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.
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).
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.
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.)
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.
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.
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".
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.
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.
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?
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).
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).
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.
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.
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.
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.
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.
62 comments
[ 3.1 ms ] story [ 131 ms ] threadSo 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.
> 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?
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.
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.)
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.
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".
Nah, nice try, but I'm good with ssh, key based authentication and few white-listed IPs.
Anything more sophisticated will inspect the traffic and drop SSH connections no matter the port.
I guess if that work depends on how the proxy is set up.
If not, then this seems like an exfiltration risk your security people should fix.
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?
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).
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.
Desktop permissions are based on protecting a user’s data from other users, not from anything that they themselves are running.
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.
I'm old.