Getting bitten by SELinux and sshd authorized_keys




TL;DR:  If you can't ssh using a public key, it could be a SELinux thing.


Logging in to a server with ssh using your public key is pretty handy.  While setting up an OEL 6 VM  I ran into a strange error where sshd would not let me log in with a public key, even though my key was in ~oracle/.ssh/authorized_keys.  Password logins worked just fine.

Somewhat puzzling: I could ssh into the root account using my public key and without a password.

Nine times out of ten, this is a permission problem. Sshd is picky about the permissions on your home directory, ~/.ssh, and the authorized_keys file.  I carefully checked this over - but in this instance permissions were not the problem.

The standard advice to debug SSH problems is to run sshd in the foreground with debugging turned on:

service sshd stop
/usr/sbin/sshd -dD

And of course my problem promptly disappeared. Hmmm, so it works in debug mode, but not when running as a daemon. It also works fine to ssh into the root account, but not ~oracle.

My initial google-fu skills were weak, but on a hunch I googled "sshd SELinux".

Bingo:

http://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login


In my case disabling SELinux did the trick (not good for production, but acceptable for my purposes).



Oracle Identity Federation: Federate yourself!


A customer asked me how they could test their OIF IdP configuration without standing up another relying party.

Since OIF can act in both roles (IdP and SP), in turns out you can configure OIF to federate against itself.  It's seems somewhat crazy, and its not all that intuitive, so I thought I would include a few notes on how to set this up.

The key is that you must export OIFs SP and IdP metadata and re-import it back into OIF as configured federations. The "/fed/user/testspsso" test page can be then be used to initiate the federation.

Here are the basics of how to accomplish this.

Step 1: Export your SP and IdP metadata. This is done from the em console.
Administration -> Security and Trust:





Step 2) Import the exported meta data back into OIF:
Administration->Federations 

Click on the "Choose File" button and select the meta-data files you exported in step 1




You should now have an IdP and SP configured under your federations.  You may want to edit your federation settings to enable additional attributes to be mapped or change the default request format (POST, for example). See your OIF Admin guide for the details.


Step 3) Set your default SSO Identity Provider to be the newly created IdP that you just imported.

Administration->Service Provider->Common






Step 4) You are now ready to test your IdP

There is a neat Firefox plugin called "SAML Tracer" that is great for debugging SAML isses.  I highly recommend installing it.

Navigate to the test SP SSO page. This is located at:
 http://your-oif-server:7499/fed/user/testspsso

You should see something like this:




Click on "Start SSO".

You will be redirected to your OIF login page. Assuming you have configured LDAP authentication (Administration->Auth Engines -> LDAP), you will see this:


Login with your LDAP credentials, and you will see the response from the IdP:





If you are using the SAML tracer you can see the SAML request (OIF acting the SP role) and the response (OIF acting in the IdP role).  Here is an example request:









Congratulations. You have now federated with yourself!