Advanced Connection Options

From FarmShare

(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
Public key authentication is not supported by FarmShare systems.
Public key authentication is not supported by 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
 +
GSSAPIAuthentication yes
-
Host rice rice?? cardinal cardinal? corn corn?? rye rye??
+
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:
-
    HostName %h.stanford.edu
+
-
Host rice rice?? rice.stanford.edu rice??.stanford.edu corn cardinal cardinal? cardinal.stanford.edu cardinal?.stanford.edu corn?? corn.stanford.edu corn?.stanford.edu rye rye?? rye.stanford.edu rye??.stanford.edu barley?? barley??.stanford.edu
+
-
    GSSAPIDelegateCredentials yes
+
-
Host *
+
-
    GSSAPIKeyExchange yes
+
-
    GSSAPIAuthentication yes
+
-
This configuration should work safely in all common cases.
+
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.
See the <code>man</code> page for <code>ssh_config</code> for more information on GSSAPI options.
Line 27: Line 23:
=== PuTTY  ===
=== PuTTY  ===
-
[http://www.chiark.greenend.org.uk/~sgtatham/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'''.  
+
[http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] supports GSSAPI authentication by default; to enable forwarding, select <code>Connection</code> -&gt; SSH -&gt; <code>Auth</code> -&gt; <code>GSSAPI</code> -&gt; <code>Allow GSSAPI credential delegation</code>.  
-
=== SecureCRT<br> ===
+
=== SecureCRT  ===
-
You can enable GSSAPI authentication in [https://itservices.stanford.edu/service/ess/pc/securecrt SecureCRT's] Session Options dialog, in category Connection -&gt;&nbsp;SSH2. Make sure Authentication -&gt;&nbsp;'''GSSAPI''' and Key exchange -&gt; '''Kerberos (Group Exchange)''' and/or Key exchange -&gt; '''Kerberos''' are checked. SecureCRT attempts authentication and key exchange methods in the order listed, so these methods should be moved to the top of their stacks.<br>
+
[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> -&gt; <code>SSH2</code>-&gt; <code>Authentication</code> -&gt; <code>GSSAPI</code> and <code>Connection</code> -&gt; <code>SSH2</code> -&gt; <code>Authentication</code> -&gt; <code>Key exchange</code> -&gt; <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.
-
=== Verifying Credentials  ===
+
== Two-step Authentication ==
-
After you successfully connect to the destination host, use <code>klist -f</code> to see which Kerberos credentials got forwarded.
+
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 using <code>ControlPersist</code>, even after you have closed the initial connection. Add the following lines to <code>~/.ssh/config</code> file on your local system to enable multiplexing.
-
== Two-factor Authentication ==
+
ControlMaster auto
 +
ControlPath ~/.ssh/%r@%h:%p
 +
ControlPersist yes
-
Add the following lines to your <code>~/.ssh/config</code> file on your local machine (not on FarmShare) to enable ControlMaster which will create a tunnel on your first login, and will re-use the same tunnel on subsequent connections, thus avoiding 2-step after the initial connection. This will only work if you are logging into the same node to which the tunnel was established.
+
PuTTY and SecureCRT support multiplexing, but do not support <code>ControlPersist</code>, so the feature is of less utility on Windows systems.
-
+
-
Host rice rice?? rice.stanford.edu rice??.stanford.edu corn corn?? corn.stanford.edu corn??.stanford.edu
+
-
  ControlMaster auto
+
-
  ControlPath ~/.ssh/%r@%h:%p
+
-
  ControlPersist yes
+
== Keep-alive ==
== Keep-alive ==
-
You can actively keep a session alive by adding the following line to any Host statement:
+
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
  ServerAliveInterval 60
 +
 +
=== PuTTY ===
 +
 +
Select <code>Connection</code> -&gt; <code>Sending of null packets to keep session active</code> -&gt; <code>Seconds between keepalives (0 to turn off) 60</code> and <code>Connection</code> -&gt; <code>Low-level TCP connection options</code> -&gt; <code>Enable TCP keepalives (SO_KEEPALIVE option)</code>.
 +
 +
=== SecureCRT ===
 +
 +
In the Session Options dialog, select <code>Terminal</code> -&gt; <code>Anti-idle</code> -&gt; <code>Send protocol NO-OP every 60 seconds</code>.
 +
 +
== 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.
 +
 +
# 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

Revision as of 15:08, 24 August 2017

Contents

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. 

# 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
Retrieved from "https://web.stanford.edu/group/farmshare/cgi-bin/wiki/index.php/Advanced_Connection_Options"
Personal tools
Toolbox
LANGUAGES