Automaticlly geting the password using ssh

[Marty Metras]

I am using rssync to keep some parts our HP-9000 using hp-ux 11.0 boxes in sync.
I using ssh to do the link.
My problem is getting ssh to connect without asking for the password.
I used "ssh-keygen -t dsa" to create the Public key then copied the key to the authrize_key file on the other host.
I still get asked for the Password before it will process.
As I understand ssh and ssh-keygen I should not have to enter the password just execute the script.
My script looks some thing like this:
"rsync -az -e ssh -rsync-path=/usr/local/bin/rsync User@hostname:/Path/to/sourse/file /Path/to/Dest/Directory"

this work from the command line or inside a script except for it stops and asks for the password for the User
What am I missing.
Marty

[Marty Metras]

I did use no passphrase.
I defaulted through all 3 prompts.
The file name for id_dsa and both passphrase prompts.
Then I copied the .ssh/id_dsa.pub to .ssh/authorized_keys on the other host.
when I was finished I had id_dsa, id_dsa.pub(Public key) and authorized_keys (Public key for the other host.)
I had this on both servers I am using the same userID/Password on both boxed.
Marty

[Steven Mertens]

hi

you must supply no passphrase
when you make the key.
Just press enter.
You can also change your current
key passphrase. Just press enter. Then you could login without password.

ssh-keygen -p -f ~/.ssh/id_dsa
Enter old passphrase:
Key has comment '/home/smertens/.ssh/id_dsa'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

hope this helps.

Steven

[Belinda Dermody]

check the permissions on the owners home directory they must be 755 otherwise SSH will ask for a password. Also do the ssh connection with a -v arg and it will show you what passes and fails for the checks.

[Marty Metras]

Hi,
I tried the -v (debug)
Here are the resolts of the 2 connections tries. I left out most of it because it matches on both contections.
Please note that UNIX to Linux and Linux to Linux works fine.
But UNIX to Unix and Linux to Unix prompts for the password.
After looking at the debug output I'm confused. Is the problem with the Public key.
Let me verify how I made the public key in case I miss understand the process.
On each of the 4 servers using the sam userID.
command: ssh-keygen -t dsa
When prompted for file name I just press enter.
When prompted for passphrase I just press enter
also just press enter for the confirm to the passphrase.
It creates 2 files ~/.ssh/id_dsa ~/.ssh/id_dsa.pub
Then I create an authorized_keys file using
Command: cp -p id_dsa.pub authorized_keys
Then I append the authorized_keys with the id_dsa.pub from each of the other 3 servers.
Command: cat id_dsa.pub >> authorized_keys
At this point I should have a public key for each server in the authorized_keys file.
I copy the authorized_keys to each of the 4 servers so each server will have all 4 keys.
At this point I have 3 new files in ~/.ssh
id_dsa id_dsa.pub authorized_keys
As I understand this I should be able to do an "ssh hostname" logged in as my testuser that is is on al 4 servers and not be prompted for the password.
Do I understand the right?

Marty

### from UNIX_1 to UNIX_2 server
### "testuser" same on both boxes
$ ssh -v UNIX_2
...
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/users/testuser/.ssh/id_rsa
debug1: try pubkey: /home/users/testuser/.ssh/id_dsa
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is password
testuser@UNIX_2's password:
### not it stops for passwsord

###################################################
### From UNIX_1 to LINUX_1
### "testuser" same on both boxes
$ ssh -v LINUX_1
...
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/users/testuser/.ssh/id_rsa
debug1: try pubkey: /home/users/testuser/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 40022430 hint 1
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Wed Dec 18 07:44:45 2002 from kncryvis
[testuser@LINUX_1 testuser]$
### Note it connected without password prompt

[Scott Corzine]

From your description, the most like thing is that some part of the path of the ~testuser/.ssh/authorized_keys file on the Unix server does not meet the security tests. Each directory from / down to .ssh and the authorized_keys file itself must be owned by either root or testuser, and can not be group or world writable. This is to prevent someone else from sticking a bogus file in place.

If this fails, you might check the sshd's logging on the Unix machine to see if it indicates why it is rejecting the key.

Lastly, if the Unix server is running a different version of sshd than OpenSSH (i.e. the ssh.org/ssh.com version), it may be looking in a different place (like ~/.ssh2). The version is displayed near the top of the verbose dialog.

Hope this helps,
-Scott-

[Marty Metras]

I have changed Protocol 2 to Protocol 2,1 in the sshd_config file and restarts sshd.
Being that my problem seams to be logging in to the UNIX servers and not Linux, I'm thinking I should start over.
Before I do this please confirm the following that I understand it correct.

On UNIX_1 server I create a public key using `ssh-keygen -t dsa`
I create a file that is a copy of id_dsa.pub called authorized_keys and put it in the .ssh directory on the UNIX_2 server.
At this point I should be able to ssh from UNIX_1 to UNIX_2 without a prompt for a password.
I should NOT be able ssh from UNIX_2 to UNIX with out a prompt for password.
Because I have not created a Public key on UNIX_2 yet.

Do I not under stand this correct?

Below are the Versions info and the Rights.
I have also set the LogLevel to DEBUG3 to see if there is more info that would help.
I saw nothing more that was different than I sent earlier.
What am I missing?
Marty


UNIX_1 to UNIX_2 Ver. using ssh -v UNIX_2
HP-UX port of OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f

Dir rights on both unix servers
drwxrwxr-x 6 testuser dba 8192 Dec 18 06:59 /home/users/testuser

drwxr-xr-x 2 testuser dba 8192 Dec 13 10:23 .ssh

-rw-r--r-- 1 testuser dba 2424 Dec 13 10:53 authorized_keys
-rw------- 1 testuser dba 672 Dec 13 09:32 id_dsa
-rw-r--r-- 1 testuser dba 606 Dec 13 09:32 id_dsa.pub
-rw-r--r-- 1 testuser dba 687 Dec 13 09:18 known_hosts
-rw------- 1 testuser dba 1024 Dec 18 10:25 prng_seed


Linux_1 to Linux_2 Ver. using ssh -v linux_2
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600fd

Dir. Rights on both Linux servers
drwxr-xr-x 6 testuser testuser 4096 Dec 19 07:47 /home/users/testuser

drwxr-xr-x 2 testuser dba 4096 Dec 13 11:04 .ssh

-rw-r--r-- 1 testuser dba 2424 Dec 13 11:04 authorized_keys
-rw------- 1 testuser dba 668 Dec 13 09:58 id_dsa
-rw-r--r-- 1 testuser dba 606 Dec 13 09:58 id_dsa.pub
-rw-r--r-- 1 testuser dba 684 Dec 13 09:53 known_hosts2

[Marty Metras]

Scott,
In syslog.log I have this message.
Authentication refused: bad ownership or modes for directory /home/users/testuser
I think the rights are ok.
Marty

[Scott Corzine · Accepted solution]

Marty-

The syslog message:
Authentication refused: bad ownership or modes for directory /home/users/testuser

Is caused by:
Dir rights on both unix servers
drwxrwxr-x 6 testuser dba 8192 Dec 18 06:59 /home/users/testuser
^--- (That 2nd w is the culprit)

Your home directory is group-writable, so sshd considers it insecure. This is because someone else in your group could move things around so that they control the contents of /home/users/testuser/.ssh/authorized_keys and could break into your account. It's ssh being paranoid to protect you.

Each of the following must be no more open than:
drwxr-xr-x /
drwxr-xr-x /home
drwxr-xr-x /home/users
drwxr-xr-x /home/users/testuser
drwxr-xr-x /home/users/testuser/.ssh
-rw-r--r-- /home/users/testuser/.ssh/authorized_keys

Each of the above must belong to either root or testuser.

It's annoying, obscure, and a fairly common problem. But it's there to protect you.

BTW, there is an option in the sshd config file named something like GroupWriteableOK (not the exact name). This allows group write permissions, but shouldn't be used unless you are using RedHat's group-per-user/umask 002 permission setup (which is why it was added).

You probably shouldn't turn the GroupWritableOK thing on unless: (a) you run a machine\ with multiple users collaborating in groups, and (b) you use the group-per-user scheme, or (c) you're building your own sshd software on an RH machine (their RPMs already have it on). If these last two paragraphs don't make much sense, don't worry.

Good Luck,
-Scott-

[Marty Metras]

Scott,

We got it.
I only had to change
drwxr-xr-x /home/users/testuser

Even though the directories above were to open to the group to write, it did not stop ssh.

I went through all the changes I had made to sshd_config and ssh_config to put them back to the defaults. Restarted sshd.
And every thing is working.
I retried to ssh from each of the 4 computer to each of the other. It worked great!

I can make it work and not work by making the change to just the rights. This has to be the cause.

Thanks for all your help.
Thank all of you.
Have a Merry Christmas.
Marty

[Larry Basford]

Marty and asistants, Thanks for getting tis figured out. I spent the last week fighting the same thing. I was able to get mine to work yesterday using putty terminal.

[Marty Metras]

Thanks for reminding me Larry.
Some times the simple things drive you up the wall.
Marty

[Scott Corzine]

Unfortunately this does seem to be one of the most common things which trip people up when they first start using per-user RSA keys in ssh. And it's not an easy one to find.

The hardest part is that ssh considers this "insecure permissions" problem to be a security hole, so it won't tell the ssh client about the problem (because that would be revealing a security problem to a non-authenticated user). It only logs it in the server's logs (where the user probably can't see it even when using ssh -v).

It's a good reason to always have a non-ssh method into your system (telnet w/ Kerberos, console access, etc.), especially when ssh is configured to require per-user RSA keys (and plain passwords are disabled).

-Scott-