The FTP question
Summary: decided not to install any kind of ftp server for now. Use sftp only (part of ssh).
When the webserver is built I'm going to need to give access to the staff in the department who updates content - using Dreamweaver, as well as to our design company.
I want to make sure that each user who accesses the web folders with write access has an individual account (counting the design vendor as a single user). Furthermore I want all login information to be encrypted.
This means that instead of using the default ftp server I'm going to need a secure method of file transfer.
Briefly I considered web-dav, http, sftp and others. The deiciding factors are security and ease of use. Ease of use applies only to myself, my office staff and our design company.
When it came time to choose an ftp over ssl server I relied completely on the information on this site: www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html I also refered to a link which convinced me that ftp-ssl was preferable to sftp www.enterprisedt.com/products/edtftpjssl/faq-answers.html
I've spent several days (over the past two weeks) evaluating ftp-ssl servers and I've gone through considerable trouble learning how to install them. (I went with bsdftpd-ssl-1.0.2 Secure FTP server with the TLS/SSL support) , however, in the process of writing this update in the blog I reviewed the requirements for Dreamweaver. I cannot find any indication that DW supports ftp-ssl after all. So it looks like I'll have to go back to the drawing board and enable sftp.
Partway through the headache of trying to find information in man sshd(8) and sftp-server(8) about setting up sftp I just decided to try it out on a whim. It seems that ssh is already running the sftp subsystem. Hah! I'll try to figure out where this is set later.
As the day wears on I'm getting frustrated. SSH seems like a poor subsitute for the functionality of ftp (and the security of ftp-ssl). I'm going to have to step back and look at the problem objectively.
What we love about ftp is that you can specify clear separation of shell accounts vs ftp. In the file ftpusers you can list all accounts and groups that are not allowed ftp access. I put @wheel there. So no account that is able to SU is able to login with ftp.
Also it is easy to set up ftp with chroot so that ftp users can be limited to specific directories. I want my staff and designers to have ftp access to the web documents only. Maybe even only a subdirectory of the web document even. With sftp I'm allowing people ssh access by default. Also they have access to the whole file system.
I think ftp-ssl is clearly more elegant and less complex however I am stuck supporting dreamweaver both in the office and for our vendors.
-------------
After some agonizing I'm sketching in the following plan. I'll go with sftp after all. But I won't use the chroot and I wont deny shell access. chroot() and no shell access introduces more complexity into the system than I'm willing to deal with at the moment. It's better to trust my staff and our design vendor than to risk openning a new security hole by screwing up chroot or jails.
However - to make things simple. The sftp users accounts will all have the web document root as their home directory. At least that make their job simpler as by default they will start in the correct directory when they log in either through sftp or shh.
------------
Okay that's not so simple. Must give these users r/w access to htdocs and below. Also if one user creates a file in the web root will it default to 644 or 755? What they will need is 664 or 775. Hmm.
...
right, umask does this. umask can be set for each user in their profile or for login classes (sic) in /etc/profile or /etc/login.conf - thats the job for tomorrow.
I wonder what everyone else does?
I also wonder what will happen when I start using scripts in web pages. Argh.
I would think - if the users all create files that are group rwx 'able and the http server (www) will be a member of the same group...? But does any one ever do this?
When the webserver is built I'm going to need to give access to the staff in the department who updates content - using Dreamweaver, as well as to our design company.
I want to make sure that each user who accesses the web folders with write access has an individual account (counting the design vendor as a single user). Furthermore I want all login information to be encrypted.
This means that instead of using the default ftp server I'm going to need a secure method of file transfer.
Briefly I considered web-dav, http, sftp and others. The deiciding factors are security and ease of use. Ease of use applies only to myself, my office staff and our design company.
- Dreamweaver 4.0 supports ftp, web-dav and some other proprietary protocols
- Dreamweaver MX supports the the above plus sftp (which actually uses shh protocol not ftp)
When it came time to choose an ftp over ssl server I relied completely on the information on this site: www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html I also refered to a link which convinced me that ftp-ssl was preferable to sftp www.enterprisedt.com/products/edtftpjssl/faq-answers.html
I've spent several days (over the past two weeks) evaluating ftp-ssl servers and I've gone through considerable trouble learning how to install them. (I went with bsdftpd-ssl-1.0.2 Secure FTP server with the TLS/SSL support) , however, in the process of writing this update in the blog I reviewed the requirements for Dreamweaver. I cannot find any indication that DW supports ftp-ssl after all. So it looks like I'll have to go back to the drawing board and enable sftp.
Partway through the headache of trying to find information in man sshd(8) and sftp-server(8) about setting up sftp I just decided to try it out on a whim. It seems that ssh is already running the sftp subsystem. Hah! I'll try to figure out where this is set later.
As the day wears on I'm getting frustrated. SSH seems like a poor subsitute for the functionality of ftp (and the security of ftp-ssl). I'm going to have to step back and look at the problem objectively.
What we love about ftp is that you can specify clear separation of shell accounts vs ftp. In the file ftpusers you can list all accounts and groups that are not allowed ftp access. I put @wheel there. So no account that is able to SU is able to login with ftp.
Also it is easy to set up ftp with chroot so that ftp users can be limited to specific directories. I want my staff and designers to have ftp access to the web documents only. Maybe even only a subdirectory of the web document even. With sftp I'm allowing people ssh access by default. Also they have access to the whole file system.
I think ftp-ssl is clearly more elegant and less complex however I am stuck supporting dreamweaver both in the office and for our vendors.
-------------
After some agonizing I'm sketching in the following plan. I'll go with sftp after all. But I won't use the chroot and I wont deny shell access. chroot() and no shell access introduces more complexity into the system than I'm willing to deal with at the moment. It's better to trust my staff and our design vendor than to risk openning a new security hole by screwing up chroot or jails.
However - to make things simple. The sftp users accounts will all have the web document root as their home directory. At least that make their job simpler as by default they will start in the correct directory when they log in either through sftp or shh.
------------
Okay that's not so simple. Must give these users r/w access to htdocs and below. Also if one user creates a file in the web root will it default to 644 or 755? What they will need is 664 or 775. Hmm.
...
right, umask does this. umask can be set for each user in their profile or for login classes (sic) in /etc/profile or /etc/login.conf - thats the job for tomorrow.
I wonder what everyone else does?
I also wonder what will happen when I start using scripts in web pages. Argh.
I would think - if the users all create files that are group rwx 'able and the http server (www) will be a member of the same group...? But does any one ever do this?
posted by J.J. Juggins the Third at 12:38 pm
5 comments
