How to use SSH with skeys

How to log in to the Maths servers e.g. como from "outside" machines, with skeys.
Some ideas here may be useful without skeys, e.g. for laptops or office machines within the School.
Internal users connect to como e.g. ssh -C -X USER@como, not to; see also the network setup needed for internal laptops.
To log in to office Windows PCs see the RDP howto, for office Macs see the VNC howto also (instead?).



You will need an ssh client (the ssh command or program); you should also have an X server.
You will need a sheet of
skeys: get it from Paul, in person. After running your ssh command, just follow the prompts: type the six words from your paper skey sheet for the line number shown, then your normal como password. You will be logged in to como. The very first time you use ssh, you will be prompted about the as-yet unknown authenticity fingerprint: say yes.
Lines on your skey sheet decrement each time: cross out last line used, making it easy to find next one when needed.

You will have full X-windows access, so could xfrom to other machines, or use other X-windows software like nedit or tuteroll, or licenced software like matlab, mathematica or maple, or even firefox or thunderbird (with full access to scnews and other internal pages or mail files, though these may be too slow over the network); or use "xnest -query como" for an authentic login experience.

File transfer with scp

As well as ssh, you can use scp (or sftp or sshfs) to copy files between como and your machine.

Tempting to try some GUI clients ... but mostly they do not understand the skey prompt (expecting to send just a plain password) so they fail; they work fine once you save skeys ... see below under made easy.
Some GUI clients for SFTP:

Anyway it is best to use a tool integrated with the native "file manager":

File transfer made easy

Save skeys
... (and the "complexity" of using them), use tunneling or port forwarding so you can connect direct to como (in effect from como itself, so skeys are not needed).
Start your ssh session with the forwarding: With your ssh session running, use sftp (or scp or ssh), or rsync, or your favourite
GUI client for SFTP, to connect to localhost on port 12022.
Your initial ssh session needs skeys, it is subsequent connections that may avoid it.

Save typing your password
... use public keys. Generate some keys and copy things around so you end up having the private key on the home machine and the public key as authorized on como. For example, on como run commands

ssh-keygen (accept filename, press ENTER to use empty passphrase)
ln -s ~/.ssh/authorized_keys
then copy ~/.ssh/id_rsa to home machine: You may also use this to ssh/scp between como and the research servers.
You still get a password prompt after your skey, as configured for security.

Easy access
... to your files on como, while your ssh session is running, with port forwarding in place:

"Look Ma, no hands": no pesky skey or password prompts!

Using the ssh-with-skey script

Using the ssh-with-skey script
is not required, but using it may make things a little easier, as it chooses the "right" options for ssh or scp or sftp. In particular, you could start your skey session just by typing
ssh USER@como
or use
scp file1 USER@como:
scp USER@como:file2 .
and the "right" things would happen (maybe with skeys or maybe skey-less via the port forward while your ssh session is running), whether your laptop is at home or connected to the School's internal network.
ssh-skey will use the "correct" options, all those mentioned above and below; it will also do the right thing for any other uses, connecting to any other places, not just for "School related".

To use the script:

Then software that uses ssh e.g. unison will also work just fine (without skeys or even passwords).

If you have any problems with ssh-with-skey then run with "--debug" as first option e.g.

ssh --debug USER@como
perl ssh-with-skey --debug
to see more verbose messages.
Please let Paul know if you find anything that is any less than magical and perfect.

Other forwardings: IMAP, POP, SMTP

You may want to (and ssh-with-skey will) use the forwarding options
-L 12025:rome:25 -L 12110:rome:110 -L 12143:como:143
to make our internal POP and SMTP server (rome) and IMAP server (como) accessible, while the skey/ssh session is running. Set your mail client (e.g. mutt, alpine, thunderbird) to use:
POP server localhost, port 12110
IMAP server localhost, port 12143
SMTP server localhost, port 12025
This also solves the issue of finding an SMTP server from home networks like Optusnet or Bigpond that disallow port 25 access.
Seems that first-time IMAP users need to do "mkdir -p ~/Mail/.imap" for IMAP login to succeed.

You may also want same forwardings for "internal" laptop clients connecting ssh to como, so the mail client configuration does not need to change between internal and external uses.

Dynamic forwarding

From outside, you may want to (and ssh-with-skey will) use the dynamic forwarding option
-D 13080
so on your home machine (in a terminal, not the ssh-ed one running on como) you can use tsocks or proxychains to access any "internal" services. Examples (all examples with tsocks, could equally use proxychains instead):
With dynamic forwarding, name lookups (DNS services) are done locally not via the forwarding, so need to use FQDN names e.g. instead of plain como, on all "local" commands.

To use tsocks (Linux): on the home machine, edit ~/.tsocks.conf (or /etc/tsocks.conf) to contain the lines

  server =
  server_type = 5
  server_port = 13080
(remove or comment out other lines).

To use proxychains (Linux, Mac): on the home machine, edit ~/.proxychains/proxychains.conf (or /etc/proxychains.conf) to contain the lines

  socks5 13080
(do not use proxy_dns, and with just one line in ProxyList).

On your home machine (in a terminal, not the ssh-ed one running on como) use commands like

tsocks command args...
proxychains command args...
or, once use either of the commands
tsocks bash
proxychains bash
to run a new shell, then in that shell use "plain" commands.
See about other similar utilities e.g. for Windows.

Comments on port forwarding

We use ports above 12000 because low ports are root-access-only on Linux, and to avoid clashes with locally running services.

Seems tempting to use -L 515:siv:515 for LPD and easy printing. But copying the file to be printed with scp and then printing directly from como may be simpler; and anyway we cannot use low ports on Linux.
Setting up local printing (on localhost) would not be trivial. Printing from outside, when not around to pick up printout, is not much use.

Very tempting to use -L 139:rome:139 then use connect-to-server smb://localhost to access the Samba server on rome (for file access or even printing), but that might not work: on Linux/Mac it requires root access e.g. sudo on the home machine; on Windows, port 139 may be "in use" already.
On Windows, I could not get it to work, not even with the tricks in


The performance (responsiveness etc) of the connection should depend on the speed of the "home" end of the network: on a fast cable or ADSL connection, should be similar to the speed of a Y-terminal within the School.

Known issues:

See also mention of X11 being a "network hog", later below.


We do not even try incoming VPN, as that would require complex and intrusive settings on both como and on the home machine. For references see:

Idle timeouts

Incoming connections have an idle timeout of 3 hours, outgoing have an idle timeout of 4 hours; there are no timeouts on the internal Maths network.

Home users beware: your router (or modem) may have a shorter timeout, my DLink DI524 wireless router uses 1 hour (in Status, ActiveSessions, then drops the connection).
Some hotel (wireless?) networks may have shorter idle timeouts.

The above may be a non-issue, as we have the lines

  TCPKeepAlive yes
  ClientAliveInterval 10
  ClientAliveCountMax 60
in the Maths /etc/ssh/sskd_config file: we are never much idle, and survive network dropouts of 10 minutes. BEWARE: this consumes data, about half a kB each 10 secs, 200kB per hour, 4MB per day.

The ICT network people have put in a 5-minute idle timeout into their new FortiGate firewall appliance around 13 Jan 2012. With the above setting of ClientAliveInterval, we were not affected; we protected outgoing connections by using SO_KEEPALIVE in the siv outgoing proxy.

If affected still, you may want to add the -oServerAliveInterval=10 option to ssh (for Linux or Mac, putty does not seem to have it); or leave

while :; do date; sleep 60; done
(really: "rpt 60 date") running.

Random ramblings

No need to mention outgoing connections: we have transparent proxy on the firewall, see
You may still want to use the ssh-with-skey script, to choose sensible options.

For internal laptops etc, please see
about wired and wireless connections, and
about settings and printing.

These instructions are referenced (referred to) from:     (click "Incoming ssh")    (here).

For incoming connections, ssh or putty talks to the firewall, and only the firewall knows which internal machine the connection is sent to: currently como.

When using Cygwin (its ssh and its X server), or maybe from MacOSX, you need the (unsafe) -Y option instead of -X: I guess needed whenever xdpyinfo does not show the SECURITY extension.

Note that X-windows is a very (in?)efficient "network hog" (a particularly bad example is the firefox downloads window). Using the ssh -C option seems to help.
I do not know if using lbxproxy would have helped, as it does not work, see
See also similar or related:     xterm     gnome-terminal     dxpc     nxproxy
file:/usr/sms/bin/x11proxy             our script
NOTE: file:/ links (as above) do not work in Firefox. Copy link location then paste to Firefox URL bar, see't_work .

Dire warnings (words of Jim Richardson):
Note that skeys are only for use of the person to whom the sheet was allocated, and no forwardings or tunnels other than the above should be used without prior arrangement with the School Computing Manager.

Note for Maths (129.78.68.*, e.g. Magma) users:
You do not need skeys from such "trusted" hosts.

The skey code is available in file:/usr/sms/etc/skey.

sshfs: see some instructions in

Rate limits

On occasions, while trying to log in, you may receive errors like
   Connection closed by remote host
   server unexpectedly closed network connection
   Connection refused
When that happens, try again in a little while. Long story below.

That is our protection against password guessing attacks, in action: we have rate limiting on ssh connections. When that happens, try again in a little while; or maybe wait until the next wall-clock hour, then try; maybe use "ssh -v ..." (or "putty -v") to see the "error" message; try soon after the restriction is lifted, before the "bad guys" use up all permitted tries.

For some background, see:
and example log lines from 2011:

  Aug 25 22:17:33 bari sskd: Failed for invalid user aaa
  Aug 25 22:17:48 bari sskd: Failed for invalid user aaron
  Aug 25 22:17:51 bari sskd: Failed for invalid user abacus
  Aug 25 22:17:56 bari sskd: Failed for invalid user abby
Our ssh service (on our firewall machine siv or talus: the front-end, reverse-proxy process) is handled by our sshind script. In sshind we have two kinds of rate limits: Our sshind is started from xinetd. In the file /etc/xinetd.conf we use the setting "cps=1 15", providing another protection: (No longer have my cpm and cph patches in xinetd, but have rate limiting in the sshind script as above.)

We are pretty safe against any breakins with skeys; in fact I have never noticed them trying skeys at all, they just try single passwords. Many try root only as the login name (and root does not have skeys).

We limit connections to protect against attackers wasting resources, hoping to make the attacker "go away" and try another victim. Our protections have stopped many ssh password guessing runs/attacks, significantly lowering the CPU load on our machines.

Beware that any limits (in sshind or xinetd) will affect legitimate users also: hopefully our rates and back-off times are not too annoying.

Further reading, random references

Paul Szabo 22 May 17