Kategorie-Archiv: Linux

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 😉

Linux: mount error 13 = Permission denied

Veröffentlicht am von — Keine Kommentare ↓

Problem

  • Es soll ein CIFS share von einem Netapp Filer, einem Windows 2000 oder anderem Linux-System gemountet werden; es tritt der Fehler „mount error 13 = Permission denied“ auf.
  • Einzelne (bis zu zwei) Shares können problemlos verbinden werden. Ob die Credentials an der Kommandozeile eingegeben oder aus einer Credentialsfile eingelesen werden ist egal, es tritt immer der selbe Fehler auf.
  • Das sieht zum Beispiel so aus:
# mount -t cifs //exampleserver/share1 /mnt/share1 -o credentials=/root/.credentials/s1
# mount -t cifs //exampleserver/share2 /mnt/share2 -o credentials=/root/.credentials/s2
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Lösung

Die Verbindungssicherheit erlaubt nur zwei Verbindungen pro Hostsitzung für einen Benutzer (=Mountpoint). In älteren Kernels wird dieses System umgagen, wenn das Ziel ein Windows 2000 ist. Netapp nutzt (im Moment) die CIFS-Version von Windows 2000, daher fehlen einige Protokollfeatures.

Möglichkeit 1: Einen älteren Kernel installieren (Redhat: vor 2.6.18-348.18.1)

Möglichkeit 2: Maximal zwei Verbindungen pro Benutzersitzung verwenden.

Referenz: https://access.redhat.com/site/solutions/509393