I'm running (LMDE) Linux Mint Debian Edition.

I normally "share" my single flatscreen and e keyboard between quite a few older computers using a mulitport KVM switch. However, I have a need for several coming months to move my primary desktop about 100 feet from my computer room, which means I need to be able to ssh into my computer room's systems, since my screen and keyboard are going with the move.

The firewall ips are correct and each computer has ssh openssh-client and openssh-server installed. Complicating the situation is, I often have to disconnect these computers from power to protect them from lightning storms. I want to be able to simply power them up and access them from across the network, without having to directly carry my screen and keyboard back to the KVM switch and directly log onto each of them and that is what I am having to do, because without directly logging in first they are refusing to allow remote access.

Here is what is happening when I try to access them across my network when they have simply been powered up:

$ ssh lucky@192.168.2.210
ssh: connect to host 192.168.2.210 port 22: Connection refused

If I directly get on that machine and check ssh, I get:

lucky@ispy / $ sudo chkconfig ssh
ssh on

Someone told me that I need to enter the Bios and look for error codes, and set "Don't skip on Keyboard" to "continue", as when I power up my computers they are waiting on a direct access from the keyboard or something like that. However, I can't find anything in the bios that refers to error codes or to keyboards.

Does anyone have any suggestions how to solve this problem? I hate the idea of carrying my screen and keyboard back and forth every time I want to boot up one of those computers on the network!

Thanks!

Sometimes the BIOS option is named "Halt on Errors" and you have to set this to "All, but keyboard"

Have you edited /etc/ssh/sshd_config for remote access.
Look for "#ListenAddress 0.0.0.0" and replace it with "ListenAddress <your server ip>"

And your router has to route port 22 to your server unless you stay on the local network.

TobiSGD: That's just the problem....There isn't anything that refers to Halt or Errors in this bios that I can find.

whizje: Concerning the target machine I want to access.....when you say to enter <your server ip>, does that mean enter the ip address of the machine itself, like I was trying to talk to 192.168.2.200, so I would ender that ip address in this blank? Or does it mean I should enter the ip address of the machine I am trying to communicate from, such as 192.168.2.100?

I tried both, and in both cases, I still got a "no route to host" message.

We should back up and split this into two steps.

Boot the machine with the keyboard, monitor, and mouse connected. Ensure SSH is running, ensure you can SSH in remotely. Only AFTER you get that working should you try to make the system completely headless and connect again. From the sounds of it you've never tried to SSH into the machine when you KNOW the OS is up and running. Then you're blaming the BIOS config for keeping you out of the OS when KVM is not attached, when it could simply be a misconfigured SSH server the entire time and the BIOS is fine.

1 members found this post helpful.

+1 for suicidaleggroll.
If you have made the suggested tests and SSH is working, but not when the machine is headless, please post manufacturer and model of the mainboard(s).

suicidaleggroll: Good suggestion! And it is my fault for not having mentioned up front, that I in fact did test my ability to access the machines if I had first booted them and logged in with screen/keyboard/mouse. That was in fact the very first thing I did after moving my primary machine 100 feet away, to verify everything still works......life has taught me not to trust the universe...it likes to laugh behind my back too much!

So rest assured....everything works this way....before I try to make it into a headless setup.

And, you are right again, I have only rarely used ssh directly from the command line, although more frequently via gftp and putty, but still, in a very limited way. So, I am not very familiar with this method...

So, all the preliminary testing was done and it looked good and worked that way.


TobiSGD: I will post the motherboard info a bit later, when I can shut the machines down...

Thanks so much for your input on this!

I found the info in my records, on the first machine I am trying to access:

Hp Compaq Presario sr1303wm
Mb manufacturer name: ASUS A7V8X-LA
HP/Compaq name: Kelut-GL6E
(The document the above info is in, is entitled A7V8X-LA Kelut )

Have you only tested ssh via local login or also remote as i read it you have only tried ssh on the local machine. Oh the ip you have to insert is the ip of the machine self.

And if the machine boots without a keyboard is easy to find out. Only attach a monitor and look what the machine does.

I did a little research and found that ASUS provides absolutely no information about this mainboard, which normally means that this mainboard was specifically produced for HP. HP provides no information about the BIOS of that machine, but I was able to find information on the A7V8X-LA Kamet and this definitely has a "Halt on" BIOS setting. If your PC has not then it is likely that you have a somewhat restricted BIOS, not uncommon for /Dell/HP/Compaq.
In that case your best bet would be to find a cheap keyboard and keep it attached to the machine

whizje: I am not sure what you are asking me concerning testing ssh local or remote. So, I will go over what I have done and not done. My layout is simple, I have a wired/wireless router and all my computers are connected directly to it, one way, or the other. That is my LAN. I have not tried to come in remotely from the WAN from another location.

All my testing has been within my LAN, from my "originating" computer (192.168.2.100) to my "target" computer (192.168.2.200.

If the target (192.168.2.200) has been logged into using a keyboard on the KVM switch, my "originating" computer (192.168.2.100) is then able to ssh into the target computer (192.168.2.200).

If the target computer (192.168.2.200) has not been logged into directly by the kvm switch keyboard, my "originating" computer (192.168.2.100) is then NOT able to ssh into the target computer (192.168.2.200).

Now, I can tell you that I can make it work going from the target computer (192.168.2.200) and ssh-ing into the "originating" computer (192.168.2.100) when it has been booted up without a keyboard. But that doesn't help me, as I need the "originating" computer (192.168.2.100) at the end of that 100 feet of ethernet cable...

As for your suggested test of watching a bootup of the target computer (192.168.2.200) with only the monitor attached to the KVM switch, I can see the boot go all the way to the gui login and wait for my user to be selected. So, it is booting the the login point. I also added a an additional test of clicking on my user so it was waiting for the password, and tried ssh-ing in at that point, but that didn't work either.

I did see something that might have something to do with the problem, maybe, but I am not experienced enough to know: In the boot up, it shows Firestarter (my firewall) showing as failed. However, I know that once I have logged in, Firestarter is running...but...I don't know when it actually starts.

So, this is the result I am getting:
ssh: connect to host 192.168.2.200 port 22: No route to host


TobiSGD: I scrounged up an old PS-2 mouse and keyboard and attached them to the target computer and then tried sshing into it after booting it headless. It seemed like an excellent idea, but it didn't work. I got the same thing:
ssh: connect to host 192.168.2.200 port 22: No route to host

--Which seems strange, and also if you read my note above to whizje, seems to me to maybe indicate my Firestarter firewall really isn't operating until I directly login....but the question is, would I get the above error if the natural firewall of the LMDE OS is rejecting my attempt to connect because Firestarter isn't alive to tell it otherwise at this point? And if so, how does one get Firestarter to successfully execute in the bootup?

Also, I do not know much about trying to flash a bios or if there is even an available bios that will work on this aged machine. I've heard it is potentially risky and one can end up rendering their computer inoperatable if they make a mistake...

Are you sure it's a "halt on error" issue? Generally I'd think you would see a timeout rather than a connect refused when attempting to connect to a port on a down system.

May it be possible that your network connection on the target computer is managed by some GUI network manager that is only started after you logged in? That would explain that behavior.