On 22/03/02, 14:10:05, "Lennart Regebro" <lennart@torped.se> wrote regarding Re: [Zope] ssh and zope:

From: "Robert Hood, Ph.D." <rhood@mtsu.edu>

...

is it possible to ssh in to zope (or: can anyone suggest how I might configure my server to do this)?

Zope doesn't have a command prompt, so I don't understand your question. How do you mean "in to Zope"?

Well, there's zshell but that uses a browser. There are command line webDav clients. Cadaver lets you do a lot of Zope stuff, including editing text files in vi;) from a cli shell. He could ssh in to the zope host and run cadaver locally, for security. -- Bruce

On Fri, Mar 22, 2002 at 09:09:31AM -0600, Robert Hood, Ph.D. wrote:

I've been advised by security people on my campus to shut down normal ftp and telnet access to my server if possible and to use sftp and ssh for access. I currently sometimes ftp things to zope.

One solution would be (this assumes that your Zope server runs on some sort of Unix variant) to: 1) have ZServer listen only on the localhost interface (named lo, address 127.0.0.1) 2) get an SSH client on your desktop computer that does port forwarding. Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) works fine for Windows in that regard. This would allow you to set up an encrypted tunnel between your desktop computer and the Zope server's FTP port (or HTTP port, or Webdav port, whatever). 3) You'd then point your ftp client to the port on your desktop computer that is on one end of the tunnel, and you'd be automatically connected to the server port that's not otherwise exposed to the outside world. 4) Since your Zope ports are no longer directly exposed to the outside world, you'll have to put Apache, Squid, or some other proxy-capable server on your publicly-available port 80. You may have already done this for other reasons, though.

I do not have any packages installed that give zope file system access, so I don't really think zope's ftp port would be a security hazard (and my own view is that my machine does not have any national security type stuff on it, so that this request may be going a bit far).

As an aside, your security-conscious (or security-paranoid) coworkers don't care whether or not you have national-security information on the server. I'm one of their security-paranoid counterparts up the road, and if they're anything like me, their concerns include: - the possibility that someone's cleartext password would be sniffed in a lab, from offsite, or wherever. If someone used the same password on their FTP server and on their main email account (or worse, their account that gets them into the student records system), there's a potentially big compromise there. Maybe the FTP server only has your account on it, but they don't know that. Maybe you use different passwords there and other place, but they don't know that either. And they're not likely to maintain a list of low-account-number, properly-differently-passworded FTP servers that they don't control. - the possibility for a poorly-written FTP server to be used in bounce attacks on other hosts. No, Zope's FTP server isn't a candidate for that right now. However, they're not going to keep a list that says "oh, *that* FTP server's for Bob's Zope site (running Zope 2.foo.bar). That version's 100% secure, so let it run". -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University -- renfro@tntech.edu

On Fri, 22 Mar 2002 09:09:31 -0600 (CST), "Robert Hood, Ph.D." <rhood@mtsu.edu> wrote:

and to use sftp and ssh for access.

That makes sense.

I currently sometimes ftp things to zope. I do not have any packages installed that give zope file system access, so I don't really think zope's ftp port would be a security hazard (and my own view is that my machine does not have any national security type stuff on it, so that this request may be going a bit far).

The risk is that your zope password is transmitted in the clear across your network. I dont think their requests is unreasonable. Anyone with physical access to your network can break into your zope server. If you accidentally type a password for a different system into the zope ftp prompt, then that can break into that other system too. The same is true of authentication over http too; I guess this hasnt hit your security people's radar yet.

Suggestions appreciated.

Use a secure method to copy files across the network onto the zope machine; scp is ok, but a network filesystem may be easier. Then use ssh to log on to that machine, and use a local ftp to transfer things into zope. There is no security problem with ftp that does not cross a network. Toby Dickenson tdickenson@geminidataloggers.com

On Fri, 2002-03-22 at 17:12, Robert Hood, Ph.D. wrote:

thanks for all the information re: ssh / sftp.

I didn't mean to sound resentful about the security requests. I'm switching over to linux (currently my server is NT) to improve security. (among other things). And a colleague's academic server at another school got hacked into recently, which has really perked up my ears.

Ahh, security. I have to enforce security in over 600 locations. That's a lot of people that think of me as the "technology taxman". Oh well, never thought I would win any popularity contests!

again, thanks for the advice (and any additional advice).

Another solution that I did not see mentioned earlier. Has a dependency: 1) Use apache, with mod_dav reverse-proxied to the DAV port of Zope 2) SSL-enable apache 3) use cadaver as "ftp-like" client, with SSL enabled This (to me at least) looks the cleanest, as each technology is being used as intended -;^>= I'm doing it on my machine at home just to see what it takes to get going, and it really was not that bad... -- Mitch Pirtle Corporate Security Officer Kühne & Nagel Management AG Tel: +41 1 786 96 45 Fax: +41 1 786 95 95

On Fri, 22 Mar 2002, Bruce Richardson wrote:

Well, there's zshell but that uses a browser.

You can also use ZShell from your favorite shell using Andy McKay's ZShellCLI. This needs more work, especially most of the ZShell commands don't output anything when successful to better mimic the Unix commands, so ZShellCLI is not very verbose when commands ran OK, but it can be used this way. ZShellCLI is now part of ZShell. The soon-to-be-released next version of ZShell will feature improvements wrt ZShellCLI interaction, as well as an impressing preliminary support for ZShell variables useable like the Unix shell ones (e.g. $0 ... $n, $PATH, etc...) I originally planned to release a new version because I've modified the license again : since the ZPL is compatible with the GPL now, ZShell's new license is pure GPL. bye, Jerome Alet