SSH to a NetApp Using Key Based Authentication

EDIT 2014-03-03: An updated post for Clustered Data ONTAP is here.

I find it quite handy to use a *nix server as a management host for my NetApp systems. Using key based authentication and SSH the whole process is easy and secure. With the addition of bash aliases for the hosts, I can even quickly run commands against multiple hosts.

A couple of pre-requesites…you need to have either CIFS or NFS enabled and the root volume exported/shared. Also, you must have SSH enabled. I will refer you to the documentation on how to get these tasks done. I recommend you create a non-root user for any administrators to use for access (for accountability reasons). If you are ok with using root for everything, then don’t execute the following: useradmin user add some_username -g Administrators.

This will work with OnTAP 7 and OnTAP 8 7-mode. I haven’t had the priviledge of using a Clustered OnTAP system at this time, so I don’t know the process.

I use PuTTY to SSH to the *nix host (I prefer RHEL or one of it’s derivitives…CentOS, Oracle Enterprise Linux, Scientific Linux, etc.) from my Windows desktop.

1. Create a SSH key to use:
   
   ssh-keygen -b 2048

   1	ssh-keygen -b 2048

   
   The result should be like the following screen shot.
   
   This will create a directory and two files in your home directory. The directory is ~/.ssh (remember the tilde is a short cut for your home directory in bash), and the two files are ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. The first file is your private key, the second is the public key. These two work in combination to provide a secure way of identifying you (for the curious, this YouTube video shows how Diffie-Hellman key exchange works in a very understandable manner).
2. We need to mount the root file system for the NetApp to the admin host.

   First, make sure that the root file system is exported. If it is not, from the NetApp, export the file system like so: exportfs -io rw=your_admin_host,root=your_admin_host /vol/root_vol. Note that the name of your root volume will probably be different (the default is vol0). Also, this is a temporary mount and will not persist should the NetApp or NFS be restarted.

   Next, we need to mount the file system. I like to use the /mnt folder on my linux host for these operations.

   mkdir -p /mnt/netapp sudo mount your_netapp:/vol/root_vol /mnt/netapp

   1 2	mkdir -p /mnt/netapp sudo mount your_netapp:/vol/root_vol /mnt/netapp

3. Now we configure the NetApp to accept the user’s key. Make sure you use the actual name of the user for the folloing commands, not the stand-in “<username>” I used.

   These commands should be executed as root. You can either su to root, or prepend each command with sudo

   # change to our working directory cd /mnt/netapp/etc/sshd # make a directory with the same name as the user, with a # sub-directory of ".ssh" mkdir -p /.ssh # set permissions on these directories...not necessary (will # work without, but if you export the root volume to non-root # hosts this adds some security) chmod 700 chmod 700 /.ssh # copy the user's public key to the authorized_keys file on the NetApp cat ~/.ssh/id_rsa.pub &gt;&gt; /.ssh/authorized_keys # set permissions on the file chmod 600 /.ssh/authorized_keys

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   # change to our working directory cd /mnt/netapp/etc/sshd   # make a directory with the same name as the user, with a # sub-directory of ".ssh" mkdir -p /.ssh   # set permissions on these directories...not necessary (will # work without, but if you export the root volume to non-root # hosts this adds some security) chmod 700 chmod 700 /.ssh   # copy the user's public key to the authorized_keys file on the NetApp cat ~/.ssh/id_rsa.pub >> /.ssh/authorized_keys   # set permissions on the file chmod 600 /.ssh/authorized_keys

   Take note that this will work with root as well. Additionally, a single user (e.g. root) can have multiple public keys in the authorized_keys file for multiple users…so you do not need to share private keys with multiple users. For accountability/security reasons, I don’t recommend this, but it’s your choice.

4. At this point we have done all the work necessary on the NetApp. You can unmount the root file system using the following: umount /mnt/netapp.

   To test the login, do the following from your *nix admin host: ssh your_netapp. It should connect you to the ssh session console for the NetApp. I have noticed with some versions of OnTAP I have to use a password to authenticate at least once (after each reboot) before it will allow me to use key based authentication.

   Assuming that worked, press ctrl+d to disconnect. Next, let’s try executing a command via ssh: ssh your_netapp version. It should result in the following:

   [Andrew@cent01 ~]$ ssh 192.168.1.20 version NetApp Release 7.3.6: Thu Jul 7 00:41:19 PDT 2011 [Andrew@cent01 ~]$

   1 2 3

   [Andrew@cent01 ~]$ ssh 192.168.1.20 version NetApp Release 7.3.6: Thu Jul  7 00:41:19 PDT 2011 [Andrew@cent01 ~]$

   Notice the command was executed and returned back to the bash session on my admin host. This is EXTREMELY convenient if you are handy with bash commands (e.g. grep, awk, etc.) for getting and manipulating information.

Since things don’t always go as planned, here’s some troubleshooting:

Assuming you have a default SSH configuration it should automatically use the id_rsa private key file in your home directory to authenticate you to the NetApp. If you want to ensure it is using the correct file, specify the -i option to your ssh command: ssh -i ~/.ssh/id_rsa your_netapp.

If the username you are logged into on the admin host is different than the username on the NetApp, use the following: ssh -i ~/.ssh/id_rsa some_user@your_netapp.

If you see a number of messages in the NetApp’s syslog like the following:

It is the result of your ssh client sending unsupported/unneeded environment information to the NetApp. If you are the root for the admin host, you can modify the /etc/ssh/ssh_config file and remove the SendEnv lines from the bottom. If you do not have root on your admin host I’m afraid there’s not much you can do to stop it from sending the bad information…at least it’s harmless.