Re: Building 2.6.10 kernel for Debian and ncurses
From: John Beardmore (wookie_at_wookie.demon.co.uk)
Date: Sun, 23 Jan 2005 17:32:42 +0000
In message <dPydnV2GzZ4LIW7cRVnfirstname.lastname@example.org>, Nico Kadel-Garcia
>"John Beardmore" <email@example.com> wrote in message
>> In message <firstname.lastname@example.org>, Andy Fraser
>> <email@example.com> writes
>>>In comp.os.linux.setup, John Beardmore uttered these immortal words:
>>>>>>On Debian you want the libncurses5-dev package.
>>>> Is there a general way to find the precise name of an available package
>>>> from the generic name of the facility ?
>>>> Let's say I want to track down Scp Only for example. How could I check
>>>> if it was available through apt ?
>>>scp is part of SSH so apt-file will help there. You'll probably need to
>> Yes, but I don't think that ScpOnly, see
>> http://www.sublimation.org/scponly/, is part of the standard ssh/scp
>> packages which are already installed and work fine.
>> I'm interested in ScpOnly as a login shell because I have large numbers of
>> people that get access to user IDs and passwords for our machines to
>> exchange large numbers of small files, and I don't want them to be able to
>> log in and poke about.
>> I just wondered if it was available as an apt package, but apt cache seems
>> to suggest not, so I've downloaded and compiled it.
>1: If you're going that route, you really want chroot cages. Look over at
>sourceforge.net for available chroot tools for SSH.
I thought that's more or less what ScpOnly offered ? To quote the home
"scponly" is an alternative 'shell' (of sorts) for system
administrators who would like to provide access to remote
users to both read and write local files without providing any
remote execution priviledges. Functionally, it is best
described as a wrapper to the "tried and true" ssh suite of
A typical usage of scponly is in creating a semi-public
account not unlike the concept of anonymous login for ftp.
This allows an administrator to share files in the same way
an anon ftp setup would, only employing all the protection
that ssh provides. This is especially significant if you
consider that ftp authentications traverse public networks
in a plaintext format.
logging: scponly logs time, client IP, username, and the
actual request to syslog chroot: scponly can chroot to the
user's home directory, disallowing access to the rest of
We use the linux password mechanism to authenticate users, and give them
ScpOnly as a shell which they can't interactively log in to.
> I used to publish
>patches to do that, but got busy with other projects and the OpenSSH authors
>have consistently rejected the patches for various policy reasons. But it's
>consistently turned out to be the right thing to do, since restricting user
>access once they've SSH'ed in has otherwise turned out to be quite
> I highly recommend Richard Silverman's book on SSH, and hopping
>over to the SSH newsgroups for more details.
Hmmm... I was hoping that having moved to ScpOnly I could avoid having
to learn loads more about this. Given what ScpOnly claims to do, will
time invested in reading the book and the news group really make my
world a safer place ?
>2: If you don't need to actually give them shells,
Not ones they can log into anyway.
> and just want them to
>securely exchange files without shell access, look into WebDAV running under
>Apache using HTTPS. I've used it extremely effecively for exactly that sort
>of access, and graphical drag&drop is built into Windows, the Konqueror web
>browser, and published Java widgets for other OS's.
In our case, although the end users have to enter user IDs and passwords
manually, the actual communication is managed from a VB6 user interface
to an accountancy training simulation.
I see WebDAV has a .NET component available, but I don't think we'd want
to port from VB6 to .NET just to use a nicer file transfer tool. Mind
you, our current practice of shelling out to pscp, while fairly robust,
looks pretty ugly.
-- John Beardmore