It does not require a reboot. What likely happened was that the keys had not replicated across the cluster properly. A reboot probably just kicked that into gear.

Similar to bug 825392.

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Alexander Griesser Sent: Monday, July 14, 2014 11:50 AM To: April Cc: toasters@teaparty.net Subject: AW: SSH Public Key Authentication in Clustered Data OnTap

Hi April,

thanks, I’ve done that already and followed the instructions to the T – but I replaced the username „monitor“ in the example with „admin“, which is what I wanted to achieve actually. But as several others already pointed out: Logging in with admin + public key does not seem to work, creating a new user and uploading the key there worked – I tried that yesterday.

Now the funny thing is: When I logged in to the filer _TODAY_ (after I’ve rebooted it, because it’s a new filer and I had to recable some things), I could successfully authenticate myself with the SSH public key now, so it seems that a reboot of the controller is needed to alllow SSH authentication using public keys for the admin account…

So, thanks, got it sorted actually by means of a reboot :-/ Would be interesting to see if anyone else can confirm that a reboot really fixes it ☺

best,

Alexander Griesser System-Administrator

ANEXIA Internetdienstleistungs GmbH

E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: April [mailto:aprilogi@yahoo.com] Gesendet: Montag, 14. Juli 2014 03:32 An: Alexander Griesser Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: SSH Public Key Authentication in Clustered Data OnTap

Hello Alexander:

Try looking at kb.netapp.comhttp://kb.netapp.com KB1012542

This KB has a youtube video that demonstrates the procedure It might help.

From what I see below, you create a username admin for your ssh login but you might want to use a different login name so that you don't confuse it with admin.

You might check your LIF to see if the LIF allows for the ssh protocol. Generally, the mgmt LIF will do so.

Just a few thing but see if the KB helps.

--April

Sent from my iPad

On Jul 13, 2014, at 4:25 PM, Alexander Griesser <ag@anexia.atmailto:ag@anexia.at> wrote: Hey there,

I’ve tried to set up SSH public key authentication on a new cluster pair (8.2.1P1) today and failed miserably – has anyone configured that as of yet?

What I’ve done (and what seems to be the correct procedure) is:

security login create -username admin -application ssh -authmethod publickey -role admin -vserver CLUSTERNAME security login publickey create -vserver CLUSTERNAME -username admin -index 0 -publickey "ssh-rsa AAAAB3....C8=" -comment ANEXIA

The resulting configuration looks like that:

::> security login show -application ssh

Vserver: CLUSTERNAME Authentication Acct UserName Application Method Role Name Locked ---------------- ----------- -------------- ---------------- ------ admin ssh password admin no admin ssh publickey admin - 2 entries were displayed.

::> security login publickey show

Vserver: CLUSTERNAME UserName: admin Index: 0 Public Key: ssh-rsa AAAAB3....C8= Fingerprint: a7:08:e1:0d:22:ea:59:97:f9:3e:5c:1d:2a:84:ec:40 Bubblebabble fingerprint: xokel-...-soxex Comment: ANEXIA

But when I try to login using username „admin“ and my private key (which works on hundreds of other boxes and also on all of my 7-mode filers), the filer just seems to refuse my key and prompts me for the password.

Also (maybe unrelated), when logging in via SSH, I do always get this warning message:

Could not chdir to home directory /var/home/admin: No such file or directory

Getting this on two Clustered Data Ontap systems so far, both running 8.2.1.

Thanks,

Alexander Griesser System-Administrator

ANEXIA Internetdienstleistungs GmbH

E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

Public report is pending for it.

Just click “watch this bug” for updates.

From: Alexander Griesser [mailto:ag@anexia.at] Sent: Monday, July 14, 2014 12:28 PM To: Parisi, Justin; April Cc: toasters@teaparty.net Subject: AW: SSH Public Key Authentication in Clustered Data OnTap

Hi,

is this a private bug?

[cid:image001.png@01CF9F62.9275D180]

I just tried it on a second filer today where I’ve created the home directories first and I think _THIS_ was the problem, because the authorized_keys get stored in the home directory of this user and since this directory did not exist earlier, it couldn’t save the keys there:

%pwd /var/home/admin/.ssh %ls -la total 6 drwxr-xr-x 2 admin nogroup 512 Jul 14 18:25 . drwxr-xr-x 3 admin nogroup 512 Jul 14 18:26 .. -rw-r--r-- 1 root nogroup 210 Jul 14 18:25 authorized_keys %

So I think these two issues were actually related – if you do not have a home directory (and the default admin user sometimes (in my tests, everytime) comes without one on recent filer shipments), the filer is unable to store the public keys to the authorized_keys file in this users $HOME/.ssh.

best,

Alexander Griesser System-Administrator

ANEXIA Internetdienstleistungs GmbH

E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: Parisi, Justin [mailto:Justin.Parisi@netapp.com] Gesendet: Montag, 14. Juli 2014 17:59 An: Alexander Griesser; April Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: RE: SSH Public Key Authentication in Clustered Data OnTap

It does not require a reboot. What likely happened was that the keys had not replicated across the cluster properly. A reboot probably just kicked that into gear.

Similar to bug 825392.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Alexander Griesser Sent: Monday, July 14, 2014 11:50 AM To: April Cc: toasters@teaparty.netmailto:toasters@teaparty.net Subject: AW: SSH Public Key Authentication in Clustered Data OnTap

Hi April,

thanks, I’ve done that already and followed the instructions to the T – but I replaced the username „monitor“ in the example with „admin“, which is what I wanted to achieve actually. But as several others already pointed out: Logging in with admin + public key does not seem to work, creating a new user and uploading the key there worked – I tried that yesterday.

Now the funny thing is: When I logged in to the filer _TODAY_ (after I’ve rebooted it, because it’s a new filer and I had to recable some things), I could successfully authenticate myself with the SSH public key now, so it seems that a reboot of the controller is needed to alllow SSH authentication using public keys for the admin account…

So, thanks, got it sorted actually by means of a reboot :-/ Would be interesting to see if anyone else can confirm that a reboot really fixes it ☺

best,

Alexander Griesser System-Administrator

ANEXIA Internetdienstleistungs GmbH

E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Von: April [mailto:aprilogi@yahoo.com] Gesendet: Montag, 14. Juli 2014 03:32 An: Alexander Griesser Cc: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: Re: SSH Public Key Authentication in Clustered Data OnTap

Hello Alexander:

Try looking at kb.netapp.comhttp://kb.netapp.com KB1012542

This KB has a youtube video that demonstrates the procedure It might help.

From what I see below, you create a username admin for your ssh login but you might want to use a different login name so that you don't confuse it with admin.

You might check your LIF to see if the LIF allows for the ssh protocol. Generally, the mgmt LIF will do so.

Just a few thing but see if the KB helps.

--April

Sent from my iPad

On Jul 13, 2014, at 4:25 PM, Alexander Griesser <ag@anexia.atmailto:ag@anexia.at> wrote: Hey there,

I’ve tried to set up SSH public key authentication on a new cluster pair (8.2.1P1) today and failed miserably – has anyone configured that as of yet?

What I’ve done (and what seems to be the correct procedure) is:

security login create -username admin -application ssh -authmethod publickey -role admin -vserver CLUSTERNAME security login publickey create -vserver CLUSTERNAME -username admin -index 0 -publickey "ssh-rsa AAAAB3....C8=" -comment ANEXIA

The resulting configuration looks like that:

::> security login show -application ssh

Vserver: CLUSTERNAME Authentication Acct UserName Application Method Role Name Locked ---------------- ----------- -------------- ---------------- ------ admin ssh password admin no admin ssh publickey admin - 2 entries were displayed.

::> security login publickey show

Vserver: CLUSTERNAME UserName: admin Index: 0 Public Key: ssh-rsa AAAAB3....C8= Fingerprint: a7:08:e1:0d:22:ea:59:97:f9:3e:5c:1d:2a:84:ec:40 Bubblebabble fingerprint: xokel-...-soxex Comment: ANEXIA

But when I try to login using username „admin“ and my private key (which works on hundreds of other boxes and also on all of my 7-mode filers), the filer just seems to refuse my key and prompts me for the password.

Also (maybe unrelated), when logging in via SSH, I do always get this warning message:

Could not chdir to home directory /var/home/admin: No such file or directory

Getting this on two Clustered Data Ontap systems so far, both running 8.2.1.

Thanks,

Alexander Griesser System-Administrator

ANEXIA Internetdienstleistungs GmbH

E-Mail: ag@anexia.atmailto:ag@anexia.at Web: http://www.anexia.athttp://www.anexia.at/

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

Yes, you can.

It really depends on the cause of the issue. Sometimes it's the keys themselves not replicating. Sometimes it's the database.

If it's the keys themselves, you can manually copy them from node to node. If it's the database, you would need to look into why the database is not replicating, as it could be a cluster network issue or a larger prevailing problem.

Reboots are sometimes faster than trying to figure out what is broken, but you can fix pretty much anything in cDOT before needing to reboot. Generally, reboots are only needed for issues with the node level portion of the cluster.

-----Original Message----- From: John Stoffel [mailto:john@stoffel.org] Sent: Monday, July 14, 2014 3:39 PM To: Parisi, Justin Cc: Alexander Griesser; April; toasters@teaparty.net Subject: RE: SSH Public Key Authentication in Clustered Data OnTap

Justin> It does not require a reboot. What likely happened was that the Justin> keys had not replicated across the cluster properly. A reboot Justin> probably just kicked that into gear.

Can you force replication across the cluster by hand? I'm just getting ready to go with Clustered OnTap 8.2.x (and the week long class in about a month) and I'd like to know about gotchas like this.

John