After run NextCloudPi many days, got following message
Your data directory is invalid
Ensure there is a file called ".ocdata" in the root of the data directory.Go to nextcloud/data, create an empty file
cd nexcloud/data
touch .ocdataBut I don't know why it was missing.
Table of Contents
vault.json
cat vault.json
{
"backend": {
"file": {
"path": "/vault/file"
}
},
"listener": {
"tcp":{
"address": "0.0.0.0:8200",
"tls_enable": 1,
"tls_cert_file": "/vault/config/cert.pem",
"tls_key_file": "/vault/config/privkey.pem"
}
},
"ui": true
}Copy into /vault/config folder
Open Disk Utility
View => Show All Devices
Select Disk (not partition)
Click on Erase or Partition
Select GUID Partition Map in Scheme
Select APFS in Format
Table of Contents
As suggested, root token should not be used, and it should be revoked immediately after used.
Follow the steps in page below to create a new root token and revoke it after used.
Generate a new root token for Hashicorp Vault
For example, SSH secret engine, following admin policy can be created
vault policy write ssh-admin-policy - << EOF
# SSH secret engine
path "ssh-client-signer/sign/*" {
capabilities = ["create", "read", "update", "delete", "sudo", "list" ]
}
# Mount the AppRole auth method
path "sys/auth/approle" {
capabilities = [ "create", "read", "update", "delete", "sudo" ]
}
# Configure the AppRole auth method
path "sys/auth/approle/*" {
capabilities = [ "create", "read", "update", "delete" ]
}
# Create and manage roles
path "auth/approle/*" {
capabilities = [ "create", "read", "update", "delete", "list" ]
}
# Write ACL policies
path "sys/policies/acl/*" {
capabilities = [ "create", "read", "update", "delete", "list" ]
}
##### Add other requirement if required. For example
# Write test data
# Set the path to "secret/data/mysql/*" if you are running `kv-v2`
path "secret/mysql/*" {
capabilities = [ "create", "read", "update", "delete", "list" ]
}
EOFThen create token under this policy
vault token create -field token -policy=ssh-admin-policyThe using this token follow the steps in page below:
Signed SSH Certificates using Hashicorp Vault in Practice
To get renew token before expired, run following command
vault token renewThe expire time can be view using following command
vault token lookupTable of Contents
To generate a new root token without old token.
$ docker exec -it vault sh$ vault operator unseal$ vault operator generate-root -init
Nonce 15565c79-cc9e-5e64b986-8506e7bd1918
...
OTP mOXx7iVimjE6LXQ2Zna6NA==
...Note: Beware of last -.
echo $UNSEAL_KEY | vault operator generate-root -nonce=f67f4da3... -Note: run vault operator generate-root only, will show nonce key.
The last person will get Encoded Token
Encoded Token IxJpyqxn3YafOGhqhvP6cQ==vault operator generate-root \ -decode=IxJpyqxn3YafOGhqhvP6cQ== \ -otp=mOXx7iVimjE6LXQ2Zna6NA==Note: The root token can be used to revoke itself.
$ vault token revoke 96ddf4bc-d217-f3ba-f9bd-017055595017Success! Revoked token (if it existed)$ vault token revoke -mode=orphan 96ddf4bc-d217-f3ba-f9bd-017055595017Success! Revoked token (if it existed)$ vault token revoke -accessor 9793c9b3-e04a-46f3-e7b8-748d7da248daSuccess! Revoked token (if it existed)I tried a few website to convert HTML to Markdown, only Convert HTML to Markdown works well, others stopped half way, or could not convert table correctly.
The reinstallation was hung with following message:
Preparing to restore "Machintosh HD"...After a few hours, still the same. Hard reboot later found that no modification in old OS, even requested erasing the disk.
Formatted disk before retry, got same issue.
The possible issue could be that the Mac can not reach Time Machine backup, because there is no blinking of the backup USB disk.
Install fresh OS, then start performing OS transfer from Time Machine backup.
Table of Contents
In previous setup, root token is used all the time, which should not be the case in real situation.
The steps can follow Signed SSH Certificates using Hashicorp Vault
export VAULT_TOKEN=<root_token>
export VAULT_ADDR='http://host:8200'$ vault policy write my-policy - << EOF
path "ssh-client-signer/sign/my-role" {
capabilities = ["create", "update", "read"]
}
EOF$ vault token create -field token -policy=my-policy$ export VAULT_TOKEN="<policy_token>"
$ vault write -field=signed_key ssh-client-signer/sign/my-role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pubssh -i signed-cert.pub -i ~/.ssh/id_rsa ubuntu@hostvault auth enable approlevault write auth/approle/role/my-role \
secret_id_ttl=10m \
token_num_uses=10 \
token_ttl=20m \
token_max_ttl=30m \
secret_id_num_uses=40 \
token_policies=my-policyvault read -field=role_id auth/approle/role/my-role/role-id
vault write -f -field=secret_id auth/approle/role/my-role/secret-idexport VAULT_ADDR='http://host:8200'
export ROLE_ID=<role_id>
export SECRET_ID=<secret_id>
vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"Result contains token
Key Value
--- -----
token s.Sh9h1wZ9ycATeSaASoOQvovr
...vault token lookup | grep policies
policies [default my-policy]$ export VAULT_TOKEN="<policy_token>"
$ vault write -field=signed_key ssh-client-signer/sign/my-role public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pubssh -i signed-cert.pub -i ~/.ssh/id_rsa ubuntu@hostIf tested finished, password authentication can be set to no:
PasswordAuthentication noIf the secret_id expires so fast, then needs to have master token to generate secret_id again, because the policy token is generated using role_id and secret_id pair.
If don't use approle, then all SSH clients can use policy token. Still thinking the advantage of using role_id and secret_id.
The root token should not be used as recommended. Will try admin token later.
Vault with Consul Storage Reference Architecture
Table of Contents
The idear of signed SSH certificates verification is to use valid (signed) SSH certificate to be verified by SSH server or by SSH client, or by both.
Client retrieves signed public key which issued by the CA key in Vault. This key has short expiry date.
Server uses the CA public key configured in SSH configuration, validates the client public key issued by Vault.
This is to validate server public whether signed by Vault by place public key in .ssh/known_hosts file. This key should have long expiry date.
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN="<token>"$ vault secrets enable -path=ssh-client-signer ssh
Successfully mounted 'ssh' at 'ssh-client-signer'!$ vault write ssh-client-signer/config/ca generate_signing_key=true
Key Value
--- -----
public_key ssh-rsa AAAAB3NzaC1yc2EA...Beware of *allowed_users" and "default_user", they must be set correctly.
$ vault write ssh-client-signer/roles/my-role -<<"EOH"
{
"allow_user_certificates": true,
"allowed_users": "*",
"allowed_extensions": "permit-pty,permit-port-forwarding",
"default_extensions": [
{
"permit-pty": ""
}
],
"key_type": "ca",
"default_user": "ubuntu",
"ttl": "30m0s"
}
EOHexport VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN="<token>"# vault read -field=public_key ssh-client-signer/config/ca > /etc/ssh/trusted-user-ca-keys.pemAdd following lines in /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem# systemctl restart sshd$ ssh-keygen -t rsa -C "user@example.com"This will generate a pair of files, .ssh/id_rsa and .ssh/id_rsa.pub.
$ vault write -field=signed_key ssh-client-signer/sign/my-role \
public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pubThis can verify the valid period and user
$ ssh-keygen -Lf ~/.ssh/signed-cert.pub
...
Valid: from 2021-11-27T17:51:29 to 2021-11-27T18:21:59
Principals:
ubuntu
...$ ssh -i signed-cert.pub -i ~/.ssh/id_rsa username@10.0.23.5Note: Add following configure in /etc/ssh/sshd_config if got error __userauth_pubkey: certificate signature algorithm ssh-rsa: signature algorithm not supported [preauth]__
CASignatureAlgorithms ^ssh-rsaSigned SSH Certificates
Leveraging Signed SSH for Remote Access with Vault