Forum

General discussion on using the Kognitio Analytical Platform.
Contributor
Offline
User avatar
Posts: 48
Joined: Tue May 28, 2013 1:44 pm

How can I use ssh keys with Kognitio?

by anonymous2 » Fri Jun 14, 2013 2:11 pm

I don't understand how to use ssh keys to authenticate with Kognitio, rather than having to enter my password. What do I need to do?
Reply with quote Top
Contributor
Offline
User avatar
Posts: 386
Joined: Thu May 23, 2013 4:48 pm

Re: How can I use ssh keys with Kognitio?

by markc » Fri Jun 14, 2013 2:14 pm

The Kognitio database currently supports two means of authentication. The first is simple username/password authentication, and the second is authentication using public/private keys in openssh format.

How does public/private key authentication work?

A user has a public and private key, known as a key pair. The private key must be kept secret and the contents not divulged to anyone but the user. The public key is not secret. ssh-keygen(1) can be used to generate public and private key files.

First, the service doing the authentication (in this case the Kognitio database) must be configured to allow the holder of a certain key pair to access the service. This is accomplished by the database administrator using the wxaddkey(1) command. The database administrator adds the user's public key to the list of authorised keys associated with that Kognitio user.

To log in, the server issues a challenge, which is a random string of bytes. The client signs the challenge with their private key to produce a digital signature. The signature is sent back to the server, which uses the public key to verify that the challenge was signed with the private key. At no point does the server, or an eavesdropper, have the private key or any means of deriving it. All the server can verify is that the challenge it sent was signed by the private key, and so the client must therefore hold the private key.

How do I get this to work with Kognitio?

To authenticate with your SSH key, the ODBC driver needs access to your private key or to an SSH agent program which has your private key, and the server needs to have your public key and to know which Kognitio user is allowed to authenticate with that key.

To add your public key to the server, use wxaddkey(1) as SYS. You (or, if you don't have the SYS password, the database administrator) need to tell wxaddkey the Kognitio user who should be allowed to log in with the key, and the public key of the key pair. This will put an appropriate record in the IPE_ALLAUTHORISED_KEYS system table. See wxaddkey(1) for more information.

To allow the ODBC driver to authenticate using SSH keys, there are two possible approaches:

Option 1: allow the ODBC driver to sign the challenge directly

The first option is to tell the ODBC driver where your private key is. You do this by adding a key "PrivateKey" to the section in odbc.ini associated with the server you're connecting to, with the value being the path to the private key file. In Windows, you can enter this path name in the driver configuration window in the ODBC Administrator (Control Panel, Administrative Tools, Data Sources (ODBC), select your DSN, click "Configure..." and enter the path name in the box marked "Auth File").

If your private key has a passphrase, it should be supplied as the password when you log in.

Option 2: refer the task to an SSH agent (not available on Windows)

If the environment variable SSH_AUTH_SOCK is set, then the ODBC driver expects it to contain the path to a socket with which to communicate with an SSH agent. The SSH agent has the private key, and the ODBC driver passes it a challenge and fetches back the response. For details on running an SSH agent, see the man pages for ssh-agent(1) and ssh-add(1). The typical usage goes like this:

user1@pc2:~$ eval `ssh-agent`
Agent pid 25400

user1@pc2:~$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/user1/.ssh/id_dsa:
Identity added: /home/user1/.ssh/id_dsa (/home/user1/.ssh/id_dsa)

The ssh-agent command outputs bash commands to set the appropriate environment variables including SSH_AUTH_SOCK, which is why we ran it with "eval". The SSH_AUTH_SOCK variable now contains the name of a Unix domain socket:

user1@pc2:~$ echo $SSH_AUTH_SOCK
/tmp/ssh-DmVk25399/agent.25399

When you log in, don't supply a password (if the client you're using insists on having a password, use a blank string). If $SSH_AUTH_SOCK is set then the ODBC driver will attempt to authenticate using SSH keys held by the SSH agent.

If you do supply a password, the ODBC driver will attempt to log in to the database using that and not with your SSH key.

When I try to log in using my SSH agent it prompts for a password, or says "Password check failed"

The number one cause of this complaint is that the environment variable SSH_AUTH_SOCK is not set. If it's not set, you need to run...

eval `ssh-agent`

... to start up an SSH agent and set the SSH_AUTH_SOCK variable, then you need to use ssh-add to tell the agent to add your private key. This step will prompt for a passphrase if your private key is protected by one. Now try to log in to the database again.

I've already run my SSH agent! Then I SSHed to another machine and suddenly my agent isn't there any more

When you SSH to another machine, environment variables aren't carried over. However, you can enable SSH agent forwarding by passing the -A option to ssh when you SSH to the remote machine from your local one. If there's an agent running on the local side (and SSH_AUTH_SOCK is set) and you've passed -A to ssh then a socket will be created on the remote host which connects back through your SSH connection to your agent. In this case SSH_AUTH_SOCK will be set on the remote side automatically.

I put PrivateKey=/path/to/my/private/key in my odbc.ini file under the appropriate DSN, and I still get "password check failed" or a prompt for a password rather than my key's passphrase. It's like it's not even trying to open my key file

Provided the private key is present and valid the ODBC driver should prompt you for a passphrase if you haven't supplied one as your password, unless of course your private key has no passphrase.

If you get "password check failed" or if it prompts for a "password" rather than a "passphrase" then perhaps the ODBC driver isn't loading the libcrypto library properly. On Windows this won't be an issue because the libcrypto library is included with the driver, but on Unix-like platforms, if it can't find a library called "libcrypto.so" it will fail. On some systems the libcrypto library is called something like libcrypto.0.9.8.somepatchstring.so. Create a symlink to this file called "libcrypto.so" and make sure the directory in which the symlink resides is in your LD_LIBRARY_PATH environment variable, and the ODBC driver should find it and open it.

mkdir ~/lib
ln -s /usr/lib/libcrypto.0.9.8.so ~/lib/libcrypto.so

# Having created the symlink you might want to put this line in your .bashrc
export LD_LIBRARY_PATH=~/lib:$LD_LIBRARY_PATH

I've tried all of the above and it still seems to want my password rather than letting me log in with my SSH key

Check that you're actually allowed to log in to that Kognitio system using your SSH key. Your public key and user ID should appear in SYS.IPE_AUTHORISED_KEYS. If it doesn't, badger your database administrator to add it with wxaddkey(1).

I've done all the above, and I am still being prompted for a password

Please check that the private and public keys you are trying to use are actually a key pair, as in the past a surprising number of users have had problems due to mismatching keys.

How do I use SSH key authentication with Kognitio if my private key is protected with a passphrase but I'm running from a cron job or other non-interactive environment, so I can't enter the passphrase when I add the key to the agent?

You need to have an SSH agent permanently running which has the private keys, then manually set SSH_AUTH_SOCK in your cron job to this agent's socket. How you do this is up to you, but you'll need some way of entering the passphrase every time you have cause to restart the SSH agent.
Reply with quote Top
Contributor
Offline
User avatar
Posts: 386
Joined: Thu May 23, 2013 4:48 pm

Re: How can I use ssh keys with Kognitio?

by markc » Tue Oct 08, 2013 10:51 am

http://www.kognitio.com/forums/Password ... %20KAP.pdf explains configuration prerequisites for using passwordless authentication, and covers other details relevant to this topic.
Reply with quote Top
Multiple Poster
Offline
User avatar
Posts: 7
Joined: Fri May 08, 2015 3:59 pm

Re: How can I use ssh keys with Kognitio?

by matfior » Fri May 08, 2015 4:11 pm

Hi,
after setting up all as explained, I'll get this error:

AM002C Unknown authentication method

What am I missing here?

Thanks,
Matteo
Reply with quote Top
Contributor
Offline
User avatar
Posts: 386
Joined: Thu May 23, 2013 4:48 pm

Re: How can I use ssh keys with Kognitio?

by markc » Fri May 08, 2015 5:30 pm

The AM002C error can be decoded by searching for it at http://www.kognitio.com/forums/wcss004.htm

The expansion of the error code on that page is "The client is asking to authenticate in a manner unfamiliar to the server, or which the server cannot perform".

The action recommended is "Either upgrade the server to one that does know how to authenticate in the manner the client is describing, or use a different authentication method, or ensure the server has the appropriate libraries available"

In this case, the most likely cause of the problem is that libcrypto cannot be loaded. In that case, the server will have added information to the serverdbg file in the current smd logging directory (which you can switch to from a Linux command line on a server node with "cd `wxlogd smd`" - note the backquotes around wxlogd smd).

For example, if libcrypto is not installed on ALL the DB nodes you might see something like the following - you'd then need to get libcrypto installed on all nodes, and ensure that a relevant link existed for it - e.g. /lib/libcrypto.so on all nodes points to a suitable library:

21-12_13:37:12_GMT: CheckSSHKeyAuth() couldn't dlopen libcrypto - libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
21-12_13:37:12_GMT: To use public/private key authentication, OpenSSL libcrypto version 0.9.7 or later must be present.
21-12_13:37:12_GMT: Read the man page for dlopen(3) for the directories that are searched; the library should be called libcrypto.so.
21-12_13:37:12_GMT: If libcrypto.so is not present anywhere, I will instead search for libcrypto.so.1 then libcrypto.so.0.
Reply with quote Top

Who is online

Users browsing this forum: No registered users and 1 guest

cron