Ditching Passwords: Public-Key Authentication on NetApp Filers

Password-based SSH access to storage controllers is one of those legacy conveniences that quietly becomes a liability. Every automation script, monitoring job, or backup workflow that shells out to a NetApp filer with an embedded password is a credential waiting to leak, rotate poorly, or get stuck in a config management repo. If you manage a fleet of ONTAP clusters alongside Linux hosts, moving to public-key authentication is a small change with an outsized payoff: no more plaintext credentials in cron jobs, no more password expiry breaking automation, and a cleaner audit trail of exactly which key touched which system.

Here’s how to do it cleanly on ONTAP, using the admin user as an example, though the same approach applies to any role-based service account.

Step 1: Audit the current authentication methods

Before changing anything, check what’s already configured for the account:

usnetapp07::> security login show -user-or-group-name admin

Vserver: usnetapp07
                                                                 Second
User/Group                 Authentication                 Acct   Authentication
Name           Application Method        Role Name        Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
admin          amqp        password      admin            no     none
admin          console     password      admin            no     none
admin          http        cert          admin            -      none
admin          http        password      admin            no     none
admin          ontapi      cert          admin            -      none
admin          ontapi      password      admin            no     none
admin          service-processor password admin           no     none
admin          ssh         password      admin            no     none
8 entries were displayed.

This lists every application (ssh, http, ontapi, console, service-processor, amqp) and its authentication method. On a stock system, ssh typically shows password only. You want to add publickey alongside it — not replace it outright — until you've verified the new method actually works.

Step 2: Create the SSH login method entry

usnetapp07::> security login create -user-or-group-name admin -application ssh -authentication-method publickey -role admin

ONTAP will immediately warn you that no public key exists yet for this method — that’s expected. This step just registers that publickey is a valid authentication path for admin over ssh; it doesn't attach a key.

Step 3: Generate a key pair on the Linux side

Get sahil suri’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

On the host that will connect to the filer (your automation server, jump box, or admin workstation), generate a dedicated key pair rather than reusing a personal one:

ssh-keygen -t rsa -b 2048 -f ~/.ssh/netapp_admin -C "root@jumphost"

Keep the private key protected with appropriate file permissions (600) and restrict which hosts can use it if you're centralizing key management.

Step 4: Upload the public key to ONTAP

usnetapp07::> security login publickey create -username admin -index 0 -publickey "ssh-rsa AAAA... root@jumphost"

The -index value matters if you plan to support multiple keys per user — for example, rotating in a new key before retiring an old one. Index 0 is simply the first slot.

Step 5: Verify and test

Re-run the audit command:

usnetapp07::> security login show -user-or-group-name admin

Vserver: usnetapp07
                                                                 Second
User/Group                 Authentication                 Acct   Authentication
Name           Application Method        Role Name        Locked Method
-------------- ----------- ------------- ---------------- ------ --------------
admin          amqp        password      admin            no     none
admin          console     password      admin            no     none
admin          http        cert          admin            -      none
admin          http        password      admin            no     none
admin          ontapi      cert          admin            -      none
admin          ontapi      password      admin            no     none
admin          service-processor password admin           no     none
admin          ssh         password      admin            no     none
admin          ssh         publickey     admin            -      none
9 entries were displayed.

You should now see a new row: admin ssh publickey admin - none, alongside the original password entry. Test the connection from your Linux host:

ssh -i ~/.ssh/netapp_admin admin@usnetapp07

If it drops you into the cluster shell without a password prompt, the key is working.

Step 6: Decide on the password entry

At this point you have both password and publickey active for ssh. Whether you remove the password method entirely depends on your environment's policy — some shops keep it as a break-glass fallback secured separately, others enforce key-only access for compliance. Either way, the decision should be deliberate, not left as a default.

A few practical notes from the field: keep key indexes and comments (-C in ssh-keygen) descriptive — root@jumphost tells you exactly which host owns that key when you're staring at an audit report months later. And if you're managing this across dozens of clusters, script the security login publickey create step through your configuration management tool rather than doing it by hand each time — it's the same command whether you run it once or a hundred times, and consistency here is what actually makes the security improvement scale.