Problems setting private key for SSH logins on Mac OS X 10.10.5 (Yosemite) without passphrase

Question

I’m trying to use SSH client for logging on remote server. On this server is my public key and I have private key that was created without passphrase.

On Windows I’m able to login via PuTTY without problems.

On Mac OS X when I use SSH client, Window asking for password pops-up and whatever I enter, SSH asks me for password. Here also doesn’t matter what I enter, it’s always writes permission denied.

I found that similar problems may happen when private key is in PPK format (which was my case), so I tried to convert it to PEM, but it didn’t help:

puttygen id.ppk -O private-openssh -o id.pem

Additional info:

My SSH config contains path to private key for the host I'm trying to connect. I also tried using ssh parameter -i to specify the key manually, but with same results.

Command used to create PEM format was 'puttygen id.ppk -O private-openssh -o id.pem'

Log output (only relevant part)

debug1: Authentications that can continue: publickey,password 
debug1: Trying private key: /Users/josef/.ssh/talnet_rsa 
debug1: read PEM private key done: type RSA 
debug3: sign_and_send_pubkey: RSA #I removed these for security reasons#
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Answer 1

If you generate your key with ssh-keygen it will prompt you to enter a password. The private key will be encrypted using this password. If you want to use the private key (for authorisation as example), you have to decrypt it first. The window which pops up ask you to enter that password you also entered in ssh-keygen.

It may be possible to generate a key without a password, but then anyone who gets that key can use it without limitations. It is not recommended to do that, and your Mac won’t prompt you for a password, if you don’t have set any.

I may be wrong, if so, enter a blank password; I mean the “nothing here” password.

Answer 2

I’m trying to use SSH client for logging on remote server. On this server is my public key and I have private key that was created without passphrase.

This is a good start for a password-less setup. On Windows you clearly added the public key correctly. This is what you need to do to add the public key to the Mac OS X authorized_keys file for your user. Here are the steps you should use if you already have a public key file (~/.ssh/id_rsa.pub) located on your remote server.

Preface.

Based on your comments and recent edit you seem to have a .pem file (id.pem) which is just a container format that encompasses the public and private key in a certificate. Unsure how Mac OS X would use a .pem directly, but for my preferred method of creating password-less setups, I would recommend you extract the public key before proceeding any further. It’s easy enough by doing something like this on the Mac OS X system from the Terminal:

openssl rsa -in id.pem -pubout > ~/id_rsa.pub

Of course, change the name/path of id.pem to match the path of where that file is located on the system. The ~/id_rsa.pub path tells the command to extract id_rsa.pub to your home directory.

And for those out there who see what I did above and what I am doing below, yes the command could probably be something like this to dump the public key right into authorized_keys:

openssl rsa -in id.pem -pubout >> ~/.ssh/authorized_keys

But this answer is about tracing the details, understanding the process and seeing where things “broke.” So cleanly dumping a public key into ~/.ssh/authorized_keys directly is faster but not necessarily better for learning purposes.

Shorter answer.

In short I believe that if the id_rsa.pub was added to authorized_keys, then this is a permissions issue that can be solved by just running the following command by your user on the Mac OS X system:

chmod 600 ~/.ssh/authorized_keys

If that doesn’t work, read the fuller details below to see if you missed a step.

Longer answer.

First, copy the contents of ~/.ssh/id_rsa.pub into authorized_keys:

nano ~/.ssh/authorized_keys

Just place the contents of ~/.ssh/id_rsa.pubat the bottom of~/.ssh/authorized_keys. If you do not have anauthorized_keysfile already you will be creating one with thatnanocommand so you should set proper permissions on the file—600` aka owner/user read & write only—so SSH does not choke on it like this:

chmod 600 ~/.ssh/authorized_keys

Now with that done, you are pretty much done. In the final step you just login to your machine within your machine and you will be presented a “known hosts” warning something like this:

The authenticity of host 'my_host(123.456.78.90)' can't be established.
ECDSA key fingerprint is ab:12:cd:34:ef:56:gh:78:ij:90:kl:12:mn:34:op:56.
Are you sure you want to continue connecting (yes/no)? yes

Just answer yes and then you will get a message like this:

Warning: Permanently added 'my_host,123.456.78.90' (ECDSA) to the list of known hosts.

And now you should be all set. Any SSH login you make to that machine moving forward will be 100% password-less.

If you want to debug the connection, be sure to use the -v (verbose) option like this:

ssh -v myuser@my_host

If all works well, you will get verbose—but clean—output like this:

OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to my_host [123.456.78.90] port 22.
debug1: Connection established.
debug1: identity file /home/myuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ab:12:cd:34:ef:56:gh:78:ij:90:kl:12:mn:34:op:56
debug1: Host 'my_host' is known and matches the ECDSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:3
debug1: ssh_ecdsa_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_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to my_host  ([123.456.78.90]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-34-generic x86_64)

And if that doesn’t work, just look at the debug output & see where things are choking to debug.

Answer 3

If you converted the PPK Key succesfully to an openSSH Key using puttygen.exe it should work.

I assume misconfiguration here. Try to chmod 700 <private keyfile> on your Mac OS X system.

Probably also check chown. Your user should be holding the correct UID for the key.

Also @Jakuje said in the comment, use ssh -vvv ... to resolve connection problems.

Like @Schwertspitze said, this is a security issue you should be aware of.

EDIT

About setting the correct access rights ... In another thread is a listing for different files.