del.icio.us Tags:
FreeSSHd,
SSH While not perfect with regards to security, I would like to think that I take extra-ordinary steps to protect my computers. This can be seen in my use of SSL for logging into my blog and with the Password Maker application I provide on this site. So I was especially annoyed when I contacted several web hosting companies and asked about file transfer methods. For all of the providers I called it appeared that you must use Linux services in order to get SSH file transfers. None of the hosting providers I called would provide anything other than FTP (yuck). Worse than that, they wanted me to use the same username/password for my SQL server, FTP connection, and Web Services. No thanks.
This seems strange to me since there are plenty of SSH services for the Windows Platform (FreeSSHD, WinSSHD, and even OpenSSH for Windows) that a hosting company could install. But alas FTP seems to be the only option... For those of you who don't know, FTP is completely clear and plenty of people have specially configured network capturing tools that specifically look for FTP username and password information.
I can hear some of you saying, why not Remote Desktop? Well RDP is definitely nice and I use it whenever I need full control of the server. But copying files over RDP isn't as easy as simply opening up a SSH connection with WinSCP and modifying the necessary files.
So I ended up hosting my own server and running FreeSSHD. Everything works great and I can perform uploads and console work anytime with confidence. Here are a couple of things worth mentioning about using SSH:
- Configure something other than the default port (22). Yes I know this is security through obscurity, but it keeps simple scripting attacks from identifying your SSH server, and adds another layer to your defense in depth strategy.
- Disable username/password authentication and only accept certificates. You can use PuttyGen to generate certificate keys for authentication. This will make it extremely more difficult (if not impossible) for someone to brute force their way into your server.
- Monitor your logs for repeated intrusion attempts, and block specific IP addresses that you have identified as malicious. I have even gone so far as to disable IP addresses from outside of the US (not planning on using SSH from outside the US anytime soon).
- Protect your authentication keys! If these get out then your server is no longer your server!
If anyone needs help with configuring SSH for their environment then please feel free to drop me a line and I will see what I can do to help!