This blog post explains how to force the OpenSSH client to log in with a specific password or public key. This is useful if some of the SSH client config files (/etc/ssh/ssh_config, /etc/ssh/ssh_known_hosts, /etc/ssh/ssh_known_hosts2, ~/.ssh/config, ~/.ssh/known_hosts) or the ssh-agent are in a broken state, and you want to try whether login works independently of these client-side issues.
Run this command to log in, substituting the "${...}" values:
SSH_AUTH_SOCK= /usr/bin/ssh -F /dev/null \
-o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no \
-p "${PORT}" -i "${KEYFILE}" -- "${USERNAME}"@"${HOST}"
Usage notes:
- To use the default port (22), drop the
-p "${PORT}". - To use password login instead of public key login, drop the
-i "${KEYFILE}". - If you don't know where your public key file is, try
-i ~/.ssh/id_rsa - To use the same username as your local client username, drop the
"${USERNAME}"@.
How it works:
SSH_AUTH_SOCK=disables the ssh-agent for this connection.- Spelling out
/usr/bin/sshmakes sure that shell aliases, shell functions and strange directories in$PATHhave no effect on which SSH client is used. -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/nullmakes existing host keys inknown_hostsfiles to be ignored, thus the connection will be established even if old or incorrect host keys are saved there. Please note that this also makes it impossible to detect a man-in-the-middle attack, so attackers may be able to steal your password if you use a password to log in; also attackers can steal the contents of your session (commands and their results).-o StrictHostKeyChecking=nosuppresses the prompt to add the host key to theknown_hostsfiles.
