[CENTOS7] SSHD onbereikbaar met firewall disabled

[RoRoo]

Dit topic lijkt een beetje op deze: [CentOS7] httpd/sshd niet te bereiken ondanks disabled fw
Ware het niet dat er een paar cruciale zaken anders zijn.

Nieuwe installatie van CentOS7 op Hyper-V 2012R2 LIS 4.0.11 geinstalleerd.

1. IPSEC tunnel tussen 2 routers op locaties
2. Andere services (Apache e.d. zijn gewoon bereikbaar)
3. SELinux staat uit
4. Firewall staat uit
5. Hosts.deny en Hosts.allow zijn leeg
6. SSHD op andere poort dan 22 draaien = werkende connectie
7. routes staan correct. Static routes aangemaakt voor de zekerheid, geen verschil.
8. logs geven niks (messages, secure)

Internet, werkt
Ping, werkt
Apache server, werkt
SSHD (OpenSSH) niet.

Doe ik een nc -l 0.0.0.0 9876 en probeer vanaf een machine in het remote subnet de sessie op te bouwen, komt er niets in beeld na het random karakter meppen.

Wireshark, geeft niets aan. Verkeer komt niet aan.

router firewall staat helemaal open voor verkeer van en naar tunnel adressen local en remote.
Vanaf CENTOS 7 machine kan ik naar een andere machine in het remote subnet connecten.
van de andere machine naar de CENTOS 7 machine, gaat het pas zodra ik openSSH op iets anders dan 22 laat luisteren.

Wat mis ik toch steeds

Iemand nog een goed idee?

sshd_config file:

code:

#       $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel VERBOSE

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
#KerberosUseKuserok yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox          # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# override default of no subsystems
Subsystem       sftp    /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

[ Voor 40% gewijzigd door RoRoo op 07-09-2015 17:04 ]

[CAPSLOCK2000]

Ik denk niet dat het iets met je SSH-configuratie te maken heeft.
Dat poort 22 niet werkt maar op andere poorten wel suggereert dat er toch iets van een firewall in je netwerk zit.
Dat je met 'nc' niks doorkrijgt suggereert hetzelfde. Waarom SSH op andere poorten wel werkt snap ik alleen niet. Was dat een specifieke poort waar op je hebt getest? Werkt SSH op poort 9876 wel?

Heb je ook Windows / Hyper-V gezocht? Komen pakketjes wel aan op je Hyper-V host?

Hoe ver kun je de pakketjes volgen van bron tot bestemming?

[Hero of Time]

Gebruik ook eens tcptracepath. Hiermee traceer je de verbinding via het TCP protocol, ipv ICMP. Door een poort op te geven kan je precies uitzoeken welke poorten er wel werken en waar 't mogelijk mis gaat. Zoals je zegt gaat poort 80 van Apache wel goed, test daar eerst mee en check welke hops je tegen komt. Doe 't dan met een andere poort, die je met nc bijvoorbeeld open zet en uiteraard poort 22.

Heb je niet ergens in de firewall (tussen of vlak voor de machine) extra regels staat om dat soort verkeer tegen te houden of anders te routeren (NAT)?

[johnkeates]

Heb je alle offloading zaken uitgezet? Soms zijn er problemen met virtio adapters die shmem als transport gebruiken ter vervanging van virtuele L1 en L2.

Verder kan je ook tcpdump en wireshark er even bij pakken. Nu ben je vooral aan het gokken en shotgun debuggen

[Donaldinho]

Start je sshd uberhaubt wel goed op als je hem op poort 22 laat draaien.

Wat staat er in je sshd logging? (evt ssh opstarten met -d/-D of vergelijkbare debug mode)
Zie je als je ssh op poort 22 gestart hebt een listener draaien, en welk ip adres?
kan je als je ssh op poort 22 gestart hebt lokaal via ssh connecten?

[ Voor 9% gewijzigd door Donaldinho op 09-09-2015 11:38 ]

[RoRoo]

Hero of Time schreef op maandag 07 september 2015 @ 19:30:
Gebruik ook eens tcptracepath. Hiermee traceer je de verbinding via het TCP protocol, ipv ICMP. Door een poort op te geven kan je precies uitzoeken welke poorten er wel werken en waar 't mogelijk mis gaat. Zoals je zegt gaat poort 80 van Apache wel goed, test daar eerst mee en check welke hops je tegen komt. Doe 't dan met een andere poort, die je met nc bijvoorbeeld open zet en uiteraard poort 22.

Heb je niet ergens in de firewall (tussen of vlak voor de machine) extra regels staat om dat soort verkeer tegen te houden of anders te routeren (NAT)?

Bedankt voor deze supertip!
tcptracepath nergens kunnen vinden in de repositories, maar wel de (windows) tool tracetcp.exe

Er bleek dus een rule in onze router te staan die het SSH verkeer naar ELKE host.. gewoon over de wan connectie naar buiten gooide ipv de tunnel in

Rule disabled en connectie komt tot stand..
Dit heb ik dus niet voorbij zien komen in wireshark.. Verkeerd gekeken dus..

Deze tool gaat dus mooi hier de KB in.. Werelds..

Ik dank u allen voor het meedenken.

[Hero of Time]

Kan ook zijn dat het tcptraceroute is, deed 't even uit m'n hoofd. Het moet in de repo's staan.

[Blokker_1999]

Die bestaat wel: http://linux.die.net/man/1/tcptraceroute . Interessante tool

[d1ng]

tcptraceroute is (in CentOS7) onderdeel van traceroute en doet hetzelfde als traceroute met vlaggetje -T.

code:

traceroute -T <ipadres> -p <port>

[ Voor 13% gewijzigd door d1ng op 12-09-2015 11:44 ]

[RoRoo]

Nice one!