Thread: Connection Closes when sftp user tries to login to rssh chroot
Brought to you by:
xystrus
Menu
▾
▴
rssh-discuss
|
From: David W. <dw...@gm...> - 2011-08-03 16:29:45
|
I posted the following message on Serverfault a few days ago, but as I've
had no response, I thought I'd post here. I'm running a CentOS 5.x server.
I am trying to configure a chroot environment with rssh. I have added the
user with "useradd" specifying its home directory as the chroot environment
(/var/www/sage). I have also configured rssh to allow scp and sftp logins,
and have configured the specific user's chroot shell:
[root@elmer sage]# cat /etc/rssh.conf
# This is the default rssh config file
{snip}
allowscp
allowsftp
{snip}
user="sage:002:00011:/var/www/sage"
I then ran rpm --root /var/www/sage --initdb to let me use yum inside it,
and added the CentOS-release repository as well as the epel and ius
repositories. Then I ran the equivalent of:
Yum install --installroot=/var/www/sage openssh-server sftp-server rssh
I then try to login as sage via SFTP, and I'm unable (the connection closes
immediately). Here's what /var/log/messages says:
Jul 27 21:01:28 elmer rssh[18143]: setting log facility to LOG_USER
Jul 27 21:01:28 elmer rssh[18143]: allowing scp to all users
Jul 27 21:01:28 elmer rssh[18143]: allowing sftp to all users
Jul 27 21:01:28 elmer rssh[18143]: setting umask to 022
Jul 27 21:01:28 elmer rssh[18143]: line 52: configuring user sage
Jul 27 21:01:28 elmer rssh[18143]: setting sage's umask to 02
Jul 27 21:01:28 elmer rssh[18143]: allowing scp to user sage
Jul 27 21:01:28 elmer rssh[18143]: allowing sftp to user sage
Jul 27 21:01:28 elmer rssh[18143]: chrooting sage to /var/www/sage
Jul 27 21:01:28 elmer rssh[18143]: chroot cmd line:
/usr/libexec/rssh_chroot_helper 2 "/usr/libexec/openssh/sftp-server"
Here's what /var/log/secure says:
Jul 27 20:57:57 elmer sshd[18094]: Accepted password for sage from
68.169.154.132 port 57766 ssh2
Jul 27 20:57:57 elmer sshd[18094]: pam_unix(sshd:session): session
opened for user sage by (uid=0)
Jul 27 20:57:57 elmer sshd[18096]: subsystem request for sftp
I've verified that sftp-server and rssh_chroot_helper exist within the
chroot under /usr/libexec/. I've also verified with ldd that all of the
libraries for rssh_chroot_helper and sftp-server exist under the chroot in
the appropriate places.
Finally, I've tried various tricks such as running a chmod -R 777 on the
whole chroot to make sure this isn't a permissions issue.
I ran an strace on the ssh process. Here's how:
1) Opened up a 2nd window, and ran sftp sage@localhost
2) In my first terminal window, ran ps aux | grep sage, and find the PID
3) Ran strace -p 29188 -ff -o sage.trace 4) In the 2nd window, I then logged
in. Below are the contents of sage.trace:
[root@elmer ~]# cat sage.trace.29188
read(4, "t", 1) = 1
read(4, "r", 1) = 1
read(4, "E", 1) = 1
read(4, "k", 1) = 1
read(4, "u", 1) = 1
read(4, "7", 1) = 1
read(4, "R", 1) = 1
read(4, "a", 1) = 1
read(4, "\n", 1) = 1
write(4, "\n", 1) = 1
ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon
echo ...}) = 0
rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGTTIN, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
close(4) = 0
write(3, "\316\347\350\3R\224\337\375H\243a*]Fu\205pX\304%\27\272\244\3\300\337\210\344\7\233Q6"...,
144) = 144
select(4, [3], NULL, NULL, NULL) = 1 (in [3])
read(3, "\303\273SJ\215\316\262\35\333\262\2762\r\3717\33\2\305\335\373\326\20\261\261\370\207\342\231\212\266\240\24",
8192) = 32
dup(0) = 4
dup(1) = 5
dup(2) = 6
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66fe0) = -1 ENOTTY
(Inappropriate ioctl for device)
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66fe0) = -1 ENOTTY
(Inappropriate ioctl for device)
fcntl(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee66f60) = -1 ENOTTY
(Inappropriate ioctl for device)
gettimeofday({1311890179, 310651}, NULL) = 0
brk(0x7f314c27c000) = 0x7f314c27c000
rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGHUP, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGHUP, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGHUP, {0x7f314b8d55c0, [], SA_RESTORER,
0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGINT, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGQUIT, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGQUIT, {0x7f314b8d55c0, [], SA_RESTORER,
0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGTERM, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x1, [], SA_RESTORER, 0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGTERM, {0x7f314b8d55c0, [], SA_RESTORER,
0x7f314979c2d0}, NULL, 8) = 0
rt_sigaction(SIGWINCH, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGWINCH, {0x7f314b8d5a50, [], SA_RESTORER,
0x7f314979c2d0}, NULL, 8) = 0
select(7, [3], [3], NULL, NULL) = 1 (out [3])
write(3, "T(8\352\\\230\305\203R\237\302\245\270\216\257\241\327cg\25\327\"\4\16\23\231|\3075\316\370\223"...,
64) = 64
select(7, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\3\f6\357g[\253\344\350\221\21\330\302\255%X\203\320\303\262Y\320\351\232n'\213\31\343\260\356j"...,
8192) = 48
getsockname(3, {sa_family=AF_INET, sin_port=htons(45213),
sin_addr=inet_addr("127.0.0.1")}, [11362581868445696016]) = 0
setsockopt(3, SOL_IP, IP_TOS, [8], 4) = 0
select(7, [3], [3], NULL, NULL) = 1 (out [3])
write(3, "*\341\212csS_Z\0222x\f\312\306\v\226\273\177*>\337%\274\255\220\200H]\311\20\320\234"...,
128) = 128
select(7, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\312|\345r\30\373_\1\346\326\3502\330`f\35xf\332~\2\233\373\352\331\214g1\23h\361+"...,
8192) = 80
select(7, [3 4], [], NULL, NULL) = 1 (in [4])
read(4, "\0\0\0\5\1\0\0\0\3", 16384) = 9
select(7, [3 4], [3], NULL, NULL) = 1 (out [3])
write(3, "\361o\215\0050f\30U\275\334E\30\0\235\251~\325\300r\301\31q\200\227G\344\252up86\263"...,
48) = 48
select(7, [3 4], [], NULL, NULL) = 1 (in [3])
read(3, "\324\1JRtRy,\200I>\211\3039\225\261\317\270\273\324\302\276`\326\221\211\364\3539{\335\277",
8192) = 32
close(5) = 0
select(7, [3 4], [], NULL, NULL) = 1 (in [3])
read(3, "\216E\300\326]\0\t\231A\277\237\203\310\221\204\206\n\332u|\350J\371=\277v_\240\303n\324f"...,
8192) = 96
close(4) = 0
close(6) = 0
select(7, [3], [3], NULL, NULL) = 1 (out [3])
write(3, "4uj\304\342\241\\\372\1\220\301\200b^\356\177\222\276\10\253I\222\374\221\316\262\240\344CJ?,",
32) = 32
rt_sigaction(SIGWINCH, NULL, {0x7f314b8d5a50, [], SA_RESTORER,
0x7f314979c2d0}, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f314979c2d0}, NULL, 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee64e60) = -1 ENOTTY
(Inappropriate ioctl for device)
fcntl(0, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(0, F_SETFL, O_RDWR) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff0ee64e60) = -1 ENOTTY
(Inappropriate ioctl for device)
fcntl(1, F_GETFL) = 0x2 (flags O_RDWR)
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
brk(0x7f314c276000) = 0x7f314c276000
gettimeofday({1311890179, 788197}, NULL) = 0
shutdown(3, 2 /* send and receive */) = 0
close(3) = 0
exit_group(1) = ?
I've found tons of blog posts and forum topics of people complaining about
this issue. However, I still haven't come up with a solution that works for
me.
Thanks for any input.,
David
--
- David White -
Smooth Stone Services
Computer Technical Support, IT Services, & Web Hosting Solutions
http://www.smoothstoneservices.com
|
|
From: R. D. <rap...@gm...> - 2011-08-31 15:19:02
|
Hi David, I've been running into similar situation. My OS is Centos 5.6 64bit. I managed to run rssh correctly. I've just copied the files from /lib64 to the /path/chroot/lib64 directory (without the subdirectories). I've created the chroot directory with the mkchroot.sh script, but it seems to miss some files from lib64 Maybe this can help. PS: sorry if I broke the thread, I cannot find how to answer a pre registration post. -- Raphael |
|
From: Ben W. <bw...@ar...> - 2011-08-03 16:36:18
|
Excerpts from David White's message of Wed Aug 03 12:29:38 -0400 2011: Hi David, > I've found tons of blog posts and forum topics of people complaining > about this issue. However, I still haven't come up with a solution > that works for me. I set this up on RHEL5 recently so my experience should be similar. I used the chroot setup script (with the patch I sent to the list) to create my environment though instead of doing yum inside the chroot. You'll need to have ld-linux.so in the chroot in addition to libraries listed by ldd. Feel free to ping me off list for further assistance if you need it. (On list is fine too if the info will be useful to others.) Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 |
Thanks for helping keep SourceForge clean.
X