Month: December 2021

Dock installation issue in Armbian with iptables

Dock installation issue in Armbian with iptables

Issue

Docker requires legacy iptables. If docker installation got network issue, following commands might fix the issue.

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
apt remove apparmor

References

iptables-nft vs iptables-legacy #11612

Delete docker images from docker registry

Delete docker images from docker registry

Steps

Get Digest by pulling image

Use docker pull command can get image digest

docker pull registry.example.com/image_path/image:tag

If it is daily build for container backup purpose, the tag can be in date format, such as YYYYMMDD. The output can be

20210624: Pulling from image_path/image
...
22b5d63ad977: Already exists
8e2e66517d7e: Pull complete
Digest: sha256:7535af1f65524f9200b901fc31b9c779819e45c0502ef99605666842a319908f

Get Digest by deleting local image

The digest is also printed when deleting it.

docker rmi registry.example.com/image_path/image:tag

Sample output as below

Untagged: registry.example.com/image_path/image:tag
Untagged: registry.example.com/image_path/image@sha256:e300ff463dc18c7b3bf3964dc5a9832f613d829285a0da49e5fd37519dc7d0fc
Deleted: sha256:35baba3d5948b5844b67adcd6a236905039e929f8647d4e4afc9e64e9460d557
Deleted: sha256:bd681f3956f55dc028bae7ca4c2657457824a0e356c59705302fb084660a669b

Note: The Digest is the second tag, the sha256 in the first Deleted message is allowed to be deleted too, but the sha256 in the second Deleted message was not. Don't understand why

Get Digest by curl command

curl -v --silent -H "Accept: application/vnd.docker.distribution.manifest.v2+json" -X GET https://$USER:$PASSWORD@registry.example.com/v
2/image_path/image/manifests/tag 2>&1 | grep Docker-Content-Digest | awk '{print ($3)}'

Check manifests existence

curl https://$USER:$PASSWORD@registry.example.com/v2/image_path/image/manifests/sha256:xxxxxxxxxxxxxxxx

Delete tag

curl -X DELETE https://$USER:$PASSWORD@registry.example.com/v2/image_path/image/manifests/sha256:xxxxxxxxxxxxxxxx

Run garbage-collect

docker exec registry bin/registry garbage-collect --delete-untagged /etc/docker/registry/config.yml

Restart registry if necessary

docker restart registry

Unable to show login page for NextCloud

Unable to show login page for NextCloud

NextCloud shows Internal Server Error on first page.

Error

In docker log, shows following message

Class 'OCP\\User' not found

and it points to following file

/data/nextcloud/apps/epubreader/lib/Hooks.php

Warning before

There was an warning message pointing to epubreader app, shows untruested source, but after I reinstalled it, the message disappered.

Fix

Access docker

docker exec -it nextcloudpi bash

Move the epubreader app to /tmp directory.

mv /data/nextcloud/apps/epubreader/ /tmp/

Restart NextCloudPi docker container

Next

After fixed, if try to install EPUB/CBZ/PDF ebook reader app again, following message appears.

Error: This app cannot be enabled because it makes the server unstable

If force install it, NextCloud will appear Internal Server Error again.

More secure but easy ways to access SSH server

More secure but easy ways to access SSH server

Except User name and Password, which is hard to remember if you don't want others guess it easily, there are other easy ways to protect SSH server.

Public Key

Steps

This is most a simple way, just generate a pair of key,

ssh-keygen

If need more secure, generate 4096 bit RSA key

ssh-keygen  -t rsa -b 4096

Then inject public key in .ssh/id_rsa.pub into remote .ssh/authorized_keys

Cons

  • Needs to perform for every user
  • Needs to inject public keys of clients into all target servers
  • No expiration

Signed Certificate

Steps

Refer to Signed SSH Certificates using Hashicorp Vault in Practice

  • Use free software, hashicorp vault to manage signed certificate.

  • Inject trusted CA key retrieved from vault into target SSH server configure,

  • Use authorized token and client private key to generate short life signed certificate

  • Use signed certificate and client private key login to target server

Note: Only need normal token to generate signed certificate

  • Authorized token can be renewed (replaced) after used

Pros

  • Token never reach Internet, and it can be renewed (replaced) any time
  • Signed certificate has short life

Cons

Need to save a token

2FA

Steps

Refer to Enable 2FA for Ubuntu

Pros

  • Only need a 2FA software, and adding digits after key in password
  • Short life of digits

LDAP or Kerberos

Instead of all servers maintain their own password, passwords are centrally managed by authentication server.

Cons

  • Every server needs connection to authentication server
  • Cannot login if lost connection to authentication server
  • All servers are using same password

One time password

Retrieve password from authentication server, then use it to login to remote server.

Remote server will use it to verify against authentication server.

Cons

  • Every server needs connection to password server
  • Cannot login if lost connection to password server