Sysadmin:SSH

You can install sshd through the package manager of your choice on a system. This page has some details about how to do more specific client-side and server-side actions with ssh.

Dynamic port forwarding

text from an email exchange between Craig and Skylar on the admin list

A lot of good stuff here, thanks Skylar.

FWIW, from my experiments using some comparable config options to those described below, I have been able to ssh to bronte and pollock from my local machine by way of hopper. Which is nice.

For the admins less familiar with some of the vocabulary in this conversation:

• https://linux.die.net/man/1/nc
• https://en.wikipedia.org/wiki/SOCKS
• https://en.wikipedia.org/wiki/Proxy_server

On Mar 26, 2019, at 12:19 PM, Skylar Thompson wrote:

This is a great suggestion, Craig. One trick I use with ssh_config is to have a Host stanza with a name not in DNS, and no HostName specified. This lets me use it as a profile for other settings, and then I can run "ssh -o HostName=some-host some-profile".

For instance, I can use this to open a SOCKS proxy port 1082 tunneled via SSH (nexus is our SSH gateway system, gsits-a is a management system, and nc glues the local SSH process to gsits-a via netcat on nexus):

Host gs-proxy

      HostName gsits-a.gs.washington.edu
      ProxyCommand ssh nexus.gs.washington.edu nc %h %p
      User skylar2
      DynamicForward 1082

I can then use this to forward local SSH traffic to arbitrary hosts accessible via the SOCKS proxy endpoint:

Host gs-proxy-client

      User skylar2
      ProxyCommand nc -X 5 -x localhost:1082 %h %p

For instance, "ssh -o HostName=foo.gs.washington.edu gs-proxy-client".

There's a lot of SOCKS clients you can use; for instance, almost any web browser supports SOCKS traffic.

On Mon, Mar 25, 2019 at 09:57:09AM -0400, Craig Earley wrote:
  Hi all,

  I�ve observed that several admins type full ssh commands to do a remote
  connect, e.g. `ssh [1]username@hopper.cluster.earlham.edu`.

  Since we ssh to the cluster and CS servers frequently, a better
  approach is to create a ~/.ssh/config file on your local machine (and
  probably on tools and cluster as well) that includes configurations for
  the servers you commonly ssh into. You can then specify something like
  this in that file:

  Host cluster

  Hostname [2]hopper.cluster.earlham.edu

  User username

  Then you run `ssh cluster` and it works the same as the full command
  typed above. You can add as many command-line-option-equivalent options
  to ~/.ssh/config as you'd like.

  For more detail, here's an intro-user-friendly
  description [3]https://nerderati.com/2011/03/17/simplify-your-life-with
  -an-ssh-config-file/ and here's the complete
  documentation [4]https://linux.die.net/man/5/ssh_config.

  I'd encourage you to make a ~/.ssh/config file. It takes very little
  time, and it will save you a lot of time and frustration in typing and
  typos.


References

  1. mailto:username@hopper.cluster.earlham.edu
  2. http://hopper.cluster.earlham.edu/
  3. https://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/
  4. https://linux.die.net/man/5/ssh_config

SSH tunneling

SSH port forwarding, or ssh tunneling, is a way to forward content from a port on a remote server to a port on your local computer.

For example, in the case of babbage, to tunnel to babbage through home, run this command in a terminal:

ssh -L 9000:babbage.cs.earlham.edu:443 <username>@tools.cs.earlham.edu

Replace <username> with your username on the cs machines. This is basically saying to send connections to your local port 9000 to whatever is running on port 443 (https) on babbage.

Go to https://localhost:9000. If you have a CS IP, go to https://babbage.cs.earlham.edu.

This model applies to other machines as well. Pay attention to http versus https. Check log files and use the -v option for ssh if it's not working.

Avoid displaying ssh errors to users on an upgraded server

When you can use this

The following works for a specific case:

• you have installed a new OS possibly on a new server BUT
• the system has the same hostname, domain, NFS mounts, etc. as the old version of the system

For example, you can do this if you need to upgrade Hopper but you still want to call it "Hopper" and you want user behavior to be the same. In that case, read on.

What to do

If you just start from scratch on an OS with a new sshd and new /etc/sshd files, users will encounter a scary security message (includes "SOMEONE MIGHT BE DOING SOMETHING NASTY"). This is because the files that sshd uses to identify itself to the user will not match the files from the previous version of the system.

All you have to do to get around this is save the ssh key files from /etc/sshd on the old version of the server. (You should be saving these through a backup system anyway.) This should be a simple copy.

A user's ssh process will check for the identity of the remote server. It will recognize it from the known_hosts file as the same system (which is what you want, in this very specific case!), so they won't have to go through the work of removing a line from their ~/.ssh/known_hosts file.