How to get SSH to start on boot?

Isaac Velando · 02-06-2014, 09:59 PM

Based on your previous output of chkconfig --list, sshd is enabled on runlevel 5 so that's not the issue; runlevel 5 is I believe standard convention for graphical logins like you seem to be using presently, which is fine.

Ignore the systemctl comment; that's the tool to configure services under the systemd init daemon. CentOS uses either SysV (5.x) or Upstart (6.x), and the chkconfig/runlevel style of service management applies here. These are just different processes for managing the system and its services; distributions like Arch, Fedora, OpenSuse, and possibly the next version of Debian use systemd by default, but that's besides the point.

I'm assuming you haven't yet discovered the problem causing your ssh issues? If not, the next step would be:

Code:

/usr/sbin/sshd -t

and see if it outputs anything; if so you have a misconfigured /etc/ssh/sshd_config and need to fix that followed by

Code:

service sshd start

Otherwise proceed with

Code:

grep 'sshd' /var/log/messages | less
grep 'sshd' /var/log/secure | less

and scan the latest entries for any trouble signs - warnings and the like. If you find anything and want to output it here you could run

Code:

grep 'sshd' /var/log/messages | tail -n 10
grep 'sshd' /var/log/secure | tail -n 10

or however many lines are necessary.

Ryanms3030 · 02-07-2014, 10:09 AM

I'm still having trouble. But maybe I'm looking at the wrong thing. I just tried to ssh into the server and get:

connection timed out

When I go physically log on to the server and type: service sshd status the output is:

Code:

openssh-daemon (pid  1804) is running...

I restarted sshd and still can't log on remotely. Next I did service iptables restart and get:

Code:

iptables: Setting chains to policy ACCEPT: filter mangle na[  OK  ]
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules: iptables-restore: line 39 failed
                                                           [FAILED]

After restarting iptables I am able to ssh into the server. But I'm starting to think the firewall is causing the problem. Below is a copy of my iptables. 2020 is the ssh port. I manually added rules for samba and for 9091 for Transmmission torrent server but that is commented out. Other lines were added automatically from KVM. I have tried commenting out line 39 but if I do it just fails and a different line. Is there anything in the iptables that stands out as a problem? Can I just set up a more vanilla iptables that will still work? I just want to be able to use ssh and samba on the server.

Code:

# Generated by iptables-save v1.4.7 on Tue Feb  4 17:58:35 2014
*mangle
:PREROUTING ACCEPT [3940:5229103]
:INPUT ACCEPT [3940:5229103]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1792:96503]
:POSTROUTING ACCEPT [1792:96503]
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Feb  4 17:58:35 2014
# Generated by iptables-save v1.4.7 on Tue Feb  4 17:58:35 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-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 2020 -j ACCEPT
#-A INPUT -p tcp --dport 9091 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
COMMIT
# Completed on Tue Feb  4 17:58:35 2014

DavidMcCann · 02-07-2014, 11:42 AM

Most of the discussion here is about things I have no desire to learn, but I set my services and adjust my firewall with the GUI tools in System Administration. It might just be worth trying, now you're in run-level 5.

Ryanms3030 · 02-07-2014, 01:13 PM

Quote:

Originally Posted by DavidMcCann

Most of the discussion here is about things I have no desire to learn, but I set my services and adjust my firewall with the GUI tools in System Administration. It might just be worth trying, now you're in run-level 5.

I might do that. The last time I used the gui firewall to make changes it wiped out a bunch of other configurations so. Since this server is a learning tool for me I do want to learn what is going on under the hood with iptables and other services.

Ryanms3030 · 02-08-2014, 09:51 PM

So, I solved my problems. It was wifi/network related. I made a couple of changes:

1. I connected the computer directly to my router via Ethernet instead of using wifi. I previously avoided this because I am forced to run it "headless" to be able to connect it directly to the router and I have not been comfortable with the idea of not having a gui to fall back on.

2. I switched it to runlevel 3. I don't think that was part of the problem but since I'm going to try to administer the system 100% remotely now there's no reason to boot into the gui by default.

3. I set a static ip on the ethernet. I had been using DCHP on the wifi.

Here is what I think the real problem was:

1. I was using wifi with NetworkManager.
2. When I rebooted it would come up to the log in screen and I don't think the wifi was connecting via NetworkManager until I logged into the computer.

Maybe I could have just set NM to start on boot? Or manually configure my wlan0 adapter in the config file? Regardless, of what the real fix was I probably should be connected with wire, static ip and headless

schneidz · 02-10-2014, 08:27 AM

i think the real problem was that the server changed its address upon each reboot therefore the router had no idea where to send ssh packets. setting up static ip is the way to go.

Ryanms3030 · 02-10-2014, 11:58 AM

Quote:

Originally Posted by schneidz

i think the real problem was that the server changed its address upon each reboot therefore the router had no idea where to send ssh packets. setting up static ip is the way to go.

When I was using DHCP, I was using a ip reservation on the router for the server. It was not changing ip address and I would confirm that by ifconfig.

Once I would log onto the account physically at the server and the network manager kicked in and connected to the wifi I would be able to connect ssh using the same ip address I had been using.

...I'm sure there is why none of the servers at my work are using wifi ;-) amongst other reasons