Alright, the workaround was to create a new keypair and have local stuff install the public key as ~/.ssh/authorized_hosts
I now have access to the machine but haven't had the time to do serious troubleshooting (and honestly, I don't want to push it too much for fear of being locked out again). Here's the requested info: hostname:~# ssh -v OpenSSH_4.3p2 Debian-9etch2, OpenSSL 0.9.8c 05 Sep 2006 This is the sshd_config before the dist-upgrade: hostname:~# grep -v ^# /etc/ssh/sshd_config | grep -v ^$ Port 222 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes AllowUsers user1 AllowUsers [EMAIL PROTECTED] KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 600 PermitRootLogin no StrictModes yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no PasswordAuthentication yes X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog no KeepAlive yes Subsystem sftp /usr/lib/openssh/sftp-server UsePAM no This is sshd_config now: Port 222 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin no StrictModes yes AllowUsers alex AllowUsers [EMAIL PROTECTED] RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes One intricacy that I did forget to mention (since I only deal with this server when something goes wrong) is that there is a second OpenSSH daemon running on port 22, listening only for LAN connections. So there theoretically might have been confusion when the upgrade scripts ran, but I don't understand why. One instance uses /etc/init.d/ssh, /etc/ssh/sshd_config, /etc/default/ssh and 22/tcp Second instance uses /etc/init.d/ssh2, /etc/ssh/sshd_config2, /etc/default/ssh2 and 222/tcp Not knowing what went wrong, I'm unable to fix it, but this workaround (new keys) seems to work for now. Thank you for your suggestions. -A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
