SSH unknown option errors occur when an invalid or mistyped command-line flag is passed to the ssh command. This commonly happens due to typos, using double-dashes instead of single-dashes, or trying to use options that don't exist in your SSH version.
The SSH client strictly validates all command-line options before attempting to connect. When you pass an unrecognized flag (like a typo or a non-existent option), SSH immediately returns an "unknown option" error and exits without trying to connect. The error message typically includes the problematic option to help you identify the issue. Unlike some command-line tools that accept double-dash options (--), SSH uses single-dash options exclusively.
Review the exact command you're running and look for misspelled options:
# WRONG - typos in option
ssh -prot 22 [email protected]
ssh -kep ~/.ssh/id_rsa [email protected]
# CORRECT - proper option names
ssh -p 22 [email protected]
ssh -i ~/.ssh/id_rsa [email protected]Common typos:
- -prot should be -p (port)
- -kep or -key should be -i (identity file)
- -usr should be -l (login username)
- -hosy should be understood as hostname (not an option)
SSH options must use a single dash (-), not double-dashes (--):
# WRONG - double-dashes not supported by ssh
ssh --port 22 [email protected]
ssh --identity ~/.ssh/id_rsa [email protected]
# CORRECT - single dash
ssh -p 22 [email protected]
ssh -i ~/.ssh/id_rsa [email protected]SSH does not support GNU-style long options. Some tools support both -p and --port, but SSH only accepts the short form.
Check what options are available in your SSH version:
ssh --helpOr view the full manual:
man sshLook for your option in the list. If it doesn't appear, either:
1. You have a typo
2. The option doesn't exist in your SSH version
3. You're using the wrong command (scp, sftp, ssh-keygen, etc.)
Some SSH options are only available in newer versions of OpenSSH. Check your version:
ssh -VIf you're trying to use an option that requires a newer version:
- Upgrade OpenSSH if possible
- Or use the -o option with the older equivalent:
# Instead of: ssh -J jumphost user@target
# On older SSH: ssh -o ProxyCommand="ssh -W %h:%p jumphost" user@targetDifferent SSH tools use different options. A common mistake:
# WRONG - scp uses -P (capital) for port, not -p
ssh -P 2222 [email protected]
scp -p file.txt [email protected] # -p means preserve permissions
# CORRECT - ssh uses -p (lowercase) for port
ssh -p 2222 [email protected]
# CORRECT - scp uses -P (capital) for port
scp -P 2222 file.txt [email protected]Remember:
- ssh uses lowercase -p for port
- scp and sftp use uppercase -P for port
If you're connecting without explicit options, check your config files:
cat ~/.ssh/config
cat /etc/ssh/ssh_configRemove any deprecated or invalid options. Example:
# BAD - unknown options
Host myhost
Hostname host.example.com
User ubuntu
IdentityFile ~/.ssh/id_rsa
UnknownOption value
# GOOD - only valid options
Host myhost
Hostname host.example.com
User ubuntu
IdentityFile ~/.ssh/id_rsa
Port 22
StrictHostKeyChecking accept-newIf you need to pass options that might not be recognized, use the -o flag to test:
# -o allows passing options in config file format
ssh -o "Port=2222" [email protected]
ssh -o "IdentityFile=~/.ssh/id_rsa" [email protected]
# Multiple -o flags work too
ssh -o "Port=2222" -o "StrictHostKeyChecking=no" [email protected]This way, if the option is invalid, you get a clearer error message from the config parser rather than the command-line parser.
Advanced troubleshooting:
SSH Config File Format vs Command Line: SSH config files use a different syntax than command-line options. Config files use Port 22 while command line uses -p 22. Common mistake: using --Port 22 on the command line (wrong).
Case Sensitivity: SSH options are case-sensitive on the command line. -P (uppercase) is different from -p (lowercase). However, in SSH config files, option names are case-insensitive.
Option Order Matters for Some Tools: While ssh is generally flexible about option order, some SSH wrappers or scripts may require options before the hostname. Try moving options to the front if you get unexpected errors.
Escaping in Scripts: If running SSH from scripts (bash, Python, etc.), be careful with shell escaping. Quotes and special characters can affect how options are parsed:
# In bash script - careful with quotes
ssh -i "~/.ssh/id_rsa" user@host # May not expand ~
ssh -i "$HOME/.ssh/id_rsa" user@host # Better - expands variableEnvironment Variables: Some SSH behavior can be controlled via environment variables instead of command-line options. Check man ssh_config for options that can also be set in config files.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH