If I use pubkey auth from e.g.: an Ubuntu 11.04 how can I set the ssh client to use only password auth to a server? (just needed because of testing passwords on a server, where I default log in with key)
I found a way:
mv ~/.ssh/id_rsa ~/.ssh/id_rsa.backup
mv ~/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub.backup
and now I get prompted for password, but are there any offical ways?
Disable PubkeyAuthentication and also set PreferredAuthentications to password so that alternative methods like gssapi-with-mic aren't used:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password example.com
You need to make sure that the client isn't configured to disallow password authentication.
ssh -o GSSAPIAuthentication=no example.com
-o PubkeyAuthentication=no was sufficient in my case.
-o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no instead
PasswordAuthentication. In fact, I'm here because I wanted to test that disabling password auth worked correctly on my host.
Commented
Sep 8, 2018 at 14:39
I've discovered a shortcut for this purpose:
ssh user:@example.com
Note the colon (:) and the empty password after it.
mysql -u user -p
Commented
Apr 14, 2014 at 2:38
ssh client was blindly trying unrelated private keys to authenticate to a newly installed server and keep in being rejected due to the maximum amount of tries being reached without ever asking for the password. In order to force password authentication for this first connection, I had to to use -o PreferredAuthentications=password syntax, the colon trick having no noticeable effect. So while this trick may be worth to try, one should not rely on it as a consistent behavior.
Commented
Jun 13, 2015 at 6:26
As well as the method posted by scoopr, you can set per host options in your ssh client configuration file.
In your .ssh directory, create a file called config (if it doesn't already exist) and set the permissions to 600, you can then create sections which start with
host <some hostname or pattern>
and then set per host options after that, for example,
host bob.specific.foo
user fred
host *.home.example
user billy
port 9191
so you could have
host server.to.test
PubkeyAuthentication no
in that file, and then simply
ssh server.to.test
and the option will get picked up.
~/.ssh/config and added PubkeyAuthentication no
Commented
Jun 21, 2018 at 13:55
PubkeyAuthentication no note that the = sign is not required in ~/.ssh/config file
Commented
Aug 8, 2020 at 11:53
I recently needed this but none of the options above worked, ssh -v showed that the command-line options passed via the -o switch were over-ridden by the values specified in my ~/.ssh/config file.
What worked was this:
ssh -F /dev/null <username>@<host>
From the ssh man page:
-F configfile
Specifies an alternative per-user configuration file. If a
configuration file is given on the command line, the system-wide
configuration file (/etc/ssh/ssh_config) will be ignored. The default
for the per-user configuration file is ~/.ssh/config.
Credits to this answer: How can I make ssh ignore .ssh/config?
~/.ssh/config, the keys don't get used if I specify -F /dev/null. ssh -v output helps in this case, it clearly shows that because I have a catch-all entry in my ssh config for *, it elects to use the public key rather than respect the options passed via the -o switch as in the former answers.
~/.ssh/id_rsa as stated in manual page. These paths are hardcoded in the client. Just make sure you provide the correct user when testing.
I tried a few of these answers, but ssh -v kept showing my public keys getting pulled out of my home directory. However, specifying a bogus identity file did the trick for me:
ssh -i /dev/null host
I have to do this permanently (to work around the broken SSH server in an APC rack-mounted PDU — stay far away from these things if you care about security), so I ended up putting the option into my config file:
Host apc1 apc2
KexAlgorithms +diffie-hellman-group1-sha1
IdentityFile /dev/null
Permissions 0666 for '/dev/null' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored.
This is mentioned in a comment above, but I think it deserves to be its own answer.
For people receiving the Permission denied (publickey) error despite the other solutions here, the problem is likely that the server is set not to accept passwords. To change this, you need to get into the server (many services will allow you to access with a password via a virtual console on their management console) and:
nano /etc/ssh/sshd_config
Find PasswordAuthentication no and change it to yes, and uncomment it.
Run sudo service sshd restart (or sudo systemctl restart sshd if using systemd services)
Now try to log in, from a remote server, using one of the methods above, such as ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com
ssh -v you see the following line debug1: Authentications that can continue: publickey,password. If password is missing then none of the client side solutions on this page are going to help you.
@scoopr and @Halil Özgür answers didn't work for me.
This worked for me:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected]
Source: http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
I may be the only one in the world with this issue, but I had an ssh from another operating system running (choco ssh in Windows in a cygwin shell) seen via which ssh
So the solution was to
/usr/bin/ssh [email protected]
Note the full path. I did this after I had run cyg-get openssh
A little late to the party but I had to set the ControlPath option to none because I had an already established connection by the means of SSH connection sharing. So authentication was skipped instead of asking for a password. If it's same for you try following command line.
ssh -o ControlPath=none -o PreferredAuthentications=password example.org
And also be sure, there is no BatchMode=yes active in .ssh/config.
Otherwise you've got no chance, to get an interactive password prompt.
I tried just about everything suggested, including setting
PasswordAuthentication yes in /etc/ssh/sshd_config on the host, and lots of different arguments to ssh on the client, but still got Permission denied (pubkey).
Then I noticed, in /etc/ssh/sshd_config on the host, the line:
Include /etc/ssh/sshd_config.d/*.conf
and wondered what config that might be pulling in that seemed to be overriding PasswordAuthentication yes. I commented it out (and restarted sshd) - and now I can log in by doing simply ssh user@host!
Both the client and server are DigitalOcean Ubuntu "droplets" (servers), one of which is messed up because of an aborted do-release-upgrade, and I am just trying to migrate the data from the old one (the client) to the new one (the host). Because I only have access to a recovery console on the old server through the web from which I can't copy any text (e.g. a pubkey) and if I try to paste a pubkey into authorized_keys through the web the paste gets screwed up - and I really want to avoid typing in a pubkey by hand! - I have been trying to ssh to the new server using a password rather than a pubkey so found this question. Hopefully I can now start to transfer some data with scp or rsync. But I have had to comment out that Include to do it, which may not be a safe or desirable thing to do in the long term - I just did it to be able to migrate my data. So be careful! But it might help if you're in a similar situation.
In my case, I resolved the issue by using -i to specify the private key for the target VM. For example:
ssh -i /path/to/private_key <username>@<vm_ip>
