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
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.
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
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.
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.
First, copy the contents of
Just place the contents of ~/.ssh/id_rsa.pub
at the bottom of~/.ssh/authorized_keys
. If you do not have anauthorized_keys
file already you will be creating one with thatnano
command 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
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 firstname.lastname@example.org
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.
-vvvof command you are issuing? How are you trying to connect to the remote server?