I am trying to setup ssh using public key authentication with putty.

It works for root, but not for my non-privileged user.

I even tried copying the .ssh/authorized_keys file from root to the non-privileged user home, but that did not help. If anyone can think of why it does not work for the non-privileged user

This works: pscp c:\putty\abc.tst root@srv1:/tmp/abc.tst
This does not work: pscp c:\putty\abc.tst usr1@srv1:/tmp/abc.tst

I would appreciate the help.

Thanks
Randy

did you do a chown to the correct user and group for the authorized keys file?

the authorized keys files is owned by the correct user.

Instead of using putty, try a Linux-based ssh client and use the -v option to show more details about what is happening. You can use it more than once to get very verbose output. Paste the output here.

the key is unique to each user.

try generating a key for that user.

C:\putty>pscp -v c:\putty\abc.tst usr1@srv1:/tmp/abc.tst
Server version: SSH-1.99-OpenSSH_3.6.1p2
We claim version: SSH-2.0-PuTTY_Release_0.58
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-rsa 1024 31:c2:7c:80:4f:e5:55:a5:68:b3:31:39:14:2d:36:db
Initialised AES-256 client->server encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised AES-256 server->client encryption
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "usr1".
Pageant is running. Requesting keys.
Pageant has 4 SSH-2 keys
Trying Pageant key #0
Key refused
Trying Pageant key #1
Key refused
Trying Pageant key #2
Key refused
Trying Pageant key #3
Key refused
Keyboard-interactive authentication refused
usr1@srv1's password:

I've only had minimal experience with SSH, so I can't tell you much from your output.

However, the instructions on this site got key authorization up and working: http://sial.org/howto/openssh/publickey-auth/ Hopefully you'll have good luck with them, too.

What was the real sticking point for me was that the ~/.ssh directories AND all the files inside them, have to have the proper permissions --one of my machines had them readable by group & other. SSH would simply ignore them because it considered the files to be insecure.

Did you try generating a new key for your non-root user per slimm609? I'd try that.

The last thing I would know to check is the ~/.ssh/config and /etc/ssh/ssh_config files. Perhaps root has a ~/.ssh/config that enables something which the system-wide /etc/ssh/ssh_config does not? Or your user's ~/.ssh/config is disabling something that's in the system-wide /etc/ssh/ssh_config? (use "man ssh_config" on the Linux system to get more info on these files.)

its just as slim said, its by user. Once I regened the key just for my new user its worked.

Thanks everyone
Randy

i am glad that worked. The reason that they make them user specific is because it users the username as the salt for the encryption making it harder to break

I've never had any trouble trying to use the same key for different users. I make keys per client machine and can log into a couple different usernames on the same machine by just changing my command line from ssh user1@example.com to ssh user2@example.com. The line I pasted into .ssh/authorized_keys is the same for user1 and user2. While you may have corrected the problem, it seems to me that you must have included another step which really fixed the problem.

on your system type "ssh-keygen -t dsa" and look at the fingerprint for that key. The keys are made for each user. The keys use part of the username for the salt. I am going to test this a few different ways in my lab and see what happens. I have never seen it work with different usernames in ssh version 2. I have not tested version 1

ssh-keygen should generate a new key every time, regardless of if it is the same user or not. If anybody has a version that produces the same results over and over, run away quickly. That'd be a security nightmare.

Aren't we trying to use one key for multiple different users? Pasting the same id_dsa.pub (or equivalent) contents into each users's authorized_keys file has never failed me.

Pasteing the id_dsa.pub in multiple users on a different machine will work but the issue in on the server side putting the prv key into multiple users so they can all share the same prv key. That will not work because then if user1 and root used the same key then any user that had user1 access would also have root access. ( major security issue )

I am not saying that it uses the same key everytime. But is includes the username into the salt to help scamble the encryption even more.

The key should not be able to be used for multiple users. because then i could create a key on my machine and take both the pub and the prv keys to any machine and use them as if they were created there.

Wouldn't that require the server to check all the authorized_keys files on the machine each time you connect?

Let me tell you scenarios that I have done in the past. The security of these scenarios is another topic.

1. Local_1 and Local_2 have same private key and can log into Remote_1
2. Local_1 has a private key that can log into Remote_1 and Remote_2 users which are on Remote_Machine_1.
3. Local_1 has a single private key that can log into Remote_1 on Remote_Machine_1 and Remote_2 on Remote_Machine_2 respectively.

Again, I have used them and for my local network, have similar setups currently in action.

SSL starts before the username is sent. And it is not salted from the username, the SSH server sends a public certificate which is global to all users on the machine. I'm not sure the details of authentication after SSL is established but it apparently is not dependent upon the username.

Go ahead and try out some of the scenarios I laid out above. They can work and can make life a lot easier. I have set up several SSH servers and each time only mildly modified the sshd.conf. I think my most recent setup only deviates in that I have no passwords allowed, just keys and I have scenario 2 active on that machine. That machine is based off of FC7 I believe so perhaps there is a difference in server configurations for different distributions?

and that should work fine

user1@local_1 to user1@remote_1 should work fine. but user1@local_1 to user2@remote_1 will not. same as user1@local_1 to root@remote_1 will not work.