Security & Infrastructure. My Crypto Bot VPS Was Hacked: Three Security Lessons

A weak SSH login, an overprivileged exchange key, or a forgotten provider snapshot can give an intruder enough access to trade against you, expose credentials, or turn a contained server problem into an account-wide incident.

That is the uncomfortable part of VPS security for crypto trading bots: the controls are usually familiar, but they have to work together. SSH keys, a deny-by-default firewall, narrowly scoped API permissions, protected secrets, and a recovery plan are not separate decorations around a bot. They are the bot’s operating environment. Miss one layer, and the rest may have to absorb an attack it was never designed to handle.

I have treated the following as non-negotiable since reviewing how easily a poorly configured bot server can be abused. None of these measures is complicated in isolation. The discipline is in applying them before a strategy goes live, and in revisiting them whenever the server, exchange account, or deployment process changes.

Hardening SSH Access: Beyond Default Credentials

The first thing an attacker scanning the public internet is likely to encounter is SSH. Automated tools continually test exposed servers with common usernames, leaked passwords, and familiar configuration patterns. If a VPS still accepts password logins on the default SSH port, it is offering an easy first conversation.

The single biggest improvement is to replace password authentication with SSH keys. Generate a key pair on your local machine, copy the public key to the server, and then disable password login in /etc/ssh/sshd_config with:

PasswordAuthentication no

Once that setting is active, knowing the username is not enough. The attacker also needs the corresponding private key. That changes the problem from guessing a credential to obtaining a protected administrative secret.

Do not make the change while relying on your only open terminal. Keep the existing session active, open a second terminal, and test a new key-based connection before closing anything. A small syntax error in the SSH configuration or a mistaken file permission can lock you out just as effectively as an attack. The old session is your safety line while you verify the new one.

Root login should be disabled as well:

PermitRootLogin no

The bot should run under its own unprivileged service account, and administration should happen through a separate user with narrowly controlled sudo access. This separation matters because a trading process does not need permission to rewrite the operating system. If the bot is compromised, running it as root gives the intruder a much larger workspace.

A non-standard SSH port is useful, but only for the reason people sometimes dismiss too quickly. It is not a security boundary, and it will not conceal a server from a determined attacker who performs a full port scan. It can, however, reduce the amount of routine noise generated by automated scans. Think of it as moving your front door away from the street’s most obvious entrance, not as replacing the lock.

A different SSH port reduces background noise. Keys, disabled root login, and a firewall are what provide meaningful control.

A practical sequence is straightforward:

1. Create an Ed25519 key pair locally with ssh-keygen -t ed25519.

2. Install the public key for a dedicated administrative user.

3. Confirm that key-based login works from a separate terminal.

4. Disable password authentication and direct root login.

5. Reload the SSH service and test the connection again.

6. Keep a documented recovery path through the provider console in case the network configuration fails.

The private key needs protection too. Give it a passphrase, use an SSH agent where appropriate, and avoid carrying an unrestricted copy on every computer used to manage the VPS. A carefully configured server can still be taken over through a stolen laptop or an exposed workstation key. VPS security for crypto trading bots begins before the first packet reaches the server.

Multi-factor authentication for the hosting account is another part of this boundary. It does not protect the SSH daemon directly, but it protects the provider console, rebuild function, snapshot controls, billing account, and recovery tools. An attacker who cannot log in over SSH may still cause serious damage if they can reset the VPS, attach its disk to another machine, or change its network settings through the hosting panel.

Network Perimeter Defense: Firewalls and Fail2Ban

SSH is the front door. The firewall is the decision about which doors exist at all.

A fresh VPS may have services listening that the bot does not need: a database, a development dashboard, a container API, a monitoring interface, or a default management service. Every unnecessary listener adds another place where a configuration mistake can become an entry point. The safest starting position is to deny inbound traffic by default and allow only the paths required for administration and monitoring.

On Debian and Ubuntu, many operators use UFW. On CentOS, RHEL, and AlmaLinux, firewalld is common. The tool matters less than the policy:

• Allow the selected SSH path, ideally from a narrow IP range or private network.
• Expose HTTPS only when a dashboard genuinely needs public access.
• Keep databases, queues, bot control ports, and container-management interfaces private.
• Permit outbound HTTPS to exchanges and other required services.
• Remove temporary rules created during installation or troubleshooting.

Most execution-only bots need to initiate connections rather than receive them. They call exchange APIs, fetch market data, send notifications, and report status to a monitoring system. The wider internet usually has no legitimate reason to open a connection to the bot itself. That makes a narrow inbound policy particularly appropriate for this kind of server.

If the dashboard does not need to be public, put administration and monitoring behind a private overlay network such as Tailscale or another controlled VPN. The point is not that a private network is automatically trustworthy. It is that the service no longer has to accept connections from every address on the internet. Access can then be tied to specific devices, users, and authentication policies.

Fail2Ban adds another useful layer. It watches authentication logs, detects repeated failures, and temporarily blocks addresses that behave like brute-force clients. It can reduce repetitive SSH probes and password spraying, but it should never be used as an excuse to leave password login enabled. A service that rejects passwords is safer than a service that accepts them until an automated ban arrives.

A compact perimeter for a small bot VPS usually has these characteristics:

• Administration is available only through a selected SSH path, private network, or tightly managed allowlist.
• The monitoring interface is private whenever possible and protected by HTTPS and separate authentication when it is exposed.
• Internal service ports are bound to localhost or a private interface rather than the public address.
• Logs are copied to a separate destination so an intruder cannot erase every useful record from the VPS.
• Firewall rules are reviewed after software updates, migrations, and changes to the bot’s architecture.
• Provider-level network controls are enabled where they offer meaningful protection against volumetric attacks or unwanted exposure.

The firewall also needs to be tested from outside the server. A rule that looks correct in a configuration file may not match the interface, address family, container bridge, or provider security group you actually use. Check the listening services, review the provider’s network panel, and confirm that an internal port is genuinely unreachable from an external connection.

The hosting provider belongs in the threat model. A secure VPS for trading bots is not just an operating system with a few hardened settings. It is also a provider account with strong multi-factor authentication, protected recovery details, controlled console access, and a clear understanding of how backups and snapshots are handled.

Review whether snapshots are enabled automatically, who can access rescue images, how support requests are authenticated, and whether account-level actions are logged. A server can be well configured while the provider account remains easy to take over. That is still a hosting security failure, not an unrelated administrative detail.

API Key Hygiene: Limiting the Blast Radius

A compromised VPS becomes much more dangerous when the exchange API key can withdraw funds. If the bot only has the permissions required to read account data and place trades, the incident is still serious, but the attacker’s options are narrower.

When creating an API key, start with the minimum permissions rather than accepting the exchange’s broad default. For a conventional trading bot, that generally means read access and trading access. Withdrawal access should remain disabled. Permissions that move funds between sub-accounts should also be disabled unless the strategy has a clearly documented reason to use them.

A trade-only key is not harmless. An attacker may still open oversized positions, cancel protective orders, consume margin, trade illiquid pairs, or generate losses through repeated activity. Permission limits reduce the blast radius; they do not replace position limits, monitoring, or a rapid shutdown mechanism.

IP whitelisting is the next control. If the exchange supports it, bind the key to the VPS’s egress IP address. A stolen key then becomes harder to use from an attacker’s own machine. This protection needs operational care: rebuilding the server, changing regions, adding a standby node, or altering the network gateway can change the source IP and cause legitimate requests to fail.

That failure is preferable to silently accepting requests from anywhere, but only if it is documented. Keep the current egress address, the exchange allowlist, and the procedure for changing them in the deployment runbook. Test the process with a non-production key before an outage forces you to improvise.

One key per strategy is another useful boundary. If several bots share one credential, a compromise of the least secure bot can expose every market and account attached to that key. Separate keys make rotation more surgical. Better still, use separate exchange sub-accounts where the platform and strategy permit it, and give each bot only the product permissions it needs.

A futures strategy should not automatically receive access to spot, margin, options, and account transfers. Some exchanges group these capabilities behind a single toggle, while others allow more granular settings. Read the permission descriptions carefully; “trade” does not mean the same thing on every venue.

No withdrawals. IP restrictions where available. Separate keys for separate strategies. Security is easier to contain when identity is not shared.

The bot software itself deserves suspicion. Some tools ask for full API access because broad permissions simplify integration or support features that most users never enable. Do not grant those permissions by habit. If a bot cannot operate with a restricted key, ask whether the convenience is worth making the server a direct path to your exchange account.

Credentials should not appear in support conversations, screenshots, shell history, or pasted configuration files. Treat any key that has been exposed during debugging as compromised and rotate it. Do not wait for evidence of misuse; the value of a key is that it can be replaced before it is used.

Logs are a frequent source of accidental exposure. Debug output may include request headers, signed payloads, environment variables, account identifiers, or complete error objects returned by an exchange library. Review the logging configuration before putting live credentials into production. Mask secrets, disable verbose request logging outside development, and restrict access to retained logs.

The same principle applies to alerts. A notification that contains the full API request or account response may be convenient during testing and dangerous during an incident. Send enough information to identify the strategy and failure, but not enough to reconstruct the credential or signed request.

In-Memory Secrets: Protecting Keys from Disk Snapshots

Many bot deployments start with a .env file in the application directory. It is convenient, familiar, and often copied into backups without anyone noticing. The problem is not the filename. The problem is persistence.

A secret saved on a VPS can end up in a filesystem snapshot, automated backup, container layer, temporary archive, shell history, or support bundle. Encrypting the file improves protection against casual reading, but the application still needs a way to decrypt it. The decryption key, passphrase, or running process then becomes part of the design.

In-memory secret handling reduces one class of exposure by keeping the usable credential out of persistent storage for as long as practical. Depending on the architecture, that may involve a secrets manager such as HashiCorp Vault or Doppler, an encrypted tmpfs mount, or a deployment process that retrieves the secret at startup and places it only in a protected runtime location.

The benefit is clearest with snapshots. If an exchange key is not present on the filesystem when a snapshot is taken, the image cannot reveal that key simply because someone later mounts or copies the image. This does not make the live VPS safe from a privileged attacker. A running process still has to use the credential, and an intruder with sufficient access may inspect memory, environment data, or outgoing requests.

That limitation is important. In-memory secrets are not a substitute for a hardened host, restricted API permissions, and rotation. They are a way to prevent one compromise or backup mistake from becoming a durable credential leak.

An encrypted tmpfs can be appropriate for smaller deployments. The mount should have restrictive ownership and permissions, and only the bot’s service account should be able to read from it. The startup process can populate the mount from a protected source, launch the bot, and remove the material during shutdown. The exact implementation depends on the operating system and deployment model, but the security question stays the same: where can the secret exist, and how long does it remain there?

Environment variables need the same scrutiny. They are often described as safer than files, but they can appear in process inspection tools, crash reports, orchestration metadata, diagnostic output, and accidentally verbose service logs. An environment variable is not magically private because it lacks a file extension.

Avoid leaving decrypted credentials in:

• Shell history or command-line arguments.
• Container images and copied container layers.
• Temporary troubleshooting archives.
• CI artifacts and deployment logs.
• Crash dumps and monitoring payloads.
• Unrestricted backup directories.

The deployment process should make accidental persistence difficult. Use a dedicated service account, keep secret locations inaccessible to other users, and avoid running the bot as root. If a process needs a credential only during startup, remove the temporary copy after it has been loaded. If the bot must refresh credentials during runtime, define how that refresh occurs and what happens when the secret manager is unavailable.

There is a trade-off. In-memory handling is less convenient than keeping a permanent .env file on disk. Restarts, deployments, and recovery procedures require more thought. That inconvenience is useful: it forces the operator to decide how a bot is authenticated instead of allowing the most convenient file to become the permanent source of truth.

Secrets also need a lifecycle. Rotate them after a suspected compromise, after exposing them in a log or support ticket, and whenever an administrator or service boundary changes. Rotation should be tested before an emergency. A credential that can be revoked but cannot be replaced without taking the strategy offline is only partially managed.

Infrastructure Resilience: Beyond Basic Configurations

Hardening a VPS is not the same as making a trading operation resilient. A locked-down server can still fail because of a provider outage, a broken update, a lost SSH key, an expired API key, a full disk, or a bot that continues trading after its market-data connection becomes unreliable.

The first resilience measure is separation. Keep the trading process, monitoring, and administrative access logically distinct where the workload justifies it. A public dashboard should not share the same exposed service boundary as an internal execution engine. A test bot should not use the same exchange account, credentials, or filesystem paths as a live strategy.

The second is observability. You need to know not just that the process is running, but whether it is behaving correctly. Useful signals include:

• Repeated authentication failures on the host.
• Unexpected changes in outbound destinations.
• API errors and authentication failures.
• Orders placed outside the strategy’s expected market or size range.
• Position growth beyond defined limits.
• Sudden cancellation of protective orders.
• Changes to firewall rules, users, scheduled tasks, and service files.
• Disk, memory, and CPU conditions that could make the bot unstable.

Monitoring should be independent of the VPS where possible. If all alerts are written to a local file and the attacker controls the host, the alerting system is part of the compromise. Send important events to a separate service and make sure the notifications do not contain secrets or excessive account detail.

A kill switch should be operational, not theoretical. It may revoke the exchange API key, disable the bot service, block outbound traffic, close positions according to a documented emergency procedure, or combine several of these actions. The right response depends on the strategy and venue, but it must be possible to execute quickly from a trusted device.

Do not assume that stopping the process closes exposure. A bot may leave open positions, unfilled protective orders, or borrowed balances behind when it exits. The incident procedure should state who checks the exchange account, which orders are cancelled, how positions are assessed, and when credentials are revoked.

Backups need the same discipline as live systems. A backup that contains the application, configuration, logs, and secrets is not a neutral recovery copy. Encrypt it, restrict access, define retention, and determine whether secrets should be excluded entirely. Test restoration on a clean environment. A backup that has never been restored is a hope, not a recovery plan.

Updates should be staged rather than applied blindly to a live execution node. Maintain a record of the operating system, bot version, libraries, firewall rules, systemd units, and exchange settings. Before an upgrade, confirm that you can recover the previous version and that the API key can be rotated if the deployment process exposes it.

Least privilege should extend beyond the exchange. The bot’s service account should not have administrative access. The monitoring process should not be able to rewrite the application’s credentials. Deployment credentials should not be available to the running strategy. If containers are used, review their privileges, mounted paths, host networking, and access to the container runtime. A container boundary is not a replacement for host security.

The provider console needs an emergency plan too. Store recovery codes securely, document the account owner and billing contact, and know how to rebuild a compromised instance without reintroducing the same vulnerable configuration. If the only person who knows the recovery process is unavailable, the infrastructure has a single point of failure.

Finally, rehearse the unglamorous actions. Revoke a test API key. Restore a bot on a fresh VPS. Confirm that an IP allowlist update works. Lock down a dashboard. Recover access through the provider console. Check that alerts arrive when the bot is stopped. These exercises expose configuration gaps while the stakes are low.

A secure VPS configuration for crypto trading is not a one-time installation task. It is a set of boundaries that must survive routine change: new strategies, new exchange accounts, new hosting regions, software upgrades, and emergency fixes. The configuration mistakes that matter most are rarely dramatic. They are the temporary firewall rule that stayed open, the API key copied into a debug log, the old snapshot never deleted, or the service account granted more access “just for now.”

That is why protecting a trading bot server is less about finding a perfect tool than about reducing unnecessary capability. The SSH service should accept fewer kinds of authentication. The network should expose fewer services. The exchange key should be able to move less money. The secret should persist in fewer places. The recovery process should depend on fewer assumptions.

A bot can still lose money because a strategy is wrong or a market moves violently. Security controls cannot eliminate that risk. They can, however, prevent a routine server compromise from becoming an unrestricted withdrawal, an entire-account takeover, or an incident that remains hidden inside an old backup.

The best time to make those limits boring is before the bot starts trading. Once the server is live, the exchange key is funded, and the strategy is producing orders, every security change becomes more stressful. Build the restrictions into the deployment from the beginning, and a compromised VPS becomes a contained infrastructure problem rather than a crisis with access to everything.