676

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?

Greg Dubicki
  • 372
LanceBaynes
  • 40,135
  • 97
  • 255
  • 351

12 Answers12

1049

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.

Cristian Ciupitu
  • 2,510
scoopr
  • 10,614
  • 7
    I needed to enforce the password prompt to appear in an environment where Kerberos was used for automated authentication, and a similar command worked for me in that specific situation: 
    `ssh -o GSSAPIAuthentication=no example.com`
    – IllvilJa Aug 13 '13 at 10:56
  • 50
    Nice. Only -o PubkeyAuthentication=no was sufficient in my case. – mivk Sep 04 '16 at 10:04
  • 1
    @mivk same here. – Adam Mackler Sep 13 '16 at 14:12
  • 14
    to ssh into a friend osx laptop, I had to use: -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no instead – guido Sep 17 '16 at 15:23
  • @guido: Same here. I bet it's not OS X related, though, but rather has to do with OpenSSH versions. – Luis Casillas Oct 18 '16 at 22:11
  • my 5cent. I have normal sshd on port 22, that accept passwords and PK. Firewall is configured to allow only specific IP addresses on port 22. Then i have second sshd on different port that accept only PK. – Nick Jul 10 '18 at 09:39
  • 24
    This doesn't work for me. It keeps saying: Permission denied (publickey). and never offers a password prompt. – reinierpost Jul 27 '18 at 12:18
  • 20
    @reinierpost that's likely because the ssh host has disabled PasswordAuthentication. In fact, I'm here because I wanted to test that disabling password auth worked correctly on my host. – RubberDuck Sep 08 '18 at 14:39
  • 2
    @reinierpost I had the same problem as you, and changing password with keyboard-interactive make it work, as spotted by guido : ssh -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no me@example.com – tobiasBora Sep 15 '18 at 17:19
  • The host had enabled PasswordAuthentication but I never tried keyboard-interactive. I don't recall where I had the problem, but I will bear this in mind, thanks. – reinierpost Sep 16 '18 at 16:24
  • Make sure you've enabled password access on the server: https://serverpilot.io/docs/how-to-enable-ssh-password-authentication/ – Finesse Mar 02 '20 at 10:14
  • I was getting Permission denied (publickey,password) which seemed to suggest that a password should be accepted, but none of the options above would actually cause ssh to prompt me for the password. Turns out it was a configuration error in ~/.ssh/config that was setup to use key authentication. Who knew this prevents all command line options from taking effect! – Jonathan Cross Mar 31 '20 at 10:44
  • @tobiasBora: I know password authentication is enabled, as it works for other accounts on the same server. @Finesse: this is not my server and I cannot even read its sshd_config. – reinierpost Sep 28 '20 at 13:49
  • 1
    I had to add another option: -o UserKnownHostsFile=/dev/null. Otherwise it may bail out with an error WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED. This may happen for example if remote host has a system booted different to the one you had originally key generated for. – Hi-Angel May 27 '21 at 09:51
  • https://superuser.com/a/1684034/329627 this was the correct solution for me. ssh -o "PasswordAuthentication yes" user@host – Summer-Sky Feb 11 '23 at 21:57
258

I've discovered a shortcut for this purpose:

ssh user:@example.com

Note the colon (:) and the empty password after it.

Anthon
  • 79,293
Halil Özgür
  • 2,771
  • 2
    Is this documented somewhere? – Faheem Mitha Apr 13 '14 at 22:23
  • 5
    No documentation yet. Actually, I've skimmed through the OpenSSH source code to no avail (its parsing stage is rather cryptic and it's morning here :)). My initial motivation: many clients prompt for a password if you give an empty password, e.g. mysql -u user -p – Halil Özgür Apr 14 '14 at 02:38
  • I don't expect another answer will come up I like better, but I will leave the bounty open for a bit so this Q gets more attention. After reviewing this answer, I originally posted on the chat site to draw some attention to it, which got you some upvotes. But I hope the bounty gets you some more attention as well. – Anthon Apr 14 '14 at 11:51
  • Thanks. I hope that this is not very fragile and meets the expectations. By the way, the question Why doesn't the ssh command follow RFC on URI? and the answers there seem relevant.

    I guess the modus operandi here is that OpenSSH sees the empty password, having discovered that the remote sshd doesn't allow empty passwords, prompts the user for one, or something like that. I'm hoping to take another shot at the source code when I have some time.

     – Halil Özgür Apr 14 '14 at 13:25
  • 1
    Note that everything after the colon seems to get stripped (it doesn't help that the whole string gets displayed on the password prompt, though), ssh user:foobar@example.com works just as well. I don't particularly like the way this behaves but have an upvote for finding out :-) – Adrian Frühwirth Apr 14 '14 at 14:27
  • Beautiful, you just hacked the parser. – MGP Dec 08 '14 at 17:57
  • 82
    This does not seem to work anymore, at least not in my case. 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. – WhiteWinterWolf Jun 13 '15 at 06:26
  • @WhiteWinterWolf indeed, the parser must have changed in the meantime. – Halil Özgür Jun 13 '15 at 12:08
  • It doesn't always work for me. Depending on the server, sometimes it does, sometimes no. – ItalyPaleAle Jan 17 '16 at 18:59
  • 3
    @Qualcuno as WhiteWinterWolf said, it doesn't work on some platforms anymore, unfortunately. – Halil Özgür Jan 17 '16 at 23:04
  • 1
    Would be nice to have the actual SSH versions where this used to work. – kaiser Mar 10 '16 at 14:34
  • @kaiser I have an older system at work behind the firewall. Still works on ssh client version OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29. – Ogre Psalm33 Sep 26 '17 at 11:19
  • 3
    Make sure that you don't have PasswordAuthentication no on your ssh_config file! – Braiam Jul 29 '18 at 22:43
  • I must say this is the best answer ever to this question, so simple and perfectly working. – AboElnouR Jul 23 '22 at 14:18
  • 1
    What an awesome shortcut! Still works for me in 2022. FYI 'ssh -V' returns: "OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n 15 Mar 2022". – Jeremy Davis Dec 08 '22 at 05:43
53

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.

EightBitTony
  • 21,373
22

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?

Community
  • 1
adeelx
  • 337
  • 2
    this does not answer the question. You can always have the keys stored in agent and your approach will not prevent client from using them. – Jakuje Jan 22 '16 at 15:46
  • Hm, how would one remediate that issue as well as the one I mentioned in my answer? – adeelx Jan 22 '16 at 15:49
  • 2
    Also if you have the keys in standard location (as in the question), they will be used regardless the config is present or not. I would go with one of the methods mentioned in the first answers. – Jakuje Jan 22 '16 at 15:54
  • Not quite true, I just tested it out on my Lubuntu 14.04 and even though I have my keys in the standard location ~/.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. – adeelx Jan 22 '16 at 15:58
  • 1
    Standard location is ~/.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. – Jakuje Jan 22 '16 at 16:02
  • My bad, ~/.ssh/id_rsa is what I meant -- just re-tested it out though -- just using the command I mentioned above, I'm able to SSH into my server without the need for any other command line options of the older answers. – adeelx Jan 22 '16 at 16:08
  • As a short-cut to overriding the .ssh/config file I often use -F., pointing the ssh client to use . - which means the current directory rather than a specific file. You'd think that would be invalid but it accepts it and it's less to type than -F /dev/null. – Gibbsoft Jul 20 '18 at 06:51
11

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
Cristian Ciupitu
  • 2,510
miken32
  • 466
  • 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. – rubo77 Sep 09 '21 at 17:22
  • This works perfectly and is far easier (both to remember and less typing!) than the top voted answer. Sad how many other answers here are blatantly wrong / out dated. – jmc Sep 22 '22 at 11:48
  • 1
    This is great to test if password authentication works (i.e. if you have the right password), despite having a key file locally. So you can test if you can still access the server whenever you lose your key somehow. – Martin Braun Sep 30 '22 at 19:09
9

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:

  1. nano /etc/ssh/sshd_config

  2. Find PasswordAuthentication no and change it to yes, and uncomment it.

  3. Run sudo service sshd restart (or sudo systemctl restart sshd if using systemd services)

  4. 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

drognisep
  • 103
Andrew
  • 191
  • Nice, from point 1 to 3 worked for me. (Just with small change: sudo systemctl restart sshd) – Mauricio Toledo Jan 19 '21 at 19:36
  • When you look at the output generated by 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. – Martin Oct 19 '23 at 11:12
3

@scoopr and @Halil Özgür answers didn't work for me.

This worked for me:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@example.com

Source: http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

shrx
  • 445
  • 4
  • 6
  • 15
    The question is about client authentication by password. This answer is about checking if the servers host key matches one in known hosts. In effect it is answering a different question – Anigel Sep 03 '15 at 10:48
3

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 user@example.com

Note the full path. I did this after I had run cyg-get openssh

Jonathan
  • 1,565
3

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

thomas
  • 479
2

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.

Gunnar Tiedt
  • 21
0

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.

drkvogel
  • 151
-1

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>
Cristian Ciupitu
  • 2,510
Chance
  • 99