connect to host 192.168.0.7 port 22: Connection refused

893 views
Skip to first unread message

Josh

unread,
Aug 6, 2008, 3:47:49 AM8/6/08
to
Hi

I encountered the a.m. error while doing ssh to a computer in my hous net;
it used to work before the recent update of Mandriva 2008; now I have port
22 closed to ssh - did you folks out there have the same problem? How could
did you solve it? No luck making shorewall to go down.

Thanks in advance for your help.

Joshua

Bit Twister

unread,
Aug 6, 2008, 6:18:05 AM8/6/08
to
On Wed, 06 Aug 2008 09:47:49 +0200, Josh wrote:
> Hi
>
> I encountered the a.m. error while doing ssh to a computer in my hous net;
> it used to work before the recent update of Mandriva 2008;

Which one of the 4+ 2008* installs? Show us the output from

cat /etc/lsb-release

> now I have port 22 closed to ssh - did you folks out there have the
> same problem?

Not me, 2008.0 and 2008.1 32 bit install.

> How could did you solve it?

I solve it by clicking up a terminal on the inbound/target system.

ssh $USER@$(hostname)

to verify ssh works locally.
Any time ssh fails, I

su - root
tail -f /var/log/messages

Then try the ssh $US...@target.machine

> No luck making shorewall to go down.

Was that a "shorewall clear" command?

David Mathog

unread,
Aug 6, 2008, 11:41:44 AM8/6/08
to
Josh wrote:

> I encountered the a.m. error while doing ssh to a computer in my hous net;
> it used to work before the recent update of Mandriva 2008; now I have port
> 22 closed to ssh - did you folks out there have the same problem? How could
> did you solve it? No luck making shorewall to go down.

There has been a tendency over the last several years for Mandriva to
stomp on config files in /etc during updates. In particular, and
relevant to what you are seeing, rules.drakx was often changed. This
became such an issue that my Mandriva systems now all have copies of
most of /etc and bits and pieces of other directories under
/root/saf_config, along with scripts to compare these after each update.
So, my general answer to your question is that you should do something
similar, so that when an errant update reconfigures your system, you can
automatically locate the problem and resolve it. The scripts and method
were posted in this forum 25 Jun 2007 with the subject: "Baby steps
towards surviving overly helpful helper scripts".

Regards,

David Mathog

Unruh

unread,
Aug 6, 2008, 11:48:24 AM8/6/08
to
Josh <e.pi...@libero.it> writes:

>Hi

>I encountered the a.m. error while doing ssh to a computer in my hous net;
>it used to work before the recent update of Mandriva 2008; now I have port
>22 closed to ssh - did you folks out there have the same problem? How could
>did you solve it? No luck making shorewall to go down.

Is sshd running on that computer? do you allow connections from your
computer to that one in /etc/hosts.allow on the server?
Does your firewall allow connections from that computer?

Robert Riches

unread,
Aug 6, 2008, 11:09:51 PM8/6/08
to

One way to keep an eye out for "helpers" is to keep a copy
(and/or an RCS repository) of all the configuration files in
/etc (and elsewhere). Run a 'diff' of all the files right
before updating. Then, run another 'diff' right after the
update. If any "helper" messed with your files, you now
know what changed and what you used to have in that file.

HTH

--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)

Vitalie Ucrainciuc

unread,
Aug 15, 2008, 8:32:59 PM8/15/08
to

Try to enable SSH in firewall rules as Allow or Permit.

It should work!


"Josh" <e.pi...@libero.it> wrote in message
news:48995725$0$11373$5fc...@news.tiscali.it...

Maurice Batey

unread,
Aug 16, 2008, 2:31:54 PM8/16/08
to
Josh" <e.pi...@libero.it> wrote in message
news:48995725$0$11373$5fc...@news.tiscali.it...

> I encountered the a.m. error while doing ssh to a computer in
> my house net; it used to work before the recent update of


> Mandriva 2008; now I have port 22 closed to ssh -

It just so happens that I have beem trying to set things up to
RYSNC from laptop to desktop on house network, and have come
across the same problem when trying 'ssh MABsdesktop' on the
laptop:

"ssh: connect to host MABsdesktop port 22: Connection refused"

On the laptop, /etc/hosts has:

127.0.0.1 localhost
192.168.0.2 desktop.mab.unregistered MABsdesktop

and the laptop's MCC sees the desktop PC's printer as on 'host:
192.168.0.2'.

The desktop does have SSH enabled on its firewall.

Of course, as I'm sadly still a network neophyte, it's quite
possible that I'm doing something wrong (or not doing domething I
should)...

--
/\/\aurice
Linux Mandriva 2.6.22.19-desktop-2mdv 2008.0 PP 32-bit
KDE 3.5.7 Virtualbox 1.5.6
(Remove 'removethis.' to reply by email)

Bit Twister

unread,
Aug 16, 2008, 2:48:22 PM8/16/08
to
On Sat, 16 Aug 2008 19:31:54 +0100, Maurice Batey wrote:
>
> "ssh: connect to host MABsdesktop port 22: Connection refused"
>
> On the laptop, /etc/hosts has:
>
> 127.0.0.1 localhost
> 192.168.0.2 desktop.mab.unregistered MABsdesktop
>
> and the laptop's MCC sees the desktop PC's printer as on 'host:
> 192.168.0.2'.

Click up a terminal on desktop
su - root

/sbin/runlevel

Verify sshd is on boot for your run level
chkconfig --list sshd

and sshd is running with
pgrep -lf sshd

Next see if anything shows up when you try the ssh
tail -f /var/log/messages (on both systems)


Control c aborts the tail -f command.

PS: make it a habit to do a
shorewall clear
to temporally open the firewall, and as soon as possible
service shorewall restart

Now you can do a testhost with ssh -vv $USER@MABsdesktop

Would not hurt to show us contents of
cat /etc/hosts.allow
cat /etc/hosts.deny
chkconfig --list | grep sshd
on MABsdesktop

Maurice Batey

unread,
Aug 16, 2008, 5:10:24 PM8/16/08
to
On Sat, 16 Aug 2008 18:48:22 +0000, Bit Twister wrote:

> Click up a terminal on desktop
> su - root

etc...

Did all that:
-----------------------------------------
[root@localhost mab]# /sbin/runlevel
N 5
[root@localhost mab]# chkconfig --list sshd
error reading information about service sshd: No such file or
directory
[root@localhost mab]# pgrep -lf sshd
[root@localhost mab]# cat /etc/hosts.allow
#
# hosts.allow This file describes the names of the hosts which
are
# allowed to use the local INET services, as
decided
# by the '/usr/sbin/tcpd' server.
#

sshd: 192.168.0.3/255.255.255,0
[root@localhost mab]# cat /etc/hosts.deny
#
# hosts.deny This file describes the names of the hosts which
are
# *not* allowed to use the local INET services, as
decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you
that
# the new secure portmap uses hosts.deny and hosts.allow. In
particular
# you should know that NFS uses portmap!

[root@localhost mab]# ssh -vv $USER@MABsdesktop
OpenSSH_4.7p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MABsdesktop [192.168.0.2] port 22.
debug1: connect to address 192.168.0.2 port 22: Connection
refused


ssh: connect to host MABsdesktop port 22: Connection refused

[root@localhost mab]#
[root@localhost mab]# chkconfig --list | grep sshd
[root@localhost mab]#
-----------------------------------------

Closing down for the night now...

Bit Twister

unread,
Aug 16, 2008, 5:17:41 PM8/16/08
to
On Sat, 16 Aug 2008 22:10:24 +0100, Maurice Batey wrote:
> On Sat, 16 Aug 2008 18:48:22 +0000, Bit Twister wrote:
>
>> Click up a terminal on desktop
>> su - root
> etc...
>
> Did all that:
> -----------------------------------------
> [root@localhost mab]# /sbin/runlevel
> N 5
> [root@localhost mab]# chkconfig --list sshd
> error reading information about service sshd: No such file or
> directory

Yep, right there, sshd not installed.


> [root@localhost mab]# pgrep -lf sshd

Yep, sshd not running.

> [root@localhost mab]# cat /etc/hosts.allow
> #
> # hosts.allow This file describes the names of the hosts which
> are
> # allowed to use the local INET services, as
> decided
> # by the '/usr/sbin/tcpd' server.
> #
>
> sshd: 192.168.0.3/255.255.255,0

^
|
Is that a comma----------------'

> Closing down for the night now...

Sleep tight. :)

Maurice Batey

unread,
Aug 17, 2008, 9:55:51 AM8/17/08
to
On Sat, 16 Aug 2008 21:17:41 +0000, Bit Twister wrote:

>> [root@localhost mab]# cat /etc/hosts.allow
>
>> sshd: 192.168.0.3/255.255.255,0
> ^
> |
> Is that a comma---------------'

Yes - that's what is in the file.
I assume it should be a '.', and have changed it.

> Yep, right there, sshd not installed.
>
>
>> [root@localhost mab]# pgrep -lf sshd
>
> Yep, sshd not running.

OK, have now found sshd (disguised as "OpenSSH Server" in
MCC...), and installed it.
Started it with "/etc/init.d/sshd start".

However, attempts to ssh from laptop meet with same Port 22
connection refusal as before.

Here is a rerun (on desktop) of your debugging suggestions, after
installing & starting sshd:

-------------------------------------------------------------


[root@localhost mab]# /sbin/runlevel
N 5

[root@localhost mab]# chkconfig --list sshd

sshd 0:off 1:off 2:on 3:on 4:on 5:on
6:off

[root@localhost mab]# pgrep -lf sshd

8351 /usr/sbin/sshd

[root@localhost mab]# ssh -vv mab@MABsdesktop


OpenSSH_4.7p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MABsdesktop [192.168.0.2] port 22.
debug1: connect to address 192.168.0.2 port 22: Connection
refused
ssh: connect to host MABsdesktop port 22: Connection refused

[root@localhost mab]# cat /etc/hosts.allow


#
# hosts.allow This file describes the names of the hosts which

# are allowed to use the local INET services, as decided by the
# '/usr/sbin/tcpd' server.

sshd: 192.168.0.3/255.255.255.0

[root@localhost mab]# chkconfig --list | grep sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on
6:off
-----------------------------------------------------------

By the way, when you recommend doing 'service shorewall clear'
and then a.s.a.p. 'service shorewall restart', on what occasion
should those be done?
(I suspect it's when e.g. changing the firewall to allow SSH,
instead of doing a re-boot.)

--
/\/\aurice
http://www.maurice99.ukfsn.org

Bit Twister

unread,
Aug 17, 2008, 12:10:08 PM8/17/08
to
On Sun, 17 Aug 2008 14:55:51 +0100, Maurice Batey wrote:

> OK, have now found sshd (disguised as "OpenSSH Server" in
> MCC...), and installed it.
> Started it with "/etc/init.d/sshd start".

Less typing if you do a
service sshd start :)

> Here is a rerun (on desktop) of your debugging suggestions, after
> installing & starting sshd:

> [root@localhost mab]# chkconfig --list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off


Do a
chkconfig --list | grep sshd
and verify is returns something like

sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

sshd-xinetd: off

> By the way, when you recommend doing 'service shorewall clear'
> and then a.s.a.p. 'service shorewall restart', on what occasion
> should those be done?

Anytime you think the firewall is in the way, you can open shorewall
firewall with no restrictions with shorewall clear.

I recommend not running in that mode very long, so
service shorewall restart
sets it back to the on boot/normal setting.

If you have not been dinking with customizing shorewall, just clicking
up a terminal
su - root

tail -f /var/log/messages

and then run your test shot should show a line if shorewall blocks your
ssh attempt.

> (I suspect it's when e.g. changing the firewall to allow SSH,
> instead of doing a re-boot.)

About the only time you need a reboot is kernel change, or node
name change in my stupid opinion. In the case of node name change,
init 1, followed with init 3, or init 5, depending on your requirement.

Anytime you change the firewall outside of the GUI interface, it would not
hurt to do a shorewall -check just to verify there are no glaring errors.
Then do a
service shorewall restart


An FYI on hosts.allow/deny.

tcpwrapper code will look in hosts.allow and allow the app to continue
upon hitting the first rule which applies. If nothing applies in hosts.allow,
wrapper code proceeds to see if anything is denied in hosts.deny.
Noting in deny then the application gets to run.

With your wrapper setup, you restricted sshd to an ip address and no
restrictions for everyone else.

That is ok if you manage what services you enable. Downside is
you/malware enables some other service and do not add to allow/deny
you leave a hole in your security.

My suggestion for you would be to add to bottom of hosts.allow,
something like


ALL: LOCAL, .mab.unregistered

#***************** End of hosts.allow. ********************

To the bottom of /etc/hosts.deny

ALL: ALL:\
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s \"$(uname -n)\" root ) & : DENY

#*********************** end host.deny ********************************

The above mails root a warning/debugging email about a tcpwrappers deny.
When that happens bittwister get an email. :)

Assuming you have postfix installed/running:

cd /etc/postfix

tail -11 aliases | head -4
# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: mab <============ you have set this line

did a
postalias aliases
service postfix restart

mail -s "$USER testshot" root < /dev/null

You should be able to click up a terminal in your mab user account,
and do a

mail -s "$USER testshot" root < /dev/null

mail and see 1 root testshot
2 mab testshot
(carriage return) to read the empty email from root
d to delete the email
(carriage return) to read the empty email from mab
q to quit mail and do the deletions.

With imap installed, you can have thunderbird open in another window
in your mab account, set incomming mail server as localhost,
you should get any root email at whatever polling rate you set it at.

test that with
mail -s "$USER testshot" root < /dev/null
click Get mail in thunderbird and you should see
mab testshot in thunderbird's window.

While still on MABsdesktop, in mab's account
do a
ssh $USER@$(hostname)
to see what happens.


Now, if the above changes/tests work, and you run
tail -f /var/log/messages

I am hopping you get some error message in /messages or
an email from root when trying from the laptop.


If not, I am at a loss to explain why it does not work,
unless you have done some customizing in shorewall.

Maurice Batey

unread,
Aug 17, 2008, 1:37:54 PM8/17/08
to
On Sun, 17 Aug 2008 16:10:08 +0000, Bit Twister wrote:
>
> Assuming you have postfix installed/running:

No, I use KMail.

> While still on MABsdesktop, in mab's account do a
> ssh $USER@$(hostname) to see what happens.

Here it is (actually I had already tried it but forgot to
capture the output, which also said something about adding
some info into some file):

-------------------------------------------------------
[mab@localhost ~]$ ssh $USER@$(hostname)
mab@localhost's password:
Last login: Sun Aug 17 18:17:43 2008 from localhost

> Now, if the above changes/tests work, and you run tail -f
> /var/log/messages

[mab@localhost ~]$ su
Password:
[root@localhost mab]# tail -f /var/log/messages

Aug 17 18:01:02 localhost msec: changed mode of
/var/log/cups/page_log from 644 to 640
Aug 17 18:14:44 localhost sshd[12511]: Accepted password for mab
from 127.0.0.1 port 36189 ssh2
Aug 17 18:17:43 localhost sshd[12642]: Accepted password for mab
from 127.0.0.1 port 36190 ssh2
Aug 17 18:23:39 localhost drakconf.real[12756]: ### Program is
starting ###
Aug 17 18:23:54 localhost drakconf.real[12763]: ### Program is
starting ###
Aug 17 18:23:58 localhost rpmdrake[12768]: ### Program is
starting ###
Aug 17 18:24:00 localhost rpmdrake[12768]: opening the RPM
database
Aug 17 18:24:24 localhost rpmdrake[12768]: ### Program is exiting
###
Aug 17 18:24:25 localhost drakconf.real[12763]: modified file
/etc/mcc.conf
Aug 17 18:25:23 localhost sshd[12821]: Accepted password for mab
from 127.0.0.1 port 51444 ssh2
-------------------------------------------------------------

(How does one *exit* from an 'ssh' invocation?!)

Sadly, ssh from the laptop still gives 'Port 22 connection
refused' failure. Nothing seems to show up in /var/log/messages
on either m/c for that.

--
/\/\aurice

Maurice Batey

unread,
Aug 17, 2008, 1:43:17 PM8/17/08
to
On Sun, 17 Aug 2008 16:10:08 +0000, Bit Twister wrote:

> Do a
> chkconfig --list | grep sshd
> and verify is returns something like
>
> sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
> sshd-xinetd: off

Not quite. As shown in earlier posting:
-----------------------------------------------------
[root@localhost mab]# chkconfig --list | grep sshd

sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

-----------------------------------------------------

i.e. it doesn't end with "sshd-xinetd: off"

--
/\/\aurice

Bit Twister

unread,
Aug 17, 2008, 1:53:31 PM8/17/08
to
On Sun, 17 Aug 2008 18:37:54 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 16:10:08 +0000, Bit Twister wrote:
>>
>> Assuming you have postfix installed/running:
>
> No, I use KMail.

M=Mail
T=Transport
C=Client
A=Agent


KMail is a MTC, postfix is a MTA. MTC read/sends mail via a MTA.

>> While still on MABsdesktop, in mab's account do a
>> ssh $USER@$(hostname) to see what happens.
>
> Here it is (actually I had already tried it but forgot to
> capture the output, which also said something about adding
> some info into some file):

That would be ~/.ssh/known_hosts
If name/ip/key differ during connection attempt with that node,
you will get a man in the middle warning.

> -------------------------------------------------------
> [mab@localhost ~]$ ssh $USER@$(hostname)

> (How does one *exit* from an 'ssh' invocation?!)

exit :)

> Sadly, ssh from the laptop still gives 'Port 22 connection
> refused' failure. Nothing seems to show up in /var/log/messages
> on either m/c for that.

Without my suggestion of postfix and hosts.deny;
I can recommend commenting out the sshd line in /etc/hosts.allow
service xinetd reload
and try again.

Still broke, out of suggestions and ideas. :-(

Bit Twister

unread,
Aug 17, 2008, 2:01:25 PM8/17/08
to
On Sun, 17 Aug 2008 18:43:17 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 16:10:08 +0000, Bit Twister wrote:
>
>> Do a
>> chkconfig --list | grep sshd
>> and verify is returns something like
>>
>> sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
>> sshd-xinetd: off
>
> Not quite. As shown in earlier posting:

Yes, but the one I responded to had
[root@localhost mab]# chkconfig --list sshd


sshd 0:off 1:off 2:on 3:on 4:on 5:on
6:off

:)


> -----------------------------------------------------
> [root@localhost mab]# chkconfig --list | grep sshd
>
> sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
> -----------------------------------------------------
>
> i.e. it doesn't end with "sshd-xinetd: off"

How rude. I'll show you mine if you'll show me yours. :)

$ rpm -q -f /usr/sbin/sshd
openssh-server-4.7p1-9.1mdv2008.1

Bit Twister

unread,
Aug 17, 2008, 2:04:25 PM8/17/08
to
On Sun, 17 Aug 2008 18:01:25 +0000 (UTC), Bit Twister wrote:

Opps, forgot to show which command differed.

> Yes, but the one I responded to had

> [root@localhost mab]# chkconfig --list sshd instead of

Maurice Batey

unread,
Aug 17, 2008, 2:28:31 PM8/17/08
to
On Sat, 16 Aug 2008 18:48:22 +0000, Bit Twister wrote:

> make it a habit to do a shorewall clear to temporally open
> the firewall, and as soon as possible service shorewall restart

Tried 'shorewall clear' before attempting ssh from laptop;
still failed as before.

But there were some 'uknown symbol' error msgs from the
'shorewall clear':
-----------------------------------------------
[root@localhost mab]# shorewall clear

FATAL: Error inserting nf_conntrack_h323
(/lib/modules/2.6.22.19-desktop-2mdv/kernel/net/netfilter/
nf_conntrack_h323.ko.gz): Unknown symbol in module, or unknown
parameter (see dmesg)

WARNING: Error inserting nf_conntrack_h323
(/lib/modules/2.6.22.19-desktop-2mdv/kernel/net/netfilter/
nf_conntrack_h323.ko.gz): Unknown symbol in module, or unknown
parameter (see dmesg)

FATAL: Error inserting nf_nat_h323
(/lib/modules/2.6.22.19-desktop-2mdv/kernel/net/ipv4/netfilter/
nf_nat_h323.ko.gz): Unknown symbol in module, or unknown
parameter (see dmesg)

Clearing Shorewall...
done.
--------------------------------------------------

and similar msgs from the 'service shorewall restart'....

Maurice Batey

unread,
Aug 17, 2008, 2:31:46 PM8/17/08
to
On Sun, 17 Aug 2008 18:01:25 +0000, Bit Twister wrote:

> $ rpm -q -f /usr/sbin/sshd
> openssh-server-4.7p1-9.1mdv2008.1

$ rpm -q -f /usr/sbin/sshd

openssh-server-4.7p1-2.3mdv2008.0

Bit Twister

unread,
Aug 17, 2008, 2:43:30 PM8/17/08
to
On Sun, 17 Aug 2008 19:31:46 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 18:01:25 +0000, Bit Twister wrote:
>
>> $ rpm -q -f /usr/sbin/sshd
>> openssh-server-4.7p1-9.1mdv2008.1

Opps, that was my 2008.1 install

>
> $ rpm -q -f /usr/sbin/sshd
> openssh-server-4.7p1-2.3mdv2008.0

Ok, matches my 2008.0 install.

I assume all test shots are not trying to
ssh root@where


Did adding the # sshd: in /etc/hosts.allow still fail a test shot?

Maurice Batey

unread,
Aug 17, 2008, 2:45:18 PM8/17/08
to
On Sun, 17 Aug 2008 17:53:31 +0000, Bit Twister wrote:

> I can recommend commenting out the sshd line in
> /etc/hosts.allow service xinetd reload and try again.

Tried that ("allow service xinetd reload") but ssh from


laptop still failed as before.

As the desktop ssh self-call seemed to work, is it possible
something is awry on the laptop?

The fact that it's ssh reports Port 22 refusal to connect does
show that ssh is working, doesn't it?

Bit Twister

unread,
Aug 17, 2008, 2:45:44 PM8/17/08
to
On Sun, 17 Aug 2008 19:31:46 +0100, Maurice Batey wrote:

> Virtualbox 1.5.6

Are the ssh/sshd systems real or virtual?

Maurice Batey

unread,
Aug 17, 2008, 2:47:10 PM8/17/08
to
On Sun, 17 Aug 2008 18:43:30 +0000, Bit Twister wrote:

> I assume all test shots are not trying to ssh root@where

No - "ssh mab@MABsdesktop"

--

Bit Twister

unread,
Aug 17, 2008, 3:01:04 PM8/17/08
to
On Sun, 17 Aug 2008 19:45:18 +0100, Maurice Batey wrote:
>
> Tried that ("allow service xinetd reload") but ssh from

But did you Comment out sshd in /etc/hosts.allow?


It is odd, xinetd is installed but sshd-xinetd did not show up in
chkconfig --list | grep ssh

sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sshd-xinetd: off

Guessing /etc/xinetd.d/sshd-xinetd is not there.
Should have been installed when you installed the server package.

$ rpm -q -f /etc/xinetd.d/sshd-xinetd
openssh-server-4.7p1-2.3mdv2008.0

I am not happy that you do not have /etc/xinetd.d/sshd-xinetd

> As the desktop ssh self-call seemed to work, is it possible
> something is awry on the laptop?

Since you cannot connect, something is stopping it.

> The fact that it's ssh reports Port 22 refusal to connect does
> show that ssh is working, doesn't it?

Yes, shows that ssh on the laptop is trying to connect.

Verify ip address in laptop /etc/hosts matches
hostname -i
on desktop

Bit Twister

unread,
Aug 17, 2008, 3:02:49 PM8/17/08
to
On Sun, 17 Aug 2008 19:47:10 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 18:43:30 +0000, Bit Twister wrote:
>
>> I assume all test shots are not trying to ssh root@where
>
> No - "ssh mab@MABsdesktop"

groping around in the dark.

do a hosthame -i on MABsdesktop

and a ssh mab@the_above_ip_address_here


Bit Twister

unread,
Aug 17, 2008, 3:06:11 PM8/17/08
to
On Sun, 17 Aug 2008 19:02:49 +0000 (UTC), Bit Twister wrote:

in ~mab on desktop do
cd ~/.ssh
chmod 700 .
chmod 600 *
cd

and do the same on the laptop

and run the test shot

Maurice Batey

unread,
Aug 17, 2008, 5:23:42 PM8/17/08
to
On Sun, 17 Aug 2008 18:45:44 +0000, Bit Twister wrote:

> Are the ssh/sshd systems real or virtual?

Absolutely real! (Only WIndows stuff under VBox)

--

Maurice Batey

unread,
Aug 17, 2008, 5:26:47 PM8/17/08
to
On Sun, 17 Aug 2008 19:02:49 +0000, Bit Twister wrote:

> do a hosthame -i on MABsdesktop
>
> and a ssh mab@the_above_ip_address_here

-------------------------------------------------------
[mab@localhost ~]$ hostname -i
127.0.0.1

[mab@localhost ~]$ ssh m...@127.0.0.1
Warning: Permanently added '127.0.0.1' (RSA) to the list of known
hosts.
m...@127.0.0.1's password:
Last login: Sun Aug 17 18:25:23 2008 from localhost
[mab@localhost ~]$ exit
logout

Connection to 127.0.0.1 closed.
[mab@localhost ~]$
------------------------------------------------------

Bit Twister

unread,
Aug 17, 2008, 5:27:58 PM8/17/08
to
On Sun, 17 Aug 2008 22:23:42 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 18:45:44 +0000, Bit Twister wrote:
>
>> Are the ssh/sshd systems real or virtual?
>
> Absolutely real! (Only WIndows stuff under VBox)

You seem to missing/ignoring my questions in other replies,
the ones ending in ?.

Maybe, your just behind in answering them. :)
Guess I'll wait and see.

Maurice Batey

unread,
Aug 17, 2008, 5:33:17 PM8/17/08
to
On Sun, 17 Aug 2008 19:01:04 +0000, Bit Twister wrote:

> But did you Comment out sshd in /etc/hosts.allow?

Yes.


>
> $ rpm -q -f /etc/xinetd.d/sshd-xinetd
openssh-server-4.7p1-2.3mdv2008.0

--------------------------------------------------
[mab@localhost ~]$ rpm -q -f /etc/xinetd.d/sshd-xinetd
openssh-server-4.7p1-2.3mdv2008.0
--------------------------------------------------


>
> Verify ip address in laptop /etc/hosts matches hostname -i
> on desktop

It does - both 127.0.0.1

Maurice Batey

unread,
Aug 17, 2008, 5:40:18 PM8/17/08
to
On Sun, 17 Aug 2008 19:06:11 +0000, Bit Twister wrote:

> in ~mab on desktop do
> cd ~/.ssh
> chmod 700 .
> chmod 600 *
> cd
>
> and do the same on the laptop

OK on desktop, but laptop has no ~/.ssh directory anywhere.
(And ssh from laptop still fails.)

Have to close down now. 'night all...

Bit Twister

unread,
Aug 17, 2008, 6:33:37 PM8/17/08
to
On Sun, 17 Aug 2008 22:33:17 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 19:01:04 +0000, Bit Twister wrote:
>
>> But did you Comment out sshd in /etc/hosts.allow?
>
> Yes.

Good. I will suggest something like
sshd: 192.168.0.3, 192.168.0.0/255.255.255.0

for you final test.

>>
>> $ rpm -q -f /etc/xinetd.d/sshd-xinetd
> openssh-server-4.7p1-2.3mdv2008.0
> --------------------------------------------------
> [mab@localhost ~]$ rpm -q -f /etc/xinetd.d/sshd-xinetd
> openssh-server-4.7p1-2.3mdv2008.0
> --------------------------------------------------

Something went wrong because I expected sshd-xinetd
to show up in your chkconfig --list | grep ssh

Tell you what, bring up MCC and set On Boot for sshd.
verify the other sshd is off/unchecked.
and click Ok. Quit MCC and do a

chkconfig --list | grep ssh

sshd-xinetd should now show up.


>> Verify ip address in laptop /etc/hosts matches hostname -i
>> on desktop
>
> It does - both 127.0.0.1


hmmm, ok, I had expected something like
$ hostname -i
192.168.0.2

Because I assumed
$ grep -i $(hostname -a) /etc/hosts
192.168.0.2 desktop.mab.unregistered MABsdesktop
would be found on the desktop. My bad.

Let's ignore that for the moment:

On MABsdesktop do a

ifconfig
and double check the nic connected to the laptop shows 192.168.0.2, then

ssh m...@192.168.0.2
and if it works;

run
ssh m...@192.168.0.2
on the laptop

Sleep tight.

Bit Twister

unread,
Aug 17, 2008, 8:37:53 PM8/17/08
to
On Sun, 17 Aug 2008 22:26:47 +0100, Maurice Batey wrote:


> [mab@localhost ~]$ hostname -i
> 127.0.0.1

Heheh, just an FYI for the lurkers.


[bittwister@pm80 ~]$ cat /etc/release
Mandriva Linux release 2008.0 (Official) for i586

[bittwister@pm80 ~]$ grep $(hostname) /etc/hosts
192.168.1.213 pm80.home.test pm80

[bittwister@pm80 ~]$ ssh $US...@127.0.0.1
Last login: Sun Aug 17 19:29:09 2008 from localhost

[bittwister@pm80 ~] exit
Connection to 127.0.0.1 closed.


[bittwister@wm81 ~]$ cat /etc/release
Mandriva Linux release 2008.1 (Official) for i586

[bittwister@wm81 ~]$ grep $(hostname) /etc/hosts
192.168.1.131 wm81.home.test wm81

[bittwister@wm81 ~]$ ssh $US...@127.0.0.1
ssh_exchange_identification: Connection closed by remote host

Snippet from /var/log/messages
Aug 17 19:23:32 wm81 sshd[9895]:
refused connect from localhost.localdomain (::ffff:127.0.0.1)

Bit Twister

unread,
Aug 17, 2008, 10:01:34 PM8/17/08
to
On Mon, 18 Aug 2008 00:37:53 +0000 (UTC), Bit Twister wrote:

bittwister wrote:
> Snippet from /var/log/messages
> Aug 17 19:23:32 wm81 sshd[9895]:
> refused connect from localhost.localdomain (::ffff:127.0.0.1)

Just a follow up. Rejection was caused because of hosts.allow did not
catch it and let host.deny reject it.

Thought hosts.allow should have let it through.

ALL: LOCAL, .home.test

#****** End of hosts.allow. ********

Looking on pm80, I had to add wm81 ip address to hosts.allow
for wm81 access.

On wm81 (2008.1) None of the following worked
sshd: .home.test
sshd: .home.test, LOCAL, 192.168.1.131
sshd: .home.test, LOCAL, 192.168.1.131, 192.168.1.0/24
ALL: LOCAL, .home.test, 192.168.1.131, 192.168.1.0/24

My host.allow solution for ssh $US...@127.0.0.1 on 2008.1 is

ALL: LOCAL, .home.test, 27.0.0.1

2008.0 has
ALL: LOCAL, .home.test, 192.168.1.131, 192.168.1.0/24

Gotta love the increase in security.

Bit Twister

unread,
Aug 17, 2008, 10:05:43 PM8/17/08
to
On Mon, 18 Aug 2008 02:01:34 +0000 (UTC), Bit Twister wrote:
> On Mon, 18 Aug 2008 00:37:53 +0000 (UTC), Bit Twister wrote:
>
> bittwister wrote:
>> Snippet from /var/log/messages
>> Aug 17 19:23:32 wm81 sshd[9895]:
>> refused connect from localhost.localdomain (::ffff:127.0.0.1)
>
> Just a follow up. Rejection was caused because of hosts.allow did not
> catch it and let host.deny reject it.
>
> Thought hosts.allow should have let it through.
>
> ALL: LOCAL, .home.test
>
> #****** End of hosts.allow. ********
>
> Looking on pm80, I had to add wm81 ip address to hosts.allow
> for wm81 access.
>
> On wm81 (2008.1) None of the following worked
> sshd: .home.test
> sshd: .home.test, LOCAL, 192.168.1.131
> sshd: .home.test, LOCAL, 192.168.1.131, 192.168.1.0/24
> ALL: LOCAL, .home.test, 192.168.1.131, 192.168.1.0/24
>
> My host.allow solution for ssh $US...@127.0.0.1 on 2008.1 is
>
> ALL: LOCAL, .home.test, 27.0.0.1

Opps, cut did not pick up 1, should read
ALL: LOCAL, .home.test, 127.0.0.1

Maurice Batey

unread,
Aug 18, 2008, 10:24:10 AM8/18/08
to
On Sun, 17 Aug 2008 21:27:58 +0000, Bit Twister wrote:

> You seem to missing/ignoring my questions in other replies, the ones
> ending in ?.

Not deliberately, I can assure you!

Will comb through and check. Watch this space... 8-))

Bit Twister

unread,
Aug 18, 2008, 10:29:07 AM8/18/08
to
On Mon, 18 Aug 2008 15:24:10 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 21:27:58 +0000, Bit Twister wrote:
>
>> You seem to missing/ignoring my questions in other replies, the ones
>> ending in ?.
>
> Not deliberately, I can assure you!
>
> Will comb through and check. Watch this space... 8-))

Tell you what, Instead of that, go through this and see what needs
improvement and lets you run a check front to back.


-------- standard debug ssh/sshd problem steps follows: ------------
Version
0.0

The following is mainly for Mandriva, maybe Suse, maybe Redhat/Fedora and
your install is not using SELinux/ACL's.

I assume you have:
o installed ALL system updates and have rebooted.
o installed the sshd daemon/service package. (OpenSSH Server).
o enabled it to run on boot.
o started sshd on the server.

In this document, "server" is where you are trying to ssh into and
"client" is where you ssh from.

Client is where ssh it trying to connect to sshd on the server.

All ssh test shots will be to a user account on the server, not root.
Where you see bittwister, or ~/, you should be in/using your user account.

Some commands need root privileges to run. To create a root terminal,
Click up a terminal,
su - root or for the k/ubuntu crowd it would be
sudo -i

Anytime I am working a problem, I will open another root terminal and do a

tail -f /var/log/messages
on each system I am working with.

I suggest you do the same.

PS: To abort tail -f command, do a Control c
To close a terminal/ssh session exit

sshd has to running and/or enabled to run on the server.

pgrep -lf sshd <===== Should return the pid and program name
3866 /usr/sbin/sshd <============ see, sshd is running, pid=3866

It might not be running if sshd is to run when needed. :(

Do check the permissions on it

ls -al /usr/sbin/sshd
-rwxr-xr-x 1 root root 379292 2008-05-06 14:53 /usr/sbin/sshd


chkconfig --list | grep sshd <====== on some systems
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off <= which run level starts on boot
sshd-xinetd: off <=== on indicates to start when needed

NOTE: Do not have both set on.

Current run level found with
/sbin/runlevel
N 3 <==== indicates my system is set at 3 and 3:on indicates
sshd will be started on boot.

If not running, you might be able to start it with
service sshd start
or maybe
/etc/init.d/sshd start


First prove you can connect to it by ip address when you are on the server

ssh bittwister@$(hostname -i)

If there is nothing in /etc/hosts.allow and /etc/hosts.deny
I expect that to work.

If fails, make sure your user account's .ssh directory has the correct
permissions by doing:

cd ~/.ssh
chmod 700 .
chmod 600 *
cd

ssh bittwister@$(hostname -i)

If no message showed up in /var/log/messages and there is nothing in
/etc/hosts.allow and /etc/hosts.deny I have no idea what to check next.

man hosts.allow to understand lines not starting with #

Next, run some test to prove network resolution is working.
Test by node name with
ssh bittwister@$(hostname --alias) then by fully qualified domain name
ssh bittwister@$(hostname --fqdn)

Failure on those, will be a /etc/hosts or network problem.
If so, only use the server's ip address from your client until
you get the network problem solved.

Once that works, verify the hostname ip matches what the client sees.
hostname -i on the server
host servers_hostname_here on the client.

If the hostname -i returns 127.0.0.1 on the server,
you need to use the ip address of the server's nic that
is connected to the client.

ifconfig to find the address. Snippet follows

eth1 Link encap:Ethernet HWaddr 00:16:17:57:66:54
inet addr:192.168.1.131 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::216:17ff:fe57:6654/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
the inet addr: field is ip4 ip address
the inet6: field is the ip6 ip address.

Verify the ip address test on server with
ssh bittwister@servers_ip_here


Once those run, only the firewall and /etc/hosts.allow and hosts.deny
contents would block incoming ssh attempts on the server.

You open the Mandriva firewall with
shorewall clear

Before doing that, get the server ip address for the nic connected to
the client.
ifconfig should give you a list of running nics.

hostname -i on the server.

assuming server is not blocking pings, verify connection with
ping -c1 servers_ip_here on the client, if works then
bittwister@servers_ip_here on the client.
if fails, hit up arrow

and open the firewall on the server with
shorewall clear
hit a carriage return on the client to run the ssh client to server
test shot again.

No matter what, quickly enable the firewall, with
service shorewall restart
or shorewall restart
on the server.

If no messages in /var/log/messages on the server and hosts.allow and
hosts.deny are empty. I do not know what the problem is.


If all the above seems to be true, you will need to dump your settings
so we can see them. Run the commands on server and client.
Cut the command and results and paste them in your reply.


hostname
hostname -fqdn
hostname -i
cat /etc/hosts
grep -v \# /etc/hosts.allow
grep -v \# /etc/hosts.deny
ifconfig

If you see repeatable error messages in the tail -f terminals
every time you do the ssh command, we need to see those also.

Would not hurt to provide results from doing something like
ssh -v bittwister@servers_ip_here
or ssh -vv bittwister@servers_ip_here
or ssh -vvv bittwister@servers_ip_here
which will give increasing debug information with each v.
Take a look at each and decide which one might help us.

PS:
If you run with /etc/hosts.allow and hosts.deny, I found
it helpful for /etc/hosts.deny to contain


ALL: ALL:\
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s \"$(uname -n)\" root ) & : DENY

#*********************** end host.deny ********************************

That will send an email to root any time something gets through hosts.allow
without being allowed.

Example email follows:.

TCP Wrappers: Connection Refused
By: wm81.home.test
Process: sshd (pid 11046)

User: unknown
Host: localhost.localdomain
Date: Sun Aug 17 20:50:41 CDT 2008

I have postfix installed, so I modified aliases to send any mail
to root to me.

tail -11 /etc/postfix/aliases | head -5

# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN

root: bittwister

And executed:
postalias aliases


Once postfix is restarted, all mail to root (security alerts, cron job
failures, audit failures,...) automagically shows up in my email box.

Maurice Batey

unread,
Aug 18, 2008, 11:18:36 AM8/18/08
to
On Sun, 17 Aug 2008 22:33:37 +0000, Bit Twister wrote:

> I will suggest something like
> sshd: 192.168.0.3, 192.168.0.0/255.255.255.0
>
> for you final test.

Tried that (see below). Still no go from laptop.

Here is what is in /etc/hosts, by the way:
----------------------------------------------------
127.0.0.1 localhost
192.168.0.1 router.mab.unregistered MABsrouter
192.168.0.2 desktop.mab.unregistered MABsdesktop
192.168.0.3 laptop.mab.unregistered MABslaptop
---------------------------------------------------

and non-descriptive entries in /etc/hosts.allow:

# sshd: 192.168.0.3/255.255.255.0
# service xinetd reload
# ALL: LOCAL, .mab.unregistered
ALL:LOCAL,.mab.unregistered,192.168.0.3,
192.168.0.0/255.255.255.0
----------------------------------------------------



> Tell you what, bring up MCC and set On Boot for sshd. verify
the other
> sshd is off/unchecked. and click Ok. Quit MCC

sshd was already running and set On Boot

What do you mean by "Verify the other sshd is off/unchecked"?
=============================================================
What other sshd?

> On MABsdesktop do a ifconfig and double check the nic connected
> to the laptop shows 192.168.0.2

If you mean (under eth0) "inet=", it shows:
inet addr:192.168.0.3
which is the IP of the laptop.

> Do ssh m...@192.168.0.2 on desktop

I assume you meant to laptop, which is 192.169.0.3, so used
latter and it did work - i.e. ssh connected to laptop.
(That puzzles me, because sshd is not running on laptop...)

> run ssh m...@192.168.0.2 on the laptop

Did you mean ssh on laptop to itself? As above, did ssh to
m...@192.168.0.3, and it did work (though no sshd on laptop).

On laptop, ssh mab@MABsdesktop) still fails - see -vv output:

--------------------------------------------------------
[mab@localhost ~]$ ssh -vv mab@MABsdesktop
OpenSSH_4.7p1, OpenSSL 0.9.8f 11 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to MABsdesktop [192.168.0.2] port 22.
debug1: connect to address 192.168.0.2 port 22: Connection
refused
ssh: connect to host MABsdesktop port 22: Connection refused
[mab@localhost ~]$
--------------------------------------------------------

The annoying thing is that - last year, when still using MDV
2007 on desktop and Vista on laptop - I could do ssh via Putty on
Vista!

Presumably this is not a router firewall problem. (Although it
does have an SSH blocker, I believe that only applies to traffic
coming from the outside 'net. Anyway, I tried turning the
blocker off - no difference (so turned it back on.))

Thanks for sticking with me, BT - much appreciated!
I keep thinking we're just one step away from cracking this...

Anything else I can do to help get there?

Bit Twister

unread,
Aug 18, 2008, 11:54:42 AM8/18/08
to
On Mon, 18 Aug 2008 16:18:36 +0100, Maurice Batey wrote:
> On Sun, 17 Aug 2008 22:33:37 +0000, Bit Twister wrote:
>
>> I will suggest something like
>> sshd: 192.168.0.3, 192.168.0.0/255.255.255.0
>>
>> for you final test.
>
> Tried that (see below). Still no go from laptop.

After playing around last night, I can now suggest just

ALL: .mab.unregistered, 192.168.0.

Until we can get ssh working from the laptop,
I wish you would not have any commands in hosts.allow and hosts.deny

> Here is what is in /etc/hosts, by the way:
> ----------------------------------------------------
> 127.0.0.1 localhost
> 192.168.0.1 router.mab.unregistered MABsrouter
> 192.168.0.2 desktop.mab.unregistered MABsdesktop
> 192.168.0.3 laptop.mab.unregistered MABslaptop
> ---------------------------------------------------

Which /etc/hosts file. With that hosts file,
you can have the same hosts file on both machines.

Just for fun, I want to make the hosts file the same
on both machines and looks as follows:

127.0.0.1 localhost
192.168.0.1 router.mab.unregistered router
192.168.0.2 desktop.mab.unregistered desktop
192.168.0.3 laptop.mab.unregistered laptop

>
> and non-descriptive entries in /etc/hosts.allow:
>
> # sshd: 192.168.0.3/255.255.255.0
> # service xinetd reload
> # ALL: LOCAL, .mab.unregistered
> ALL:LOCAL,.mab.unregistered,192.168.0.3,
> 192.168.0.0/255.255.255.0
> ----------------------------------------------------

Until we can get ssh working from the laptop,
I wish you would not have any commands in hosts.allow and hosts.deny
on either machine.

>
>> Tell you what, bring up MCC and set On Boot for sshd. verify
> the other
>> sshd is off/unchecked. and click Ok. Quit MCC
>
> sshd was already running and set On Boot
>
> What do you mean by "Verify the other sshd is off/unchecked"?
> =============================================================
> What other sshd?

In both 2008.0 and 2008.1 MCC System Services I have two lines/selections
sshd running [Info] [x] On Boot Start Stop
sshd-xinetd [Info] [ ] Start when Requested Start Stop

If you are missing sshd-xinetd, I have no idea why you are missing
/etc/xinetd.d/sshd-xinetd

$ ls -al /etc/xinetd.d/sshd-xinetd
-rw-r--r-- 1 root root 321 2008-05-06 14:53 /etc/xinetd.d/sshd-xinetd

You have shown me it was in the rpm in an earlier post.


>> On MABsdesktop do a ifconfig and double check the nic connected
>> to the laptop shows 192.168.0.2
>
> If you mean (under eth0) "inet=", it shows:
> inet addr:192.168.0.3
> which is the IP of the laptop.

Well, there you have it. Your settings in /etc/hosts and
what is configured for the nic are incorrect.

You have to make ip address in /etc/hosts match what is
in /etc/sysconfig/network-scripts/ifcfg-eth0's IPADDRESS
from each machine.


>
>> Do ssh m...@192.168.0.2 on desktop
>
> I assume you meant to laptop,

No assuming, as I mis-understood it, 192.168.0.2 is the desktop
running sshd.

So, I want to verify you can connect to the desktop from the desktop
with the desktop's ip address.
ip given as commands were what you told me was the ip for the desktop.

Numbers were before you told me about you ipconfig results on desktop.

>
> Presumably this is not a router firewall problem.

Nope, just involves two machines and their connection.

> (Although it
> does have an SSH blocker, I believe that only applies to traffic
> coming from the outside 'net.

Sounds about right.


> Anyway, I tried turning the
> blocker off - no difference (so turned it back on.))

Outstanding.


> Thanks for sticking with me, BT - much appreciated!
> I keep thinking we're just one step away from cracking this...

Good for you. I was about one step away from giving up. :(

> Anything else I can do to help get there?

First, get the ip addresses in /etc/hosts matching what you
find in the nics which connect to each machine.

Fix /etc/hosts on all machines.

Then go through the trouble shooting text provided in another
post and see if you understand/agree with what is checking doing
and your problem is fixed.

Maurice Batey

unread,
Aug 18, 2008, 12:13:32 PM8/18/08
to
On Mon, 18 Aug 2008 14:29:07 +0000, Bit Twister wrote:

> -------- standard debug ssh/sshd problem steps follows:

> I assume you have:
> o installed ALL system updates and have rebooted.
> o installed the sshd daemon/service package. (OpenSSH Server)

> o enabled it to run on boot.
> o started sshd on the server.

Yes.


>
> pgrep -lf sshd <===== Should return the pid and
program
> name 3866 /usr/sbin/sshd <============ see, sshd is running,
> pid=3866

Yes (though no sign of "pid=xxxx")



>
> It might not be running if sshd is to run when needed. :(
>
> Do check the permissions on it
>
> ls -al /usr/sbin/sshd
> -rwxr-xr-x 1 root root 379292 2008-05-06 14:53 /usr/sbin/sshd

Yes - same


>
> chkconfig --list | grep sshd <====== on some
systems sshd
> 0:off 1:off 2:on 3:on 4:on 5:on 6:off <= which run level starts on boot
> sshd-xinetd: off <=== on indicates to start when
> needed

OK - except still no sign of "sshd-xinetd..."
=============================

>
> Current run level found with
> /sbin/runlevel
> N 3 <==== indicates my system is set at 3 and 3:on
> indicates
> sshd will be started on boot.

Yes - that's OK


>
> First prove you can connect to it by ip address when you are on
the server
>
> ssh bittwister@$(hostname -i)

Fine.

> ssh bittwister@$(hostname --alias)

Failed:
------------------------------------------------
[mab@localhost ~]$ ssh mab@$(hostname --alias)
ssh: : Name or service not known
------------------------------------------------

then by fully qualified
domain name
> ssh bittwister@$(hostname --fqdn)

Fine.


>
> Once that works, verify the hostname ip matches what the client
sees.
> hostname -i on the server host servers_hostname_here on
> the client.

'hostname -i' gives 127.0.0.1,


>
> If the hostname -i returns 127.0.0.1 on the server, you need to use the ip
> address of the server's nic that is connected to the client.

I believe that is 192.168.0.2 in my case: cat /etc/hosts gives

127.0.0.1 localhost
192.168.0.1 router.mab.unregistered MABsrouter
192.168.0.2 desktop.mab.unregistered MABsdesktop
192.168.0.3 laptop.mab.unregistered MABslaptop

>

> ifconfig to find the address.

In my case:
-----------------------------------------------------------
eth0 Link encap:Ethernet HWaddr 00:1B:21:07:31:63
inet addr:192.168.0.3 Bcast:192.168.0.255
Mask:255.255.255.0


UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

------------------------------------------------------------


>
> Verify the ip address test on server with
> ssh bittwister@servers_ip_here

You mean - on server - ssh to itself? This is what happens:

------------------------------------------------------------
[mab@localhost ~]$ ssh m...@192.168.0.2
ssh: connect to host 192.168.0.2 port 22: Connection refused
------------------------------------------------------------
(though ssh m...@127.0.0.1 and ssh mab@(hostname) work)


I'll stop here, as my earoier posting today may have helped
clear the air.

Maurice Batey

unread,
Aug 18, 2008, 12:55:23 PM8/18/08
to
On Mon, 18 Aug 2008 15:54:42 +0000, Bit Twister wrote:

> After playing around last night, I can now suggest just
>
> ALL: .mab.unregistered, 192.168.0.
>
> Until we can get ssh working from the laptop, I wish you would not have
> any commands in hosts.allow and hosts.deny

So I should ignore the "ALL: .mab...." suggestion 5 lines
above here?
>
>> [quoted text muted]


>
> Which /etc/hosts file. With that hosts file, you can have the same hosts
> file on both machines.

But I already do! They are identical on both desktop & laptop...


>
> Just for fun, I want to make the hosts file the same on both machines and
> looks as follows:
>
> 127.0.0.1 localhost
> 192.168.0.1 router.mab.unregistered router
> 192.168.0.2 desktop.mab.unregistered desktop
> 192.168.0.3 laptop.mab.unregistered laptop

That's as already are, but omitting the 'MAB prefix. OK!

> Until we can get ssh working from the laptop, I wish you would
> not have any commands in hosts.allow and hosts.deny on either
> machine.

OK - will comment them out.


>
> In both 2008.0 and 2008.1 MCC System Services I have two
lines/selections
> sshd running [Info] [x] On Boot Start Stop
> sshd-xinetd [Info] [ ] Start when Requested Start Stop

No sign of tha sshd-xinetd entry...

> If you are missing sshd-xinetd, I have no idea why you are missing
> /etc/xinetd.d/sshd-xinetd

But it's not missing!
----------------------------------------------------
[mab@localhost ~]$ cat /etc/xinetd.d/sshd-xinetd
# default: off
# description: sshd server, xinetd version. \
# Don't run the standalone version if you run \
# this.
service ssh
{
disable = yes
socket_type = stream
wait = no
user = root
server = /usr/sbin/sshd
server_args = -i
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
}
--------------------------------------------------------

> -rw-r--r-- 1 root root 321 2008-05-06 14:53
> /etc/xinetd.d/sshd-xinetd

Check here on desktop:
------------------------------------------------------
[mab@localhost ~]$ ls -al /etc/xinetd.d/sshd-xinetd
-rw-r--r-- 1 root root 321 2008-05-06 20:50
/etc/xinetd.d/sshd-xinetd
------------------------------------------------------
Seems a bit of a mystery. It's there but showing up where it
should. How can that be? (Or, how can it be made to...)


> Your settings in /etc/hosts and what is configured for the
> nic are incorrect.
>
> You have to make ip address in /etc/hosts match what is in
> /etc/sysconfig/network-scripts/ifcfg-eth0's IPADDRESS from each machine.

I've no idea why ifconfig shows the wrong host IP!

(Are you saying "inet addr" should show 192.168.0.2, rather
than 192.168.0.3?)

How does one figure out how to acquire the correct info from the
ifcg-eth0 file so that ifconfig shows correct IP?
Here are the contents of that file on desktop:
----------------------------------------------------------------
[mab@localhost ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
NETMASK=255.255.255.0
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no
DHCP_CLIENT=dhclient
NEEDHOSTNAME=no
PEERDNS=yes
PEERYP=yes
---------------------------------------------------------------

Regards,

Bit Twister

unread,
Aug 18, 2008, 1:08:19 PM8/18/08
to
On Mon, 18 Aug 2008 17:13:32 +0100, Maurice Batey wrote:
> On Mon, 18 Aug 2008 14:29:07 +0000, Bit Twister wrote:

>> pgrep -lf sshd <===== Should return the pid and program name
>> 3866 /usr/sbin/sshd <============ see, sshd is running, pid=3866
>
> Yes (though no sign of "pid=xxxx")

Comment was trying to show 3866 is the pid, hence pid=3866
I change comment to read pid is 3866

>> chkconfig --list | grep sshd <====== on some
> systems sshd
>> 0:off 1:off 2:on 3:on 4:on 5:on 6:off <= which run level starts on boot
>> sshd-xinetd: off <=== on indicates to start when
>> needed
>
> OK - except still no sign of "sshd-xinetd..."
> =============================

That is a problem in it's self. No idea why it is not there.
It is in the sshd package you installed.

>
>> ssh bittwister@$(hostname --alias)
>
> Failed:
> ------------------------------------------------
> [mab@localhost ~]$ ssh mab@$(hostname --alias)
> ssh: : Name or service not known
> ------------------------------------------------

Ok, your node name of localhost is biting you. You need to set the
hostname to a FQDN value. Suggestion follows:

$ cat /etc/sysconfig/network
NETWORKING_IPV6=no
NOZEROCONF=yes
NEEDHOSTNAME=no
NETWORKING=yes
HOSTNAME=desktop.mab.unregistered <========= FQDN node set here

Recommendation:
$ cat /etc/sysconfig/network
NETWORKING_IPV6=no
NOZEROCONF=yes
NEEDHOSTNAME=no
NETWORKING=yes
HOSTNAME=desktop.mab.test <========= better domain name here

Read http://www.rfc-editor.org/rfc/rfc2606.txt

NOTE: warning, anytime I change the hostname, I reboot to make every
service/daemon aware of the name change, and check nothing breaks.

>>
>> If the hostname -i returns 127.0.0.1 on the server, you need to use the ip
>> address of the server's nic that is connected to the client.
>
> I believe that is 192.168.0.2 in my case: cat /etc/hosts gives

Belief does not hack it. You are required to KNOW.

>
> 127.0.0.1 localhost
> 192.168.0.1 router.mab.unregistered MABsrouter
> 192.168.0.2 desktop.mab.unregistered MABsdesktop
> 192.168.0.3 laptop.mab.unregistered MABslaptop

Just an FYI, those long aliases could bit you. I suggest getting them
less than 9 characters.


>
>>
>> ifconfig to find the address.
> In my case:
> -----------------------------------------------------------
> eth0 Link encap:Ethernet HWaddr 00:1B:21:07:31:63
> inet addr:192.168.0.3 Bcast:192.168.0.255
> Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> ------------------------------------------------------------
>>
>> Verify the ip address test on server with
>> ssh bittwister@servers_ip_here
>
> You mean - on server - ssh to itself?

Yep, that is just what you did with these commands:
ssh bittwister@$(hostname -i)
ssh bittwister@$(hostname --alias)
ssh bittwister@$(hostname --fqdn)

> This is what happens:

>
> ------------------------------------------------------------
> [mab@localhost ~]$ ssh m...@192.168.0.2
> ssh: connect to host 192.168.0.2 port 22: Connection refused
> ------------------------------------------------------------

> (though ssh m...@127.0.0.1 and ssh mab@$(hostname) work)

And why is that you ask. Run these three commands and see if you can relate.

grep 127.0.0.1 /etc/hosts
grep $(hostname) /etc/hosts
echo $(hostname)

> I'll stop here, as my earoier posting today may have helped
> clear the air.

Guessing my reply to that post should have fixed it. :-)

David W. Hodgins

unread,
Aug 18, 2008, 1:29:52 PM8/18/08
to
On Mon, 18 Aug 2008 12:55:23 -0400, Maurice Batey <mau...@bcs.removethis.org.uk> wrote:

> I've no idea why ifconfig shows the wrong host IP!

It doesn't. The hosts files are wrong.
Change the hosts file (on both systems) to show what ifconfig shows.

Also, try running "chkconfig --list" without any other pararaters, or piping it
to grep. Does it show the sshd-xinetd?

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

Bit Twister

unread,
Aug 18, 2008, 1:38:54 PM8/18/08
to
On Mon, 18 Aug 2008 17:55:23 +0100, Maurice Batey wrote:
> On Mon, 18 Aug 2008 15:54:42 +0000, Bit Twister wrote:
>
>> After playing around last night, I can now suggest just
>>
>> ALL: .mab.unregistered, 192.168.0.
>>
>> Until we can get ssh working from the laptop, I wish you would not have
>> any commands in hosts.allow and hosts.deny
>
> So I should ignore the "ALL: .mab...." suggestion 5 lines
> above here?

I am saying, when you get done making the laptop to desktop test work,
and you are ready to enable /etc/host.allow controls, the only
line you will need is

ALL: .mab.unregistered, 192.168.0.

>> Which /etc/hosts file. With that hosts file, you can have the same hosts
>> file on both machines.
>
> But I already do! They are identical on both desktop & laptop...

Heheheh, But I did not know that. :-D

>
>> If you are missing sshd-xinetd, I have no idea why you are missing
>> /etc/xinetd.d/sshd-xinetd
>
> But it's not missing!
> ----------------------------------------------------
> [mab@localhost ~]$ cat /etc/xinetd.d/sshd-xinetd
> # default: off

Then check the perms.

$ ls -ald /etc/xinetd.d/
drwxr-xr-x 2 root root 4096 2008-08-14 19:34 /etc/xinetd.d/

>> Your settings in /etc/hosts and what is configured for the
>> nic are incorrect.
>>
>> You have to make ip address in /etc/hosts match what is in
>> /etc/sysconfig/network-scripts/ifcfg-eth0's IPADDRESS from each machine.
>
> I've no idea why ifconfig shows the wrong host IP!
>
> (Are you saying "inet addr" should show 192.168.0.2, rather
> than 192.168.0.3?)
>
> How does one figure out how to acquire the correct info from the
> ifcg-eth0 file so that ifconfig shows correct IP?
> Here are the contents of that file on desktop:
> ----------------------------------------------------------------
> [mab@localhost ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
> DEVICE=eth0
> BOOTPROTO=dhcp

Ok, what I am saying, is, if laptop is sshing into desktop,
then desktop's ip address in laptop's hosts file has to match
the ip address where laptop connects to desktop.

Here look at this drawing


192.168.1.1 pc1 node's gateway
192.168.1.14 pc1 node's ip
|
v
x pc1 printer 24.x.x.xx
x \ / |
x \ / v
x Hub---------eth1_fw_eth0---cablemodem-----ISPgateway---Internet
x / ^ ^
x / | |
x pc2 192.168.1.1 ggg.ggg.ggg.1
^ lan gateway
|
192.168.1.12 pc2 node's ip
192.168.1.1 pc2 node's gateway

If pc2 wanted to ssh to fw.
pc2's hosts file would have
192.168.1.1 fw.home.test fw


If you cannot understand what I am saying, draw a picture, label with
values and I will run over this again.

Maurice Batey

unread,
Aug 18, 2008, 1:51:51 PM8/18/08
to
On Mon, 18 Aug 2008 17:38:54 +0000, Bit Twister wrote:

> Then check the perms.
>
> $ ls -ald /etc/xinetd.d/
> drwxr-xr-x 2 root root 4096 2008-08-14 19:34 /etc/xinetd.d/

OK:
-------------------------------------------------------------
[mab@desktop ~]$ ls -ald /etc/xinetd.d/
drwxr-xr-x 2 root root 4096 2008-08-17 16:54 /etc/xinetd.d//
-------------------------------------------------------------

Still a mystery, I guess...

However, despite all that, you can GET OUT THE FLAGS!
MAFEKING HAS BEEN RELIEVED... 8-))

I can now ssh in to desktop from laptop, now that the IP muddle
has been identified and sorted out.
(I really don't know how they got mixed up, but whenever it
did was yonks ago, and a lot of water has flown under the bridge
(and probably into what's left of my brain) since then.)

BT, many many thanks once again for your unstinted help and
patience - very much appreciated indeed.

Maurice Batey

unread,
Aug 18, 2008, 1:54:00 PM8/18/08
to
On Mon, 18 Aug 2008 13:29:52 -0400, David W. Hodgins wrote:

> try running "chkconfig --list" without any other pararaters, or
> piping it to grep. Does it show the sshd-xinetd?

No! Absolutely no sign of it, Dave.

Bit Twister

unread,
Aug 18, 2008, 1:55:32 PM8/18/08
to
On Mon, 18 Aug 2008 18:51:51 +0100, Maurice Batey wrote:

> [mab@desktop ~]$ ls -ald /etc/xinetd.d/
> drwxr-xr-x 2 root root 4096 2008-08-17 16:54 /etc/xinetd.d//


What is that // doing on the end of that line. Should be

Maurice Batey

unread,
Aug 18, 2008, 2:27:44 PM8/18/08
to
On Mon, 18 Aug 2008 17:55:32 +0000, Bit Twister wrote:

> What is that // doing on the end of that line. Should be
>
> $ ls -ald /etc/xinetd.d/
> drwxr-xr-x 2 root root 4096 2008-08-14 19:34 /etc/xinetd.d/

Mmm. I tried it without the '/' on the end of the call and the
2nd '/' doesn't appear!:
-------------------------------------------------------------


[mab@desktop ~]$ ls -ald /etc/xinetd.d

drwxr-xr-x 2 root root 4096 2008-08-17 16:54 /etc/xinetd.d/

-------------------------------------------------------------

Figure that one out!

David W. Hodgins

unread,
Aug 18, 2008, 2:24:51 PM8/18/08
to
On Mon, 18 Aug 2008 13:51:51 -0400, Maurice Batey <mau...@bcs.removethis.org.uk> wrote:

> Still a mystery, I guess...

Do you have the package xinetd installed? Run "rpm -q -i xinetd"
Is it running "service xinetd status"?

Bit Twister

unread,
Aug 18, 2008, 2:46:44 PM8/18/08
to
On Mon, 18 Aug 2008 19:27:44 +0100, Maurice Batey wrote:
>
> Mmm. I tried it without the '/' on the end of the call and the
> 2nd '/' doesn't appear!:
>
> Figure that one out!

No thank you. :)

Homework assignment.
type ls
type -a ls

On the subject of hosts.allow and hosts.deny.

Your initial setup did not have anything in hosts.deny.

I recommend All: ALL if you are not going to use mine.

If you are going to hardcode ip addresses in /etc/hosts
I recommend setting static instead of dynamic (chcp)
for those interfaces.

I recommend a FQDN for all nodes. For the linux install, I recommend
these lines and values <=============
$ cat /etc/sysconfig/network
NETWORKING_IPV6=no <=============
NOZEROCONF=yes <=============
NEEDHOSTNAME=no <=============
NETWORKING=yes <=============
HOSTNAME=desktop.mab.test <=============

Maurice Batey

unread,
Aug 18, 2008, 2:46:52 PM8/18/08
to
On Mon, 18 Aug 2008 14:24:51 -0400, David W. Hodgins wrote:

> Do you have the package xinetd installed? Run "rpm -q -i xinetd" Is it
> running "service xinetd status"?

[root@desktop mab]# rpm -q -i xinetd
package xinetd is not installed

So - in spite of all that evidence to the contrary - it appears
not!

Have now installed it via MCC.

Is there anything more that should be done with it?

Maurice Batey

unread,
Aug 18, 2008, 2:53:06 PM8/18/08
to
On Mon, 18 Aug 2008 15:54:42 +0000, Bit Twister wrote:

> In both 2008.0 and 2008.1 MCC System Services I have two lines/selections
> sshd running [Info] [x] On Boot Start Stop
> sshd-xinetd [Info] [ ] Start when Requested Start Stop

I now see those two entries.

Bit Twister

unread,
Aug 18, 2008, 2:57:03 PM8/18/08
to
On Mon, 18 Aug 2008 19:46:52 +0100, Maurice Batey wrote:
> On Mon, 18 Aug 2008 14:24:51 -0400, David W. Hodgins wrote:
>
>> Do you have the package xinetd installed? Run "rpm -q -i xinetd" Is it
>> running "service xinetd status"?
>
> [root@desktop mab]# rpm -q -i xinetd
> package xinetd is not installed
>
> So - in spite of all that evidence to the contrary - it appears
> not!
>
> Have now installed it via MCC.
>
> Is there anything more that should be done with it?

In your case, so far, it is only good for deciding if you want sshd started
on boot, or if sshd only starts when a sshd connection is tried.

Maurice Batey

unread,
Aug 18, 2008, 5:48:29 PM8/18/08
to
On Mon, 18 Aug 2008 18:57:03 +0000, Bit Twister wrote:

> In your case, so far, it is only good for deciding if you want sshd
> started on boot, or if sshd only starts when a sshd connection is tried.

OIC - that answers a question I was going to ask!

How does one use it to get sshd to start only when a ssh
connection is attempted?

Aragorn

unread,
Aug 18, 2008, 6:04:43 PM8/18/08
to
On Monday 18 August 2008 23:48, someone identifying as *Maurice Batey* wrote
in /alt.os.linux.mandriva:/

> On Mon, 18 Aug 2008 18:57:03 +0000, Bit Twister wrote:
>
>> In your case, so far, it is only good for deciding if you want sshd
>> started on boot, or if sshd only starts when a sshd connection is tried.
>
> OIC - that answers a question I was going to ask!
>
> How does one use it to get sshd to start only when a ssh
> connection is attempted?

If that is what you want, then you should use /xinet-sshd/ - or whatever
it's called - instead of the regular sshd, and then you must set
up /xinetd/ to include /sshd/ among the offered services.

--
*Aragorn*
(registered GNU/Linux user #223157)

Bit Twister

unread,
Aug 18, 2008, 6:26:15 PM8/18/08
to
On Mon, 18 Aug 2008 22:48:29 +0100, Maurice Batey wrote:
>
> How does one use it to get sshd to start only when a ssh
> connection is attempted?

Get into MCC Services,
uncheck sshd On Boot
click Stop for sshd
click Start when requested for ssd-xinetd
Click Ok, bottom left
Control q
Control q

man xinetd
man xinetd.conf

And start hacking away at
/etc/xinetd.d/sshd-xinetd
do keep an original somewhere else before editing. :-)

Maurice Batey

unread,
Aug 19, 2008, 11:44:13 AM8/19/08
to
On Mon, 18 Aug 2008 18:46:44 +0000, Bit Twister wrote:

> I recommend All: ALL if you are not going to use mine.

Have put that in /etc/hosts/deny; thanks.

I did take a long look at your 'email' setup for that file,
and would love to have it, but it seemd so intricate that I
chickened out, as it would have cost you more days of
trouble-shooting to get it working. 8-)

I assume the purpose is to report any rogue attempt to ssh in to
the server via the router wireless channel.
In my case the router is WAP-key protected, and no one else
here would know what 'ssh' was, so I don't feel a need for more
security.

But all the same it looks an interesting project for a rainy
day...

> If you are going to hardcode ip addresses in /etc/hosts ..

How does one avoid that?

Maurice Batey

unread,
Aug 19, 2008, 12:04:22 PM8/19/08
to
On Mon, 18 Aug 2008 22:26:15 +0000, Bit Twister wrote:

> Get into MCC Services,
> uncheck sshd On Boot
> click Stop for sshd
> click Start when requested for ssd-xinetd Click Ok, bottom left

Happy with that!

> And start hacking away at /etc/xinetd.d/sshd-xinetd

Mmm. I won't get into that, as I don't see a need for
sshd-xinetd (yet).

Many thanks!

Maurice Batey

unread,
Aug 19, 2008, 12:10:48 PM8/19/08
to
On Tue, 19 Aug 2008 00:04:43 +0200, Aragorn wrote:

> If that is what you want, then you should use /xinet-sshd/ - or whatever
> it's called - instead of the regular sshd, and then you must set up
> /xinetd/ to include /sshd/ among the offered services.

I installed xinetd because I got the impression it was needed
to properly allow the SSH from laptop, hence my wondering how it
is used.

As I was (eventually!) able to achieve the SSH connection without
it, and don't really need the 'start at first call' facility, I
propose to uninstall it as superfluous (unless there is some
other reason why it should be kept).