topic Re: Secure shell messages in syslog in Operating System - HP-UX

Secure shell messages in syslog

wvsa — Wed, 28 Jul 2010 16:27:19 GMT

Good morning all;

Running the latest version of secure shell on a rx6600 servers with 11iv3 release 5. Were getting the following messages in syslog, the messages are being generated from our nagios server.

SSH: Server;Ltype: Version;Remote: 89.0.1.193-53297;Protocol: 2.0;Client: check_ssh_1991

Was wondering if anyone has seen these messages? How can we make these messages go away?

Thank you for your input

Norm

Re: Secure shell messages in syslog

Steven E. Protter — Wed, 28 Jul 2010 17:49:19 GMT

Shalom,

Probably ssh_config or sshd_config has been modified to do this.

Take a look at syslog.conf as well.

There are a number of ways to do this.

SEP

Re: Secure shell messages in syslog

wvsa — Wed, 28 Jul 2010 19:23:41 GMT

Hello Steven;

Thank you for your response. To be honest have no idea what to change in sshd_config that would make these messages go away. Idealy would like to understand why were getting these messages. We could I suppose do something with ssh logging but that may hide other issues. Again not sure what we could do with the ssh logging that would make these messages not appear in syslog. Here is our sshd_config file, would you mind taking a look?

# cat sshd_config
# $OpenBSD: sshd_config,v 2.20 2009/02/26 $

# 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:/opt/ssh/bin

# 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
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /opt/ssh/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /opt/ssh/etc/ssh_host_rsa_key
#HostKey /opt/ssh/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#CountKeyAuthBadLogins no

# Auth selection

#HostbasedAuthAllowUsers
#HostbasedAuthDenyUsers
#PubkeyAuthAllowUsers
#PubkeyAuthDenyUsers
#KerberosAuthAllowUsers
#KerberosAuthDenyUsers
#KerberosOrLocalPasswdAllowUsers
#KerberosOrLocalPasswdDenyUsers
#PasswordAuthAllowUsers
#PasswordAuthDenyUsers
#ChallRespAuthAllowUsers [pam] user1 user2 ...
#ChallRespAuthDenyUsers [pam] user1 user2 ...
#ChallRespAuthAllowUsers [bsdauth] user1 user2 ...
#ChallRespAuthDenyUsers [bsdauth] user1 user2 ...
#ChallRespAuthAllowUsers [skey] user1 user2 ...
#ChallRespAuthDenyUsers [skey] user1 user2 ...
#ChallRespAuthAllowUsers [securid] user1 user2 ...
#ChallRespAuthDenyUsers [securid] user1 user2 ...
#GSSAPIAuthAllowUsers
#GSSAPIAuthDenyUsers

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

# For this to work you will also need host keys in /opt/ssh/etc/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 yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# 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

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

# no default banner path
#Banner none

#The following are HPN related configuration options
#tcp receive buffer polling. enable in autotuning kernels
#TcpRcvBufPoll no

# set tcp buffer size in Kbytes
#TcpRcvBuf 128

# allow the use of the none cipher
#NoneEnabled no

# disable hpn performance boosts.
#HPNDisabled no

# buffer size for hpn to non-hpn connections
#HPNBufferSize 2048

# override default of no subsystems
Subsystem sftp /opt/ssh/libexec/sftp-server

# sftp-server umask control
#SftpUmask

#SftpPermitChmod yes
#SftpPermitChown yes

#The following are TPM related configuration options
#Engine-loaded RSA key for host authentication (no default value)
# EngineHostRSAKey

# If EngineHostRSAKey has been created, the associated OpenSSL information is identified with:
# EngineConfigFile /opt/ssh/etc/server.cnf
# EngineConfigSection server_conf

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

Thank you

Norm

Re: Secure shell messages in syslog

Bill Hassell — Wed, 28 Jul 2010 21:06:55 GMT

You can change the sshd_config file:

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

But I would leave the facility as AUTH (the default). You can raise the level to more important messages but whether this drops the Nagios message is unknown until you find out what level (called priority in syslogd) this message uses. You can experiment by raising the level:

LogLevel Notice
or
LogLevel Warning
or
LogLevel Err

After changing to a higher level, restart sshd and see if the messages stop. The downside is that you don't know what may be filtered out of ssh messages that you may need.

The simplest way to clean up syslog.log is to separate the various facilities into different logs. This is done with the syslog.conf file. Change the line with syslog.log on the end to add auth.none:

*.info;mail.none;auth.none /var/adm/syslog/syslog.log

and add 1 additional line:

auth.info /var/adm/syslog/auth.log

NOTE: all spaces in the entire file MUST be tabs -- no spaces allowed! Any line with a space is silently ignored. Now restart syslogd with this command:

kill -HUP $(cat /var/run/syslog.pid)

Now check /var/adm/syslog and you'll see a new logfile called auth.log. All daemons that send messages to syslog using the AUTH facility will now send their messages to auth.log.

Re: Secure shell messages in syslog

wvsa — Thu, 29 Jul 2010 16:44:50 GMT

Hello Bill;

Thank you for your response, the syslog re-config worked as advertised. However the log options for SSH did not. The options for ssh logging are as follows:

LogLevel
Gives the verbosity level that is used when logging messages from
sshd. The possible values are: QUIET, FATAL, ERROR, INFO, VER-
BOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3. The default is INFO.
DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
higher levels of debugging output. Logging with a DEBUG level
violates the privacy of users and is not recommended.

Do you have any idea what are causing these messages to appear in the first place, see below;

SSH: Server;Ltype: Version;Remote: 89.0.1.193-53297;Protocol: 2.0;Client: check_ssh_1991

Thanks again for your response.

Norm

Re: Secure shell messages in syslog

Matti_Kurkela — Thu, 29 Jul 2010 20:18:09 GMT

The message seems to be identifying the version of the client that is trying to connect to the SSH server.

"Client: check_ssh_1991" might mean that this is not a real SSH client, but a Nagios check_ssh plugin that monitors the availability of your SSH service. "1991" might be the PID of the Nagios check_ssh process.

(Note: "check_by_ssh" is a different Nagios plugin, that uses an actual SSH login to run other monitoring tasks on a remote server. Don't confuse the two.)

The check_ssh plugin does the monitoring by connecting to the SSH service, then stopping short of an actual login. The sshd daemon will see this as an aborted connection: it logs information to aid troubleshooting in case this was a real connection attempt.

It's a bit like the Heisenberg's Uncertainty Principle in physics: when you actively probe something to monitor it, the probes will have some effect on their target too. In this case, the effect is some extra log messages.

MK

Re: Secure shell messages in syslog

wvsa — Thu, 29 Jul 2010 22:48:04 GMT

Hello Bill;

Is there anyway to remove the following message from syslog:

Isaac inetd[25943]: registrar/tcp: Connection from localhost (127.0.0.1) at Thu Jul 29 16:41:41 2010

Don't want to use inetd -l would prefer move these messages to a different file. Played with syslog.conf and could not get syslog to write these messages to a seperate file, not sure if the .info option in syslog.conf has the option to make this happen (moving the inetd: registrar/tcp localhost connections to a seperate file.

Thank you for the input.

Norm