51–60 of 63 posts
Why not just use SSH?
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.
> 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.
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).
Earlier quoted context omitted.
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.
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.)
Earlier quoted context omitted.
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).
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…
Earlier quoted context omitted.
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…
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?
The idea is basically:
Your SSH client Proxy front-end Proxy back-end 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".