Home / server / Questions / 416441
Accepted
amateur barista
Asked: 2012-08-11 14:01:20 +0800 CST

PAM module causes flurry of SSH sessions

  • 772

While tailing /var/log/auth.log I noticed that there where multiple entries being entered (instantly) by the minute for user "foo". I personally had only one connection open as user "root_bar" while tailing the auth.log (log sample below). As you can see, there is no IP information for this incoming SSH connections. What is the best way to trace the IP address for incoming SSH connections?

Aug 10 14:30:04 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:04 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:06 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:06 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:08 ps2000 CRON[16879]: (pam_unix) session closed for user root_bar
Aug 10 14:30:14 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:14 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:16 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:16 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:27 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:27 ps2000 suexec: (pam_unix) session closed for user root_bar
Aug 10 14:30:39 ps2000 suexec: (pam_unix) session opened for user root_bar by (uid=999)
Aug 10 14:30:39 ps2000 suexec: (pam_unix) session closed for user root_bar

Disclaimer: servername, and all user information has been changed for security reasons.

Correction: The question "Tracing incoming SSH connections" has been properly answered by the posters below. The message suexec (pam_unix) session does not necessarily indicate any sshd activity as clarified by @aseq, and I posted this as a sshd question due to my ignorance. Since the original question, and it's answers are helpful, I'm accepting the most helpful answer. I think tracing suexec: (pam_unix) session is the candidate for a separate question.

Final update: I discovered that the messages above did have to do with sshd. After doing some tweaks in /etc/pam.d/common-auth I started seeing lines such as

Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session opened for user summer_flag by (uid=0)
Aug 10 16:45:23 candy_bass sshd[427]: PAM pam_parse: expecting return value; [...sucess=1 default=ignore]
Aug 10 16:45:23 candy_bass sshd[427]: PAM pam_parse: expecting return value; [...sucess=1 default=ignore]
Aug 10 16:45:23 candy_bass sshd[427]: Accepted publickey for summer_flag from xxx.zzz.yyy.abc port 35964 ssh2
Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session opened for user summer_flag by (uid=0)
Aug 10 16:45:23 candy_bass pam_limits[427]: setrlimit limit #11 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0
Aug 10 16:45:23 candy_bass pam_limits[427]: setrlimit limit #12 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0
Aug 10 16:45:23 candy_bass sshd[427]: (pam_unix) session closed for user summer_flag

So this is related to sshd, however, since this is so specific to a token-auth vendor (whose name I am not disclosing for privacy), I think this might be better solved by the vendor.

ssh

5 Answers

  1. Best Answer

    How do those log entries look like?

    The ssh server should log the IP addresses by default in /var/log/auth.log and other log files, such as:

    Aug 1 12:21:30 example.host sshd[1174]: Failed password for invalid user example from 192.0.2.1 port 9460 ssh2
Aug 1 12:21:32 example.host sshd[1176]: Invalid user root from 192.0.2.10

    If the log entries you are asking about do not have the string "sshd" in it I doubt they actually came from the ssh server and you need to look elsewhere. Look ate the string that comes after the hostname, it tells you which program was writing the log.

    You may also check /etc/ssh/sshd_config and see if the loglevel is correct, the default on squeeze is:

    # Logging
SyslogFacility AUTH
LogLevel INFO

    Perhaps increasing verbosity may reveal more information. The log entry you added to your question should be preceded by log entries as pasted above.

    • 3

  2. You will see connections open and close for SSH whenever a connection is made, regardless of whether someone successfully logged in or not.

    To view more information on successful and failed login attempts via ssh, look at /var/log/secure and/or /var/log/messages.

    ***Note that the location may vary depending on your distribution of Linux and/or your hosting provider.*

    • 1

  3. If you have access to the root user on the server, you could leverage iptables to implement a 'LOG' statement for all NEW connections on tcp port 22. This would add information to the /var/log/messages file indicating what connections are coming inbound to your server.

    If you are running IPv6, the firewall for there would be iptables6 I believe.

    • 0

  4. I resolved the flurry of opening and closing sessions on auth.log problem by commenting out the ChallengeResponseAuthentication and UsePAM settings on /etc/ssh/sshd_config from 

    ChallengeResponseAuthentication yes
UsePAM yes

    to 

    #ChallengeResponseAuthentication yes
#UsePAM yes

    In other words, I temporarily disabled the PAM module while I figure out with it's vendor the correct settings.

    • 0

  5. there may be an ip conflict on the same network with a windows server

    • 0