Lxcite’s Planet

…the ultimate solution

Setting up a SFTP Server on Windows

I recently had to create an SFTP server on our work development system, and after doing a fair bit of Googling on the topic found a good solution. The solution is a combination of research done at differnt sites. It is this solution that I am sharing in hopes that it will help someone else.

This tutorial will help you turn your Windows based system into a SecureFTP server.

Background

Secure Shell (SSH) is a program that lets you log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. When using ssh, the entire login session, including transmission of password, is encrypted and therefore is very secure.

You may have noticed that many webhosts allow ssh access. This means that you can login to their webserver and execute many UNIX commands (the ones they allow you access to) on your account. Not only can you connect to other computers that provide SSH access, but you can also allow others to connect to your computer using SSH.

To take this one step further, you can also turn your Windows PC into a Secure FTP (SFTP) server. SFTP is a program that uses SSH to transfer files. Unlike standard FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted in clear text over the Internet. It is similar to FTP, but because it uses a different protocol, you must use a FTP client that supports SFTP (more about that later).

Installing SSH on Windows

Most UNIX based systems (Linux and OSX) come with SSH preinstalled, so connecting to a remote host is very easy. However, if you run a Windows system, you need to download some additional software to make the SSH programs available to you. Fortunately a free open-source project called SSHWindows, provides a nice Windows installer that will setup the SSH client and Server on your system.

Your first step will be to download the Binary Installer Release from SSHWindows. Once downloaded, run the installer and be sure to install both the client and server components.

Configure the SSH Server

In this next step, I have summarized the information that is included with the readme.txt that is included with SSHWindows (it can be found in c:\program files\openssh\docs)

Your first configuration step is to set up the passwd file. You will need to set up the passwd file before any logins can take place.

Passwd creation is relatively easy and can be done using two programs that are included with SSHWindows – mkgroup and mkpasswd. Both of these programs are located in the c:\program files\openssh\bin directory.

To begin creating the group and passwd files, open a command prompt window and navigate to the c:\program files\openssh directory.

You must first create a group file. To add all local groups on your computer to the group file, type the command as shown below:

mkgroup -l >> ..\etc\group

You will now need to create a passwd file. Any users in the passwd file will be able to log on with SSH. For this reason, it is recommended that you add users individually with the -u switch. To add a user to the passwd file type the command shown below:

mkpasswd -l -u username >> ..\etc\passwd

NOTE: the username specified above must be an existing windows login account.

Creating Home Directories for you Users

In the passwd file, you will notice that the user’s home directory is set as /home/username, with username being the name of the account. In the default install, the /home directory is set to the default profile directory for all users. This is usually c:\documents and settings.

If you want to change this location you will need to edit the passwd file. The passwd file is in plain text and can be edited in Notepad or any text editor. The last two entries for each user are safe to edit by hand. The second to last entry (/home/username) can be replaced with any other directory to act as that user’s home directory. It’s worth noting that when you run SSH on windows, you are actually running SSH in a scaled down version of cygwin, which is a Unix emulator for Windows. So, if you will be placing the user somewhere outside the default directory for their Windows profile, you will need to use the cygdrive notation.

To access any folder on any drive letter, add /cygdrive/DRIVELETTER/ at the beginning of the folder path. As an example, to access the winnt\system32 directory on the *c:* drive you would use the path:

*/cygdrive/c/winnt/system32*

Connecting to your SFTP Server

To connect to your new SFTP server, you will need to download an FTP client that supports SFTP. I use Filezilla which is a nice free FTP and SFTP client. You might also try WinSCP which is another free SFTP client.

To test if your server is running, create a new connection in your client and specify SFTP as the server type, 22 as the port, and localhost or 127.0.0.1 as the server name. You will also need to provide the user account and password for any account that you added to your passwd file. Now connect to the server. If all went well, you should see a directory listing where you pointed the home folder to. If not, there are a couple of things to check. Make sure your Windows firewall is set to allow traffic over port 22 and finally double check your passwd file to make sure that the account you added is actually there.

Security

Because SSH allows access to only Windows user accounts, you can restrict access based upon NTFS file permissions. As such, SFTP does not provide for chroot jails (a Unix method for locking a user to his/her home directory). Simply lock down your filesystem for that user, and SFTP will respect that.

Summary

In the end, setting up an SFTP server turned out to be a very effortless task. With a couple of open source programs and a couple of command-line commands, you can up and running in no time at all!

July 10, 2008 Posted by lxcite | Windows | | No Comments Yet

Windows Is Still More Reliable Than Linux On The Server

Windows Server and Linux are growing up fast, but they still aren’t a match for the solid, stable Unix systems on the high-end of the server scale.

That’s the conclusion of a report from The Yankee Group, which released it 2006 Global Server Reliability Survey on Wednesday. The report compared a number of server operating systems in areas of reliability, down time and recovery.

It found that Windows Server 2003 showed the highest reliability gains, surpassed only by mature Unix-based server operating systems like HP-UX from Hewlett-Packardand Sun Solaris 10 from Sun Microsystems.

Windows Server 2003 had nearly 20 percent more annual uptime in similar deployment scenarios over Red Hat Enterprise Linux.

The Yankee Group found that corporate Linux, Windows and Unix servers experience on average three to five failures per server per year, resulting in 10.0 to 19.5 hours of annual downtime for each server. The down time for Linux systems was longer not due to a software failure, but because Linux often isn’t as well-known or that well documented.

“One of the reasons for extended down time often had nothing to do with performance and reliability of the OS,” said Laura DiDio, research fellow for application infrastructure and software platforms at The Yankee Group.

“The one random element I can’t emphasize enough is I think some of the disparity we see between Red Hat Linux down time and Windows and Unix comes not so much from any inherent flaws in the Linux core kernel, but the unfamiliarity of some of the network administrators with Linux.”

When a Linux system fails, it can sometime send a Linux administrator, who likely has less years of experience than a Sun or IBM Unix veteran, scouring the Internet for documentation or a fix.

Overall, DiDio said, all of the server operating system environments have shown markedly improved reliability in recent years, both in hardware and software. The improvements in hardware from Dell, HP and other vendors has given the operating systems a better base on which to run.

This in turn helps the software, which has also improved. With each new release of the Windows server since Windows 2000 was released in 1999, Microsoft has showed a 20 to 30 percent improvement in reliability, said DiDio.

The poorest performing operating system was Debian GNU/Linux, while SUSE Linux from Novell had the best performance, even topping some of the big Unixes. But it’s used so little as to be statistically irrelevant, said DiDio.

Another reason Linux may prove shakier is that many shops, more than 50 percent in this survey, were making some level of customization to their Linux environment. Making changes to the kernel and underlying system increases the chances for breakage somewhere in the system.

But don’t unplug the mainframe just yet. In terms of power, performance and reliability, DiDio said the only thing that could come close to mainframe performance is the high-end Unix systems from Hewlett-Packard, Sun and IBM. “And even that is debatable.”

June 27, 2008 Posted by lxcite | Linux, Servers, Windows | | No Comments Yet