Connect to a Linux node

SSH gets you a shell on your Linux node. You need its public IP, from its detail page, and either its password or a private key whose matching public key you have added to the node. Use the password from your email to connect the first time; add a key for a node you will keep using, since a key stays safer over the long run.

Before you connect, make sure the node’s security group allows inbound TCP port 22 from the source you are connecting from, and that the node’s own firewall inside it allows the same port. Most connection failures come from one of those two, not from the node’s status in the portal.

Connect with a password

Password-based SSH access is on by default when you create a node. E2E emails you the node’s username and password as soon as it is created. Open a terminal and run:

ssh <username>@<public-ip>

Enter the password from that email when prompted. Once you are in, the terminal shows the node’s own prompt, and every command you type runs on the node.

Connect with a private key

Add your SSH key while creating the node, or add one since through Add an SSH key to a node. Then connect with the private key that matches it:

chmod 600 ~/.ssh/<key>
ssh -i ~/.ssh/<key> <username>@<public-ip>

On Linux or macOS, the private key file must be readable only by you: run chmod 600 ~/.ssh/<key> first, or SSH refuses the key. Replace <key> with the name of your actual key file.

The first time you connect, SSH asks you to accept the host’s fingerprint. Type yes when the address matches the node you meant to reach. If you set a passphrase on the key, SSH asks you to enter it each time you connect.

E2E’s key forms take only the public key, so your private key stays on your machine. Keep it safe: if a node trusts only that key and you lose it, you cannot get back in. Add a second key, or leave password login on as a fallback.

If password login is disabled

Turning off password-based SSH while creating the node (see Create a node) means the password from your creation email does not work for SSH, even though the email itself still arrives. Connect with a private key that matches an SSH key attached to the node instead. If you lose that key, add another one from Add an SSH key to a node and connect with its matching private key.

On a Linux node, you manage access by adding or removing SSH keys; the in-portal password change is for Windows nodes. See Add an SSH key to a node.

SSH connects straight to the node over the network. Whenever the node is reachable on the network, SSH works, whatever status the portal shows; locking a node, for example, leaves SSH open. If the connection times out or is refused, see Troubleshooting: networking and connectivity.

Common SSH connection problems

What you see	Likely cause	What to do
Permission denied (publickey)	The private key you are using does not match an SSH key attached to the node.	Use the private key that matches an attached SSH key, or add a new one and retry.
Permission denied, please try again	Password login is off for the node, or the password or username is wrong.	Connect with a private key instead, or confirm the username and the latest password.
Connection times out	The node has no reachable IP, port 22 is blocked, or the node is not Running.	Check the public IP, the security group, and the node’s own firewall.
Connection refused	SSH is not listening yet, an OS firewall blocks it, or the node is still starting up.	Open Access Console to check the SSH service, or retry once the node finishes starting.
A different host-key warning than before	Your machine has a stored host key for that IP from an earlier, different node.	Confirm you are connecting to the node you mean to before replacing the stored host key.

If none of these match what you are seeing, see Troubleshooting: networking and connectivity.

Before you rely on SSH access in production

• Prefer a private key over the emailed password once you are past first access.
• Keep private keys only on machines you trust.
• Restrict the security group’s inbound port 22 to the sources that actually need it, not every address.
• Do not share the emailed password over chat or a support ticket.
• Rotate an SSH key once someone who had it leaves, or the key’s exposed.
• Keep Access Console available as a fallback if you ever lose both the password and the key.

If SSH stops answering, you can still reach the node through its console; see Open a node’s console.