SUMMARY: Non-interactive sftp

Many thanks for the responses, notwithstanding the marginal
applicability of the question to the list.

The inital objective was to enable encrypted transfer of data between
two machines, whilst not allowing an interactive shell for this use.

I had been trying to do this with sftp, having learned that scp
required an interactive shell for its operation.

I had neglected to consider that sftp is simply an ssh subsystem -
sshd uses a shell in /etc/shells to run a subsystem driver, and thus a
valid shell is still needed.

Several people recommended looking at the scponly shell -
http://www.sublimation.org/scponly/ - I shall be playing with this in
a test environment - it looks to be very good.  A similar option would
be to use rssh.  I did also consider using one of the Solaris
restricted shells (/bin/rsh and /bin/rksh) but other than enforcing a
different PATH for the user, I was concerned that the user could
simply run /sbin/sh and then explore the filesystem, and couldn't see
how to prevent this.

Having established that there is not difference between sftp and scp
from a shell perspective, it makes no sense to use sftp - so I've
returned to using scp.

>From further reading, I've discovered that openssh / sunssh supports a
wide range of further access controls via the authorized_keys file.
Using, for example, the no-pty directive before the start of the
user's public key, we can prevent the user having a pty.  We could
also restrict the user to running one script or command.

So in this sense, the problem has been resolved.

What hasn't been resolved is why sftp wouldn't work even with a valid
shell.  All of my research has led me to believe this is a permissions
issue of some sort - but I have been unable to establish where the
problem lies.  I have, however, discovered:

* Cannot canonicalize means the sftp subsystem is attempting to use
the UID of the user to check the path after login, and failing.

* Other users have found that under some circumstances, the
permissions on the mount-point where the destination filesystem
resides need to be explicitly set to 755.

Thanks once again for your valuable input on what I accept is only
marginally a genuine sunmanager's question - if anyone is able further
to enlighten me on the issue of permissions and ownerships with
respect to source and destination filesystems for sftp, I'd be
grateful, and will of course further summarise.

Thanks guys,

Steve Nelson
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers