Skip to content

SSH Over Flaky Connection With MOSH

If you are like me and have to occasionally work while traveling, you may find yourself having to use Internet connections that are a bit on the flaky side. Sometimes I’m tethering to my phone while riding in a car or RV and pass though places where cell service is poor or non-existent. These situations are of lesser concern to web browsers and most email clients as they’ll just continue when the connection resumes, but for SSH any interruption usually results in a disconnect. Well thanks to MOSH (mobile shell) we can say goodbye to disconnects.

First we need to install mosh on the remote system and on our local system. On Gentoo systems this can be accomplished with ’emerge -av net-misc/mosh’ my USE flags:

net-misc/mosh client examples mosh-hardening server -ufw utempter


On Debian/Ubuntu systems you can do an ‘apt-get install mosh’ to get going.

Next you’ll need to open some ports up on the firewall. Mosh uses a port between 60000 and 61000 by default and the UDP protocol on the remote system. I personally open the full range as I sometimes have a lot of logins simultaneously.

Finally, you can connect to the remote machine in very much the same way you would with SSH:

mosh


Now you should be able to login once and have the connection stay up despite loss of connectivity and even moving from one ISP to another. I even leave them running while suspending (sleep) my laptop overnight.

Double SSH Tunnel, Port Forwarding To Access A Remote, Firewalled Webserver

Here’s the scenario: you need to access the webserver running on a UNIX machine that sits behind a firewall but we have access to a different machine via SSH that’s on the same network. Well not to fear because SSH is here to the rescue!

First we need to be sure that we can reach the remote SSH machine, so check that now. Next we need to make sure that we can get to the destination machine from the remote SSH machine so check that at the same time.

So how does all this work? It works by forwarding a local port to the remote SSH machine and then a second connection on the remote SSH machine will forward to our destination machine.

The command on the local machine:

ssh -L 127.0.0.1:1234:127.0.0.1:1234


The command on the remote SSH machine:

ssh -L 127.0.0.1:1234:127.0.0.1:80


Once both pieces are up and running all we have to do is point our web browser of choice to localhost:1234 and we’ll be accessing the destination webserver on port 80 as if we were on the same network, or thereabouts.

There really isn’t a limit, at least not that I’ve encountered, to how many times/machines you can tunnel through. This makes it ideal if you are trying to access a location when there are multiple firewalls in between. That’s all there is to it, it’s fairly simple and straightforward.

Proper DNS and DHCP for your LAN

If you are like me you don’t like the fact that most routers do a terrible job at providing DNS for the LAN-side. Sure, routers are easy to setup and will get you up and going quickly, but most of them suck in more advanced areas. I mean is it too much to ask for to be able to type in a hostname or IP address and have a consistent experience across all devices? Also, what about if I know an IP address but I have no idea what devices it belongs to. I don’t want to login to the router and search the logs for a Mac address that I may or may not recognize and I don’t want to waste time running nmap to try and fingerprint the system in hopes of identifying it. The router should provide reverse DNS lookup so I don’t have to! Oh and don’t get me started about the crappy DNS servers that ISPs provide!

So what we will be doing here is setting up BIND and DHCPd for our local network. It will provide IP address to our devices, register host (DNS) names, provide a local DNS server for queries, and give us reverse DNS.

Before we get started make sure you install dhcpd and bind9. You will probably also want to install bind-tools or whatever your distro calls it.

Now we will configure dhcpd by editing /etc/dhcp/dhcpd.conf and setting the following options (snippet):

server-identifier 192.168.1.1;
authoritative;
option routers 192.168.1.1; # use main router
option domain-name-servers 192.168.1.1;
option domain-name “”;
ddns-domainname “”;
ddns-rev-domainname “in-addr.arpa”;
ddns-update-style interim;
ddns-updates on;
allow client-updates;
update-conflict-detection false;
update-static-leases on;
include “/etc/bind/rndc.key”;
zone {
primary 127.0.0.1;
key rndc-key;
}
zone 1.168.192.in-addr.arpa {
primary 127.0.0.1;
key rndc-key;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.254;
default-lease-time 259200;
max-lease-time 518400;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
allow unknown-clients;
zone { primary 192.168.1.1; key rndc-key; }
zone 1.168.192.in-addr.arpa { primary 192.168.1.1; key rndc-key; }
}


Next we will be editing /etc/bind/named.conf. Under ‘acl “trusted”‘ add the hosts IP address. Then under the zone section you will want to add two new ones:

zone “” IN {
type master;
file “pri/.zone”;
allow-query { any; };
allow-transfer { any; };
notify yes;
allow-update { key “rndc-key”; };
};

zone “1.168.192.in-addr.arpa” IN {
type master;
file “pri/rev.zone”;
allow-query { any; };
allow-transfer { any; };
notify yes;
allow-update { key “rndc-key”; };
};


Create a normal BIND zone config file under /etc/bind/pri/.zone and also create a /etc/bind/pri/rev.zone just like a normal zone file except swap out the SOA domain with “1.168.192.in-addr.arpa” and the origin will be “$ORIGIN 1.168.192.in-addr.arpa.” Other than that it should look like a standard BIND zone config.

At this point we can disable the DHCP and DNS on the existing router and start dhcpd and named on the new one. Be sure to test it out before calling it “good” and walking away.

router ~$ host foo
foo. has address 192.168.1.230

router ~$ host 192.168.1.230
230.1.168.192.in-addr.arpa domain name pointer foo..


We are all set and can sleep soundly knowing that our network works correctly!