Topic: remote and local ssh login keeps failing

[byte]

What version of putty are you using?! I had this problem with an suse 9.1 machine and it turned out the ssh had disabled ssh v1 and the putty i had didnt support v2 so i downloaded latest version and solved my problem  

[azche24]

Do you have any custom templates in:
/etc/e-smith/templates-custom/etc/ssh/sshd_config ?

Yes: 20protocol

If so what are they?

Protocol 2 (just this one line)

Do you get a "failed" message when you do:
service sshd reload

Yes: [failed]

I could do sshd start.

After that again the connection was refused even with the latest putty 0.55!

This is the logfiles:

Sep 24 10:03:37 castor sshd: sshd shutdown failed
Sep 24 10:03:41 castor sshd:  succeeded
Sep 24 10:03:41 castor sshd[4355]: Server listening on 0.0.0.0 port 22.
Sep 24 10:03:49 castor sshd[4355]: Received SIGHUP; restarting.
Sep 24 10:03:49 castor sshd: sshd -HUP succeeded
Sep 24 10:03:49 castor sshd[4381]: Server listening on 0.0.0.0 port 22.
Sep 24 10:04:30 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)
Sep 24 10:41:34 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)
Sep 24 10:43:22 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)
Sep 24 10:50:23 castor /etc/e-smith/web/panels/manager/cgi-bin/remoteaccess[5511]: /home/e-smith/configuration: OLD sshd=service|PasswordAuthentication|yes|PermitRootLogin|yes|access|private|status|enabled
Sep 24 10:50:23 castor /etc/e-smith/web/panels/manager/cgi-bin/remoteaccess[5511]: /home/e-smith/configuration: NEW sshd=service|PasswordAuthentication|yes|PermitRootLogin|yes|access|public|status|enabled
Sep 24 10:49:52 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)

[Reinhold]

Hi Alexander,

Hope you'll recover from the flu soon !

Now there IS some confusing data in your posts...
-You used two different servers Castor, Pollux...
Pollux:
Sep 22 07:55:43 pollux sshd[22212]: Accepted password for root from 192.168.1.4 port 1893 ssh2
Sep 22 07:56:35 pollux sshd[22212]: Received disconnect from 192.168.1.4: 11: All open channels closed
That seems strange ... i.e. who is closing ??? Pollux OK? ...note that Pollux seems on sshd private i.e. bound to 192.168.1.x  

Castor:
...wasn't running sshd so you couldn't stop it.
Now when you started it was on 0.0.0.0 (???)
and it refused connection from 192.168.57.9 (whereas from above I assume you are in subnet 192.168.1.x)
...even if you have (obviously) /public/enabled there's something fishy about this.

In short: Getting fuzzy here so please give the direct configuration file as in /etc/ssh/sshd_config
...preferably for both castor&pollux

(*) meanwhile you may
- stick things to private sshd and
- go through the webadmin interface once (=set it),
- then use a fresh, standards unmodified putty 0.55 (i.e. ssh2) to
-ip-connect with castor/pollux from within the subnet ... and tell us what happens

Regards
Reinhold

[azche24]

Hi Reinhold,

i recovered - getting closer to the problem now.

1. reinstalled openssh again
2. when doing sshd reload i get sshd re-exec requires absolute path and nothing else happens.
3. my sshd_config in /etc/sshd is like this:

#   $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~

This must be the standard-file!

4. And in the logs (with a new an clean putty) is still get

Oct  2 15:41:49 castor sshd[4142]: Server listening on 0.0.0.0 port 22.
Oct  2 15:42:46 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)
Oct  2 15:47:13 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)
Oct  2 15:50:21 castor sshd: refused connect from 192.168.57.9 (192.168.57.9)

Of course i am connecting from this local network, where this particular server castor is located.

And: sshd dies after reboot. It is not started after reboot.

Very strange...

[smeghead]

Yep, its a standard sshd config with nothing uncommented.  Execute /sbin/e-smith/expand-template /etc/sshd/sshd_config and then recheck the file.  If the command errors or the file is not changed then you have a template problem.  If you get a good sshd file then restart sshd & try it out.

For your reference my cchd_config file looks like this:

#------------------------------------------------------------
# DO NOT MODIFY THIS FILE! It is updated automatically by the
# SME Server software. Instead, modify the source template in
# an /etc/e-smith/templates-custom directory. For more
# information, see http://www.e-smith.org/custom/
#
# copyright (C) 1999-2003 Mitel Networks Corporation
#------------------------------------------------------------


Port 22
ListenAddress 10.10.10.10

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_rsa_key
KeyRegenerationInterval 3600
LoginGraceTime 600

ServerKeyBits 768
ChallengeResponseAuthentication no
Compression yes

IgnoreRhosts yes

KbdInteractiveAuthentication no


MaxStartups 10:30:60

PasswordAuthentication yes
PermitEmptyPasswords no
PermitRootLogin yes
RSAAuthentication yes

RhostsRSAAuthentication no

StrictModes yes
UsePrivilegeSeparation yes
Subsystem      sftp    /usr/libexec/openssh/sftp-server
X11DisplayOffset 10
X11Forwarding no
KeepAlive yes
PrintMotd yes

The files in /etc/e-smith/templates/etc/ssh/sshd_config are:

-rw-r--r--    1 root     root           24 Feb 15  2002 00intro
-rw-r--r--    1 root     root            8 Feb 15  2002 10Port
-rw-r--r--    1 root     root          278 Feb 15  2002 15ListenAddress
-rw-r--r--    1 root     root           30 Feb 15  2002 20HostKey
-rw-r--r--    1 root     root           34 Feb 15  2002 20HostKeyDSA
-rw-r--r--    1 root     root           34 Feb 15  2002 20HostKeyRSA
-rw-r--r--    1 root     root           29 Feb 15  2002 20KeyRegenerationInterval
-rw-r--r--    1 root     root           19 Feb 15  2002 20LoginGraceTime
-rw-r--r--    1 root     root           18 Feb 15  2002 20Protocol
-rw-r--r--    1 root     root           18 Feb 15  2002 20ServerKeyBits
-rw-r--r--    1 root     root           35 Feb 15  2002 40ChallengeResponseAuthentication
-rw-r--r--    1 root     root           16 Sep 18  2003 40Compression
-rw-r--r--    1 root     root           68 Feb 15  2002 40IgnoreRhosts
-rw-r--r--    1 root     root          108 Feb 15  2002 40IgnoreUserKnownHosts
-rw-r--r--    1 root     root           32 Feb 15  2002 40KbdInteractiveAuthentication
-rw-r--r--    1 root     root          133 Feb 15  2002 40KerberosAuthentication
-rw-r--r--    1 root     root           88 Feb 15  2002 40KerberosTgtPassing
-rw-r--r--    1 root     root          373 Sep 18  2003 40MaxStartups
-rw-r--r--    1 root     root          380 Feb 15  2002 40PasswordAuthentication
-rw-r--r--    1 root     root           24 Feb 15  2002 40PermitEmptyPasswords
-rw-r--r--    1 root     root          271 Feb 15  2002 40PermitRootLogin
-rw-r--r--    1 root     root          105 Feb 15  2002 40RhostsRSAAuthentication
-rw-r--r--    1 root     root           22 Feb 15  2002 40RSAAuthentication
-rw-r--r--    1 root     root          100 Feb 15  2002 40SkeyAuthentication
-rw-r--r--    1 root     root           16 Feb 15  2002 40StrictModes
-rw-r--r--    1 root     root           27 Sep 18  2003 40UsePrivilegeSeparation
-rw-r--r--    1 root     root          508 Feb 15  2002 50SubsystemSftp
-rw-r--r--    1 root     root           20 Feb 15  2002 50X11DisplayOffset
-rw-r--r--    1 root     root           17 Feb 15  2002 50X11Forwarding
-rw-r--r--    1 root     root           14 Feb 15  2002 60KeepAlive
-rw-r--r--    1 root     root           14 Feb 15  2002 60PrintMotd
-rw-r--r--    1 root     root           17 Feb 15  2002 60UseLogin
-rw-r--r--    1 root     root           92 Feb 15  2002 80Logging

HTH

[smeghead]

.. of course you saw the deliberate mistake, the template command should be:

/sbin/e-smith/expand-template /etc/ssh/sshd_config

doh!

[Reinhold]

Hi Alexander,

Looking at your data I'd say smeghead has said it all .-)

You do have a "virgin" sshd config file
i.o.w. your SME-sshd-template is non-expanded,
and the sshd config is emptied (all #-ed) out.
(strange - hope there isn't more to that)

In short, on the local command-line issue two commands:

# /sbin/e-smith/expand-template /etc/ssh/sshd_config
# /sbin/e-smith/signal-event remoteaccess-update

(of course you have to remove the "# " in front but I know you know .-)

now check the  /etc/ssh/sshd_config    file again...
the line starting with ListenAddress should show your SERVER-IP now...
ListenAddress 192.168.57.9  ...or something like that.

x-ing fingers

Reinhold

[azche24]

Hi folks,

this solved it: The complete e-smith-openssh was uninstalled (perhaps i did it myself during manual update?) - poor me  

Complete /etc/e-smith/templates/ssh was missing.

I did rpm -Uvh openssh*.rpm to uninstall the rudiments, then a complete upgrade from CD, reboot, then i had to manually delete the /etc/ssh/sshd_config and then do

expand-template
and signal event

as described. Thanx again folks - you helped a lot.

[wittenborg]

Reinhold's solution of re-installing ssh updates together works well, for this problem(within 30 second problem solved) . Maybe someone should tell the person who made the update system script. Seems a bit silly to have a workaround for workaround to updates!

www.wittenborg-university.com