• Request Urgent Help -- SSH authentication problem

    From dakupoto@gmail.com@1:0/0 to All on Sat Sep 14 02:46:22 2013
    Could some Linux/ssh guru please help me with
    this ssh authentication issue ? I am trying to
    ssh from a Fedora 15 box to a Raspberry Pi Model
    B SBC running OpenELEC 2.99.5. Both have static
    IPs on the same network, behind a small D-Link
    router. The ssh port on the Fedora box's firewall
    is open, for now. The first thing that seems out
    of place is that I cannot ping the Raspberry Pi
    from the Fedora box.That is if I use the static
    IP address of the Raspberry Pi, I get:

    ping 192.168.1.2
    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=2 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=3 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=4 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=5 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=6 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=7 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=8 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=9 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=10 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=11 Destination Host Prohibited
    ^C
    - --- 192.168.1.2 ping statistics ---
    11 packets transmitted, 0 received, +11 errors, 100% packet loss, time 9999ms


    However, if I just use the default hostname of
    Raspberry Pi, I get:
    ping openelec
    PING openelec.localdomain (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_req=1 ttl=254 time=0.304 ms
    64 bytes from 192.168.1.1: icmp_req=2 ttl=254 time=0.397 ms
    64 bytes from 192.168.1.1: icmp_req=3 ttl=254 time=0.465 ms
    64 bytes from 192.168.1.1: icmp_req=4 ttl=254 time=0.419 ms
    64 bytes from 192.168.1.1: icmp_req=5 ttl=254 time=0.452 ms
    64 bytes from 192.168.1.1: icmp_req=6 ttl=254 time=0.452 ms
    64 bytes from 192.168.1.1: icmp_req=7 ttl=254 time=0.388 ms
    64 bytes from 192.168.1.1: icmp_req=8 ttl=254 time=0.464 ms
    64 bytes from 192.168.1.1: icmp_req=9 ttl=254 time=0.437 ms
    64 bytes from 192.168.1.1: icmp_req=10 ttl=254 time=0.459 ms
    ^C
    - --- openelec.localdomain ping statistics ---
    10 packets transmitted, 10 received, 0% packet loss, time 18009ms
    rtt min/avg/max/mdev = 0.304/0.423/0.465/0.053 ms

    The inconsistenct between the two results is not clear.

    Please note that I have used ssh-keygen on the Fedora
    box to generate the DSA keys. I have tried RSA keys as well,
    but no luck.
    So, if I try to ssh from the Fedora box to the Raspberry Pi,
    I get:
    ssh root@192.168.1.2 -vvv
    OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
    debug1: Connection established.
    debug1: identity file /home/lama/.ssh/id_rsa type -1
    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1
    debug3: Not a RSA1 key file /home/lama/.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/lama/.ssh/id_dsa type 2
    debug1: identity file /home/lama/.ssh/id_dsa-cert type -1
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5 debug1: match: OpenSSH_5.5 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.5
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    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-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib@openssh.com,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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blow fish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,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_setup: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug2: mac_setup: found hmac-md5
    debug1: kex: client->server aes128-ctr 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: 124/256
    debug2: bits set: 513/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: host 192.168.1.2 filename /home/lama/.ssh/known_hosts
    debug3: check_host_in_hostfile: host 192.168.1.2 filename /home/lama/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host '192.168.1.2' is known and matches the RSA host key.
    debug1: Found key in /home/lama/.ssh/known_hosts:1
    debug2: bits set: 567/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: Roaming not allowed by server
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: /home/lama/.ssh/id_dsa (0x1996038)
    debug2: key: /home/lama/.ssh/id_rsa ((nil))
    debug1: Authentications that can continue: publickey,password
    debug3: start over, passed a different list publickey,password
    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: Offering public key: /home/lama/.ssh/id_dsa
    debug3: send_pubkey_test
    debug2: we sent a publickey packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    debug1: Trying private key: /home/lama/.ssh/id_rsa
    debug3: no such identity: /home/lama/.ssh/id_rsa
    debug2: we did not send a packet, disable method
    debug3: authmethod_lookup password
    debug3: remaining preferred: ,password
    debug3: authmethod_is_enabled password
    debug1: Next authentication method: password
    root@192.168.1.2's password:
    debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
    debug2: we sent a password packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    Permission denied, please try again.
    root@192.168.1.2's password:
    debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
    debug2: we sent a password packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    Permission denied, please try again.
    root@192.168.1.2's password:
    debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
    debug2: we sent a password packet, wait for reply
    debug1: Authentications that can continue: publickey,password
    debug2: we did not send a packet, disable method
    debug1: No more authentication methods to try.
    Permission denied (publickey,password).

    So it appears that the connection is established:
    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
    debug1: Connection established.
    debug1: identity file /home/lama/.ssh/id_rsa type -1
    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1
    debug3: Not a RSA1 key file /home/lama/.ssh/id_dsa.

    But somehow the ssh module does not correctly parse the
    key files, that is the comment lines starting with "----".

    Any hints, suggestions as t what might be going on, will
    be gratefully appreciated. I apologize for the long post,
    and thanks in advance for your help.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobbs.
  • From Trevor Hemsley@1:0/0 to All on Sat Sep 14 10:20:47 2013
    On Sat, 14 Sep 2013 02:46:22 UTC in comp.os.linux.security, dakupoto@gmail.com wrote:

    I am trying to
    ssh from a Fedora 15 box to a Raspberry Pi Model
    B SBC running OpenELEC 2.99.5. Both have static
    IPs on the same network, behind a small D-Link
    router. The ssh port on the Fedora box's firewall
    is open, for now. The first thing that seems out
    of place is that I cannot ping the Raspberry Pi
    from the Fedora box.That is if I use the static
    IP address of the Raspberry Pi, I get:

    ping 192.168.1.2
    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited

    192.168.1.2

    However, if I just use the default hostname of
    Raspberry Pi, I get:
    ping openelec
    PING openelec.localdomain (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_req=1 ttl=254 time=0.304 ms

    192.168.1.1

    Which one is it really? 1 or 2?

    From the symptoms, given that I know that openelec has an iptables policy of ACCEPT on all chains, I'd say that your "dns" entry is pointing at your Fedora host.

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobbs.
  • From unruh@1:0/0 to All on Sat Sep 14 16:46:37 2013
    On 2013-09-14, dakupoto@gmail.com <dakupoto@gmail.com> wrote:
    Could some Linux/ssh guru please help me with
    this ssh authentication issue ? I am trying to
    ssh from a Fedora 15 box to a Raspberry Pi Model
    B SBC running OpenELEC 2.99.5. Both have static
    IPs on the same network, behind a small D-Link
    router. The ssh port on the Fedora box's firewall
    is open, for now. The first thing that seems out
    of place is that I cannot ping the Raspberry Pi
    from the Fedora box.That is if I use the static
    IP address of the Raspberry Pi, I get:

    ping 192.168.1.2
    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited

    However, if I just use the default hostname of
    Raspberry Pi, I get:
    ping openelec

    Uh, you do see the difference between the IP numbers don't you?

    PING openelec.localdomain (192.168.1.1) 56(84) bytes of data.
    64 bytes from 192.168.1.1: icmp_req=1 ttl=254 time=0.304 ms

    The inconsistenct between the two results is not clear.

    Your dns is telling you that openlec is not the IP address you claim
    that the RPi has.



    Please note that I have used ssh-keygen on the Fedora
    box to generate the DSA keys. I have tried RSA keys as well,
    but no luck.
    So, if I try to ssh from the Fedora box to the Raspberry Pi,
    I get:
    ssh root@192.168.1.2 -vvv
    OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
    debug1: Connection established.

    OK, so 192.168.1.2 has an ssh deamon listening on port 22

    debug1: identity file /home/lama/.ssh/id_rsa type -1
    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1
    debug3: Not a RSA1 key file /home/lama/.ssh/id_dsa.

    So your files in .ssh are screwed up.

    So it appears that the connection is established:
    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.
    debug1: Connection established.
    debug1: identity file /home/lama/.ssh/id_rsa type -1
    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1
    debug3: Not a RSA1 key file /home/lama/.ssh/id_dsa.

    But somehow the ssh module does not correctly parse the
    key files, that is the comment lines starting with "----".

    Well, look at that key file.


    Any hints, suggestions as t what might be going on, will
    be gratefully appreciated. I apologize for the long post,
    and thanks in advance for your help.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobbs.
  • From dakupoto@gmail.com@1:0/0 to All on Sun Sep 15 06:28:21 2013
    On Saturday, September 14, 2013 6:20:47 AM UTC-4, Trevor Hemsley wrote:
    On Sat, 14 Sep 2013 02:46:22 UTC in comp.os.linux.security,
    dakupoto@gmail.com

    wrote:



    I am trying to

    ssh from a Fedora 15 box to a Raspberry Pi Model

    B SBC running OpenELEC 2.99.5. Both have static

    IPs on the same network, behind a small D-Link

    router. The ssh port on the Fedora box's firewall

    is open, for now. The first thing that seems out

    of place is that I cannot ping the Raspberry Pi

    from the Fedora box.That is if I use the static

    IP address of the Raspberry Pi, I get:



    ping 192.168.1.2

    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.

    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited



    192.168.1.2



    However, if I just use the default hostname of

    Raspberry Pi, I get:

    ping openelec

    PING openelec.localdomain (192.168.1.1) 56(84) bytes of data.

    64 bytes from 192.168.1.1: icmp_req=1 ttl=254 time=0.304 ms



    192.168.1.1



    Which one is it really? 1 or 2?



    From the symptoms, given that I know that openelec has an iptables policy of

    ACCEPT on all chains, I'd say that your "dns" entry is pointing at your
    Fedora

    host.



    --

    Trevor Hemsley, Brighton, UK

    Trevor dot Hemsley at ntlworld dot com

    Well, I checked the network manager on my Fedora box,
    and it says clearly that both the default gateway and
    DNS addresses are 192.168.1.1. All IPs are set statically
    on the LAN.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobbs.
  • From dakupoto@gmail.com@1:0/0 to All on Sun Sep 15 06:42:01 2013
    On Saturday, September 14, 2013 12:46:37 PM UTC-4, unruh wrote:
    On 2013-09-14, dakupoto@gmail.com <dakupoto@gmail.com> wrote:

    Could some Linux/ssh guru please help me with

    this ssh authentication issue ? I am trying to

    ssh from a Fedora 15 box to a Raspberry Pi Model

    B SBC running OpenELEC 2.99.5. Both have static

    IPs on the same network, behind a small D-Link

    router. The ssh port on the Fedora box's firewall

    is open, for now. The first thing that seems out

    of place is that I cannot ping the Raspberry Pi

    from the Fedora box.That is if I use the static

    IP address of the Raspberry Pi, I get:



    ping 192.168.1.2

    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.

    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited



    However, if I just use the default hostname of

    Raspberry Pi, I get:

    ping openelec



    Uh, you do see the difference between the IP numbers don't you?
    From the OpenELEC screen menu bar, if I navigate:
    System -> System Info -> Network, I see that the static IP
    address of the Raspberry Pi is : 192.168.1.2 and the default
    gateway is 192.168.1.1, as expected. Only the Raspberry Pi's
    DNS address is not set to any value. If I ping on the 192.168.1.2
    address, I get:
    ping 192.168.1.2
    PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
    From 192.168.1.2 icmp_seq=1 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=2 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=3 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=4 Destination Host Prohibited
    From 192.168.1.2 icmp_seq=5 Destination Host Prohibited
    .......
    .......




    PING openelec.localdomain (192.168.1.1) 56(84) bytes of data.

    64 bytes from 192.168.1.1: icmp_req=1 ttl=254 time=0.304 ms



    The inconsistenct between the two results is not clear.



    Your dns is telling you that openlec is not the IP address you claim

    that the RPi has.
    Is it not true that the default hostname of the Raspberry Pi
    is openelec ?







    Please note that I have used ssh-keygen on the Fedora

    box to generate the DSA keys. I have tried RSA keys as well,

    but no luck.

    So, if I try to ssh from the Fedora box to the Raspberry Pi,

    I get:

    ssh root@192.168.1.2 -vvv

    OpenSSH_5.5p1, OpenSSL 1.0.0e-fips 6 Sep 2011

    debug1: Reading configuration data /etc/ssh/ssh_config

    debug1: Applying options for *

    debug2: ssh_connect: needpriv 0

    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.

    debug1: Connection established.



    OK, so 192.168.1.2 has an ssh deamon listening on port 22
    That is exactly the issue. Both devices can recognize
    each other, but not authenticate.



    debug1: identity file /home/lama/.ssh/id_rsa type -1

    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1

    debug3: Not a RSA1 key file /home/lama/.ssh/id_dsa.



    So your files in .ssh are screwed up.



    So it appears that the connection is established:

    debug1: Connecting to 192.168.1.2 [192.168.1.2] port 22.

    debug1: Connection established.

    debug1: identity file /home/lama/.ssh/id_rsa type -1

    debug1: identity file /home/lama/.ssh/id_rsa-cert type -1

    debug3: Not a RSA1 key file /home/lama/.ssh/id_dsa.



    But somehow the ssh module does not correctly parse the

    key files, that is the comment lines starting with "----".



    Well, look at that key file.
    Key files have been re-generated several times using ssh-keygen
    using RSA 1, RSA 2 and DSA. No luck.





    Any hints, suggestions as t what might be going on, will

    be gratefully appreciated. I apologize for the long post,

    and thanks in advance for your help.




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobbs.