*IMPORTANT SSH Login Policies*

Changes to Remote Access to Peyton Hall Computers

For several years we have only allowed logins to Peyton Hall computers from machines that allow "Reverse Name Lookup"(1). As you may have experienced while traveling, this can be an obstacle to connecting from hotel rooms, etc.; not all ISPs use properly registered IPs. The exception to this rule has been machines such as muse and newton which were running Solaris. The last of these computers is about to be retired, so we need to do something to maintain unfettered external access. There are more excuses for why we're proposing changes under "RATIONALE" at the end of this document.

Proposed Plans for Remote Access

Lemma:

There is a machine (minos.astro.princeton.edu)(2) which allows open access, i.e. minos accepts logins (using passwords or ssh keys) from any machine on the net; it has been told not to pay any attention to problems with Reverse Name Lookup.
N.b. Minos mounts the home filesystems READ ONLY.(3)

Proposal:

That we change things so as to:
Allow access to all Peyton machines from anywhere, even without
BUT
Only allow users to login to machines other than minos by using ssh keys (i.e. no passwords). Password logins will still be permitted if you're sitting at the console. This rule will apply even within the building --- this is good; no more need to type your password.

We further propose that, before anything is changed, we run a series of hands-on workshops to get everyone in the building comfortable with using ssh keys to login, or (for those who prefer) comfortable with using minos as an intermediary.

In addition, Steve and Leigh have provided a "ssh-setup" script that you can run to accomplish all the magic required to set up your ssh keys on the astro machines. In addition, the astro FAQ web pages provide step-by-step instructions for installing ssh-keys on laptops or home computers.

Using ssh really is trivial (and very convenient), but setting it up initially is arcane, and something that most of us do only once in our lives; hence the offer of a workshop.

Rationale/FAQ

If it aint broke, why are we fixing it?

Because the last Solaris box is departing this earthly plane.

The speed and ruthlessness of attacks on computers has increased dramatically --- in other words, the cost of being successfully attacked has increased significantly over the last few years; no longer does a hacker simply poke around, nowadays they tend to destroy the system.

Most users connect from their own laptop, in which case they probably have ssh installed, and the proposed relaxation of the Reverse Name Lookup rule will be a considerable improvement in their life while travelling (e.g. when connecting from a hotel in Afghanistan). Of course, this change in their quality of life will only occur when the "no passwords" change is implemented --- so you should start lobbying for it.

Why is Reverse Name Lookup worth worrying about?

The bulk of attacks upon our systems (99% of 30k attacks/month) come from machines without reverse name lookup --- the reason's obvious: If you work for Student Admissions and you're smart enough that you don't want your handiwork traced back to your University, you don't want your machine's IP to be identified as "princeton.edu"; so you use a spoofed IP.

The breakins that we've seen recently (most recently from Arizona about 18months ago) have been caused by programs reading keyboard input to capture passwords; Evil People don't usually read every key typed at the keyboard, but instead install Evil versions of ssh that record your password as you type it. Access via ssh keys is less vunerable to such attacks as the passphrase is typed less often (and to a different programme, ssh-add), and because the Evil One has to capture both the passphrase AND the key. Most people keep their keys on their own laptops, which they physically control. But passwords can be used by themselves to login to accounts from any machine and are vulnerable to capture when one uses them on an unfamiliar machine.

As mentioned above, you'll be able to use your ssh keys stored in your home directory to authenticate to any machine on the planet that runs ssh-agent --- but beware key loggers in Lower Slobbenia.

Why do we want to mount /u Read-Only?

If we don't mount home directories read only on minos, the Evil Hacker can install her own .ssh directory and proceed to compromise the rest of the department.

Why not use smart cards (also known as crypto-cards)?

Because they're a bit of a pain, and because the initial cost would be in the neighbourhood of 10k$.

What do I do if I run Windows on my laptop?

Fear not, you can use Putty; see the instructions in the Peyton FAQ entry for SSH

Will remote access to mail be affected?

No; nothing will change either for the better or worse. Well, that's not quite true. If you like to log in, start pine, and save your mail to your home directory this won't work on minos (but it will of course work on other machines). You will however be able to read mail on minos and save messages to folders on the mail server.(6)

Footnotes

1. I.e. when they connect we know their IP address; Reverse Name Lookup means that we can associate that address with a registered machine

2.

                    ... Minos the dreadful
  Snarls at the gate.  He examines each one's sin,
  Judging and disposing as he curls his tail:
  That is, when an ill-begotten soul comes down,
  It comes before him, and confesses all;
  Minos, great connoisseur of sin, discerns
  For every spirit its proper place in Hell...

  Said Minos, who at the sight of me had paused
  To interrupt his solemn task mid-deed:
  "Beware how you come in and whom you trust,
  Don't be deceived because the gate is wide."

  [Dante's Inferno, Canto V, translation by R. Pinsky]

3. Making home directories read only means that minos may be used for:

• Logging in to other machines in Peyton using ssh keys; if you have an agent running remotely but don't have your keys you can even login to minos; add your keys; logout again, and then connect to any Peyton machine(4)
• Reading email with pine (mail messages can be saved to mail folders on the mail server, but not to home directories)
• Reading files with e.g. more, less, cat, or emacs.
• Copying files From /u To remote machines. You naturally won't be able to scp To /u, as it's read only. You will be able to copy to scratch disks, e.g. scp my_file minos.astro.princeton.edu:/scr/apache22/rhl or you can copy to /u using ssh tunnels(5)

4. E.g. you're sitting in a seedy internet cafe in Coonabarabran (which happens to have some unixy machines) and need to get some work done.

      cafe$ eval `ssh-agent`
      cafe$ ssh-add -l
      The agent has no identities.
      cafe$ ssh minos.astro.princeton.edu
      rhl@minos.astro.princeton.edu's password: XXXXXXX
      minos$ ssh-add
      Enter passphrase for /u/rhl/.ssh/id_dsa: XXX XXX XXXX XXXX XXXX X
      Identity added: /u/rhl/.ssh/id_dsa (/u/rhl/.ssh/id_dsa)
      minos$ logout
      cafe$ ssh minos.astro.princeton.edu
      minos$ ssh apache2
      apache2$ logout
      minos$ logout
      cafe$ ssh apache2.astro.princeton.edu
      apache2$

Note that the ssh-add adds your identity to the ssh-agent; it doesn't write to disk. If the evil cafe owner has installed her own ssh binary and captured your password and your pass-phrase she can now login to our machines --- but that's a risk that we have to take to allow remote access from untrusted sites. We hope that the evil one is a windows user and doesn't understand ssh, but security through obscurity isn't.

Once you've added your keys, you can go directly into any Peyton machine; you can connect via minos, but there's no point.

5. E.g. to copy to your home directory on eos from Somewhere in Cuba, via minos:

      guant$ ssh -N -f -L 9000:eos.astro.princeton.edu:22 minos.astro.princeton.edu
      guant$ scp -P 9000 -o StrictHostKeyChecking=no myFile localhost:RemoteMyFile

The first magic incantation made the port "localhost:9000" an ssh connection to eos; the scp command then used it. The "StrictHost" part is so that SSH will let you do this - the first time it will work fine, but after that SSH may think the host identification changed, especially if you use a different host between the colons ("coma.astro.princeton.edu" instead of "eos..."); the

  StrictHostKeyChecking=no

tells ssh to disregard any change in host identification.

6. Well, you won't even be able to do this if you have asked pine to write to your home directory in your .pinerc file. For example,

folder-collections=mail/[]

In case of trouble, move .pinerc out of the way and try again