Das Werkstatt

[THE TASK]
Remote-Control software for PCs where you can almost handle the computer as if you were in front of it is a very brilliant thing - especially if you are supposed to help people who you could hardly visit in person.


[THE PROBLEMS]
1) But nowadays, almost everyone's behind any kind of firewall or NAT-router, thus making it very difficult to access a certain (or multiple) machines from the outside.

2) In the real world, most of the people behind Firewalls do not know how to configure them, making it an even bigger obstacle to connect from outside.

3) One could use a VPN-connection (pptp, ipsec, ...), but according to my practical experience, this is not as good as it sounds:
a) Merging networks merges ALL protocols - Have fun when connecting to a virus-infected network (:D )
b) Setting up the infrastructure is not very funny.
c) Most VPN types have their own protocols:
pptp -> GRE
ipsec -> protocol 50 and 51
which sometimes cannot be routed easily through Firewalls at all.

[THE IDEA]
Most firewalls allow traffic from inside out, which led me to the idea of establishing some kind of "call / recall" system:

1) The client should connect from inside out, thus probably passing a very high percentage of firewalls.
2) The connection should be using a standard protocol, like TCP (to avoid routing problems, and firewall incompatibilites)
3) ...and should only use 1 static port.
4) but still - the content should be secured.


(...I should get a software-patent on this one, shouldn't I ? (:twisted:))

[SOLUTION - OVERVIEW]

1) SSH2 can provide port-tunnels, not just mapping server-ports to the clientside (local), but also the other way round (remote) and this is what I'm going to use.

2) By using key-based authentication, I can use a single user on my SSH-server for connecting clients, and manage the security almost 100% on my side. By deleting allowed-keys from the keyfile, old users will lose the ability to connect at all.

3) RemoteControl server and SSH2-client (including the right config) can be packed within an Installer, thus making the client-setup as fool-proof as possible.

4) A logon-script on my server side, logs all successful connects, including information about the used key, so I can easily identify who is connected and which port on my server is the client mapped to.

5) After the client side has executed the installer, there can be a script (e.g. batch file) which starts the remotecontrol server and establishes the tunnel.

6) Some modifications can be done in order to increase the possibility of piercing a whole in the firewall:
- Set your sshd to be available on "allowed" ports: 80, 21, ...
- Wrap SSH within HTTP (for protocol-sensitive FWs)
- SSH over http-proxy.
(see: Breaking Firewalls)

[GOOD]
+ Since there's no network-merging done, there's no real danger of a virus infecting my systems.

+ SSH takes care of the traffic being encrypted.

+ The SSH-server is on my (the helper's) side, so there's just client stuff on the "to-be-helped" side.

+ The client-side is pretty platform independent, since SSH-clients exist for (I presume) every major OS currently used.

+ The SSH-server can be configured to restrict the connecting user, thus preventing it from executing commands, allocating a PTY, mapping local ports, etc...


[NOT SO GOOD]
- The remote-connection cannot be started from outside (which could be desirable in some support-cases).

[PROBLEM]
There seems to be a strange bug with PuTTY & Tunneling when the application window is NOT minimized:

The remote side can be viewed, but it's like "read only" - After minimizing the putty window, everything's fine.
The downside is that a lot of people get scared when they see application in their taskbar that has "strange, gray characters on evil black background" - so they close it.


[SOLUTION]
Send putty to the system tray! but how? A lot of people had the same requirement: "PuTTY wish system-tray", and my absolutely favorite tool for that is: Trayconizer

You can simply start the tunnel like this:
"trayconizer putty.exe -load myProfile"

Here are the important settings to be tweaked and/or modified in your sshd_config:

AllowTcpForwarding yes: This enables TCP port forwarding in the first place.
GatewayPorts yes: This allows other computers to connect through the computers connected by SSH. Very handy for "jumping" to computers behind the entry point.
PermitUserEnvironment yes: Necessary for distinguishing between users later on.
Protocol 2: This avoids silent fallbacks to SSH v1 and thus avoids some security risks. Might limit the number of clients able to connect, but that should not be an issue nowadays anymore.
PermitRootLogin no: Prevent anyone from "trying" to gain root access by SSH.

These 2 settings affect the stability of tunnels that are open for a long time over a not so reliable connection:
ClientAliveInterval 5
ClientAliveCountMax 3

In order to simplify administration, I've used a single user for all clients, and called it "portier" (a word used in German for the guy watching the door of a hotel or bureau buildings). This has the following benefits:
*) Only one system user to administer.
*) No password, so no one can brute-force it, and...
*) ... because you only use public/private keys, you can disable client accounts on the server side, which is great if someone has lost their key, or you simply don't want them to connect anymore.

That user should have no rights on the system, except being allowed to connect per SSH. It doesn't even require (or should have) a shell set in /etc/passwdHere's an example: Additionally, you should disable its password by putting an "x" instead of its password hash in /etc/shadow: Since all clients are using the same system user, you have to add their public keys to its ~/.ssh/authorized_keys file.
The first and important entry should be for a so called "connection test" key, which is used directly in the installer:
So, for each user you need to add such a line with their public key - and the same settings as the one above. You need to change the value for "SSH_KEY" - The easiest way is to simply use the comment string from the SSH key as identification string.

Here's an example of another user: Here is a detailed explanation of these settings:

command="/home/portier/logon": Execute that script on logon of the portier user. This prevents users from being able to execute commands per SSH - and it is also used to log connections to a customized logfile, and provide the user feedback upon a successful connection.

environment="SSH_KEY=ConnTest"
Stores a string in the environment variable "SSH_KEY". I'm using this to identify which key is currently connected. Very useful for later processing in the logon script.

permitopen="0.0.0.255:65535"
This prevents the client to request ports on our side to be mapped, since that would pose a real ugly security threat.

no-pty
This simply tells SSH to *not* give the user a shell at all. Possibly saving us further trouble.