OpenSSH on Solaris 9: Puzzling problems

From: Phil Stracchino (alaric_at_caerllewys.net)
Date: 06/06/03

  • Next message: sparhawk_at_beyond.nu: "Tape backup through ssh"
    Date: Thu, 5 Jun 2003 23:45:08 -0400
    To: SSH List <secureshell@securityfocus.com>
    
    

    Hi,
    I have an odd problem with OpenSSH 3.6.1p1 on Solaris 9 (4/03 release).
    I'm wondering if anyone can help me out.

    The setup:
    The machine is a Sun Ultra30 with a brand-new Solaris 9 install. It has
    gcc-3.2.3 installed from the sunfreeware.com package. This gcc was used
    to build OpenSSL 0.9.7a (I've also tried 0.9.7b with the same behavior),
    configured with "threads shared", and OpenSSH 3.6.1p1 configured with
    tcpwrappers support and configured for privilege separation. OpenSSL
    passed all tests, and both it and OpenSSH built cleanly.

    The symptoms:
    Outgoing ssh works perfectly. Incoming ssh sessions can only connect
    via password auth. All public-key authorizations fail, including
    connections to localhost. Iv'e tried starting sshd with -D -o
    LogLevel=DEBUG3, but this gets me no useful information. I get only ten
    lines of debug output at initial startup:

    $ /usr/sbin/sshd -b 1024 -f /etc/ssh/sshd_config -D -o LogLevel=DEBUG3
    debug2: read_server_config: filename /etc/ssh/sshd_config
    debug1: sshd version OpenSSH_3.6.1p1
    debug1: private host key: #0 type 0 RSA1
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
    debug1: read PEM private key done: type RSA
    debug1: private host key: #1 type 1 RSA
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
    debug1: read PEM private key done: type DSA
    debug1: private host key: #2 type 2 DSA
    debug1: Forcing server key to 1152 bits to make it differ from host key.

    A connection with -v from another machine yields the following output
    from ssh, but none whatsoever from sshd:

    $ ssh -v -l root minbar
    OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
    debug1: Reading configuration data /home/alaric/.ssh/config
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug1: /etc/ssh/ssh_config line 40: Deprecated option "FallBackToRsh"
    debug1: Rhosts Authentication disabled, originating port will not be
    trusted.
    debug1: Connecting to minbar [192.168.0.13] port 22.
    debug1: Connection established.
    debug1: identity file /home/alaric/.ssh/identity type 0
    debug1: identity file /home/alaric/.ssh/id_rsa type 1
    debug1: identity file /home/alaric/.ssh/id_dsa type 2
    debug1: Remote protocol version 1.99, remote software version
    OpenSSH_3.6.1p1
    debug1: match: OpenSSH_3.6.1p1 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: server->client aes128-cbc hmac-md5 zlib
    debug1: kex: client->server aes128-cbc hmac-md5 zlib
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'minbar' is known and matches the RSA host key.
    debug1: Found key in /home/alaric/.ssh/known_hosts:17
    debug1: ssh_rsa_verify: signature correct
    debug1: Enabling compression at level 6.
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,password
    debug1: Next authentication method: publickey
    debug1: Offering agent key: /home/alaric/.ssh/id_dsa
    debug1: Authentications that can continue: publickey,password
    debug1: Offering agent key: /home/alaric/.ssh/id_rsa
    debug1: Authentications that can continue: publickey,password
    debug1: Offering agent key: /root/.ssh/id_dsa
    debug1: Authentications that can continue: publickey,password
    debug1: Offering agent key: /root/.ssh/id_rsa
    debug1: Authentications that can continue: publickey,password
    debug1: Offering public key: /home/alaric/.ssh/id_rsa
    debug1: Authentications that can continue: publickey,password
    debug1: Offering public key: /home/alaric/.ssh/id_dsa
    debug1: Authentications that can continue: publickey,password
    debug1: Next authentication method: password
    root@minbar's password:
    debug1: Authentication succeeded (password).
    debug1: channel 0: new [client-session]
    debug1: Entering interactive session.
    debug1: channel 0: request pty-req
    debug1: Requesting X11 forwarding with authentication spoofing.
    debug1: channel 0: request x11-req
    debug1: Requesting authentication agent forwarding.
    debug1: channel 0: request auth-agent-req@openssh.com
    debug1: channel 0: request shell
    debug1: channel 0: open confirm rwindow 0 rmax 32768
    Last login: Thu Jun 5 23:27:49 2003 from babylon5.babcom
    Sun Microsystems Inc. SunOS 5.9 Generic May 2002
    Sun Microsystems Inc. SunOS 5.9 Generic May 2002
    Found SSH agent: Agent pid 16616
    minbar:root:~:1 #

    The questions:

       Can anyone suggest why I'm getting no useful debugging output from
          sshd, and how to make it give me output I can use to figure out
          why public key auth is consistently failing?

       Can anyone suggest possible theories why, with this configuration,
          public key auth would be consistently failing with known valid
          keys which are verified to be present in the authorized_keys file?

    Any insights and tips appreciated.

    -- 
     .*********  Fight Back!  It may not be just YOUR life at risk.  *********.
     : phil stracchino : unix ronin : renaissance man : mystic zen biker geek :
     :  alaric@caerllewys.net : alaric-ruthven@earthlink.net : phil@latt.net  :
     :   2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold)   :
     :    Linux Now!   ...Because friends don't let friends use Microsoft.    :
    

  • Next message: sparhawk_at_beyond.nu: "Tape backup through ssh"

    Relevant Pages

    • error:key_read, hostname failed
      ... and I have openssh 3.4.1 on the server. ... Can you think of any reason why ssh would work and sftp/scp wouldn't? ... debug1: Rhosts Authentication disabled, ... Host ''hostname' is known and matches the RSA1 host key. ...
      (comp.security.ssh)
    • help with ssh
      ... debug1: Authentications that can continue: publickey,gssapi-with-mic,password ... debug2: we sent a gssapi-with-mic packet, ...
      (RedHat)
    • Re: SFTP/SCP connection prob
      ... debug1: Authentications that can continue: publickey,password,keyboard- ... debug2: we sent a publickey packet, ... which only supports SFTP/SCP protocal from server C ...
      (comp.security.unix)
    • Re: Expect scripting help - to determine hostname with ssh
      ... You're sending the scp command to your ping process. ... debug1: Authentications that can continue: ... debug1: Next authentication method: keyboard-interactive ...
      (comp.lang.tcl)
    • Re: SSH issues with 4.9 stable (key_verify failed for server_host_key)
      ... The main thing I noticed is that the openssh in the base is the only one ... port and openssh release use RSA. ... debug1: Host 'x.x' is known and matches the DSA host key. ...
      (freebsd-stable)