I have an Ubuntu Server and OS X and Windows (Cygwin) clients.

A few days ago, I was able to successfully generate RSA keys on the client and copy them to the server with:

ssh-copy-id <username>@<host>

And I was easily able to SSH without being prompted for a password.

I created a cronjob and the OS X client would backup the Documents folder nightly and send an email with the output.

Recently, I received this in the email.

Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9]

When I went to manually SSH into the server, I realized that it was prompting for the password again.

I tried rebooting the server and the client, generating a new RSA key and re-sending it, changin permissions on the .ssh folder on both the server and client,

chmod 700 ~/.ssh

I tried changing permissions on the home directory of the server

chmod go-w ~

Tried to do the same procedure from a different OS X machine and had the same error of being prompted for a password after copying the SSH key to the server.

When I did a -v when doing a SSH into the server, this is what I got (hid the server IP, username, and RSA key)

Andrews-MacBook-Pro:~ USER-NAME$ ssh -v Ubuntu-User@"Server-IP"
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to "Server-IP" ["Server-IP"] port 22.
debug1: Connection established.
debug1: identity file /Users/USER-NAME/.ssh/id_rsa type 1
debug1: identity file /Users/USER-NAME/.ssh/id_rsa-cert type -1
debug1: identity file /Users/USER-NAME/.ssh/id_dsa type -1
debug1: identity file /Users/USER-NAME/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA [RSA Key was Here]
debug1: Host '"Server-IP"' is known and matches the RSA host key.
debug1: Found key in /Users/USER-NAME/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/USER-NAME/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/USER-NAME/.ssh/id_dsa
debug1: Next authentication method: password
Ubuntu-User@"Server-IP"'s password: 

When I enter the password, the SSH does work but I am trying to automate backups to the server at midnight and would like to not have to constantly enter the password.

What can I do to fix this?

Thank you.

Edit: I looked into the "/var/log/auth.log" and found that the top line might be able to help. Below that shows the line of me typing in my password and then opening up the log. Does this information help?

Mar 23 12:58:26 SERVER-USERNAME sshd[8799]: pam_ecryptfs: Passphrase file wrapped
Mar 23 12:58:28 SERVER-USERNAME sshd[8795]: Accepted password for SERVER-USERNAME from "CLIENT-IP" port 55224 ssh2
Mar 23 12:58:28 SERVER-USERNAME sshd[8795]: pam_unix(sshd:session): session opened for user SERVER-USERNAME by (uid=0)
Mar 23 12:58:28 SERVER-USERNAME systemd-logind[689]: New session 10 of user SERVER-USERNAME.
Mar 23 12:59:00 SERVER-USERNAME sudo:   SERVER-USERNAME : TTY=pts/7 ; PWD=/home/SERVER-USERNAME ; USER=root ; COMMAND=/usr/bin/nano /var/log/auth.log
Mar 23 12:59:00 SERVER-USERNAME sudo: pam_unix(sudo:session): session opened for user root by SERVER-USERNAME(uid=0)
  • It seems that public key authentication is failing for some reason. I'd guess that it's related to directory permissions -- as that's a very common cause. In any case, the best source of information for debugging SSH is the server logs. With an Ubuntu server, check /var/log/auth.log. If the log messages aren't clear, you can edit the question to include the relevant lines. Mar 22, 2015 at 18:50
  • 1
    ssh into the server and have a look into /var/log/auth.log, it might tell you why it is denying access with that key. You can of course add the last lines of that file to your question.
    – guntbert
    Mar 22, 2015 at 19:36
  • I couldn't find anything relevant. It was hard to find anything because it was drowned out in several failed login attempts by IP addresses I don't recognize. I would only see that the password was accepted (likely referring to whenever I was successfully logging in via SSH). Should I take any actions such as changing the default port so that I see less login attempts?
    – AndrewMRiv
    Mar 23, 2015 at 3:40
  • Changing port isn't a bad way of getting rid of the noise in your log files but you should be able to grep the log file for your (external) IP address to see the relevant entries. If you're using less to view the file, use forward slash to search through it. Mar 23, 2015 at 9:48
  • I was using Nano. I could only find where it accepted my password for SSH. Unless some of the failed authentication messages I saw referred to my login and not the other IP addresses trying to login. Which command do you recommend I use to view the logs?
    – AndrewMRiv
    Mar 23, 2015 at 14:55

2 Answers 2


to pinpoint the source of the problem, try to setup passwordless login for localhost on the server. This way, you deal with only one machine, the server. If it does work, the problem is caused by the client(s); if it doesn't, you'll have to figure out what's wrong with the server itself


I plugged a monitor into the Ubuntu Server (it runs the Desktop version of Ubuntu 14, I believe) and upon logging in saw a message asking me to create a passphrase.

I clicked on it and hit enter (for a blank passphrase). After that, I rebooted and password-less SSH logins seemed to work again.

Before I mark this as complete, I will give this a few days of testing to make sure it wasn't anything else.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .