SSH Key based user level access problem.

[Charles Harris]

Dear all,

I'm currently struggling to get ssh password-less logins to work. I've 18 host machines that I need seamless access between all running HPUX 11.x with OpenSSH_3.7.1p2-pwexp26, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
HP-UX_Secure_Shell-A.03.71.000, HP_UX Secure Shell versions.....
I've created a .ssh directory for every user that requires equivelent access, with 700 permisions and created the id_dsa.pub / id_dsa.
I've added all the key file from all hosts to the authorized_keys file and for 14 out of the 18, everything works. On the other machines, every time I ssh to the host, it askes me for a password!?
The Debug output is as follows:

debug1: Authentications that can continue: publickey,password,keyboard-interactve^M
debug2: we did not send a packet, disable method^M

Any ideas?!

Any help comments, tips, RTFM's etc warmly received as ever!!

Thanks,

-=ChaZ=-

[Charles Harris]

....bit more info:

The very verbose debug output states:
debug2: we did not send a packet, disable method

just before it falls back to password based authentication, although on the working servers, this line is never seen in the logs.

Again any help, comments, suggestions greatfully received!

Cheers,

-=ChaZ=-

[Florian Heigl (new acc)]

Points You didn't mention:
- ownership / permissions of user's home directory
- have target machines dsa hosts keys?
I could imagine there could be problems due to rsa/dsa mismatches.

Last last I bite my teeth out on this one I had accedentially called the file .ssh/authorized.keys instead of ..._...

Unfortunately, with this type of problem the -vv option doesn't help a lot, better check the target hosts' syslogs.

[Charles Harris]

Hi,

Thanks for the tips, unfortunately I have no access to the syslog's on the servers in question, so no luck there....
The .ssh dir has 700 permissions and everything under it ix 755 apart from id_dsa. I've double checked the permissions to no avail.
The authorised_keys, bit me once, but this time all file names are correct!

Any more pointers warmly received!

Cheers,

ChaZ

[Florian Heigl (new acc)]

no syslog? what stupid os has syslog not world-readable?

anyhow - see man ssh_config for dedicating a log file in the users homedir and more fancy logging.

[Charles Harris]

Thanks, I'll reconfigure the ssh config to log locally.... I hope it gives me something more useful to go on! - Shame I can't do the same for the sshd_config on the remote end....

Other than permissions (which are all to spec) and the files, has anyone come across a similar situation? - I've googled and seen the same errors, but no fixes as yet....

Cheers,

ChaZ

[Charles Harris]

....er... setting the log level in ssh_config on the client just reveals the same verbose messages as the -vvv command line!

Any other ideas (please, starting to get desperate now!! ;-)

Cheers,


ChaZ

[Florian Heigl (new acc)]

*cough* - don't mean to put You on the wrong track, but:

sshd_config:
#PubkeyAuthentication yes

ensure this is set and done, if that were for some reason disabled You would search until the very end of time [*]




[*](that would be when Ry'leh comes back on earth, for the lovecraftian's among us)

[Con O'Kelly]

Hi Charles

Sounds like you have covered all the bases.
The output
"debug2: we did not send a packet, disable method" is the key to your problem.

Unfortuntaely its fairly generic. This message could indicate:
- no entry in "authorized_keys" file
- incorrect entry in "authorized_keys file

I'd also check the following parameter in sshd_config.
PubkeyAuthentication yes
If its set to no, you'll also get this message.

Don't know if this will help but worth a try.

Cheers
Con

[Charles Harris]

Thanks for the great replies, unfortunately I'm still non the wiser..... I can't change the sshd_conf because I've not got root access to the remote servers..... so no joy there....

Con: Thanks for the confirmations, I'm sure everything is fine, all configs / permissions / server & client options in the conf files are the same! The *only* difference between the remote hosts that work and the ones that don't are the inetd.sec files. Although inetd.sec has no port 22 defined, maybe there is a generic rule that is messing things up.....

Incidently, the sshd_config's on all machines don't include the line to explicitly allow host/key based authentication although the some of them work....

Very strange!?!

Any other pointers / suggestions / comments warmly received as ever!!

Thanks for the help so far,

-=ChaZ=-

[Florian Heigl (new acc)]

The generic rule would look like all:all:deny

If that publickey line is missing and You don't have root access, kindly ask the root person to set it for debugging. As this represents an increase in security, he could hardly be against it :)

also, cksum the authorized_keys files maybe there's a line wrap in there.

[Charles Harris]

Haven't checked the inetd.sec, although thinking about it, if there was a deny filter, the connection would never get established in the first place....

I've tried re-creating the pub / host keys again too, still no joy. I've generated rsa and dsa keys but again nothing good to report.....

The error implies that the client is not doing or getting something, although if I use the same client (server) I can ssh as other users to the working machines......

If anyone else has anything else to offer, I'd really appreciate it!!! - Having sold ssh as the answer to our prayers, it's starting to get on my nerves now.....

Thanks again,


ChaZ

[Florian Heigl (new acc)]

Please try to exclude the publickeyauth yes (or whatever) parameter being wrong. have the system administrators explicitely set it and restart sshd.
It kind of smells like it.

[Gordon Morrison_1]

You might also want to check the following line in sshd_config on the hosts where it isn't working:

#AuthorizedKeysFile .ssh/authorized_keys

If is is uncommented and set to anything OTHER than .ssh/authorized_keys, I think that could explain it (or it could be 1 of 256 other things :o/)

[Charles Harris]

Thanks again for the tips, I've attached the logs from -vvv from bloth the client and a new sshd server I'm running on the remote end as a user (with comparible params / permissions etc)
if anyone can assist with deciphering the logs and pointing me towards a fix I would be eternally greatful (and will consider spell checking further posts ;-)

Thanks again for the help so far!!!!!

-=ChaZ=-

[Charles Harris]

Only one attachment at a time? ...... here's the client log.....


Thanks!

-=ChaZ=-

[Con O'Kelly]

Hi (again) Chaz

Perplexing problem you have!

Don't want to repeat what you've said but can I confirm your problem as follows:

Client A (user "gnsadm") can connect to "gnsadm" user account on "neutron" using Publickey authentication. Client B (User "gnsadm") cannot connect to "gnsadm" user account on "neutron" with publickey authentication and is prompted for password.

From the log files it appears very much to be a problem with the public key entry in the authorized_keys file. It appears publickey is a recognised authentication method but the server is not recognising the public key thats been sent.

Perhaps its worth comparing the sshd log on the server for a client connecton that succeeded and one that failed.

Don't know if you have it but have attached a doco on HP-SSH. Might be useful.

http://newfdawg.com/docs/HP-SSH_Explained.PDF

Cheers
Con

[Charles Harris]

Thanks Con,

Yes as you deduced, the scenario is exactly as you state. The log file does look like it's having a problem with the id_dsa.pub key although I've check all permissions and even run the server side configuration on another port so that I can check the logging (I have no root access to the neutron side....) but all to no avail. I removed all of the users'd id's and regenerated them, but still get the same connection problem. I'm at a total loss now...
I've read and re-read all the documents I've found and can see nothing wrong at all.

I'm going to try creating another set of ID's of both rsa and dsa flavours to see if that gives any different errors.

I'll update as soon as I've something to report!!!

Thanks again for the support (I was a bit shocked to see a *cough* hostname appear, I guess both my sed and spelling skills have also left me.... ;-)

Cheers,

-=ChaZ=-

[Andrei Lica_1]

it seems to be a problem with permisions. It always was for me.

Check to have 700 on .ssh , owner and group to be your user/group or start with a rm -rf .ssh
Check also the parent directory ( /home/user ) -> 755
It's better to first create the key ( ssh-keygen -t dsa ). This will create .ssh for you

On remote, same steps. ( ssh-keygen -t dsa is not needed but it doesn't hurt )
Then transfer the public key id_pub.dsa to remote host and :
cat id_dsa.pub >> ~/.ssh/authorized_keys2
Make sure you don't have 2 keys ( in .ssh/authorized_keys2 ) for the same host

[Travis Harp_1]

Does this happen to be a Trusted system?
I had a similar problem about a year ago and it turned out to be an issue with the non hp (meaning it wasn't from an hp depot) version of ssh and my trusted systems.

Once trusted was turned off it worked correctly, the fix we used was to install the hp .depot version of ssh and all was well.

[Charles Harris]

Thanks again for the tips, I've already re-generated all directories / id's and even started the services as an authorised user (local login) on another port so that I can examine more closley the sshd behavour, all to no avail.

There are a few other interesting things to consider, the suggestion of installation method is interesting, I'm not sure if the sshd (although it's an HP release) was installed via a depot, so I'll confirm. All of the host systems are trusted, but some work as expected and the other's don't so I'm not sure if this is a factor.

I have also spotted the RNG package on working systems so will compare against the non-workers to see if it's missing.

Thanks again for everyones help / tips / info, this is turning into quite a monster thread!!! - When I get it fixed, I'll post the complete solution although I just hope it's nothing as trivial as directory permissions!!!!

Any further comments / tip / suggestions warmly received as ever!!!

Cheers,

-=ChaZ=-

[Charles Harris]

Dear All,

After what seems like an eternity of wrong, I've managed to get it going with all of your help!!

A big thanks for everyone's suggestions and reading materials!

Ok: The problem was 2 fold (I'm not sure which one fixed the issue)

1: The RNG kernel based random number generator was not installed on the problem machines. (unlikley to have resolved the problems as it's only used to seed the id's) although new id's created after installation did eventually work...

2: The sshd sw was part of an ignite image on the 'broken' servers, re-installed from depots.

Created new dsa id_dsa.pub's with the new sw, swapped keys in the usual fashion, everything worked!

Thanks again for the support!

-=ChaZ=-

[Charles Harris]

Please see the PP!

Thanks again,


-=ChaZ=-

[Anju..]

Hi Charles,

I know that this thread was closed long time back,but I need a help from you.I am not able to make a passwordless secure connection to a HP_UX m/c.The debug logs are same as yours.Password prompt is coming up whenever I try to connect to HP_UX. Can you please tell me the steps that you did to resolve this issue?

Thanks in advance,
Anju