How to use SSH with 2FA

How to log in to the Maths servers from "outside" machines, with 2FA two-factor authentication.
Some ideas here may be useful without 2FA, e.g. for laptops or office machines within the School.
Internal users connect to dora e.g. ssh -C -X USER@dora, 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?).


Set up 2FA for your account

2FA two-factor authentication provides a cheap, effective, additional layer of security, similar to popular online services such as Google accounts.

Choose either skeys or TOTP.

To decide whether to use skeys or TOTP:

Recommendations in a nutshell

Follow these recommendations to use 2FA words or codes, and password, just once per day.
For details, rationale, other ways or other things you can do, see later in this document.


You will need an ssh client (the ssh command or program); you should also have an X server. After running your ssh command, just follow the prompts: type the words from your skey sheet for the line number shown, or the authenticator code, then your normal dora password. You will be logged in to dora.
The very first time you use ssh, you will be prompted about the as-yet unknown authenticity fingerprint: say yes.

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 dora 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 dora and your machine.

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

It may be best to use a tool integrated with the native "file manager":

File transfer made easy

Save 2FA prompts
... (and the "complexity" of using them), use tunneling or port forwarding so you can connect direct to dora (in effect from dora itself, so 2FA is 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 2FA, 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 laptop and the public key as authorized on dora.
At the initial login with 2FA you still get a password prompt, as configured for security.
Easy for Linux or Mac, not so easy to do on Windows.
You may also use this to ssh/scp between dora and the research servers.
Do not inadvertently publish your private key, e.g. when uploading to web or Git servers.

On dora run commands

  ssh-keygen     (accept filename, press ENTER to use empty passphrase)
  ln -s ~/.ssh/authorized_keys
then copy the private key file ~/.ssh/id_rsa to your laptop. Easy access
... to your files on dora, while your ssh session is running, with port forwarding in place: "Look Ma, no hands": no pesky 2FA or password prompts!

Using the ssh-with-2fa script

Using the ssh-with-2fa 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 ssh session just by typing
  ssh USER@dora
or use
  scp file1 USER@dora:
  scp USER@dora:file2 .
and the "right" things would happen: connect to the right host and port (maybe with 2FA, or 2FA-less via the port forward while your ssh session is running), with the "correct" options (all those mentioned above and below), whether your laptop is "outside" or connected to the School's internal network; 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 or rsync) will also work just fine (without 2FA or even passwords).

Please let Paul know if you find anything that is any less than magical and perfect.
If you have any problems with ssh-with-2fa then run it as ssh --debug USER@dora to see more verbose messages.

Other forwardings: IMAP, POP, SMTP

You may want to (and ssh-with-2fa will) use the forwarding options
  -L 12025:rome:25 -L 12110:rome:110 -L 12143:dora:143
to make our internal POP and SMTP server (rome) and IMAP server (dora) accessible, while the ssh session is running. Set your mail client (e.g. mutt, alpine, thunderbird) to use:
   proto   server   port
   POP    localhost   12110
   IMAP   localhost   12143
   SMTP   localhost   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 dora, 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-2fa will) use the dynamic forwarding option
  -D 13080
so on your laptop (in a terminal, not the ssh-ed one running on dora) 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 dora, on all "local" commands.

To use tsocks (Linux): on the laptop, 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 laptop, 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 laptop (in a terminal, not the ssh-ed one running on dora) 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 dora 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 laptop; 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:


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

Idle timeouts

If you allow your computer to disconnect from the network e.g. to go to sleep/hibernate, as most laptops do with the lid closed, then your ssh session will be terminated.

There are timeouts set in several network "appliances":

The above timeouts may all be non-issues, 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.
If your computer goes to sleep or hibernate then it will not communicate, and the above settings will cause the session to be terminated in 10 minutes. Without the above settings, the ICT firewall would drop the connection in 5 minutes, instead.

If affected still, you may want to add the -oServerAliveInterval=10 option to ssh (for Linux or Mac, putty has keepalive settings but not for command line); or leave

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

Random ramblings

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

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

For outgoing connections we have transparent proxy on the firewall, see
You may still want to use the ssh-with-2fa script, to choose sensible options.

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.

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 2FA from such "trusted" hosts.

The 2FA software is available in directory /usr/sms/etc/2fa (on dora).
NOTE: file:/ links (as above) do not work in Firefox. Copy link location then paste to Firefox URL bar, see't_work .

You might want to use sshfs, though seems more complicated than the alternatives above. Should you insist on sshfs then maybe use (or see instructions in)
(noting that it could connect via port forwarding).

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

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: We are pretty safe against any breakins with 2FA; in fact I have never noticed them trying 2FA at all, they just try single passwords. Many try root only as the login name (and root does not have 2FA).

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.

Our 2FA implementation has a "max bad tries" lockout: after 5 failed attempts at 2FA authentication, no more tries are permitted for an hour (the lockout is cleared automatically after the hour).

Further reading, random references

Paul Szabo 29 Jan 18