Hi, slackers. I'm trying to configure a machine to allow ssh connections,
but I'm facing some problems. Let me describe what I have: I set up a
fresh Slackware64-current (15.0-rc1) install, without KDE and XFCE
packages. I configured shhd_config file to port 3333, which is the only
one opened at the facility where my server (let's call it server1) is
installed. Then, I tested the ssh inside local network, and it did worked.
When I did got home, I tried again, and I got "connection timed out".

I thoughted that could be my router, so I asked a co-worker the credentials
from another machine (let's call it server2), with ssh configured, located
at the same facility, and it works fine (same port, same client).

My conclusions: It is not my router, it is not my client configuration, it
is not some firewall somewhere. It is, probably, server1's configuration.

Since local ssh connection worked, I did a ssh from server2 to server1, and
it worked. So, I copied the shhd_config file from server2 to server1, and
tried connect again directly to server1 with no sucess: still got
"connection timed out".

Aditional information: server2 is running Ubuntu; netstat shows the port
3333 listening to tcp and tcp6; iptables and hosts.deny are clean; I can't
ping any machine inside the facilty from outside; I can use telnet to touch
server2, but not server1 (connection time out again).

Most online tutorials work with 3 possibilities: wrong hosts, wrong port or
firewall restrictions. None of these seems to be the case.

What am I missing here?

--
May the Source be with you!
carriunix

On Sat, 04 Sep 2021 04:32:20 +0000, carriunix wrote:
> Hi, slackers. I'm trying to configure a machine to allow ssh
> connections, but I'm facing some problems. Let me describe what I have:
> I set up a fresh Slackware64-current (15.0-rc1) install, without KDE and
> XFCE packages. I configured shhd_config file to port 3333, which is the
> only one opened at the facility where my server (let's call it server1)
> is installed. Then, I tested the ssh inside local network, and it did
> worked. When I did got home, I tried again, and I got "connection timed
> out".
>
> I thoughted that could be my router, so I asked a co-worker the
> credentials from another machine (let's call it server2), with ssh
> configured, located at the same facility, and it works fine (same port,
> same client).

Are server1 and server2 configured with public IP addresses? Or (as I
would guess) are they behind some kind of NAT firewall?

If they are behind some NAT firewall I would doublecheck the settings of
that. The fact that it has been configured to allow port 3333 connections
to server2 might not for sure mean that also port 3333 connections to
server1 are allowed.

I don't think that you have done anything wrong in the configuration of
server1, but if that would be the one blocking incoming requests it would
probably explain why it did that in some system log file.
> My conclusions: It is not my router, it is not my client configuration,
> it is not some firewall somewhere. It is, probably, server1's
> configuration.
>
> Since local ssh connection worked, I did a ssh from server2 to server1,
> and it worked. So, I copied the shhd_config file from server2 to
> server1, and tried connect again directly to server1 with no sucess:
> still got "connection timed out".

If the problem really were server1 configuration you would not be able to
connect from any remote machine at all or see some explanation in the log
file why some remote machines are discriminated.

> Aditional information: server2 is running Ubuntu; netstat shows the port
> 3333 listening to tcp and tcp6; iptables and hosts.deny are clean; I
> can't ping any machine inside the facilty from outside; I can use telnet
> to touch server2, but not server1 (connection time out again).

When you connect from the outside, how do you differ between server1 and
server2? If they are behind a NAT router my guess is that router would
have only one IP address? If they are not behind a NAT router but have
their own public IP addresses, what kind of device do you have that only
allows port 3333?

regards Henrik

carriunix <carriunix@gmail.com> writes:
[ snip ]

There's a lot of verbiage here an a long description of your own and
other systems which I can't be bothered to read.

What is missing though are cut and pasted commands that you've tried
with their responses, try this next time.

Deeply buried within that text it appears that you are getting a
"connection timed out" response. This is the response you usually get
when connected to a non-reachable host eg.:

$ ssh -o ConnectTimeout=4 3.3.3.3
ssh: connect to host 3.3.3.3 port 22: Connection timed out

This should indicate that you cannot reach the host. If the host is
reachable but I'm using the wrong port, or there's a configuration or
authentication failure I get another response.

You can try telnet to check that you got the correct host and port,
eg.:

$ telnet motozw 7022
Trying 192.168.43.125...
Connected to motozw.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.6

Indicating that you've reached a ssh-port.

--
... Øyvind - soon to appear in a kill file near you.
... Ignorance can be cured; stupidity is forever.

Hi, Henrik. Thanks for the reply.

On 2021-09-04, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:

> Are server1 and server2 configured with public IP addresses? Or (as I
> would guess) are they behind some kind of NAT firewall?

There is some firewall: if I try to use any port but 3333, connection fails.
Even if properly set in sshd_config. However, the IP used is the public IP,
those that we get using curl or wget testing.

> If they are behind some NAT firewall I would doublecheck the settings of
> that. The fact that it has been configured to allow port 3333 connections
> to server2 might not for sure mean that also port 3333 connections to
> server1 are allowed.

I must contact the network admin (oh, here comes the burocracy!) to be sure.

> If the problem really were server1 configuration you would not be able to
> connect from any remote machine at all or see some explanation in the log
> file why some remote machines are discriminated.

Ok.

> When you connect from the outside, how do you differ between server1 and
> server2? If they are behind a NAT router my guess is that router would
> have only one IP address? If they are not behind a NAT router but have
> their own public IP addresses, what kind of device do you have that only
> allows port 3333?

As I said, we use the public IP of the servers. Obviously, I'm not a network
expert, so I must contact the admin to know that. My point is, all the other
users are non-experts too. And they set their Ubuntu servers, without
contact the network admins. So, I though that should be something with the
config.

I will try to get some answers. Thank you, again.

--
May the Source be with you!
carriunix

Thanks, Øyvind for the reply.

On 2021-09-04, Øyvind Røtvold <orotvold@gmail.com> wrote:
> There's a lot of verbiage here an a long description of your own and
> other systems which I can't be bothered to read.

I'm sorry about the gabble.

> This should indicate that you cannot reach the host. If the host is
> reachable but I'm using the wrong port, or there's a configuration or
> authentication failure I get another response.

It is not the wrong port. The authentication works locally. That is why
I bet on configuration.

> You can try telnet to check that you got the correct host and port,

As I wrote in original post, telnet fails by timeout too.

> What is missing though are cut and pasted commands that you've tried
> with their responses, try this next time.

Ok. I will. Thanks for your time.

--
May the Source be with you!
carriunix

On Sat, 04 Sep 2021 16:35:51 +0000, carriunix wrote:
> However, the IP used is the public
> IP, those that we get using curl or wget testing.

So if you logged in to server1 try:

lynx -dump https://whatismyipaddress.com/ | grep IPv4

you will see the same IP address as when you try:

/sbin/ifconfig | grep netmask

?

regards Henrik

carriunix <carriunix@gmail.com> wrote:
<snip>
>
> Most online tutorials work with 3 possibilities: wrong
> hosts, wrong port or firewall restrictions. None of these
> seems to be the case.
>
> What am I missing here?

Kind of silly, but I get caught by this a lot.

Check the protections of ~/.ssh and all files in
that dir on all involved systems. Example:

chmod 700 ~/.ssh
chmod 600 or 400 for files under ~/.ssh

John

Hi, John. Thanks for the reply.

On 2021-09-04, John McCue <jmccue@jmcw541.hsd1.ma.comcast.net> wrote:

> Kind of silly, but I get caught by this a lot.
>
> Check the protections of ~/.ssh and all files in
> that dir on all involved systems...

Sorry, I forgot to mention that in my original post, but I checked it.

--
May the Source be with you!
carriunix

Okay, I solved it. With an anticlimax plot twist, it was
a hardware issue. Thank you, Henrik, for the tip that
showed me the problem.

A little digression (Øyvind, skip that part): this IBM
SystemX3650 server was assembled using "waste", parts of
many old servers that "doens't work" and were going to
the trash. Although I have tested all the hardware used,
seems that something passed through my inspection.

The problem: The ethernet controler is broken. Using a
specific interface (eth0), the connection with LAN is
stable, but WAN don't. When I tried get the IP from lynx,
I observe the fail. First, I got this:
$ lynx -dump https://whatismyipaddress.com/ | grep IPv4
IPv4: ? The most common IP version assigned by ISPs.
Checking...

Then, refreshing the site, I lost connection. After some
tests, I identified the problem. Using another interface,
everything works fine.

Thank you Henrik, Øyvind, and John for the opinions.
I'm sorry about the waste of your time.

--
May the Source be with you!
carriunix

On Sun, 05 Sep 2021 15:43:15 +0000, carriunix wrote:
> Using another interface, everything works fine.

Great that the problem is solved!

Maybe one word of caution:

I don't know what sshd_config looks like on Ubuntu, but I do know that
the root account usually is unusable on Ubuntu and administrative tasks
are done with sudo instead. On Slackware the root account is usable and
if you open up ssh on a public IP you should make sure that you have:

PermitRootLogin no

....in /etc/ssh/sshd_config

You should also make sure that all usable accounts use hard to guess
passwords if you allow ssh password login.

This is what my log files look like on a system which has ssh on port
2222 on a public IP address:

....
Sep 5 18:42:33 igor sshd[25577]: Failed password for root from
194.19.182.119 port 52974 ssh2
Sep 5 18:42:33 igor sshd[25577]: Received disconnect from
194.19.182.119: 11: Bye Bye [preauth]
Sep 5 18:44:51 igor sshd[25579]: Connection closed by 106.75.222.175
[preauth]
Sep 5 18:45:13 igor sshd[25581]: Invalid user chenmm from 210.104.28.71
Sep 5 18:45:13 igor sshd[25581]: input_userauth_request: invalid user
chenmm [preauth]
Sep 5 18:45:13 igor sshd[25581]: pam_unix(sshd:auth): check pass; user
unknown
Sep 5 18:45:13 igor sshd[25581]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.104.28.71
Sep 5 18:45:15 igor sshd[25581]: Failed password for invalid user chenmm
from 210.104.28.71 port 33658 ssh2
Sep 5 18:45:15 igor sshd[25581]: Received disconnect from 210.104.28.71:
11: Bye Bye [preauth]
Sep 5 18:51:16 igor sshd[25583]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.104.28.71
user=root
Sep 5 18:51:18 igor sshd[25583]: Failed password for root from
210.104.28.71 port 37942 ssh2
Sep 5 18:51:18 igor sshd[25583]: Received disconnect from 210.104.28.71:
11: Bye Bye [preauth]
Sep 5 18:56:54 igor sshd[25587]: Accepted publickey for henca from
192.168.17.2 port 63492 ssh2
Sep 5 18:56:54 igor sshd[25587]: pam_unix(sshd:session): session opened
for user henca by (uid=0)
....

I blacklist IP addresses which has made too many ssh attempts, that list
is 38976 different IP addresses which I route to /dev/null

Once I saw a Slackware machine with a weak root password being connected
to internet with a public IP address. It took about 30 minutes before
someone was able to login as root.

regards Henrik

Greetings, Henrik.

Ubuntu's sshd_config file is similar to Slackware's. However, I changed
the file back to my version (which I consider more secure than the one
my colleagues use). Before, my intention was only to test if was a
configuration error.

Since we get to the *server's security* topic, here are my precautions:
(i) Changes in sshd_config
#Port 22
Port 3333
AllowUsers myuseronly
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no

(ii) iptables firewall to avoid brute force attacks
iptables -I INPUT -p tcp --dport 3333 -i eth1 -m state --state NEW
-m recent --update --seconds 60 --hitcount 4 -j LOGDROP

Do you guys recommend something else?

--
May the Source be with you!
carriunix

On Mon, 06 Sep 2021 12:52:10 +0000, carriunix wrote:
> AllowUsers myuseronly
> PermitRootLogin no
> PubkeyAuthentication yes
> PasswordAuthentication no

> (ii) iptables firewall to avoid brute force attacks iptables -I INPUT -p
> tcp --dport 3333 -i eth1 -m state --state NEW -m recent --update
> --seconds 60 --hitcount 4 -j LOGDROP

That seems great!

regards Henrik