I connect to sftp server error "error looking up user groups"

[Goriik]

I press "Ok" and taken to the Chroot Directory. But I am embarrassed by this error. Can it as something to overcome? Connect to sft with FAR with WSCP.

[Steven E. Protter]

Shalom Goriik,

Not a lot to go on here.

But I believe the problem is either with the process used to chroot the user. Necessary files/links may be inaccessible.

Or if you used the hp provided script, there may be a problem with that.

There should be something in the syslog.log

Further investigation might help pinpoint the cause of the problem.

SEP

[Steven Schweda]

I know nothing, but in a "chroot"
environment, some program may be trying to
find "/etc/passwd" (or "/etc/group", or
something), but it can't find the real
"/etc/passwd" (or whatever), because "/" in
the "chroot" environment is not the real "/".
You may need to create a "/etc/passwd" (or
whatever) file in the "chroot" "/" tree.

If that is the problem, then this "chroot"
"/etc/passwd" file would not need any actual
password data, only the basic name and number
data.

This sort of thing is commonly done in a
plain FTP server "chroot" environment.

[Goriik]

Problem resolved

Need copy /usr/bin/groups to directory /newroot/bin

/newroot - ChrootDirectory

[Steven Schweda]

> Need copy /usr/bin/groups to directory
> /newroot/bin

Or, if not data files, then programs. It's
always something.

When you start copying programs into "chroot"
trees, you may do better with programs from
"/sbin". Otherwise, you may find that you
also need to start dragging in parts of the
run-time library from "/usr/lib".

On the bright side, if you have multiple
"chroot" trees on the same file system, then
you can use hard links instead of actual
copies of everything, which can save some
space.

[Don Mallory]

Ugh. Which version of ssh are you running?

Prior to v5.x, there was no support for chrooting the sftp server as part of the services.

By the error, I am also assuming that you have included the "Match Group" directive in your sshd_config, and the group file wasn't in the chrooted environment.

If you can get v5.x, you can do the following:

Subsystem sftp internal-sftp -f LOCAL2 -l VERBOSE
Match Group sftpusers
ForceCommand internal-sftp -f LOCAL2 -l VERBOSE
ChrootDirectory /sftpchroot
AllowTcpForwarding no

This would let you use the internal sftp server, log to LOCAL2 facility in syslog and chroot without having a huge chrooted environment built.

The group file doesn't need to be in there. The only thing you would need would be a copy of /dev/log for the syslog events to go to.

Don