scp to chrooted user on unique sshd port

[TheJuiceman]

Hey gang,

Here's what I got. I have a box (box A) that has a user (user A) set up in a chrooted environment. The user is in a special group in /etc/group and is setup to use a separate sshd on a unique port (2222). This unique sshd is also using a unique sshd_config file.

I have a user on box B with the same name as the one on box A. However, this user is not a chrooted user.

I can ssh from box B to A using "ssh -p 2222 userA@boxA" with no problem.

I can sftp from box B to A using "sftp -oPort=2222" with no problem.

However, when I try to use scp, I have problems. Using something like

scp -P 2222 file userA@boxB:~/file

returns "scp: /newroot/home/userA/file: No such file or directory"

Trying to write to a perm 777 directory within the chrooted user's home dir results in the same so it's not that. Besides, I can sftp the same file to the same location with no problem.

Could it be something in the sshd_config file? I have attached it for review.

Also, I am wanting this to be a very secure connection, so any advice on changes to the sshd_config file is appreciated.

[Matti_Kurkela · Accepted solution]

The _local shell_ is expanding "~/file" to "/newroot/home/userA/file", before the scp command even begins executing. The shell does not understand this parameter is meant for the remote end, and happily expands it based on local conditions. Of course it does not make sense at the remote end.

When you use scp, all shell special characters (wildcards, ~, etc) should be escaped when they appear in the _remote_ path.

In this case, the "~/" is unnecessary: if the remote path does not begin with a slash character, it's interpreted as relative to the user's home directory. In other words, the command

scp -P 2222 file userA@boxB:file

or even

scp -P 2222 file userA@boxB:

should do what you apparently want.

Also, you should pay attention to the chrooted userA's entry in /newroot/etc/passwd. As that file is read only if the chrooted environment is already in effect, it should indicate the user's home directory as /home/userA even if it's really /newroot/home/userA.

If you just copy userA's entry from the real /etc/passwd to /newroot/etc/passwd as-is, any program that reads the home directory information from /etc/passwd will get confused when run inside the chroot environment: the value /newroot/home/userA + the effect of chrooting = the program will think the user's home directory is effectively /newroot/newroot/home/userA (as viewed from outside the chroot jail).

MK

[TheJuiceman]

Thanks. You are right...my syntax was wrong. However, here is the problem that I'm still experiencing...

If I create the password-less keys prior to chrooting the user, the keys work. Once I chroot the user, the keys no longer work.

If I chroot the user before creating the keys, it will not let me because it is wanting /home/user for a home path when the new path is /newroot/home/user.

What is the procedure to make password-less keys for a chrooted user in this instance? Thanks.

[Matti_Kurkela]

Your real /etc/passwd on boxA should identify userA's home directory as /newroot/home/userA, but the /newroot/etc/passwd should list it as /home/userA, because that's how chrooted programs will see it.

Only chrooted programs will ever look at /newroot/etc/passwd, because "everyone knows" /etc/passwd is at /etc/passwd :-)

If you just duplicate your real /etc/passwd entries in /newroot/etc/passwd, you are likely to get exactly the kind of problems you describe.

If you absolutely must use the same /etc/passwd entries both inside and outside the chroot, you might work around it with a bit of symlink trickery. Use these commands exactly:

# cd /newroot
# ln -s . newroot

After this, outside the chroot, /newroot/home/userA will be the correct path to the userA's home directory, just as before. But inside the chroot, /newroot/home/userA will be mapped to /./home/userA, which is equivalent to /home/userA... which is the correct path as viewed inside the chroot environment.

MK

[Steven E. Protter]

Shalom,

On box b:

ls /newroot/home/userA/file

Looks to me if this path does not exist you might want to specify the path you wish to write to instead of relying on the ~

SEP

[Wilfred Chau_1]

try this:


copy
/newroot/home/userA/.ssh
to
/newroot/home/userA/newroot/home/userA/.ssh

after you chroot userA
/newroot/home/userA becomes /

[TheJuiceman]

I'm not getting far with this. I can get the keys to work if I change /etc/passwd for the user to be /newroot/home/userA and leave it as /home/userA in /newroot/etc/passwd. By doing this the ssh into the box as userA works.

But, the scp does not work. I get a "permission denied" message when attempting a scp. I'm not seeing what I'm doing wrong here. Permissions all look right. If I do not change the entry in /etc/passwd, then it asks for a password and then still gives me the "permission denied" message.

[TheJuiceman]

I think I might have got it as I typed the last message.

Setting up the /etc/passwd and /newroot/etc/passwd files to be different as suggested appears to be the way to go.

Doing the scp of "file" would use syntax such as:

scp -P 2222 file userA@boxB:/home/userA/file

This seems to do the desired thing of putting the file into /newroot/home/userA.

[TheJuiceman]

This has indeed worked!!! Thank you all for your help