Authentication Error

Hi All,

I need help on my suse system. I am getting this error and i can’t run script that require me to ssh from another system to this system. Error logs as below. Any advise?

Oct 9 00:13:14 my00bkeb-p sshd[17257]: Accepted publickey for nagios from 145.64.127.130 port 33632 ssh2
Oct 9 00:13:14 my00bkeb-p sudo: nagios : TTY=unknown ; PWD=/home/nagios ; USER=root ; COMMAND=/etc/init.d/apache2 status
Oct 9 00:13:30 my00bkeb-p sshd[17309]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:30 my00bkeb-p sshd[17309]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:30 my00bkeb-p sshd[17312]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:30 my00bkeb-p sshd[17309]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:30 my00bkeb-p sshd[17312]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:31 my00bkeb-p sshd[17312]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:31 my00bkeb-p sshd[17318]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:31 my00bkeb-p sshd[17318]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:31 my00bkeb-p sshd[17318]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:33 my00bkeb-p sshd[17324]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:34 my00bkeb-p sshd[17324]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:34 my00bkeb-p sshd[17324]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:34 my00bkeb-p sshd[17329]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:34 my00bkeb-p sshd[17329]: error: PAM: Authentication failure for eccroot from 145.64.127.130
Oct 9 00:13:34 my00bkeb-p sshd[17329]: error: PAM: Authentication failure for eccroot from 145.64.127.130

Regards
Wan

It would help a lot to know which version of SUSE you are using. Can you post the output of this command

$ cat /etc/*release*

The problem is that the user eccroot cannot log in to my00bkeb-p via ssh, correct?

Hi mikewillis,

Thanks for replying.

Below is the output.

my00bkeb-p:/etc # cat /proc/version
Linux version 2.6.16.60-0.23-bigsmp (geeko@buildhost) (gcc version 4.1.2 20070115 (SUSE Linux)) #1 SMP Thu May 15 06:38:31 UTC 2008

my00bkeb-p:/etc # cat /etc/issue

Welcome to SUSE Linux Enterprise Server 10 SP2 (i586) - Kernel \r (\l).

We are able to log in via ssh manually but when i tried using script that is built in we got below error message.

Executing /etc/rc.eptos-sopr/init.d/bke_soprano stop

Permission denied (publickey,keyboard-interactive) .
Permission denied (publickey,keyboard-interactive) .

Below are my sshd_config and ssh_config output for your reference.

my00bkeb-p:/etc/ssh # cat sshd_config

$OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

This is the sshd server system-wide configuration file. See

sshd_config(5) for more information.

This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

The strategy used for options in the default sshd_config shipped with

OpenSSH is to specify options with their default value where

possible, but leave them commented. Uncommented options change a

default value.

#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h
#ServerKeyBits 768

Logging

obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH
#LogLevel INFO

Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

similar for protocol version 2

#HostbasedAuthentication no

Change to yes if you don’t trust ~/.ssh/known_hosts for

RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

Don’t read the user’s ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no
#PermitEmptyPasswords no

Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

Set this to ‘yes’ to enable support for the deprecated ‘gssapi’ authentication

mechanism to OpenSSH 3.8p1. The newer ‘gssapi-with-mic’ mechanism is included

in this release. The use of ‘gssapi’ is deprecated due to the presence of

potential man-in-the-middle attacks, which ‘gssapi-with-mic’ is not susceptible to.

#GSSAPIEnableMITMAttack no

Set this to ‘yes’ to enable PAM authentication, account processing,

and session processing. If this is enabled, PAM authentication will

be allowed through the ChallengeResponseAuthentication mechanism.

Depending on your PAM configuration, this may bypass the setting of

PasswordAuthentication, PermitEmptyPasswords, and

“PermitRootLogin without-password”. If you just want the PAM account and

session checks to run without PAM authentication, then enable this but set

ChallengeResponseAuthentication=no

UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

no default banner path

#Banner /some/path

override default of no subsystems

Subsystem sftp /usr/lib/ssh/sftp-server

This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
UseDNS no
Protocol 2

ssh_config outpt below

my00bkeb-p:/etc/ssh # cat ssh_config

$OpenBSD: ssh_config,v 1.20 2005/01/28 09:45:53 dtucker Exp $

This is the ssh client system-wide configuration file. See

ssh_config(5) for more information. This file provides defaults for

users, and the values can be changed in per-user configuration files

or on the command line.

Configuration data is parsed as follows:

1. command line options

2. user-specific file

3. system-wide file

Any configuration value is only changed the first time it is set.

Thus, host-specific definitions should be at the beginning of the

configuration file, and defaults at the end.

Site-wide defaults for some commonly used options. For a comprehensive

list of available options, their meanings and defaults, please see the

ssh_config(5) man page.

Host *

ForwardAgent no

ForwardX11 no

If you do not trust your remote host (or its administrator), you

should not forward X11 connections to your local X11-display for

security reasons: Someone stealing the authentification data on the

remote side (the “spoofed” X-server by the remote sshd) can read your

keystrokes as you type, just like any other X11 client could do.

Set this to “no” here for global effect or in your own ~/.ssh/config

file if you want to have the remote X11 authentification data to

expire after two minutes after remote login.

ForwardX11Trusted yes

RhostsRSAAuthentication no

RSAAuthentication yes

PasswordAuthentication yes

HostbasedAuthentication no

BatchMode no

CheckHostIP yes

AddressFamily any

ConnectTimeout 0

StrictHostKeyChecking ask

IdentityFile ~/.ssh/identity

IdentityFile ~/.ssh/id_rsa

IdentityFile ~/.ssh/id_dsa

Port 22

Protocol 2,1

Cipher 3des

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

EscapeChar ~

GSSAPIAuthentication no

GSSAPIDelegateCredentials no

Set this to ‘yes’ to enable support for the deprecated ‘gssapi’ authentication

mechanism to OpenSSH 3.8p1. The newer ‘gssapi-with-mic’ mechanism is included

in this release. The use of ‘gssapi’ is deprecated due to the presence of

potential man-in-the-middle attacks, which ‘gssapi-with-mic’ is not susceptible to.

GSSAPIEnableMITMAttack no

This enables sending locale enviroment variables LC_* LANG, see ssh_config(5).

SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL
StrictHostKeyChecking no
ConnectTimeout 20

For future reference, wrapping output of commands and contents of files in CODE tags takes posts much easier to read. (Look for the # button in toolbar when composing.)

You’re using an End Of Life version of SLES which doesn’t have all the updates it could/should have installed. SLES 10 SP2 which went End Of Life years ago. A quick look on Patch Finder shows that there were kernel updates released after version 2.6.16.60-0.23.

It’s still not clear what you’re trying to do. I think you’ve got a script in which you are expecting to be able to ssh in to another machine to run some commands, is that correct? If so are you using ssh keys to do the authentication? If now, how is the authentication being attempted?

Hi mikewills,

Apologize for posting the logs/config in this thread. This is my first post here and i will surely follow your guideline next time i posted up anything.

Back to the issue. We actually have a script tied up to a monitoring application which is Nagios. Previously everything seems to work. We can execute start,stop and show status using the script to stop our application. However about 6 months back we are unable to execute all of the option available and get above errors. is there strange thing about the config files attached before?

It’s OK to post logs/config, it’s just that unless you wrap it in CODE tags they can be be very difficult to read and not obvious where they end. (If you do post such things you should also check first that it doesn’t contain anything potentially sensitive, like passwords.)

[QUOTE=z1tr0n;24192]
Back to the issue. We actually have a script tied up to a monitoring application which is Nagios. Previously everything seems to work. We can execute start,stop and show status using the script to stop our application. However about 6 months back we are unable to execute all of the option available and get above errors. is there strange thing about the config files attached before?[/QUOTE]
I don’t see anything strange about the config files, I suspect they’re probably defaults but I don’t have a copy of SLES 10 SP2 to compare against. (Note my previous comments about SLES 10 SP2 being End Of Life.)

When stuff stops working it’s (obviously) because something changed. Updates are an obvious potential candidate for changing things, but given the lack of updates on the server that seems less likely. What changes were made to any relevant systems about 6 months ago? You haven’t explained exactly how authentication is being done. Can you log in as the user manually? E.g.

$ ssh eccroot@my00bkeb-p 

I’m assuming the usercode and hostname from the contents of your first post.