Secure Shell SSH

What Secure Shell does

Secure Shell, often called SSH, acts as the front door to your rented VPS (virtual private server). It creates a scrambled text line between your computer and a machine that might be on another continent. You use this line to type commands and move files, just like you were sitting right at the server. Everything sent over the internet gets scrambled up, including your password. So, if someone is watching the network in a hotel, airport, or shared office, they only see random noise instead of your login details. You can read our page on encryption to see how this scrambling works in simple words.

Try not to think of SSH as just a tool for developers. A virtual server usually lacks a screen, mouse, and desktop. Secure Shell is the real way you, your agency, or your freelancer connects to the machine. Anyone who gets through that door can read your customer list, change your website, and install whatever they want. This is why the few settings that protect it matter so much, more than most things you read about servers.

How you use it in practice

You need three things to connect: the server address, a user name, and a way to prove it is you. You should use a key instead of a password for this. The terminal on macOS and Linux already has an SSH tool built in, and newer Windows computers do as well. Because of this, your first login can be as simple as typing ssh deploy@your-server-address. If you prefer clicking to typing, apps like PuTTY or Termius give you a simpler window to work in. Many code editors also have built-in remote tools that do the same thing.

Once you are in, most daily tasks happen over this connection, whether you rent a VPS or a VDS, a similar virtual machine with resources set aside just for you. You can install security updates, restart a web server that stopped working, and check logs to see why a checkout page broke last night. You also grab the newest version of your site from Git, put it live, and download website backups. Many automated tools use Secure Shell in the background, too. So, even a team that hardly ever types commands still relies on it.

Keys, passwords and common mistakes

A password is easy to guess, reuse on another site, or steal with a fake email. An SSH key pair is different. It is made of two matching files: a public key you put on the server, and a private key you keep on your computer. The server only lets you in if you have the private key. The key itself is far too long for a bot to ever guess. That is why we suggest using keys for every login and turning off password logins once your key works. You should also protect your private key with a passphrase, so a lost laptop does not mean a lost server.

Another good habit is to avoid logging in directly as root. This is the main administrator account found on every Linux server, and it can do anything. Automated bots scan the internet all day and night, guessing the user name root on the standard port 22, and they never stop. You should create a normal user account for yourself. Only give it administrator power when a specific command needs it, and turn off direct root access. This brings the idea of least privilege to your server. Moving SSH to a different port will not secure a server by itself, but it does keep a lot of junk out of your logs.

Most real problems happen because of how people handle keys, not because of the technology. Here are the mistakes that cause the most trouble:

• Sharing one private key. If three freelancers share the same key, you cannot track who did what. You also cannot remove one person without locking out the others. You must give each person their own key.
• Forgetting old keys. A developer who left a year ago can still log in if their public key is on the server. Always check your key list when someone leaves your team.
• Sending private keys by email or chat. A private key should never leave its owner's computer. You should only share the public key.
• Keeping a single copy. If your only private key was on a broken laptop, you cannot get in until you ask your provider to restore your access.

When you need it and what to ask

If you run a normal website on shared hosting, you might never need Secure Shell. The control panel manages your files, email hosting, and databases for you, making it the smart choice for most small sites. Some web hosting plans give developers a basic SSH login, but you will never get full administrator rights on a shared machine. On a VPS server, VDS server, or dedicated server, things work the opposite way. Having SSH with root access is the main way you manage those machines. On our VPS servers at Hostrena, this access is included with the server, not sold as an extra.

Before you choose a host, ask three questions. Is SSH included, and do you get full root access or just a limited user? Can you add your own SSH key when the server is built, so it never relies on just a password? Finally, is there an out-of-band console? This is a window in the provider's panel that shows the server screen even if SSH goes down. It acts like a spare house key hidden under the mat. If a firewall rule or bad setting locks you out, the console lets you log back in to fix it. If you ever struggle to find this on a Hostrena server, our support team will happily guide you.