Passwordless login via SSH - SSH

This is a discussion on Passwordless login via SSH - SSH ; Hi all I'm using passwordless logins to remote computers successfully for "normal" PCs. (guide on http://www.tux.org/~tbr/rsync/ ) With my freecom Network attached storage running OpenSSH_4.5p1, OpenSSL 0.9.7m 23 Feb 2007 however, it doesn't work. (guide on http://www.openfsg.com/index.php/Ssh_without_passwords ) I've exported ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Passwordless login via SSH

  1. Passwordless login via SSH

    Hi all
    I'm using passwordless logins to remote computers successfully
    for "normal" PCs. (guide on http://www.tux.org/~tbr/rsync/)
    With my freecom Network attached storage running
    OpenSSH_4.5p1, OpenSSL 0.9.7m 23 Feb 2007
    however, it doesn't work. (guide on
    http://www.openfsg.com/index.php/Ssh_without_passwords)

    I've exported my public keys from the "local machine" to the
    authorized_keys of of the "remote machine". Using keychains,
    I load the private keys on the "local machine" and try to log
    in on the "remote machine".

    To the point:
    Can someone determine what the error is from the following output
    (taken from ssh -vvv "remote.machine")
    I'd be terribly grateful! :-) Have spent hours in vain...

    -----------------------------------------------------------------------
    OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to "remote.machine" ["remote.machine"] port 22.
    debug1: Connection established.
    debug1: identity file /home/roman/.ssh/identity type -1
    debug3: Not a RSA1 key file /home/roman/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'Proc-Type:'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'DEK-Info:'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /home/roman/.ssh/id_rsa type 1
    debug3: Not a RSA1 key file /home/roman/.ssh/id_dsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'Proc-Type:'
    debug3: key_read: missing keytype
    debug2: key_type_from_name: unknown key type 'DEK-Info:'
    debug3: key_read: missing keytype
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug3: key_read: missing whitespace
    debug2: key_type_from_name: unknown key type '-----END'
    debug3: key_read: missing keytype
    debug1: identity file /home/roman/.ssh/id_dsa type 2
    debug1: Remote protocol version 1.99, remote software version OpenSSH_4.5
    debug1: match: OpenSSH_4.5 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit:
    diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit:
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit:
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit: none,zlib
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit:
    diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit:
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit:
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-cbc hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-cbc hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 131/256
    debug2: bits set: 508/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/roman/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 4
    debug1: Host '"remote.machine"' is known and matches the RSA host key.
    debug1: Found key in /home/roman/.ssh/known_hosts:4
    debug2: bits set: 519/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/roman/.ssh/identity ((nil))
    debug2: key: /home/roman/.ssh/id_rsa (0x808c090)
    debug2: key: /home/roman/.ssh/id_dsa (0x808c0a8)
    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive
    debug3: start over, passed a different list
    publickey,password,keyboard-interactive
    debug3: preferred publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: keyboard-interactive,password
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/roman/.ssh/identity
    debug3: no such identity: /home/roman/.ssh/identity
    debug1: Offering public key: /home/roman/.ssh/id_rsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive
    debug1: Offering public key: /home/roman/.ssh/id_dsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup keyboard-interactive
    debug3: remaining preferred: password
    debug3: authmethod_is_enabled keyboard-interactive
    debug1: Next authentication method: keyboard-interactive
    debug2: userauth_kbdint
    debug2: we sent a keyboard-interactive packet, wait for reply
    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive
    debug3: userauth_kbdint: disable: no info_req_seen
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred:
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    roman@"remote.machine"'s password:
    -----------------------------------------------------------------------

    If you've read this far, you'll understand my frustration.... :-/

  2. Re: Passwordless login via SSH

    Roman Ratnaweera wrote:
    > Anyay, for the record, I stumbled across the solution on a wiki.
    > I knew that .ssh and authorized_keys had to have chmod 700 and 600
    > respectively. But it seems for the mentioned NAS gadget, that is not
    > enough. It acutally requires the user's home directory to be 700 as
    > well. I have no idea why this is so. IMHO, it does not really make
    > sense. Since /home/ is 755, what good does a /home/user 700 do, if
    > /home/user/.ssh/ is 700 already?


    I don't know why OpenSSH would care about that. As long as no part of
    the path is writable, it should be fine. Authorized_keys doesn't have
    to be secret. Now if user were 775 or something like that, it would
    make a difference.

    But you can run the server in debug mode in both configurations and
    verify that it's the permissions that are biting here.

    --
    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. >

  3. Re: Passwordless login via SSH

    I don't know why I hardly ever get answers to my questions.
    Either they are too stupid or too specific... or something else is wrong.

    > I'm using passwordless logins to remote computers successfully
    > for "normal" PCs. (guide on http://www.tux.org/~tbr/rsync/)
    > With my freecom Network attached storage running
    > OpenSSH_4.5p1, OpenSSL 0.9.7m 23 Feb 2007
    > however, it doesn't work. (guide on
    > http://www.openfsg.com/index.php/Ssh_without_passwords)


    Anyay, for the record, I stumbled across the solution on a wiki.
    I knew that .ssh and authorized_keys had to have chmod 700 and 600
    respectively. But it seems for the mentioned NAS gadget, that is not
    enough. It acutally requires the user's home directory to be 700 as
    well. I have no idea why this is so. IMHO, it does not really make
    sense. Since /home/ is 755, what good does a /home/user 700 do, if
    /home/user/.ssh/ is 700 already?

    "normal" PC: chmod (user and group system specific)
    /home 755
    user 755
    .ssh 700
    authorized_keys 600

    Freecom NAS:
    /home 755
    user 700
    .ssh 700
    authorized_keys 600

    Ok, so much for that. If anyone can enlighten me to the use of this
    setup, please do. But I expect there will not be an answer to this
    post... ;-)

  4. Re: Passwordless login via SSH

    >>>>> "RR" == Roman Ratnaweera writes:

    RR> I don't know why I hardly ever get answers to my questions.
    RR> Either they are too stupid or too specific... or something else is
    RR> wrong.

    >> I'm using passwordless logins to remote computers successfully for
    >> "normal" PCs. (guide on http://www.tux.org/~tbr/rsync/) With my
    >> freecom Network attached storage running OpenSSH_4.5p1, OpenSSL
    >> 0.9.7m 23 Feb 2007 however, it doesn't work. (guide on
    >> http://www.openfsg.com/index.php/Ssh_without_passwords)


    RR> Anyay, for the record, I stumbled across the solution on a wiki.
    RR> I knew that .ssh and authorized_keys had to have chmod 700 and 600
    RR> respectively. But it seems for the mentioned NAS gadget, that is
    RR> not enough. It acutally requires the user's home directory to be
    RR> 700 as well. I have no idea why this is so.

    So that others can't subvert your security by simply renaming, deleting,
    or replacing your ~/.ssh.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: Passwordless login via SSH

    On Mon, 14 Apr 2008 22:25:24 -0400 Richard E. Silverman wrote:
    |>>>>> "RR" == Roman Ratnaweera writes:
    |
    | RR> I don't know why I hardly ever get answers to my questions.
    | RR> Either they are too stupid or too specific... or something else is
    | RR> wrong.
    |
    | >> I'm using passwordless logins to remote computers successfully for
    | >> "normal" PCs. (guide on http://www.tux.org/~tbr/rsync/) With my
    | >> freecom Network attached storage running OpenSSH_4.5p1, OpenSSL
    | >> 0.9.7m 23 Feb 2007 however, it doesn't work. (guide on
    | >> http://www.openfsg.com/index.php/Ssh_without_passwords)
    |
    | RR> Anyay, for the record, I stumbled across the solution on a wiki.
    | RR> I knew that .ssh and authorized_keys had to have chmod 700 and 600
    | RR> respectively. But it seems for the mentioned NAS gadget, that is
    | RR> not enough. It acutally requires the user's home directory to be
    | RR> 700 as well. I have no idea why this is so.
    |
    | So that others can't subvert your security by simply renaming, deleting,
    | or replacing your ~/.ssh.

    And how does read-only access enable that? The only things I am aware of
    that need protection from reading are the non-public keys.

    My home directory is 755 and that works fine. If it were 775 then someone in
    my group could juggle around some directory he found that could, if renamed
    as ".ssh", permit her to login as me. Reality is, I use personal groups for
    only my own userids. But sshd doesn't know that because other systems might
    have different userids in a group that shouldn't login as each other. But
    permissions of 755 on the home directory should be fine.

    --
    |WARNING: Due to extreme spam, I no longer see any articles originating from |
    | Google Groups. If you want your postings to be seen by more readers |
    | you will need to find a different place to post on Usenet. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

+ Reply to Thread