Re: Password auth turned off in OpenSSH

From: Daniel Prevett (Daniel.Prevett_at_vandyke.com)
Date: 10/11/04

  • Next message: Senthil Kumar: "OpenSSH -3.9 connection delay" 
    To: "C. Linus Hicks" <lhicks@nc.rr.com>, <secureshell@securityfocus.com>
Date: Mon, 11 Oct 2004 13:59:05 -0600

    Look for an option in the sshd_config file that looks like this:

    # Set this to 'yes' to enable PAM keyboard-interactive authentication
    # Warning: enabling this may bypass the setting of 'PasswordAuthentication'
    PAMAuthenticationViaKbdInt yes

    If it's set to yes, that's likely what is happening. Setting that
    option to no should force the users to have to use public key provided
    that PasswordAuthentication is also set to no.

    -daniel

    >I posted a similar message to this list earlier, but it was rejected by
    > the moderator. Unfortunately the response I got didn't answer my
    > question. This message is an attempt to clarify my question.
    >
    > Since I have PasswordAuthentication turned off, I was under the
    > impression that a brute force password attack on my system was not
    > possible. That is, it would not allow anyone to attempt a login by
    > providing username/password. The fact that it seems to be allowing
    > password authentication has me wondering if there is a bug. Am I not
    > understanding what this flag does? When I try to connect from one of my
    > other systems via username/password to this ssh server, I don't get the
    > chance to enter a password, and my logfiles look different from what
    > happens during an attack.
    >
    > I do understand that a computer on a public network can be the target of
    > brute force password attacks, but doesn't that become impossible when
    > public key authentication is the only way allowed?
    >
    > So my question is, is there a bug, or do I have something wrong in my
    > config file? And do my logfiles really tell me that username/password
    > authentication is happening?
    >
    > Here is a sample from my log file:
    >
    > Oct 4 15:15:09 lh2 sshd[28337]: Could not reverse map address 202.33.56.20.
    > Oct 4 15:15:09 lh2 sshd[28337]: Failed password for root from 202.33.56.20 port 47240 ssh2
    > Oct 4 15:15:09 lh2 sshd[28337]: Received disconnect from 202.33.56.20: 11: Bye Bye
    >
    > I searched the mail archives and also looked on the openssh "Security"
    > page for references to a bug, to no avail. And I am wondering: if it is
    > a bug, is it fixed in the latest version, but there doesn't seem to be
    > any information about it, like it's not a problem.
    >
    > --
    > C. Linus Hicks <lhicks@nc.rr.com>
    >
    >
    >

  • Next message: Senthil Kumar: "OpenSSH -3.9 connection delay"

    Relevant Pages

    • Password auth turned off in OpenSSH
      ... impression that a brute force password attack on my system was not ... password authentication has me wondering if there is a bug. ... other systems via username/password to this ssh server, ... So my question is, is there a bug, or do I have something wrong in my ...
      (SSH)
    • Re: SSH Auth Failure?
      ... There are a couple of bug reports of this in bugzilla, but no coments from redhat so far. ... I do not understand why the login process should take longer time than usual. ... As for the log messages, ... But the bogus authentication failure message is wrong in either case. ...
      (RedHat)
    • "Local" and "Remote" considered insufficient
      ... These types of discrepancies in terminology happen fairly often. ... to include the amount of "authentication" required, ... vs. remote terminology for a while. ... When an FTP bug is exploitable by "authenticated" users, ...
      (Vuln-Dev)
    • "Local" and "Remote" considered insufficient
      ... These types of discrepancies in terminology happen fairly often. ... to include the amount of "authentication" required, ... vs. remote terminology for a while. ... When an FTP bug is exploitable by "authenticated" users, ...
      (Bugtraq)
    • Re: PEAP authentication with Windows 2003 unreliable
      ... Are you using wireless authentication or wired? ... The particular behavior that you are seeing is related to a bug which gets ... with no particular user or computer and eventually after the user logs on ...
      (microsoft.public.internet.radius)