Passwords are all well and good, though in this modern world it pays to go the extra mile. You should consider moving to key-based authentication to enhance security and enable you to further lock-down access to critical systems. Allowing multiple keys per *nix user, you have flexibility in not just access but auditability beyond that - if you need to react, you can deauthorise a key rather than impacting everyone in need of access to a user account. If you're semi-confident performing technical tasks then you should have no issues getting your own key-pair generated and in-use!
These steps are for a macOS environment - please let us know if you need help around/past that coverage. Thank you!
Quick run-down of SSH key-pairs:
Most important thing about them - you'll end up with a very short "public key" and a very long "private key".
PRIVATE KEYS MUST NEVER BE SHARED - if your private key is ever disclosed, contact us IMMEDIATELY.
On the contrary, your public key is what's placed on hosts (ie. servers) that you wish to easily access.
Creating the key-pairs locally:
On macOS, using Terminal (if you're feeling up to it) from its landing CWD (current working directory) of ~ (ie. home) you'll need to create (if it doesn't exist already) then move into your .ssh directory, generate your key-pair then open Finder.
Everyone needing access must use these commands, but only run the ssh-keygen for yourself:
-
cd ~ && mkdir -p .ssh && cd ~/.ssh -
ssh-keygen -C flast@example.com -f abc_flast -t rsa -
open .
(Note: You'll want to choose a strong password for your keys - you'll need it to ever import/etc your key-pair again)
Make sure you only ever give out your public key - this is CRITICAL. Don't give ANYONE your private keys!
Private keys are the "something you have" element, and verify that you are the holder of the key-pair.
The folder will have 2 files within - abc_flast (private key) and abc_flast.pub (public key)
From there, your public key does NOT need importing to FileZilla, etc. Just make sure your Sites are set to Interactive, and the connection type is changed to SFTP - that'll allow FileZilla to leverage macOS for the authentication side.
As for Secure Shell (SSH) itself, macOS will default to checking and presenting keys to machines, and where it can be negotiated and used, it does so.
That's the local side handled. If you hit problems, please let us know so we can help you!
Using keys to access infrastructure, intro:
Now to enable the "S" part of SFTP on the server side.
Once your keys are ready, use WHM to Manage Shell Access (ie. SSH) and enable it for accounts that need it.
From there, you need to authorise your public key/s to access all accounts that you desire access to.
This is done with a file called authorized_keys in the .ssh directory under each user's home.
Each user on a Linux server has a home directory assigned to them - /home/username/ etc.
The only user which differs from that norm is root which has the directory of /root/ assigned.
Adding keys to cPanel accounts (& servers):
Regardless of the host involved, authorised public keys will be stored in the same relative file:
/home/vpsadmin/.ssh/authorized_keys
/home/abccust8/.ssh/authorized_keys
/root/.ssh/authorized_keys
etc (you can use cPanel File Manager, just enable Show Hidden Files via File Manager's Settings)
So for "abccust8" let's say, you'd need to create the authorized_key file and potentially the .ssh folder.
In the end, you'd have 1x public key per-line in the file located at: /home/abccust8/.ssh/authorized_keys
You most likely won't try to connect to your computer, so this authorisation only applies to servers you'll access.
(LH Clients: If you're going to want access to all sorts of accounts, we can authorise you as-needed - let us know) :-)
Giving out your PUBLIC key on-request:
Sometimes, you'll be asked to provide your public "key file" which is the .pub file, and other times you'll be asked for the public key "contents" - they take the below format (open the .pub in Sublime Text, etc, to see the same format).
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDqz3mFgyUDyVSwzp+kUAKAIoISKoGQcpTO+WQ6mNVoqXRLHLZlJBhjovR3k868tE6YtV/AhB10jplmibxtVzBlXfzOMBORJGiRKUEIz6vXNv8iLEDI2pWsREljw/wAeO4LfMmVQiWFMR25ztkkxIXUAZTinjNDMoVi6ZVmHukSvhDywndOaqvcsxLOFkqv81spOcp0KrnyY1GmC1fCWTEZoMhb3HZ0u+w+GKFfuSuim+TxXCOGZbFYvy8qnRSOjywElB8XIm/pfP+BbfB/iMM6uZgL+9GQALepk/HRM1ASngL0ycF75q35TEUJ0wB0gT2r3NIGzOn5SXVi0agddfNr7EN0zS5IH2zcpL4I8D/hl+AppvLddNyDesDpsruXwG+I3J5QTTy3xAKrGiv1IODYuCSlSZ/nhpJFVd7lq984F9mcKoHFNPVin0wDc+TgBy0OmXHvj+WHTSBHBLLs2lHpjvR+D/e2DAcgOBnmmyGtYFZWPkxiuFhPiWpa6DoWfSU= testkey@example.com
Any account on any server that you want to access using SFTP/SSH/etc will need your key/s to be authorised like we've stepped out above. Where you're gaining 3rd-party temporary access (ie. for inbound migrations), it's always best practice to remove your public key/s when you're done, to reduce the amount that you're able to freely access.
Reminder: You must NEVER give out your private key, not even to the Merlot Digital Helpdesk - keep it secure and private, and only install it on devices you will SSH/etc via.
If you encounter any problems while following this guide, or would like guidance around bulk authorisation of your keys (etc), simply get in touch with our local crew.
We can only provide hands-on assistance where you're a client of Merlot Digital!
