Bug#626112: openssh-server: ssh doesn't log some failed authentications to auth.log anymore
On Thu, 2011-07-28 at 15:17 +0100, Colin Watson wrote: As far as I can tell, nothing relevant has changed in OpenSSH at all recently. Ok,.. weird... maybe there's something I don't see or I forgot,... was quite sure that it worked like that and I changed nothing,... Nevertheless... I don't think it's reasonable to regard this bug as release-critical, so I'm downgrading it. Yeah, that's probably ok. I mean... failed authentications with public key are usually harmeless anyway,... as you can't (well in practise) to brute force attacks there. On the other hand failed pubkey auth tries _are_ in some way security relevant, as they could be some form of [D]DoS... and that's where fail2band would be at least somewhat handy. Do you think it makes sense to ask Damaien to change the default behaviour here? You may have only started to notice this recently due to external factors; for example, perhaps your attackers have started to use authentication methods other than password? Actually I noticed it when testing myself some improved iptables rules from a remote host... Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#626112: openssh-server: ssh doesn't log some failed authentications to auth.log anymore
severity 626112 important thanks On Wed, Jul 27, 2011 at 10:38:26PM +0200, Christoph Anton Mitterer wrote: On Sun, 2011-07-24 at 11:02 +0100, Colin Watson wrote: If you use 'LogLevel VERBOSE', does that help? Can you provide some examples of log messages that fail2ban is noticing and banning? The problem isn't fail2ban,... it's that sshd doesn't log these attempts at all... You misunderstood me; I was asking for examples of the messages that *were* logged, since you said that some addresses did get successfully banned. But never mind now. But your idea (don't know why I didn't come up with this myself) with LogLevel helped! Now (with VERBOSE) messages like the following get logged to auth.log: Jul 27 22:33:29 hilbert sshd[4542]: Set /proc/self/oom_score_adj to 0 Jul 27 22:33:29 hilbert sshd[4542]: Connection from 129.187.131.203 port 33023 Jul 27 22:33:30 hilbert sshd[4542]: Failed publickey for root from 129.187.131.203 port 33023 ssh2 Jul 27 22:33:30 hilbert sshd[4544]: Set /proc/self/oom_score_adj to 0 Jul 27 22:33:30 hilbert sshd[4544]: Connection from 129.187.131.203 port 33024 Jul 27 22:33:31 hilbert sshd[4544]: Failed publickey for root from 129.187.131.203 port 33024 ssh2 fail2ban also detects them now (I guess it goes for the Failed pub..)... So the problem seems to be, that those messages are no longer logged in the default LogLevel. The rules are that authentication results are logged at the default level if any of the following is true: * the authentication was successful * the authentication attempt was for an invalid user * the number of failures on this connection = MaxAuthTries/2 * the authentication method was password As far as I can tell, nothing relevant has changed in OpenSSH at all recently. Before MaxAuthTries was introduced, the required number of failures was simply hardcoded to the same value. Prior to that, the rules have remained essentially unchanged since November 1999: revno: 142 committer: damien timestamp: Wed 1999-11-24 13:26:21 + message: - Merged very large OpenBSD source code reformat - OpenBSD CVS updates - [channels.c cipher.c compat.c log-client.c scp.c serverloop.c] [ssh.h sshd.8 sshd.c] syslog changes: * Unified Logmessage for all auth-types, for success and for failed * Standard connections get only ONE line in the LOG when level==LOG: Auth-attempts are logged only, if authentication is: a) successfull or b) with passwd or c) we had more than AUTH_FAIL_LOG failues * many log() became verbose() * old behaviour with level=VERBOSE Given how long this behaviour has been in place, and that there's a straightforward workaround by changing LogLevel, I don't think it's reasonable to regard this bug as release-critical, so I'm downgrading it. You may have only started to notice this recently due to external factors; for example, perhaps your attackers have started to use authentication methods other than password? Regards, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626112: openssh-server: ssh doesn't log some failed authentications to auth.log anymore
Hi Colin. On Sun, 2011-07-24 at 11:02 +0100, Colin Watson wrote: Did this work as you expect in some previous version? Which one? Yes definitely,.. but unfortunately,.. I don not remember which one.. If you use 'LogLevel VERBOSE', does that help? Can you provide some examples of log messages that fail2ban is noticing and banning? The problem isn't fail2ban,... it's that sshd doesn't log these attempts at all... But your idea (don't know why I didn't come up with this myself) with LogLevel helped! Now (with VERBOSE) messages like the following get logged to auth.log: Jul 27 22:33:29 hilbert sshd[4542]: Set /proc/self/oom_score_adj to 0 Jul 27 22:33:29 hilbert sshd[4542]: Connection from 129.187.131.203 port 33023 Jul 27 22:33:30 hilbert sshd[4542]: Failed publickey for root from 129.187.131.203 port 33023 ssh2 Jul 27 22:33:30 hilbert sshd[4544]: Set /proc/self/oom_score_adj to 0 Jul 27 22:33:30 hilbert sshd[4544]: Connection from 129.187.131.203 port 33024 Jul 27 22:33:31 hilbert sshd[4544]: Failed publickey for root from 129.187.131.203 port 33024 ssh2 fail2ban also detects them now (I guess it goes for the Failed pub..)... So the problem seems to be, that those messages are no longer logged in the default LogLevel. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#626112: openssh-server: ssh doesn't log some failed authentications to auth.log anymore
On Mon, May 09, 2011 at 12:15:19AM +0200, Christoph Anton Mitterer wrote: For *some* failed connections ssh seems to put no logging into auth.log anymore. Did this work as you expect in some previous version? Which one? This can be quite security relevant when using e.g. fail2ban which relies on this. Only some (types?) of connections seem to be affected, as I still see few IPs that get banned by fail2ban. But when I e.g. go to another host of mine, and try repeatedly to login, they don't get banned (as nothing appears in the logs). I tried both, hosts where a ~/.ssh/id_rsa* was in place and not. Attached is my sshd's configuration. Please ask for mor information if you need any. If you use 'LogLevel VERBOSE', does that help? Can you provide some examples of log messages that fail2ban is noticing and banning? Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626112: openssh-server: ssh doesn't log some failed authentications to auth.log anymore
Package: openssh-server Version: 1:5.8p1-4 Severity: grave Tags: security Justification: user security hole Hi. For *some* failed connections ssh seems to put no logging into auth.log anymore. This can be quite security relevant when using e.g. fail2ban which relies on this. Only some (types?) of connections seem to be affected, as I still see few IPs that get banned by fail2ban. But when I e.g. go to another host of mine, and try repeatedly to login, they don't get banned (as nothing appears in the logs). I tried both, hosts where a ~/.ssh/id_rsa* was in place and not. Attached is my sshd's configuration. Please ask for mor information if you need any. Cheers, Chris. -- debconf information: ssh/vulnerable_host_keys: ssh/new_config: true * ssh/use_old_init_script: true ssh/disable_cr_auth: false ssh/encrypted_host_key_but_no_keygen: ListenAddress lo.localhost ListenAddress lo.ip6-localhost ListenAddress localhost.localhost ListenAddress eth0.localhost #ListenAddress eth0.ip6-localhost AllowUsers root #PermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no RSAAuthentication no Protocol 2 Ciphers aes256-cbc,aes192-cbc,aes128-cbc,aes256-ctr,aes192-ctr,aes128-ctr,blowfish-cbc MACs hmac-sha1,hmac-ripemd160 ClientAliveInterval 30 TCPKeepAlive no AcceptEnv LANG LC_* X11Forwarding yes Subsystem sftp /usr/lib/openssh/sftp-server
