This morning I apt-get upgraded my Ubuntu 8.04 server box, and got some of the recent ssh fixes that have gone in since the last apt-get upgrade I ran on May 13. I believe I also installed a couple of recommended packages I saw listed for openssh (I had to do the install manually; openssh was in the held back list in apt-get).

I've been able to log into the 8.04 server from my laptop (running gutsy) for months. Now I can't log into the box from my laptop, but am able to log in fine from my old server (Debian Etch). When I try logging in from the laptop, the following appears in /var/log/auth.log:

May 24 13:57:14 mercury sshd[13227]: Disabling protocol version 1. Could not load host key
May 24 13:57:14 mercury sshd[13227]: refused connect from ::ffff:192.168.200.250 (::ffff:192.168.200.250)
May 24 13:57:25 mercury sshd[13229]: Disabling protocol version 1. Could not load host key
May 24 13:57:25 mercury sshd[13229]: refused connect from ::ffff:192.168.200.250 (::ffff:192.168.200.250)

On the laptop:

junk@lapdog:~$ ssh -vvv mercury
OpenSSH_4.6p1 Debian-5ubuntu0.5, 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 mercury [192.168.200.222] port 22.
debug1: Connection established.
debug1: identity file /home/junk/.ssh/identity type -1
debug1: identity file /home/junk/.ssh/id_rsa type -1
debug1: identity file /home/junk/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host



Things I've tried:

1) I've grepped all the files in /etc/ssh for 200.250; it's not in any of the files there.

2) The old server has address 192.168.200.200, so the problem is host-specific, but not the entire 192.168.200.0/24 subnet.

3) I created a test user account on the laptop and a corresponding user on the server. Didn't help. So it's not user keys, or user known hosts, or anything user-specific as far as I can tell.

4) The laptop can ssh fine to the Debian Etch box, and also to an apt-get upgraded feisty server.

5) The laptop is updated with the recent ssh fixes for gutsy. It can ssh fine to the Debian Etch box.

6) I can log in from the Debian box with both keys and passwords.

Any thoughts?

m00t

Is it possible the upgraded server now requires protocol 2? (And on the laptop client side you're forcing ssh to use protocol 1?)

I don't think so, but I'd love to be wrong. I tried an ssh_config on the client with all the active lines commented out and got the same results. Here's ssh_config on the client, which is plain vanilla untouched by human hands:

# 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 some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS 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 ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

I'm pretty sure this is not the issue (based on what you have shared), but have you checked /etc/hosts.allow & /etc/hosts.deny to be sure you're not being blocked by tcp wrappers?

The only reason I ask this is sshd generates a message that looks quite a lot like what you posted when a client connection is blocked at the tcp wrapper level.

Yep, it was in hosts.deny. Apparently I boofed the password once too often and my denyhosts process locked me out.

Doh.

m00t