Subscribe to Blog via Email
As we migrate to the cloud, secured credentials are starting to become a standard in most DBAs worlds. If you don’t take the time to understand ssh keys and secured credentials, well, you’re not going to get very far in the cloud.
Now ssh keys are a way to authenticate to a host without the need for a password. Its far more secure, but takes a little time to set up and comprehension between public and private keys, along with the impact of pass phrases.
Private keys shouldn’t be shared, as anyone with access to the private key can generate and get access to your host. The Public host has a generated key that can be used to authenticate the user to another host when the key is implemented to that secondary host.
As RSA generation is the most common and what we will require here for EM13c and OPC setup, we’ll focus our post on this type of ssh key.
As the user that needs to authenticate to the secondary host or cloud provider, you’ll need to generate the key. This is a simple process on Unix and Linux and with Windows, Putty provides a great Putty Key Generator program that can be used to perform the task.
In a putty console, again, as the OS User that will need to authenticate, run the following command:
$ssh-keygen -b 2048 -t rsa
The command calls the ssh key generator, asks for the key to be in 2048 bytes, (-b) and the type, (-t) is RSA.
The command will ask for a directory to create the files, but a default .ssh directory will be used from the directory the command was issued from if none is specified.
Three files are generated:
-rw-------+ 1 oracle dba 1675 Mar 11 15:01 id_rsa -rw-r--r--+ 1 oracle dba 398 Mar 11 15:01 id_rsa.pub -rw-r--r--+ 1 oracle dba 1989 Mar 14 14:42 known_hosts
Note the read write permissions on these files and protect them as you see fit, especially the private key, (the one without an extension… :))
Now I’ve discussed how to create a named credential in my previous post, but I want to discuss how to use these keys to make sure that they’re set up correctly to log into the OPC and other hosts.
You can validate the ssh key by performing the following:
ssh -i ./id_rsa remote_OSUser@remote_hostname
If you can’t log into the remote server, your named credentials creation has an issue and you need to check for typos or incorrect key usage.
Once you create a Named Credential, the key is then added to that remote host so that no password is required to authenticate.
On that remote host, you’ll now see the .ssh folder just as you have one on your local host:
-rw------- 1 opc opc 221 Mar 15 12:46 .bash_history -rw-r--r-- 1 opc opc 18 Oct 30 2014 .bash_logout -rw-r--r-- 1 opc opc 176 Oct 30 2014 .bash_profile -rw-r--r-- 1 opc opc 124 Oct 30 2014 .bashrc -rw-r--r-- 1 opc opc 500 Oct 10 2013 .emacs drwx------ 2 opc oinstall 4096 Mar 14 17:43 .ssh
In this folder, there is only one file called “authorized_key” until you create ssh keys on the remote host and the authorized_key file has all the public keys and other ssh keys that are required to authenticate. You can also view this file and you should see the entry for the local host you created a ssh key and named credential for earlier:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAy+LQteSnuVmxquHXrA0Vfk6Vi8I4aW/vAgmm1BNpMoIe...........== oracle@orig_hostname
This entry will match the .pub file entry on the hostname for the OS User that you generated and used for your Named Credential earlier. This is all that’s done when a named credential with an SSH key is used for a target- It simply adds this information to the authorized_key file.
I hope this short post about RSA SSH keys is beneficial in adding to your knowledge base on EM13c, cloud based authentication and other remote host authentication challenges that may require a little more explanation and until next post, keep curious.