SSH can be configured so that you are not prompted for a password when you ssh to another host when combined with the ssh-agent and ssh-add command.
The UIowa Enterprise Password Policy has strict minimum standards for passwords/passphrases that also apply to SSH keys.
When following the instructions below, it helps to think about the SSH connections in terms of a "client" machine (the machine you're on) and a "server" machine (the machine you're trying to login to). In order to use SSH keys for authentication you will need to generate an SSH key, and the private key will need to be on the source or client side, and public key will need to be on the server side.
If your intention is to create an SSH key for the purpose of accessing the linux.divms.uiowa.edu service, then the SSH key can be created on your desktop or laptop system and the public portion of the key will be copied to the linux.divms.uiowa.edu system.
The alternative is to generate an SSH key on the linux.divms.uiowa.edu server and copy the private portion of the key back to your desktop or laptop system. Depending on the SSH client software you are using this may be more complex.
For the purposes of this document we will assume you intend to create keys on your client desktop or laptop in order to access linux.divms.uiowa.edu.
If you are using SecureCRT on a Windows laptop or desktop, follow the instructions from the vendor for generating keys at Using Public-Key Authentication in Secure Shell Applications.
If you are using the Putty SSH client on a Windows laptop or desktop, follow the instructions at PuTTYgen - Key Generator for PuTTY on Windows
If you are using Linux or MacOS and are comfortable with the command line you can use the following instructions.
Generate a set of private and public keys (on the client machine)
[user@client]% ssh-keygen -t rsa
You will be asked for the file in which to save the key. Take the default by simply pressing the Enter key. You will then be asked for a passphrase. Choose a good passphrase; then type it in again to confirm the passphrase. This will generate you public and private keys. You'll now be prompted for the SSH passphrase instead of your HawkID passhrase when SSHing between hosts. Choosing an empty passphase is not recommended and is a potential security risk.
Make your new public key an authorized key (on the server, or destination machine)
If you are using public key authentication from a host outside of the university, then you will need to copy the contents of ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys. You can use a text editor to do this, or you can use the commands (you'll have to substitute appropriately for hawkid) below:
[user@client]$ ssh-copy-id -i ~/.ssh/id_rsa.pub email@example.com
Make sure your SSH files are not publically readable (on both source and dest machine)
To ensure security, change permissions on your SSH files so that they are not readable by any other user:
chmod og-rwx ~/.ssh/*
Silently handle passphrases in the background using ssh-agent and ssh-add (optional)
This step is completely optional but often convenient. In Unix, ssh-agent is a background program that handles SSH private keys exchanges. The ssh-add command prompts the user for a private key password and adds it to the list maintained by ssh-agent. Once you add a private key passphrase to ssh-agent, you will not be prompted for it when using ssh/slogin or scp to connect to hosts where you've copied your public key as an authorized_keys. All managed Linux hosts have already run the ssh-agent as a part of the login process.
The ssh-agent command below is only required on hosts not managed by the CLAS Linux Group. It only has to by done once (per unique machine login) and is valid until you logout or the ssh-agent process is killed.
[user@client]$ eval `ssh-agent`
The ssh-add is required on both managed and remote hosts. When prompted, enter your private key passphrase generated in step 1. You can also specify a time limit to keep the key in memory, for instance the length of a work day:
[user@client]$ ssh-add -t 9h
When you log out, kill the ssh-agent process (not required on managed hosts, or when you specify a lifetime to keep the key in memory)
[user@client]$ ssh-agent -k
You should now be able to ssh/slogin/scp to remote hosts with out typing in your SSH passphrase for the duration that the ssh-agent process is running.
By-passing port 22/ssh block when off-campus (optional)
The University blocks port 22/ssh at the campus border. This means you need to use the campus VPN product to establish a VPN connection before you can use ssh/slogin/scp from off campus. See Configuring AnyConnect Client for details.
Or, from your remote machine, you can configure ssh/slogin/scp to always connect to an alternate port that the CLAS No Machine servers have SSH listening on to by-pass the port 22 border block. This port may or may not work for other hosts at the University. This will only use work with SSH keys, it will not work with password authentication.
[user@remotehost]% cat << EOF > ~/.ssh/config
This will allow you to type
ssh linux.divms.uiowa.edu instead of
ssh -p 40 linux.divms.uiowa.edu and connect to linux.divms.uiowa.edu with out having to establish a VPN connection. It will also work with the file transfer command scp.
The only CLAS Linux host that listens on port 40 is the host linux.divms.uiowa.edu, NOT the other Linux lab machines, research clusters or any other Linux hosts or servers managed by the CLAS Linux Group.
Learn more about SSH
More information is available by using the man command. Do a man slogin or man ssh-keygen or man ssh or man scp or man ssh-agent or man ssh-add for more information. Additionally this tutorial covers various aspects of SSH and SSH keys: How To Configure SSH Key-Based Authentication on a Linux Server