There are a few common reasons why your SSH command might not be working:
The command wasn't quite formatted correctly or had a typo.
The correct format is: ssh cyberian@<ip-address>
Here's an example: ssh cyberian@69.61.2.166
The username or ip address wasn't right.
Unless you set up a different user for yourself,
the default username for logging into a capsul will always be cyberian
Although we try our best to prevent this, in some situations the IP address of a capsul can change.
You can always get up-to-date IP address information for your capsuls at
https://capsul.org/console
Your SSH key is not configured correctly, or the key(s) you have configured don't match
the one you uploaded to capsul.org and assigned to your capsul when you created it.
The ssh command line application (OpenSSH Client) looks for keys to use in
~/.ssh.
It will try to use each key that it finds there until either one of them works, it runs out of keys to try,
or the server tells it "too many failed attempts" and closes the connection.
âšī¸ INFO: The tilde ~ here represents the user's home directory,
Linux: /home/username
Windows: C:\Users\username
MacOS: /Users/username
Also, note that as the .ssh folder's name starts with a period, it is a "hidden" folder.
This just means that your operating system's Graphical User Interface (GUI) will not display it by default.
All operating systems have a way to enable "Show Hidden Files" in the GUI, otherwise you can always access it via the
command line.
You can also specify an additional key file for ssh to try using with the -i flag.
For example: ssh -i /path/to/my/key_file cyberian@<ip-address>
You may also use the ssh-keygen command to generate a new key-pair, however this
won't help you if you are locked out of your existing capsul.
If you lost your SSH key permanently, sorry, but we cannot help you log into your capsul. Our policy is we
do not touch capsuls after they are created.
You happen to have a lot of SSH keys, and you are being trolled by the SSH client.
Like I mentioned, OpenSSH Client will try to use each key that it finds in ~/.ssh
until either one of them works, it runs out of keys to try, or the server tells it
"too many failed attempts" and closes the connection.
If you specify an additional key file for ssh to try using with the -i flag,
it won't try that one first, and there is no indication to the user about what is going on.
Personally I find this behavior of the OpenSSH client software to be obnoxious/toxic. Whatever.
It is what it is; it's probably too late to change it now.