*IMPORTANT SSH Login Policies*

From Peyton Hall Documentation

Revision as of 15:55, 2 May 2007

Template:oldfaq

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.

----------------
$^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.

                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:

Setting up Putty in Windows

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$

$^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