ssh and certificates...

[shadedecho]

OK, I have recently installed ssh on two linux servers... one (server1) is local here at my work, behind a firewall, and the other (server2) is external.

I want to set up ssh so that my user (dummy) account, which is the same on both boxes, can log into server1 (obviously providing a password through the windows client i use to connect). Once into server1, i want to be able to ssh to server2 without providing the remote password... mainly this is because the ultimate goal is to be able to issue commands remotely using ssh without the password prompt, which is NOT scriptable it seems. In addition, I want to use scp from a script to copy files from server1 to server2 without a password prompt, which will be possible once ssh doesn't require the password prompt anymore.

I have read places on the internet that talk about this being possible, like being able to type

ssh 123.456.789.012 'date'

and have ssh execute that command on the remote machine without prompting for the user account's password.

The articles I've read mention this can be done with public and private key pairs on one or both machines, but i'm not familiar with how to do this.

I tried using

ssh-keygen -t dsa

and then

cat id_dsa.pub >> authorized_keys

as one website suggested, but that didn't work.

Can someone please explain exactly the steps I would use on both server1, and server2, to get server1 to be able to connect to (and execute commands on) server2 without an ssh password prompt?

 

[shadedecho]

i should also mention that i tried the method described in

thread54-589774

i used the external address of our ISP connection, not the internal address of server1

but, i think maybe that doesn't work because the IP address that the remote server gets reported may not be the same... i dunno.

 

[timsr]

You need to cat the id_dsa.pub into the authorized_keys of the machine where you want the connection. So, if server1 wants to connect to server2, cat id_dsa.pub from server1 to the authgorized keys of server2. If the server is behind a firewall, you can redirect a port from the firewall to the server using rinetd. Simple config file in /etc will allow port redirection so you can ask for port xxxx on the firewall which will redirect it to the server on port 22 or any other port you want. Just need to start sshd with a -pxxxx to open a different port. Should have no problem with the connection then.

 

[shadedecho]

the port I don't think is the issue, we already have ssh port 22 open on our firewall.

here's the steps I just repeated, to try to make it work:

1. on server1 (internal), i ssh'd in as my user.

2. I "su -"'d to the root account.

3. made sure a /root/.ssh directory exists

4. in that directory, i ran "ssh-keygen -t dsa". It asked for a file name, left it as default id_dsa. It asked for a passhphrase, hit enter twice to make no passphrase.

5. I executed "cat id_dsa.pub >> authorized_keys" which created that file in the current .ssh directory.

6. I scp'd the "authorized_keys" file to the same corresponding directory on the server2 (remote, external).

7. I ssh'd to the remote server2 (from my windows box) to verify the file was in fact there.

8. from server1, I executed "ssh 123.456.789.012 'date'", expecting that the command would be executed remotely on server2 without prompting for the user account's password.

It prompted for the password still. What am I doing wrong?

also,
I tried going into the file on the server2 and, as the thread I mentioned earlier above suggests, adding

from "987.654.321.012"

at the beginning of the file, specifying the IP address that the connections would be coming from.

I tried first the external IP address of my company. Then, I tried the internal IP address of the gateway router firewall that we have, where all internal traffic passes through before being translated out to the internet. Then, I lastly tried the internal IP address of the actual server1, which SHOULD BE according to that thread the correct one. Still, no go! HELP!

 

[flugh]

Try 'ssh -v' to get more verbose error messages. Common thing here is you have a group- or world-readable ~/.ssh directory. The error messages produces when using the -v option should help get this fixed though.

--
JR

 

[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?

 

[flugh]

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

That's where things break. None of those files are present or set up the way ssh expects them to be.

Do the 'cat id_dsa.pub >> authorized_hosts' thing, then copy the 'authorized_hosts' file to your ~/.ssh directory on the remote server. Make sure the ~/.ssh directories aren't group or world read/writeable.

--
JR

 

[shadedecho]

Acting on a tip from another thread (Thread54-589774), I decided to try this stuff on 2 internal servers, NOT going to a remote one through our firewall. It worked immediately. hmmm.

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?