1

I'm doing an experiment on my Ubuntu server and have stored OpenSSH keys in the OpenLDAP server. There are enough examples around how to achieve this. A good source is this one. Somehow my keys are returned base64 encoded. According to the sources I found this can be caused by a trailing newline character in the stored key. I'm pretty sure this isn't the problem in my case. How do I solve this?

2 Answers 2

3

Base64 encoding in LDAP output is not a problem and does not need to be "solved". It's part of the syntax of the LDIF format for representing LDAP data in texual form.

You will notice that in the LDIF output, data encoded with Base64 is preceded by a double colon instead of a single colon:

key1: value1
key2:: dmFsdWUy

In this example, the first value (value1) is shown in plaintext and the second value (value2) is shown encoded with base 64.

Tools that output LDIF must use the base 64 encoding capability if the value contains special characters that cannot otherwise exist in the LDIF syntax. That's why a value that contains an embedded newline must be encoded. But tools not restricted to use the encoding feature only when absolutely necessary, they can use it for any reason they want to, including for example for the purpose of breaking a long value into multiple lines without introducing introducing actual whitespace into the value. And SSH keys certainly quality as long strings with very little whitespace upon which to break.

Tools which parse LDIF must recognize the double colon and correctly decode values that are encoded wherever they appear.

2
  • Thanks for your explanation, but why does the page I mentioned in the question (and several other sources I found) use sed to extract the key from the output? This must mean the key is returned in the original state and not as base64 encoded. So apparently there must be something wrong, and I'm searching for what can be wrong.
    – wie5Ooma
    Commented Aug 6, 2015 at 22:20
  • No, you're not doing anything wrong. Using sed to parse LDIF is the wrong tool for the job. It may work 95% of the time but that's not enough. I can see that the sed command in the page you linked assumes no double colon and no base64, but it is not allowed to assume that.
    – Celada
    Commented Aug 6, 2015 at 22:23
1

Even though the answer given by Celada sounds very plausible, this wasn't the problem in my situation. Initially I've added the key with phpldapadmin and apparently this software adds something at the end of the key that causes the base64 encoding to be triggered. I've deleted the key and added it again with webmin and this time the key is returned as regular plain text.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .