On Wed 30 Mar 2016 at 07:02:46 (-0500), Tom Browder wrote: > On Saturday, March 26, 2016, David Wright <deb...@lionunicorn.co.uk> wrote: > > > > A bit early for [SOLVED], I think. > > I respectively disagree, David.
Correct me if I'm wrong, but I make the assumption that putting [SOLVED] in the subject line is so that people searching for <some symptom or some problem> will find such a tagged post and be able to follow the method therein to potentially fix their problem. > > On Sat 26 Mar 2016 at 12:08:37 (-0500), Tom Browder wrote: > > > On Fri, Mar 25, 2016 at 12:12 PM, Tom Browder <tom.brow...@gmail.com> > > > wrote: > > > > I have installed Deb on my laptop and reused my old Deb 7 .ssh > > > > directory. > ... > > > > Not such a wonderful resource if it is so easily misunderstood. The > > idea is to fix the permissions, not make your installation less secure. > > I agree. But it's the first step on your solution post. It would be usual to edit out false trails and red herrings from a solution. > > > Base on the comments from jvp, I looked closer at my home directory on > > > the laptop and, sure enough, the permissions were too loose (first I > ... In the snipped section, you would have people set their home directory permissions to 0700. Debian by default sets them to 0755, which others might be unwittingly relying on. > > > Then, in the upper widow, I saw the problem. Directory '/usr/local', > > > under which my .ssh directory is actually located, was reported to > > > have bad permissions: > > > > > > Authentication refused: bad ownership or modes for directory /usr/local > ...> > > > > I checked and they were, surprisingly: > > > > > > # ls -ld /usr/local > > > drwxrwsr-x 31 root staff 4096 Mar 24 07:37 /usr/local > > > > > > I don't know how that happened, but it must have happened during the > > > upgrade two days ago when I continued to use my original partition > > > mounted as '/usr/local' which was not supposed to have been touched. > ... If this was a Debian installation, one would expect the ownerships and permissions as posted. > > I don't know what happened long before that! When did /usr/local > > become your home directory? > > See below. > > > > Anyway, as root, I fixed the permissions back to what I think is correct: > > > > > > # chmod 00755 /usr/local > > > # ls -ld /usr/local > > > drwxr-xr-x 31 root staff 4096 Mar 24 07:37 /usr/local > > > > So now the system is degraded a bit more. The correct permissions, in > > fact the entire contents, are: > ... > > Who says those permissions are correct? I checked the file system > standard which says that /usr/local is optional. I provide my own > /usr/local partion which I save when reinstalling a new OS and see no > reason to provide setuid or setgid for it. The last paragraph of section 9.1.2 Site-specific programs in the Debian Policy Manual. > When I first started > administering Unix systems on SGI in 1993, the user home directories > were in /usr/local/people and I kept using that as I transitioned the > hosts under my control to Linux systems in 1994. That is very historical. While you're free to configure your system any way you choose, it's not sensible to suggest that others should do this by tagging your post [SOLVED]. AFAICT Linux has never used /usr/local/ in that way. > Over the years on my own systems I have found it convenient to keep > home system resource directories and files (.bashrc, .profile, > .bash_aliase, .xemacs, .ssh, etc.) in a version-controlled, personal > directory under /usr/local. I then soft link those back to whatever > the newly installed system sets as my home directory. It has worked > fine until the Debian 8 install set the permissions as noted which > interfered with strict ssh. Again, you're free to configure your system any way you choose. However, /usr should effectively be readonly software with, possibly, configuration files, whereas your .ssh/ directory is not readonly; for example, known_hosts and authorized_keys get modified on the fly. So your way of fixing your problem is not a general solution for anyone because most of the post concerns your highly individually configured system. That's what made me unhappy about your [SOLVED] tag. I hope you'll understand. Cheers, David.
