Category Archives: linux

ssh connection sharing

Another relatively unknown feature of openssh is connection sharing. This enables you to reuse an existing ssh connection for another one. The second (and subsequent) connections(s) (called slaves) will use the same TCP connection as the first one (called master). The advantages are that the slave connections are initiated faster and that there is no password needed. And both these improvements make bash tab completion very fast. For example if you have an ssh session already running to a remote host you can use tab completion from another shell for scp, and it finds the files on the remote host.

Setting it up is simple: in your .ssh/config, add these lines:

Host *
ControlMaster auto
ControlPath /home/oku/.ssh/%r@%h:%p

Replace ‘oku’ with your user name.

The ‘ControlMaster auto’ option tells ssh to check if there is already a master, and if not set itself to the master. Otherwise, be a slave and use the master’s socket. The next line tells ssh how to name the unix socket it needs to create. In this example, it is composed of the remote user name, the host name and the port number, and will be created in the user directory in the subdirectory ‘.ssh’.

That’s all.

I use this for years now. It usually works fine, but there are a few disadvantages:

  • when the ssh connection unexpectedly dies (for example, a cold hardware reset), it leaves the socket behind. When you then try to login again, ssh complains that it cannot create the socket. You need to manually delete it.
  • when there are slaves, you cannot terminate the master session without terminating the slave connections.
  • if you do port forwarding, this works only for the master – if you try it with a slave, you don’t see an error message though. This is pretty annoying if you don’t know it. I think this also applies to ssh tunneling. This is reported as a bug in Debian.

Despite these flaws, I still find it very useful.

You will also find information here, and of course in the man pages.

Advertisements

7 Comments

Filed under debian, linux, openssh

VPN with openssh

A relatively unknown feature of openssh is its abilty to create a VPN tunnel. This has been implemented in version 4.3. I am not talking about port forwarding. This VPN creates a virtual network interface, which you can use like any other network interface. This is much more flexible than simple TCP port forwarding. It can be used for udp and icmp.
To set it up is actually very simple, but because I couldn’t find any good documentation, it wasn’t easy to figure out.

Here are the steps:

On the server, in /etc/ssh/sshd_config, configure it to allow tunneling and allow root login (if it isn’t there already):

PermitTunnel yes
PermitRootlogin yes

Restart the server with

/etc/init.d/sshd restart

From the client, you can then as root, and login as root to the server.

sudo ssh -w any:any root@fedoku

You need to be root on the client, and login as root. This is important, because only root can create the needed network devices (this is where I was stuck for some time).

When that was successful, you will see on both server and client a tun device:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Now you just need to configure them, both on server and client. Because they are point-to-point devices, you need to set the respective peer. The ifconfig commands mirror each other:

Client:

ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2

Server:

ifconfig tun0 10.0.0.2 pointopoint 10.0.0.1

That’s it, actually. Now you can set up routing, firewall, nat and so on, if needed.

There is also a way to use layer 2 networking, with virtual ethernet devices. All you have to do is to set the device type in the client configuration file:

TunnelDevice ethernet

The network devices now show up as tap instead of tun. The advantage is that you can use those for IPv6. I was never able to do that with the tun devices.

Another good documentation can be found here – which I found when I already had it figured out.

6 Comments

Filed under debian, ipv6, linux, openssh

Using ptrtd

I just checked out ptrtd. Understanding what it does is actually harder than installing and using it…: ptrtd is useful if you have an IPv6 only network. Of course, you do not want to isolate yourself from the IPv4 internet, so you need a way to access it. ptrtd maps every IPv4 address into IPv6 by prependig a prefix, so the whole internet becomes a tiny speck in the IPv6 address space. An address like 192.168.1.1 becomes fec0:0:0:ffff::192.168.1.1. ptrtd does this by creating a virtual network interface (tap) using tuntap.

But first the installation, which is pretty common:

./configure
make

I tested with:

sudo ./ptrtd

When it starts, it creates the interface:

tap0      Link encap:Ethernet  HWaddr D2:B2:5E:9D:07:89
          inet6 addr: fe80::1/64 Scope:Link
          inet6 addr: fe80::d0b2:5eff:fe9d:789/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:129 errors:0 dropped:0 overruns:0 frame:0
          TX packets:115 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:18747 (18.3 KiB)  TX bytes:15839 (15.4 KiB)

and sets the route to the network fec0:0:0:ffff::/64 to that device:

# ip -6 route show
...
fec0:0:0:ffff::/64 via fe80::5 dev tap0  metric ...
...

So now every IPv4 address is reachable via IPv6. I can for example ssh to 192.168.2.1 using the address fec0:0:0:ffff::192.168.1.1. The destination host does not notice, it appears to be coming from a usual IPv4 address.

Of course, the host running ptrtd needs to have both IPv4 and IPv6 (dual stack). It becomes only really interesting for hosts in an IPv6 only network when they set the route to fec0:0:0:ffff::/64 to the host running ptrtd.

The problem left is that we do not want to use the literal IPv6 addresses, but DNS names. And that’s where totd steps in. It translates IPv4 addresses from DNS to IPv6 addresses. I will test that later, and hopefully write about it.

2 Comments

Filed under debian, ipv6, linux

llconf site created

A few days ago I finally released my ongoing open source project, llconf. It is a library to make parsing configuration files easy. To learn how it works, see the Quick Guide.

3 Comments

Filed under debian, linux, programming

ipv6 patch for bidilink

Yesterday, I sent a patch to support IPv6 for bidilink to the author. I think it is a good example on IPv6 socket programming. It is also available here.

Comments Off on ipv6 patch for bidilink

Filed under ipv6, linux, programming