Introduction#

First Connection to This Machine#

After buying the server, the real problem began: how do I get in?

The console provides a public IP, root user, and initial password. The most direct way is to connect once with the password:

1
ssh root@<VPS_PUBLIC_IP>

The first connection will ask if you want to trust this machine. Confirm the IP is correct, then type yes.

But this password login is only for temporary use. For long-term use, I still recommend switching directly to SSH key login.

Password login is like hiding a key under the doormat. It’s convenient, but public machines are scanned daily. Default port 22 plus password login is basically telling all the scripts on the internet, “Come knock on my door.”

Generating SSH Keys#

I’m doing this on Windows, so I’ll first generate an SSH key specifically for this server locally:

1
ssh-keygen -t ed25519 -C "sayori-vps" -f "$env:USERPROFILE\.ssh\sayori_ed25519"

You can just press Enter all the way through. If you want to add another layer of protection to your private key, set a passphrase.

Two files will be generated:

1
C:\Users\<Your_Username>\.ssh\sayori_ed25519
2
C:\Users\<Your_Username>\.ssh\sayori_ed25519.pub

The one without .pub is the private key. If you don’t know what it’s for, you can send it to me, then I can connect to your SSH 😈

The one with .pub is the public key, which can be placed on the server.

Let’s look at the public key content:

1
Get-Content "$env:USERPROFILE\.ssh\sayori_ed25519.pub"

Copy the entire line, from ssh-ed25519 to the end of the comment.

Putting the Public Key on the Server#

Keep the password-logged-in SSH window open. On the server, prepare the SSH directory:

1
mkdir -p ~/.ssh
2
chmod 700 ~/.ssh
3
nano ~/.ssh/authorized_keys

Paste the entire line from your local .pub file, then save.

Then change permissions:

1
chmod 600 ~/.ssh/authorized_keys

This step seems strange, but it’s very important. If the permissions are too loose, SSH will fail directly and won’t recognize this key.

Next, write an SSH alias locally. This way, you won’t have to type a long string of IP, port, and private key path every time.

Open:

1
notepad $env:USERPROFILE\.ssh\config

Write this in:

1
Host sayori
2
  HostName <VPS_PUBLIC_IP>
3
  User root
4
  Port 22
5
  IdentityFile ~/.ssh/sayori_ed25519

Open a new terminal to test:

1
ssh sayori

If you can connect directly, it means key login is working.

Note: test in a new terminal. Don’t close the old password login window yet; it’s like a safety rope. Only let go after everything is changed.

Disable Password, Change to a Non-Standard Port#

Once key login is stable, you can disable password login and move SSH from the default port 22.

First, choose a non-standard port, for example:

1
11451

Don’t just copy mine directly. Pick a port between 1024 and 65535 that doesn’t conflict with other services.

Then, go to Alibaba Cloud ECS security group and allow this port. This is crucial.

The UFW inside the server is one door, and the Alibaba Cloud security group is another. If you only change the server and not the security group, the new port still won’t be accessible.

After allowing the port in the security group, go back to the SSH window and write your own SSH configuration snippet:

1
nano /etc/ssh/sshd_config.d/99-sayori.conf

Content:

1
Port <SSH_PORT>
2
PubkeyAuthentication yes
3
PasswordAuthentication no
4
PermitRootLogin prohibit-password

Here, PermitRootLogin prohibit-password means root can still log in with a key, but not with a password.

A more rigorous approach is to create a new regular user and then disable root. But for this post, I’m covering the fastest usable method.

After modifying, first check for syntax errors in the SSH configuration:

1
sshd -t

No output is good news.

Then restart the SSH service:

1
systemctl restart ssh

Do not close the old window yet.

Also change the port in your local ~/.ssh/config:

1
Host sayori
2
  HostName <VPS_PUBLIC_IP>
3
  User root
4
  Port <SSH_PORT>
5
  IdentityFile ~/.ssh/sayori_ed25519

Now open a third new terminal to test:

1
ssh sayori

If you can connect, it means the new port, key login, and security group are all working.

I would test one more time if the old password login is disabled, for example, by not using the private key and manually connecting to the IP.

If it still asks for a password and lets you in, it means PasswordAuthentication no didn’t take effect. Don’t rush to continue; figure that out first.

Configure Firewall#

Once SSH is stable, configure the server’s own firewall.

On Ubuntu, UFW is the most convenient:

1
apt update
2
apt install -y ufw

Write the rules first:

1
ufw default deny incoming
2
ufw default allow outgoing
3
ufw allow <SSH_PORT>/tcp

If you’re already planning to run web services, you can allow HTTP / HTTPS for now:

1
ufw allow 80/tcp
2
ufw allow 443/tcp

Then enable it:

1
ufw enable
2
ufw status verbose

Here, I still recommend keeping the old SSH window open. Open a new terminal and connect again:

1
ssh sayori

If you can connect, then close the old window.

After Connecting, Explore the Machine#

Once truly connected and stable, you can take a look at the machine’s status:

1
uname -a
2
df -h
3
free -h
4
systemctl status ssh --no-pager
5
ufw status numbered

2H2G isn’t a lot of memory, so future service choices will mostly need to be lightweight.

If you can avoid a database, do so. If SQLite works, use SQLite first. If it can be hosted on Cloudflare Pages, don’t put it on the VPS.

This machine later ran more than just bots; Vaultwarden, ntfy, Gatus, Portainer, and AI Search Gateway all grew from here.

https://awesome-selfhosted.net/, this is a great “awesome” series website about how to utilize servers!

Looking back, the most useful thing about a personal server isn’t a specific service, but rather being forced to understand networking, deployment, security, and backups.

If I were to do it again, I would establish a few habits earlier:

1. Separate directory for each service
2. Real secrets only in .env or platform Secrets
3. Write all reproducible commands into documentation
4. Leave a verification command after each deployment

That’s all for this post. The server can now be stably connected via SSH, password login is off, the port has been changed, and the firewall has its basic boundaries.

The next post will cover how to use scp to move local configurations to the remote host.

Which means, finally, moving the bot from “it runs on my computer” to “it runs on the server too.”