Category: commandline

Comparing SSH Key Algorithms: RSA, DSA, ECDSA, and Ed25519

Posted on by editor Posted in commandline, crypyography, linux, security, ssh, UncategorizedLeave a comment
Reading Time: 2 minutes

Secure Shell (SSH) authentication relies on key pairs to provide secure access to remote systems. Various key algorithms offer different levels of security, performance, and compatibility. In this article, we’ll compare four commonly used SSH key algorithms: RSA, DSA, ECDSA, and Ed25519.

1. RSA

RSA (Rivest-Shamir-Adleman) is one of the most widely supported and trusted SSH key algorithms. It provides strong security, especially with key lengths of 2048 bits or more.

Generating an RSA Key Pair

To create an RSA key pair, use the following command:

ssh-keygen -t rsa -b 2048 -C "your_email@example.com"

This command generates a 2048-bit RSA key pair and associates it with your email address.

Configuring the SSH Server for RSA Authentication

Modify the SSH server configuration file (/etc/ssh/sshd_config) with these settings:

PubkeyAuthentication yes
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

RSA is a robust and compatible choice for most SSH authentication needs.

2. DSA

DSA (Digital Signature Algorithm) was once a common choice but is now considered outdated due to its fixed 1024-bit key size, which is no longer considered sufficiently secure.

Generating a DSA Key Pair

ssh-keygen -t dsa -b 1024 -C "your_email@example.com"

Since DSA keys are limited to 1024 bits, they are less secure than other algorithms.

Configuring the SSH Server for DSA Authentication

Add the following lines to /etc/ssh/sshd_config:

PubkeyAuthentication yes
DSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

While DSA offers fast key generation, its security limitations make it less favorable for modern deployments.

3. ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) is designed for better performance with smaller key sizes compared to RSA while maintaining strong security.

Generating an ECDSA Key Pair

ssh-keygen -t ecdsa -b 256 -C "your_email@example.com"

ECDSA supports key sizes of 256, 384, and 521 bits, with 256-bit ECDSA offering a good balance of security and performance.

Configuring the SSH Server for ECDSA Authentication

Modify /etc/ssh/sshd_config to include:

PubkeyAuthentication yes

While ECDSA is more efficient than RSA, its security depends on the choice of an elliptic curve, and some concerns exist regarding its implementation.

4. Ed25519

Ed25519 is a modern elliptic curve algorithm designed for high security, fast performance, and resistance to side-channel attacks.

Generating an Ed25519 Key Pair

ssh-keygen -t ed25519 -C "your_email@example.com"

This command generates a compact and efficient key pair suitable for modern SSH authentication.

Configuring the SSH Server for Ed25519 Authentication

Edit /etc/ssh/sshd_config and ensure the following is present:

PubkeyAuthentication yes

Ed25519 is increasingly favored for its speed, security, and compact key sizes.

Choosing the Right SSH Key Algorithm

When selecting an SSH key algorithm, consider the following factors:

Algorithm Key Size Security Performance Compatibility
RSA 2048+ Strong Moderate Widely Supported
DSA 1024 Weak Fast Limited Support
ECDSA 256+ Strong High Moderate
Ed25519 256 Very Strong Very High Growing Adoption

Recommendations:

  • For general use, RSA (2048-bit or higher) is a reliable and widely supported choice.

  • For better performance, Ed25519 provides strong security with fast authentication.

  • For constrained environments, ECDSA offers efficiency but requires careful implementation.

  • Avoid DSA unless compatibility reasons require it, as it is outdated and less secure.

Conclusion

SSH key authentication is a critical aspect of securing remote access. While RSA remains a robust default, Ed25519 is gaining traction due to its efficiency and security. ECDSA is suitable for performance-sensitive environments, while DSA is largely obsolete. Selecting the right algorithm depends on your specific security, compatibility, and performance requirements.

Mastering SSH: The Power of SSH Keys Over Passwords

Posted on by editor Posted in commandline, unixLeave a comment
Reading Time: 2 minutes

SSH is how you log in to remote servers and devices.

Once upon a time, people used telnet, but telnet wasn’t encrypted, so it was replaced with the “Secure Shell”, or ssh.

Like telnet, it’s possible to log in using your username and password, but, if you’re still relying on passwords in this day and age, you’re leaving yourself vulnerable. SSH keys are  far superior in terms of security and once you have them set up, they’re much more convenient.

In this article, we’ll talk about why SSH keys are essential, how to create them, and best practices for ensuring their security.

Why SSH Keys are Non-Negotiable

  1.  Security You Can’t Ignore: SSH keys are significantly more secure than passwords. If you’re not using them, you’re leaving your systems exposed. They leverage public-key cryptography, making brute-force attacks virtually impossible.
  2. Effortless Access: Once configured, SSH keys enable password-less login, making your workflow more efficient and secure.
  3. Control and Flexibility: SSH keys can be easily managed, revoked, or rotated as needed, giving you unparalleled control over access. Keys can be easily managed, revoked, or rotated as needed, providing better control over access.

Creating SSH Keys

To create SSH keys, follow these steps:

  1. Generate a Key Pair: Use the ssh-keygen command to generate a key pair. You can specify the key length and encryption algorithm. For example, to create a 4096-bit RSA key:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
  1. Secure Your Private Key: Store your private key in a secure location, such as ~/.ssh/id_rsa, and set appropriate permissions:
chmod 600 ~/.ssh/id_rsa
  1. Copy the Public Key: Copy your public key to the remote server’s ~/.ssh/authorized_keys file:
ssh-copy-id user@remote_server

Best Practices for SSH Key Security

  1. Use Strong Passphrases: Protect your private key with a strong passphrase to prevent unauthorized access.
  2. Regularly Rotate Keys: Rotate your SSH keys periodically to minimize the risk of compromise.
  3. Limit Key Usage: Use separate keys for different servers and restrict key usage to specific commands or hosts.
  4. Monitor Key Usage: Monitor SSH key usage and access logs to detect any suspicious activity.

Don’t compromise on security; follow these steps to make sure your SSH keys are secure and well-managed.

Custom Command Namespace

Posted on by Jim O'Connell Posted in bash, commandline, unix, zshTagged , , Leave a comment
Reading Time: 2 minutes

If you are a moderate to heavy user of the command line in Linux or OS X, you’ll eventually build up a set of custom commands and shortcuts that you’ve written that help streamline your workflow. These are known as “aliases.”
Let’s say you frequently find yourself searching your shell history for a command you used before.
To display your command history, you simply type `history`in your shell, and every command you’ve typed streams by.
This is useful, of course, but most likely you want to know about a particular command you typed, so you might use shell redirection to pipe the output to another command, in this case, `grep` to find lines in history that are interesting to you. In this example, we’re looking for commands we’ve typed that involved the word “projects”:

$ history | grep projects
9627 cd projects/ansible_dexter
9641 cd ~/projects/ansible_dexter
9675 cd projects/ansible_dexter
9684 cd ~/projects/sendgrid-test
9696 source /home/jim/projects/sns_python/venv/bin/activate
9707 source /home/jim/projects/sns_python/venv/bin/activate
9713 cd ~/projects/
9863 cp -r ~/projects/sendgrid-test/lib64 .
9865 cp -r ~/projects/sendgrid-test/share .
9962 cd projects
9972 cd projects/terraform-provider-aws
9979 cd projects/terraform-provider-aws
10003 cd projects/terraform-provider-aws

For me, this is something I do so frequently that I wanted to shorten that command to the minimum number of characters. I settled upon `hg` for “history grep”, so I created an alias as a line in my `~/.zshrc` file: `alias hg=”history | grep”`
The `~/.zshrc` (or `~/.bashrc` if you use `bash` as your shell,) is a file that gets read every time you log in and sets up your preferred environment.
Perfect! Now, if I want to search history for commands that included a particular string, I can just type `hg projects` and I will get the above output.
Well, nearly perfect…

As it happens, hg is also a command used by the Mercurial Source Code Management system. This is not a big issue for me, as I’m a loyal Git user, but it presents an interesting dilemma:


How do I protect against command name collisions in my aliases?

You see, pretty much any alias you create has the potential to conflict with a command someone else has written, but where this gets even more complicated is when these commands are referenced from a script. Scripts should, however, only call external programs using the program’s full path, e.g.:/bin/ls instead of just ls
A blog post by Brandon Rhodes proposes an interesting solution:
Prepend all of your custom commands and aliases with a comma. Interestingly, a comma is just a normal letter to the shell, no different than renaming your command jimoconnell_hg, though a comma is of course much shorter.

I found this tip via the excellent ‘/r/commandline’ subreddit.

I haven’t used this technique much at all yet, so let me know what you think!

Create a Directory and `cd` into it in one command

Posted on by Jim O'Connell Posted in bash, commandline, unix, zshLeave a comment
Reading Time: 2 minutes

(This post is meant not only to describe a little shell function, but to introduce you to a powerful, yet simple concept.)

When I’m working with a command line, I will frequently need to create a directory and then immediately change to that directory.

Let’s say I’m starting a new project.  I will cd  into my ~/projects directory and then create a new folder where I’ll be putting my files.  After creating the new folder, I’ll generally need to `cd` to that folder.

cd ~/projects
mkdir foo
cd foo

My first thought was to write a little `alias` that combined the two operations, but aliases don’t really handle parameters well, so I wrote it as a shell function.  (I use the amazing `zsh` as my terminal shell, but this approach works just the same in bash.)
In the below example, the “$1” refers to the argument passed. “$2”, “$3” and so on also work. (Be sure to quote them!)

mgo () {
mkdir "$1"
cd "$1"
}
You can paste that into your shell and it will work for the duration of your session, but of course the better way of making it available is to put it in your `~/.zshrc` or whatever your ~/.profile file is in your shell of choice. For example, in OS X, you have to first create the file:

Start up Terminal.
Type "cd ~/" to go to your home folder.
Type "touch .bash_profile" to create your new file.
Edit .bash_profile with your favorite editor (or you can just type "open -e .bash_profile" to open it in TextEdit.

To use it, you need to have that file be re-read, so you can either close and re-open your terminal, `source` the file you just edited, or just paste the function in to have it be active for the current session.

I realize that this is an insanely simple thing to worry over, but so much of the Linux/Unix philosophy is about making things just a bit more efficient and shell functions are a very approachable way to craft your own customizations for efficiency.

Another Example:
If you’re a python programmer or student, you are probably aware of venv, the virtual environment for Python that create lightweight Virtual Environment on a directory-by-directory basis. If you have, you know that each time you move to a project directory, you need to type `./venv/bin/activate` to set up the environment. A clever function I found a while back takes over the `cd` command to check for a virtual environment and activate it if it exists:
cd () {
builtin cd $1
if [[ -d ./venv/bin ]]
then
source ./venv/bin/activate
fi
if [[ -d ./bin ]]
then
source ./bin/activate
fi
}
Both of the above examples are simple, but useful. Please leave a comment below if you know of any other good examples, or can think of a good use case for a function.