Common Issues

Debugging Failed SSH Connections

If you're unable to connect to a machine over SSH, it may be due to a misconfiguration.

Check if SSH Traffic Is Blocked by Security Group Rules

It's easy to accidentally deploy a VM with SSH access blocked. To determine if your SSH traffic is even reaching the VM (and not being dropped by security group rules), run the ssh command with verbose logging:

ssh -i ~/.ssh/id_rsa evroc-user@185.222.1.1 -vvvv
OpenSSH_9.6p1 Ubuntu-3ubuntu13.12, OpenSSL 3.0.13 30 Jan 2024
debug1: Reading configuration data /home/example/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 185.222.1.1 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/example/.ssh/known_hosts'
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 185.222.1.1 [185.222.1.1] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10

If the logs stop shortly after a line like: Connecting to 185.222.1.1 [185.222.1.1] port 22....then it is likely that security group rules are blocking your SSH traffic.

If so:

  • Determine which security groups your VM belongs to.
  • Inspect the rules in those security groups.
  • If no rule allows SSH ingress:
    • Update the VM to include the default-sto-1-ssh security group which is created by default to allow SSH.

Determining Which Security Groups Your VM Belongs To

To identify the security groups associated with your VM:

Example output:

$ evroc compute vm show myVM --verbose
name: myVM
....
== Spec ================================
networking:
  securityGroups:
    securityGroupMemberships:
      - name: default-sto-1
      - name: allow-https
....

Inspecting Rules in Security Groups

To inspect the rules:

You need to check for a rule that allows:

  • Ingress traffic
  • Protocol = TCP and Port = 22 or Protocol = All
  • A remote source that includes your IP address

Examples:

$ evroc networking securitygroup showrules my-sg
[
    {
        "name": "allow-ssh-from-anywhere",
        "direction": "Ingress",
        "protocol": "TCP",
        "port": 22,
        "remote": {
            "securityGroupRef": {},
            "subnetRef": {},
            "address": {
                "IPAddressOrCIDR": "0.0.0.0/0"
            }
        }
    }
]
$ evroc networking securitygroup showrules my-sg
[
    {
        "name": "allow-all-protocols-from-1921010slash24",
        "direction": "Ingress",
        "protocol": "ALL",
        "remote": {
            "securityGroupRef": {},
            "subnetRef": {},
            "address": {
                "IPAddressOrCIDR": "192.10.10.0/24"
            }
        }
    }
]

If you cannot find a rule allowing SSH:

  • Proceed to the next section to create one.

If you can find a rule:

Updating a VM to use the "default allow SSH" Security Group

When updating a VM’s security groups, you must provide the complete list of groups it should belong to:

$ evroc compute vm update <VM name> our-vm --security-group=default-sto-1 --security-group=allow-https --security-group=default-sto-1-ssh

Note this default-sto-1-ssh rule is created by default and allows for SSH acccess.

Once this is done, you should retry, and see if your VM is now accessible.

SSH public key failures

If your SSH session progresses further and you see a prompt like this:

ssh -i ~/.ssh/id_rsa ubuntu@185.222.1.1
The authenticity of host '185.222.1.1 (185.222.1.1)' can't be established.
ED25519 key fingerprint is SHA256:aIJjCFHtSIBi5InM6LdAht2gTPDFpfNL3S9+M0BGcjU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '185.222.1.1' (ED25519) to the list of known hosts.
ubuntu@185.222.60.45: Permission denied (publickey).

This means you have reached the VM, but your private key is being rejected.

Check the following:

  1. Correct Username:
  • In the example above, the user incorrectly used ubuntu instead of evroc-user.
  1. Correct Private Key:
  • Make sure you're using the private key that corresponds to the public key configured on the VM.

VM inaccessible over SSH after VM recreation

If the user:

  1. Creates a VM, boot Disk, and public IP.
  2. Deletes the VM resource.
  3. Re-creates the VM resource, but keeps the link to the existing boot Disk resource.

Then, the new VM will come up with a new MAC address and a unique UUID in its metadata.

If you have stored the details of the old MAC address onto your boot disk, or disabled software such as cloud-init or DHCP, you may find that the new VM has invalid networking configuration which both you and evroc support will be unable to recover easily.

To recover from this, you will need to attach the broken disk to another functioning VM as an additional disk, fix the disk, then umount it.

VMs stopped and restarted will keep the old MAC addresses and cloud-config provided metadata Instance ID.