sshd error - what could be wrong?

0

I am getting the error below from my /var/adm/messages (or syslog)

Aug 28 19:11:21 myhost sshd[25570]: [ID 800047 auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

Aug 28 19:12:50 myhost sshd[25570]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer
  1. Who is actually trying to ssh to the server? Why isn't there any username or terminal name?
  2. Is 25570 the process ID? Are we able to get more information about the process?
  3. What should be done next?

Noob

Posted 2015-08-28T15:56:21.443

Reputation: 1 145

Which OS are you using? Are the two error messages above in the client or int he server's logs? – MariusMatutiae – 2015-08-28T16:21:11.313

i am using solaris, these 2 message are from the server log /var/adm/messages – Noob – 2015-08-28T18:27:52.463

is the PID of the SSHD process, so, assuming you know you have SSH running on the server, that won't tell you too much. usually the log files should tell you the user account being used with a keyboard-interactive login attempt. are there any additional messages in /var/syslog (or whereever it is in solaris)? – Frank Thomas – 2015-08-28T18:38:39.470

@FrankThomas no, there isn't any additional message. normally, it will show which user attempt to login, but for this log entry, there isn't. is the server trying to login to itself ? hence no username ? – Noob – 2015-08-28T20:09:57.920

then it would still use an account (probably root, or a daemon user). – Frank Thomas – 2015-08-28T20:31:01.227

@FrankThomas in that case, what could be trying to login via ssh on my case above ? any idea what does the error means esp on the 2nd line – Noob – 2015-08-28T20:40:01.003

The error on the second line means that after the user at the other end tried once and failed to log in, they then disconnected instead of trying again and again. Since normally after an authentication failure the SSH daemon will ask the user to try again, when the user instead dropped the connection, this resulted in a failure to read from a no-longer-open socket. – This isn't my real name – 2015-10-30T17:39:33.367

Answers

0

  1. We can't tell who is trying to connect, because you aren't providing enough log data. This may be because you aren't getting enough log data, potentially. To increase your logging: The LogLevel keyword in /etc/ssh/sshd_config lets you control how verbose the logs are that the ssh daemon generates, and the "auth" facility in /etc/syslog.conf or /etc/rsyslog.conf lets you control what level of logging you want actually to be recorded.

  2. Yes, 25570 is the process ID. It's the process ID of the specific instance of sshd that was spawned to handle this connection, and the process lifetime will have been the same as the connection lifetime. The main value of this is that when reviewing logs, it lets you distinguish this instance from all the other login sessions to your server.

  3. What should be done next, is to increase the logging settings everywhere you can. Make sure the SSH daemon is logging at the highest leve, make sure the syslog is recording all the details that are being passed to it by the SSH daemon, check to see if any relevant PAM modules have optional increased-logging parameters that can be applied, and continue monitoring your logs.

This isn't my real name

Posted 2015-08-28T15:56:21.443

Reputation: 101

Asked: 2015-08-28T15:56:21.443

Viewed: 946 times

Active: 2015-10-30T17:37:39.013