Verified Huawei Cloud Account Huawei Cloud ECS Linux server configuration

Huawei Cloud / 2026-05-15 13:48:40

Introduction: The Moment You Realize It’s “Just a Server”… Until It Isn’t

So you’ve got yourself a Huawei Cloud ECS Linux instance and you want to configure it. Congratulations: you’re now the proud caretaker of a tiny virtual machine that can either be helpful or vindictive depending on your choices. The good news is that most problems come from predictable places: networking assumptions, SSH settings, firewall rules, storage confusion, or the eternal classic—using a default password and then wondering why your server looks like it’s been through a food truck riot.

This article walks you through a clear, practical configuration path for a Huawei Cloud ECS Linux server. We’ll cover planning, provisioning basics, secure access, OS hardening, common software setup patterns, and troubleshooting. Along the way, you’ll get “do this, not that” advice so you can move from “it launched” to “it actually works” without spending your weekend Googling error messages like they’re cursed artifacts.

1) Before You Touch the Buttons: Planning Your ECS Setup

Before you even configure your instance, do a little planning. Think of it as putting on armor before you walk into a dragon’s lair. The dragon here is usually configuration drift or connectivity issues.

Verified Huawei Cloud Account 1.1 Decide What the Server Will Do

Different workloads require different choices. Ask yourself: will this server run a web app, a database, a batch job, a CI runner, or something else?

  • Web server: needs good network throughput, open inbound ports (usually 80/443), and basic hardening.
  • Database: more careful storage sizing, strict network access (often private networks), and performance tuning.
  • Development/test: you still want security basics, but you may be more flexible.
  • Containers: you’ll want to plan for container runtime, networking, and logging.

1.2 Choose the Right Linux Image

Most ECS offerings give you multiple Linux options. Typically you’ll see distributions like Ubuntu, CentOS (or its community descendants), Debian, or others.

Pick based on:

  • Package availability: does your software have easy install instructions for that distro?
  • Support horizon: you don’t want to run on a distro that’s out of date unless you enjoy living dangerously.
  • Operational comfort: if you already know how to administer Ubuntu with your eyes closed, choose Ubuntu.

1.3 Plan Networking and Addressing

Before provisioning, decide how your server will be reachable:

  • Public access: easier for testing; requires careful security group rules and SSH hardening.
  • Private access: safer; often combined with a bastion host or VPN for admin access.

If you’re going to expose services publicly, plan your inbound firewall rules early. A server with no firewall rules is like leaving your front door unlocked and labeling the keys “in case of emergency.”

2) Provisioning the ECS Instance: Getting the Basics Right

When you provision the ECS Linux server, you’ll typically configure region, availability zone, networking, compute size, image, storage, and security settings. The exact labels can vary, but the idea stays the same.

2.1 Compute Size and Disk: The “Don’t Regret It Later” Part

Pick CPU and memory based on your workload. If you’re unsure, start small but not too small. A 1 vCPU instance can run many web apps just fine, but databases, heavy processing, or multiple services might need more headroom.

For storage, you’ll usually see a system disk size option. Don’t under-provision system disk space. Logs, package caches, updates, and container layers can quietly eat space while you’re busy doing important things like learning what “disk full” means.

2.2 System Disk vs Data Disk

Many ECS templates provide a system disk and optionally data disks. The system disk often holds the OS. Data disks are better for:

  • databases
  • persistent application storage
  • container storage (if you know what you’re doing)

If you expect growth, consider using a data disk rather than squeezing everything onto the system disk.

2.3 Authentication: Password vs SSH Key

You’ll usually be offered authentication options like:

  • Password-based login
  • SSH key-based login

SSH keys are strongly preferred for real-world security. Password login tends to attract attention from bots. If you absolutely must use passwords, at least ensure they are strong and you’ve configured rate limiting (though many clouds handle some of that for you).

3) First Login: Connecting to Your New Server

Once the instance is created and “active,” you can connect. This is where people often run into the classic “I can’t SSH” problem.

3.1 Verify You Have the Right Admin Endpoint

Confirm the instance’s IP address (public or private) and ensure you are connecting to the correct one. A wrong IP is a silent failure generator.

3.2 SSH Command Basics

A typical SSH command looks like:

ssh -i your_key_file username@server_ip

If your security expects a specific username (like ubuntu or centos), use the correct one. Using the wrong username often fails with “Permission denied” even when your key is fine.

3.3 If SSH Fails: A Quick Diagnostic Checklist

  • Security group: does inbound allow TCP 22 (or your custom SSH port)?
  • Network ACL: if applicable, is there a rule blocking inbound?
  • OS firewall: is UFW/iptables blocking SSH?
  • SSH config: is sshd running and listening on the right interface/port?
  • User/key mismatch: are you using the correct username and correct private key?

Don’t worry—this is normal. Servers fail in predictable ways; you just have to observe the clues instead of guessing wildly like a raccoon in a closet.

4) System Updates and Baseline Setup

Once you’re logged in, do the boring stuff first. It’s boring like vegetables, but vegetables keep you alive.

4.1 Update Package Index and Upgrade Packages

On Debian/Ubuntu-based systems:

sudo apt update && sudo apt -y upgrade

On RPM-based systems (like CentOS/RHEL-like distributions):

sudo yum -y update

Sometimes you may need dnf depending on the distro version. Always check your distribution’s package manager.

4.2 Install Useful Admin Tools

Consider installing:

  • curl
  • wget
  • vim or another editor
  • git
  • net-tools or iproute2
  • htop (optional but delightful)

Examples:

sudo apt -y install curl wget vim git iproute2 htop

Or:

sudo yum -y install curl wget vim git iproute net-tools htop

4.3 Check Disk Space Immediately

Before installing anything heavy, confirm disk usage:

df -h

If your system disk is tight, adjust early. Fixing it later is possible, but it’s like reorganizing your pantry after it explodes.

5) Create a Proper Admin User (Because “root Everything” Is a Lifestyle Choice)

Many images log you in as a default user. That’s fine, but you should still create an admin account with sudo privileges and avoid running everything as root.

5.1 Add a New User

Replace adminuser with your desired username:

sudo adduser adminuser

Set a password only if you truly need it; prefer SSH keys.

5.2 Add User to Sudo Group

On Debian/Ubuntu-based systems:

sudo usermod -aG sudo adminuser

On RPM-based systems:

sudo usermod -aG wheel adminuser

Then verify:

sudo -l -U adminuser

5.3 Configure SSH for the New User

Create the SSH directory and authorized_keys file:

sudo mkdir -p /home/adminuser/.ssh
sudo nano /home/adminuser/.ssh/authorized_keys

Paste your public key, then set permissions:

sudo chmod 700 /home/adminuser/.ssh
sudo chmod 600 /home/adminuser/.ssh/authorized_keys
sudo chown -R adminuser:adminuser /home/adminuser/.ssh

Permissions matter more than people like to admit. SSH is picky because it’s seen what happens when permissions are sloppy.

6) SSH Hardening: Make It Harder for Random People to Enjoy Your Company

SSH hardening isn’t about paranoia; it’s about making obvious attacks slightly less convenient. You can’t stop all threats, but you can definitely reduce “drive-by” scanning success.

6.1 Disable Password Authentication (If Using SSH Keys)

Open SSH config:

sudo nano /etc/ssh/sshd_config

Find or add:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Then restart SSH service. On many systems:

sudo systemctl restart sshd

Some distros use ssh instead of sshd:

sudo systemctl restart ssh

6.2 (Optional) Change the SSH Port

Changing the port from 22 to something else can reduce noise. It is not security by itself, but it’s a small step.

In /etc/ssh/sshd_config set:

Port 2222

Then update security group rules to allow TCP 2222 from your IP (not the whole internet, unless you enjoy chaos).

6.3 Allow Only Your Admin User(s)

Add:

AllowUsers adminuser

This prevents other users (including accidental ones) from logging in via SSH.

6.4 Restart and Validate

After changes:

  • Confirm SSH daemon is running:
sudo systemctl status sshd

Then try a new SSH session from your workstation before closing your old one. That way, if you mess up config, you still have a fallback. This is called “not locking yourself out,” and it’s a popular feature of competent admins.

7) Firewall Configuration: Stop Unwanted Traffic Before It Becomes a Podcast

Your ECS security group may handle inbound access, but configuring the OS firewall is still useful—especially for restricting outbound, limiting service exposure, and defense-in-depth.

7.1 Check Whether UFW or Firewalld Is in Use

Check:

sudo systemctl status ufw

If it’s not present, maybe you have firewalld:

sudo systemctl status firewalld

7.2 Example: UFW Rules (Ubuntu/Debian)

Basic pattern:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Adjust ports according to your services. Remember: if you allowed SSH on 2222 but you restart and forget to change it, you may end up feeling personally attacked by your own firewall.

7.3 Example: Firewalld Rules (RHEL-like)

Pattern:

sudo firewall-cmd --permanent --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

If you changed SSH port, you’ll need to add a port rule instead of --add-service=ssh.

8) System Time and Reliability: NTP, Logs, and “Why Is This Timestamp Wrong?”

Time drift can cause headaches with logs, authentication, and certificate validation. Configure time sync right away.

8.1 Enable Time Sync (chrony or systemd-timesyncd)

Check status:

timedatectl

If you have chrony:

sudo systemctl status chronyd

If not, you might have timesyncd:

sudo systemctl status systemd-timesyncd

Enable whichever is applicable.

8.2 Enable and Review Logs

Use journalctl to view system logs:

sudo journalctl -xe

Verified Huawei Cloud Account And check common logs:

ls -lah /var/log

You don’t need to become a log detective, but you should know where the bodies are buried (metaphorically—mostly).

9) Storage Layout: Make Disks Behave Like Adults

Sometimes you just accept the default partitioning. Sometimes you need more control. Either way, it’s good to understand what’s happening.

9.1 Check Block Devices

lsblk

Verified Huawei Cloud Account This will show devices and mount points. Look for:

  • the system disk (usually mounted at /)
  • any data disk (unmounted or mounted elsewhere)

9.2 If You Have a Data Disk: Partition and Mount

If the data disk is already formatted and mounted, you can skip this. If it’s raw, you’ll need to create a filesystem and mount it.

Example workflow (be careful—this is where you can accidentally wipe the wrong disk):

  • Identify disk name from lsblk
  • Create partition (optional depending on existing layout)
  • Format filesystem
  • Create mount directory
  • Mount and add to /etc/fstab

Example for a data disk device like /dev/vdb:

sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data
sudo mount /dev/vdb /data
sudo chown -R adminuser:adminuser /data

To make it persistent, add to /etc/fstab using UUID (recommended):

sudo blkid

Then edit /etc/fstab and add a line like:

UUID=your-uuid-here /data ext4 defaults,nofail 0 2

10) Create a Baseline Directory Structure (So You Don’t Scatter Files Like Confetti)

When setting up services, plan a simple directory scheme:

  • /opt for optional software
  • /var/www for web content
  • /etc for configuration files (apps often create their own subfolders)
  • /var/log for logs
  • /data for persistent application data (if you created a data disk)

Using a consistent structure makes maintenance far less miserable when you return to the server weeks later and wonder why your app is buried under five layers of mystery folders.

11) Install and Configure Common Services

Here are a few common server configuration paths. Pick the one that matches what you’re trying to do. If you’re doing something else, the ideas still apply: keep services organized, secure them, and enable sensible defaults.

11.1 Deploy a Web Server (Nginx Example)

Install Nginx:

sudo apt -y install nginx

Start and enable:

sudo systemctl enable --now nginx

Check status:

sudo systemctl status nginx

Adjust firewall rules to allow 80/443 if needed. Then place a site configuration:

sudo nano /etc/nginx/sites-available/example.conf

Then enable it (Ubuntu-style) using symlinks, or use the distribution’s standard layout. Reload Nginx after changes.

11.2 Use a Reverse Proxy for an Application (The Sensible Way)

If you run an app on a different port (like 3000, 5000, or a container port), use Nginx as a reverse proxy. That gives you one consistent HTTP entry point and easier TLS handling.

Typical reverse proxy principles:

  • Set proxy_pass to your app upstream
  • Forward headers like Host and X-Forwarded-For
  • Use timeouts appropriate to your app

11.3 Install Certs (Optional but Usually Necessary)

If you need HTTPS, you can use Let’s Encrypt (commonly via certbot). Ensure ports 80/443 are reachable and domain DNS points to the server.

Typical steps:

  • Install certbot
  • Obtain certificate for your domain
  • Configure Nginx to use it
  • Enable auto-renew

Exact commands vary by distro and Nginx layout, so follow your chosen guide. The key idea is: don’t improvise. TLS is not a place for “let’s just see what happens.”

11.4 Add Monitoring (Because You Can’t Fix What You Can’t See)

Even basic monitoring helps. At minimum, consider:

  • system metrics (CPU, memory, disk, network)
  • service status (web server running, error rates)
  • log collection

Verified Huawei Cloud Account You can use tools like Prometheus node_exporter, Grafana dashboards, or vendor-provided monitoring if available in your environment. The cloud ecosystem often includes built-in monitoring services, which can save time.

12) Containers and ECS-Friendly Setup Patterns

If you want containers, you can configure them on your ECS instance. Common patterns:

  • install Docker or an alternative runtime
  • use docker-compose for multi-service apps
  • Verified Huawei Cloud Account store data on mounted host volumes
  • ensure proper logging and restart policies

12.1 Container Networking: Don’t Surprise Yourself

Container ports may be mapped to host ports. Decide which ports should be reachable from outside. Then align both:

  • the container port mapping
  • the OS firewall rules
  • the cloud security group inbound rules

When all three layers agree, things work. When they don’t, you’ll experience that special kind of frustration reserved for “everything is configured except the one thing you didn’t think about.”

12.2 System Hardening Still Applies

Even with containers, you should keep your base OS hardened. Treat the host as the security boundary. Container isolation is helpful, but it’s not magic.

Verified Huawei Cloud Account 13) Performance Quick Checks: Make Sure the Server Isn’t Running on Vibes

After configuration, do a few checks so you’re not flying blind.

13.1 CPU, Memory, Load

top

Or:

htop

Look for:

  • unexpectedly high CPU usage
  • memory pressure
  • load averages that don’t make sense for your workload

13.2 Network and Listening Ports

Verified Huawei Cloud Account Check listening ports:

sudo ss -lntp

Make sure your expected ports are open and bound to the right interfaces.

13.3 Verify Service Health

For Nginx:

sudo systemctl status nginx

For your app, use whatever health check command your framework supports, or at least verify HTTP responses.

14) Maintenance Habits: Keep the Server From Turning Into a Time Capsule

Verified Huawei Cloud Account Configuration is not a one-time event. It’s more like eating soup: you can stop, but it gets cold and tastes worse than before.

14.1 Regular Updates

Set a plan for system updates. Some people do weekly patch windows. Others do monthly. Just do it. If you’re running production workloads, use a strategy that fits your risk tolerance.

14.2 Log Rotation

Make sure logs don’t fill the disk. Most distros include logrotate defaults. Confirm that logrotate is enabled and working.

14.3 Backups (If You Care About Existence)

Decide what needs backup:

  • configuration files
  • database data
  • Verified Huawei Cloud Account uploaded user content

Many cloud platforms offer snapshot or backup services for disks. For databases, you might also do application-level backups. Choose a strategy that you could explain without sweating.

15) Troubleshooting: Common Problems and Quick Fixes

Here are a few common “new server” issues and what to do.

15.1 “I Can’t SSH In”

Try this order:

  • Confirm IP address.
  • Confirm security group inbound allows your SSH port (22 or your custom port).
  • Confirm OS firewall allows SSH port.
  • Confirm sshd is running: sudo systemctl status sshd.
  • Check sshd config for port/password changes and user restrictions.
  • Verify your public key is in the correct `authorized_keys` file for the correct user.

Also: if you changed SSH port and locked down security group rules, you might have a chicken-and-egg moment. Fix the cloud rule first, or temporarily revert sshd config.

15.2 “My Web Page Doesn’t Load”

  • Confirm Nginx service is running.
  • Confirm Nginx is listening on the correct port.
  • Confirm OS firewall allows inbound 80/443.
  • Confirm cloud security group allows inbound 80/443.
  • Check Nginx error logs and access logs.

15.3 “Disk Is Full and Everything Is on Fire”

  • Check disk usage: df -h
  • Find large files: sudo du -h -d 2 /var/log | sort -hr | head
  • Clean package caches if safe.
  • Rotate logs or move logs to a data disk.
  • Plan future disk size.

15.4 “Time Looks Wrong”

  • Check: timedatectl
  • Ensure NTP/chrony/timesyncd running.
  • Confirm time zone settings.

16) A Practical Configuration Checklist (Print It in Your Mind)

Here’s a compact checklist you can use every time you create a Huawei Cloud ECS Linux instance:

  • Pick a suitable Linux image and confirm your admin username expectations.
  • Choose compute and disk sizes with your workload in mind.
  • Use SSH key authentication instead of passwords.
  • Set security group inbound rules for required ports only.
  • Log in and run system updates.
  • Create a dedicated admin user with sudo privileges.
  • Harden SSH: disable password login, restrict users, consider changing port.
  • Configure OS firewall with default deny for inbound.
  • Verify time sync (NTP) and system logging.
  • Check disk layout and mount data disks if needed.
  • Install your services (web/app/database) and validate ports/services.
  • Set up monitoring and log retention/rotation.
  • Verified Huawei Cloud Account Plan backups and maintenance cadence.

If you complete this checklist, you’ll likely avoid 80% of “why is this broken” scenarios. The remaining 20% is where the universe enjoys a laugh.

17) Security Notes: The “Don’t Accidentally Invite the Entire Internet” Section

Some extra security considerations that are worth mentioning explicitly:

  • Verified Huawei Cloud Account Limit inbound IP ranges: allow SSH only from your IP or VPN, not 0.0.0.0/0 (unless you enjoy surprises).
  • Use strong keys: don’t generate keys like “test123.”
  • Keep your software updated: especially web and server packages.
  • Minimize exposed services: run only what you need.
  • Use least privilege: don’t run everything as root.

Security is not a one-time configuration; it’s a habit. Still, getting the foundation right on day one is a huge win.

Conclusion: You Now Have a Configured ECS Linux Server (Not a Mystery Box)

Configuring a Huawei Cloud ECS Linux server is totally doable—and honestly, much less painful than it sounds once you approach it in the right order. Start with planning, lock down access, update the system, set up a proper admin user, configure firewall rules at both cloud and OS layers, and then install your actual services.

Most issues come from skipping one layer—usually networking or firewall consistency. When you keep those layers aligned, your server behaves like a responsible citizen instead of a chaotic gremlin.

Now go forth and configure with confidence. And remember: if you ever think “I’ll just tweak SSH config quickly,” pause and imagine future-you trying to log in at 2 a.m. Future-you deserves kindness, not surprise.

TelegramContact Us
CS ID
@cloudcup
TelegramSupport
CS ID
@yanhuacloud