Home / server / Questions / 40110
Accepted
p.campbell
Asked: 2009-07-14 11:33:55 +0800 CST

SSH/SCP with no password not working?

  • 772

Consider this scenario: an admin configured a public/private key pair to use when rsync'ing files between servers to avoid the password prompt. This setup works great.

Then when attempting to use SSH/SCP, the system prompts for a password.

Question: why is this the case if rsync is working properly?

ssh rsync scp

9 Answers

  1. Best Answer

    How have you configured the server to allow your key? By putting your public key in the .ssh/authorized_keys on the server? If that is the case, it should work. Are you using the same usernames (both remote and local) when you use ssh/scp as when you use rsync?

    Oh, and btw, this question should be asked at serverfault.com instead I think.

    • 2

  2. The other thing that I find helpful is to run the server in debug mode on a different port. Sometimes the server side will complain and the client doesn't really give you a good clue why.

    Server side: /usr/sbin/sshd -Dedd -p 2222

    Client side: ssh -vv -p 2222 server

    • 1

  3. Thank you very much, I was able to solve the problem using config item

    ~/.ssh/config PasswordAuthentication no

    and setting up the permissions 700 for .ssh directory and 600 authorized_keys.

    This post was very helpful.

    thanks a lot.

    • Amar.
    • 1

  4. See the section of the ssh man page on Authentication. Some possibilities:

    • You client may be defaulting to password authentication
    • Your identity file doesn't use the default name (i.e. id_rsa see options for -i)
    • You're encountering one of the configuration issues noted in the Authentication section
    • 0

  5. Check the auth logs (probably one of /var/log/secure or /var/log/auth.log) on the server -- they're usually a bit more verbose than the client (even if you add -vvv to the ssh command).

    Far and away, the most common thing I've seen cause this is permissions on files SSH referenced due to StrictModes being enabled..

    I'd recommend adding this to ~/.ssh/config to prevent ever being asked for a password. It won't magically make the keys work, but it'll make a failing script a little faster and clearer.

    PasswordAuthentication no
    • 0

  6. When you created the keys did you make sure to login as the same user as you made the keys with. Also make sure when you imported the keys to the authorized-keys correctly.

    • 0

  7. On the server, check the relevant log file to see if there are any messages there. The most common reason for a server refusing to use otherwise correctly setup keys is permissions errors (your home directory, ~/.ssh/ and ~/.ssh/authorized_keys must have sufficiently secure permissions or the server will not trust the contents of ~/.ssh/authorized_keys as they could have been altered by another user). If key based auth has been refused for this reason it will be logged (as would a number of other reasons). This is usually in /var/log/auth.log (at least on Debian and similar systems with default SSHD configuration, the location logged to may vary).

    The other thing to try in order to get more information is to increase the verbosity of the SSH client. If you are using OpenSSH from the command line, add -v for more verbose output while connecting, and -v again (or just -vv as options can be grouped that way) to ask it to be even more chatty.

    • 0

  8. Are you sure that it isn't asking for a passphrase to decrypt the key, as opposed to a username and password to login to the server?

    • 0

  9. We have discussed this in "Forcing rsync to non-interactive mode". You can read about many possible solutions there, but in short:

    rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path

    (Thanks, guss!) Which requires no configuration change that might alter some other uses of rsync or ssh on the server.

    Udi

    • 0