theinoob.comsitemap

how to connect from mac to centos using ssh private/public keys (video)

No Comments

Requirements:

  • Access to your centos machine
  • Mac OS X v. 10.9.x
  • Basic command line knowledge
  • A virtual or physical machine running centos connected to your network or with internet access

centos

Video / Text:

Using encrypted keys for authentication offers two main benefits. Firstly, it is convenient as you no longer need to enter a password (unless you encrypt your keys with password protection) if you use public/private keys. Secondly, once public/private key pair authentication has been set up on the server, you can disable password authentication completely meaning that without an authorized key you can’t gain access – so no more password cracking attempts. 

It’s a relatively simple process to create a public/private key pair and install them for use on your ssh server. 

First, create a folder called .ssh in your home directory and cd into it (make sure you also have it on the server in the home directory of the user you are connecting with):

$ mkdir ~/.ssh; cd ~/.ssh

Second, create a public/private key pair on the client that you will use to connect to the server (you will need to do this from each client machine from which you connect):

$ ssh-keygen -t rsa -C "Name Surname" -f name

Replace “Name Surname” and “name” with your name. This is to give it a bit of personalisation. For my example here I will use it like this:

$ ssh-keygen -t rsa -C "TheiNoob Tutorials" -f theinoob

This will create two files in your (hidden) ~/.ssh directory called: theinoob and theinoob.pub The first: theinoob is your private key and the other: theinoob.pub is your public key. 

Add RSA or DSA identities to the authentication agent and to keychain so that identities will persist through reboots:

$ ssh-add -K ~/.ssh/theinoob

Run ssh-add -l to list the agent’s keys, ssh-add -D to clean out all keys.

If you don’t want to still be asked for a passphrase (which is basically a password to unlock a given public key) each time you connect, just press enter when asked for a passphrase when creating the key pair. It is up to you to decide whether or not you should add the passphrase protective encryption to your key when you create it. If you don’t passphrase protect your key, then anyone gaining access to your local machine will automatically have ssh access to the remote server. Also, root on the local machine has access to your keys although one assumes that if you can’t trust root (or root is compromised) then you’re in real trouble. Encrypting the key adds additional security at the expense of eliminating the need for entering a password for the ssh server only to be replaced with entering a passphrase for the use of the key. This may be further simplified by the use of the ssh_agent program 

Now set permissions on your private key:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/theinoob

Copy the public key (theinoob.pub) to the server and install it to the authorized_keys list:

$ cat theinoob.pub | ssh -v user@your.ip.or.fqnd "cat >> ~/.ssh/authorized_keys"

For my example I will be using user=root, your.ip.or.fqnd=192.168.1.252 the command will then be:

$ cat theinoob.pub | ssh -v root@192.168.1.252 "cat >> ~/.ssh/authorized_keys"

Note: once you’ve imported the public key, you can delete it from the server. 

and finally set file permissions on the server:

$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

The above permissions are required if StrictModes is set to yes in /etc/ssh/sshd_config (the default).

I had some issues when it will not connect using private/public key authentication, after correcting the SELinux permissions all was good, I could connect using private/public key authentication.

Ensure the correct SELinux contexts are set:

$ restorecon -Rv ~/.ssh

Now when you login to the server you won’t be prompted for a password (unless you entered a passphrase when you created your key pair). By default, ssh will first try to authenticate using keys. If no keys are found or authentication fails, then ssh will fall back to conventional password authentication. 

Once you’ve checked you can successfully login to the server using your public/private key pair, you can disable password authentication completely by adding the following setting to your /etc/ssh/sshd_config file: 

# Disable password authentication forcing use of keys
PasswordAuthentication no

Original post here:

Here is a short demo movie. Please feel free to comment.

Leave a Reply