Ubuntu – Allowing multiple users SSH access to Ubuntu instance running on Amazon Web Services

It seems as if similar questions have been asked before, but the issue that I am having hasn't been raised or answered as a part of the answers provided to the other questions. So…

I'm using an Amazon EC2 instance that is running Ubuntu, and I've already figured out how to gain SSH access with PuTTY with the "ubuntu" login. I figured I could simply do a few useradds, and in each of the home folders of the other users, add ".ssh/authorized_keys" as it was in the "ubuntu" home folder, and then SSH in using the other usernames (but the same private key) would run smoothly – this didn't happen (I got the "Server refused our key" message).

There seems to be something that I'm unaware of as to how SSH key-pairing works… any ideas?

Quick summary:

• SSH access with PuTTY using "ubuntu" as username – works fine.
• Creating other users, copying ".ssh/authorized_keys" from "ubuntu" home folder to other user home folders, and SSH with same private key (login with different username) – doesn't work. Receiving "Server refused our key" message.

UPDATE: I've edited the file '/etc/ssh/sshd_config' to uncomment the line:

AuthorizedKeysFile %h/.ssh/authorized_keys

(which I didn't realize was commented by default), but still no luck. Just thought I'd mention it if that was going to be a suggestion…

UPDATE2-IMPORTANT: Thanks to Nikolay's answer, I realized I had overlooked the permissions of the file. Although the permissions were not quite the issue (I think), it turns out that when I used sudo to copy '.ssh/authorized_keys' to the other added user folders, the owner of the newly created folder and file was actually root. The question seems to be now – how can I change the owner of the folder/file (as a non-root user most likely wouldn't be able to check a key that is owned by root)? I'll do a search to see if that comes up with the answer…

UPDATE3-IMPORTANT: I've changed the permission for both '.ssh' and 'authorized_keys' as well as the owner and the group from root to otheruser, yet when using username otheruser when trying to SSH, I still receive the "Server refused our key" message. Sorry I prematurely added the answered section… the answer provided seemed (and still seems) like the correct answer, logically speaking, so I said it was answered before I tested…

UPDATE4-IMPORTANT: Nickolay's answer is indeed correct (which I said wasn't in UPDATE3). My issue (after I followed Nickolay's answer) was not actually related to any SSH caveats. When I created the otheruser account, I accidentally specified the shell as /bin/bash/ instead of /bin/bash (notice the extra /). I came upon this because all work I had done was from the "ubuntu" account, and after getting frustrated I tried to just log into otheruser after SSHing in with ubuntu – which returned the error "Cannot execute /bin/bash/: Not a directory". After changing the shell with chsh -s /bin/bash otheruser, I was able to log in to otheruser from ubuntu, but more interestingly this allowed me to SSH using otheruser as the user without receiving the "Server refused our key" message. So… the inability to instantiate a shell to use somehow returned as a refused key message. Is there somewhere I should maybe call attention to this…? In any case, thanks again to Nickolay.

ANSWERED: Nickolay's answer covers what needs to be done in this situation, including using the chown command to change the ownership of the folder/file as is mentioned provided link under his answer. (I also used the chgrp command as the group was also root)

Here are the steps I used (you may have to preface these commands with sudo):

• chmod go-w otheruser otheruser/.ssh
• chmod 600 otheruser/.ssh/authorized_keys
• chown 'otheruser' otheruser/.ssh
• chown 'otheruser' otheruser/.ssh/authorized_keys
• chgrp 'otheruser' otheruser/.ssh
• chgrp 'otheruser' otheruser/.ssh/authorized_keys

NOTE: The last two commands are for changing the group the '.ssh/' folder and 'authorized_keys' file are associated with. You may want them to be something else, but I wanted to keep them consistent with the other files/folders in that user's home folder.