Das längste Thema

sla

Zitat von geekmonkey

Ich installer ja auch keine Kamera im Schuhschrank... ?

Das hätte allerdings einige Vorteile

geekmonkey

übersehe ich gerade irgendwas, oder kann ich bei acme.sh nicht mehr einfach die renew-hook manuell editieren? sind die jetzt encryptet? o0

geekmonkey

Zitat von geekmonkey

übersehe ich gerade irgendwas, oder kann ich bei acme.sh nicht mehr einfach die renew-hook manuell editieren? sind die jetzt encryptet? o0

Ich zitiere mich mal selbst. Man darf die Änderungen also vorab per base64 codieren...

der Sinn erschließt sich mir hierbei zwar nicht, aber okay...

mainziman

Zitat von sla

Das hätte allerdings einige Vorteile

Mottenbefall frühzeitig erkennen?

geekmonkey

Wer sich die Implementierung von Letsencrypt bei Synology ausgedacht hat sollte irgendwo an ein Server Rack gekettet werden, ....

hab jetzt 1h gebraucht um 2 wildcard Zertifikate von meinem Cert VPS elegant auf der DS einzupflegen und automatisch zu erneuern. Acme.sh direkt auf der DS laufen zu lassen ist keine Option, da ich die Zertifikate lieber alle Zentral auf einer Maschine verwalte.

Bensen

Zitat von geekmonkey

da ich die Zertifikate lieber alle Zentral auf einer Maschine verwalte.

Magst du mir/uns erklären wie du die Zertifikate von deinem zentralen Server an deine jeweilige Webserver schickst und auch die Dienste neu startest?

Weil ich aktuell noch auf jeden Host mit certbot arbeite und mich aktuell in acme.sh, RSA und ECDSA einlesen und wenn ich das ganze schon ändere würde ich dies auch gerne zentral über nen kleinen VPS. Jedoch bin ich noch unschlüssig wie ich die Zertifikate sicher auf meine Server übertrage und den Webserver im Anschluss neu starte bzw. reloade.

mainziman

Bensen des geht trivial

per sftp transferieren und z.B. das Äquivalent von dem da

C:\_TOOLS\putty\plink.exe -4 -ssh host.domain.tld -l root -i C:\_TOOLS\putty\host.ppk shutdown -h now

gibts unter Linux bestimmt (nur halt net gleich niederfahren); oder wie war das mit dicken Fenstern und schlanken Tuxen?

geekmonkey

Zitat von Bensen

Magst du mir/uns erklären wie du die Zertifikate von deinem zentralen Server an deine jeweilige Webserver schickst und auch die Dienste neu startest?

Weil ich aktuell noch auf jeden Host mit certbot arbeite und mich aktuell in acme.sh, RSA und ECDSA einlesen und wenn ich das ganze schon ändere würde ich dies auch gerne zentral über nen kleinen VPS. Jedoch bin ich noch unschlüssig wie ich die Zertifikate sicher auf meine Server übertrage und den Webserver im Anschluss neu starte bzw. reloade.

Geht eigentlich erstaunlich einfach:

auf dem Cert VPS läuft eigentlich fast nix außer acme.sh welches sich um 99% meiner Zertifikate kümmert.

Per --renew-hook wird quasi nen bash script aufgerufen /opt/lazy_server/ssl/ssl_deploy.sh <server> <domain>

Bash

#!/bin/bash


#################################################
#
# Deploy SSL Certificates
# Version 1.2
# Copyright 2020, Veit <mail@brnk.de>
#
# Tested: 21.08.2020
#
#################################################


##
##  Usage: ./ssl_deploy.sh <server> <domain>
##


##################  Settings  ###################


  # Certificates
  acme_dir="/etc/acme/mycerts"
  remote_dir="/etc/nginx/ssl"

  <server1>_port="<ssh_port>"
  <server2>_port="<ssh_port>"
  <server3>_port="<ssh_port>"
  <server4>_port="<ssh_port>"
...

  remote_host="$1"
  domain="$2"

  get_port="${remote_host%.*}_port"
  remote_port=${!get_port}


######### DO NOT EDIT BELOW THIS LINE  ##########

ssl_copy() {
   ssh -i ~/.ssh/id_rsa -p $remote_port root@$remote_host "mkdir -p ${remote_dir}/${domain}" > /dev/null 2>&1
   scp -i ~/.ssh/id_rsa -P $remote_port \
   ${acme_dir}/${domain}/fullchain.cer \
   ${acme_dir}/${domain}/${domain}.cer \
   ${acme_dir}/${domain}/${domain}.key \
   root@${remote_host}:${remote_dir}/${domain} > /dev/null 2>&1
}

ssl_cmd() {
  ssh -i ~/.ssh/id_rsa -p $remote_port root@$remote_host "/opt/lazy_server/ssl/ssl_receive.sh $domain" > /dev/null 2>&1
}

#################### RUN  #######################

do_ssl_deploy() {
  sleep 30
  ssl_copy
  ssl_cmd
}

do_ssl_deploy

Alles anzeigen

wobei bei mir jeder Server eine eigene domain hat unter der er erreichbar ist, also übergebe $1/2 innerhalb des renew-hooks:

./ssl_deploy.sh server1.de domain.de

damit verbindet sich der Cert server dann mit server1.de lädt dort die files hoch und löst dort dann /opt/lazy_server/ssl/ssl_receive.sh <domain> aus.

Bash

#!/bin/bash

#################################################
#
# Receive SSL Certificates
# Version 1.2
# Copyright 2020, Veit <git@brnk.de>
#
# Tested: 12.04.2019
#
#################################################

##
##  Usage: ./ssl_receive.sh <domain> 
##

##################  Settings  ###################

  mydir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

  # Connect
  domain="$1"

  # Certificates
  remote_dir="/etc/nginx/ssl" 

  # Docker Settings
  # some docker containers might be restartet after renewing certificate
  mailcow_host="<domain.de>"

######### DO NOT EDIT BELOW THIS LINE  ##########
nginx_restart() {
  service nginx restart
}
mailcow_restart() {
  $mydir/ssl_mailcow.sh  
}
push_notify() {
  $mydir/../notify/push_ssl.sh $domain > /dev/null 2>&1
}
#################### RUN  #######################

do_ssl_receive() {
  nginx_restart
  if [ "$domain" = $mailcow_host ]; then
    mailcow_restart
  fi  
  push_notify
}

do_ssl_receive

Alles anzeigen

Hier ist eigentlich nur mailcow_host="<domain.de>" wichtig, da hier noch mal gesondert ssl_mailcow.ssh ausgelöst wird. Damit werden die Zertifikate in die Mailkuh kopiert

Das Script sieht dann so aus:

Bash

#!/bin/bash

#################################################
#
# Mailcow Container Restart
# Version 1.2
# Copyright 2020, Veit <git@brnk.de>
#
# Tested: 12.09.2018
#
#################################################

##
##  Usage: ./ssl_mailcow
##

##################  Settings  ###################

  # Certificates
  remote_dir="/etc/nginx/ssl"
  domain="<domain.de>"

######### DO NOT EDIT BELOW THIS LINE  ##########

copy_ssl() {
  cp ${remote_dir}/${domain}/fullchain.cer /opt/mailcow/data/assets/ssl/cert.pem
  cp ${remote_dir}/${domain}/${domain}.key /opt/mailcow/data/assets/ssl/key.pem
}
restart_mailcow() {
  postfix_c=$(docker ps -qaf name=postfix-mailcow)
  dovecot_c=$(docker ps -qaf name=dovecot-mailcow)
  nginx_c=$(docker ps -qaf name=nginx-mailcow)
  docker restart ${postfix_c} ${dovecot_c} ${nginx_c}
}

#################### RUN  #######################

do_mailcow_ssl() {
  copy_ssl
  restart_mailcow
}

do_mailcow_ssl

Alles anzeigen

Zusätzlich werde ich über das neue Zertifikat per push notification benachrichtigt /lazy_server/notify/push_ssl.sh <domain.de>

Bash

#!/bin/bash


#################################################
#
# Login Push Notification
# Version 1.1
# Copyright 2020, Veit <git@brnk.de>
#
# Tested: 17.09.2018
#
#################################################


##
##  Usage: ./push_ssl.sh <domain>
##  Requires Push Over API (https://pushover.net/)
##


###################  Config  ####################


  mydir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
  . $mydir/cfg/push.cfg

  # Import
  domain="$1"

######### DO NOT EDIT BELOW THIS LINE  ##########


get_cfg() {
  hostname="$(hostname)"
  host=${hostname%.*}
  token="${host}_api_token"
  key="${host}_user_key"
}

generate_msg() {
  title="SSL: Deployed"
  msg="Renewed certificate | Domain: $domain" 
}

send_msg() {
  curl -s \
    --form-string "token=${!token}" \
    --form-string "user=${!key}" \
    --form-string "title=$title" \
    --form-string "message=$msg" \
    https://api.pushover.net/1/messages.json
}

####################  Run  ######################


do_push() {
  get_cfg
  generate_msg
  send_msg
}

do_push

Alles anzeigen

die API keys für die ganzen server liegen noch mal extra in einem config file, aber folgen immer dem gleichen Muster:

Code

<hostname>_api_token="xxxxx"
<hostname>_user_key="xxxx"

...

Zugegeben auf den ersten Blick etwas verwirrend, aber ich nutze die Scripte nun schon seit mehreren Jahren und fahre eigentlich immer die gleich syntax - von daher versuche ich alles so allgemein wie möglich zu halten. Der vorteil von bash scripten im renew-hook ist, dass man die eben jederzeit anpassen kann. ändert sich z.b. der SSH Port kann ich das schnell korrigieren

Der Vorteil ist halt, dass es sich beliebig erweitern lässt mit anderen dingen wie nem nextcloud container z.b.

Geht sicher irgendwie eleganter, aber bash läuft auf allen maschinen und solange der code läuft bin ich zufrieden

nan0

Bensen

Also bei mir macht das Ansible verteilt alle Certs, entfernt alte Certs, startet Dienste durch und testen in immer mehr fällen auch nochmal ob alles passt.

Bensen

geekmonkey vielen lieben Dank für die ausführliche Antwort + deine Scripts

Ich werde mich da morgen mal in Ruhe durchkämpfen.

geekmonkey

Zitat von Bensen

geekmonkey vielen lieben Dank für die ausführliche Antwort + deine Scripts

Ich werde mich da morgen mal in Ruhe durchkämpfen.

Kein Ding, wenn du Fragen hast ruf an ???

Spaß beiseite, wenn ich endlich mal Zeit finde lade ich den ganzen überarbeiteten Quack mal bei github hoch. Gibt sicher besserer und professionellere Lösungen. Aber mein ganzes Script System läuft seit Jahren ohne Probleme und reduziert meine eigentliche Arbeit an den ganzen Servern auf weniger als 10min in der Woche.

Bei sensiblen Daten machts evtl. noch Sinn die Daten zu verschlüsseln oder aber auf das vLAN auszuweichen. Hatte ich auch mal am Anfang, aber dann wars mir zu doof für netcup und nicht netcup Server unterschiedliche Lösungen zu haben.

Edit: Bei der Lösung für ein eher eingeschränktes System würde hier wahrscheinlich ein Teil der User im Dreieck springen. Da wird das Wildcard Zertifikat im renew-hook verschoben, umbenannt, gepackt und per nginx bereit gestellt. Der Empfänger zieht sich das dann per curl.... immerhin gibt's ne htpasswd ??

whoami0501

Wow... nutzt Chromium-basierte Browser haben Sie gesagt, die sind gut haben Sie gesagt... *facepalm*

https://blog.apnic.net/2020/08/21/chr…ot-dns-traffic/

mainziman

Zitat von whoami0501

Wow... nutzt Chromium-basierte Browser haben Sie gesagt, die sind gut haben Sie gesagt... *facepalm*

https://blog.apnic.net/2020/08/21/chr…ot-dns-traffic/

wo is jetzt des Problem?

whoami0501

Zitat von mainziman

wo is jetzt des Problem?

Zitat

Of the 51% observed fewer than four times, all
but 2.86% of these have a first label between 7 and 15 characters in length
(inclusive). Furthermore, most of these match the pattern consisting of only a-z
characters (case insensitive), leaving us with 45.80% of total traffic on this
day that appear to be from Chromium probes

Fast 46% aller Anfragen und damit nach meinem Verständnis auch Last sind sinnlose Müllanfragen aus Chromium, für eine in meinen Augen irgendwie ziemlich fraghafte Funktion, die dem User scheinbar mal wieder das Denken abnehmen soll.

mainziman

Zitat von whoami0501

Fast 46% aller Anfragen und damit nach meinem Verständnis auch Last sind sinnlose Müllanfragen aus Chromium

und die anderen 53,999% von Seiten mit

- Adwords

- Adsense

- Tracking

- anderer 3rd Party Quark

des verbleibende Etwas - 1 von 100 000 Requests - wär somit tatsächlich sinnvoll;

wobei wenn die Server dieser Last nicht gewachsen sind,

dann hätten sie keine Server werden dürfen

Zitat von whoami0501

für eine in meinen Augen irgendwie ziemlich fraghafte Funktion, die dem User scheinbar mal wieder das Denken abnehmen soll.

back to Lynx wär angesagt

ich hätte irgendwo aufgeschnappt, dass dieser Unfug wie ein DDoS wirkt, wobei auch,

wenn die des net aushalten, hätten sie keine Server werden dürfen, den anderen Quark vertragen sie ja auch

des stell ich mir dann bei den kurgepfuschten Unfug von DNS-over-HTTPS od. DNS-over-TLS interessant vor

m_ueberall

Zitat von mainziman

back to Lynx wär angesagt

Wie kann man sich denn so vertippen, um "Lynx" statt "EAF" zu schreiben?

mainziman

Zitat von m_ueberall

Wie kann man sich denn so vertippen, um "Lynx" statt "EAF" zu schreiben?

das war kein Vertippen,

ich meinte tatsächlich den textbasierenden Browser im Linux Terminal: Lynx, klappt ganz ohne X

voja

Habt ihr schon von FritzFrog gelesen?

https://www.guardicore.com/2020/08/fritzf…ts-ssh-servers/

whoami0501

Zitat von whoami0501

Ich hätte da jetzt auch gerne einen Link reingepackt, aber den ihr Shop ist gerade im Wartungsfenster und da wird wohl was an der DB gemacht.

Interessant. Via IPv4 komme ich auf den Mindfactory Webshop, per IPv6 wird mir die Wartungsseite angezeigt.

Habt ihr das auch, wenn ihr auf https://www.mindfactory.de geht?

Paul

Zitat von whoami0501

Interessant. Via IPv4 komme ich auf den Mindfactory Webshop, per IPv6 wird mir die Wartungsseite angezeigt.

Habt ihr das auch, wenn ihr auf https://www.mindfactory.de geht?

Funktioniert hier sowohl mit IPv6 als auch IPv4 einwandfrei.

Benutzer online in diesem Thema