RE: Re[2]: Re: [suse-security] FTP over SSH
For tunneling a FTP connection via SSH, please have a look at
http://www.ccp14.ac.uk/ccp14admin/security/secure_tunnelling_ftp.htm
I am under the impression that the solutions provided at the above link do indeed work as I suggested, i.e. the control connection is tunneled via SSH, but the data connection occurs outside of that tunnel, as is indicated by the link to 'SSH Tunneling via ProFTPD' on the page above. Note also that they have active and passive FTP mixed up in the quoted post titles 'Something to keep in mind'. HTH Tobias
For tunneling a FTP connection via SSH, please have a look at
http://www.ccp14.ac.uk/ccp14admin/security/secure_tunnelling_ftp.htm
I am under the impression that the solutions provided at the above link do indeed work as I suggested, i.e. the control connection is tunneled via SSH, but the data connection occurs outside of that tunnel, as is indicated by the link to 'SSH Tunneling via ProFTPD' on the page above. Note also that they have active and passive FTP mixed up in the quoted post titles 'Something to keep in mind'.
Yeah, you're right (I missed that funny part in the quoted post). And that's exactly why I prefer sftp and scp. You don't have to worry about the data connection, active and passive FTP and local or remote firewalls (if SSH is allowed). The only connection between local and remote host is the SSH connection. Ralf * * Ralf 'coko' Koch * mailto:info@formel4.de * --- Drücken Sie auf Abbrechen zum Fortfahren
FTP Attacks
http://www.securityportal.com/closet/closet20010418.html
Kurt Seifried, seifried@securityportal.com
PGP Key ID: 0xAD56E574 Fingerprint:
A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574
http://www.securityportal.com/
----- Original Message -----
From: "Ralf Koch"
For tunneling a FTP connection via SSH, please have a look at
http://www.ccp14.ac.uk/ccp14admin/security/secure_tunnelling_ftp.htm
I am under the impression that the solutions provided at the above link do indeed work as I suggested, i.e. the control connection is tunneled via SSH, but the data connection occurs outside of that tunnel, as is indicated by the link to 'SSH Tunneling via ProFTPD' on the page above. Note also that they have active and passive FTP mixed up in the quoted post titles 'Something to keep in mind'.
Yeah, you're right (I missed that funny part in the quoted post). And that's exactly why I prefer sftp and scp. You don't have to worry about the data connection, active and passive FTP and local or remote firewalls (if SSH is allowed). The only connection between local and remote host is the SSH connection. Ralf * * Ralf 'coko' Koch * mailto:info@formel4.de * --- Drücken Sie auf Abbrechen zum Fortfahren -- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
FTP Attacks http://www.securityportal.com/closet/closet20010418.html
pasvagg.pl: Did you actually try out what you write in that section? Are you positive about the conclusions at the end of that stanza, as well as the workarounds that you suggest? Are you sure that it is a good idea to restrict the destination of the PORT connection or the origin of the PASV connection to the origin of the data connection?
Kurt Seifried, seifried@securityportal.com PGP Key ID: 0xAD56E574 Fingerprint: A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.securityportal.com/
Roman.
--
- -
| Roman Drahtmüller
pasvagg.pl: Did you actually try out what you write in that section?
Yup, it worked fine against netscape.com and a few other sites I tried.
Are you positive about the conclusions at the end of that stanza, as well as the workarounds that you suggest?
Actually the real point of the article was to point out what a POS the ftp protocol is security wise. no matter what you do you got security issues.
Are you sure that it is a good idea to restrict the destination of the PORT connection or the origin of the PASV connection to the origin of the data connection?
proftpd does this I believe. As long as you don't have a multi-homed box sending/receiving the connections via different IP's it's mostly a non issue (I can't see to to many ftp servers doing this).
Roman.
1 more week, grinz =) -Kurt
And that's exactly why I prefer sftp and scp. You don't have to worry about the data connection, active and passive FTP and local or remote firewalls (if SSH is allowed). The only connection between local and remote host is the SSH connection.
Is it necessary to have a shell account on the machine? I have users which only have ftp access. Is it possible to have users with sftp but no shell? mfg ar -- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
On 21-Jun-01 Andreas Rittershofer wrote:
And that's exactly why I prefer sftp and scp. You don't have to worry about the data connection, active and passive FTP and local or remote firewalls (if SSH is allowed). The only connection between local and remote host is the SSH connection.
Is it necessary to have a shell account on the machine? I have users which only have ftp access. Is it possible to have users with sftp but no shell?
Yes, it's possible, at least with ssh and its ssh-dummy-shell which has been designed for this purpose. However, I wasn't too successful with other shells (false, noshell, scripts, etc.). Rejecting console access is highly recommended for sftp users just doing data transfer (e. g. for updating web pages).
mfg ar
-- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
---
Boris Lorenz
Is it necessary to have a shell account on the machine? I have users which only have ftp access. Is it possible to have users with sftp but no shell?
Yes, it's possible, at least with ssh and its ssh-dummy-shell which has been designed for this purpose. However, I wasn't too successful with other shells (false, noshell, scripts, etc.).
I just tried it with false, it didn't work. Now I look out for this dummy shell and will test it.
Rejecting console access is highly recommended for sftp users just doing data transfer (e. g. for updating web pages).
Thats exactly what I want. mfg ar -- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
On 21-Jun-01 Andreas Rittershofer wrote:
Is it necessary to have a shell account on the machine? I have users which only have ftp access. Is it possible to have users with sftp but no shell?
Yes, it's possible, at least with ssh and its ssh-dummy-shell which has been designed for this purpose. However, I wasn't too successful with other shells (false, noshell, scripts, etc.).
I just tried it with false, it didn't work.
Now I look out for this dummy shell and will test it.
ssh-dummy-shell is part of the ssh package for Linux from ssh.fi (ftp.ssh.fi/pub/ssh/ssh-2.4.0.tar.gz). I don't know wether it runs with OpenSSH. The trick of this dummy-shell is that it provides ssh wrapping of your sftp connection without the need of shell access.
Rejecting console access is highly recommended for sftp users just doing data transfer (e. g. for updating web pages).
Thats exactly what I want.
mfg ar
-- mailto:andreas@rittershofer.de http://www.rittershofer.de PGP-Public-Key http://www.rittershofer.de/ari.htm
---
Boris Lorenz
And that's exactly why I prefer sftp and scp. You don't have to worry about the data connection, active and passive FTP and local or remote firewalls (if SSH is allowed). The only connection between local and remote host is the SSH connection.
Is it necessary to have a shell account on the machine? I have users which only have ftp access. Is it possible to have users with sftp but no shell?
That's the cool part of sftp solutions. I use it with the /bin/ftponly shell - no problems. scp can't do that and the standard ssh tunnel can't do it too. Just test it with the SecureFX trial version. Cheers, Ralf P.S.: Please don't answer twice! If I'm posting to this list - why shouldn't I read the answers there? ;-)
participants (6)
-
Andreas Rittershofer -
Boris Lorenz -
Kurt Seifried -
Ralf Koch -
Reckhard, Tobias -
Roman Drahtmueller