WARNING: Incorrectly configuring ssh keys can leave your accounts vulnerable to attack and, more importantly, can provide attackers with a trivial means to transfer their attacks to other systems and organizations. Organizations you are affiliated with may require you to maintain certain standards of personal IT security to help limit the risk of their systems being compromised. Please consult their IT security policies and staff. Regardless of policy, you should consider it your responsibility to help avoid the compromise of any system you have been given access to by deploying safe IT security practices.
Using SSH keys in the simplest way (with a passphrase) appears, superficially, no different to not using keys at all, i.e. just using a password. One difference is that the ssh private security token is at the source end, not at the remote destination - along with the authentication method, this means keys are much harder to brute-force attack. Another difference is that the keys are under your control and are your responsibility, not that of the system (local or remote). These differences allows keys to be used in more interesting and flexible ways than passwords and still provide security. There are two particular usage patterns that may be of interest to you in making the most of NCI systems:
It is the second of these we cover in detail below. Note that it is easy to unwittingly subvert SSH security if you are not careful when setting up restricted commands. Seek advice if you are unsure.
NCI users often have chained workflows requiring automated transferring of files to or from remote systems or performing other operations on those systems. Since the scheduling of these operations is driven by a batch controlled workflow, relying on entering a password or passphrase at the time of the operation is not feasible. If the ssh keys are restricted to allow only those remote commands needed for the file transfers, then passphraseless keys can be used with some degree of security.
Usually, you are unaware of what commands are executed at the remote end when using a file transfer utility. Finding out what those commands are and configuring ssh to use them securely is, generally, non-trivial. Fortunately, the work has already been for
rsync. On Linux system with
rsync installed you will most likely find a file called something like /usr/share/doc/rsync/support/rrsync which is a "restricted rsync command target". Its certainly on Gadi.
The general idea is:
Make sure perl and
rrsync are installed on the destination host for the file transfers. You can just put
rrsync in your personal bin directory there but make sure its executable:
MyDesktop:~ > cp rrsync ~/bin MyDesktop:~ > chmod +x ~/bin/rrsync
Generate restricted command ssh keys on Gadi:
[dbs900@gadi-login-07 ~]$:~/.ssh > ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/900/dbs900/.ssh/id_rsa): /home/900/dbs900/.ssh/id_rsa_file_transfer Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/900/dbs900/.ssh/id_rsa_file_transfer. Your public key has been saved in /home/900/dbs900/.ssh/id_rsa_file_transfer.pub. The key fingerprint is: ....
Yes, that was passphrase-less - just hit return when prompted for a passphrase.
Add the id_rsa_file_transfer.pub public key to the authorized_keys file on the file transfer target host but only with a restricted command prefix:
MyDesktop:~/.ssh > cat authorized_keys ... from="gadi-dm*.nci.org.au,gadi*.nci.org.au",command="~/bin/rrsync /data/archive",no-port-forwarding,no- X11-forwarding,no-agent-forwarding,no-pty,no-user-rc ssh-rsa AAAAB3N ... ynuw== firstname.lastname@example.org ...
Things to note:
On Gadi use something like:
rsync -vrlpt ./ExpDir/ -e "ssh -i $HOME/.ssh/id_rsa_file_transfer" MyDesktop.myuni.edu.au:ExpDir
to archive a directory on Gadi to a directory on the remote system under the nominated archive directory there.