January 29, 2025

Fixing “Load Key Error in Libcrypto” Caused by CRLF Line Endings

🔍 Introduction

Luca Berton

2 min read

🔍 Introduction

If you've encountered the error:

load key "my.key": error in libcrypto

when trying to use SSH, OpenSSL, or other cryptographic tools, you might be dealing with an incorrect file format. A common but overlooked cause is wrong line endings — specifically, your key file might use CRLF (Carriage Return + Line Feed) instead of LF (Line Feed).

This issue typically arises when a key file is edited or transferred between Windows and Unix/Linux systems. Fortunately, it's an easy fix.

🚨 Why Does This Error Happen?

Cryptographic tools like OpenSSH and OpenSSL expect keys to use LF (\n) line endings, which are standard on Unix/Linux systems. However, if a key file is created or edited on Windows, it may have CRLF (\r\n) line endings, causing OpenSSL's libcrypto to misinterpret the key format.

Common scenarios where this can happen:

  • Editing the key in Notepad or another Windows-based editor.
  • Transferring the key file between Windows and Linux/macOS.
  • Copying the key from a Windows terminal without proper formatting.
  • Cloning a Git repository with incorrect line-ending settings.

🔧 How to Detect CRLF Line Endings in Your Key File

Before fixing the issue, you can check whether your key file contains CRLF (\r\n) or LF (\n) endings.

Option 1: Using file Command (Linux/macOS)

Run the following command:

file my.key
  • If it returns ASCII text, your file likely has LF (correct).
  • If it returns ASCII text, with CRLF line terminators, your file has CRLF (incorrect).

Option 2: Using cat with od (Linux/macOS)

Run:

cat -A my.key
  • If you see ^M at the end of lines, it means the file uses CRLF endings.

Option 3: Using Notepad++ (Windows)

  1. Open my.key in Notepad++.
  2. Look at the bottom-right corner — if it says Windows (CRLF), your file has incorrect endings.
  3. Convert it to Unix (LF) using Edit → EOL Conversion → Unix (LF).

✅ How to Fix: Convert CRLF to LF

If your key file has CRLF line endings, you need to convert it to LF.

1️⃣ Using dos2unix (Linux/macOS)

The easiest way to fix line endings:

dos2unix my.key

If dos2unix is not installed, you can install it:

sudo apt install dos2unix   # Ubuntu/Debian
brew install dos2unix       # macOS (Homebrew)

2️⃣ Using sed (Linux/macOS)

Convert CRLF to LF using sed:

sed -i 's/\r$//' my.key

3️⃣ Using tr (Linux/macOS)

Manually remove carriage returns:

cat my.key | tr -d '\r' > fixed.key
mv fixed.key my.key

4️⃣ Using vim (Linux/macOS)

Open the key file in vim:

vim my.key

Then type:

:set ff=unix
:wq

5️⃣ Using Notepad++ (Windows)

  1. Open the file in Notepad++.
  2. Click Edit → EOL Conversion → Unix (LF).
  3. Save the file.

🛠 Preventing This Issue in the Future

To avoid running into this problem again:

  • Use Unix-compatible text editors like VS Code, Vim, or Nano instead of Windows Notepad.
  • Use Git settings to prevent CRLF conversion:
git config --global core.autocrlf input
  • This ensures files are stored with LF but checked out correctly on Windows.
  • Transfer files carefully using scp or rsync to avoid modifications.

🚀 Final Steps: Verify and Use the Fixed Key

Once you've converted the key to LF, check it again:

file my.key

It should now say ASCII text without CRLF mentioned.

Now, try loading the key:

ssh -i my.key user@server

or, for OpenSSL:

openssl rsa -in my.key -text -noout

If no errors appear, the problem is fixed! 🎉

🔚 Conclusion

The "Load key error in libcrypto" issue is often caused by incorrect CRLF line endings, which confuse OpenSSL and OpenSSH. By converting the file to LF format, you can quickly resolve the error and ensure smooth authentication.

By following the detection, conversion, and prevention steps outlined in this guide, you'll avoid future issues when handling private keys. 🚀

Have you encountered similar SSH or OpenSSL key issues? Let me know in the comments! 💬