openssh login without typing password?

[gosuc]

Hi gurus,

I have openssh installed and managed that dsa (rsa) authentication takes place without asking the passwd-phrase for RSA resp. DSA.
My problem is, that the normal account-password is still being asked when establishing a ssh-connection. After typing in the login-password, the rsa-authentication processs takes place without asking the passwd-phrase (as desired).
Is there a way, to avoid to login-password for the account?
The reason is, that I have to monitor some remote hostactivity via
ssh by some script that starts automatically, so there is no way for some password-dialog.

Any help is very welcome.

regards,

Fred

 

[fluid11]

Connnect FROM comp = Tiger (192.168.1.81)
Connect TO comp = Lion


From Tiger...

ssh-keygen -t dsa
(when asked for location and password, just press enter)
scp ~/.ssh/id_dsa.pub root@lion:/root


From Lion...
cat /root/id_dsa.pub
ssh-dss AAAB3NzaC1kc3MAAACBAPDKnsR29YiaAgjBbqIGh/78NXjNRA3fwjMFVjv3WE9wLc8TUvxhE7lBk9kBbu2s5Ny4bvm5ZMREebKd1fsoAoXaXA8jgBb84jbsBu6QTBhFgH7iRHSCeogvirzV2EZtgsL0vQtvrVaTT5VeNgkPEPERLymGo2uJB7yrbNMkwyBxAAAAFQDxH4VVE6I0kob6zjFrgS5gPppGfwAAAIEAwwL1MWM16isiEpeJO+H9cBOcjBsHJsYzRAd5Z3kOV9DZ7ZhBK6Ljd+bk6zyEygcq6dXu1P1DqRlEUXtS9LxzO0pVsNZQFn0sf2fT/4ET4N7MbFiHJun1IfEfUV//NZJq8NX2GrN1lhmI9bhidNYMD+AJcLPn1ewh2XUxPn0NiIgAAACAMugkdgXuPwdMKLQmaZeb8ufCvrqN+rnAiBWmplOSvw3ccwN+Xjp5PHgnyn4CVkHo4q/AQYPJXJGePb1lt0BxyJri5aqvBWjq9SPnKyfQDPxaFuglbxt4d5hhMqtUZU3HnRR7QGJ3V6glydBB1ZlqExWWdgkqijyVY47wPFGdafY= root@tiger

Open id_dsa.pub with vi and prepend from=tiger

cat /root/id_dsa.pub
from="192.168.1.81" ssh-dss AAAAB3NzaC1kc3MAAACBAPDKnsR29YiaAgjBbqIGh/78NXjNRA3fwjMFVjv3WE9wLc8TUvxhE7lBk9kBbu2s5Ny4bvm5ZMREebKd1fsoAoXaXA8jgBb84jbsBu6QTBhFgH7iRHSCeogvirzV2EZtgsL0vQtvrVaTT5VeNgkPEPERLymGo2uJB7yrbNMkwyBxAAAAFQDxH4VVE6I0kob6zjFrgS5gPppGfwAAAIEAwwL1MWM16isiEpeJO+H9cBOcjBsHJsYzRAd5Z3kOV9DZ7ZhBK6Ljd+bk6zyEygcq6dXu1P1DqRlEUXtS9LxzO0pVsNZQFn0sf2fT/4ET4N7MbFiHJun1IfEfUV//NZJq8NX2GrN1lhmI9bhidNYMD+AJcLPn1ewh2XUxPn0NiIgAAACAMugkdgXuPwdMKLQmaZeb8ufCvrqN+rnAiBWmplOSvw3ccwN+Xjp5PHgnyn4CVkHo4q/AQYPJXJGePb1lt0BxyJri5aqvBWjq9SPnKyfQDPxaFuglbxt4d5hhMqtUZU3HnRR7QGJ3V6glydBB1ZlqExWWdgkqijyVY47wPFGdafY= root@tiger


cat id_dsa.pub >> /root/.ssh/authorized_keys



From Tiger...

Now you should be able to run ssh commands with entering a password...

ssh root@lion echo "success"
success




ChrisP

 

[shadedecho]

OK, server 1 is referred to as "rosebud" on our local internal network, and has 192.168.0.9 as its IP address. server 2 is referenced by the xxx.xxx.xxx.xxx external IP address.

Notice I ran the -v ssh session to try to execute the "date" command remotely, hoping it would not need the password.

So, in the authorized_keys file on the remote server, I tried first putting

from "192.168.0.9"

at the beginning of the file. That didn't work. So then I tried 192.168.0.2 (the IP of our gateway/firewall). Still didn't work. So then I tried the external IP address that our network connects to the ISP. Still, no go. Here's the output from the -v command. I see no errors about world-readable directories. It just tries the key, and then goes on to trying the password, without giving a reason why it didn't work.

My first question about the id_dsa.pub file is that "root@rosebud" appears at the end of the file. Well, when I copy that file to the remote server, should that be changed to be root@server1 ??? Or, should it still reference the internal source server, like root@192.168.0.9 ??? "rosebud" wouldn't resolve to anything on the external server cause it only exists on our internal network.




[root@rosebud .ssh]# ssh -v xxx.xxx.xxx.xxx 'date'
OpenSSH_3.6p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.5.2p2
debug1: match: OpenSSH_2.5.2p2 pat OpenSSH_2.5.0*,OpenSSH_2.5.1*,OpenSSH_2.5.2*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.6p1
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_OLD sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
root@209.61.155.175's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: date
debug1: channel 0: request exec
debug1: channel 0: open confirm rwindow 0 rmax 16384
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
Sun Jul 6 13:30:14 CDT 2003
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
[root@rosebud .ssh]#


I still don't get it... anyone got any ideas?

 

[fluid11]

Bring two servers up on the same subnet and follow the instructions above. Whether or not you can get it to work will tell us whether its a firewall issue or not. It should only take less than 10 minutes.

Chris

 

[shadedecho]

Ok, I did so, and it worked just fine internally.

Then, I found this tutorial:

http://www.mayin.org/aragorn/writings/ssh-keys.pdf

This mentions nothing about putting in the from="xxx" in the file, but it DOES curiously mention calling the file "authorized_keys2" --> notice the 2 on the end. I did this on the remote server, and poof! it worked. grrrr!

so, in reading that tutorial a little closer, it mentions that for version 1 of ssh, you use "authorized_keys" and for version 2, you use "authorized_keys2".

So, then i tried renaming the file on the internal server #2 to "authorized_keys2" and it still worked just fine, EVEN WITH the from="192.168.0.9" in it. Then I removed that phrase from the file, and it STILL worked ok. so, obviously the version 1 requires it, and the version 2 doesn't. hmm.

so, my conjecture is this... is it possible that the problem is related to the firewall for the version 1 type file on the remote server, and that once I specified the version 2 type file, without any IP in it, it worked fine? Does this mean I am running different versions of ssh internally than on that remote server?

It works, hallelujah, but, I'd still like to understand WHY it works. anyone?