[ec2] Connecting as non Ubuntu User

[Rolo M]

Thanks for your detailed response - it was indeed the ownership of the
non ubuntu user's authorized_keys file which was the problem.

And also nice one on giving me some food for thought with your ninja
command lines - will be useful for my scripts to spawn new instances.

Cheers.

2009/8/26 Scott Moser <scott.moser at canonical.com>:
> On Wed, 26 Aug 2009, Rolo M wrote:
>
>> I've launched an instance (Hardy) and I can connect fine via SSH using
>> ubuntu@<hostname>.  I've created two other users, one for django, to
>> run my apps, and one for my username, kolo.
>>
>> Would it be considered the best way of doing things to continue to
>> connect via the ubuntu user, and then su to my kolo user account?  I
>
> I'm not a security expert.  I could be way off base here.  It would seem
> to me that you want as few "external facing" accounts (those that can be
> connected to as ssh), and want those accounts to be reached in the fewest
> ways possible.
>
> The system is configured with PasswordAuthentication in /etc/sshd to 'no'.
> Thus, the only way in is via ssh key.
>
> I added a user 'kolo' and verified I could ssh in with the same key
> registered to the ubuntu user.  I created by doing the following as
> 'ubuntu':
>
> sudo adduser --disabled-password --ingroup admin --gecos "kolo,,," kolo
> cd $HOME && tar -cpf - .ssh |  sudo -u kolo -i -- tar -xvf -
>
> One common gotcha for failed ssh logins is .ssh directory or
> .ssh/authorized_keys permissions.  The above makes sure they're consistent
> with the 'ubuntu' user, and populates that key also.
>
> I then allowed 'kolo' to be able to do passwordless 'su' via:
>
> printf "kolo\tALL=(ALL) NOPASSWD:ALL\n" | sudo tee -a /etc/sudoers
>
> That is less secure than using 'ALL:ALL' rather than 'NOPASSWD:ALL', but
> needed if you need password-less sudo.
>
> I did the above on the karmic alpha, but it "should work" on the hardy
> image as well.
>
>> Presuming I'm best to be connecting via my own account, I've put my
>> SSH key in ~/.ssh/authorized_keys for both the ubuntu user and my own
>> user, and infact I can connect with the ubuntu user and authoize with
>> my key now, but when I try and user my account I get Permission denied
>> (publickey). (ssh output with -v is pasted below).
>
> In general, to debug this you need the information from the other side.
> The ssh server is not going to tell the user exactly why they can't log
> in, as that is disclosing more information than need be.
>
>> What am I missing?  Also, if I su to another user I lose the terminal
>> colours.  I presume this is because it's not setting the shell
>> correctly?  All of my user's shells are set to /bin/bash, is there
>> some other setting I'm missing?  Will my ~/.bash* files get processed
>> when I su?
>
> In general, try using 'sudo' rather than 'su'.  Its nicer with shells and
> such.  'sudo -i' will get the login files processed.
>
>>
>> Thanks loads for any assistance!  Sorry if it's a bit of a ramble.  Cheers.
>