The system:
I am using a cluster of four physical machines all running on CentOS 5.5 (64 bit). I do not have the option to upgrade to a newer version of CentOS. When it is working, each machine can use "ssh" to access the others- for example c1 can "ssh c2".

I have been informed that each machine has two net cards, and ifconfig -a reflects this by giving lo, eth0, and eth1.

The current problem:
One of the clusters, c4, is not able to use the ssh command. When I try to enter externally from c1, I cannot ping it, and I get

"ssh: connect to port c4 port 22: no route to host"


When accessing c4 directly, I can use it as normal, but cannot ssh or ping anything.

Using the ifconfig command shows that both eth0 and lo are in existence.


Previous things tried:
Originally, eth0 did not show up on ifconfig.
I tried

ifconfig eth0 (ip address) netmask 255.255.255.0

This made eth0 show up in the ifconfig results. I can toggle it on and off of that list with "ifup eth0" and "ifdown eth0".


In conclusion:
If you should need any additional information I would be more than happy to provide it! I am extremely new to linux (and computer work in general), so there may be some improper use of terminology.

Try enabling eth1 and see if you can reach the host then.

Are you certain the problem box has network connectivity? What's the output of

Has any changes been done to any of the computers lately?

Do the machines use both interfaces? Do you know how the network is configured?

Can you ping other computer by their IP address versus hostname?

Post the output of the route command.

AwesomeMachine: I just tried to bring up eth1 using "ifup eth1", this brings it to the same state as eth0? (appears in ifconfig but will not connect)

TheEzekielProject: The output is written below. Sorry it's not nice looking, but I cannot copy/paste due to the connectivity issue.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0:<NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:48:f8:72:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0
3: eth1: <BROADCAST, MULTICAST, UP, LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00.30:48:f8:72:b9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::23048ff:fef8:72b9/64 scope link
valid_lft forever preferred_lft forever
4: sit0: <NOARP>mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0


Thank you both for your suggestions!

michaelk:

(Oh look, I can quote! Neat.)
No changes have been made to the computers since a new user was added to the system in... march, I believe? It went down fairly recently, so I hope that's not the issue.

I am unsure how to respond to these, I'm sorry. If you mean how they are used in daily operation, putty is typically used to access c1, from which one can ssh to c2-4. I know that c1 has both a local and a global ip address?

I attempted this, but it still gave me the "no route to host" message.

Apologies if posting messes up the table.

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0

From your first post it looks like you usually use eth0, is that correct? The eth0 connection has NO-CARRIER. Eth1 appears to be ipv6, and looks like it is connected.

Have you double checked and made sure you have ssh running on the problem box? or, it CentOS5.5 is systemd

1 members found this post helpful.

eth0 is what seems to be running on the functional clusters, so I presume it is what is usually used. Although if eth1 does wind up working, I don't think anyone will complain!

When I attempted to run those commands, I got the following outputs:

service ssh status: --> ssh: unrecognized service

systemct1 status ssh --> command not found

I get the same responses when I try these on one of the functional machines.

Update: I have noticed that half of the boxes are actually running CentOS 5.3, if that changes anything. The outputs listed above are the same on boxes running 5.3 and 5.5. (Is a box what you call one unit of this system?)

Does this mean I have to install ssh? How do I get ssh if I can't connect to the internet to download it? (Presuming it's the kind of thing one can download- my friends tease me that up until last year I thought drivers were a physical object you had to put inside your computer. I'm not very knowledgeable about technology.)

Correct syntax is

Note that the second command is a lower-case "L" and not a 1 (one).
Also, I forgot to mention these commands need a root terminal.

On my non-systemd systems, sshd returns . But ssh works.

1 members found this post helpful.

Depends on the distribution i.e RedHat/CentOS uses sshd while debian uses ssh.

Ah. Good to know!

In your output for ifconfig it appears eth1 has no ipv4 address. Try giving it an ipv4 address on the same subnet as the network is on, i.e 192.168.0.0/24.

If that fails, try restarting the network service.

1 members found this post helpful.

Regarding the service codes for any future newbies on antiquated systems, openssh-daemon is running.



Giving eth1 an ipv4 address worked! c4 is now fully operational!

Thank you all very much for your help.