GCP Korea Account Google Cloud CentOS VM Initial Server Setup

Introduction

You just spun up a CentOS VM on Google Cloud, probably feeling like a cloud wizard. But let's be real: your shiny new server is sitting there with a big "OPEN FOR BUSINESS" sign painted on it. Hackers are already scanning for default ports, script kiddies are testing your SSH login, and your server is basically a digital door without a lock. Don't panic—we'll fix this faster than you can say "I forgot to update sudo!" In this guide, we'll walk through the initial server setup with humor, no jargon, and just enough sarcasm to keep it real. By the end, your CentOS VM will be more secure than a vault guarded by a dragon named Firewalld. Let's go!

Step 1: Connecting to Your CentOS VM

First things first: how do you even get in? The easiest way is using Google Cloud's built-in terminal. Just click the "SSH" button in the VM instance details page. It's like walking through the front door—convenient, but let's not stay there forever. For real work, you'll want to use your local terminal. But wait—where's your SSH key? Google Cloud automatically generates keys for you, but you need to make sure they're in the right place. If you're using a Mac or Linux, open Terminal and type ssh username@your-vm-ip. Windows users? Use PuTTY or the new Windows Terminal with OpenSSH. Pro tip: if you're using Google Cloud's SSH keys, they're usually in ~/.ssh/google_compute_engine. If you're getting "Permission denied" errors, run chmod 600 ~/.ssh/google_compute_engine. This step is the digital equivalent of finding your keys before leaving the house. Without it, you're just staring at your server, wondering why it won't let you in.

Using Google Cloud's Built-in Terminal

This method is great for a quick glance at your server. Just click "SSH" and voilà—you're in. But don't get comfortable here. This browser-based SSH is handy for emergencies, but for serious work, your local machine is better. Imagine trying to type a complex command on a tiny browser window—ouch. Also, if your internet cuts out, you lose the connection. So treat this as a temporary lifeline, not your main entrance.

Using SSH from Your Local Machine

Here's where the real magic happens. Open your terminal (or PuTTY) and use the command ssh username@public-ip-address. If you're using Google Cloud's key, you might need to specify it with -i ~/.ssh/google_compute_engine. If you see "Could not resolve hostname," double-check your IP address. If it's "Permission denied," you might need to add the key to your SSH agent with ssh-add ~/.ssh/google_compute_engine. Remember: this is your first checkpoint. If you can't connect here, nothing else matters. So take your time, get this right, and maybe celebrate with a coffee. You've earned it.

Step 2: Updating the System

Before you do anything else, update your system. This is like giving your server a vaccine—it might seem boring, but skipping it is asking for trouble. CentOS uses yum (for older versions) or dnf (for newer ones). Run sudo yum update -y or sudo dnf update -y. Don't worry, it won't bite. Just watch the packages scroll by like a train of updates. If you see "Nothing to do," congrats—your server is already up to date. If not, let it run. This step ensures you're not patching vulnerabilities while your server is still using old, broken code. Think of it as putting on your seatbelt before driving. It's not exciting, but you'll thank yourself later when you're not stuck in a crash.

Step 3: Creating a New Sudo User

Stop! Don't work as root. Seriously. Using root is like driving your car without a seatbelt—possible, but incredibly risky. Let's create a new user. Run sudo adduser yourusername, then sudo passwd yourusername to set a password. Pick something strong, like "correcthorsebatterystaple" (but not that exact one—hackers know that trick). Next, add the user to the sudo group: sudo usermod -aG wheel yourusername. The wheel group is your server's VIP pass for admin tasks. Now test it: su - yourusername, then sudo ls /root. If it works, great! If not, go back—this is critical. And please, for the love of all things digital, don't name your user "admin" or "root." That's like painting a target on your server. Even script kiddies know to try those first.

Why You Need a Separate User (and Why 'admin' is a Terrible Name)

Working as root is a bad habit. Imagine if you had a master key that opened every door in your house—would you carry it around all day? Probably not. But that's what root does. If you accidentally run rm -rf / as root, your server is toast. But with a regular user, you can limit damage. Also, naming your user "admin" is like writing "I'm easy to hack" on your forehead. Hackers have lists of common usernames. Use something creative, like "penguin" or "banana." Just don't make it obvious. If you can't think of anything, just pick your favorite color or animal. Anything but "admin." Seriously. Stop it.

Step 4: Locking Down SSH

SSH is the main door to your server. Let's make it lockable. First, edit the SSH config file: sudo vi /etc/ssh/sshd_config. We'll change a few settings. Let's start with the port. The default is 22, but most hackers scan that port first. Change it to something like 2222. Find the line #Port 22, uncomment it (remove the #), and change to Port 2222. Save and exit. Next, find #PermitRootLogin yes and change it to PermitRootLogin no. This stops brute-force attacks targeting the root account. Then, find PasswordAuthentication yes and change it to PasswordAuthentication no. Wait—hold on. Before you do this, make sure you've tested your key-based login. Because if you disable password auth and can't log in with keys, you're locked out forever. Always test first! Once you're confident, save the file and restart SSH with sudo systemctl restart sshd. Remember: changing the port without updating your firewall will lock you out. So let's fix that next.

Changing the Default Port

GCP Korea Account Switching SSH from port 22 to something random (like 2222) isn't a magic shield, but it stops the automated bots. These bots scan port 22 relentlessly. By changing the port, you're hiding your server from the easiest attacks. Now, go to Google Cloud Console > VPC Network > Firewall Rules. Click "Create Firewall Rule." Set name to something like "ssh-custom," source IP ranges to your IP or "0.0.0.0/0" (if you need public access), and allow TCP port 2222. For the target, maybe apply it to your instance. Now check your CentOS firewall too.

Disabling Root Login

Root is like the nuclear launch code for your server. Only a fool would leave it easily accessible. Setting PermitRootLogin no ensures hackers can't brute-force root. They'll still try, but now they're stuck at a dead end. If you ever need root access, use sudo from your regular user. This adds a layer of security. Remember: "sudo" is not a curse word—it's a safety harness. Use it wisely.

Enforcing Key-Based Authentication

Passwords can be guessed. Keys are harder. So disable password auth and force key-based login. In sshd_config, set PasswordAuthentication no. Then, ensure your public key is in ~/.ssh/authorized_keys for your user. Test this before restarting SSH. If you get locked out, don't panic—Google Cloud lets you access via serial console to fix the config. But let's hope you don't have to use that.

Step 5: Setting Up Firewalls

Firewalls are your server's bouncers. They decide who gets in and who gets thrown out. Let's set up two layers: Google Cloud's firewall and CentOS's firewalld.

Google Cloud Console Firewall Rules

Earlier, we added a rule for port 2222. But let's make sure no other ports are open. In Google Cloud Console, check your firewall rules. The default might allow SSH on port 22, so delete that rule or modify it. Only allow the ports you need—like your custom SSH port, HTTP (80), HTTPS (443), etc. For example, if you're running a web server, allow ports 80 and 443. Otherwise, keep it tight. Remember: the fewer open ports, the fewer attack vectors. Don't open everything just because you can. That's like leaving every window in your house wide open.

Configuring Firewalld on CentOS

Inside your VM, firewalld is running by default. Let's configure it. First, add the custom SSH port: sudo firewall-cmd --permanent --add-port=2222/tcp. If you're running a web server, add 80/tcp and 443/tcp too. Then, reload: sudo firewall-cmd --reload. Check your rules with sudo firewall-cmd --list-all. You should see your ports listed. If you accidentally block yourself, you can use the serial console to fix it. But better to test first—open a new terminal and try connecting to the new port before closing the old session.

Step 6: Adding Fail2Ban for Extra Protection

Fail2Ban is like a bouncer who keeps an eye on the door and kicks out troublemakers. Install it with sudo yum install epel-release (if needed) and sudo yum install fail2ban. Then copy the default config: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. Edit jail.local and set findtime = 600 and bantime = 86400. This means after 10 failed attempts in 10 minutes, the IP gets banned for a day. Start and enable it: sudo systemctl start fail2ban and sudo systemctl enable fail2ban. Now, watch your logs with sudo fail2ban-client status sshd. It'll show you who's been blocked. Fun fact: the average server gets thousands of SSH attack attempts daily. Fail2Ban saves you from drowning in logs.

Step 7: Testing Your New Setup

Before you call it a day, test everything. Open a new terminal window. Try connecting to your server on the new SSH port with your regular user. If it works, great! Now try logging in as root—should fail. Try using a wrong password a few times—see if Fail2Ban blocks you. Then fix your firewall rules to allow your IP. If anything breaks, use Google Cloud's serial console to fix the config. It's like a backup key under the doormat (but don't actually do that—use serial console). Once everything checks out, pat yourself on the back. You've just made your server 10x more secure than when you started.

Conclusion: Your Server is Now a Fortress

Congratulations! You've transformed your CentOS VM from a sitting duck into a fortress. You've updated the system, created a secure user, locked down SSH, set up firewalls, and added Fail2Ban. Remember, security isn't a one-time task—it's a habit. Check for updates regularly, review your firewall rules, and maybe treat your server to a virtual pat on the back. Now go enjoy your secure server—you've earned it. And if you ever feel tempted to skip these steps again, just remember: hackers are always watching. Don't give them the satisfaction.