[CHUUG]

Stupid SSH Tricks

All-in-one version

((Regular [individual slides] version)

Overview


 

Introduction


 

Main Parts


  1. slogin hostname [-l username] [-v] [-x] [other options]

    -v verbose mode
    -x don't tunnel X connection
    -l username different username on remote host

  2. ssh hostname [-l username] [-v] command [args]

    One-off command; falls back to slogin if no command given. Most options work with ssh as with slogin. Command can be quoted (' or ")

  3. scp file.ext [username@]hostname:[path/file]

    Several points to note:

    1. files can be local or remote (one or both);
    2. Second argument can be a directory; if so, first filename is preserved;
    3. Multiple files can be specified; if so, last argument must be a directory.
     

    Extras


    • ssh-agent: typically run from .xinitrc; holds authentication key(s).

      eval `ssh-agent`

      or

      ssh-agent my-window-manager

      (those are backticks). Environment variables (e.g. SSH_AGENT_PID) inherited by child processes. Can be run from an xterm (not as good).

    • ssh-add: adds your key to the agent. If you have a passphrase (see next slide) it asks for it and caches it.

    • ssh-askpass: GUI way of prompting for your passphrase if you have one, e.g.:
      ssh-askpass | ssh-add -p
      Grabs the X focus (as does the xterm ctrl-left-mouse menu item "Secure Keyboard") to make it harder for others to monitor keystrokes:
     

    Basic Setup


    • Create a key:

      1. cd
      2. ssh-keygen
      3. Accept default location for your keys (~/.ssh/) by pressing <return>
      4. Choose an empty passphrase; just hit <return> when asked for it (see next slide if you want a non-blank passphrase).
      5. cd ~/.ssh/
      6. cp identity.pub authorized_keys
      7. chmod 0600 authorized_keys

      This gives password-less access to any local machines that share your login area (via NFS, presumably). This can be good and bad.

    • To extend this to remote systems:

      1. slogin to the remote site; it'll want your password.
      2. Go through the steps above on the remote system (generate a key there).
      3. Copy your identity.pub file from the local host, and append it to the authorized_keys file you just created on the remote host. This allows you a password-less login from local to remote.
      4. If you want the same from remote to local, copy the newly generated identity.pub from the remote host and append it to the authorized_keys file on the local host.
      5. Repeat for each other remote site as you want (think if you need things two-way or not, and how well secured the remote site may be; do you trust its sysadmin?).
     

    Advanced Use


    1. Use a Passphrase! Greatly increases your level of security, but can affect ease of use.

      • ssh-keygen -p will add or change a passphrase.
      • Use ssh-agent and ssh-add to cache your identity; you thus only need to authenticate once on login, and all your remote connections will query the agent (not you) for your identity.
      • Prevents automated scripts using scp. Solution is to use special purpose keys (see below).

    2. X Tunneling: happens by default unless you (or whoever installed sshd) decide otherwise. How it works:

      • DISPLAY variable is automatically set to, e.g., remotehost:10
      • Remote ssh daemon tunnels X events to local ssh client.
      • Local ssh client connects these to local X server (:0 or whatever).
      • No need to manually set variables, use xhost or xauth; it just works.

    3. Compression: most useful across a slow link (e.g., modem). Add -C to command lines, or use ~/.ssh/config to enable for some or all hosts. For text (including PS) transfers, can vastly improve performance. Works for simple X apps too (emacs) but doesn't do much for graphic-intensive X apps.

    4. Special Keys: If you generate a second or subsequent key (NOT your identity file!) and then specify:

      command="/home/mystuff/progname",no-port-forwarding,
      no-X11-forwarding,no-agent-forwarding,no-pty 1024 37 343452435...
      (for example; but no line breaks!) in authorized_keys on that new key, this restricts what ssh using the equivalent private key can do. You can use environment variables:

      • SSH_ORIGINAL_COMMAND and
      • SSH_CLIENT (remote IP)

      within the program or script. Use stdout from your program/script to send output to the other end, or read from stdin if the remote end sends to its stdout.

      This has been used to facilitate many automatic jobs within NRAO that used to use rcp and relied on .rhosts files. Here is a sample perl script that serves up only certain files.

    5. Other Tunneling: You can tunnel arbitrary ports, e.g. POP3, IMAP, and even FTP (tricky; need ports 20, 21). Beyond the scope of this talk; Possible presentation by Brian Mays? See -L and -R options in the manual pages for ssh.
     

    Conclusions


    • ssh is being widely deployed in many places (especially academia) in response to a rash of break-ins and password sniffing incidents.

    • It can allow a near-"single-sign-on" mode of access.

    • Tunneling feature (X11, others) can be very useful; X11 convenience may persuade reluctant users to use it.

    • Automated tasks formerly done with rsh and rcp can still be done with dedicated keys and appropriate programs.

    • It's not a panacea; a good security policy, firewalls, and more are required elements of any effort to improve network security.

     

    Pat Murphy