Advanced Connection Options

From FarmShare

(Difference between revisions)
Jump to: navigation, search
(Two-step Authentication)
 
(30 intermediate revisions not shown)
Line 1: Line 1:
== Public Key Authentication  ==
== Public Key Authentication  ==
-
Public key authentication is not supported by FarmShare systems. However...  
+
Public key authentication is not supported on FarmShare systems.
-
== GSSAPI (Kerberos) Authentication  ==
+
== GSSAPI Authentication  ==
-
FarmShare systems do support password-less authentication using GSSAPI.  
+
FarmShare systems ''do'' support password-less authentication using GSSAPI if you have a valid Kerberos ticket for the <code>stanford.edu</code> realm.  
-
=== OpenSSH (Linux, Mac OS X)  ===
+
=== OpenSSH ===
-
The default configuration of OpenSSH uses GSSAPI for authentication if a valid Kerberos ticket is present but does not forward tickets to the remote system, which can cause problems with [[AFS]].  
+
On macOS and Linux systems you can enable GSSAPI by adding the following lines to <code>~/.ssh/config</code> on your local system.
-
It is possible to enable forwarding by adding the ssh option '''GSSAPIDelegateCredentials''' to ~/.ssh/config, but you should do so only for trusted computers. Something like the following is recommended:
+
GSSAPIKeyExchange yes
-
<pre>Host cardinal cardinal? corn corn??
+
GSSAPIAuthentication yes
-
    HostName&nbsp;%h.stanford.edu
+
-
Host cardinal cardinal? cardinal*.stanford.edu corn corn?? corn*.stanford.edu
+
Recent versions of macOS no longer support the <code>GSSAPIKeyExchange</code> option; you can either omit this option or, if you prefer to keep a standard configuration, add the additional option <code>IgnoreUnknown GSSAPIKeyExchange</code> to your <code>~/.ssh/config</code> file.
-
    GSSAPIKeyExchange yes
+
-
    GSSAPIAuthentication yes
+
-
    GSSAPIDelegateCredentials yes
+
-
</pre>  
+
-
This configuration should work safely in all common cases for both cardinal and corn systems.  
+
-
See the man page for ssh_config for more information on GSSAPI options.  
+
In some cases GSSAPI authentication may be enabled by default, but <code>ssh</code> 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 <code>rice</code>. You can enable forwarding by adding <code>GSSAPIDelegateCredentials yes</code> to <code>~/.ssh/config</code>, but you should do so ''only'' for trusted systems; to restrict the option, add it to a <code>Host</code> block:
 +
 
 +
Host rice rice.stanford.edu rice?? rice??.stanford.edu cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
 +
  GSSAPIDelegateCredentials yes
 +
 
 +
See the <code>man</code> page for <code>ssh_config</code> for more information on GSSAPI options.
 +
 
 +
=== PuTTY  ===
 +
 
 +
[https://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] supports GSSAPI authentication by default; to enable forwarding, select <code>Connection</code> → SSH → <code>Auth</code> → <code>GSSAPI</code> → <code>Allow GSSAPI credential delegation</code>.
 +
 
 +
=== SecureCRT  ===
 +
 
 +
[https://itservices.stanford.edu/service/ess/pc/securecrt SecureCRT] supports GSSAPI authentication, but it is disabled by default. To enable GSSAPI, open the Session Options dialog and select <code>Connection</code> → <code>SSH2</code> → <code>Authentication</code> → <code>GSSAPI</code> and <code>Connection</code> → <code>SSH2</code> → <code>Authentication</code> → <code>Key exchange</code> → <code>Kerberos (Group Exchange)</code>. 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 <code>ssh</code> 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 even after you have closed the initial connection using the <code>ControlPersist</code> option. On macOS and Linux systems you can add the following lines to <code>~/.ssh/config</code> file on your local system to enable multiplexing.
 +
 
 +
ControlMaster auto
 +
ControlPath ~/.ssh/%C
 +
ControlPersist yes
 +
 
 +
Note that while PuTTY and SecureCRT support multiplexing, they do not support <code>ControlPersist</code>, so the feature is of less utility for this purpose on Windows systems.
 +
 
 +
If you'd like to learn more, the OpenSSH Cookbook has a good introduction to [https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing multiplexing].
 +
 
 +
== 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 <code>~/.ssh/config</code> on your local system.
 +
 
 +
ServerAliveInterval 60
=== PuTTY ===
=== PuTTY ===
-
PuTTY supports GSSAPI authentication as of version 0.61; it also attempts to use GSSAPI by default but does not forward tickets. To enable forwarding: select Connection -&gt; SSH -&gt; Auth -&gt; GSSAPI -&gt;&nbsp;'''Allow GSSAPI credential delegation'''.
+
Select <code>Connection</code> → <code>Sending of null packets to keep session active</code> → <code>Seconds between keepalives (0 to turn off) 60</code> and <code>Connection</code> → <code>Low-level TCP connection options</code> → <code>Enable TCP keepalives (SO_KEEPALIVE option)</code>.
 +
 
 +
=== SecureCRT ===
 +
 
 +
In the Session Options dialog, select <code>Terminal</code> → <code>Anti-idle</code> → <code>Send protocol NO-OP every 60 seconds</code>.
 +
 
 +
== Sharing Host Keys ==
 +
 
 +
FarmShare consists of many individual nodes, grouped by function: login (or interactive use), compute, and GPU. Each group of systems shares an SSH host key, and you can configure OpenSSH to cache each of these keys once, and use it whenever you connect to a particular system in a given group, using the <code>HostKeyAlias</code> option. This can save some time when connecting for the first time to any particular system in a group if you've previously connected to another system in that same group.
 +
 
 +
<pre>
 +
Host rice rice.stanford.edu rice?? rice??.stanford.edu
 +
  HostKeyAlias rice.stanford.edu
 +
 
 +
Host wheat?? wheat??.stanford.edu
 +
  HostKeyAlias wheat.stanford.edu
 +
 
 +
Host oat?? oat??.stanford.edu
 +
  HostKeyAlias oat.stanford.edu
 +
 
 +
Host cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
 +
  HostKeyAlias cardinal.stanford.edu
 +
</pre>
 +
 
 +
== Mosh ==
 +
 
 +
[https://mosh.org Mosh] is also supported for interactive terminal sessions. Mosh connections are more responsive under high-latency conditions, and can persist when your network changes or while your computer sleeps. The native Mosh client is available on macOS and Linux; on Windows you can use [https://mobaxterm.mobatek.net MobaXterm] or the [https://chrome.google.com/webstore/detail/mosh/ooiklbnjmhbcgemelgfhaeaocllobloj Mosh extension] for Chrome.
 +
 
 +
== 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.
 +
 
 +
<pre>
 +
# ~/.ssh/config
 +
 
 +
IgnoreUnknown GSSAPIKeyExchange
 +
 
 +
# FarmShare 2
 +
 
 +
Host rice rice?? cardinal cardinal?
 +
  HostName %h.stanford.edu
 +
 
 +
Host rice rice.stanford.edu rice?? rice??.stanford.edu
 +
  HostKeyAlias rice.stanford.edu
 +
 
 +
Host wheat?? wheat??.stanford.edu
 +
  HostKeyAlias wheat.stanford.edu
 +
 
 +
Host oat?? oat??.stanford.edu
 +
  HostKeyAlias oat.stanford.edu
 +
 
 +
Host cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
 +
  HostKeyAlias cardinal.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
-
=== Verifying Credentials ===
+
# All hosts
-
After you successfully connect to the destination host, use '''klist -f''' to see which Kerberos credentials got forwarded.
+
Host *
 +
  ControlPath ~/.ssh/%r@%h:%p
 +
  GSSAPIKeyExchange yes
 +
  GSSAPIAuthentication yes
 +
  ServerAliveInterval 60
 +
</pre>

Latest revision as of 17:56, 1 March 2022

Contents

Public Key Authentication

Public key authentication is not supported on 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

Recent versions of macOS no longer support the GSSAPIKeyExchange option; you can either omit this option or, if you prefer to keep a standard configuration, add the additional option IgnoreUnknown GSSAPIKeyExchange to your ~/.ssh/config file.

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 → AuthGSSAPIAllow GSSAPI credential delegation.

SecureCRT

SecureCRT supports GSSAPI authentication, but it is disabled by default. To enable GSSAPI, open the Session Options dialog and select ConnectionSSH2AuthenticationGSSAPI and ConnectionSSH2AuthenticationKey exchangeKerberos (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 even after you have closed the initial connection using the ControlPersist option. On macOS and Linux systems you can add the following lines to ~/.ssh/config file on your local system to enable multiplexing.

ControlMaster auto
ControlPath ~/.ssh/%C
ControlPersist yes

Note that while PuTTY and SecureCRT support multiplexing, they do not support ControlPersist, so the feature is of less utility for this purpose on Windows systems.

If you'd like to learn more, the OpenSSH Cookbook has a good introduction to multiplexing.

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 ConnectionSending of null packets to keep session activeSeconds between keepalives (0 to turn off) 60 and ConnectionLow-level TCP connection optionsEnable TCP keepalives (SO_KEEPALIVE option).

SecureCRT

In the Session Options dialog, select TerminalAnti-idleSend protocol NO-OP every 60 seconds.

Sharing Host Keys

FarmShare consists of many individual nodes, grouped by function: login (or interactive use), compute, and GPU. Each group of systems shares an SSH host key, and you can configure OpenSSH to cache each of these keys once, and use it whenever you connect to a particular system in a given group, using the HostKeyAlias option. This can save some time when connecting for the first time to any particular system in a group if you've previously connected to another system in that same group.

Host rice rice.stanford.edu rice?? rice??.stanford.edu
  HostKeyAlias rice.stanford.edu

Host wheat?? wheat??.stanford.edu
  HostKeyAlias wheat.stanford.edu

Host oat?? oat??.stanford.edu
  HostKeyAlias oat.stanford.edu

Host cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
  HostKeyAlias cardinal.stanford.edu

Mosh

Mosh is also supported for interactive terminal sessions. Mosh connections are more responsive under high-latency conditions, and can persist when your network changes or while your computer sleeps. The native Mosh client is available on macOS and Linux; on Windows you can use MobaXterm or the Mosh extension for Chrome.

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

IgnoreUnknown GSSAPIKeyExchange

# FarmShare 2

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

Host rice rice.stanford.edu rice?? rice??.stanford.edu
  HostKeyAlias rice.stanford.edu

Host wheat?? wheat??.stanford.edu
  HostKeyAlias wheat.stanford.edu

Host oat?? oat??.stanford.edu
  HostKeyAlias oat.stanford.edu

Host cardinal cardinal.stanford.edu cardinal? cardinal?.stanford.edu
  HostKeyAlias cardinal.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

# All hosts

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