Ensuring that ssh daemon starts

A question for you Aspidastra: How did you originally load ssh onto your system (apt-get, loaded by default, compile from source)? As a secondary question, what version of Mepis are you using? The reason I ask is, on all of my systems running 3.3.1-1 ssh is loaded by default and the start links in /etc/rc*d to /etc/init.d/ssh already exist.

Jon

The ssh was loaded onto the system just by default.

Mepis version 3.4-2 rc-1

Now that you ask I cannot be sure that I told the install utility to start mepis on system boot. I am trying to recall if I was given that choice.

I will find out next week when I reinstall on an old non-production laptop.

I didn't know if maybe the ssh daemon wasn't meant to start up yet. I started it manually. Then found I couldn't ssh to the box, apparently because of the guarddog firewall. Couldn't find anything on the menu pointing to guarddog. I manually started guarddog from an xterm, created a new zone, and allowed ssh. Now I can ssh to the box. I still need to create the startup links. I'm newish to Debian & Mepis, so it's nice to learn about the update-rc.d command.

I don't recall telling the install utility anything about what to start or not start. I told it to go ahead and install grub in my MBR, which it did. The box booted OK. But the ssh daemon wasn't running.

Marnix

Marnix, the location of the setting to turn ssh on/off in guardog is under the Protocol tab, then for each Network Zone check the "Interactive Session" Network Protocol on the right-hand side. You will find "SSH - Remote Login Protocol" within that section. Click the check box to enable it and then press the Apply button below.

You shouldn't need to create a separate zone just to use this feature

Jon

This is getting away from the ssh startup file subject, but ...

I've long been too impatient to thoroughly digest the guarddog instructions. I thought that if I wanted ssh access only from within my LAN, I would need to set up a separate zone for my LAN. Of course I do also have a little firewall router that doesn't allow ssh in from the internet, but just in case, I thought it better to also only allow ssh in from hosts in my LAN. It seems to work the way I have it.

But say, I did as you suggested and did not add a new zone. I suppose I would then check that "SSH - Remote Login Protocol" check box for the 'internet' zone and apply. Cool, if so.

Getting back to the ssh startup file issue, was there something I had done wrong which caused those startup files not to be there? Also, if those startup files *are* supposed to be there and if the ssh daemon is supposed to startup after a new installation, then wouldn't it make sense to have guarddog allow ssh connections in by default. Or, if you really want the user/administrator to explicitly configure guarddog, then there ought to be a guarddog on the menu, or a way to get to it from the MEPIS Config (OS Center) or from the Control Center. I had to search for it and finally call it from the command line.

I'm quite pleased with MEPIS. I'm just pointing out something which might be amiss or which might need improving.

Marnix

You bring up some good questions Marnix. I will give my opinons on some of them. You may decide whether they are correct or not

First, regarding the ssh startup issue. Did you do something wrong on initial setup? Of course, I can't say. Hypothetically speaking, we have all messed things up at one time or another

If things were really, really messed up, I would recommend going back into synaptic, perform a search on ssh, right-click on ssh and choose "Mark for Upgrade" and apply. Or, if you like apt-get better, then "apt-get install ssh" as root. If you install something that's already installed, it will re-install it. If the various /etc/init.d/* and /etc/rc*d/* things were messed up, they will be corrected.

Next, to the question of a tighter link between ssh and guarddog. I think you bring up a good idea. Namely, can an application that has a link in the firewall have an impact on the firewall? I think the answer lies in the fact that ssh is the primary application. Guarddog is only one of many different firewalls that are available for Linux. Guarddog is actually a front-end to the real firewall called ipchains. Typical of the general Linux philosophy of being conservative when it comes to security, just because you install an application doesn't mean that you want to expose it to the world yet. So, you end up installing the application, then opening a hole in the firewall.

The integration that you are speaking of is what happens with KDE. There are many applications that, upon installation, will check if KDE is used. If it is, then a link to the new application will be put somewhere within the KDE menu structure. But, as I'm sure you've discovered, this doesn't always work either

Jon

Regarding the ssh startup issue: You did NOT do anything wrong. I just verified that with a fresh installation - and having done the normal set of click actions* - the rc.Xd links which should START ssh are missing.

find /etc -name "*ssh"
/etc/ssh
/etc/default/ssh
/etc/pam.d/ssh
/etc/rc1.d/K20ssh
/etc/rc2.d/K20ssh
/etc/rc3.d/K20ssh
/etc/rc4.d/K20ssh
/etc/rc5.d/K20ssh
/etc/init.d/ssh

.. as you can see there are no S##ssh scripts/links which will start ssh when the machine boots.

I had expected to find

/etc/ssh
/etc/default/ssh
/etc/pam.d/ssh
/etc/rc0.d/K20ssh
/etc/rc1.d/K20ssh
/etc/rc2.d/S20ssh
/etc/rc3.d/S20ssh
/etc/rc4.d/S20ssh
/etc/rc5.d/S20ssh
/etc/rc6.d/K20ssh
/etc/init.d/ssh

...Since that was not in place, I fixed things by running update-rc.d as mentioned in the post that started this thread.

*"Normal Click actions"
boot CD
Install-ME/(Mepis OS center)
!->Install Mepis on Hard Drive
|->Set root, swap, and home partitions
|->Install
|->Grub Setup
|->Select services to run at startup
|->Create non-root user
|->Set root password
|->Reboot

Thanks for testing and confirming this issue. I do not currently run 3.4-2 in a live environment so it's good that you found this

Sounds like a little "fix" that's needed in 3.4-2rc1. You should send this info to the dev folks at mepis.com to get it corrected.

Jon

Just ran into this problem with MepisLite 3.3.2.

Appreciate the quick fix.

q

After a reread of the man pages for update-rc.d to figure this out, it looks like Mepis is working as designed. Per the EXAMPLES section of the update-rc.d man pages:

Example of disabling a service:
update-rc.d -f foobar remove
update-rc.d foobar stop 20 2 3 4 5 .

... and what do you know, that gives the types of symlinks which come in the shipped version of MEPIS.

What does this mean then? I would assert that:

- Mepis/Debian IS working as designed with respect to disabling the service

- This is NOT a bug.

However, it was non-obvious.

OK. So Here is one for the FAQs

--------------------------------------
"Starting sshd at boot time in Mepis"
--------------------------------------

To ensure that the Mepis ssh daemon starts at boot time do the following:

1) update-rc.d -f ssh remove
2) update-rc.d ssh defaults

--------

- (aspidastra who was nagged by the thought that things were working as designed and sought to confirm/clarify I wasn't taking the long way home)

Regards,

Aspidastra

Everyone in the known Universe must be having this problem. Is this in a FAQ somewhere?
Kurt

Kurt, are you speaking for the entire known universe or are you just speaking for yourself? If you are speaking for yourself, are you having this problem? You are also restarting a four-month-old post.

I have a number of systems that I have put together that communicate via ssh. There are no problems. However, what you do depends upon exactly what version of Mepis you are using. So if you need help, please ask and I'm sure someone here can help

Jon

Clearly, if you read the above messages, you would find a suggestion that might be included in a FAQ, yet it isn't. Why would I be restarting a four-month-old post, if the answer was, indeed, in a FAQ?

I have now used two different versions, 6.0 and 3.4, and had the same problem. So, yes, please excuse you....

I did not mean to start a flame war or anything, but, clearly, "everyone in the universe" is hyperbole.

These are all the procedures I've found local to MEPIS that someone might follow. Feel free to include it in the Wiki or a FAQ.

------------------------------------------------
"Starting sshd at boot time in Mepis"
------------------------------------------------
1.
Ensure Port 22 is open in guarddog. SSH is under "Interactive Session". I opened it in both directions.
2.
To ensure that the Mepis ssh daemon starts at boot time do the following:
1) update-rc.d -f ssh remove
2) update-rc.d ssh defaults
3.
Also setting in /etc/hosts.allow may be set to DENY ALL HOSTS. Edit the file as root.
Comment out the "deny all" by preceeding the line with "#":
#ALL : ALL@ALL : DENY
Then add some lines at the bottom like these:
# Add base address to allow all connections from local connections
ALL : 192.168. LOCAL : ALLOW
or
ALL : ALL@ALL : ALLOW
4.
Also, as root, open /etc/inetd.conf in your favorite editor. This is the configuration file for inetd.
Add the following lines:
# SSH
ssh stream tcp nowait root /usr/sbin/tcpd sshd -i
5.
Restart the SSH server:
/etc/init.d/inetd restart
If that type of restart doesn't work, try rebooting; that's what I did, and it worked.

Regards,
Kurt