Hi,
I've got a situation whereby there is a shared server that I need to
give an organization access to particular directories.
What I've devised, but it isn't working for the other side..., is the
following:
Debian Squeeze with schroot installed and a special schroot called
"squeeze-zzz", here is the section from the /etc/schroot/schroot.conf file:
[squeeze-zzz]
aliases=default
description=Debian squeeze (stable)
directory=/home/schroot-squeeze-zzz
users=zzz.user1,zzz.user2
root-users=root
The schroot has specific bind mounted directories that the remote users
need full access to.
Now the schroot works /mostly/ fine as a login shell via remote access
using public/private keys. A "standard" ssh login gives them a shell
and access to the required directory trees.
The server's /etc/passwd shell entries for each user is setup as a
script file:
/usr/local/bin/schroot--zzz.user1
/usr/local/bin/schroot--zzz.user2
This is one of those files:
#!/bin/bash
/usr/bin/schroot /bin/bash
So, that's pretty simple, and they can connect to the schroot okay from
a remote location. The required schroot area is the default, so no need
to have that in the login script file.
Normally (with a standard shell), you can do the following:
ssh server_in_config ls
And if the /server/ is set up appropriately in the ~user/.ssh/config
file with the right host, port, username and key file, then you'll see
the output of 'ls' without any problem. But using the schroot, it gets
stuck and won't run the ls command
Consequently the following won't work either:
scp -pr server_in_config:/remote_dir/ /tmp
[again, that works perfectly well with a normal shell, but not with schroot]
Here is the final part of a verbose attempt to copy a directory tree:
debug1: Authentication succeeded (publickey).
Authenticated to remote_server ([115.nnn.nnn.nn]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_AU.UTF-8
debug1: Sending command: scp -v -r -p -f /remote_dir/
The schroot process on the server end just hangs there..... with a new
process as follows:
sshd: zzz.user1@notty
The process tree on the server looks like this:
# pstree -alpG 12295
schroot,12295 /bin/bash
└─bash,12296
- really simple, bash is running, but the scp command is not passed.
Now I did suggest the person do a reverse scp from the server once
logged in, but they don't have an ssh server of their own to copy back to.
Everything works perfectly well with the latest WinSCP 5.5.3 (just
released) -- but the client has Linux and Mac machines and they don't
want to get Wine working (WinSCP 5.5.3 has /better/ support for Wine
according to WinSCP site).
Version details:
schroot 1.4.19-1+squeeze1
[debian] 6.0.9
Other:
libssh2-1 1.2.6-1
openssh-blacklist 0.4.1
openssh-blacklist-extra 0.4.1
openssh-client 1:5.5p1-6+squeeze5
openssh-server 1:5.5p1-6+squeeze5
Any ideas? I really do want to limit their file access to directories
as needed, hence the schroot requirement.
--
Kind Regards
AndrewM
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534cf874.5060...@affinityvision.com.au
