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-sshsecurity group which is created by default to allow SSH. 
 - Update the VM to include the 
 
Determining Which Security Groups Your VM Belongs To
To identify the security groups associated with your VM:
- Using the CLI: See the 'show' command.
 - Using the API: Get detailed information about a resource
 
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:
- Using the CLI: See the 'showrules' command
 - Using the API: Get detailed information about a security group
 
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:
- Ensure your current IP is included in the allowed remote range.
 - If you're still unable to connect, see VM inaccessible over SSH after VM recreation.
 - If none of these apply, contact evroc support.
 
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:
- Correct Username:
 
- In the example above, the user incorrectly used ubuntu instead of evroc-user.
 
- 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:
- Creates a VM, boot Disk, and public IP.
 - Deletes the VM resource.
 - 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.