Ssh with public/private key not working for one user


#1

I am creating a script to automate local msyqldump, rsync backup and restore functions for use with my dreamhost websites. For that reason, I’ve activated passwordless ssh, via public/private keys.

It’s working on every user I’ve got, except one. In other words, I can do ‘ssh-copy-id myusername@myhostbox.dreamhost.com’. It asks me for a password, which it accepts.

Then, as ‘ssh-copy-id’ suggests, I try ‘ssh myusername@myhostbox.dreamhost.com’ and end up having to still use the password.

I tried erasing the line at ~/.ssh/authorized_keys on myhostbox responsible for authorization and re-applied ssd-copy-id, to no affect.

At one point I even deleted all the files at ~/ (except of course logs) and had to recreate .bash_profile, .bashrc, etc. I then tried resinstalling the public key via ssh-copy-id and it still doesn’t work.

So I cannot cron my local script to automatically and remotely ssh in to mysqldump or rsync my files for this user. This is not happening with any of my other users or accounts, so I’m puzzled. I’d be grateful for any suggestions or clues as to why this could happen and how to fix it.


#2

You can fix it by going to the panel, turning off enhanced user security, then re-enabling it (or vice-versa depending on your preferred settings). I have complained to Support about this and pointed out the problem, but they refuse to acknowledge that it exists. If this fix works for you, please let me know.


#3

[quote=“bobocat, post:2, topic:57617”]
You can fix it by going to the panel, turning off enhanced user security, then re-enabling it (or vice-versa depending on your preferred settings). I have complained to Support about this and pointed out the problem, but they refuse to acknowledge that it exists. If this fix works for you, please let me know.
[/quote]bobocat – Thank you.

I can confirm that you are correct. I disabled and then re-enabled ‘enhanced security’ for the user at panel.dreamhost.com and was then able to ssh into that user’s account sans password. I didn’t even have to re-‘ssh-copy-id’.

You may confidently relay to Dreamhost that they do in fact have a bug - in essence exposed via a client-duplicable remedy. Hey – at least there’s a remedy, right?

I wonder if there is anything in common to your experience and mine that could be the trigger that foils passwordless ssh. Originally, this user had a number of domains, but I transferred them to other users over a year ago. Then recently I put a one-click install of Concrete5 on a subdomain as a demo to try it out.

I’ve been doing rsync and mysql dumps and restores, and wanted to make sure I didn’t delete every file in the user directory by mistake with an rsync restore before I got a handle on it. I’m glad I did, because that’s exactly what happened.

Thank you so much for figuring this out. I was about to delete the user and start again.


#4

[quote=“greenman, post:3, topic:57617”]
You may confidently relay to Dreamhost that they do in fact have a bug - in essence exposed via a client-duplicable remedy.
[…]
I wonder if there is anything in common to your experience and mine that could be the trigger that foils passwordless ssh.[/quote]

Unfortunately, DH doesn’t seem to be interested in user suggestions. It took them 8 years of pleas and two password leaks before they stopped storing passwords in a recoverable format. It took them over two years after I warned them of the information leak through the @ shell expansion, which gave a list of every SQL domain on each machine. They finally turned it off.

I think DH is going through a bit of a crisis over the last few months and is scrambling to clean up, undo, and shore up the entire system. One of the things that has changed, which they haven’t been too upfront about, is forcing everyone’s home directory to belong to the adm group with 711 permissions. Even if you change this, it will be changed back within a few hours.

The ssh problems started to occur at this time and, I think, is caused by this permissions-checking robot. I’ve reported it to DH, but they don’t seem interested.


#5

[quote=“bobocat, post:4, topic:57617”]I think DH is going through a bit of a crisis … forcing everyone’s home directory to belong to the adm group with 711 permissions. … [/quote]I suppose after the Great Password Leak of February 2012, they have bigger fish to fry than a user-recoverable issue like this one. Or disappearing crons or memory problems…

I’m curious what the group change entails for the user home directory. Could you elaborate?


#6

Ironically, though, a lot of those features which are now breaking, being phased out, etc, are the reason why I and others chose DH over other hosts. As hosting becomes commoditised, it’s the little things that make a big difference. Shell access, generous resource limits, and few restrictions on installing software, are/were one of the things that set DH apart from others.

If you don’t share files/data between users, it will have no effect. Most people don’t and most people didn’t realise that others on the same machine could look at their files, and possibly change their files, if they weren’t careful. The change I mentioned caters to those people by just making it impossible for those that know what they are doing to share files between users. 99% of DH’s customers likely will not notice.


#7

[quote=“bobocat, post:6, topic:57617”]Ironically, though, a lot of those features which are now breaking, being phased out, etc, are the reason why I and others chose DH over other hosts. As hosting becomes commoditised, it’s the little things that make a big difference. Shell access, generous resource limits, and few restrictions on installing software, are/were one of the things that set DH apart from others.[/quote]Same here. It’s hard to find a host that offers this much latitude for shared hosting. I’ve gotten very used to it. If I hadn’t been able to create a dev user to test rsync restore, all of my websites would have been borked.

Actually, I did notice when I was attempting to transfer a php.ini file from my cgi-bin in one user to another yesterday. I thought I was doing something wrong. Bummer. I also wrongly assumed that they assigned a unique group to all users owned by a single account – allowing transfer between users for each account on the same box but not between users on different accounts. I thought they were at least that secure… I suppose not.

Up until end of last year, if I remember correctly, you could
$ cd
$ ls …/
to view every other viewer on the shared box. That isn’t possible now, except in VPS where all the users are yours anyway.

While I’m happy for the extra security, I just hope this isn’t a slipperly slope to dwindling capability like so many other hosts.


#8

They still do. You can set it to the automatic group, or you can still create groups in the panel and use them. Just be aware that any changes to your home dir will revert within a few hours. Just add a chgrp command to your bash_profile or cron job :stuck_out_tongue:

Must have been earlier than that. I noted several information leaks here but the one you mentioned was blocked at that time (May 2011).