On Jun 28, 2004, at 5:53 PM, G Chinnery wrote:
su ed to root su ed to apache to set up my id_rsa and id_rsa.pub keys and those are in /var/www/.ssh
had to copy the id_rsa.pub to /home/max/.ssh to scp it across to apollo:/home/max/.ssh/id_rsa.key then did what I had to do to the key.
ended up with authorized_keys file in /max/.ssh dir.

OK, so /var/www/.ssh/id_rsa* are owned by the apache user on the server. That's correct.


/var/www/.ssh/id_rsa.pub was copied to /home/max/.ssh - by which user? I guess root did it, so it may not have the right ownership. This will make no difference on the server, because no-one connects to it ...

id_rsa.pub was scp'd to apollo. I think you might have done this as the user 'max', because of your comment about copying. I presume that 'what you had to do' was to rename or copy this file and call it '/home/max/.ssh/authorized_keys' ?

You will need to copy that authorized_keys file from the /home/apache/.ssh directories to /home/max/.ssh to be able to use "ssh -l max". When ssh tries to connect with the username "max", it will only look in "/home/max/.ssh" for keys.

I still get asked for a password when I run the script, (should I call it a CGI? ) from a shell, and if I su to apache and run a command like...


ssh -v -l max apollo uname -a

I get a request for a password from max at apollo.

OK, how about sending the output of that ssh -v command? I'm only interested in the section following on from the first occurrance of "debug1: Authentications" ...

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/jim/.ssh/identity
debug1: Trying private key: /Users/jim/.ssh/id_rsa
debug1: Trying private key: /Users/jim/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password


This unfortunately only tells us what the client is trying (i.e. your server) and not what the internal state of the remote server (apollo) is ... but it's a start.

I'm hoping that we will see the correct key file being "offered". If so, the problem is on apollo, and will probably be related to the permissions and ownership of the files in ~max/.ssh. If you could also include an 'ls -la' from that directory, that would be good.

-jim



Reply via email to