[Solved] LISH/SSH Access Denied
Presenting two symptoms which may or may not be related
1> SSH returns connection refused on all ports/accounts.
2> No login prompt appears in LISH/AJAX after bootup messages. The LISH console is available(CTL-CAD), but the login prompt refuses to appear.
I've logged in to recovery profile and disabled firewalls, checked and changed ports, the SSH server appears in the console logon messages.
I am able to use SSH/LISH when started in the recovery profile.
I havent noticed anything apparent in the logs, although a brighter mind may be able to point me to an issue.
I have used pub key SSH without a hitch until this occurred. As I haven't made any major changes, except rebooting. I am assuming that an update or other change borked it but did not take effect until reboot.
All other services appear to be running as normal.
Any advice, pointers, solutions or workarounds would be greatly appreciated.
10 Replies
The lish part will be you're linode is using the wrong console, for linode it's hvc0
Are you using a custom kernel?
On another note, support for ubuntu 9.10 ended in april, once this is fixed you should upgrade to 10.04.
Latest 2.6 Paravirt kernel, nothing special should be compiled.
I will indeed be upgrading after I can access the machine again.
Assuming I can likely fix the SSh issue, how do I go about the hvc0?
i've had a brief look round.
Most of the "guides" related to this are for other distros and have inittab or event.d alterations?
there is indeed a /dev/hvc0, and it looks like the correct settings in /etc/init.
I must admit zip experience in this area, so any pointers, or links to send me in the right direction?
This file defines which devices root can log in on.
These are the ttys on the physical console:
console
tty0
tty1
hvc0
xvd0
# hvc0 - getty
#
# This service maintains a getty on hvc0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/getty -8 38400 hvc0
If that's there and looks right then poke linode support since they can see your server they'll be able to look at it closer.
I changed to an older kernel allowing access with root password in maintenance mode. Fixed the SSH problem which was caused by a corruption in sshd_config.
The Lish problem was caused by getty not loading on boot. Manual starting of the process by upstart or directly through /sbin/getty worked.
To make it persistent, I updated the /etc/init/hvc0.conf file as follows:
start on (virtual-filesystems
or starting rcS
or starting mountall-shell)
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
respawn
exec /sbin/getty 38400 hvc0
Returned to Latest 2.6 Paravirt kernel in profile.
Rebooted.
Solved.
8.04 LTS: April 2013
10.04 LTS: April 2015
10.10: April 2012
11.04: October 2012
Generally, people running production servers at Linode should stick to the LTS releases. They come out every two years, are supported for five years, and you can upgrade directly between them without going through the intermediate releases (although you can do that too if you want).
There's no real reason not to run a non-LTS version on a server, except for the fact that they're typically only supported for 18 months, requiring frequent updates to stay on a supported version. With an LTS release, you can afford to stay on the same release for up to five years, which really gives you the flexibility to upgrade on your own schedule.
One thing some people like to do for maturity, for example, taking advantage of that flexibility, is upgrade every 2 years to the previous LTS release; by the time they upgrade to a newer release, it's already had two years to mature.
Personally, I stick to the LTS releases on my production boxes, and typically upgrade to it after the subsequent release comes out the following October (6 months later). It's my compromise between not wanting to have a brand new release on my box, but also not wanting to fall too far behind. My non-production box (the one I use for personal use, development, messing around) I just keep on the latest-and-greatest release, since stability isn't as important.
@bltc:
I changed to an older kernel allowing access with root password in maintenance mode. Fixed the SSH problem which was caused by a corruption in sshd_config.
For future reference, it's also possible to fix items such as this without switching kernels by booting into a recovery (Finnix) configuration, mounting your disk volume and then making the change. That will work even in cases where changing kernels isn't an option or won't affect the behavior.
– David
As far as the upgrade goes, that certainly was a most detailed post. I have completed upgrading and should be good for a few more years. Except for a sticky SQL problem all went well But then I supposed thats why I have backups and DB dumps.
-bltc