Re: openssh remote upgrade procedure?
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 user2@nnn.nnn.nnn.nnn
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 shutdown@192.168.1.201
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
Reply to: