topic Re: SSH authentication issues in Operating System - HP-UX

SSH authentication issues

dictum9 — Thu, 16 Nov 2006 10:33:32 GMT

This is on 11.11

I restored the passwd file and /tcb encrypted passwd database. (The system wasn't trusted and I hope it made it trusted). Telnet still works but it broke ssh and I cannot figure out why. The UID seem to be consistent between the home directories and the passwd file.

I even tried generating new keys to no avail.

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
debug3: Not a RSA1 key file /.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /.ssh/id_dsa type 2
ssh_exchange_identification: Connection closed by remote host
debug1: Calling cleanup 0x4000a8fa(0x0)
debug1: Calling cleanup 0x4000a902(0x0)
debug1: writing PRNG seed to file //.ssh/prng_seed

Re: SSH authentication issues

Ivan Ferreira — Thu, 16 Nov 2006 10:44:49 GMT

Use cat -e to check your public key, it seems that some extra characters are in the file:

debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'

As if the file where break in the BEGIN/END blocks. It should look like:

---- BEGIN SSH2 PUBLIC KEY ----
---- END SSH2 PUBLIC KEY ----

Re: SSH authentication issues

Jaime Bolanos Rojas. — Thu, 16 Nov 2006 10:48:25 GMT

Etc,

Looks like I got confused:

"I restored the passwd file and /tcb encrypted passwd database. (The system wasn't trusted and I hope it made it trusted)."

What do you mean the system was not trusted, but you trusted by restoring the /tcb database...?

Regards,

Jaime.

Re: SSH authentication issues

dictum9 — Thu, 16 Nov 2006 10:53:09 GMT

I figured out what the problem was. The newly restored /etc/passwd did not have the sshd user. I was fairly certain that the backed up file from the old system did have it, but it didn't. It had ssh for sure. But I upgraded ssh and now it seems to require a user in /etc/passwd.

Anyway, it works now.

Re: Trusted system --- Here is the deal, the system crashed and I installed an entirely new OS and restored /etc/passwd and /tcb/* tree. The new system off the DVDs was not trusted and I think that by restoring the /tcb tree and /etc/passwd I made it trusted. I hope some weird errors don't come up in the future.

Re: SSH authentication issues

Jaime Bolanos Rojas. — Thu, 16 Nov 2006 11:01:11 GMT

etc,

looks like it's working for you. I would have trusted the system first and then override the /tcb and /.secure

Do not really know if your steps are supported but it's working so far.

Regards,

Jaime.

Re: SSH authentication issues

dictum9 — Thu, 16 Nov 2006 11:27:54 GMT

That's true. What other things happen when you make a system trusted? In other words, when you make a system trusted manually, by restoring the /tcb directory, are there any important files left out?

Re: SSH authentication issues

Jaime Bolanos Rojas. — Thu, 16 Nov 2006 13:26:11 GMT

Etc,

Looks like this is all that it does:

Creating secure password database...
Directories created.
Making default files.
System default file created...
Terminal default file created...
Device assignment file created...
Moving passwords...
secure password database installed.
Converting at and crontab jobs...
At and crontab files converted.

Regards,

Jaime.