Accessing Kerberized Machines (Fermilab-Supported Methods)
Intended for:
Kerberos users.
Scenario/Use case:
This article provides instructions on how to access systems in the FNAL.GOV realm from UNIX and Windows machines using the methods recommended and supported by the Fermilab Computing Sector. We cover logging in at the console, connecting over the network, and using RSA SecurID tokens with portal mode.
Instructions:
Very important note: Any time you're about to enter your Kerberos password, first verify that you're using the host's directly-connected keyboard! If necessary, you may transmit your password over an encrypted network connection, but this is discouraged if at all possible. See Encrypted vs. Unencrypted Connections for more information.
Logging In at the Console of a Kerberized UNIX Machine
Using Standard UNIX Login Program
If your desktop is running the standard login program, log in at the console normally, entering your standard local UNIX account password. The standard login program does not accept your Kerberos password. You need to run kinit after logging in to obtain your credentials. The credentials should then get forwarded to other strengthened machines normally (default in the standard Fermilab Kerberos and OpenSSH configurations is to forward your credentials). If you need an address-less ticket, use the -A option (see section kinit).
Using Kerberos Login Program
If your desktop is configured to use PAM for login authentication and the pam_krb5 module is installed, you can enter your Kerberos password at the password prompt. You do not need to run kinit after such a login. You can still login using your local UNIX account password, then run kinit to get Kerberos tickets, if you wish. PAM with the pam_krb5 module is standard in Scientific Linux Fermi allowing use of either your local account password or Kerberos password to login (assuming your local username and principal name are identical).
If you don't have a principal yet...
Note that if you have an account and a standard UNIX password on a machine (in the passwd file or NIS map) but no principal or Kerberos password, you can still log in at the console. (From any terminal other than the console, the Kerberized machine looks for existing Kerberos credentials, and responds in portal mode if none are found; you have no option to enter your UNIX password.) However, once logged in, you cannot make outbound connections from there since Kerberized services are unavailable to you.
Connecting from One Kerberized Machine to Another
Make sure you have forwardable credentials on your desktop machine, then run the Kerberized version of the connection program you want to use (ssh, or scp) to connect and forward your credentials to the target machine. Forwarding is described in section Forwarding Tickets. The Kerberized features of these programs are described in Network Programs Available on Kerberized Machines. Strictly speaking, forwarding of credentials is not necessary for login to a remote system unless you use some other Kerberized service there (such as ssh).
Assuming your credentials get forwarded to the target machine, you should be automatically recognized and authenticated there; you should not be prompted for your Kerberos password.
A few notes:
- If the usernames on the machines differ, use the -l <login_name_on_target_host> option; e.g., ssh -l <login_name_on_target_host>.
- If ticket forwarding has been set "off" for your system, and you want to connect to a Kerberized machine with ticket forwarding turned on, use the appropriate option, e.g., -f or -F.
- If ticket forwarding has been set "on" for your system, and you want to connect to a Kerberized machine with ticket forwarding turned off, use the appropriate option, e.g., -k for Kerberized ssh. Forwarding is described in section Forwarding Tickets.
Warning! If your on-site Kerberized system accepts a login password over the network (even on an encrypted connection), this is a violation of the Fermilab Policy on Computing.
Connecting via Kerberized SSH
Any machines that are on-site at FNAL and that wish to use ssh are required to use Kerberized ssh. Non-Kerberized ssh is not permitted on these machines.
With both kerberos and Kerberized ssh installed on your machine, make sure you have a Kerberos ticket, then run the Kerberized version of the connection program you want to use (e.g., ssh, slogin, or scp) to connect to a remote Kerberized host. The Kerberized options for these programs are described in Network Programs Available on Kerberized Machines. You do not get prompted for your Kerberos password during login.
ssh encrypts the connection by default, typically (check your configuration in /etc/ssh/ssh_config or your personal configuration in $HOME/.ssh/ssh_config to make sure that the Cipher or Ciphers parameters are not disabling encryption) you can always use the -c <cipher> option to ensure encryption.
Connecting from Home (Off-Site)
Many people connect from home using high speed internet access through a local area router, and in many cases their ISP subjects them to NAT (Network Address Translation). We discuss NAT in the section Network Address Translation. In these cases you will need address-less Kerberos tickets. When obtaining your credentials with kinit, include the qualifier -A. See section kinit for more information.
If you are using the VPN (Virtual Private Network) to connect to Fermilab, then you do not need address-less Kerberos tickets even if your ISP is using NAT. This happens because the VPN tunnel gives your system an on-site Fermilab IP address which is used to access any other Fermilab IP address. In this case, you can obtain your Kereros credentials without using the -A option on the kinit command.
Connecting from a Non-Kerberized Machine: Portal Mode and Gateway Systems
If your local desktop computer does not run Kerberos software and is not configured for the FNAL.GOV realm, then you can't authenticate to FNAL.GOV locally on this computer. You can work on the desktop with no problem, but in order to connect over the network to Kerberized UNIX hosts, you must authenticate to FNAL.GOV first.
Some Kerberized machines in the FNAL.GOV realm are configured to require entry of a single-use password whenever they receive a login request coming from an un-Kerberized computer over the network. (The password gets transmitted over the network, and it could get intercepted. That's why it must be valid for only one login.) The target computer is said to be a gateway system and to respond in portal mode in this case. It is acting as a secure gateway into the strengthened realm.
How do you get a single-use password that Kerberos will recognize and honor? Some gateway systems at Fermilab (in particular, the recommended general purpose gateway systems is FNALU) are set up to use RSA SecurID Tokens to provide these single-use passwords only with OpenSSH connections.
Once you've logged on successfully to the gateway system, you must obtain Kerberos credentials in order to connection to other FNAL systems and services. You do this by using kinit on the gateway system (be sure you are using an encrypted SSH tunnel).
Logging into a UNIX Account that's not your own
If you wish to log into an account for which the username is different from your principal name (e.g., a group or shared account), your principal (including the Kerberos realm) must be listed in either the .k5login or the .k5users file (ksu only) of the target account. See note The .k5login File.
First log in to your own account on a Kerberized machine and obtain credentials as usual, then connect to the target account after you're authenticated. If the target account is on a different machine, simply connect to that machine using one of the Kerberized connection utilities, and use the -l <login_name> option where <login_name> is the target account name. If the account is on the same machine, use ksu <login_name>.
Logging In Through PuTTY (SSH) from Windows
PuTTY is a terminal emulator program which supports Kerberized ssh. The PuTTY package also includes the command line programs plink, pscp, and psftp. These are similar to the Linux ssh (when used to execute a command on a remote system), scp , and sftp commands. See Installing and Configuring PuTTY on a Windows System for information on setting up PuTTY's Default Settings for use in the Fermilab environment. Complete documentation for PuTTY is available from the PuTTY Docs page in a variety of downloadable formats as well as an online HTML version. Additionally, Fermilab community-supported instructions for configuring and using PuTTY with Windows are available here.
Note: When using your Windows system to log into a Linux or Macintosh system, you will probably (depending upon how you have configured your Network Identity Manager identities) want to have your FERMI Domain principal, user@FERMI.WIN.FNAL.GOV, in the .k5login files of the systems you are going to access (as well as your user@FNAL.GOV principal). See note The .k5login File for further information.
For instructions on how to setup and configure MIT Kerberos for Windows, see note Installing MIT Kerberos for Windows.
Run an interactive SSH Terminal Session to a Kerberized Host
- Start the PuTTY application. The PuTTY Configuration window will appear.
- In the Session section, type your destination hostname in the Host Name box. You can also type username@hostname if you are logging in as a different user.
- Click the Open button to log in. If you don't already have a valid Kerberos ticket, a dialog will pop up asking for your Kerberos username and password.
- You can also enter a name in the Saved Sessions box and click the Save button for future use. To use a saved session, click on the session name in the Saved Sessions list to select and then click on the Load and then the Open buttons.
From the Windows command line, run a command on a remote Kerberized Host
PuTTY plink is a command line application that allows for interactive logins from a command window or to execute commands on a remote system (useful for automated processes and scripting). Documentation on Using Plink is available online with a complete list of command line options. The basic command to run a command on another system is (see the plink documentation for a complete list of options):
plink -ssh -batch [user@]host command
The -ssh option guarantees that the SSH protocol is used, it is not needed if you have configured PuTTY with Kerberized SSH as your Default Session. The -batch option is useful for automated processes and scripts, it disables all interactive prompts and instead causes the plink command to fail if there is a problem. You can also specify the username for the remote system by using the "-l user" option or by pre-pending the username to the hostname as in "user@host" similar to the ssh command under Linux or the Macintosh. If you have setup a Saved Session in PuTTY, you can use that session name in place of the hostname.
From the Windows command line, copy files to/from a remote Kerberized Host
PuTTY pscp is a command line application that provides for secure file transfers to/from other systems. Documentation on Using Pscp is available online with a complete list of command line options. The basic command to copy a file from a remote system to the local system (see the pscp documentation for a complete list of the options):
pscp -batch [user@]host:sourcefile targetfile
The -batch option is useful for automated processes and scripts, it disables all interactive prompts and instead causes the plink command to fail if there is a problem. You can also specify the username for the remote system by using the "-l user" option or by pre-pending the username to the hostname as in "user@host" similar to the scp command under Linux or the Macintosh. Similarly, the basic command to copy a local file to a remote system is:
pscp -batch sourcefile [user@]host:targetfile
You can use wildcards in the sourcefile to copy multiple files to the target (works best if the targetfile just specifies a directory). You can also list multiple source files on the command:
pscp -batch sourcefile [sourcefile...] [user@]host:targetfile
Examples to copy the /etc/hosts file from node hornflogger as user nagy to a local temporary file and to copy a local file to the temporary directory on hornflogger are shown here:
pscp -batch nagy@hornflogger:/etc/hosts C:\Windows\temp\hornflogger-hosts.txt
pscp -batch C:\Documents\foe.txt nagy@hornflogger:/tmp/fie.txt
You can also use pscp to get a directory list of a file or an entire directory on a remote system:
pscp -ls [user@]host:filespec