ssh - Slackware as server - seems like a chroot jail, but I don't want a chroot jail
 

I'm trying to ssh into my Slackware 15.0 desktop from my Slackware 15.0 laptop I find that I can list my home directory but I cannot see a lot of the root file system (permission denied) and also not run a large number of the commands. when I list my home directory I find user id 0, group id 0. Its almost like I have set up a chroot jail, but I have not. I can su to root and everything is normal as root. However, I've not tried setting up a chroot jail.

#ChrootDirectory none

Any suggestions? Googling give me lots of links for setting up a chroot jail, but not for removing unwanted chroot behaviour.

Odd. Are there files created by root in your user's home directory?

User 0 and group 0 generally refer to root.

Are you using the same user names on both devices?

Yes, careful I am using the same user names with the same UID and GID on both. No (or few if any) files owned by root in the home directories. All were showing as owed by uid 0 gid 0. I need match user names, UID and GID as I want to sync my laptop to my desktop. I've been using unison to do this, with the home directory on my desktop mounted by nfs, but, being becoming aware that unison can use ssh for the connection it would be much neater to do it that way.

What if you don't ssh into your desktop but log in as the same normal user on the console? Does everything look normal then?

My guess is that you somehow have messed up permissions so that your normal user is unable to access the file /etc/passwd and /etc/group. Unable to map uid and gid numbers to user names and group names ls will display numeric id for user and group.

regards Henrik

Anything unusual when using ssh with verbose options (-v or -vvv)?

Henrik,

that was it. I must have updated a package when sudo'ed into root somehow as that seems to pick up my user umask and not use roots. So large areas of the filesystem were not readable by anyone but root. I just happened to notice it when trying to log in first via ssh. I think I've manually fixed it but it is tempting to go back to a snapshot and re-run any updates.

Pete

Thank you, I was wondering about that.

This can also happen even if you are able to read /etc/passwd or /etc/group if those numeric uid and gid are missing in /etc/passwd and /etc/group. The file system might have been created on another machine with other/more contents in those files.

regards Henrik