I've followed instrunction on https://www.elastic.co/guide/en/elastic-stack-get-started/7.4/get-started-docker.html#get-started-docker-tls to setup basic authentication
The doc creates certificate by
bash -c '
yum install -y -q -e 0 unzip;
if [[ ! -f /certs/bundle.zip ]]; then
bin/elasticsearch-certutil cert --silent --pem --in config/certificates/instances.yml -out /certs/bundle.zip;
unzip /certs/bundle.zip -d /certs;
fi;
chown -R 1000:0 /certs
'
It seems I can connect to the https endpoint from localhost only, is it?
Yes elastic can generate CSR for sign it in Public CA or corporate CA or it issues just selfsign certificate.
So if you issued self-sign - sure you can use it in production but with "no veryfy certificate" option. Otherwise you can buy or order free certificate for example letsencrypt.
Related
I use this guthub to implement the establishment of broker in AWS ec2.
https://github.com/chiachin2686/oqs-demos/tree/main/mosquitto
broker-start.sh
#!/bin/bash
# generate the configuration file for mosquitto
echo -e "
## Listeners
listener 8883
max_connections -1
max_qos 2
protocol mqtt
## General configuration
allow_anonymous false
# Comment out the following two lines if using two-way authentication
#password_file /test/passwd
#acl_file /test/acl
## Certificate based SSL/TLS support
cafile /test/cert/CA.crt
keyfile /test/cert/server.key
certfile /test/cert/server.crt
tls_version tlsv1.3
ciphers_tls1.3 TLS_AES_128_GCM_SHA256
# Comment out the following two lines if using one-way authentication
require_certificate true
## Same as above
use_identity_as_username true
" > mosquitto.conf
# generate the password file(add username and password) for the mosquitto MQTT broker
mosquitto_passwd -b -c passwd user1 1234
# generate the Access Control List
echo -e "user user1\ntopic readwrite test/sensor1" > acl
mkdir cert
# copy the CA key and the cert to the cert folder
cp /test/CA.key /test/CA.crt /test/cert
# generate the new server CSR using pre-set CA.key & cert
openssl req -new -newkey $SIG_ALG -keyout /test/cert/server.key -out /test/cert/server.csr -nodes -subj "/O=test-server/CN=$BROKER_IP"
# generate the server cert
openssl x509 -req -in /test/cert/server.csr -out /test/cert/server.crt -CA /test/cert/CA.crt -CAkey /test/cert/CA.key -CAcreateserial -days 365
# modify file permission
chmod 777 cert/*
# execute the mosquitto MQTT broker
mosquitto -c mosquitto.conf -v
Then I enter the following command in EC2 to enable broker:
sudo docker run -it --rm --net=host --name oqs-mosquitto-demo -p 8883:8883 -e "BROKER_IP=<Public IP in ec2>" -e "EXAMPLE=broker-start.sh" oqs-mosquitto-img
In the second step, I enter the following command in my VirtualBox(ubuntu) to enable publisher-start.sh
publisher-start.sh
#!/bin/bash
mkdir cert
# copy the CA key and the cert to the cert folder
cp /test/CA.key /test/CA.crt /test/cert
# generate the new publisher CSR using pre-set CA.key & cert
openssl req -new -newkey $SIG_ALG -keyout /test/cert/publisher.key -out /test/cert/publisher.csr -nodes -subj "/O=test-publisher/CN=$PUB_IP"
# generate the publisher cert
openssl x509 -req -in /test/cert/publisher.csr -out /test/cert/publisher.crt -CA /test/cert/CA.crt -CAkey /test/cert/CA.key -CAcreateserial -days 365
# modify file permissions
chmod 777 cert/*
# execute the mosquitto MQTT publisher
mosquitto_pub -h $BROKER_IP -m "Hello world." -t test/sensor1 -q 0 -i "Client_pub" -d --repeat 60 --repeat-delay 1 \
--tls-version tlsv1.3 --cafile /test/cert/CA.crt \
--cert /test/cert/publisher.crt --key /test/cert/publisher.key
Then I enter the following command in ec2 to enable broker:
sudo docker run -it --rm --net=host -p 8883:8883 --name oqs-mosquitto-publisher -e "BROKER_IP=<Public IP in ec2>" -e "EXAMPLE=publisher-start.sh" oqs-mosquitto-img
This is broker message in ec2:
1670399106: Warning: Unable to drop privileges to 'mosquitto' because this user does not exist. Trying 'nobody' instead.
1670399106: mosquitto version 2.0.15 starting
1670399106: Config loaded from mosquitto.conf.
1670399106: Opening ipv4 listen socket on port 8883.
1670399106: Opening ipv6 listen socket on port 8883.
1670399106: mosquitto version 2.0.15 running
1670399120: New connection from 49.216.40.44:8247 on port 8883.
1670399120: OpenSSL Error[0]: error:1409441B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error
1670399120: Client <unknown> disconnected: Protocol error.
I found this code elsewhere on stackoverflow:
if [ -z "`ssh-keygen -F ${wPCS_IP}`" ]; then
ssh-keyscan -p ${wPCS_PT} -H ${wPCS_IP} >> ~/.ssh/known_hosts
fi
I have two issues where I'm using the code:
This code is generating an error ($?=1) even though it succeeds.
If I run ssh-keygen -F ${wPCS_IP} again after known_hosts is appended, it does not find the keys in known_hosts, even though they were just added. This is the larger problem.
The local machine is Ubuntu Server 16.04 LTS, the remote machine is Ubuntu Server 14.04 LTS.
The major difference between my code and the code sample I found is my use of the port option -p.
Also, I've noticed that the known_hosts file does not list the machines by name or IP address. Which is different from my Gentoo laptop.
So it turns out that when there's an alternate port for ssh, it is stored in the known_hosts file as part of the IP address in this format:
[${WPCS_IP}]:WPCS_PT
Which means that for the if statement to work, it needs to look like this:
if ! ssh-keygen -F "[${wPCS_IP}]:${WPCS_PT}" -f ~/.ssh/known_hosts > /dev/null 2>&1; then ssh-keyscan -p ${wPCS_PT} ${wPCS-IP} >> ~/.ssh/known_hosts; fi
Thanks to alvits for getting me moving in the right direction...
Update: it turns out the Ubuntu 16.04 encrypts the IP address of the remote host (but not the port). I'm still trying to figure out how to adapt to this difference.
Another update: It turns out the the -H option is what's failing. Once you hash the key, it isn't found anymore. This works on Ubuntu 14.04:
if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
# IP_ADDR SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
# IP_ADDR SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
if ! ssh-keygen -F ${IP_ADDR} -f ~/.ssh/known_hosts > /dev/null 2>&1; then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
You can see that the first if statement generates the keyscan data and the second does not because the keyscan data is correct, but if you add the -H, the keygen does not detect the hashed key entries...
However, to get a similar command to work on Ubuntu 16.04, the if has to be changed:
if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts > /dev/null 2>&1; then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
# IP_ADDR:PORT SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
# IP_ADDR:PORT SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
# IP_ADDR:PORT SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
if ! ssh-keygen -F [${IP_ADDR}]:${PORT} -f ~/.ssh/known_hosts > /dev/null 2>&1; then ssh-keyscan -p ${PORT} ${IP_ADDR} >> ~/.ssh/known_hosts; fi
In this case the known_hosts file must include the port...
-H is right out here as well. The if won't find the key if it was generated with -H.
It's frustrating that the behavior varies from version to version and that the safest hashed version doesn't work.
Yet another edit: It may be the port is specified in known_hosts when the remote server uses a non-standard port in sshd_config. This may be an expected behavior.
I sent an email to the open-ssh list and had several good suggestions. Basically, it is not good to rely on ssh-keygen -F and ssh-keyscan -H as file formats and locations tend to vary from system to system.
The real solution, which I will implement today is to generate certificates for each of the servers so they recognize each other. This works well for me because I have complete control over both servers.
I was given a link that explains how to setup server certificates:
https://blog.habets.se/2011/07/OpenSSH-certificates.html
Here's a link specifically for Ubuntu.
https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu
If this is my last update, assume this worked for me.
I execute the following commands a few times a day:
ssh-keygen -t rsa -N "" -C "info#example.com" -f ~/.ssh/id_rsa_projectname
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa_projectname
cat ~/.ssh/id_rsa_projectname.pub
ssh -T git#github.com
The only variable in this script is the projectname, I would like to make a keygen.sh script or something like that to automate this process and pass along the projectname. Is this possible?
Also where should I start looking and what not to forget, I'm a bit new to bash scripting and I know it can be quite dangerous in the wrong hands.
Would it not be easier to just maintain a single set of staging or development keys rather than generating them for everything? IMHO you're losing configurability and not gaining much in security.
That aside, you're on the right track but I would do things a bit different.
export PROJECT=foo;
ssh-keygen -t rsa -N "" -C "info#example.com" -f ~/.ssh/id_rsa_${PROJECT}
That will generate named keys id_rsa_foo and id_rsa_foo.pub
Now you need to make your ssh config use it for github. ~/.ssh/config should have something like:
Host remote github.com
IdentityFile ~/.ssh/id_rsa_foo
User git
StrictHostKeyChecking no
You'll need to upload the public key to github. You'll have to figure this out for yourself using their API.
If you do all this correctly you should be able to git clone automagically.
#!/bin/bash
[[ -z "${PROJECT}" ]] && echo "project must be set" && exit 1
ssh-keygen -t rsa -N "" -C "info#example.com" -f ~/.ssh/id_rsa_${PROJECT}
chmod 400 ~/.ssh/id_rsa_${PROJECT}
echo $' Host remote github.com\n IdentityFile ~/.ssh/id_rsa_'${PROJECT}'\n User git\n StrictHostKeyChecking no' >> ~/.ssh/config
chmod 644 ~/.ssh/config
# do the github api stuff to add the pub key
It is possible to download a file from a server that use HTTPS + SSO (Single Sign ON) by means command line (of course using linux)?
The Single Sign On system run with shibbolet process
SOLVED!!
wget --save-cookies sso.cookie --keep-session-cookies --header="Referer: https://serverCheckPoint/" 'https://serverCheckPoint/Shibboleth.sso/Login?target=https://ServerCheckPoint/path_Of_The_File_To_Read'
curl -b sso.cookie -c 2sso.cookie -L -k -f -s -S https://IDP_SERVER/PATH_of_loginPAge --data "USER=yourUser&password=YOURPASSWORD" -o localfile.html
wget -v --load-cookies 2sso.cookie --save-cookies auth2.cookie --keep-session-cookies https://CheckPointServer/Path_of_data/DATA_to_DOWNLOAD
the file sso.cookie, 2sso.cookie, auth.cookie are used in order to store the session and the SAML token.
In case there are problem with certificates you should to disable the check for the TLS certificates
Is it possible to use makecert to create self-signed certificates with a specific key usage property?
I need to generate a self-signed certificate for testing. It must have the "Digital Signature" and "Non-repudiation" values on the "Key Usage" property such as described in RFC 3280 section 4.2.1.3.
I have tried some variations with the "-sky" option, such as "3" (bit 0 and bit 1 set) and "1,2". The first is not accepted and the second creates a certificate but it doesn't seem to have the "KeyUsage" property set.
Please notice that this doesn't refer to "-eku" (extended key usage).
This is the script I'm using:
makecert -r -pe -n "CN=cte-dev-CA" -ss CA -sr CurrentUser -a sha1 -sky signature -sv cte-dev-CA.pvk cte-dev-CA.cer
certutil -user -addstore Root cte-dev-CA.cer
makecert -pe -n "CN=cte-dev-SPC" -eku 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4 -a sha1 -sky signature -ic cte-dev-CA.cer -iv cte-dev-CA.pvk -sv cte-dev-SPC.pvk cte-dev-SPC.cer
pvk2pfx -pvk cte-dev-SPC.pvk -spc cte-dev-SPC.cer -pfx cte-dev-SPC.pfx -po my-password
There is no argument for makecert that affects the "Key Usage" field of the created certificate. At least, I have also been unable to find one.