[deanhills]

Step 1:  Navigate to the link below and download PuttyGen for either 32 or 64 bit VPS
https://www.chiark.greenend.org.uk/~sgta...atest.html

Step 2:  Create a Keys Folder in a safe area of your computer and move the puttygen.exe file into the Keys Folder


Step 3:  Open the puttygen.exe file as indicated below and generate a Private.ppk key





Step4:  Save the private.ppk file to the Keys Folder as indicated below.


Step 5:  Copy the contents of the Public Key below to the clipboard/notepad



Step 6: Access your VPS with SSH to add the PuttyGen Key with the following commands
mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
paste the contents of the public key that you copied before to notepad to the 'authorized' keys file
ctrl x to exit and accept and ctrl y

Check that you have made the change to the authorized keys successfully and it now contains your private key. Then exit the VPS.

Step 8: Open up your Putty Again and load your VPS as with the diagram below.



Step 9: Click on the SSH link in the left column below and then select 'auth'.  Use the "browse" tool to
select the private.ppk file in your Keys Folder.



Step 10: Open the VPS

Step 11:  Once you've checked that the keys are working you can now disallow password authentication:

Code: (Select All)

nano /etc/ssh/sshd_config

Search with ctrl + w  passwordauthentication yes
Change it to 'no'
Then exit with ctrl+x and y

Check that the change has been made successfully with nano

Now check whether you can access root with a password.  You should not be able to do so.

[Mashiro]

Navigate to the link below and download PuttyGen for either 32 or 64 bit VPS

Whether you need the 32 Bit or 64 Bit version of PuTTYGen actually depends on the Windows version that the machine where you will run PuTTYGen to generate the keys is running on. For a 32 Bit Windows version you will of course need the 32 Bit version of PuTTYGen while a 64 Bit Windows version will happily take 32/64 Bit PuTTYGen. The architecture of the VPS doesn't really matter at all in this case.

A small thing I thought that should be edited or corrected because it sounds rather weird in this context.


I see that in the first pictures SSH2-RSA with a key length of 1024 bits is used. Which seems to be a default of PuTTYGen. So nothing to blame on you here.

SSH2-RSA is also fine while SSH1-RSA should be avoided at all cost due to massive security flaws in the outdated SSH1 protocol (I wonder why it is even STILL included in SSH clients and tools after so many years). Nowadays I would strictly recommend to use atleast 2048 bits key length or go even higher to values such as 4096 bits, 8192 bits and etc. Oh, SSH2-DSA is also fine.

It might take a bit more time to generate the keys but the security level of 2048, 4096 bits and etc is much higher vs 1024 bits. Don't go too high though or it will take a hit on performance.


After the keys have been generated I would also recommend to apply an extra layer of security to them by adding a passphrase to them. You can easily do this when saving the private.ppk file. PuTTYGen will ask if you wish to apply a passphrase to secure the key pair.


A small note regarding adding SSH keys to the necessary files on Linux. Always use this SSH format like in PuTTYGen and be careful with formatting. If whatsoever the format is wrong or the formatting of the key is broken with something simple as a breakline... well, you will lock yourself out of your own server because SSH cannot recognize the public key and match it to the provided private key. BE CAREFUL!

That's just some important trivia everyone should keep in mind. In the past it happened so often to me that I pasted the key from PuTTYGen into a notepad that didn't honor the formatting... Then I copied it from that notepad tool into authorized_keys and it simply never worked. Locked myself out a few times this way. Since that I usually directly copy the key from PuTTYGen and paste it directly into authorized_keys in nano or vi.


One last thing. At the end you set "passwordauthentication yes" to "passwordauthentication no" which is absolutely correct. However there are a few other things that should be atleast reviewed when editing sshd_config for SSH key authorized login.

• Uncomment (if commented) "PermitRootLogin yes" and set it to "PermitRootLogin without-password" to allow root to login with SSH key authorization. In this case be sure you added your public key to the authorized_keys on the root user profile, too!
  
• Uncomment (if commented) "RSAAuthentication yes" to allow RSA keys. If it is set to no set it to yes.
  
• Uncomment (if commented) "PubkeyAuthentication yes" to actually enabled the public key authentication feature. Set it to yes if it is set to no.
  
• Uncomment (if commented) "AuthorizedKeysFile .ssh/authorized_keys" to set the default path for the authorized_keys file to the .ssh folder inside the user home folder.
  

I think that's it. Pretty sure someone else with more knowledge on security could add more points to improve SSH security but you're very good to go once you disabled password login and successfully setup SSH public key authentication with a strong and passphrase protected key pair.

[SeductiveWalrus]

This is very helpful for security and an action I strongly recommend taking if you need extra security. This makes bruteforce attacks essentially impossible and, in my opinion, is more convenient for the authentication process. I've always hated memorizing passwords.

[youssefbasha]

Secured but what will happen if i lost this file?
I will need to reset the vps?

[SeductiveWalrus]

Secured but what will happen if i lost this file?
I will need to reset the vps?

I honestly do not know, but you can probably do research on preventative measures. If its the file itself you're worried about, back it up in multiple locations so it can't be lost. Besides, I can't even think of a way to lose the file without accidentally deleting it. Corruption shouldn't really be too much of a worry. And with accidents and corruption out of the way, the only other way you can really lose any file is system compromisation.

[deanhills]

[align=justify]I see that in the first pictures SSH2-RSA with a key length of 1024 bits is used. Which seems to be a default of PuTTYGen. So nothing to blame on you here.

SSH2-RSA is also fine while SSH1-RSA should be avoided at all cost due to massive security flaws in the outdated SSH1 protocol (I wonder why it is even STILL included in SSH clients and tools after so many years). Nowadays I would strictly recommend to use atleast 2048 bits key length or go even higher to values such as 4096 bits, 8192 bits and etc. Oh, SSH2-DSA is also fine.

Thanks for the valuable feedback @"Hidden Refuge".  I've never really looked properly at the above - just went for the default settings always - if I may ask, can I put in 8192 bits in that empty box at the bottom when I generate a key?  With RSA?  It probably will take very long but I don't mind taking more time to generate the key.

A small note regarding adding SSH keys to the necessary files on Linux. Always use this SSH format like in PuTTYGen and be careful with formatting. If whatsoever the format is wrong or the formatting of the key is broken with something simple as a breakline... well, you will lock yourself out of your own server because SSH cannot recognize the public key and match it to the provided private key. BE CAREFUL!

It really worried me yesterday when I disabled password authentication for logging in.  For me I'm usually careful, but if the worst should happen I've made my peace that I'll just have to reload the OS again.  I doubt however that I'll disable password authentication of a VPS that I don't have a user panel for.  Only for one where I have a greater measure of control over the outcome. I've always hesitated to use keys for this very reason - worrying that something should happen for them to get corrupted or something. In this particular case where I felt I got more bad login attempts than I should have for the type of VPS and Websites I have, the end for me more than justified the means.

What I found interesting too is that there is a tiny portion of the public key right at the beginning of the key - ssh-rsa - that one copies and pastes to one's VPS that isn't really part of the actual key.  More like a heading?  I had to think whether to include it for a few seconds until I understood that I had to include absolutely everything that was in the Public Key field for pasting to the VPS.

One last thing. At the end you set "passwordauthentication yes" to "passwordauthentication no" which is absolutely correct. However there are a few other things that should be atleast reviewed when editing sshd_config for SSH key authorized login.

• Uncomment (if commented) "PermitRootLogin yes" and set it to "PermitRootLogin without-password" to allow root to login with SSH key authorization. In this case be sure you added your public key to the authorized_keys on the root user profile, too!
  
• Uncomment (if commented) "RSAAuthentication yes" to allow RSA keys. If it is set to no set it to yes.
  
• Uncomment (if commented) "PubkeyAuthentication yes" to actually enabled the public key authentication feature. Set it to yes if it is set to no.
  
• Uncomment (if commented) "AuthorizedKeysFile     .ssh/authorized_keys" to set the default path for the authorized_keys file to the .ssh folder inside the user home folder.
  

Thanks very much for this tip - all of your feedback has been very educational and detailed.  Most helpful as per always!  

[Mashiro]

@deanhills

can I put in 8192 bits in that empty box at the bottom when I generate a key?

Of course you can. It will take longer to generate the key pair and due to the high encryption level operations over SSH can take a bit longer in certain situations (really depends on network speed, hardware on both sides, load and other factors). I used to have a VPS with a poor old Intel Core 2 Duo CPU and there a 8192 bit key had impact even on the initial connection and key exchange time due to the CPU of the server needing more time for decryption/encryption of information/traffic. Modern hardware should be no porblem for this though.

What I found interesting too is that there is a tiny portion of the public key right at the beginning of the key - ssh-rsa - that one copies and pastes to one's VPS that isn't really part of the actual key.  More like a heading?  I had to think whether to include it for a few seconds until I understood that I had to include absolutely everything that was in the Public Key field for pasting to the VPS.

That's my point. You need the whole key. You may NOT omit anything of it or there might be the issue that you cannot login due to the key not being recognized.

My tip: Before disconnecting the old session that was initiated with password login make sure the key is recognized and login with the key is working. So you will always have a working session open to fix issues. Of course with OpenVZ you can also use the emergency console to fix the issues. On KVM you probably have a noVNC console for emergency access that connects directly to the server like it would be a local server.

[Rehan]

Thanks brother. I like all your tutorials.I was totally new to the linux.I am learning too much from the Post4VPS.
Thanks Again.
Alot of thanks to Post4VPS Community.