SSH asking for password when it shouldnt - SCO

This is a discussion on SSH asking for password when it shouldnt - SCO ; Here is the debug output that i get when i do ssh and try to login into a remote server: OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: SSH asking for password when it shouldnt

  1. SSH asking for password when it shouldnt

    Here is the debug output that i get when i do ssh and try to login into

    a remote server:
    OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to serv1.vtu.org [202.134.239.18] port 22.
    debug1: Connection established.
    debug3: Not a RSA1 key file /home/thecoolone/.ssh/id_rsa.
    debug2: key_type_from_name: unknown key type '-----BEGIN'
    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/thecoolone/.ssh/id_rsa type 1
    debug1: Remote protocol version 1.99, remote software version
    OpenSSH_3.1p1
    debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_3.9p1
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit:
    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,arcfour,aes192-cbc,aes256-cbc,rijndael-...@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-...@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96

    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@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-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

    debug2: kex_parse_kexinit:
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96

    debug2: kex_parse_kexinit:
    hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd...@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: 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: 122/256
    debug2: bits set: 488/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename
    /home/thecoolone/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug3: check_host_in_hostfile: filename
    /home/thecoolone/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host 'serv1.vtu.org' is known and matches the RSA host key.
    debug1: Found key in /home/thecoolone/.ssh/known_hosts:1
    debug2: bits set: 511/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/thecoolone/.ssh/id_rsa (0x82c2ee8)
    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive
    debug3: start over, passed a different list
    publickey,password,keyboard-interactive
    debug3: preferred
    gssapi-with-mic,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/thecoolone/.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
    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
    I have checked for the permissions of $HOME it is 755 and $HOME/.ssh is

    700
    drwxr-xr-x 4 thecoolone thecoolone 4096 Dec 1 03:53 thecoolone
    drwx------ 2 thecoolone thecoolone 4096 Dec 1 03:36 .ssh
    -rw-r--r-- 1 thecoolone thecoolone 232 Apr 9 2006 id_rsa.pub
    On debug3: is is saying "Not a RSA1 key file
    /home/thecoolone/.ssh/id_rsa."
    and then later "debug1: identity file /home/thecoolone/.ssh/id_rsa type

    1"
    I am not understanding that why at first it says not an RSA type and
    then
    recognises it as type 1?
    Does anyone have a clue on how to make ssh work with passphrase. It was

    working before i tried to make a new crontab for another account and
    now i am reverting back to the old crontab and ssh is asking password.
    Why is the old crontab not working any more?


  2. Re: SSH asking for password when it shouldnt


    > I am not understanding


    Nor I am I understanding why you keep posting this crap

    DAve

  3. Re: SSH asking for password when it shouldnt

    thecoolone wrote:
    >
    > Here is the debug output that i get when i do ssh and try to login into


    Posting that mess 3 times within 40 minutes will not endear you to
    anyone. Learn how usenet works. Google is not usenet, it is only
    a lame interface to it.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.




  4. Re: SSH asking for password when it shouldnt


    CBFalconer wrote:
    > thecoolone wrote:
    > >
    > > Here is the debug output that i get when i do ssh and try to login into

    >
    > Posting that mess 3 times within 40 minutes will not endear you to
    > anyone. Learn how usenet works. Google is not usenet, it is only
    > a lame interface to it.
    >
    > --
    > Chuck F (cbfalconer at maineline dot net)
    > Available for consulting/temporary embedded and systems.
    >


    He has not yet explained why he's posting to a Linux group and a SCO
    group.
    If the server side of this is an older SCO box, that could explain much
    (because SCO never had ssh until very recently and adding it to some
    older versions could easily be screwed up).

    Also, his posts seem contradictory: crontab didn't work, it did,
    command line worked, it doesn't.... I have no idea what the heck is
    really going on.

    I wash my hands of him. Too hard to extract information.

    --
    Tony Lawrence
    Unix/Linux/Mac OS X Resources
    http://aplawrence.com


  5. Re: SSH asking for password when it shouldnt


    ----- Original Message -----
    From: "Tony Lawrence"
    Newsgroups: comp.security.ssh,comp.os.linux.misc,comp.unix.sco .misc
    To:
    Sent: Friday, December 01, 2006 8:10 AM
    Subject: Re: SSH asking for password when it shouldnt


    >
    > CBFalconer wrote:
    >> thecoolone wrote:
    >> >
    >> > Here is the debug output that i get when i do ssh and try to login into

    >>
    >> Posting that mess 3 times within 40 minutes will not endear you to
    >> anyone. Learn how usenet works. Google is not usenet, it is only
    >> a lame interface to it.
    >>
    >> --
    >> Chuck F (cbfalconer at maineline dot net)
    >> Available for consulting/temporary embedded and systems.
    >>

    >
    > He has not yet explained why he's posting to a Linux group and a SCO
    > group.
    > If the server side of this is an older SCO box, that could explain much
    > (because SCO never had ssh until very recently and adding it to some
    > older versions could easily be screwed up).
    >
    > Also, his posts seem contradictory: crontab didn't work, it did,
    > command line worked, it doesn't.... I have no idea what the heck is
    > really going on.


    The problem is neither does he.
    As in, I don't think he should be attempting to mess with this but instead
    find the guy who originally set it up.

    Or, at least he should realise right now that he's completely in the weeds
    and should not expect it to work any time soon and should expect to spend
    some time learning some things piece by piece for while first and only after
    he understands how this all works _then_ expect to make it work. First he
    has to learn how to ask a question, then how to answer a question, then how
    to perform a suggested action, _then_ the process of solving the actual
    problem can go relatively quickly in probably just a few steps.

    If he knew that he was learning at this point and not doing, I wouldn't mind
    helping out with that.
    Having absolutely no clue what you're doing is not a crime to me.

    It's the ones who have absolutely no clue what they are doing, but expect it
    all to work by magic, immediately, and they do random things ranging from
    amuzing and harmless all the way to destructive along the way and don't do
    the things people who do know what they're doing suggest and don't answer
    diagnostic questions. Those are the ones I don't even start to help. What's
    the point? All that happens is you open yourself up to them thinking you are
    responsible for whatever disaster they inflict on their system.

    I think there is entirely too much caffein in the IT world today and not
    enough people who understand that the _only_ way to make things work is by
    deliberate, systematic, scientific, approaches. The slow road is actually
    the _fastest_ road, since that way you go in a straight, shortest path, line
    from problem to solution instead of wandering all over the place at random.

    In this case that means, learn what the hech ssh even is before expecting
    some special script that uses ssh in a fancy way to work. You can't skip
    ahead to making the script work.

    Don't wanna take the time to read about ssh and perform manual tests to try
    out the various things like how to make keys and use them? And along the way
    learn about all the other related issues that might be affecting the
    ultimate goal like ip routing, name resolution, nat forwarding and firewall
    rules, differences between the two platforms that change the behaviour of
    ssh, or discover that maye you don't even need or want ssh at all to get
    this job done, etc...?

    No problem. Thats exactly what consultants who have already done all that
    are for.

    Don't wanna pay a consultant?

    No problem. I think enough are willing to help a person who is willing to
    actually learn the stuff. And the help will be good from here. A real fast
    track to having a clue. I highly recommend this option. Even though that
    means me (or someone) spending way more time helping you for free than it
    would have taken to just do the job myself and get paid for it besides.

    Don't wanna pay a consultant OR spend the time & effort to learn the stuff
    yourself (even with the help of others which will drastically reduce the
    difficulty and time needed)?
    No problem. For me anyways. I have a jeuvenile streak that derives
    entertainment from seeing people going so far out of their way to hurt
    themselves and then wondering why the world hates them, and so I'll be quite
    entertained by the whole episode.

    Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


+ Reply to Thread