Einleitung
In diesem Dokument wird beschrieben, wie Secure Copy Push (SCP) für E-Mail-Protokolle (oder andere Protokolltypen) von einer Cisco E-Mail-Security-Appliance (ESA) auf einen externen Syslog-Server eingerichtet und konfiguriert wird.
Hintergrundinformationen
Ein Administrator erhält möglicherweise Fehlermeldungen darüber, dass Protokolle nicht über SCP gesendet werden können, oder es liegen Fehlerprotokolle vor, in denen eine nicht übereinstimmende(r) Schlüssel angegeben wird.
Voraussetzungen
Auf dem Syslog-Server, an den die ESA SCP-Protokolldateien sendet:
- Stellen Sie sicher, dass das zu verwendende Verzeichnis verfügbar ist.
- Überprüfen Sie '/etc/ssh/sshd_config' auf die Einstellungen für AuthorizedKeysFile. Dadurch wird SSH angewiesen, authorized_keys zu akzeptieren und im Basisverzeichnis des Benutzers nach der Zeichenfolge key_name zu suchen, die in der Datei .ssh/authorized_keys geschrieben wurde:
AuthorizedKeysFile %h/.ssh/authorized_keys
- Überprüfen Sie die Berechtigungen des zu verwendenden Verzeichnisses. Sie müssen möglicherweise Berechtigungsänderungen vornehmen:
- Berechtigungen auf '$HOME' sind auf 755 festgelegt.
- Berechtigungen auf '$HOME/.ssh' sind auf 755 festgelegt.
- Berechtigungen für '$HOME/.ssh/authorized_keys' sind auf 600 festgelegt.
Einschränkungen und Berechtigungen auf Dateiebene unter UNIX/Linux
Es gibt drei Arten von Zugriffsbeschränkungen:
Permission Action chmod option
======================================
read (view) r or 4
write (edit) w or 2
execute (execute) x or 1
Es gibt außerdem drei Arten von Benutzereinschränkungen:
User ls output
==================
owner -rwx------
group ----rwx---
other -------rwx
Ordner-/Verzeichnisberechtigungen:
Permission Action chmod option
===============================================================
read (view contents: i.e., ls command) r or 4
write (create or remove files from dir) w or 2
execute (cd into directory) x or 1
Numerische Notation:
Eine weitere Methode zur Darstellung von Linux-Berechtigungen ist eine oktale Notation, wie in dargestellt stat -c %a. Diese Notation besteht aus mindestens drei Ziffern. Jede der drei Ziffern ganz rechts stellt eine andere Komponente der Berechtigungen dar: Besitzer, Gruppe und andere.
Jede dieser Ziffern ist die Summe der zugehörigen Bits im binären Zahlensystem:
Symbolic Notation Octal Notation English
============================================================
---------- 0000 no permissions
---x--x--x 0111 execute
--w--w--w- 0222 write
--wx-wx-wx 0333 write & execute
-r--r--r-- 0444 read
-r-xr-xr-x 0555 read & execute
-rw-rw-rw- 0666 read & write
-rwxrwxrwx 0777 read. write & execute
Für Schritt #3 empfehlen wir, das $HOME-Verzeichnis auf 755 festzulegen: 7=rwx 5=r-x 5=r-x
Dies bedeutet, dass das Verzeichnis über die Standardberechtigungen verfügt -rwxr-xr-x (in oktaler Schreibweise 0755 dargestellt).
Konfigurieren des SCP-Pushvorgangs für Mail-Protokolle auf der ESA
- Führen Sie den CLI-Befehl logconfig aus.
- Wählen Sie die Option Neu.
- Wählen Sie den Protokolldateityp für dieses Abonnement, für IronPort Text Mail-Protokolle "1" oder einen anderen von Ihnen gewählten Protokolldateityp aus.
- Geben Sie den Namen für die Protokolldatei ein.
- Wählen Sie die entsprechende Protokollstufe aus. In der Regel müssen Sie "3" für "Informational" oder eine andere Protokollstufe Ihrer Wahl auswählen.
- Wenn Sie dazu aufgefordert werden, "Wählen Sie die Methode zum Abrufen der Protokolle aus", wählen Sie "3" für SCP Push aus.
- Geben Sie die IP-Adresse oder den DNS-Hostnamen ein, an die die Protokolle übermittelt werden sollen.
- Geben Sie den Port ein, mit dem die Verbindung auf dem Remote-Host hergestellt werden soll.
- Geben Sie das Verzeichnis auf dem Remote-Host ein, um Protokolle zu speichern.
- Geben Sie einen Dateinamen für die Protokolldateien ein.
- Konfigurieren Sie ggf. systembasierte eindeutige Bezeichner wie $hostname, $serialnumber, die an den Protokolldateinamen angehängt werden sollen.
- Legen Sie die maximale Dateigröße vor der Übertragung fest.
- Konfigurieren Sie ggf. das zeitbasierte Rollover der Protokolldateien.
- Wenn Sie gefragt werden "Möchten Sie die Überprüfung der Hostschlüssel aktivieren?", geben Sie "Y" ein.
- Daraufhin wird Ihnen die Meldung angezeigt, dass Sie die folgenden SSH-Schlüssel in Ihrer Datei authorized_keys platzieren müssen, damit die Protokolldateien hochgeladen werden können.
- Kopieren Sie diesen Schlüssel, da Sie den SSH-Schlüssel in Ihrer Datei "authorized_keys" auf dem Syslog-Server ablegen müssen. Fügen Sie den Schlüssel aus der Datei logconfig in die Datei $HOME/.ssh/authorized_keys auf dem Syslog-Server ein.
- Führen Sie auf der ESA den CLI-Befehl commit aus, um Konfigurationsänderungen zu speichern und zu bestätigen.
Die Konfiguration des Protokolls kann auch über die Benutzeroberfläche vorgenommen werden: Systemverwaltung > Protokollabonnements
Hinweis: Im Kapitel "Protokollierung" des ESA-Benutzerhandbuchs finden Sie vollständige Details und weitere Informationen.
Bestätigung
Hostschlüsselkonfiguration
Führen Sie den Befehl logconfig > hostkeyconfig aus. Es sollte ein Eintrag für den konfigurierten Syslog-Server als "ssh-dss" mit einem abgekürzten Schlüssel angezeigt werden, der dem während der Konfiguration bereitgestellten Schlüssel ähnelt.
myesa.local > logconfig
...
[]> hostkeyconfig
Currently installed host keys:
1. 172.16.1.100 ssh-dss AAAAB3NzaC1kc3MAAACBAMUqUBGztO0T...OutUns+DY=
Systemprotokolle
In den Systemprotokollen werden folgende Informationen aufgezeichnet: Boot-Informationen, Warnungen zum Ablauf von Lizenzen für virtuelle Appliances, DNS-Statusinformationen und Kommentare, die Benutzer mit dem Befehl commit eingeben. Systemprotokolle sind nützlich, um den grundlegenden Zustand der Appliance zu beheben.
Wenn Sie den Befehl tail system_logs über die CLI ausführen, erhalten Sie einen Überblick über den Systemstatus.
Sie können auch den CLI-Befehl rollovernow auswählen und die Nummer auswählen, die der Protokolldatei zugeordnet ist. Sie sehen die Protokolldatei SCP zu Ihrem Syslog-Server in system_logs:
myesa.local > tail system_logs
Press Ctrl-C to stop.
Thu Jan 5 11:26:02 2017 Info: Push success for subscription mail_logs: Log mail_logs.myesa.local.@20170105T112502.s pushed via SCP to remote host 172.16.1.100:22
Erweiterte Fehlerbehebung
Wenn es weiterhin Probleme mit der Verbindung zum Syslog-Server gibt, vom lokalen Host aus und mit ssh, führen Sie "ssh testuser@hostname -v" aus, um den Benutzerzugriff im ausführlichen Modus zu testen. Dies kann bei der Fehlerbehebung helfen, um zu zeigen, wo die SSH-Verbindung nicht erfolgreich ist.
$ ssh testuser@172.16.1.100 -v
OpenSSH_7.3p1, LibreSSL 2.4.1
debug1: Reading configuration data /Users/testuser/.ssh/config
debug1: /Users/testuser/.ssh/config line 16: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to 172.16.1.100 [172.16.1.100] port 22.
debug1: Connection established.
debug1: identity file /Users/testuser/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/testuser/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/testuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to 172.16.1.100:22 as 'testuser'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-dss SHA256:c+YpkZsQyUwi3tkIVJFXHAstwlkdewO1G0s7P2khV7U
debug1: Host '172.16.1.100' is known and matches the DSA host key.
debug1: Found key in /Users/testuser/.ssh/known_hosts:5
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: Skipping ssh-dss key /Users/testuser/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/testuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/testuser/.ssh/id_ecdsa
debug1: Trying private key: /Users/testuser/.ssh/id_ed25519
debug1: Next authentication method: password
testuser@172.16.1.100's password: <<< ENTER USER PASSWORD TO LOG-IN >>>
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (password).
Authenticated to 172.16.1.100 ([172.16.1.100]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending env LC_CTYPE = en_US.UTF-8
Feedback