HostEntrepreneur

The more you can make your customers self sufficient the less time you need to answer the same questions over and over. That leads to more time available for other things such as building services, finding new customers, etc.  That’s why we all start working on Knowledgebase (KB) building pretty quickly. But some people aren’t good at visualizing. That is they don’t take written instructions and mentally translate that into what they will see and do. Others do… For the ones that do,  knowledgebase articles work great. I’m one of those people. I’d rather a short KB instruction and then I can go do it… Others need to be shown. That’s where DemoWolf hosting video tutorials comes in.

DemoWolf has over 3600 ready made tutorials for practically any hosting related subject you’d want. Not only are there the normal cPanel, WHM, DirectAdmin, etc. but other subjects such as PuTTY, Paypal, and transfering domain names. They have tutorials that are textual with pictures (think pop up video  but instructional not comical) as well as with voice-over.

I highly recommend DemoWolf tutorials… We’ve just recently started to use them ourselves and are getting positive feedback already. Check out their site at http://www.DemoWolf.com   and check out the bundles and save 50% or more. If you have questions, I’m sure you will find them most helpful as well.

If you didn’t read yesterday’s post on changing SSHD’s port number, I suggest you start there and then come back to this. Here’s the link: http://hostentrepreneur.com/2009/08/18/changing-your-ssh-port/

I find this provides dual benefits… One, passwords are too easy to crack sometimes (or too easy to forget if you actually are one who makes them difficult to crack). And two, it actually makes ssh’ing into the server easier. What we’re going to do is generate key pairs for the server and your client, and then use that to authenticate to the server.

1. First get a SSH session going. And like yesterday, don’t close it until I tell you.
2. Generate the user’s keypair on the server with “keygen -t rsa”.  This will go into .ssh directory off the user’s home directory – you’ll need these to ssh to other boxes and it creates the .ssh directory for you.
3. cd ~/.ssh
4. Next create a keypair on the client. For putty this is done with PuTTYgen. If you use something else you’ll need to lookup how for that client.  This will create a couple of files for you… id_rsa.pub is the public key file and id_rsa.ppk is the private key.
5. Transfer the public key to the server in user’s home/.ssh directory with a NEW NAME. Don’t overwrite anything!
6. If a authorized_keys2 already exists you will need to cat the file onto the end with ‘cat (filename) >> authorized_keys2′   NOTE the double greater than. That means append it to the end.  If you mess this up other keys will be lost.
7. I also recommend that if you are going to have multiple keys for the user, you edit the comment at the end of the line you just added to authorized_keys2. The comment is the portion at the end after the second space. The line’s format is (ke type)(space)(key)(space)(comment) So you’ll see something like “ssh-rsa (lots of letters and numbers) rsa-key-YYYYMMDD  where YYYYMMDD is the year month and day you made the key. It’s that last bit (and only that last bit) you can safely change.
8. Make sure the authorized_keys2 file is readable only by you (chmod 600 or 700).
9. If this is going to be for the root user do steps 9 -
10. cd /etc/ssh
11. cp sshd_config sshd_config.save
12. vi (or vim, pico,etc) sshd_config
13. find the PermitRootLogin  line and change it to read ‘PermitRootLogin without-password’
14. Save/close  the file
15. Restart sshd with ‘service sshd restart’ or ‘/etc/init.d/sshd restart’  — Remember don’t close your session until we know everything works correctly!!
16. Start another PuTTY, and load (not start) the session
17. On the left-hand side, select the Data Category under Connection
18. Specify the user’s name in the Auto-login username field
19. Again under Connection, expand out the SSH branch and select Auth
20. Click the browse button for the Private key for authentication field and find and select the id_rsa.ppk file you created in step 4.
21. This one has caught me a couple of times… Go back up to the Sessions branch all the way at the top left side, and click Save for the session on the right. Otherwise, you’re going to do the PuTTY side config again.
22. Test the passwordless login… Be absolutely sure it works, before dropping that first session. If it doesn’t you NEED to restore the sshd_config.save file back to sshd_config AND restart SSHD again, undo the PuTTY changes and test that you have put it back to where you can get in again BEFORE you drop that connection.

Provided everything worked, you now have an automated login that’s using a nice long keypair and not some little password… and provided you did yesterday’s changing of SSHD port numbers, you’ve probably locked out 99+% of anyone’s chance of getting into you machine through brute force methods, so take a break and enjoy the enhanced security (well until you learn about all the other methods of getting into the machine anyway…) Seriously though, most hack attempts prey on the people that don’t take the precautions, so you’ve just dropped your chances quite a bit just through these 2 little procedures.  You’re not safe and secure, but you are a lot better off than you were 2 days ago.

http://www.whatsmydns.net is a cool little website that let’s you check dns across more than a dozen dns servers all over… many are in the US, but the UK and Australia are also in there. This is a great tool that lets you check if your dns changes have propagated yet.

Hosting companies today are almost expected to have live chat available.  So the question comes up quite often… which one? There are many paid chat systems out there and a few open source as well. Today we’re glancing at LiveZilla one of the latter…

LiveZilla setup was a little different than I expected. I’m accustomed to setup the server and then the client. Or more often the server is the client as they often use webpages as the client interface. But LiveZilla comes as a Windows app. I had a little trouble installing it on Windows 7. But selecting properties and telling it to use Vista SP2 compatibility mode, and run as administrator allowed it to install. To be able to save settings, you do need to run as admin I was later told by the program.  Since I don’t use FTP (I SFTP over SSH), I had it create the server files locally and sent them with WinSCP. Then comes the usual fun … I had to log into the control panel and create a database and user. Once I did you let the server admin client create the files and validate the server. I also decided I wanted to use my existing images, so I went into the images options and told it what to use. And lastly I replaced an include file with the old crafty syntax code with a new LiveZilla version… and poof it was running.

I’ve been testing it out, and hopefully will have an update to this article shortly. Thus far it does the job, albiet not too quickly. In completely unscientific testing, there’s a signifigant delay from the time either the operator or the use types in a line, and when it is shown on the other’s screen. Changing the settings to 1 second each (3 for operator, 10 for visitor) has not had much of an impact. I’ve watched the client side refresh repeatedly when a reply has been posted, and there’s no update for many cycles. I’m going to load it on another server just to see if there’s something going on with that particular server.

One note:  A nice feature of LiveZilla is the GeoIP mapping of where the visitor is located. But to use this you need to go into your server config, and enable it per server. It’s off by default.  Once you do that it works, and is pretty “neat” if nothing else.

You can download LiveZilla and try it out yourself at http://www.livezilla.net/home/  — it’s free, so what have you got to lose?