OpenSSH Assistance - New Admin

I am a windows admin and was told 2 weeks ago to take over the linux
servers because I had some linux desktop experience and no one else
did.

The first thing I was told was to upgrade our SSH server. Since the
upgrade on friday no one can log into it. Not even as root on
localhost. Here is the -vv

User need to be able to log in with username from the shell and
password or RSA.

Thanks

OpenSSH_4.3p2 Debian-9etch3, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

Here is the config file

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will
bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/
ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
UseLogin yes

#MaxStartups 10:30:60
Banner /etc/issue.net

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
ChallengeResponseAuthentication no

Sealg wrote:
> I am a windows admin and was told 2 weeks ago to take over the linux
> servers because I had some linux desktop experience and no one else
> did.
>
> The first thing I was told was to upgrade our SSH server. Since the
> upgrade on friday no one can log into it. Not even as root on
> localhost. Here is the -vv
>
> User need to be able to log in with username from the shell and
> password or RSA.
>
> Thanks
>
[snip]

first off, I recommend WebMin to help you out.

For this in particular, migh be an issue with the client settings.
They may not be using the security method the server is set to use. So
you may need to change the server configuration to match the clients.

Maxwell wrote:

> Sealg <(E-Mail Removed)> writes:
>
>> The first thing I was told was to upgrade our SSH server. Since the
>> upgrade on friday no one can log into it. Not even as root on
>> localhost. Here is the -vv

> If a user tries to connect to the upgraded service, they should get a
> warning that the certificates have changed.

He or she won't get a warning. The connection will simply break like the
one the OP posted. He might check if he changed the keys in /etc/ssh
during the upgrade. If so, the entries for the server in the
ssh_known_hosts files on the clients have to be deleted prior to a new
login. Because of the security problem with OpenSSL on Debian [1] it
might be risky to restore the old keys from backup.

{1] http://lists.debian.org/debian-secur.../msg00152.html

Günther

Joe Pfeiffer wrote:

> Günther Schwarz <(E-Mail Removed)> writes:
>>
>> He or she won't get a warning. The connection will simply break like
>> the one the OP posted. He might check if he changed the keys in
>> /etc/ssh during the upgrade.

> Yes, you get a warning about a possible man-in-the-middle attack
> because the key changed.

Sorry, I messed that up. You're right. But as the connection is closed
after the warning the user has no chance to correct the error without
verifying the new key settings with the server admin. This is a nasty
situation in a environment where lots of people log in with ssh. Email
is not trustworthy and snail mail is expensive. Recording the MD5 sum
of the new public key on an answering machine might do the trick.

Günther

On Sep 30, 10:39*am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Günther Schwarz <st...@gmx.de> writes:
> > Joe Pfeiffer wrote:
>
> >> Yes, you get a warning about a possible man-in-the-middle attack
> >> because the key changed.
>
> > Sorry, I messed that up. You're right. But as the connection is closed
> > after the warning the user has no chance to correct the error without
> > verifying the new key settings with the server admin. This is a nasty
> > situation in a environment where lots of people log in with ssh. Email
> > is not trustworthy and snail mail is expensive. Recording the MD5 sum
> > of the new public key on an answering machine might do the trick.
>
> This is configurable with the StrictHostKeyChecking setting (and
> actually, I'd forgotten that if it's set to "yes", you'll get the
> behavior you described. *So we were actually both right).

It was the keys. I got it straighted out.

Thanks folks

Joe Pfeiffer wrote:

> Günther Schwarz <(E-Mail Removed)> writes:
>
>> Joe Pfeiffer wrote:
>>
>>> Yes, you get a warning about a possible man-in-the-middle attack
>>> because the key changed.
>>
>> Sorry, I messed that up. You're right. But as the connection is
>> closed after the warning the user has no chance to correct the error
>> without verifying the new key settings with the server admin.
>
> This is configurable with the StrictHostKeyChecking setting (and
> actually, I'd forgotten that if it's set to "yes", you'll get the
> behavior you described. So we were actually both right).

That's fine. I was not aware of this variable. Setting it to "no" might
not be a good step towards security though.

Günther