DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

Using ECDSA SSH Keys: Generate, Install, and Troubleshoot

#productivity #tutorial #devops #beginners

Need an ECDSA key because a server or policy requires one? OpenSSH can generate one with ssh-keygen, but a working login also depends on installing the matching public key for the right account and using a curve the server accepts.

Generate a key pair

Run this in a terminal:

ssh-keygen -t ecdsa -b 256 -C "your_email_or_label" -f ~/.ssh/id_ecdsa
Enter fullscreen mode Exit fullscreen mode

The options mean:

  • -t ecdsa selects the ECDSA key type.
  • -b 256 requests the 256-bit curve.
  • -C adds a human-readable comment.
  • -f chooses the output filename.

OpenSSH supports ECDSA with the NIST P-256, P-384, and P-521 curves. The default size for ssh-keygen -t ecdsa is 256 bits. To request another supported curve, use -b 384 or -b 521. The P-521 curve has a 521-bit field size; its name is not a typo.

Choose a passphrase when prompted to encrypt the private-key file at rest. A passphrase helps protect the key if someone obtains that file, but it does not replace access controls on the server. If the output path already exists, stop and check what the file is before proceeding—you may not want to overwrite an existing key.

The command creates two files:

~/.ssh/id_ecdsa      # private key
~/.ssh/id_ecdsa.pub  # public key
Enter fullscreen mode Exit fullscreen mode

Keep the private key private. The .pub file is the one you can install on a server or add to a service that accepts SSH keys.

Install the public key for the right account

If you can already log in with a password and the server supports ssh-copy-id, you can install the public key with:

ssh-copy-id -i ~/.ssh/id_ecdsa.pub user@server.example
Enter fullscreen mode Exit fullscreen mode

Replace the example username and hostname with the account and server you actually use. The key must be installed for the remote account you intend to access. If ssh-copy-id is unavailable, use the server provider's supported process or append the contents of the .pub file to that account's ~/.ssh/authorized_keys file.

For a Git hosting service, add the public key through that service's SSH key settings. Don't upload or paste the private key.

Installing a key is not enough by itself: public-key authentication must be allowed, and the server or service must accept the key type and curve you generated.

Test the key explicitly

Tell SSH which private key to try:

ssh -i ~/.ssh/id_ecdsa user@server.example
Enter fullscreen mode Exit fullscreen mode

On Windows PowerShell, an example key path is:

$env:USERPROFILE\.ssh\id_ecdsa
Enter fullscreen mode Exit fullscreen mode

If the key has a passphrase, you can add it to an SSH agent so client programs can use it during your session without prompting you each time:

ssh-add ~/.ssh/id_ecdsa
Enter fullscreen mode Exit fullscreen mode

Enter the passphrase when prompted. If ssh-add cannot connect to an agent, the current shell may not be connected to one; agent setup varies by operating system and shell.

For repeated connections, you can put the hostname, username, and identity file in ~/.ssh/config:

Host my-server
  HostName server.example
  User user
  IdentityFile ~/.ssh/id_ecdsa
Enter fullscreen mode Exit fullscreen mode

Then connect with:

ssh my-server
Enter fullscreen mode Exit fullscreen mode

If authentication fails

A Permission denied (publickey) response means the server did not accept an offered public key for that login. Check the likely causes first:

  • The public key installed on the server matches the private key you selected.
  • The username and hostname are correct, and the key is installed for that username.
  • The server accepts ECDSA and the curve you chose.
  • The key path is correct and the client can read the private-key file.

To see more about which identity the client offers and where the connection fails, add verbose output:

ssh -v -i ~/.ssh/id_ecdsa user@server.example
Enter fullscreen mode Exit fullscreen mode

A local error reading the private key is different from the server rejecting a key. The verbose output can help distinguish those problems.

When ECDSA is the right choice

ECDSA is a valid SSH key type, but it is not automatically the best choice for every new setup. Use it when the target service, server, or organizational policy calls for it, and confirm which curves it supports.

Other key types may suit other environments. Ed25519 is an option when both sides support it and policy permits it; it may not work with older implementations or meet some FIPS-regulated requirements. RSA can be necessary for compatibility, but the accepted key size and signature behavior depend on the environment. In a FIPS-regulated setup, verify the requirements of the specific validated module and policy rather than assuming a key type alone establishes compliance.

One final naming distinction: ssh-keygen -t ecdsa creates a user authentication key pair. An ECDSA host key, often stored on a server under a name such as /etc/ssh/ssh_host_ecdsa_key, identifies the server to clients. It is managed on the server and is not your personal login key. ecdsa-sk is also a separate, security-key-backed credential type—not another name for an ordinary software-based ECDSA key.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)