Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration - SSH

This is a discussion on Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration - SSH ; Hi all! I thought I had configured OpenSSH's sshd the way that it 1) does not accept user-logins for users that do not have a key installed in their home-directories on the host and 2) does never accept root to ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

  1. Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    Hi all!

    I thought I had configured OpenSSH's sshd the way that it

    1) does not accept user-logins for users that do not have a key
    installed in their home-directories on the host and
    2) does never accept root to even try to log in.

    I switched sshd-login to DEBUG to check wether my configuration does
    work as I thought it should. But I encounter the folloging dialog:

    Jun 11 19:28:25 inkathlon sshd[27057]: Connection from
    ::ffff:131.211.255.12 port 56025
    Jun 11 19:28:25 inkathlon sshd[18126]: debug1: Forked child 27057.
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: Client protocol version
    2.0; client software version libssh-0.1
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: no match: libssh-0.1
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: Enabling compatibility
    mode for protocol 2.0
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: Local version string
    SSH-2.0-OpenSSH_3.7.1p2
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: list_hostkey_types:
    ssh-rsa,ssh-dss
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: SSH2_MSG_KEXINIT sent
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: SSH2_MSG_KEXINIT
    received
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: kex: client->server
    aes128-cbc hmac-sha1 none
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: kex: server->client
    aes128-cbc hmac-sha1 none
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: expecting
    SSH2_MSG_KEXDH_INIT
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: SSH2_MSG_NEWKEYS sent
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: expecting
    SSH2_MSG_NEWKEYS
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: SSH2_MSG_NEWKEYS
    received
    Jun 11 19:28:25 inkathlon sshd[27057]: debug1: KEX done
    Jun 11 19:28:26 inkathlon sshd[27057]: debug1: userauth-request for
    user root service ssh-connection method password
    Jun 11 19:28:26 inkathlon sshd[27057]: debug1: attempt 0 failures 0
    Jun 11 19:28:26 inkathlon sshd[27057]: Failed password for root from
    ::ffff:131.211.255.12 port 56025 ssh2
    Jun 11 19:28:26 inkathlon sshd[27057]: Received disconnect from
    ::ffff:131.211.255.12: 11: Bye Bye
    Jun 11 19:28:26 inkathlon sshd[27057]: debug1: Calling cleanup
    0x80733b0(0x0)

    As far as I understand it there is a user root that even is asked to
    give a passwort. Why? My sshd_config contains the following lines:

    PubkeyAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys
    PasswordAuthentication no
    PermitRootLogin no

    Have I missconfigured ssh or do I missunderstand the log-snipplet
    above? Or is there a third thing wrong? I searched the web but failed
    to understand what sshd is doing. Any help will be highly appreceated,

    Christian


  2. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration


    Did you restart sshd after making the configuration change?

    --
    Richard Silverman
    res@qoxp.net


  3. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    > Did you restart sshd after making the configuration change?

    Yes, I did so. Due to a kernel-update I even rebooted the computer so
    my configuration must have be parsed. But you do agree that the log
    indicates that sshd asked a user for his/her passwort and that this
    user even has been root!?

    Christian


  4. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    >>>>> "java" == java writes:

    >> Did you restart sshd after making the configuration change?


    java> Yes, I did so. Due to a kernel-update I even rebooted the
    java> computer so my configuration must have be parsed. But you do
    java> agree that the log indicates that sshd asked a user for his/her
    java> passwort

    (Auf Englisch schreibt man, "password.") To be precise, the client made a
    request using the password method; sshd doesn't "ask." This would not
    normally happen if the server did not offer that method, but there's no
    reason a client couldn't try it anyway. Of course, it would fail, as
    happened here. What's the client? Getting log from the client might
    reveal what methods the server actually offered.

    java> and that this user even has been root!?

    No; the authentication attempt failed.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    > (Auf Englisch schreibt man, "password.")

    Sorry, still improving ;-)

    > To be precise, the client made a
    > request using the password method; sshd doesn't "ask."
    > This would not normally happen if the server did not offer that method,
    > but there's no reason a client couldn't try it anyway.


    The client is no regular program. As the sshd is directly connected to
    the internet the log is an example for the attempt of an unknown
    skriptkid.

    My concern about this dialog is that the sshd does not immediatly close
    it down as the username root appears. I thought that any user named
    root is locked out right away.

    Thank you so far,

    Christian


  6. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    java@wispa.de wrote:
    > My concern about this dialog is that the sshd does not immediatly close
    > it down as the username root appears. I thought that any user named
    > root is locked out right away.


    That would give the client extra information. If it's shut down right
    away, you would know if root were enabled.

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  7. Re: Understanding OpenSSH_3.7.1p2 - logfile seems not to match configuration

    >>>>> "java" == java writes:

    >> (Auf Englisch schreibt man, "password.")

    java> Sorry, still improving ;-)

    >> To be precise, the client made a request using the password method;
    >> sshd doesn't "ask." This would not normally happen if the server
    >> did not offer that method, but there's no reason a client couldn't
    >> try it anyway.


    java> The client is no regular program. As the sshd is directly
    java> connected to the internet the log is an example for the attempt
    java> of an unknown skriptkid.

    Then the exploit program probably just always tries the password method,
    ignoring the list of supported methods supplied by the server.

    java> My concern about this dialog is that the sshd does not
    java> immediatly close it down as the username root appears. I thought
    java> that any user named root is locked out right away.

    It is locked out: all authentication requests for root will fail,
    regardless of the authentication data provided.

    Are you saying you want sshd to close down the connection as soon as
    someone tries to authenticate as root? OpenSSH doesn't have that
    feature.

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread