Fast SSH file transfers with HPN patches

This is a common problem: you have some big files (for example a disk image) to transfer over a Gigabig Ethernet link and it takes too much time with SCP/SFTP . Also you probably don’t want to bother installing an ftp server, then what’s the answer?

It’s called HPN-SSH and it’s a patchset you can apply on top of ssh. Is basically provides dynamic window, the none cipher and the multi-threaded MT-AES-CTR cipher. Obviously with the none cipher you will get no encryption, but that’s not a problem for a point-to-point Gigabit Ethernet link.

First I tested the maximum network speed I can achieve using FTP: 111.5 MB/s (0.87 GB/s)

1706560496 bytes received in 14,6 secs (1,1e+05 Kbytes/sec)

Then I tested the speed with SCP and the none cipher: 95.7 MB/s (0.75 GB/s)

scp -4 -o NoneSwitch=yes -o NoneEnabled=yes /mnt/ram/big root@<ip>:/mnt/ram/big

Finally the speed with SFTP and the none cipher: 81.4 MB/s (0.64 GB/s)

sftp -4 -o NoneSwitch=yes -o NoneEnabled=yes root@<ip>

I used a random generated 1.6 GB file for the tests, also all transfers are from ram to ram to avoid disk bottlenecks.

mount -t ramfs -o size=1640m ramfs /mnt/ram

If you use Debian Squeeze amd64 you can easily install SSH-HPN using my repository. Then add the following to your /etc/apt/preferences (replace at and dot)

Package: openssh-client openssh-server
Pin: release o=Niccolo Belli <darkbasic(a.t.)linuxsystems(d.o.t.)it>
Pin-Priority: 1001

To allow the use of the none cipher add NoneEnabled yes to your /etc/ssh/sshd_config, then restart ssh.

x86_64/SSE2 optimized Serpent cipher algorithm: 3x faster

Yesterday linux 3.3.0 has been released, one of the less talked features is the new assembly optimized Serpent cipher algorithm.

Serpent is a symmetric keyblock cipher which was a finalist in the Advanced Encryption Standard (AES) contest, where it came second to Rijndael. Serpent was designed by Ross Anderson, Eli Biham, and Lars Knudsen.
Source: Wikipedia

My laptop’s root is Serpent encrypted, so this is an awesome news for me. If you have an encrypted root you can easily benchmark the cipher performance with

hdparm -t /dev/mapper/vg-root

while you can see the potential of the disk with

hdparm -t /dev/sda /dev/sda:
Timing buffered disk reads: 750 MB in 3.00 seconds = 249.75 MB/sec

The new assembly optimized cipher proved to be 3x times faster on my laptop, you can find the commits here:
http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;
h=937c30d7f560210b0163035edd42b2aef78fed9e

http://git.kernel.org/?p=linux/kernel/git/herbert/crypto-2.6.git;a=commit;
h=251496dbfc1be38bc43b49651f3d33c02faccc47

Also, linux 3.2 carries an SSSE3 based SHA1 implementation for x86-64 (up to 2.3x faster). I’m pretty sure it is of much more interest because it is widely used in ipsec tunnels.

IPv4 vs IPv6 1Gbps network performance

Netperf is a benchmark that can be used to measure the performance of a network. I did a simple test over a 1Gb/s ethernet link to compare IPv4 and IPv6 overhead, here are the results:

~ # netperf -4 -H 192.168.2.1
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.1 (192.168.2.1) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size
Time
Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384
10.03
840.45

~ # netperf -6 -H a:b:c:d::1
MIGRATED TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to a:b:c:d::1 (a:b:c:d::1) port 0 AF_INET6
Recv Send Send
Socket Socket Message Elapsed
Size Size Size
Time
Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384
10.04
702.21

IPv4 reached a 100MB/s speed, while IPv6 only 84MB/s. I wouldn’t have expected such a big difference, especially while other benchmarks on the web show little gains with v4. Further testing confirmed IPv6 speed depends too much on the NIC to do a true comparison.

Bye bye Aruba.it, welcome DNSSEC!

A few days ago I asked Aruba’s technical support to add IPv6 glue to my domain because I can’t do it from their control panel, what did they told me? They told that’s my task adding AAAA records since I’m using my own DNS server! They didn’t even know what’s a DNS Glue record…
The glue records need to be created on the parent name servers because they are needed to prevent circular references. More about glue records: http://www.webdnstools.com/dnstools/articles/glue_records
That’s why yesterday I asked to transfer my .biz domain (linuxsystems.biz) to another registrar which supports both IPv6 and DNSSEC and here we are with a completely automatic DNSSEC deployment and key rollover! That’s for the authoritative, but obviously our internal recursive dns server does validate DNSSEC signatures.
Wake up NIC.it, we aren’t in the Middle Ages since a long time! We need IPv6 glue and DNSSEC!

 

Here we are, IPv6 ready!

I’m proud to announce we are finally online with dual stack IPv4/IPv6 connectivity! Not only the web server: mail server, jabber, dns, pbx, logserver, repository… everything can be reached using IPv6 (we are still waiting our domain registrar for the IPv6 glue to be honest). Also, the whole local network is IPv6 ready too: that means lots of Windows machines with a public IP attached and a 5000+ lines firewall. Our provider still didn’t give us native IPv6 connectivity, so we extruded an IPv6 subnet through an ipsec IKEv2 tunnel to reach the goal. More details may come in future, at the moment I’m looking at IPv6 layer 7 shaping and opportunistic encryption using DNSSEC.

Join the launch: http://www.worldipv6launch.org