NEVER SEND YOUR PRIVATE KEY FILE. TREAT IT LIKE A PASSWORD.
So, Eglide wants to strive for security and avoids bruteforce attack. For that, we require SSH keys for authentication.
Keys are convenient too, and can be use for your Git repositories or to connect to a lot of servers without typing a password each time.
There are composed of two files:
- The private part, you keep secret for yourself
- The public part, you communicate to each service you want to connect to with this key
Quick procedure if you’re on an UNIX system (Linux, Mac OS X, FreeBSD, etc.)
This is really easy, open a console/terminal and run ssh-keygen. Your key will be stored in your .ssh/ folder.
$ ssh-keygen -t ed25519
[You can accept the default values]
$ cat ~/.ssh/id_ed25519.pub
Procedures for other systems
On Android, users report success with ConnectBot (an open soruce SSH client) but struggle with JuiceSSH (the free version cripples some keys features).
If you use a Chromebook, you can generate keys elsewhere and import them into Secure Shell or mosh.
On Windows, PuTTY provides a software called PuTTYgen to generate a key. Pro tip; if you’re stuck, it’s just PuTTYgen waits you move the mouse to generate random values used as a source to create a more random key.
Tutorial can be found here:
Why SSH keys matter?
Attackers non stop scans all the datacenter IP ranges and tests SSH connections with a list of generic accounts like test/test or admin/admin.
With keys, these attacks don’t work, as there is no more password sent to the server to try to connect. Instead, the server and your client will negotiate authentication through a key. Keys are so long you can’t create bruteforce attack with them.
You know, in the past, there were an user called Charlie with an account of one of our previous servers, Grip. Charlie was the given name of the user. One day, we were monitoring bruteforce attacks and surprise, a connection was made to the charlie account.
With SSK keys, no charlie/charlie, charlie/123456 or other simple passwords are possible.