I am trying to initialize hashicorp vault with api.
payload.json:
{
"secret_shares": 2,
"secret_threshold": 2,
"pgp_keys": [
"sample_pub_1.asc",
"sample_pub_2.asc"
]
}
When I execute below command:
curl --request PUT --data #payload.json http://localhost:8200/v1/sys/init
Getting below error:
{"errors":["invalid seal configuration: error decoding given PGP key:> illegal base64 data at input byte 6"]}
But If I initialize Vault with command line everything works fine:
vault operator init -key-shares=2 -key-threshold=2 -pgp-keys="sample_pub_1.asc, sample_pub_2.asc"
Below is the output:
Unseal Key 1: wcBMA3EOVuvAOcf6AQgAhm4FpWmwhU9BV8jaYLuL8gyzhpQgPs76ByF/v5XFYj3PKaVcm2U3nzn7dablYMheGkFbOytCQ8G1guJrQ756+9t0dotAzghEeCUDwwIEU5lqENR/nAJXT4NvgrycASfS5OKv7vT6L/L8GokiHPSdBdouI3/4GyHKygrqaAUjbmNDUrgXDEfaWMkNv58yJE1tVpjYuKh8pWqNqJgSyDdkrXUt4AEY6yLTsLaCkOuu0j1sVE5D3huE0UV8u59qDwf9FusACgoyhyqyNwXqMn0pGet0hebk9pY/F293LWUr2zp7otbo5sX7H+086pl4plxUHo3GN/vhYnfwIVvJbCz68tLgAeShAyKfKCX6kFz+QX3LCkLW4UOS4Dngt+EvS+B24sFDtIvgPOZPueiPgmxwj5Evv0GzPm8iDvnrxvaWU1vxl+YlP1f3PI+rs+oBCndlBL0lVpFTDbtVLrFb/szxj+rRwKnz0oOZ4Djh2ufgDeQIlx/Zw6T1y+41jj8ITwn24uo5ChnhmeIA
Unseal Key 2: wcBMA0Eqk591x+XTAQgAQDi/V1yGqHlrSDWJ2SLeiqaLzpNrcbC5cB4+CxzkZsiVgjrd5YitULL7TmWkYl43VSPxs0hnk3O+uRUp+D4gVjUWykpGmdhwB5CiWHwNMzuIUE1E/UQVMQ39OLnG+C3VgzRe8HNhEr6pkbLFgSQLlr/459bgEyAPrW/U1PrHrH+hf+eE0me5/hUQWBfqcZHeY1Zp3A97UUBV54yarSgfRyqluiXe5j6L2X0qw5Ge/luRR8xPygyx3JqlIlPCj6liMS/to/yRGOKvYAXjXdflpBeodx3cSUOMmBTrzk1h6otM8LR28dp7qS+0qX0mWHFAfElMrJh9tz5PpWY5WIdyJNLgAeQO/Bvz4UMJLBAzEcCy2G7L4fDf4I/gSuHJROC+4lgAeaTgv+bRQCmvD4SEQYUJX3IP0cwMgskkys/vwUMqnZSNMS0gXayRvVSJ5YAHsynuixp+aE1x6UBiEw6cjVX7wwfupvdg4PTh4GPgG+TjTQDF06tQigWmpxio1JAa4jdU9uzhWbMA
Initial Root Token: aa3cccce-5ac8-4aef-7d50-6fab16e89ee4
You might not have base64-encoded your pgp_keys; according to the official Vault documentation when using curl init:
The keys must be base64-encoded from their original binary representation
You have to encode the original binary output in Base64.
On my Mac:
gpg2 --export sample#stackoverflow.com | base64 -b 0
Or on Linux:
gpg2 --export sample#stackoverflow.com | base64 -w 0
There is a difference of use between the vault command and HTTP API.
While the command can read a file from disk and allows the file name as a parameter as your example shows correctly:
vault operator init -key-shares=2 -key-threshold=2 -pgp-keys="sample_pub_1.asc, sample_pub_2.asc"
The HTTP API needs the base64 key in this field instead the file name.
{ "secret_shares": 2, "secret_threshold": 2, "pgp_keys": [
"mQGNBF/ALSkBDADoIAuvrTNbvkuZZTl28Pwh7i0aa.......",
"mQGNBF/ALSkBDADoIAuvrTNbvkuZZTl28Pwh7i0aa......."
]
}
That's why the error indicates the bad byte in the position number 6 because is trying to decode the string "sample_pub_1.asc" as a base64 valid value.
best regards
Related
How to view unprocessed versions of files? I want to use it for curl install script, but didn't find what counterpart is in gitlab.
The following schema is used in gitlab: https://gitlab.com/<group>/<repository>/-/raw/<branch>/<file>
You will probably have to use the gitlab api because your request has to be authorized.
Update
As iugo commented a curl request against this url https://gitlab.com/<group>/<repository>/-/raw/<branch>/<file> redirects.
To get the raw file we need to use the endpoint 'Get raw file from repository' from Repository files API:
curl --header "PRIVATE-TOKEN:<token>" "https://<server>/api/v4/projects/<project-id>/repository/files/<path-to-file>?ref=<branch>"
As output we get the the content (base64 encoded) of the requested file and additional metadata. To get the raw content we need to clip the content part of the returned json and decode it.
To clip the content part we could use jq:
jq -r '.content'
--raw-output / -r With this option, if the filter's result is a string then it will be written directly to standard output rather than being
formatted as a JSON string with quotes.
To decode the encoded content we could use base64
base64 -d > file
-d, --decode Decode data.
In summary, the following should be executed:
curl --header "PRIVATE-TOKEN:<token>" "https://<server>/api/v4/projects/<project-id>/repository/files/<path-to-file>?ref=<branch>" | jq -r '.content' | base64 -d > file
is there an elegant way to create a RDS instance without providing the credentials in plain text?
I already created a secret, but I can't find any documentation about how to use a secret when creating a database.
My current solution is saving the password in a file and reading it into a variable:
$ vim password.txt
$ pw=$(cat password.txt)
$ aws rds create-db-instance \
# all the arguments \
--master-user-password $pw
Update: I figured another way:
$ read -s -p "enter password: " pw
$ aws rds ... --master-user-password $pw
openejb-core jar is a library that can be used to cipher and decipher text. You can use this library to cipher the actual password and store the ciphered password in the text file 'password.txt'.
While retrieving the password into 'pw' variable, you can decipher it again and use it further. Hence, the actual password is never visible, even with root access.
I'm using Mac OS 10.13.3. I'm trying to base64 encode a binary file but am having some issues. Specifically, I thought all base64 encoded files have to have a length that is a multiple of 4. However, when I encode my file, notice taht the length is not divisible by 4 ...
localhost:lib davea$ openssl base64 -in myfile.binary -out ~/Downloads/myfile.base64
localhost:lib davea$ ls -al ~/Downloads/myfile.base64
-rw-r--r-- 1 davea staff 93162 May 31 14:22 /Users/davea/Downloads/myfile.base64
Also when I look at the contents of the base64 file, I don't see the traditional "=" or "==" at the end, which usually indicates padding
localhost:lib davea$ cat ~/Downloads/myfile.base64
...
C9vgMjoKSQYkXMLTrGKRleR558g3bY3VTqlsVvTqZXquCLp4JS4cprTG6N10H0u9
i4pwPrVmSAP2DmE1V7mGwR2e4fiYEWnZjpSbHofpzlUo34yhiQ2/5kJoQZktD7BU
uxYBAgQIECBAgBs2
Am I doing something wrong, or is there another way to base64 encode my file?
OK. I believe we were over thinking this quite a bit. Here is what you are looking for to get the desired behavior:
openssl base64 -A -in myfile.binary -out ~/Downloads/myfile.base64
This will convert to base64 without any line endings. The -A option is what does the trick.
Am I doing something wrong,
No
or is there another way to base64 encode my file?
Yes, you can use base64. It takes a parameter to specify line length but is otherwise similar, the equivalent to your command is:
base64 -b 64 -i myfile.binary -o ~/Downloads/myfile.base64
Also when I look at the contents of the base64 file, I don't see the traditional "=" or "==" at the end, which usually indicates padding
Base64 maps 3 input bytes to 4 output bytes. Your file is 93162 bytes which is divisible by 3, so no padding required.
HTH
I have file that ends by -comps.xml and has the following form:
http://some/url/<sha256sum>-<2 chars>-x86_64-comps.xml
sha256sum is alphanumeric string of 65 length.
For example:
http://some/url/0dae8d32824acd9dbdf7ed72f628152dd00b85e4bd802e6b46e4d7b78c1042a3-c6-x86_64-comps.xml
How I can download this file using curl?
I've found solution using wget:
wget --recursive --level=1 --no-parent --no-directories --accept '*-comps.xml' --directory-prefix=. http://some/url
Assuming that you already know the filename, to download the contents of the file, then simply use
curl -O http://some/url/0dae8d32824acd9dbdf7ed72f628152dd00b85e4bd802e6b46e4d7b78c1042a3-c6-x86_64-comps.xml
If you are looking to somehow predetermine the file name based on an SHA256 of the file's contents, then you will need to either already have access to these contents to be able to determine the SHA256 part of the URL, or to have access to an alternative source for this information.
I have a client and server system that regularly run scheduled tasks and communicate through xml files that have been encrypted by gpg. All required public keys have been successfully exchanged between the client and server. The encryption and decryption calls are being done from a batch file.
encrypt syntax
gpg.exe --batch --yes --recipient %1 --output %4 --passphrase %5 --local-user %2 --sign --encrypt %3
decrypt syntax
gpg.exe --batch --yes --output %3 --passphrase %4 --decrypt %2 2>%1
The client creates a xml file, encrypts it with gpg using server public key, signs with private key and uploads it to the server's ftp site. Server regularly checks for new files in ftp folder. For any new file it decrypts using gpg and then processes the xml inside the file.
For some of the xml files that the server tries to decrypt, I receive an error as follows:
gpg: block_filter 00AA8400: read error (size=7841,a->size=395)
gpg: mdc_packet with invalid encoding
gpg: decryption failed: invalid packet
gpg: block_filter: pending bytes!
The point to note is that this is not happening with all the files but with only some files. I haven't been able to find any commonality between the files that it fails on.
Is anyone familiar to what this error means? any suggestions to help track this down are welcome.
Finally figured it out. gpg was not the culprit here. when the server was checking for files in the specified folder, it was using the Append(fileHandler) method on Delphi to test if the file could be opened. But this method had a peculiar condition as if it found the ascii character 26 (i.e. CTRL+z) in the last 128 byte block of the file, it would remove everything from that character till the end of the file. This caused some part of the encrypted files to be deleted and subsequently caused the above error when decrypting it through gpg. After I replaced the Append method with Reset(fileHandler), encrypted files were no longer modified and decryption works perfectly.