From FarmShare

Revision as of 15:25, 24 August 2017

Public Key Authentication

Public key authentication is not supported by FarmShare systems.

GSSAPI Authentication

FarmShare systems do support password-less authentication using GSSAPI if you have a valid Kerberos ticket for the stanford.edu realm.

OpenSSH

On macOS and Linux systems you can enable GSSAPI by adding the following lines to ~/.ssh/config on your local system.

GSSAPIKeyExchange yes
GSSAPIAuthentication yes

In some cases GSSAPI authentication may be enabled by default, but ssh will not forward your Kerberos ticket to the remote system. This can be inconvenient, especially in the legacy FarmShare environment, or when you expect to access AFS on rice. You can enable forwarding by adding GSSAPIDelegateCredentials yes to ~/.ssh/config, but you should do so only for trusted systems; to restrict the option, add it to a Host block:

Host rice rice.stanford.edu rice?? rice??.stanford.edu cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
  GSSAPIDelegateCredentials yes

See the man page for ssh_config for more information on GSSAPI options.

PuTTY

PuTTY supports GSSAPI authentication by default; to enable forwarding, select Connection → SSH → Auth → GSSAPI → Allow GSSAPI credential delegation.

SecureCRT

SecureCRT supports GSSAPI authentication, but it is disabled by default. To enable GSSAPI, open the Session Options dialog and select Connection → SSH2 → Authentication → GSSAPI and Connection → SSH2 → Authentication → Key exchange → Kerberos (Group Exchange). SecureCRT attempts authentication and key exchange methods in the order listed, so these methods should be moved to the top of their respective stacks. Delegation is enabled by default when GSSAPI authentication is selected.

Two-step Authentication

You can avoid some of the inconvenience of two-step authentication using ssh multiplexing. This feature creates a master session on initial connection to a particular host; subsequent sessions reuse the existing connection as a tunnel, so no further authentication is required. The master session can be configured to remain open using ControlPersist, even after you have closed the initial connection. Add the following lines to ~/.ssh/config file on your local system to enable multiplexing.

ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p
ControlPersist yes

PuTTY and SecureCRT support multiplexing, but do not support ControlPersist, so the feature is of less utility on Windows systems.

Keep-alive

A connection that is left open but idle might be closed after some time. Many SSH clients have a keep-alive feature that can be used to prevent idle disconnections.

OpenSSH

Add the following line to ~/.ssh/config on your local system.

ServerAliveInterval 60

PuTTY

Select Connection → Sending of null packets to keep session active → Seconds between keepalives (0 to turn off) 60 and Connection → Low-level TCP connection options → Enable TCP keepalives (SO_KEEPALIVE option).

SecureCRT

In the Session Options dialog, select Terminal → Anti-idle → Send protocol NO-OP every 60 seconds.

Suggested OpenSSH Configuration

The options described above are here collected into a configuration that should be safe and convenient for most users connecting from macOS and Linux systems.

# ~/.ssh/config

# FarmShare 2

Host rice rice?? cardinal cardinal?
  HostName %h.stanford.edu

Host rice rice.stanford.edu rice?? rice??.stanford.edu cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
  ControlMaster auto
  ControlPersist yes
  GSSAPIDelegateCredentials yes

# Legacy FarmShare

Host corn corn?? rye rye??
  HostName %h.stanford.edu

Host corn corn.stanford.edu corn?? corn??.stanford.edu rye rye.stanford.edu rye?? rye??.stanford.edu
  ControlMaster auto
  ControlPersist yes
  GSSAPIDelegateCredentials yes

# General Configuration

Host *
  ControlPath ~/.ssh/%r@%h:%p
  GSSAPIKeyExchange yes
  GSSAPIAuthentication yes
  ServerAliveInterval 60