Conchshell
ENRU
Download

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 some of the wrong parts fail quietly — a repeated directive is ignored, a weak cipher simply gets negotiated — and one kind fails for every host at once: a directive name OpenSSH does not know stops it reading the file.

Paste it here

Nothing is uploaded: the script on this page has no fetch, no XMLHttpRequest and no form submission in it, so your config stays in the browser because there is nowhere for it to go. The page carries no analytics either — open the network tab and watch: no request carries your config.

Or build one from scratch

Fill in what you know. Everything you leave empty is left out rather than guessed. No algorithm lists are written: OpenSSH's own defaults are the ones worth having, and a pinned list shuts out what later releases add. Every line in the block is understood by OpenSSH 7.3 and newer, and host keys are checked the default way — the first connection asks you to confirm the key, and a key that later changes stops the connection.

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 that replaces the default list with one that has 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 are errors, because OpenSSH stops reading the file at one, unless an IgnoreUnknown line above covers them. Old names and obsolete directives are noted rather than flagged. Also unbalanced quotes, empty values, and directives repeated inside one block — except the ones meant to repeat, such as IdentityFile and LocalForward.
  • macOS. UseKeychain is Apple's own directive: valid on a Mac, so it is noted rather than flagged, together with the IgnoreUnknown line that keeps the same file working on other systems.

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. A few keywords add up instead — IdentityFile and the forwarding lines among them — and the linter leaves those alone.

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 script on this page has no fetch, no XMLHttpRequest and no form submission in it. Open the network tab of your developer tools and paste a config: no request carries it anywhere.

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, no CBC ciphers and no key exchange on SHA-1, saved credentials sealed with XChaCha20-Poly1305 once you accept the vault, and host-key confirmation drawn by the operating system rather than by the application. Closing that confirmation without pressing a button counts as a refusal, on every platform; in version 2.16.0 and earlier, closing it on Windows or Linux, or pressing Back on Android, counted as trust, which 2.17.0 fixed. A few allowances for old servers remain: MACs without -etm and, at the end of the list, hmac-sha1 in both forms are still offered, and ssh-rsa host keys are still accepted.

Download Conchshell free

Read next