Thread: Trouble getting sftp working.
Brought to you by:
xystrus
Menu
▾
▴
rssh-discuss
|
From: Ben B. <ben...@pr...> - 2003-09-01 13:07:13
|
Hi,
My final goal is to have a chrooted sftp system setup but currently I can't even
get the sftp to work in a non-chrooted environment....
Here is the output of ./configure:
rssh-2.1.0# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets ${MAKE}... (cached) yes
checking for strip... strip
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for unistd.h... (cached) yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking wordexp.h usability... yes
checking wordexp.h presence... yes
checking for wordexp.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking for gcc option to accept ANSI C... none needed
checking for an ANSI C-conforming const... yes
checking for stdlib.h... (cached) yes
checking for working malloc... yes
checking whether lstat dereferences a symlink specified with a trailing slash... yes
checking whether stat accepts an empty string... no
checking for memset... yes
checking for strdup... yes
checking for strtol... yes
checking for strerror... yes
checking for wordexp... yes
checking for basename... yes
checking for OpenSSH >= v3.5... no - v3.4
checking for scp... /usr/bin/scp
checking for sftp-server... /usr/lib/sftp-server
checking static compilation... static compilation ENABLED (detected old OpenSSH)
configure: creating ./config.status
config.status: creating Makefile
config.status: creating main.c
config.status: creating rssh_chroot_helper.c
config.status: creating pathnames.h
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
unreal:/home/bbirnbaum/rssh-2.1.0#
So it seems to detect everything okay and the compile completes without a hitch.
I've got the user sftptest - it's entry in the passwd file is as follows:
sftptest:x:1026:100::/home/chroot/home/sftptest:/usr/local/bin/rssh
My rssh config is as follows:
logfacility = LOG_USER # you can use comments at end of line
#allowscp
allowsftp
umask = 022
#chrootpath="/usr/local/chroot dir"
user=sftptest:011:10
So everything seems like it should work.....when I try sftp as the user I get:
# sftp sftptest@192.168.8.3
Connecting to 192.168.8.3...
sftptest@192.168.8.3's password:
This account is restricted to sftp only.
If you believe this is in error, please contact your system administrator.
Connection closed
#
The log output is as follows:
Sep 1 22:34:56 unreal rssh[21732]: setting log facility to LOG_USER
Sep 1 22:34:56 unreal rssh[21732]: allowing sftp to all users
Sep 1 22:34:56 unreal rssh[21732]: setting umask to 022
Sep 1 22:34:56 unreal rssh[21732]: line 30: configuring user sftptest
Sep 1 22:34:56 unreal rssh[21732]: setting sftptest's umask to 011
Sep 1 22:34:56 unreal rssh[21732]: allowing sftp to user sftptest
Sep 1 22:34:56 unreal rssh[21732]: user sftptest attempted to execute forbidden
commands
Sep 1 22:34:56 unreal rssh[21732]: command: sftp-server
So I'm sort of at a loss as to why this isn't working ..... any advice would be
greatly appreciated.
Cheers
Ben
|
|
From: Derek M. <co...@pi...> - 2003-09-01 13:59:41
|
On Mon, Sep 01, 2003 at 11:06:18PM +1000, Ben Birnbaum wrote: > Hi, > > My final goal is to have a chrooted sftp system setup but currently > I can't even get the sftp to work in a non-chrooted environment.... Ok, I see the problem: > checking for sftp-server... /usr/lib/sftp-server [SNIP] > logfacility = LOG_USER # you can use comments at end of line > #allowscp > allowsftp > umask = 022 > #chrootpath="/usr/local/chroot dir" > user=sftptest:011:10 Note that you don't NEED a per-user config line if all your users will be set up with the same restrictions... The defaults should be configured (by the sysadmin) to allow the most common case to do what they need to do. In most cases, you shouldn't need a per-user config line, and I advocate not using it unless you do. > Sep 1 22:34:56 unreal rssh[21732]: allowing sftp to user sftptest > Sep 1 22:34:56 unreal rssh[21732]: user sftptest attempted to execute forbidden commands > Sep 1 22:34:56 unreal rssh[21732]: command: sftp-server This is because rssh is expecting the sftp client to pass it the full path to the sftp-server. What are you using on the client side? If you're using the OpenSSH sftp client, it SHOULD do that. But I guess there's no guarantee... I have run into this problem with certain clients, and I have fixed this in 2.1.2, which I haven't released yet. I believe it's ready for release, but the reason I haven't released it yet is because I added code to allow cvs, rsync, and rdist, which I have not had time to test. If you want to try it out, I could e-mail you a tarball. But I won't be able to do it until at least Friday, because I'm right in the middle of moving to another country, and I won't have access to e-mail again until at least then. :) FWIW, if you actually ran this command: $ ssh remotehost /usr/lib/sftp-server it should allow you to connect. I'm not positive it will work beyond that, but I think it will. Obviously, that's not a permanent solution, but it should at least let you test things... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |
|
From: Ben B. <ben...@pr...> - 2003-09-01 15:07:02
|
Derek, Cheers for the quick reply. I figured I didn't need per-user config lines and initially I was trying it without, I added that line just to double check that it indeed wasn't needed and it's absense wasn't the reason that things weren't working. [quote Derek] > This is because rssh is expecting the sftp client to pass it the full > path to the sftp-server. What are you using on the client side? If > you're using the OpenSSH sftp client, it SHOULD do that. But I guess > there's no guarantee... [/quote] Yeh - I figured something along these lines was to blame. For the record I am using the openSSH sftp client. It doesn't however seem to be functioning correctly I guess..... [quote Derek] > I have run into this problem with certain clients, and I have fixed > this in 2.1.2, which I haven't released yet ...... > If you want to try it out, I could e-mail you a tarball. But I won't > be able to do it until at least Friday, because I'm right in the > middle of moving to another country, and I won't have access to e-mail > again until at least then. :) [/quote] Yeh - I'd be happy to give it a try if it could fix my problem. No huge rush - just get it to me when you can. Good luck with the move. :) [quote Derek] > FWIW, if you actually ran this command: > > $ ssh remotehost /usr/lib/sftp-server > > it should allow you to connect. I'm not positive it will work beyond > that, but I think it will. Obviously, that's not a permanent > solution, but it should at least let you test things... [/quote] That does allow me to connect but I can't do anything else after then, it just sits there. So it proves that the fact that the full path to the sftp-server isn't getting passed is the problem. Except it doesn't really help me test anything to do with the chroot environment or anything....I'll just use the chroot command for that I guess.... I don't understand why it is the clients job to provide the path to the server binary? Shouldn't this have nothing to do with the client? Forgive my ignorance if I am mistaken - not much of an authority on the inner working of ssh and sftp. Perhaps you could claify this a bit better for me, would be interested to know... Once again, thanks for the quick reply and for the help. Cheers Ben |
|
From: Ben B. <ben...@pr...> - 2003-09-13 13:36:25
|
Hi Derek, Just wondering how the move went/is going. Hope things are well. Pretty anxious to get this working, so was just wondering about the possibility to get that tarball of the new version over to me. I understand your probably swamped with stuff concerning the move and you might not even have net access. But just thought a small reminder couldn't hurt... Cheers Ben Birnbaum Quoting Derek Martin <co...@pi...>: > On Mon, Sep 01, 2003 at 11:06:18PM +1000, Ben Birnbaum wrote: > I have run into this problem with certain clients, and I have fixed > this in 2.1.2, which I haven't released yet. I believe it's ready for > release, but the reason I haven't released it yet is because I added > code to allow cvs, rsync, and rdist, which I have not had time to test. > > If you want to try it out, I could e-mail you a tarball. But I won't > be able to do it until at least Friday, because I'm right in the > middle of moving to another country, and I won't have access to e-mail > again until at least then. :) > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > > |
Thanks for helping keep SourceForge clean.
X