diff --git a/docs/cloud/img/instance-no-keypair.png b/docs/cloud/img/instance-no-keypair.png index d30dad97ff..5de19848f7 100644 Binary files a/docs/cloud/img/instance-no-keypair.png and b/docs/cloud/img/instance-no-keypair.png differ diff --git a/docs/cloud/img/instances-keypair.png b/docs/cloud/img/instances-keypair.png new file mode 100644 index 0000000000..282189258e Binary files /dev/null and b/docs/cloud/img/instances-keypair.png differ diff --git a/docs/cloud/img/key-pair-page.png b/docs/cloud/img/key-pair-page.png index 6fca3e2392..52527c0c87 100644 Binary files a/docs/cloud/img/key-pair-page.png and b/docs/cloud/img/key-pair-page.png differ diff --git a/docs/cloud/img/key-pairs-listing.png b/docs/cloud/img/key-pairs-listing.png new file mode 100644 index 0000000000..6ad84892d8 Binary files /dev/null and b/docs/cloud/img/key-pairs-listing.png differ diff --git a/docs/cloud/img/log-instance.png b/docs/cloud/img/log-instance.png index 40a2389553..4fc9c80fbd 100644 Binary files a/docs/cloud/img/log-instance.png and b/docs/cloud/img/log-instance.png differ diff --git a/docs/cloud/pouta/connecting-to-vm.md b/docs/cloud/pouta/connecting-to-vm.md index 72b8fbf4dc..0ca75bbdea 100644 --- a/docs/cloud/pouta/connecting-to-vm.md +++ b/docs/cloud/pouta/connecting-to-vm.md @@ -82,7 +82,7 @@ Check the manual page of [ssh_config](https://linux.die.net/man/5/ssh_config) fo ssh -A cloud-user@public-ip - By enabling agent forwarding, you enable the ssh agent running on the remote Virtual Machine to make use of the keys which are loaded in the ssh agent of your local workstation. You can use this feature to use the "Bastion host model", where only one single machine, the bastion host, in the cluster has Floating IP and outside access, and the rest of the machines are accessed through the bastion. +By enabling agent forwarding, you enable the ssh agent running on the remote Virtual Machine to make use of the keys which are loaded in the ssh agent of your local workstation. You can use this feature to use the "Bastion host model", where only one single machine, the bastion host, in the cluster has Floating IP and outside access, and the rest of the machines are accessed through the bastion. 1. Assign a floating IP to one of your instances 1. ssh to the instance enabling agent forwarding @@ -106,42 +106,6 @@ Open Putty, after following the instructions at [windows-putty](/cloud/pouta/lau Next time you need to use Putty to connect this instance, you will just need to **Load** the corresponding saved session and click **Open**. -## Troubleshooting - -### port 22: Connection timed out - -If you are not able to connect to your VM, the first thing to double check are the security groups, in the [Firewalls and security groups](../launch-vm-from-web-gui/#firewalls-and-security-groups) article there is a guide on how to set them up correctly. - -If the problem persists you may check the firewall setup of your local institution. - -!!! info "Permission denied" - Incorrectly configured Security Groups, can lead to permissions denied errors due to the fact that the VM needs to fetch the public SSH keys on its first start. If the network is not configured properly, the public key may not be added and no access will be configured. - -### REMOTE HOST IDENTIFICATION HAS CHANGED - -Sometimes Floating IPs are reused with different Virtual Machines at different times. By default SSH will have `stricthostkeychecking=yes` configured, and will show you the error message: - -```sh -$ ssh cloud-user@86.50.xxx.xxx -@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ -@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! -Someone could be eavesdropping on you right now (man-in-the-middle attack)! -It is also possible that a host key has just been changed. -The fingerprint for the ECDSA key sent by the remote host is -SHA256:JURkzITHXHGavwz6fAahou5g4ii1q9CVuzLyImH5+tI. -Please contact your system administrator. -Add correct host key in /home/yyyy/.ssh/known_hosts to get rid of this message. -Offending ECDSA key in /home/yyyy/.ssh/known_hosts:28 - remove with: - ssh-keygen -f "/home/yyyy/.ssh/known_hosts" -R "86.50.xxx.xxx" -ECDSA host key for 86.50.xxx.xxx has changed and you have requested strict checking. -Host key verification failed. -``` - -You can safely do as it suggests and remove the entry. But only if you are **sure** that it is the first time you connect to said IP since it has been **assigned to a new instance**, or since the instance has been **reinstalled**. - ## `root` administrator access on a virtual machine If you are using an image provided by Pouta, and logged in using the default user account, you will be able to run commands as root with `sudo` with no password. If other accounts are created, they will not have `root` administrator access by default. @@ -182,3 +146,10 @@ Once there is a password based account, with no remote login allowed: *Umlaut* characters, such as *ä* or *ö*, do not work in the virtual console for most keymaps. + +## Troubleshooting + +If you have any issue connecting to your new Pouta Virtual Machine, please check out our [Why can't I connect to my virtual machine in Pouta?](../../support/faq/why-cant-i-connect-to-my-vm-in-pouta.md) article. + + + diff --git a/docs/support/faq/why-cant-i-connect-to-my-vm-in-pouta.md b/docs/support/faq/why-cant-i-connect-to-my-vm-in-pouta.md index 87bfe34f90..18a6ae1b40 100644 --- a/docs/support/faq/why-cant-i-connect-to-my-vm-in-pouta.md +++ b/docs/support/faq/why-cant-i-connect-to-my-vm-in-pouta.md @@ -8,18 +8,23 @@ There are several reasons that can cause problems when connecting to a VM. We wi Before connecting to a cPouta VM, it is necessary to add a Floating IP. This step is not necessary in ePouta, indeed ePouta does not provide Virtual IPs, one must connect directly to the Private IP. -In order to add a virtual ip, follow the [Post creation step](/cloud/pouta/launch-vm-from-web-gui/#post-creation-step) guide. +In order to add a virtual ip, follow the [Post creation step](../../cloud/pouta/launch-vm-from-web-gui.md#post-creation-step) guide. -### Security groups - Openstack's firewall +### port 22: Connection timed out ```sh $ ssh cloud-user@yy.yy.yyy.yy ssh: connect to host yy.yy.yyy.yy port 22: Connection timed out ``` -The most common reason that cause connection problems are firewalls and security groups that are too restrictive. Newly launched virtual machines will by default block all traffic. You need to create a new security group. The security group must open the SSH port 22 to the ingress traffic. +If you are not able to connect to your VM, the most common reason for these problems are **Firewalls** and **Security Groups** (Openstack's firewall) that are too restrictive. Newly launched virtual machines will by default block all traffic. You need to create a new security group. The security group must open the SSH port 22 to the ingress traffic. + +Please follow the [Firewalls and security](../../cloud/pouta/launch-vm-from-web-gui.md#firewalls-and-security-groups) groups article. If the problem persists you may check the firewall setup of your local institution. + +!!! Warning "Permission denied" + Incorrectly configured Security Groups, can lead to permissions denied errors due to the fact that the VM needs to fetch the public SSH keys on its first start. If the network is not configured properly, the public key may not be added and no access will be configured. + For this reason, you need to make sure that the `default` security group is configured in the VM at creation. -Please follow the [Firewalls and security](/cloud/pouta/launch-vm-from-web-gui/#firewalls-and-security-groups) groups article. If the problem persists you may check the firewall setup of your local institution. ### REMOTE HOST IDENTIFICATION HAS CHANGED @@ -46,62 +51,81 @@ Host key verification failed. You can safely do as it suggests and remove the entry. But only if you are sure that it is the first time you connect to said IP since it has been assigned to a new instance, or since the instance has been reinstalled. The example shows the output of the ssh command, different tools and versions might have a slightly different output, but the principle is the same. -## Authentication +## Authentication - Permission denied (too many authentication failures) ```sh Received disconnect from xx.xx.xxx.xx port 22:2: Too many authentication failures ``` -If the authentication is not confired properly, you may see an error similar to the one above. +If the authentication is not configured properly, you may see an error similar to the one above. This error can come from different root causes. -### Are you using the corect user? +### Are you using the correct user? -Different distributions are configured with different defaults users. See here the up to date list of [images](/cloud/pouta/images/#images) and their corresponding default users. +Different distributions are configured with different defaults users. See here the up to date list of [images](/cloud/pouta/images/#images) and their corresponding default users. For example if you are using "Ubuntu 24.04", the correct user is "ubuntu", but if you are using "AlmaLinux-9" the correct one is "almalinux". It is a common practise for Pouta images, when you try to login as `root`, to get a message back telling you which username to use instead: ```sh -$ ssh root@86.xxx.xxx.xxx +$ ssh root@86.xxx.xxx.xxx Please login as the user "cloud-user" rather than the user "root". ``` -### Is a key pair configured in the Instance? +### Which key pair is configured in the Instance? And do you have the matching Private Key? -It can happen that when the instance was created you forgot to add a key pair during the creation. This can be checked from the [instance page](https://pouta.csc.fi/dashboard/project/instances/). +In order to see which "**Key Pair**" is configured on that VM. Go to and see the key pair name. -![Instance with no Key Pair](../../cloud/img/instance-no-keypair.png) +![VM Status check](../../cloud/img/instances-keypair.png) -The only solution for this issue is to recreate the instance, this time remember to add a key pair. See the [SSH Key Pair](../../cloud/pouta/tutorials/ssh-key.md) and the [Creating a virtual machine](../../cloud/pouta/launch-vm-from-web-gui.md) articles. +Then go to where all **your** keys are configured. The page will give you the list of **public keys**. In the screenshots above, the "**Key Pair**" is `SGC-key`. -### Are you offering the correct private key? +![Key pairs listing](../../cloud/img/key-pairs-listing.png) -It could be that there is a public key configured in the instance, but you lack the correct corresponding private key. It is possible to double check this thanks to the key's finger print. There are two ways to check which fingerprint is configured in the Virtual machine. +Copy the Public key content (`ssh-rsa AAA.... jack@sgc.com`) into a file called `SGC-key.pub`. You can then calculate the **Public key** fingerprint by: -1. Go to the [instance page](https://pouta.csc.fi/dashboard/project/instances/), find the row corresponding to your VM and write down the name of the key pair configured. Then go to the [Key Pairs](https://pouta.csc.fi/dashboard/project/key_pairs) page and find the key pair corresponding to the key pair you wrote earlier. - - ![Key pair page](../../cloud/img/key-pair-page.png) +```sh +$ ssh-keygen -lf SGC-key.pub +2048 SHA256:FjN0zrymP3mMZzTJ/UJrypmVVcH8Wgok9+JBiBhcvFc no comment (RSA) +``` -1. You can also see the finger print of the key from the Instance log. Go to [instance page](https://pouta.csc.fi/dashboard/project/instances/) and click in the name of the instance. Then click in the Log tab. You will need to find the lines that begin with `ci-info`. This is the output of the cloud init script. +The example above uses the `SHA256` algorithm by default. You can force it to use `MD5` by doing: - ![Instance log](../../cloud/img/log-instance.png) +```sh +$ ssh-keygen -lf .ssh/SGC-key.pub -E md5 +2048 MD5:eb:b3:eb:ff:65:2f:cb:a5:fa:ab:f4:84:04:a2:d3:9a no comment (RSA) +``` -You will be able to see the username, the file where the keys are configured and the list of finger prints of the configured keys. +!!! Info "No Key Pair listed" + It is possible that the VM was created without a "**keypair**` (the corresponding field is empty `-`), in this case you need to [re-create the VM](../../cloud/pouta/launch-vm-from-web-gui.md), this time with a keypair configured. + ![No Key Pair](../../cloud/img/instance-no-keypair.png) -Finally you need to compute the finger prints of the private keys you have configured in your PC: +Then it is necessary to find the corresponding **Private key**. In Linux and MacOS, private key are normally stored in the `.ssh` folder. You can use the same command as above to generate the fingerprint of the private key: ```sh -$ ssh-keygen -lf ~/.ssh/id_rsa -E md5 -3072 MD5:85:bb:dc:2e:65:5f:d7:8f:b3:d1:25:5c:7c:16:26:b5 someone@somewhere (RSA) -$ ssh-keygen -lf ~/.ssh/id_rsa.pub -E md5 -3072 MD5:85:bb:dc:2e:65:5f:d7:8f:b3:d1:25:5c:7c:16:26:b5 someone@somewhere (RSA) +$ ssh-keygen -lf .ssh/SGC-key +2048 SHA256:FjN0zrymP3mMZzTJ/UJrypmVVcH8Wgok9+JBiBhcvFc no comment (RSA) ``` -As you can see, the MD5 finger prints match. +The fingerprints must match. -!!! Info "Generate public from private" +!!! Info "Instance log" + You can also see the finger print of the key from the **Instance log**. Go to [instance page](https://pouta.csc.fi/dashboard/project/instances/) and click in the name of the instance. Then click in the Log tab. You will need to find the lines that begin with `ci-info`. This is the output of the cloud init script. - If you have lost the public key corresponding to a private key, it is possible to regenerate it: + ![Instance log](../../cloud/img/log-instance.png) + + You will be able to see the username, the file where the keys are configured and the list of finger prints of the configured keys. In the example above the output shows the `MD5` algorithm. + +If you do not find the corresponding private key, you will need to either [re-create the VM](../../cloud/pouta/launch-vm-from-web-gui.md)) with a ssh key pair that you own and control, or use our [How to rescue instances?](./pouta-openstack-rescue-mode.md) guide to be able to access the VM's disk and change the public key installed in the `authorized_keys` file. This last option is complex and it is only needed if you already have data and/or software in the VM's local disk. If you need to follow this second option, but are confused on how, please create a ticket with us at , we will help you step by step. + +### Are you offering the correct private key? + +The ssh client by default only offers the ssh keys that have a _standard name_ and are in the ~standard folder_ (`.ssh` in `$HOME`). If you happen to have a non standard file name or a non standard file location, you can use the `-i ` option to make sure that the key is being offered, and `-v` to increase the log output, to see when the client offers it. The command will be like: + +```sh +$ ssh -v -i .ssh/SGC-key ubuntu@193.166.200.200 2>&1 | grep SGC-key +debug1: identity file /home/galvaro/.ssh/SGC-key type 0 +debug1: identity file /home/galvaro/.ssh/SGC-key-cert type -1 +debug1: Will attempt key: /home/galvaro/.ssh/SGC-key RSA SHA256:FjN0zrymP3mMZzTJ/UJrypmVVcH8Wgok9+JBiBhcvFc explicit agent +debug1: Offering public key: /home/galvaro/.ssh/SGC-key RSA SHA256:FjN0zrymP3mMZzTJ/UJrypmVVcH8Wgok9+JBiBhcvFc explicit agent +``` - ```sh - $ ssh-keygen -yf id_rsa - ``` +If none of this works, please contact us at .