Check your ~/.ssh/config

Paste a config and get back the lines worth changing: ciphers OpenSSH has been phasing out, MACs built on MD5 and SHA-1, a key exchange with no curve25519 in it, host-key checking turned off. Every check runs in this tab.

The point is not that your config is wrong. Most are fine. The point is that the parts which are wrong fail quietly — a repeated directive is ignored, a typo does nothing, a weak cipher simply gets negotiated.

Paste it here

Nothing is uploaded. This page makes no network request at all once it has loaded — open the network tab and watch. It carries no analytics either, so there is nothing here to argue about: your config stays in the browser because there is nowhere for it to go.

Or build one from scratch

Fill in what you know. Everything you leave empty is left out rather than guessed, and the algorithm lines are filled in with the defaults worth having.

What it checks, and what each finding means

  • Legacy ciphers. 3des-cbc, arcfour, blowfish-cbc and anything else ending in -cbc. CBC mode in SSH has a long history of padding-oracle work behind it, and OpenSSH stopped offering these by default years ago.
  • Weak MACs. Anything built on MD5 or SHA-1, and umac-64. Also flagged, at a lower level: MACs without the -etm@openssh.com suffix, which compute the tag before encryption rather than after.
  • Key exchange. A KexAlgorithms line with no curve25519-sha256 and no ecdh-sha2-nistp521 in it, and any exchange still built on SHA-1.
  • Host-key checking. StrictHostKeyChecking set to no is an error; accept-new is a warning; UserKnownHostsFile pointed at /dev/null is an error, because it removes the memory that makes a key swap detectable.
  • Passwords and agents. PasswordAuthentication yes and ForwardAgent yes, both as warnings — they are choices, not mistakes, but they are worth making on purpose.
  • Structure. Unknown directives, unbalanced quotes, empty values, and directives repeated inside one block.

The finding people are most surprised by

A repeated directive. OpenSSH reads a block top to bottom and keeps the first value it sees for each keyword; later ones are discarded without a word. So a Port line added at the bottom of a block that already has one does nothing at all.

This is the usual explanation when someone says they changed a setting and it did not take effect. The linter reports which line actually won.

Questions people actually ask

Is my .ssh/config sent to a server?

No. The checks run in your browser. The page loads one script and never makes a request after that — there is no fetch, no XMLHttpRequest and no form submission in it. Open the network tab of your developer tools and paste a config: you will see nothing leave.

What is a safe Ciphers order?

chacha20-poly1305@openssh.com, then aes256-gcm@openssh.com, aes128-gcm@openssh.com and aes256-ctr. The AEAD ciphers come first because they authenticate as they encrypt. Anything ending in -cbc belongs at the end or nowhere.

Is chacha20-poly1305 safe?

Yes, and it is the OpenSSH default for good reason. It is fast without hardware AES support, and it carries its own integrity check, so it needs no separate MAC. If your config lists it in Ciphers, the MACs line does not apply to those sessions at all.

Do I need to set Ciphers at all?

Usually not. OpenSSH defaults today are good, and pinning a list means you inherit that list for years. Pin one only when a standard obliges you to, and revisit it when you upgrade OpenSSH.

What does StrictHostKeyChecking=accept-new do?

It accepts the key of a host you have never seen without asking, and still refuses a host whose key has changed. That is a reasonable trade for throwaway machines and a poor one for servers you care about, which is why the linter marks it as a warning rather than an error.

Why does the linter flag a repeated directive?

Because OpenSSH takes the first value in a block and ignores the rest. A second Port line further down does nothing, which is the usual reason people say they changed a setting and it did not apply.

Where this comes from

These are the same checks that shaped how Conchshell connects: Ed25519 host keys preferred, curve25519-sha256 key exchange, credentials sealed with XChaCha20-Poly1305 under an Argon2id key, and host-key confirmation drawn by the operating system rather than by the application.

Download Conchshell free

Read next