Exim4 GnuTLS error (gnutls_handshake): An unexpected TLS packet was received - exim

I have Exim4-heavy, GunTLS
it was configured correctly and the mails was working fine
suddenly I not be able to use TLS however the SSL certificates is verified
when I telnet to port 465 it gives
# telnet localhost 465
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ehlo foo
Connection closed by foreign host.
but when I telnet to port 587
# telnet localhost 587
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 box01.xxxxxxxxx.com ESMTP Exim 4.90_1 Ubuntu Wed, 29 Apr 2020 15:49:41 +0200
ehlo foo
250-box01.xxxxxxxxx.com Hello foo [127.0.0.1]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
starttls
220 TLS go ahead
ehlo foo
Connection closed by foreign host.
I didn't update anything in the configuration and it was working before 5 days
also I got a lot of this error in log
2020-04-29 15:50:02 TLS error on connection from (foo) [127.0.0.1]:55212 I=[127.0.0.1]:587 (gnutls_handshake): An unexpected TLS packet was received.

I had the similar problems with exim4. I'll share some of the configurations i made to get it to work.
echo "IGNORE_SMTP_LINE_LENGTH_LIMIT='true'" >> /etc/exim4 exim4.conf.localmacros
echo "REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *">> /etc/exim4/exim4.conf.localmacros
echo "REQUIRE_PROTOCOL = smtps">> /etc/exim4/exim4.conf.localmacros
echo "MAIN_HARDCODE_PRIMARY_HOSTNAME = localhost" >> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_ENABLE = 1">> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_CERTIFICATE=/opt/ssl/localhost.pem" >> /etc/exim4/exim4.conf.localmacros
echo "MAIN_TLS_PRIVATEKEY=/opt/ssl/localhost-key.pem" >> /etc/exim4/exim4.conf.localmacros
echo "daemon_smtp_ports = 25 : 465" >> etc/exim4/exim4.conf.localmacros
echo "tls_on_connect_ports = 465" >> /etc/exim4/exim4.conf.localmacros
echo "dc_other_hostnames='localhost'" >> /etc/exim4/update-exim4.conf.conf
echo "dc_eximconfig_configtype='satellite'" >> /etc/exim4/update-exim4.conf.conf
echo "dc_smarthost='localhost::465'" >> /etc/exim4/update-exim4.conf.conf
I also made sure exim is allowed to read the certificates.
chown root:Debian-exim /opt/ssl/key.pem
chown root:Debian-exim /opt/ssl/cert.pem
chmod 640 /opt/ssl/key.pem
chmod 640 /opt/ssl/cert.pem

Related

Connection to Redis through SSH tunnel: reset by peer

My Redis instance is installed and run at VIRTUAL_MACHINE. I connect to VIRTUAL_MACHINE via SSH tunnel through TUNNEL_SERVER to work from my local machine.
Tunnel string is the following:
ssh -L 0.0.0.0:10011:VIRTUAL_MACHINE:22 -L 0.0.0.0:10004:VIRTUAL_MACHINE:6379 -o ExitOnForwardFailure=yes -o ServerAliveInterval=15 -o ServerAliveCountMax=3 username#TUNNEL_SERVER
The issue is I can't connect to Redis instance from the local machine:
redis-cli -h 0.0.0.0 -p 10004
0.0.0.0:10004> ping
Error: Connection reset by peer
telnet 0.0.0.0 10004
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
Connection closed by foreign host.
On the remote machine (VIRTUAL MACHINE):
redis-cli -h localhost -p 6379
localhost:6379> ping
PONG
netstat -an | grep 6379
tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN
redis.conf
bind 127.0.0.1
bind 0.0.0.0
protected-mode no
port 6379
timeout 60
tcp-keepalive 600
daemonize no
Because of Redis, I can't also connect to Flower (Celery).
If you have any idea about possible reasons, please help me to figure it out.
Thanks!
Only just saw this,
Can you SSH to 0.0.0.0:10011 and have access to the VIRTUAL_MACHINE?
Also are your auth creds for the TUNNEL_SERVER the same as for the VIRTUAL_MACHINE?
Forgive me if you already have, but, I would get SSH working to the VIRTUAL_MACHINE first via the TUNNEL_SERVER and then rework that to tunnel REDIS

Nagios CHECK_NRPE Could not complete SSL handshake

I checked all over, there are many answers to this issue, but none worked.
I am following this tutorial:
https://www.digitalocean.com/community/tutorials/how-to-install-nagios-4-and-monitor-your-servers-on-ubuntu-16-04
The Nagios host is ubuntu 16.04, the client is ubuntu 18.04
Nagios® Core™ 4.3.4
The Nagios server and web is running ok, I can see the localhost status us 'up' in the dashboard.
Something very weird: I installed NRPE 3.2.1 on both the host and the client, but for some reason on the host is 2.15
Host:
root#nagios-1:/tmp/nrpe-nrpe-3.2.1# /usr/local/nagios/libexec/check_nrpe -H 10.142.0.50
NRPE v2.15
Client:
$ /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1
NRPE v3.2.1
Just to make sure, when running check_nrpe from client to server I am using '-2' option to force v2 packets, but I am still getting to error
I added the client ip to the nrpe.cnf (on server), and to be sure also the server ip to the client nrpe.cfg file.
I enabled debug to see the messages in the syslog. this is the response:
Dec 4 00:35:47 nagios-1 check_nrpe: Remote 10.142.0.50 accepted a Version 2 Packet
Dec 4 00:35:51 nagios-1 nrpe[9953]: Connection from 10.142.0.11 port 49889
Dec 4 00:35:51 nagios-1 nrpe[9953]: Host address is in allowed_hosts
Dec 4 00:35:51 nagios-1 nrpe[9953]: Handling the connection...
Dec 4 00:35:51 nagios-1 nrpe[9953]: Error: Could not complete SSL handshake. 1
Dec 4 00:35:51 nagios-1 nrpe[9953]: Connection from closed.
On the host, port 5666 is open and listening
# netstat -at | grep nrpe
tcp 0 0 *:nrpe *:* LISTEN
tcp6 0 0 [::]:nrpe [::]:* LISTEN
I compiled nrpe with --
I am not using xinetd. I use the daemon
# ps aux | grep nrpe
nagios 9866 0.0 0.1 23960 2680 ? Ss 00:35 0:00 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
Host nrpe conf file:
# grep -o '^[^#]*' /etc/nagios/nrpe.cfg
log_facility=daemon
pid_file=/var/run/nagios/nrpe.pid
server_port=5666
nrpe_user=nagios
nrpe_group=nagios
allowed_hosts=127.0.0.1, 10.142.0.50, 10.142.0.0/20,10.142.0.11
dont_blame_nrpe=1
allow_bash_command_substitution=0
debug=1
command_timeout=60
connection_timeout=300
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200
include=/etc/nagios/nrpe_local.cfg
include_dir=/etc/nagios/nrpe.d/
If you need more info let me know and I will add it.
I found the answer!
I had two versions of NRPE on the host. The deamon was running 2.15. I had to kill this version, and I manually run the 3.2.1 version from its other location
/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f
After that I was able to get a response in the client

Why isn't netcat udp message being recieved by netcat listener?

I have netcat listening for udp traffic on port 8125 in terminal 1
nc -ul 8125
and in terminal 2 I run the following (a test dogstatsd message for troubleshooting a datadog client connection):
echo "test_metric:1|c" | nc -u -w 1 -v localhost 8125
#found 0 associations
#found 1 connections:
# 1: flags=82<CONNECTED,PREFERRED>
# outif lo0
# src ::1 port 50397
# dst ::1 port 8125
# rank info not available
#Connection to localhost port 8125 [udp/*] succeeded!
I would expect to see test_metric:1|c show up in the output of terminal 1, but there is no output at all.
Can you help me understand why the udp message is not showing up and how to successfully send the udp message?
I still don't know why it makes a difference, but adding the -4 option made it work
echo "test_metric:1|c" | nc -u -4 -w 1 localhost 8125
Here's the man page on the option:
-4 Forces nc to use IPv4 addresses only.

Unable to connect to Postgres via PHP but can connect from command line and PgAdmin on different machine

I've had a quick search around (about 30 minutes) and tried a few bits, but nothing seems to work. Also please note I'm no Linux expert (I can do most basic stuff, simple installs, configurations etc) so some of the config I have may be obviously wrong, but I just don't see it! (feel free to correct any of the configs below)
The Setup
I have a running instance of PostgreSQL 9.3 on a Red Hat Enterprise Linux Server release 7.1 (Maipo) box. It's also running SELinux and IPTables.
IPTables config (added in 80, 443 and 5432.. and also 22, but that was done before...)
# sample configuration for iptables service
# you can edit this manually or use system-config-firewall
# please do not ask us to add additional ports/services to this default configuration
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5432 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
PostgreSQL pg_hba.cong (deleted all comments)
# TYPE DATABASE USER ADDRESS METHOD
local all all ident
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
host all all 0.0.0.0/0 md5
postgresql.conf (only changed the listen address)
listen_addresses = '*'
Setup new users
$ sudo -u postgres /usr/pgsql-9.3/bin/createuser -s "pgadmin"
$ sudo -u postgres /usr/pgsql-9.3/bin/createuser "webuser"
$ sudo -u postgres psql
postgres=# ALTER ROLE "pgadmin" WITH PASSWORD 'weakpassword';
ALTER ROLE
postgres=# ALTER ROLE "webuser" WITH PASSWORD 'anotherweakpassword';
ALTER ROLE
postgres=# \q
Test connection
psql -U [pgadmin|webuser] -h [localhost|127.0.0.1|hostname] -W postgres
Password for user [pgadmin|webuser]: [weakpassword|anotherweakpassword]
psql (9.3.7)
Type "help" for help.
postgres=# \q
As you can see I tested 127.0.0.1, localhost and the hostname on the command line to make sure I could connect use all three identifiers with both different accounts.
I've also connected using PgAdmin from my windows box, and it connects using the hostname and ip address using both users.
The problem...
The problem comes when I try to connect from PHP via Apache (it doesn't happen if I run the same script on the command line)
PHP Test Script
<?php
error_reporting( E_ALL );
ini_set('display_errors', '1');
$conn1 = pg_connect("host='localhost' port='5432' user='pgadmin' password='weakpassword' dbname='postgres'");
$conn2 = pg_connect("host='127.0.0.1' port='5432' user='pgadmin' password='weakpassword' dbname='postgres'");
$conn3 = pg_connect("host='localhost' port='5432' user='webuser' password='anotherweakpassword' dbname='postgres'");
$conn4 = pg_connect("host='127.0.0.1' port='5432' user='webuser' password='anotherweakpassword' dbname='postgres'");
$status1 = pg_connection_status( $conn1 );
$status2 = pg_connection_status( $conn2 );
$status3 = pg_connection_status( $conn3 );
$status4 = pg_connection_status( $conn4 );
# Check connection
if (
$status1 === false || $status1 === PGSQL_CONNECTION_BAD ||
$status2 === false || $status2 === PGSQL_CONNECTION_BAD ||
$status3 === false || $status3 === PGSQL_CONNECTION_BAD ||
$status4 === false || $status4 === PGSQL_CONNECTION_BAD
)
{
throw new Exception("I'm broken");
}
# Do a query
$res1 = pg_query( $conn1, "SELECT * FROM pg_type LIMIT 1" );
$res2 = pg_query( $conn2, "SELECT * FROM pg_type LIMIT 1" );
$res3 = pg_query( $conn3, "SELECT * FROM pg_type LIMIT 1" );
$res4 = pg_query( $conn4, "SELECT * FROM pg_type LIMIT 1" );
# Test one result.
$row1 = pg_fetch_row($res1);
$row2 = pg_fetch_row($res2);
$row3 = pg_fetch_row($res3);
$row4 = pg_fetch_row($res4);
echo $row1[0] . "\n";
echo $row2[0] . "\n";
echo $row3[0] . "\n";
echo $row4[0] . "\n";
On the command line I get the following output (as expected)
bool
bool
bool
bool
But in the browser I get the following
Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Permission denied Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? in /var/www/html/test.php on line 6
Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? in /var/www/html/test.php on line 7
Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Permission denied Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? in /var/www/html/test.php on line 8
Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? in /var/www/html/test.php on line 9
Fatal error: Uncaught exception 'Exception' with message 'I'm broken' in /var/www/html/test.php:25 Stack trace: #0 {main} thrown in /var/www/html/test.php on line 25
I've got a feeling it's something to do with IPTables not allowing the connect when coming through Apache for some reason, but I'm stumped (I bet it's stupidly simple)
I think that covers everything...
Help me Stack Overflow, you're my only hope!
OK... Answered... Was a problem with SELinux. Needed to run the following....
setsebool -P httpd_can_network_connect_db on
Also if you need to check if SELinux is causing issues it can be turned off with the following
setenforce 0
Then once finished
setenforce 1
Anyways, done... onwards!

How to enable SSH on SLES 12?

I am trying to enable ssh connection to suse linux. I have sshd service running:
peeyush#linux-pohb:~/gccgo.work> systemctl status sshd.service
sshd.service - OpenSSH Daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Thu 2015-03-19 18:36:05 IST; 3h 50min ago
Process: 5702 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
Main PID: 6035 (sshd)
CGroup: /system.slice/sshd.service
└─6035 /usr/sbin/sshd -D
Mar 19 18:36:01 linux-pohb sshd-gen-keys-start[5702]: Checking for missing se...
Mar 19 18:36:05 linux-pohb sshd-gen-keys-start[5702]: ssh-keygen: generating ...
Mar 19 18:36:06 linux-pohb sshd[6035]: Server listening on 0.0.0.0 port 22.
Mar 19 18:36:06 linux-pohb sshd[6035]: Server listening on :: port 22.
Hint: Some lines were ellipsized, use -l to show in full.
It is listening on port 22 fine:
peeyush#linux-pohb:~/gccgo.work> netstat -an | grep :22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
But I am not able to connect to it.
[root#lep8a peeyush]# ssh root#192.168.122.19
ssh: connect to host 192.168.122.19 port 22: Connection timed out
My head is aching with finding solutions on internet. Nothing is working.
Could you guys please help me out?
Check if your firewall accepts incoming TCP connections on port 22:
# iptables -nL | grep 22
If the result is empty, you have to add a rule in your firewall.
Open Yast and firewall configuration:
# yast firewall
Goto "Allowed Services" and add "Secure Shell Server". Save and quit Yast and try to connect.
Comment: If you have disabled your firewall completly (not recommended) this answer does not apply.
Run this command:
systemctl enable sshd.service
Then make necessary changes in your /etc/ssh/sshd_config file, and start sshd via:
systemctl start sshd.service
I was dealing with the same problem in SUSE Linux Enterprise Server 15 x86-64. Within the system I was able to # ssh 127.0.0.1 (so the sshd service was working correctly), but from other nodes I got a "Timed out" message.
First, I checked the firewall rules (see answer from xloto):
# iptables -nL | grep 22
Resulted in an empty return message, so we need to set an additional rule.
To set the the firewall rule for SSH's standard port 22, I followed another tutorial (as I do not have a GUI):
# firewall-cmd --permanent --add-service=ssh
# firewall-cmd --reload
It worked for my case, but I'm not sure whether this is best practice.