Kategorie-Archiv: Linux

Debian: Es gibt keine öffentlichen Schlüssel für die folgenden Schlüssel-IDs …

Veröffentlicht am von — 2 Kommentare ↓

Problem

apt-get update schlägt „seit neuestem“ mit seltsamen Schlüsselpaar-Fehlermeldungen fehl:

root@geloud:~# apt-get update
OK   http://security.debian.org wheezy/updates Release.gpg
OK   http://security.debian.org/ wheezy/updates/main Translation-en
OK   http://security.debian.org wheezy/updates Release
OK   http://security.debian.org wheezy/updates/main Sources
OK   http://ftp.at.debian.org wheezy Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-de
OK   http://ftp.at.debian.org/debian/ wheezy/main Translation-en
OK   http://ftp.at.debian.org wheezy-updates Release.gpg
OK   http://ftp.at.debian.org/debian/ wheezy-updates/main Translation-en
OK   http://security.debian.org wheezy/updates/main amd64 Packages
OK   http://ftp.at.debian.org wheezy Release
OK   http://ftp.at.debian.org wheezy-updates Release
OK   http://ftp.at.debian.org wheezy/main Sources
OK   http://ftp.at.debian.org wheezy/main amd64 Packages
OK   http://ftp.at.debian.org wheezy-updates/main Sources
Hole:1 http://ftp.at.debian.org wheezy-updates/main amd64 Packages/DiffIndex [1.012 B]
Es wurden 1.012 B in 0 s geholt (4.720 B/s)
Paketlisten werden gelesen... Fertig
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
9D6D8F6BC857C906
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010
W: Es gibt keine Öffentlichen Schlüssel für die folgenden Schlüssel-IDs:
7638D0442B90D010

Alternativ jammert apt auch gerne auf English:

There is no public key available for the following key IDs: 8B48AD6246925553

Lösung

Die Schlüssel-IDs 9D6D8F6BC857C906 und 7638D0442B90D010 gehören zu den Debian Wheezy Update Package Repositorys und sind Teil des Keyring-Pakets (die Update-Pakete benötigen das Keyring-Archiv). Einfach den debian-keyring installieren:

root@geloud:~# apt-get install debian-keyring debian-archive-keyring

Dann läuft das nächste apt-get auch schon fehlerfrei durch:

root@geloud:~# apt-get update

(Referenz: http://gnuru.org/article/1486/debian-public-keys-error-2)

Tomcat liefert „ssl_error_weak_server_ephemeral_dh_key“ im Firefox

Veröffentlicht am von — Keine Kommentare ↓

Problem

Firefox ab Version 39 zeigt bei von einem frischen Tomcat ausgelieferten Webseiten nur noch diese Alternativlose Fehlermeldung an:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit oputils.pflitsch.de aufgetreten.
SSL hat einen schwachen kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht
"Server-Schlüsselaustausch" empfangen.
(Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

Lösung

Der unsichere DH/SSL Schlüsselaustausch ist anfällig für die „Logjam“ Attacke (https://weakdh.org), aber noch die Defaultkonfiguration für neue SSL-Connectoren im Tomcat.

In der server.xml kann man im Abschnitt <connector> die passenden Cipher-Suiten vorgaben. Bewährt hat sich diese Liste hier, weil sie auch noch die älteren aber sicheren SSL-Handshakes für den Internet-Explorer enthält.

<Connector
   port="443"
   protocol="HTTP/1.1"
   SSLEnabled="true"
   keystoreFile="uggliest.keystore"
[...]
   ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
/>

CUPS meldet „Bad Request“ bei SSL auf IP/FQDN

Veröffentlicht am von — Keine Kommentare ↓

Problem

Bei der Installation von CUPS (hier: 1.5.3) auf Debian gibt es ein unangenehmes Phänomen bei der Verwendung von ganzen Host- oder Domainnamen. Das CUPS-Webfrontend setzt standartmäßig bei einigen Operationen (Drucker ändern, Drucker löschen und so weiter) voraus, das die Seite via SSL geöffnet wird. Dazu wird auch ein Redirect-Link angezeigt. Klick man diesen, erscheint:

Bad Request

Passiert der Aufruf nicht über den im Zertifikat angegebenen CN, werfen erstens die großen Browser alle eine ’sec_error_untrusted_issuer‘ Meldung und zweitens das CUPS einen „Bad Request„. Dieser HTTP-Fehler 400 verwirrt, denn in der CUPS config ist der port korrekt eingetragen. Die Standardmäßige Wahl der Konfigurationsparameter ist hier etwas ungeschickt.

Lösung

Über die IP-Adresse (192.168.x.y:631) geht das Webfrontend auf, es sei denn das Zertifikat ist falsch. Der schnelle Admin erlaubt einfach alle eingehenden Anfragen.

  1. Korrektes, passendes Zertifikat für CUPS hinterlegen 
    openssl req -new -x509 -keyout /etc/cups/ssl/server.key -out /etc/cups/ssl/server.crt -days 3650 -nodes

    (Hier dann dem Assistenten folgen, wichtig ist wie immer der „Common Name“ (CN))

  2. Konfigurationsdatei /etc/cups/cupsd.conf anpassen: 
    ServerAlias *
  3. Neustart der CUPS-Dienste 
    /etc/init.d/cups restart

CentOS 6 statische IP-Adresse an der Shell konfigurieren

Veröffentlicht am von — Keine Kommentare ↓

logo_smallStatische IP-Adresse in CentOS konfigurieren

Die Netzwerkkonfiguration in CentOS Linux ist in der Datei

/etc/sysconfig/network-scripts/ifcfg-eth0

abgelegt. Der Inahlt der Datei sieht bei einer statischen IP so aus:

DEVICE="eth0"
 NM_CONTROLLED="yes"
 ONBOOT=yes
 HWADDR=DE:AD:BE:EF:F1:04
 TYPE=Ethernet
 BOOTPROTO=static
 NAME="System eth0"
 UUID=5fbfffff-0fff-7ffb-4ff1-fffffff3e02
 IPADDR=192.168.66.6
 NETMASK=255.255.0.0

Default Gateway

Für das Routing ist diese Datei

/etc/sysconfig/network

verantwortlich, die dann so aussieht:

NETWORKING=yes
HOSTNAME=foobaerchen
GATEWAY=192.168.1.1

DNS-Einstellungen

DNS-Einstellungen sind wie bei (nahezu jedem) Linux in der

/etc/resolv.conf

abgelegt. Der Inahlt sieht dann auch entsprechend einfach aus:

nameserver 8.8.8.8      # Replace with your nameserver ip
 nameserver 192.168.1.1  # Replace with your nameserver ip

Wenn alle diese Einstellungen getätigt sind, einmal das Netzwerk neu starten:

/etc/init.d/network restart

 

Linux später neu starten ohne angemeldete Shell

Veröffentlicht am von — 1 Kommentar ↓

Problem

Ein Linux/Unix Computer soll später neu starten. Der Reboot soll nicht permanent angelegt sein (z.B. als Cronjob) und es gibt kein screen auf dem System. Die Shell ist bis dahin auch nicht mehr verbunden, daher fällt ein simpler ’shutdown‘ Befehl aus.

Lösung

Das Shutdown mir nohub starten. nohup ist ein Befehl, ein Programm auszuführen, wobei dieses dann das HUP-Signal unterdrückt. Dadurch kann man das Programm starten und laufen lassen, auch wenn es kein offenes TTY mehr gibt.

Üblicherweise nutzt man nohup, um Dienste im Hintergrund zu starten und diese so von der Login-Shell zu trennen. Ausgaben des aufgerufenen Programmes werden automatisch in die Datei nohup.out geleitet, die im Verzeichnis angelegt wird, von dem aus der Befehl ausgeführt wurde. Um zu verhindern, daß das Programm nicht weiterläuft, weil es auf Eingaben wartet, ist es außerdem manchmal notwendig, auch die Standard-Eingabe etwa mit „</dev/null“ umzulenken.

In unserem „Sei still und boote einfach neu“ Beispiel könne wir auf die Ausgane verzichten, daher sieht die einfachste Lösung so aus:

nohub shutdown -r -t sec 120 >/dev/null 2>&1 &

ACHTUNG. nohub ist nicht die Lösung der Wahl, um Dienste permanent im System zu verankern. Wer sein node.js so startet, hat weder nodeJS noch das system.d Konzept verstanden 😉