Re: secure file transfer (again)

[Hubert Chan]

> "Alf" == Alf B Lervåg <[EMAIL PROTECTED]> writes:

[...]

Alf> The problem with psftp and pscp, is that they're command line
Alf> tools.  This is all well and good for people who like it, but since
Alf> most of our students only use windows and gui programs, they
Alf> wouldn't like having to use cli. Never overestimate your users. ;)

http://www.i-tree.org/ixplorer.htm

A GUI frontend to pscp.

-- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.


pgpsBnWd8afCb.pgp
Description: PGP signature

Re: secure file transfer (again)

[Matthew Johnson]

On Fri, 2002-06-07 at 09:37, Alf B Lervåg wrote:

> Yes, I know about the putty suite. (First thing I download whenever I'm
> forced to sit on a windows computer. ;)
> 
> The problem with psftp and pscp, is that they're command line tools.
> This is all well and good for people who like it, but since most of our
> students only use windows and gui programs, they wouldn't like having to
> use cli. Never overestimate your users. ;)

There is a GUI front end that is being used in cambridge. Secure
iExplorer, I think. Theres a custom PuTTY package that includes it at
http://www.srcf.ucam.org/utilities/ssh/srcf-ssh.exe

I've had a few problems with it, but it generally works fine

-- 
Matthew Johnson
---
Matthew 6:25-34
"Therefore I tell you, do not worry... But seek first His Kingdom and
His Righteousness, and all these things will be given to you as well.
Therefore, do not worry about tommorrow..."


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer (again)

[Alf B Lervåg]

> On Thu, 6 Jun 2002, Andrew Ferrier wrote:
> > For Windows, the ssh client from www.ssh.com is the best I've
> > found. Don't know if free for university use though. If you
> > want a free client, WinSCP is best I've used, though it's far
> > more buggy than the aforementioned.
> 
> PSCP and PSFTP (part of the Putty suite) run under Windows, and are
> distributed under the MIT licence. They work fine for me, when I have to
> use an scp client under Windows.
> 
> 

Yes, I know about the putty suite. (First thing I download whenever I'm
forced to sit on a windows computer. ;)

The problem with psftp and pscp, is that they're command line tools.
This is all well and good for people who like it, but since most of our
students only use windows and gui programs, they wouldn't like having to
use cli. Never overestimate your users. ;)

-- 
Med hilsen,   | "... I'm sorry mrs tucker... your husband was
Alf B Lervåg  | brought in with a state of advanced ellipsis. He
  | hyperbolized and... I'm sorry, there was nothing
  | we could do."   -- Hatamoto


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer (again)

[Thomas Thurman]

On Thu, 6 Jun 2002, Andrew Ferrier wrote:
> For Windows, the ssh client from www.ssh.com is the best I've
> found. Don't know if free for university use though. If you
> want a free client, WinSCP is best I've used, though it's far
> more buggy than the aforementioned.

PSCP and PSFTP (part of the Putty suite) run under Windows, and are
distributed under the MIT licence. They work fine for me, when I have to
use an scp client under Windows.



T


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer (again)

[Andrew Ferrier]

On 2002-06-06 at 10:18, Alf B Lervåg wrote:

> Date: Thu, 6 Jun 2002 10:18:58 +0200
> From: Alf B Lervåg <[EMAIL PROTECTED]>
> To: debian-security@lists.debian.org
> Subject: secure file transfer (again)
> Resent-Date: Thu, 06 Jun 2002 15:06:26 +0100
> Resent-From: debian-security@lists.debian.org
>
> Reading the previous thread on secure file transfer, I felt
> like starting a thread myself.  This summer, I've been
> assigned the task of setting up sftp services at our
> university, so we can phase out ftp.
>
> What I'm asking, is if anyone has any experience with
> similiar projects, and if anyone can point me to
> documentation on how to setup the services, and also point me
> to sftp clients for different oses.
>
> ssh is already up and running on the servers, so I'm figuring
> that the sftp server shouldn't be too hard to get running.
> Problem is making things easy to use for our students. (Guess
> this falls in under the sftp client question.)

I've found that gftp is a fairly good *nix client (I run it on
Debian but don't know how portable it is). Graphical etc. so
nice and easy to use. Seems quite stable too.

For Windows, the ssh client from www.ssh.com is the best I've
found. Don't know if free for university use though. If you
want a free client, WinSCP is best I've used, though it's far
more buggy than the aforementioned.

Regards,
Andrew

-- 
Andrew Ferrier

email: [EMAIL PROTECTED]
web:   http://www.new-destiny.co.uk/andrew/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer (again)

[Tim Haynes]

Alf B Lervåg <[EMAIL PROTECTED]> writes:

> ssh is already up and running on the servers, so I'm figuring that the
> sftp server shouldn't be too hard to get running. Problem is making
> things easy to use for our students. (Guess this falls in under the sftp
> client question.)

 |  zsh/scr 11:36AM / # grep ftp /etc/ssh/sshd_config
 |  Subsystem   sftp/usr/lib/sftp-server
(I think this is all that's required server-side, isn't it?)

You might also find  a useful starting
point - see unix, java and `other' OSs in the top menu too.

~Tim
-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

secure file transfer (again)

[Alf B Lervåg]

Reading the previous thread on secure file transfer, I felt like
starting a thread myself.  This summer, I've been assigned the task
of setting up sftp services at our university, so we can phase out ftp.

What I'm asking, is if anyone has any experience with similiar projects,
and if anyone can point me to documentation on how to setup the
services, and also point me to sftp clients for different oses.

ssh is already up and running on the servers, so I'm figuring that the
sftp server shouldn't be too hard to get running. Problem is making
things easy to use for our students. (Guess this falls in under the sftp
client question.)

-- 
Med hilsen,   | "... I'm sorry mrs tucker... your husband was
Alf B Lervåg  | brought in with a state of advanced ellipsis. He
  | hyperbolized and... I'm sorry, there was nothing
  | we could do."   -- Hatamoto


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Nato]

Thanks for all the suggestions.  This mailing list rocks 

Nato
- Original Message -
From: "José Luis Ledesma" <[EMAIL PROTECTED]>
To: "'Renato Lozano'" <[EMAIL PROTECTED]>;

Sent: Wednesday, June 05, 2002 3:57 AM
Subject: RE: secure file transfer


> You can do a chrooted enviroment (see above) And start de sshd witch
chroot
>  /sbin/sshd -f /etc/sshd_config
>
> Also you can specify the shell of the users in /etc/passwd as
> /sbin/sftp-server if you only want to allow this users do a sftp.
>
>
> Regards,
>
> .:
> total 36
> drwxr-xr-x 9 root root 4096 Jun 5 10:05 ./
> drwxr-xr-x 11 root root 4096 Jun 3 13:43 ../
> drwxr-xr-x 2 root root 4096 Jun 4 12:13 bin/
> drwxr-xr-x 2 root root 4096 Jun 4 12:16 dev/
> drwxr-xr-x 4 root root 4096 Jun 4 12:35 etc/
> drwxr-xr-x 3 root root 4096 Jun 4 12:13 lib/
> drwxr-xr-x 2 root root 4096 Jun 4 12:35 sbin/
> drwxr-xr-x 2 root root 4096 Jun 4 12:32 tmp/
> drwxr-xr-x 2 root root 4096 Jun 4 12:16 usr/
> ./bin:
> total 8368
> drwxr-xr-x 2 root root 4096 Jun 4 12:13 ./
> drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
> -rwxr-xr-x 1 root root 109855 Jun 3 13:45 a2p*
> -rwxr-xr-x 1 root root 387764 Jun 3 13:45 bash*
> -rwxr-xr-x 1 root root 36365 Jun 3 13:45 c2ph*
> -rwxr-xr-x 1 root root 20629 Jun 3 13:45 dprofpp*
> -rwxr-xr-x 1 root root 6956 Jun 3 13:46 env*
> -rwxr-xr-x 1 root root 158116 Jun 3 13:45 fax2ps*
> -rwxr-xr-x 1 root root 104008 Jun 3 13:45 faxalter*
> -rwxr-xr-x 1 root root 89340 Jun 3 13:45 faxcover*
> -rwxr-xr-x 1 root root 441584 Jun 3 13:45 faxmail*
> -rwxr-xr-x 1 root root 96036 Jun 3 13:45 faxrm*
> -rwxr-xr-x 1 root root 107000 Jun 3 13:45 faxstat*
> -rwxr-xr-x 1 root root 77832 Jun 4 11:46 grep*
> -rwxr-xr-x 1 root root 19597 Jun 3 13:45 h2ph*
> -rwxr-xr-x 1 root root 46979 Jun 3 13:45 h2xs*
> -rwxr-xr-x 1 root root 10420 Jun 3 13:46 id*
> -rwxr-xr-x 1 root root 4528 Jun 3 13:46 ldd*
> -rwxr-xr-x 1 root root 111386 Jun 4 11:46 less*
> -r-xr-xr-x 1 root root 26168 Jun 3 13:45 login*
> -rwxr-xr-x 1 root root 49164 Jun 3 13:45 ls*
> -rwxr-xr-x 1 root root 11600 Jun 3 13:45 mkdir*
> -rwxr-xr-x 1 root root 24780 Jun 3 13:45 more*
> -rwxr-xr-x 1 root root 154980 Jun 3 13:45 pal2rgb*
> -rwsr-xr-x 1 root root 27920 Jun 3 13:46 passwd*
> -rwxr-xr-x 1 root root 4241 Jun 3 13:45 pl2pm*
> -rwxr-xr-x 1 root root 2350 Jun 3 13:45 pod2html*
> -rwxr-xr-x 1 root root 7875 Jun 3 13:45 pod2latex*
> -rwxr-xr-x 1 root root 17587 Jun 3 13:45 pod2man*
> -rwxr-xr-x 1 root root 6877 Jun 3 13:45 pod2text*
> -rwxr-xr-x 1 root root 3300 Jun 3 13:45 pod2usage*
> -rwxr-xr-x 1 root root 3341 Jun 3 13:45 podchecker*
> -rwxr-xr-x 1 root root 2483 Jun 3 13:45 podselect*
> -r-xr-xr-x 1 root root 82412 Jun 4 11:46 ps*
> -rwxr-xr-x 1 root root 36365 Jun 3 13:45 pstruct*
> -rwxr-xr-x 1 root root 7120 Jun 3 13:45 pwd*
> -rwxr-xr-x 1 root root 179884 Jun 3 13:45 rgb2ycbcr*
> -rwxr-xr-x 1 root root 20532 Jun 3 13:45 rm*
> -rwxr-xr-x 1 root root 6720 Jun 4 10:15 rmdir*
> -rwxr-xr-x 1 root root 14705 Jun 3 13:45 s2p*
> -rwxr-xr-x 1 root root 28764 Jun 3 13:46 scp*
> -rwxr-xr-x 1 root root 385000 Jun 3 13:45 sendfax*
> -rwxr-xr-x 1 root root 67548 Jun 3 13:45 sendpage*
> -rwxr-xr-x 1 root root 88632 Jun 3 13:46 sftp*
> -rwxr-xr-x 1 root root 387764 Jun 3 13:45 sh*
> -rws--x--x 1 root root 744500 Jun 3 13:46 slogin*
> -rwxr-xr-x 1 root root 14523 Jun 3 13:46 splain*
> -rws--x--x 1 root root 744500 Jun 3 13:46 ssh*
> -rwxr-xr-x 1 root root 570960 Jun 3 13:46 ssh-add*
> -rwxr-xr-x 1 root root 502952 Jun 3 13:46 ssh-agent*
> -rwxr-xr-x 1 root root 575740 Jun 3 13:46 ssh-keygen*
> -rwxr-xr-x 1 root root 383480 Jun 3 13:46 ssh-keyscan*
> -rwxr-xr-x 1 root root 39 Jun 3 13:46 ssh_europa*
> -rwxr-xr-x 1 root root 107252 Jun 4 10:14 strace*
> -rwxr-xr-x 1 root root 8323 Jun 4 10:14 strace-graph*
> -rwxr-xr-x 1 root root 158088 Jun 3 13:46 thumbnail*
> -rwxr-xr-x 1 root root 6312 Jun 3 13:46 tty*
> -rwxr-xr-x 1 root root 55904 Jun 4 11:46 useradd*
> -rwxr-xr-x 1 root root 585656 Jun 4 11:47 vi*
> -rwxr-xr-x 1 root root 6444 Jun 4 11:45 whoami*
> ./dev:
> total 8
> drwxr-xr-x 2 root root 4096 Jun 4 12:16 ./
> drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
> crw-r--r-- 1 root root 1, 9 Jun 3 13:43 urandom
> ./etc:
> total 208
> drwxr-xr-x 4 root root 4096 Jun 4 12:35 ./
> drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
> -rw--- 1 root root 0 Jun 4 11:46 .pwd.lock
> -rw-r--r-- 1 root root 653 Jun 3 13:46 group
> -rw-r--r-- 1 root root 242 Jun 4 11:33 host.conf
> -rw-r--r-- 1 root root 857 Jun 4 12:04 hosts
> -rw-r--r-- 1 root root 1050 Jun 4 11:29 ld.so.cache
> -rw-r--r-- 1 root root 304 Jun 4 11:28 ld.so.conf
> -rw-r--r-- 1 root root 235 Jun 4 11:27 ld.so.conf~
>

Re: secure file transfer

[Will Aoki]

On Tue, Jun 04, 2002 at 09:58:55AM -0400, Jon McCain wrote:
> You can remove the sftp-server program to disable sftp but you can't
> turn off the scp commands.  They are part of ssh.  So someone could
> still use something like winscp and be able to browse everything.
> 
> You can "break" scp by making the users shell a menu script (i.e.
> /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
> prompt.  You also have to define your menu script as a shell
> (/etc/shell) so regular ftp will still work.

Or you could use pam_listfile or pam_wheel in the PAM control file for
ssh to restrict ssh logins. For example, on one of my servers, I have
this line in /etc/pam.d/ssh:

auth   required pam_listfile.so sense=allow onerr=fail item=user 
file=/etc/loginusers

which keeps anyone not listed in /etc/loginusers from logging in.

-- 
William Aoki [EMAIL PROTECTED]   /"\  ASCII Ribbon Campaign
B1FB C169 C7A6 238B 280B  <- key change\ /  No HTML in mail or news!
99AF A093 29AE 0AE1 9734   prev. expiredX
   / \


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Jon McCain]

> 
> In proftpd.conf:
> 
> RequireValidShell   off
> 
> ;-)
> 

I would be careful about doing that.  That might open ftp
access for accounts you dont want to have access.  Plus some
applications create special accounts without shells like
mysql,inetd,etc.

mysql:x:103:102:MySQL Server:/var/lib/mysql:/bin/false

You don't want to sacrifice security for convenience.

   ___
  (@ @)
--oOo--(_)--oOo---
Jon McCainEmail: [EMAIL PROTECTED]
Sr. ProgrammerVoice: 912-355-3213
DavLong Business Solutions  Fax: 912-355-3575


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Wichert Akkerman]

Previously Michael van der Kolff wrote:
> if you want to implement a huge one you'll have to find the x.509 cert
> patch, but from what I hear it's quite a flexible implementation.

It seems to work quite well. The X.509 and multi-crypto patches are
both included in the kernel-patch-freeswan package so it should be
easy to create a freeswan enabled kernel.

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: secure file transfer

[José Luis Ledesma]

pam_time.so*
-rwxr-xr-x 1 root root 45703 Jun 3 13:46 pam_unix.so*
-rwxr-xr-x 1 root root 45703 Jun 3 13:46 pam_unix2.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_acct.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_auth.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_passwd.so*
-rwxr-xr-x 1 root root 45386 Jun 3 13:46 pam_unix_session.so*
-rwxr-xr-x 1 root root 9726 Jun 3 13:46 pam_userdb.so*
-rwxr-xr-x 1 root root 6424 Jun 3 13:46 pam_warn.so*
-rwxr-xr-x 1 root root 7460 Jun 3 13:46 pam_wheel.so*
./sbin:
total 3132
drwxr-xr-x 2 root root 4096 Jun 4 12:35 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
-rwxr-xr-x 1 root root 178256 Jun 3 13:46 choptest*
-rwxr-xr-x 1 root root 184032 Jun 3 13:46 cqtest*
-rwxr-xr-x 1 root root 81096 Jun 3 13:46 dialtest*
-rwxr-xr-x 1 root root 1142128 Jun 4 11:28 ldconfig*
-rwxr-xr-x 1 root root 2868 Jun 3 13:46 lockname*
-rwxr-xr-x 1 root root 3340 Jun 3 13:46 ondelay*
-rwxr-xr-x 1 root root 376796 Jun 3 13:46 pagesend*
-rwxr-xr-x 1 root root 13950 Jun 3 13:46 probemodem*
-rwxr-xr-x 1 root root 9234 Jun 3 13:46 recvstats*
-rwxr-xr-x 1 root root 64480 Jun 3 13:46 sftp-server*
-rwxr-xr-x 1 root root 744412 Jun 3 13:46 sshd*
-rwsr-xr-x 1 root root 30750 Jun 4 11:46 su*
-rwxr-xr-x 1 root root 194632 Jun 3 13:46 tagtest*
-rwxr-xr-x 1 root root 69892 Jun 3 13:46 tsitest*
-rwxr-xr-x 1 root root 43792 Jun 3 13:46 typetest*
./tmp:
total 8
drwxr-xr-x 2 root root 4096 Jun 4 12:32 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
./usr:
total 8
drwxr-xr-x 2 root root 4096 Jun 4 12:16 ./
drwxr-xr-x 9 root root 4096 Jun 5 10:05 ../
lrwxrwxrwx 1 root root 7 Jun 4 12:14 bin -> ../bin//
lrwxrwxrwx 1 root root 7 Jun 4 11:33 lib -> ../lib//
lrwxrwxrwx 1 root root 8 Jun 4 12:13 sbin -> ../sbin//



_ 
CLUSTER COMPETITIVENESS 
José Luis Ledesma 
Technology Park Valles 
08290 Barcelona - Spain 
http://www.clustercom.com 
Tel.: +34 93 582 02 90   Fax: +34 93 582 01 59 
-Original Message-
From: Renato Lozano [mailto:[EMAIL PROTECTED]
Sent: martes, 04 de junio de 2002 2:40
To: debian-security@lists.debian.org
Subject: secure file transfer


Hi All, 

I am trying to implement a way of transfering files securely over the
Internet using sftp which is part of the ssh2 protocol.  A down side of
implementing this is that users logging on can browse the whole filesystem.
I have done some research and found a way to chroot users so they won't be
able to browse the filesystem (http://chrootssh.sourceforge.net/).  Can
someone please suggest if there are any other ways of implementing a secure
file transfer without patching sshd ???

Nato


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Michael van der Kolff]

I'd say that the most flexible way of doing so is probably using
freeswan, which you can find in the unstable packages.  Additionally,
you'll have to build your kernel again, and if you want to implement a
huge one you'll have to find the x.509 cert patch, but from what I hear
it's quite a flexible implementation.  I believe I'll be having a go at
implementing it soon :)

My $0.02

Michael van der Kolff
A Perfect PC
Gymea, Sydney, Australia


On Tue, 2002-06-04 at 23:58, Jon McCain wrote:
> 
> 
> > Renato Lozano wrote:
> > 
> > Hi All,
> > 
> > I am trying to implement a way of transfering files securely over the
> > Internet using sftp which is part of the ssh2 protocol.  A down side
> > of implementing this is that users logging on can browse the whole
> > filesystem.  I have done some research and found a way to chroot users
> > so they won't be able to browse the filesystem
> > (http://chrootssh.sourceforge.net/).  Can someone please suggest if
> > there are any other ways of implementing a secure file transfer
> > without patching sshd ???
> > 
> > Nato
> 
> I had the same concerns a few months back.  I wanted to use sftp but I
> disliked the fact that they can see the whole filesystem although
> debian's default permission on the important files prevents anyone from
> changing them.  I did not want to patch ssh either.  It was so complex
> and I wanted to be keep to a standard ssh so as to keep up with the
> security updates to ssh.   So I used vpn and ftp. The firewall is set to
> block the ftp ports for anything from the internet.  Using vpn gives the
> user a local ip and thus allows ftp to get through plus the traffic is
> encrypted. Proftp lets you chroot the user to their home dir.
> 
> You can remove the sftp-server program to disable sftp but you can't
> turn off the scp commands.  They are part of ssh.  So someone could
> still use something like winscp and be able to browse everything.
> 
> You can "break" scp by making the users shell a menu script (i.e.
> /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
> prompt.  You also have to define your menu script as a shell
> (/etc/shell) so regular ftp will still work.
> -- 
>___
>   (@ @)
> --oOo--(_)--oOo---
> Jon McCainEmail: [EMAIL PROTECTED]
> Sr. ProgrammerVoice: 912-355-3213
> DavLong Business Solutions  Fax: 912-355-3575
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 
> 
> 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Emmanuel Lacour]

On Tue, Jun 04, 2002 at 09:58:55AM -0400, Jon McCain wrote:
> 
> 
> > Renato Lozano wrote:
> > 
> > Hi All,
> > 
> > I am trying to implement a way of transfering files securely over the
snip

> 
> You can remove the sftp-server program to disable sftp but you can't
> turn off the scp commands.  They are part of ssh.  So someone could
> still use something like winscp and be able to browse everything.
> 
> You can "break" scp by making the users shell a menu script (i.e.
> /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
> prompt.  You also have to define your menu script as a shell
> (/etc/shell) so regular ftp will still work.

In proftpd.conf:

RequireValidShell   off

;-)

-- 
Easter-eggsSpécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris   -   France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76
mailto:[EMAIL PROTECTED]   -http://www.easter-eggs.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Emmanuel Lacour]

On Tue, Jun 04, 2002 at 09:58:55AM -0400, Jon McCain wrote:
> 
> 
> > Renato Lozano wrote:
> > 
> > Hi All,
> > 
> > I am trying to implement a way of transfering files securely over the
snip

> 
> You can remove the sftp-server program to disable sftp but you can't
> turn off the scp commands.  They are part of ssh.  So someone could
> still use something like winscp and be able to browse everything.
> 
> You can "break" scp by making the users shell a menu script (i.e.
> /usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
> prompt.  You also have to define your menu script as a shell
> (/etc/shell) so regular ftp will still work.

In proftpd.conf:

RequireValidShell   off

;-)

-- 
Easter-eggsSpécialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris   -   France -  Métro Gaité
Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76
mailto:[EMAIL PROTECTED]   -http://www.easter-eggs.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Jon McCain]

> Renato Lozano wrote:
> 
> Hi All,
> 
> I am trying to implement a way of transfering files securely over the
> Internet using sftp which is part of the ssh2 protocol.  A down side
> of implementing this is that users logging on can browse the whole
> filesystem.  I have done some research and found a way to chroot users
> so they won't be able to browse the filesystem
> (http://chrootssh.sourceforge.net/).  Can someone please suggest if
> there are any other ways of implementing a secure file transfer
> without patching sshd ???
> 
> Nato

I had the same concerns a few months back.  I wanted to use sftp but I
disliked the fact that they can see the whole filesystem although
debian's default permission on the important files prevents anyone from
changing them.  I did not want to patch ssh either.  It was so complex
and I wanted to be keep to a standard ssh so as to keep up with the
security updates to ssh.   So I used vpn and ftp. The firewall is set to
block the ftp ports for anything from the internet.  Using vpn gives the
user a local ip and thus allows ftp to get through plus the traffic is
encrypted. Proftp lets you chroot the user to their home dir.

You can remove the sftp-server program to disable sftp but you can't
turn off the scp commands.  They are part of ssh.  So someone could
still use something like winscp and be able to browse everything.

You can "break" scp by making the users shell a menu script (i.e.
/usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
prompt.  You also have to define your menu script as a shell
(/etc/shell) so regular ftp will still work.
-- 
   ___
  (@ @)
--oOo--(_)--oOo---
Jon McCainEmail: [EMAIL PROTECTED]
Sr. ProgrammerVoice: 912-355-3213
DavLong Business Solutions  Fax: 912-355-3575


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Jon McCain]

> Renato Lozano wrote:
> 
> Hi All,
> 
> I am trying to implement a way of transfering files securely over the
> Internet using sftp which is part of the ssh2 protocol.  A down side
> of implementing this is that users logging on can browse the whole
> filesystem.  I have done some research and found a way to chroot users
> so they won't be able to browse the filesystem
> (http://chrootssh.sourceforge.net/).  Can someone please suggest if
> there are any other ways of implementing a secure file transfer
> without patching sshd ???
> 
> Nato

I had the same concerns a few months back.  I wanted to use sftp but I
disliked the fact that they can see the whole filesystem although
debian's default permission on the important files prevents anyone from
changing them.  I did not want to patch ssh either.  It was so complex
and I wanted to be keep to a standard ssh so as to keep up with the
security updates to ssh.   So I used vpn and ftp. The firewall is set to
block the ftp ports for anything from the internet.  Using vpn gives the
user a local ip and thus allows ftp to get through plus the traffic is
encrypted. Proftp lets you chroot the user to their home dir.

You can remove the sftp-server program to disable sftp but you can't
turn off the scp commands.  They are part of ssh.  So someone could
still use something like winscp and be able to browse everything.

You can "break" scp by making the users shell a menu script (i.e.
/usr/bin/yourmenu instead of /usr/bin/bash) so they can not get to a $
prompt.  You also have to define your menu script as a shell
(/etc/shell) so regular ftp will still work.
-- 
   ___
  (@ @)
--oOo--(_)--oOo---
Jon McCainEmail: [EMAIL PROTECTED]
Sr. ProgrammerVoice: 912-355-3213
DavLong Business Solutions  Fax: 912-355-3575


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Davy Gigan]

Renato Lozano writes:
 > I am trying to implement a way of transfering files securely over
 > the Internet using sftp which is part of the ssh2 protocol.  A
 > down side of implementing this is that users logging on can browse
 > the whole filesystem.  I have done some research and found a way
 > to chroot users so they won't be able to browse the filesystem
 > (http://chrootssh.sourceforge.net/).  Can someone please suggest
 > if there are any other ways of implementing a secure file transfer
 > without patching sshd ???

You may try sfs (Self-Certifying File System server), you can find
testing packages and the home page is at http://www.fs.net. With
this kind of system, you'll be able to allow someone to mount his
homedir but nothing else.

-- 
Davy Gigan
System & Network Administration  [Please no HTML, I'm not a browser]
University Of Caen (France)   [Pas d'HTML, je ne suis pas un navigateur]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: secure file transfer

[Davy Gigan]

Renato Lozano writes:
 > I am trying to implement a way of transfering files securely over
 > the Internet using sftp which is part of the ssh2 protocol.  A
 > down side of implementing this is that users logging on can browse
 > the whole filesystem.  I have done some research and found a way
 > to chroot users so they won't be able to browse the filesystem
 > (http://chrootssh.sourceforge.net/).  Can someone please suggest
 > if there are any other ways of implementing a secure file transfer
 > without patching sshd ???

You may try sfs (Self-Certifying File System server), you can find
testing packages and the home page is at http://www.fs.net. With
this kind of system, you'll be able to allow someone to mount his
homedir but nothing else.

-- 
Davy Gigan
System & Network Administration  [Please no HTML, I'm not a browser]
University Of Caen (France)   [Pas d'HTML, je ne suis pas un navigateur]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

secure file transfer

[Renato Lozano]

Hi All, 
 
I am trying to implement a way of transfering files 
securely over the Internet using sftp which is part of the ssh2 
protocol.  A down side of implementing this is that users logging on can 
browse the whole filesystem.  I have done some research and found a way to 
chroot users so they won't be able to browse the filesystem (http://chrootssh.sourceforge.net/).  
Can someone please suggest if there are any other ways of implementing a secure 
file transfer without patching sshd ???
 
Nato

secure file transfer

[Renato Lozano]

Hi All, 
 
I am trying to implement a way of transfering files 
securely over the Internet using sftp which is part of the ssh2 
protocol.  A down side of implementing this is that users logging on can 
browse the whole filesystem.  I have done some research and found a way to 
chroot users so they won't be able to browse the filesystem (http://chrootssh.sourceforge.net/).  
Can someone please suggest if there are any other ways of implementing a secure 
file transfer without patching sshd ???
 
Nato