584

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?

9 Answers 9

906

I recently needed this too, and came up with this:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com

You need to make sure that the client isn't configured to disallow password authentication.

14
  • 6
    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, 2013 at 10:56
  • 43
    Nice. Only -o PubkeyAuthentication=no was sufficient in my case.
    – mivk
    Sep 4, 2016 at 10:04
  • 13
    to ssh into a friend osx laptop, I had to use: -o PreferredAuthentications=keyboard-interactive -o PubkeyAuthentication=no instead
    – guido
    Sep 17, 2016 at 15:23
  • 18
    This doesn't work for me. It keeps saying: Permission denied (publickey). and never offers a password prompt. Jul 27, 2018 at 12:18
  • 16
    @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 8, 2018 at 14:39
225
+50

I've discovered a shortcut for this purpose:

ssh user:@example.com

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

13
  • 1
    Is this documented somewhere? Apr 13, 2014 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 Apr 14, 2014 at 2:38
  • 68
    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. Jun 13, 2015 at 6:26
  • 3
    @Qualcuno as WhiteWinterWolf said, it doesn't work on some platforms anymore, unfortunately. Jan 17, 2016 at 23:04
  • 2
    Make sure that you don't have PasswordAuthentication no on your ssh_config file!
    – Braiam
    Jul 29, 2018 at 22:43
47

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.

5
  • 2
    Thanks for this answer. I created an entry in my ~/.ssh/config and added PubkeyAuthentication no Jun 21, 2018 at 13:55
  • 2
    Doesn't work for me. Jul 27, 2018 at 12:19
  • This solved my issue. Mar 31, 2020 at 10:45
  • 1
    The config actually needs to be PubkeyAuthentication no note that the = sign is not required in ~/.ssh/config file Aug 8, 2020 at 11:53
  • This is what finally worked today! Spent far too much time on other options. I think partially because my server is older and cursed 😂 and I have no clue how I set it up in the past since it doesn't seem to want to honor anything in the authorized_keys on the server.
    – CTS_AE
    Nov 6, 2020 at 20:49
17

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?

7
  • 1
    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, 2016 at 15:46
  • Hm, how would one remediate that issue as well as the one I mentioned in my answer?
    – adeelx
    Jan 22, 2016 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, 2016 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, 2016 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, 2016 at 16:02
6

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
1
  • 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 9, 2021 at 17:22
4

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

1
  • Nice, from point 1 to 3 worked for me. (Just with small change: sudo systemctl restart sshd) Jan 19, 2021 at 19:36
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

1
  • 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 3, 2015 at 10:48
2

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

1
  • This fixed the problem for me, thanks
    – franzisk
    Mar 1, 2021 at 11:39
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.