This is mainly a shared hosting blog, but it grow to the VPS land too and as a guy who started with a shared hosting package and than decided to go to a VPS there are some things he needs to learn. I can’t even tell you how many changes there are . There are so mane, that it might be enough on a whole series of articles and it would not be enough.
Shared web hosting is pretty simple. Your web hosting company sets everything up and you do not have to worry about anything. If something goes wrong you email your support center and wait ’till they take a look into the problem and solve it for you. You are provided with a nice control panel from which you can change pretty anything related to your hosting package, your web site etc. Setting up a mail account or adding a new website is just a few mouse clicks away… . You think to yourself that it’s pretty easy and thus after a while you decide, that you would like to move on to a bigger challenge and you want more security and elasticity. You go to VPS and your nightmare starts pretty quickly – if your knowledge of web servers, server operating systems and security is not on the required level.
You need to understand, that there are two options you could go:
And they both differ in the depth of support you will get from your hosting provider. If you are not that good at servers and you do not have the nerves to make mistakes and learn something extra, or you need your web site online as fast as possible and do not want to be responsible for it’s uptime, than the MANAGED VPS solution is just for you! But if you want to be responsible and you think you are able to manage it than go with Unmanaged
I think, that many of you know there are two options how you could talk to your VPS or any other server. One of them is the secure way and the other is the insecure way and I can tell you NEVER use the insecure method! The insecure method is called TELNET and you should definitely disable it. There are some options how to perform it – block it’s port in iptables [firewall], remove it entirely or just shut the service down.
The more secure way is to use the SSH and configure it so, that it does not match the default configuration of ssh. That is good, because people know the defaults, but it’s harder to guess the changed settings and you make the life for an intruder harder
I will try to update this post with some example configurations i the coming days Until than – have a nice day and good luck!