beady
Inactive User
There's been a lot of interest recently, especially in the dreambox/dbox forums about accessing your home network remotely. The general answer is to just 'forward ports' through your router. However, this can be dangerous. Despite the best advice, it's human nature to choose poor passwords, not to mention the dangers of transferring data unencrypted over the internet. For instance, password for the dreambox web interface is sent in plaintext. Easy to intercept on an untrusted network. I'm going to show you a quick(ish) way to connect securely to your home network from anywhere in the world. The method uses 'SSH tunnels' to secure communications, and is easier to use than a true VPN. If you just want to be able to set up recordings remotely every now and again, VPN is overkill, and this method works great.
So what will you need? Firstly, a usb stick to store the files you use remotely (the ssh client and private key), and secondly you need to set up and SSH server within your home network. I'll concentrate on using 'dropbear' for the server, which is installed on most third party router firmware (such as OpenWRT, Tomato and DD-WRT). Using a router for the server is the easiest way to get this going, since it's always on and connected. If you want to use a PC within your network for the server that's fine. You just have to remember to forward port 22, the SSH port (or another you choose) through to the actual server. For Linux, you've probably already got sshd installed, and for windows, I'd recommend using either Cygwin(for a full featured unix like environment), or OpenSSH for Windows if you just want the standalone server. There's a howto for setting up sshd on Cygwin here.From now on, I'll assume you've got a working ssh server somewhere on your network, and that it's accessible from the internet on port 22. If you've changed the default port for security, add a '-p <port number> option to the following ssh commands.
In the zip file attached to this post I've included all the files you need to put on the usb stick. These are ssh.exe (the client for connecting), ssh-keygen.exe (for generating your public/private key pair), a few dll files required by the executables, and a couple of licenses for legal reasons.
Okay, on to setup. Extract the zip file into a folder (maybe named 'ssh-stuff') on your usb stick then open up a command window and type:
As you can probably guess, the above assumes your usb drive gets assigned as f:, change the above if needed. So what the above does is change into the directory containing the program files and then run 'ssh-keygen'. This generates our public/private 'key pair', which is used for securely authenticating with the remote server. When it asks you to enter a password, just press enter. You don't need one (trust me on this, or google around to find out what this password actually would be for. For our purposes it's not needed). The generated keys are called 'rsakey' (the private key which you must keep secret), and rsakey.pub (public key which we transfer onto the server).
The next step is to copy the 'rsakey.pub' file to the ssh server. For dropbear (on OpenWRT), we need to put the file into the '/etc/dropbear/' directory, and it must be renamed 'authorized_keys'. For Tomato you can do it from the web interface (see here, the Authorized keys bit) by copying the contents of rsakey.pub into the interface. Other servers will be different. I imagine DD-WRT will accept the rsakey.pub file in /etc/dropbear/, renamed to 'authorized_keys' (it is dropbear after all), but I don't use it so I cant test. If you use a proper linux machine, put the rsakey.pub file into the /root/.ssh directory, this time renamed to 'authorized_keys2'. Finally, if you're using Cygwin, put the rsakey.pub file into /home/<username>/.ssh/ directory, named 'authorized_keys2'. That should cover most servers you'll use.
Right, let's see if it works. I assume you've still got the command prompt open in the usb folder. Type:
Assuming everything worked, you should be at a command prompt, without having to enter a password. 
The next thing to do is a bit of tunneling. But first an explanation. I'll use the example of a http connection. When you request a web page, your browser connects to the target web server on a specified port. For http (i.e. browser) traffic, this is usually port number 80. If you can get to the ip address of the target, then all is fine and dandy. However, in a home network, it's almost certain you've got a local subnet set up (probably 192.168.x.x or 10.x.x.x). You can't access this network directly from an arbitrary ip address. This is where your router comes in. Your router will 'forward' requests to a port on the external (i.e. modem) address to a specified internal address. This is what the 'port forwarding' section of your router setup does. What we want to do is a little different. Tunneling a connection through ssh means that we define 'entry' and 'exit' ports on the local and remote systems. If we connect to our defined 'local' port, the connection gets encrypted and sent through an already set up ssh 'tunnel' (i.e. connection) until it reaches the remote system, where it's decrypted and sent on to the defined exit ip and port.
Well that's one of the worst explanations I've seen for SSH tunneling, but there's plenty on the web if you want to know more.
Anyway, back to specifics. In order to set up a tunnel, we can use the '-L' option in ssh.exe. The general syntax is:
'local' and 'remote' are in relation to where we want to connect from. Say your at work and want to connect to your home network. 'local' is our work machine, while 'remote' is our home network (confusing I know, since we're accessing the home network 'remotely'). So the 'localport' is an arbritrary port we will connect our browser to on the work machine, 'remote_name' is the target of the tunnel, from the point of view of the ssh server (don't forget that while at work, you can't directly see your internal network, but the ssh server can), and remote_port is the target port. 'username' is the username on the ssh server (probably root if you're using a router as a server), and 'ssh_server_name' or 'ip_address' is the EXTERNAL ip address of your router at home. Maybe an example will help. This is how I can connect to my home network from work:
Once I've run that, whenever I connect to port 65532 on my work pc, it gets forwarded through the established ssh connection right to my dreambox. So I can access the web interface of the dreambox by putting http://localhost:65532 into the browser address bar. Everything is secure. Note, I will still be asked for the password for the dreambox, but this time it's secured by military grade encryption.
What about multiple ports or devices. Lets say you've got 2 dreamboxes and want to be able to get at both. With standard port forwarding that would be awkward, since they both want port 80. With an ssh tunnel it's easy. Just add another '-L' section to the command line, so the following would work well:
If I want to get to dreambox one's web interface, I use http://localhost:65532 , and I use http://localhost:65533 if I want dreambox two. Easy.
It's easy to put the above commands in a batch file for ease of use. Lets say you want to have telnet, ftp and web access to your dreambox from work. Make a batch file called 'sshforward.bat' in your ssh folder on the usb stick, and fill it with:
Now I can just (at work) double click the .bat file, it starts up the tunnel, and I can do
and I'm at the dreambox log in prompt. Brilliant. Point an ftp client at localhost, and you get the dreambox login. As far as anyone scanning my home network is concerned, I've only got one port open, the ssh port. And there'd also have to be VERY strict access rules at work for this not to get through. An important point to note is that tunneling 'privileged' ports (less than 1024) requires Admin privileges on the local machine. So if you're a normal user, you'd have to have 'localport' above 1024. This isn't a problem, all telnet clients and almost all ftp clients will let you specify a port to connect to. If I was a normal user, I'd have to change the above to (e.g.):
then
works fine.
Now we've seen how great this is, there are some caveats. Firstly, you can only forward TCP traffic, not UDP (well technically you can encapsulate the UDP into TCP using something like 'socat' and then unpack it at the end, but it's awkward and I never got it to work well). This means that forwarding things like windows shared folders (SMB and NMB protocols) isn't as easy as above, and is generally not recommended.
The second point to note is that DNS resolution probably won't work as you expect. If you've got multiple web pages on a home server, referenced absolutely, then problems will occur. Say you've got page_1.html that contains a link to page_2.html, but it's defined by something like http://192.168.1.45/page_2.html. Your local browser will try to resolve the 192.168 bit and fail. This won't be a problem for dreambox web interfaces, but I've seen it in the past. SSH tunneling is certainly NOT a drop in replacement for a true VPN. Finally, certain protocols and applications will try to open ports 'on the fly'. So you connect on the standard port, which you've tunneled through ssh, but the program then tells the client to open up a new connection on a different port. This will succeed or fail depending on firewall rules and network topology, but most of all it will DEFINITELY NOT be encrypted. A classic example I've seen a lot is X11 to a local display on unix. Without the -X option to ssh, you may still get applications to appear to start correctly, but the X11 traffic is passing unencrypted. Probably not something most of you will be bothered about, but I thought I'd mention it.
I think I've been writing for long enough now. I hope you give this a try, since I for one find it a bit worrying that so many people are putting devices on the internet without properly understanding how to protect themselves from naughty people.
Good luck and post back with questions and problems.
Cheers
Beady
So what will you need? Firstly, a usb stick to store the files you use remotely (the ssh client and private key), and secondly you need to set up and SSH server within your home network. I'll concentrate on using 'dropbear' for the server, which is installed on most third party router firmware (such as OpenWRT, Tomato and DD-WRT). Using a router for the server is the easiest way to get this going, since it's always on and connected. If you want to use a PC within your network for the server that's fine. You just have to remember to forward port 22, the SSH port (or another you choose) through to the actual server. For Linux, you've probably already got sshd installed, and for windows, I'd recommend using either Cygwin(for a full featured unix like environment), or OpenSSH for Windows if you just want the standalone server. There's a howto for setting up sshd on Cygwin here.From now on, I'll assume you've got a working ssh server somewhere on your network, and that it's accessible from the internet on port 22. If you've changed the default port for security, add a '-p <port number> option to the following ssh commands.
In the zip file attached to this post I've included all the files you need to put on the usb stick. These are ssh.exe (the client for connecting), ssh-keygen.exe (for generating your public/private key pair), a few dll files required by the executables, and a couple of licenses for legal reasons.
Okay, on to setup. Extract the zip file into a folder (maybe named 'ssh-stuff') on your usb stick then open up a command window and type:
Code:
You don't have permission to view the code content. Log in or register now.The next step is to copy the 'rsakey.pub' file to the ssh server. For dropbear (on OpenWRT), we need to put the file into the '/etc/dropbear/' directory, and it must be renamed 'authorized_keys'. For Tomato you can do it from the web interface (see here, the Authorized keys bit) by copying the contents of rsakey.pub into the interface. Other servers will be different. I imagine DD-WRT will accept the rsakey.pub file in /etc/dropbear/, renamed to 'authorized_keys' (it is dropbear after all), but I don't use it so I cant test. If you use a proper linux machine, put the rsakey.pub file into the /root/.ssh directory, this time renamed to 'authorized_keys2'. Finally, if you're using Cygwin, put the rsakey.pub file into /home/<username>/.ssh/ directory, named 'authorized_keys2'. That should cover most servers you'll use.
Right, let's see if it works. I assume you've still got the command prompt open in the usb folder. Type:
Code:
You don't have permission to view the code content. Log in or register now.The next thing to do is a bit of tunneling. But first an explanation. I'll use the example of a http connection. When you request a web page, your browser connects to the target web server on a specified port. For http (i.e. browser) traffic, this is usually port number 80. If you can get to the ip address of the target, then all is fine and dandy. However, in a home network, it's almost certain you've got a local subnet set up (probably 192.168.x.x or 10.x.x.x). You can't access this network directly from an arbitrary ip address. This is where your router comes in. Your router will 'forward' requests to a port on the external (i.e. modem) address to a specified internal address. This is what the 'port forwarding' section of your router setup does. What we want to do is a little different. Tunneling a connection through ssh means that we define 'entry' and 'exit' ports on the local and remote systems. If we connect to our defined 'local' port, the connection gets encrypted and sent through an already set up ssh 'tunnel' (i.e. connection) until it reaches the remote system, where it's decrypted and sent on to the defined exit ip and port.
Well that's one of the worst explanations I've seen for SSH tunneling, but there's plenty on the web if you want to know more.
Anyway, back to specifics. In order to set up a tunnel, we can use the '-L' option in ssh.exe. The general syntax is:
Code:
You don't have permission to view the code content. Log in or register now.
Code:
You don't have permission to view the code content. Log in or register now.What about multiple ports or devices. Lets say you've got 2 dreamboxes and want to be able to get at both. With standard port forwarding that would be awkward, since they both want port 80. With an ssh tunnel it's easy. Just add another '-L' section to the command line, so the following would work well:
Code:
You don't have permission to view the code content. Log in or register now.It's easy to put the above commands in a batch file for ease of use. Lets say you want to have telnet, ftp and web access to your dreambox from work. Make a batch file called 'sshforward.bat' in your ssh folder on the usb stick, and fill it with:
Code:
You don't have permission to view the code content. Log in or register now.
Code:
You don't have permission to view the code content. Log in or register now.
Code:
You don't have permission to view the code content. Log in or register now.
Code:
You don't have permission to view the code content. Log in or register now.Now we've seen how great this is, there are some caveats. Firstly, you can only forward TCP traffic, not UDP (well technically you can encapsulate the UDP into TCP using something like 'socat' and then unpack it at the end, but it's awkward and I never got it to work well). This means that forwarding things like windows shared folders (SMB and NMB protocols) isn't as easy as above, and is generally not recommended.
The second point to note is that DNS resolution probably won't work as you expect. If you've got multiple web pages on a home server, referenced absolutely, then problems will occur. Say you've got page_1.html that contains a link to page_2.html, but it's defined by something like http://192.168.1.45/page_2.html. Your local browser will try to resolve the 192.168 bit and fail. This won't be a problem for dreambox web interfaces, but I've seen it in the past. SSH tunneling is certainly NOT a drop in replacement for a true VPN. Finally, certain protocols and applications will try to open ports 'on the fly'. So you connect on the standard port, which you've tunneled through ssh, but the program then tells the client to open up a new connection on a different port. This will succeed or fail depending on firewall rules and network topology, but most of all it will DEFINITELY NOT be encrypted. A classic example I've seen a lot is X11 to a local display on unix. Without the -X option to ssh, you may still get applications to appear to start correctly, but the X11 traffic is passing unencrypted. Probably not something most of you will be bothered about, but I thought I'd mention it.
I think I've been writing for long enough now. I hope you give this a try, since I for one find it a bit worrying that so many people are putting devices on the internet without properly understanding how to protect themselves from naughty people.
Good luck and post back with questions and problems.
Cheers
Beady
