Title: Configuring the personal remote access to firewalled hosts ==Introduction== Remote access can be useful when you have urgent work questions while physically not at work, when you forgot to commit or fix something after work. While you usually can use mail, report work time and do may things using that corporate services remotely, usually it is more comfortable when you have access to your configured working environment. Essentially you can do the same work without being physically at workplace (see "Limitations" sections for details). Typical corporate networking setup includes NAT - technology that prevents direct connections to your hosts (but not from your hosts). This requires us to set up additional software to workaround it. Note that is poses some security risk (see "Security" section), so should be done with care. ==Technology== Remote access consists ot two parts: Remote access server and NAT traversal. Remote access server manages security and connections, NAT traversal allows you to access the remote access server from outside the corporate network. ===Remote access server=== I suggest to use OpenSSH server for it. It is usually out-of-the-box or easily installable in GNU/Linux machines and also can be installed on Microsoft windows computers. OpenSSH server provides encrypted session. You can use command line, forward other connections, transfer files. You probably want to configure the following options in it: AllowTcpForwarding yes AllowUsers some_user You can forward connection to RDP (on Windows) or x11vnc (on GNU/Linux) in order to access interactive session. ===NAT traversal=== By just configuring the remote access server you provide yourself access only from other hosts in the corporate network. In order to extend it to the Internet you must traverse NAT. There are many ways to do it. We'll consider two of them: 1. Using a third relay server with white IP. 2. Using IPv6 over Teredo If you have access to some server on the Internet, you can configure your host to login to it and reverse-forward the port onto you SSH: +--------------------------------------+ +------------------------+ | Your | | Public | | host | | server | | | | reverse | +----------------------+ this connection+-----------+ forwarded | | SSH client |=================>|SSH server |== port | +-----------------/----+ contains other +-----------+ | | / | connections :22 :2222| | +------------+ /from reverse | inside | | | OpenSSH :22 <- forwarded | | | | +------------+ port | | | +--------------------------------------+ +------------------------+ You host logs in to other server (as client) over SSH and reversely forwards a port from public server to your OpenSSH server. As you probably want it to work non-iteractively, as a service, you should set up public key authentication ($HOME/.ssh/authorized_keys $HOME/.ssh/id_dsa.pub). So you can connect from public server to your remote access server when reverse forwarding is up (i.e. when your host is logged in to public server). You connect to a port in public server which is forwarded to OpenSSH on your host. The example command (to be run on host) to set up such forwarding is: ssh -R 127.0.0.1:2222:127.0.0.1:22 user@somehost.com -N To connect your host you should use (on your remote machine): 1. ssh -L 127.0.0.1:2222:127.0.0.1:2222 user@somehost # log in to public server 2. ssh some_user@127.0.0.1 -p 2222 # use forwarded connection to log in to host You should add more options (for example, "-D 127.0.0.1:1080") to the second command line to make the fuller use of your host. With "-D 127.0.0.1:1080" you can, for example, use 127.0.0.1:1080 as SOCKS5 server to browse network on behalf of your host remotely. The host-to-public-server connection is the weakest link in this chain. It can stall and you can't easily restart it having no access to the host. So you can use more advaced auto-restartable SSH session with a watchdog: for((;;)) { ssh user@somehost.com "killall sshd" # Stalled sshd can hog the "2226" port. sleep 3; ssh -R 127.0.0.1:2226:127.0.0.1:22 user@somehost.com " for((;;)) { echo watchdog; sleep 30; }" | perl -pe ' INIT{ $q=10; $SIG{ALRM} = sub { --$q; system("echo BANG; killall ssh") if $q <= 0; print "$q\n"; alarm 10; }; alarm 10; } $q=10;' sleep 30; # prevent flooding with connections in case of no access to server } In Windows it may be not that easy (although possible) to set up SSH client that will auto-start with the system and work unattended. So special Java connect-back program was development to ease it: http://vi-server.org/pub/javaconnectback.zip You can install it as Windows or Linux service. You need to configure user name, port numbers and other things in "wrapper.conf" and place your key in id_dsa file (don't use the supplied one!). If you don't have access to the server in the internet, you can use other relays. Primary example is Teredo IPv6 relays. All you need is just to bring your host into IPv6 world. Example instructions for GNU/Linux: on host: 1. Install miredo. 2. Start it /etc/init.d/miredo start 3. Save your IPv6 somewhere. Example: 2001:0:53aa:64c:2cc2:7587:a9c6:61b1 on remote computer: 4. Install and start miredo (if don't have normal IPv6 networking) 5. Connect to your host's remote access server: ssh some_user@2001:0:53aa:64c:2cc2:7587:a9c6:61b1 -D 127.0.0.1:1080 It is not guranteed to work hovewer. There are other relays to use. Basically if you can exchange information with enought bandwidth and latency you can login and access network. You can even masquerade your connection as a bunch of DNS requests. Tor or I2P provides other relatively easy ways of accessing your host. ==Security== Providing additional access channels is a security challenge (obvously). So you should ensure that only you can use this channel. Here is list of rules I usually follow: 1. Configure your access server properly: a. Use strong password or use pubkeys. In latter case you can disable the password login. b. Know which users can connect or specify "AllowUsers" explicitly. 2. Ensure security of your remote computer: a. Keep your computer free of malware, keep your "id_dsa" encrypted. b. Don't use public computers (not completely in your control) to access your corporate host. 3. Don't leave the forwarded port opened for the whole Internet. a. "-R 127.0.0.1:2222:127.0.0.1:2222", not "-R 2222:127.0.0.1:2222" b. Not applicable in case of IPv6 method. 4. Provide access _only_ to the remote access server (get to other services _throught the_ remote access server) IPv6: "ip6tables -I INPUT -j DROP" "ip6tables -I INPUT -p tcp --dport 22 -j ACCEPT" 5. Don't mix corporate and private data on your remote computer. Encrypt sensitive data. Ideally keep special virtual machine (on encrypted volume) that contains id_dsa and can access your host. 6. Pay attention if SSH server's key suddenly changes or is missing. 7. Pay attention to your network configuration. Is your remote computer accidently routing the traffic to the corporate network? Can someone suddenly login into your remote computer (therefore, access 127.0.0.1:1080, for example)? ==Limitations== Obvious limitation that you can't press physical buttons on your host, you can't reset it, repair unplugged network cable etc. It's easier to break your host remotely then to fix it remotely. Also it can be a problem if your project involves displaying the video. vi0oss, 2011.