SSH authentication issues

[dictum9]

I am trying to ssh from one box to another and I get this. Abruptly, it says "Connection closed"

All the keys look right.
Should I try regenerating the keys, or upgrading the ssh version?
I can ssh to target machine from other machines without issues.


source:
# uname -a
HP-UX B.11.00 U 9000/800 567720518 unlimited-user license

target:
# uname -a
HP-UX B.11.00 A 9000/899 1699411321 two-user license



source
#:ssh -v
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f

target:
#: ssh -v
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f


#:ssh -v sys22
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Seeded RNG with 36 bytes from programs
debug1: Seeded RNG with 3 bytes from system calls
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 1
debug1: Connecting to sys22 [111.111.11.11] port 22.
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0p1
debug1: match: OpenSSH_3.0p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 112/256
debug1: bits set: 494/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sys22' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:43
debug1: bits set: 515/1024
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /.ssh/id_rsa
debug1: try pubkey: /.ssh/id_dsa
Connection closed by 111.111.11.11
debug1: Calling cleanup 0x4000a8fa(0x0)
debug1: Calling cleanup 0x4000a902(0x0)
debug1: writing PRNG seed to file //.ssh/prng_seed

[Jaime Bolanos Rojas.]

etc,

check the permissions for the home directory, they should be 755

Regards,

Jaime.

[dictum9]

Home directory of what? I am trying to ssh as root.

$HOME/.ssh is chmoded to 700, recursively.

[Ralph Grothe]

Jaime was referring to the user's home dir on the remote ssh server.
You can verify if this was the cause by checking syslog output from the remote sshd for facility auth.
Since StrictModes yes is the default setting
there will appear such an error message in the remote host's logfile for auth.
Besides, another common reason is an inactive, locked or expired remote user account.
But this will also be messaged by the remote sshd.

[Ralph Grothe]

Forgot you mentioned you were trying to login as root.
Also check this on remote host:

# grep PermitRootLogin /opt/ssh/etc/sshd_config
#PermitRootLogin yes


Is it set to "no"?

[dictum9]

Strangely, the only ssh config files I have on the system is in:

/usr/local/etc/ssh*config

And the rootlogin is set to "yes". Could it be it's missing /etc/ssh/* stuff?

And if so, why can I ssh to this box from other systems?

[Marco A.]

Are you able to connect to the the other box by using telnet?

If so, check in the /etc/services file for the line with the port 22 .

ssh 22/tcp #secure Shell

Also check your /etc/hosts.allow , and DNS lookup, could be refused because is not finding the hostname.

To check is the daemon is running ..
# ps -ef |grep -i ssh

[Ralph Grothe]

Sorry, I haven't read your session dump carefully enough.
You are using an older SSH version than me,
and also not the HP Secure Shell depot as it seems.
Then you will have different paths,
and your system wide config files won't be under /opt/ssh/etc but in /usr/local/etc.

For some strange reason does the remote sshd close the connection.
I'm not sure if we can see more if you increase the verbosity level by rerunning

ssh -vv sys22

Note, that older SSH versions kept the RSA public keys in separate files (e.g. authorized_keys2 for protocol 2).
But this doesn't seem to be relevant here.
Maybe you could also check if you have some strange protocol versions in the server's sshd_config file?

[Denver Osborn]

Can you startup another sshd listener on another port and collect debug output from both client and server. Seeing the server side of things might help you find why the connection is closed.

# server
sshd -e -ddd -p 2222

# client
ssh -vvv -p 2222 server


-denver

[dictum9]

I will post the output of the above shortly.

The really strange thing is that I can connect via ssh to the target machine from *other* machines, in fact from any other machine it seems.

It seems there is a problem with the *source* machine more than anything. The machine I am trying to ssh from.

[dictum9]

server:

debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
WARNING: /usr/local/etc/moduli does not exist, using old modulus
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 132/256
debug1: bits set: 516/1024
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 509/1024
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for root
debug2: input_userauth_request: try method none
Failed none for ROOT from 111.11.111.111 port 53778 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/0 (e=0)
debug1: trying public key file //.ssh/authorized_keys
debug3: secure_filename: checking '/.ssh'
debug3: secure_filename: checking '/'
debug3: secure_filename: terminating check at '/'
debug2: key_type_from_name: unknown key type '1024'
debug3: key_read: no key found
debug2: user_key_allowed: check options: '1024 35 136398728465190821034871912145838516596303036487925155538098452813700003069478658967024510543427022061612281208696643344459309998769765682282204366914887313212530014076342051534857307586986141206143361430343700033554381297239013822574969382295076967914136196951473445916705157240356449864763054379769578529143 root@sys21
'
debug2: key_type_from_name: unknown key type '35'
debug3: key_read: no key found
debug2: user_key_allowed: advance: '35 136398728465190821034871912145838516596303036487925155538098452813700003069478658967024510543427022061612281208696643344459309998769765682282204366914887313212530014076342051534857307586986141206143361430343700033554381297239013822574969382295076967914136196951473445916705157240356449864763054379769578529143 root@sys21
'
buffer_get: trying to get more bytes 4 than in buffer 0
debug1: Calling cleanup 0x40008dfa(0x0)
debug1: Calling cleanup 0x40008e02(0x0)
debug1: writing PRNG seed to file //.ssh/prng_seed
debug1: WARNING: PRNG seedfile //.ssh/prng_seed must be mode 0600, owned by uid 0







client:

c-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: 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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 123/256
debug1: bits set: 509/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: match line 43
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: match line 43
debug1: Host 'sys22' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:43
debug1: bits set: 516/1024
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
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 auth method to try is publickey
debug1: try privkey: /.ssh/id_rsa
debug3: no such identity: /.ssh/id_rsa
debug1: try pubkey: /.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by 111.11.111.11
debug1: Calling cleanup 0x4000a8fa(0x0)
debug1: Calling cleanup 0x4000a902(0x0)
debug1: writing PRNG seed to file //.ssh/prng_seed
debug1: WARNING: PRNG seedfile //.ssh/prng_seed must be mode 0600, owned by uid 0

[Rasheed Tamton]

>debug1: WARNING: PRNG seedfile //.ssh/prng_seed must be mode 0600, owned by uid 0


As the error says, please change the permission on the file //.ssh/prng_seed to 600 and the owner should be root.

[Ralph Grothe · Accepted solution]

I'm not convinced that it owe to the permissions of the seedfile.
It's merely a warning.
I rather suspect that there may be something wrong with your DSA key of your ssh client.
Could you please try to skip public key authentication by reconnecting from the client with something like this:

# ssh -vv -o PreferredAuthentications=password sys22

You maybe could also try to generate a new key pair and append this new pair's public key to root's .ssh/authorized_keys on the SSH server?

On client run

# ssh-keygen -t rsa -b 1024 -N "" -f ~/.ssh/id_rsa_test

Append it somehow to autorized_keys on remote host (while ssh isn't yet working execeptionally maybe even by ftp, rcp or sneaker copy (viz. mobile data source))

Then retry, this time referring to newly created key

# ssh -v -i ~/.ssh/id_rsa_test sys22

[dictum9]

Ralph Grothe

You hit the bullseye with this, it worked with "-o PreferredAuthentications=password" and also with the test generated RSA key pair.

When I generated a new key pair with RSA, it worked, but when I tried DSA, (-t dsa) it didn't. Interesting, I've only generated DSA keys in the past.

[dictum9]

Should I regenerate public/private keys on the client?

[Steven E. Protter]

Shalom,

On the client and server, I generate a public/private key merely so that a directory exists in which I can place an authorized_keys file.

Otherwise if the client does not have a public private key, how is it going to pass a key back and forth.

Most procedures for ssh use, including those authored by me call on generating a key set on all workstations. This may indeed be required to achieve your goal.

SEP