ssh works on one data lif, but not another

[drayfus]

I have added public keys to a user on a particular vserver that has 4 data lifs.  When the user issues an ssh command against the first data lif, they are prompted for the password, but when they issue it against the second data lif they are not prompted for the password.  Each data lif has the same firewall policy.  Any ideas or suggestions on what to check?

Thanks

[SpindleNinja]

just to clarify "when they issue it against the second data lif they are not prompted for the password."   do you mean they don't get connected or it just goes right in?   

can you post the output of 

net int show -vserver SVM_name -fields role,data-protocol,status-oper,firewall-policy

[TMACMD]

Might need to check the ssh command with lots of verbosity from the client connection

 ssh -vvv user@lif_ip

 compare outputs

 maybe duplicated IP for the failing one?

[drayfus]

ssh for the second data lif just goes right in and executes the command.

All the LIFs have the same data and firewall policies:

net int show -vserver gq1-cbdbnfs -fields role,data-protocol,status-oper,firewall-policy

  (network interface show)

vserver     lif             role data-protocol status-oper firewall-policy

----------- --------------- ---- ------------- ----------- ---------------

gq1-cbdbnfs gq1-cbdbnfs-001 data nfs,cifs      up          data            

gq1-cbdbnfs gq1-cbdbnfs-001-s

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-001-s2

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-002 data nfs,cifs      up          data            

gq1-cbdbnfs gq1-cbdbnfs-002-s

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-002-s2

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-003 data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-003-s

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-003-s2

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-004 data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-004-s

                            data nfs,cifs,fcache

                                               up          data            

gq1-cbdbnfs gq1-cbdbnfs-004-s2

                            data nfs,cifs,fcache

                                               up          data            

12 entries were displayed.

[drayfus]

I found the following error in the messages files:

00001379.001b3af9 086f94fe Tue Mar 03 2020 12:30:13 -08:00 [auth_sshd:info:76694] Authentication refused: bad ownership or modes for directory /var/home/oracle
00001379.001b3afa 086f94fe Tue Mar 03 2020 12:30:13 -08:00 [auth_sshd:error:76694] error: auth2-pubkey.c:sshd_report_login_failure:1173:Login Failure: user = oracle, vserverID = 3, authmethod = publickey, application = ssh-connection,\tlocalip = 10.213.174.29, remoteip = 10.248.210.8

This user only exists on the SVM and not on the admin vserver.  Any suggestions?  

[Ontapforrum]

Hi,

Just looking at the error, it may just be an nix* permission thing, may be nothing to do with NetApp.

Found few pointers googling around this error:

"Authentication refused: bad ownership or modes for directory /var/home/oracle"

Possible cause: SSH doesn’t like it if your home (or ~/.ssh directories) have group write permissions.

I see oracle in the 'home' dir path ?

Have you given a try,  steps from the article below:
Your home directory should be writable only by you, ~/.ssh should be 700

:>chmod 700 /var/home/oracle

or,

Add 'StrictModes off' to your ssh_config file

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

Thanks!

[drayfus]

This turned out to be an issue where the underlying vserver user ids got mixed up.  Netapp had to go into the vserver and chown the user dir and chmod the user's homedir as well as .ssh.