Skip to main content
Connect your servers over SSH to let Alex (Cloud Engineer) run shell commands on your hosts: checking disk usage, tailing logs, inspecting services, and diagnosing issues directly on the box.

​
Prerequisites

RequirementDetail
Reachable hostThe server must accept inbound SSH from CloudThinker on its SSH port
Login userAn existing user account with shell access
Authorized keyThe public half of your key present in that user’s ~/.ssh/authorized_keys
Key-based auth enabledsshd must allow public-key authentication for the user

​
Setup

1

Prepare a Key Pair

Use an existing key pair or generate a dedicated one for CloudThinker:
ssh-keygen -t ed25519 -C "cloudthinker" -f ./cloudthinker_key
This produces cloudthinker_key (private) and cloudthinker_key.pub (public). Both OpenSSH (-----BEGIN OPENSSH PRIVATE KEY-----) and PEM (-----BEGIN RSA/EC PRIVATE KEY-----) formats are accepted, including ed25519, rsa, and ecdsa keys.
2

Authorize the Public Key

Add the public key to the login user’s authorized keys on the server:
ssh-copy-id -i ./cloudthinker_key.pub user@server.example.com
# or append cloudthinker_key.pub manually to ~/.ssh/authorized_keys
3

Add Connection in CloudThinker

Navigate to Connections → SSH and enter:
  • Host: hostname or IP, e.g. server.example.com or 10.0.0.5
  • User: the login user, e.g. ubuntu
  • Port: SSH port (optional, defaults to 22)
  • Private key: the full private key, including the BEGIN/END lines
  • Passphrase: optional, only needed if the private key has one
CloudThinker tests the connection and, once it succeeds, the connection is ready for your agents to use.

​
When the Server’s Identity Changes

The first time you connect, CloudThinker remembers your server’s identity. On every later connection, it checks that the server still matches, so you’re warned if that identity changes unexpectedly. If it changes, the connection stops and CloudThinker shows you both the previously trusted fingerprint and the new one. This normally happens after you rebuild a server or rotate its keys. Once you’ve confirmed the change is expected, choose Trust new host key to continue.
If you didn’t expect the server’s identity to change, don’t trust the new key yet. An unexpected change can mean the connection is being intercepted. Verify the new fingerprint against your server first.

​
Agent Capabilities

Once connected, agents run shell commands on your server over SSH:
CapabilityDescription
System inspectionDisk, memory, CPU, processes, and service status
Log analysisRead and search application and system logs
DiagnosticsInvestigate failures, connectivity, and configuration on the host
Operational checksRun read-only commands to report on the server’s state

​
Example Prompts

@alex check disk usage on the production server and flag filesystems above 80%
@alex tail the last 100 lines of /var/log/app/error.log and summarize the errors
@alex show me which processes are using the most memory right now
@alex check whether the nginx service is running and report its status
Commands run with the permissions of the login user. Scope that user to what your agents actually need.

​
Troubleshooting

  • Confirm the public key is in the login user’s ~/.ssh/authorized_keys
  • Verify the User matches an account that key is authorized for
  • Ensure the private key was pasted in full, including the BEGIN/END lines
  • If the key is passphrase-protected, provide the Passphrase
  • Verify the Host and Port are correct
  • Confirm the server accepts SSH from CloudThinker (firewall, security group, or allowlist)
  • Check that the SSH daemon is running and listening on that port
  • Expected after a server rebuild or SSH key rotation: review the new fingerprint and choose Trust new host key
  • If the change is unexpected, investigate before re-trusting
  • The connection is healthy but the command returned a non-zero exit code
  • Check the command, the user’s permissions, and paths on the remote host

​
Security Best Practices

  • Dedicated key - Generate a key pair used only for CloudThinker so it can be revoked independently
  • Least-privilege user - Connect as a user scoped to only what your agents need
  • Restrict the key - Use command= and from= options in authorized_keys to limit what the key can do and where it can connect from
  • Protect the key - Use a passphrase-protected private key
  • Rotate keys - Replace the key periodically and remove old entries from authorized_keys
  • Verify host keys - Always confirm a host key change is expected before re-trusting

Alex Agent

Cloud engineering and infrastructure operations
https://mintcdn.com/cloudthinker/aLd-ttc-SCW-aFky/images/icons/kubernetes.svg?fit=max&auto=format&n=aLd-ttc-SCW-aFky&q=85&s=7c03292954ff635a1994623a5c39971b

Kubernetes Connection

Connect clusters for workload analysis and operations