Slackware64 14.1 on public root server: SSH connection refused error

kikinovak · 05-07-2015, 11:32 AM

Hi,

I've just installed Slackware64 14.1 on a public root server from the French company Online. I've already made a good dozen of these installs. The company only has Debian, Ubuntu, CentOS, FreeBSD and Windows on offer, but about two years ago, I experimented a bit and managed to install Slackware on such a machine, using an Ubuntu Live Rescue session.

Since then, I have a few production servers running Slackware with Web, Mail and streaming audio services, and I'm quite happy with them.

This afternoon, I installed one of these machines, using my own documentation, but this time, for mysterious reasons, I can't seem to connect to the machine once it's installed. I fired up the Live Rescue system, mounted the partitions and chrooted into the installed system, I checked and double-checked everything, but I can't seem to find the culprit. The root user has a password, rc.sshd is running, I invoked the cacerts script from pkgtool...

... but still, I can't SSH into the box. Network configuration is fine, the machine boots and I can ping it. This is just a bare quite minimal Slackware installation with (so far) the A, AP, D, L and N package groups. (I do this usually, and upon the first reboot, install remaining groups like X later on.)

Any idea what possible causes I can investigate here? I admit I'm a bit clueless here.

Cheers,

Niki

ponce · 05-07-2015, 12:00 PM

you could check in /var/log/messages if the ssh server really starts: there should be some lines like

Code:

May  7 18:58:09 toscibo sshd[2051]: Server listening on 0.0.0.0 port 22.
May  7 18:58:09 toscibo sshd[2051]: Server listening on :: port 22.

kikinovak · 05-07-2015, 12:06 PM

In the meantime, I tried something else, and it worked, though I'm not exactly sure why/how. I launched the Live Rescue session again, chrooted into my Slackware system, configured slackpkg and upgraded my existing installation (consisting of A, AP, D, L and N as stated above). Then I relaunched the cacerts installation script (on a vague whim), exited the system and rebooted the server.

Now I can SSH into my server without any problems. So is it possible that some old SSH component prevents me from connecting to the server? I'm not even sure how to formulate this otherwise.

Cheers,

Niki

kikinovak · 05-07-2015, 12:11 PM

This might be a good place to ask. What exactly does the cacerts script do?

ponce · 05-07-2015, 12:21 PM

Code:

# cat /var/log/setup/setup.11.cacerts  
#!/bin/sh
#BLURB="Rebuild SSL certificate database."
chroot . usr/sbin/update-ca-certificates --fresh 1> /dev/null 2> /dev/null

Code:

man 8 update-ca-certificates

Code:

UPDATE-CA-CERTIFICATES(8) System Manager's Manual UPDATE-CA-CERTIFICATES(8)

NAME
update-ca-certificates - update /etc/ssl/certs and certificates.crt

SYNOPSIS
update-ca-certificates [options]

DESCRIPTION
This manual page documents briefly the update-ca-certificates command.

update-ca-certificates is a program that updates the directory /etc/ssl/certs to hold SSL certificates and generates certificates.crt, a concatenated single-file list of
certificates.

It reads the file /etc/ca-certificates.conf. Each line gives a pathname of a CA certificate under /usr/share/ca-certificates that should be trusted. Lines that begin with
"#" are comment lines and thus ignored. Lines that begin with "!" are deselected, causing the deactivation of the CA certificate in question. Certificates must have a .crt
extension in order to be included by update-ca-certificates.

Furthermore all certificates with a .crt extension found below /usr/local/share/ca-certificates are also included as implicitly trusted.

Before terminating, update-ca-certificates invokes run-parts on /etc/ca-certificates/update.d and calls each hook with a list of certificates: those added are prefixed with
a +, those removed are prefixed with a -.

OPTIONS
A summary of options is included below.

-h, --help
Show summary of options.

-v, --verbose
Be verbose. Output c_rehash.

-f, --fresh
Fresh updates. Remove symlinks in /etc/ssl/certs directory.

FILES
/etc/ca-certificates.conf
A configuration file.

/etc/ssl/certs/ca-certificates.crt
A single-file version of CA certificates. This holds all CA certificates that you activated in /etc/ca-certificates.conf.

/usr/share/ca-certificates
Directory of CA certificates.

/usr/local/share/ca-certificates
Directory of local CA certificates (with .crt extension).

SEE ALSO
c_rehash(1)

AUTHOR
This manual page was written by Fumitoshi UKAI <ukai@debian.or.jp>, for the Debian project (but may be used by others).

20 April 2003 UPDATE-CA-CERTIFICATES(8)

https://superuser.com/questions/4373...y-ca-to-ubuntu

in short: it should be used whenever you change (add/remove/update) your system's certificates.

xflow7 · 05-07-2015, 02:29 PM

OpenSSL recently got a security patch. Is it possible that Online has a firewall of some kind that blocks SSH connections to servers not patched with the latest?

Seems a stretch (and not sure if it would even be feasible), but just a thought.

Mark Pettit · 05-07-2015, 02:32 PM

I know there are people who pride themselves on their "minimal" installation, but quite frankly, it's just a waste of time. A full installation will prevent a multitude of later errors, especially with the so-called "lack of package management", which is not an issue IF you have done a full install. The option to do a partial install should just be removed from the Slackware installer ... :-)

Didier Spaier · 05-07-2015, 03:10 PM

Quote:

Originally Posted by Mark Pettit

I know there are people who pride themselves on their "minimal" installation, but quite frankly, it's just a waste of time. A full installation will prevent a multitude of later errors, especially with the so-called "lack of package management", which is not an issue IF you have done a full install. The option to do a partial install should just be removed from the Slackware installer ... :-)

ca-certificates being part of the N series that is installed according to the initial post of this thread, I fail to see how your statement relates to the topic.

Regardless, my crystal ball tells me that your suggestion of forbidding a partial install has zero chance to retain Pat's attention. Fortunately. And it would be very easy for a semi-skilled slacker to circumvent such a limitation anyway.

kikinovak · 05-07-2015, 03:26 PM

Quote:

Originally Posted by Mark Pettit

I know there are people who pride themselves on their "minimal" installation, but quite frankly, it's just a waste of time. A full installation will prevent a multitude of later errors, especially with the so-called "lack of package management", which is not an issue IF you have done a full install. The option to do a partial install should just be removed from the Slackware installer ... :-)

I do a full install. This is just to get started, since I can't use a Slackware installation medium, and have to bootstrap Slackware remotely from inside an Ubuntu 12.04 LTS live session into which I SSH. Here's the gory details:

https://github.com/kikinovak/microli...ibox-HOWTO.txt

PS: for the record, on a server, I leave out E, KDE, KDEI, XAP and XFCE.

Mark Pettit · 05-08-2015, 04:28 AM

Quote:

Originally Posted by Didier Spaier

ca-certificates being part of the N series that is installed according to the initial post of this thread, I fail to see how your statement relates to the topic.

Regardless, my crystal ball tells me that your suggestion of forbidding a partial install has zero chance to retain Pat's attention. Fortunately. And it would be very easy for a semi-skilled slacker to circumvent such a limitation anyway.

OK - the last statement was tongue-in-cheek - hence the smiley emoticon.

But my first point relates in that when you are chasing errors, knowing that you have a full install will certainly put libraries and packages out of the questions. Thus making the debugging that much easier.

kikinovak · 05-08-2015, 10:18 AM

Quote:

Originally Posted by Mark Pettit

OK - the last statement was tongue-in-cheek - hence the smiley emoticon.

But my first point relates in that when you are chasing errors, knowing that you have a full install will certainly put libraries and packages out of the questions. Thus making the debugging that much easier.

Here's the full and final HOWTO, BTW:

https://kikinovak.wordpress.com/2015...r-une-dedibox/

Mark Pettit · 05-08-2015, 11:22 AM

Quote:

Originally Posted by kikinovak

Here's the full and final HOWTO, BTW:

https://kikinovak.wordpress.com/2015...r-une-dedibox/

In French ... :-)

zakame · 05-08-2015, 11:27 AM

It just needs PAM. :^)

kikinovak · 05-09-2015, 01:17 AM

OK, I experimented some more, and it looks indeed like there's some upstream security from the provider. On this second install, I installed the system from within the live session, but I upgraded everything before the initial reboot. This time it worked like a charm.

Beren Erchamion · 07-12-2015, 09:16 AM

Quote:

Originally Posted by Mark Pettit

In French ... :-)

I used it for the first time yesterday. My French experience is limited to a year in high school fifteen years ago (I know Latin and Russian much better), and I was able to follow it just fine. Really, if you're reasonably familiar with the Slackware installation process it should be easy enough to figure out what's going on just by following the command lines and console output included.