Prompt For Chrooted Users
We have a requirement to allow SSH access to a server in order to provide a secure link to one of our legacy systems. I would like to chroot these accounts.
I have this working except for one small detail, the user’s prompt in the SSH session. Each user has their shell set to /bin/bash in
/etc/passwd. However, instead of getting the prompt defined in their
.bash_profiles we see this:
-bash-4.1$
when we are expecting this:
[username@hostname dir]$
So, before I go messing around moving files I would some information from you as tio what I have overlooked. Do I need to move something like etc/passwd and /etc/group into the chroot/etc?
TIA
6 thoughts on - Prompt For Chrooted Users
James B. Byrne wrote:
When ssh’ing into the chrooted directories, where’s their /home/?
I’d set the prompt in ~/.bash_profile.
mark
This just means that your users don’t have a ~/.bashrc that can sources /etc/bashrc (either/both are missing), where the traditional $PS1 is set.
—
Jonathan Billings
It appears that the user profile .bash_profile is not being called at all which no doubt is the root problem. Any ideas as to why this is not happening? Is the -l switch for bash not being used for some reason?
James B. Byrne wrote:
When logged in, that’s what I was asking – *are* they in a home directory, or are they in /?
mark
You haven’t said anything about the process you used, so it’s hard to say what you’ve overlooked.
The basics thing to remember is that the chroot is expected to be a complete system. If you need name resolution, then /etc/passwd and
/etc/group need to be present in the chroot. If you need DNS
resolution, /etc/resolv.conf, too. If your system uses sssd, chroot won’t have access to it. The shell and all of the commands and all of the associated libraries must be in the chroot. Finally, the user’s home directory has to exist within and relative to the chroot directory.
So, if the user’s home directory is /home/user and you want to chroot them there, you would expect to have something like:
/home/user/bin/bash
/home/user/etc/bash_profile
/home/user/home/user/.bash_profile
You could symlink /home/user/home/user to /, as well.
Well, I seem to have resolved most of this. In the end I had to create a separate logical link for the chrooted users’ home directories that pointed back to their actual directory. It sounds confusing because it is.
I first tried this in sshd_conf
ChrootDirectory %h
and in ~/%h I had created the following mount points:
bin dev etc lib lib64 tmp usr
Upon which I had hung mounts to directories containing the chroot reduced functionality.
mount –bind /path/to/chroot/bin bin
However, that did not work. I next tried this:
ChrootDirectory /path/to/chroot
And that did not work either. By not work I really mean did not execute the user’s bash_profile script at login, which is why the prompt was screwed up. Of course that was simply the most immediately visible problem.
What did work, eventually, was this combination:
In sshd_conf
ChrootDirectory /path/to/chroot
plus:
cd /path/to/chroot
mkdir -p path/to/chroot
cd /path/to/chroot//path/to/chroot
ln -s ../../user_home_dir user_home_dir
I infer from the documentation that sshd first switches to the chroot and then to the user’s home directory from within the chroot. Which makes sense but the implications for correct implementation are not exactly obvious. The result of not recreating the home directory path under chroot was that the programs in chroot/bin were not found and did not execute while the user stayed in chroot.
This is also why using %h in sshd_conf did not work. For that to succeed I need to recreate the user’s entire home directory tree inside each user’s home directory. Since using a common root and logical links is less burdensome from a maintenance point of view I
choose the later. I was also too lazy to return to the first approach once I got the second working.
So, that mystery is cleared up. I have others, and of course SELinux is in there, but this one is put to bed.