NCI Help

Page tree

Versions Compared

Old Version 20

changes.mady.by.user Andrew Johnston

Saved on

compared with

New Version 21

changes.mady.by.user Andrew Johnston

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Warning

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.

Panel
borderColor#21618C
bgColor#F6F7F7
titleColor#17202A
borderWidth1
titleBGColor#FFB96A
borderStyleridge
titleOn this page
Panel
borderColor#21618C
bgColor#F6F7F7
titleColor#17202A
borderWidth1
titleBGColor#FFB96A
borderStyleridge
titleSSH Security

SSH Security 

Anchor
SSH Security
SSH Security

  • If you don't sufficiently understand ssh keys, DO NOT USE THEM. Use only passwords and use strong ones - at least 9 characters long, a mixture of alphanumeric and non-alphanumeric characters and of mixed case. The password should be completely different to the password you use on any other system.
  • NEVER copy a private key anywhere! The private key should remain in your .ssh directory on the system you generated it on and should be readable only by you.
  • SSH key passphrases should be as secure as other passwords.
  • Never setup passphraseless ssh keys to allow unauthenticated login access between systems.

Background 

Anchor
Background
Background

On the surface, using SSH keys, with a passphrase, appears no different to using just 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 your responsibility and under your control, not that of the system (local or remote). These differences allows keys to be used in more interesting and flexible ways than passwords, yet still provide security. There are two particular usage patterns that may be of interest to you in making the most of NCI systems:

  • Using ssh agents and agent forwarding to move security all the way back to your desktop. This can greatly ease the burden and improve the security of ssh key usage but, as with all security, still requires discipline and attention to detail. 
  • Using restricted command ssh keys without passphrases for limited functionality remote operations such as for transferring files.

The second of these we will 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.

Using restricted commands for transferring files 
Anchor
restricted
restricted

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, it is not feasible to be relying on entering a password or passphrase at the time of the operation. If the ssh keys are restricted to allow only those remote commands that are 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 done for rsync. On a Linux system, with rsync installed, you will most likely find a file at a similar location to /usr/share/doc/rsync/support/rrsync which is a "restricted rsync command target". 

The general idea is to

  • create special purpose keys on the source system (assumed to be Gadi).
  • setup restricted command in authorized_keys on the target system (assumed to be your home institution).
Panel
borderColor#21618C
bgColor#F6F7F7
titleColor#17202A
borderWidth1
titleBGColor#FFB96A
borderStyleridge
titleProcedure to setup rrsync

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 there but make sure it is executable:

Code Block
themeFadeToGrey
MyDesktop:~ > cp rrsync ~/bin
MyDesktop:~ > chmod +x ~/bin/rrsync

Anchor
setup
setup
Generate restricted command ssh keys on Gadi:

Code Block
themeFadeToGrey
[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:  .... 

The above example is passphrase-less - just hit 'enter' when prompted for a passphrase.

3. 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:

Code Block
themeFadeToGrey
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== dbs900@gadi-login-07.nci.org.au
... 
Note

Things to note

  • The entry has the command, other options and the public key (the bit after ssh-rsa) on the one line. Do not split these.
  • Some of the restrictive options (no-...) may not be available on your system - look at the AUTHORIZED_KEYS FILE FORMAT section on the sshd man page on your system to see what is supported. The more restrictions, the better.
  • The path under which you want data to be stored, /data/archive in this case, is given as an argument to rrsync.

4. On Gadi use something similar to:

Code Block
themeFadeToGrey
$ 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.

Authors: Mohsin Ali, Andrew Wellington