sftp question
Frank Kuempel
I'm not really familar with the ssh or sftp, so please forgive.
Would like to setup a sftp server on a linux box for secure file
exchange. Is it possible to connect to sshd without having a valid shell
on the server like this :
> cat /etc/passwd
---> snip
billy:x:700:1000::/home/billy:/bin/false
thanks in advance
Frank
Richard E. Silverman
Frank Kuempel
> http://www.snailbook.com/faq/restricted-scp.auto.html
>
Hello Richard,
thank you for your response.
following the link :
The simplest way to do this is to make the target account
special-purpose, by giving it a shell which only allows runing the
file-transfer server. SSH always uses the shell to run remote programs,
so this is a reliable restriction. SSH invokes the shell program with
the option -c program to run program; your replacement should accept
either scp with appropriate arguments, or sftp-server, as appropriate.
SSH2 comes with ssh-dummy-shell for exactly this purpose, though
naturally it only handles sftp.
----
billy:x:700:1000::/home/billy:/usr/libexec/openssh/sft-server
would this be ok ? Btw where is the ssh-dummy-shell ?
Nico Kadel-Garcia
> Richard E. Silverman wrote:
>
>> http://www.snailbook.com/faq/restricted-scp.auto.html
>>
>
> Hello Richard,
>
> thank you for your response.
>
> following the link :
>
> The simplest way to do this is to make the target account
> special-purpose, by giving it a shell which only allows runing the
> file-transfer server. SSH always uses the shell to run remote programs,
> so this is a reliable restriction. SSH invokes the shell program with
> the option -c program to run program; your replacement should accept
> either scp with appropriate arguments, or sftp-server, as appropriate.
> SSH2 comes with ssh-dummy-shell for exactly this purpose, though
> naturally it only handles sftp.
Umm. Some of us disagree with this approach. Historically, way too many
"restricted shells" are easily broken out of, enabling the remote user
to gain a normal shell login. If you want to *thoroughly* trap them in a
local directory and keep them from poking around your system, I
recommend a chroot cage as well or instead.
Check out http://sourceforge.net/projects/chrootssh/ and the other
fascinating chroot/openssh pages at sourceforge.net.
Frank Kuempel
my problem.
Will try to do this tomorrow and will let you know my results
Thank you for your help
Best regards
Frank
Richard E. Silverman
FK> The simplest way to do this is to make the target account
FK> special-purpose, by giving it a shell which only allows runing the
FK> file-transfer server. SSH always uses the shell to run remote
FK> programs, so this is a reliable restriction. SSH invokes the shell
FK> program with the option -c program to run program; your
FK> replacement should accept either scp with appropriate arguments,
FK> or sftp-server, as appropriate. SSH2 comes with ssh-dummy-shell
FK> for exactly this purpose, though naturally it only handles sftp.
FK> ----
FK> billy:x:700:1000::/home/billy:/usr/libexec/openssh/sft-server
FK> would this be ok ?
It will, but only by accident; it happens that sftp-server ignores any
arguments. In general, as the quoted text says, you would need a program
which acts like the shell in starting the program(s) you want.
--
Richard Silverman
r...@qoxp.net
Richard E. Silverman
NKG> Umm. Some of us disagree with this approach. Historically, way
NKG> too many "restricted shells" are easily broken out of...
Disagree with this approach to *what*? This is not what Frank asked
about. He asked how to restrict the account to only running the
file-transfer server. He did not ask how to restrict file-transfer
operations to particular directories.
--
Richard Silverman
r...@qoxp.net
Nico Kadel-Garcia
True. But some of us disagree with merely running a "restricted shell"
as the user's login shell to control their behavior on the target
machine. If he still needs the "copy-only" behavior, he can put the
restricted shell inside a chroot cage to *really* control it and take
away all the system tools and shells that are otherwise available.
Also, I think that most folks looking to control a login user this way
would be even happier to keep that potentially dangerous user out of
their system files, their /tmp directory, their /etc/passwd, any
casually read-able userfiles belonging to other people, etc. This is
clearly the case for Frank, who asked the original question and said
"Thank you!" for the chroot cage pointer.
I've been pushing for our OpenSSH authors to incorporate the chroot
cages for *years*. I got refused pretty firmly the last couple of times
I tried, I think because they didn't see the need and had enough to do
at the time. Think it's time to try again?
Frank Kuempel
What I'm really looking for is a replacement for a simple ftp-server
like wu-ftpd etc. My intention is to set up a Linux-box with a "secure
FTP server"
Thank you for your help
Frank
G. Wolfe Woodbury
> What I'm really looking for is a replacement for a simple ftp-server
> like wu-ftpd etc. My intention is to set up a Linux-box with a "secure
> FTP server"
The "vsftpd" package is the "very secure FTP daemon" and is a simple and
security audited re-write of the "standard" FTP daemon. It is generally
easy to configure for anonymous FTP, and with some adjustments to the
config files it will handle user accounts.
It comes as a RPM in RedHat 8 and 9. I think its on sourceforge for
source and other platform packages. It looks like a BSD origin program.
--
Gregory G. "Wolfe" Woodbury `-_-' Owner/Admin: wolves.durham.nc.us
ggw at wolves.durham.nc.us U
"The Line Eater is a boojum snark." Hug your wolf.
Michael Sierchio
> What I'm really looking for is a replacement for a simple ftp-server
> like wu-ftpd etc. My intention is to set up a Linux-box with a "secure
> FTP server"
publicfile - http://cr.yp.to/publicfile.html
Nico Kadel-Garcia
> What I'm really looking for is a replacement for a simple ftp-server
> like wu-ftpd etc. My intention is to set up a Linux-box with a "secure
> FTP server"
>
> Thank you for your help
Ahh. Then you *DEFINITELY* want the chroot cage stuff to keep the
sort-of-ftp clients in their little cages, similar to the chroot
behavior for anonymous users and others in various FTP servers.
Nico Kadel-Garcia
> Frank Kuempel <fr...@try-us.de> shaped electrons to say:
>
>
>>What I'm really looking for is a replacement for a simple ftp-server
>>like wu-ftpd etc. My intention is to set up a Linux-box with a "secure
>>FTP server"
>
>
>
>>Frank
>
>
> The "vsftpd" package is the "very secure FTP daemon" and is a simple and
> security audited re-write of the "standard" FTP daemon. It is generally
> easy to configure for anonymous FTP, and with some adjustments to the
> config files it will handle user accounts.
>
> It comes as a RPM in RedHat 8 and 9. I think its on sourceforge for
> source and other platform packages. It looks like a BSD origin program.
It's a very secure FTP package, meaning it *still* takes passwords in
the clear from remote clients. It was designed securely from the ground
up to prevent the popular and ever-growing vulnerabilities of the older
wu-ftpd code, but it's still as prone to having the passwords sniffed as
any other genuine FTP package.
Don't use it if you can avoid it. It's just not a good idea these days
if you can possibly avoid it. Even HTTPS based servers are vastly better
for restricted download purposes, because the passwords are protected by
the SSL encryption.