After dist-upgrade from jessie to stretch I can no longer SSH into the server

I was doing dist-upgrades and on my ISPConfig standalone master server after I did a dist-upgrade everything looked like it was successful but I can no longer log in using SSH via putty, getting "Server unexpectedly closed network connection" after I entered root and put the password in
I have PermitRootLogin yes in SSHD_config and if I do a telnet 75.xxx.xx.xx 22 I get
SSH-2.0-OpenSSSH_7.4p1 Debian-10+deb9u6
So my port is open. nothing in /etc/hosts.deny and I use a hardware firewall rule to limit access to port 22 on that IP. Was working fine before I did the dist-upgrade. I did a apt-get remove ssh openssh-server and then a apt-get install ssh openssh-server. no luck. I restarted sshd and then rebooted that server but no luck. I can use putty to get to my other debian servers with no problem. Tried putty on a different server and got the same results so its something on that server.

Did 5 other server dist-upgrades in the last 2 days and ssh was never an issue after I finished.
Anybody ever run into this or have an idea where to start troubleshooting?

Thanks

 

Well I discovered I can SSH in from other Linux slave boxes, but not login using Putty from 3 different machines. I downloaded the latest version of Putty (0.71) but still no go. I tried using WinSCP and it told me it could not use authenticate using sftp but could use ftp.
This is so weird. Putty works great on all the other Linux boxes but not this one.

 

I installed openssh client on my windows 10 Desktop and when you open powershell and type ssh [email protected]
it connects to my ISPConfig master server with no problem. So that leaves me with an issue on how putty connects to a Linux server on this one machine thats failing. Crazy

 

If my memory serves me correctly Debian GNU/LInux Stretch introduced the measure where root can not SSH log in with password. These root logins have to be done with ssh keys. Other users can login with password, and Debian installation for Stretch and previous version forces creation of an additional user.

 

Hi,
I can log into this server as root from another linux box and even from my desktop windows 10 using openssh client. After more troubleshooting it appears its only with Putty and Winscp that I can not access this one server. I tried another non-root user and I can not log in with putty.
What makes this so weird is that I can use putty and log into any other of my recently upgraded jessie->strech servers with no issues.
I enabled debugging on the master server and I can see the server logging in successfully and accepting the root password but then I see a unhandled event 12 (below) and I think its giving me the error around there.

Code:

Apr  7 12:51:19 dotcp sshd[19020]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: SSH2_MSG_KEXINIT received [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: kex: algorithm: [email protected] [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: kex: host key algorithm: ssh-ed25519 [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [
preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [
preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: rekey after 4294967296 blocks [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: rekey after 4294967296 blocks [preauth]
Apr  7 12:51:19 dotcp sshd[19020]: debug1: KEX done [preauth]
Apr  7 12:51:23 dotcp sshd[19020]: debug1: userauth-request for user root service ssh-connection method none [preauth]
Apr  7 12:51:23 dotcp sshd[19020]: debug1: attempt 0 failures 0 [preauth]
Apr  7 12:51:23 dotcp sshd[19020]: debug1: PAM: initializing for "root"
Apr  7 12:51:23 dotcp sshd[19020]: debug1: PAM: setting PAM_RHOST to "76.187.xxx.xxx"
Apr  7 12:51:23 dotcp sshd[19020]: debug1: PAM: setting PAM_TTY to "ssh"
Apr  7 12:51:28 dotcp sshd[19020]: debug1: userauth-request for user root service ssh-connection method password [preauth]
Apr  7 12:51:28 dotcp sshd[19020]: debug1: attempt 1 failures 0 [preauth]
Apr  7 12:51:28 dotcp sshd[19020]: debug1: PAM: password authentication accepted for root
Apr  7 12:51:28 dotcp sshd[19020]: debug1: do_pam_account: called
Apr  7 12:51:28 dotcp sshd[19020]: Accepted password for root from 76.187.xxx.xxx port 61595 ssh2
Apr  7 12:51:28 dotcp sshd[19020]: debug1: monitor_child_preauth: root has been authenticated by privileged process
Apr  7 12:51:28 dotcp sshd[19020]: debug1: do_cleanup
Apr  7 12:51:28 dotcp sshd[19020]: debug1: PAM: cleanup
Apr  7 12:51:28 dotcp sshd[19020]: debug1: Killing privsep child 19021
Apr  7 12:51:28 dotcp sshd[19020]: debug1: audit_event: unhandled event 12
Apr  7 12:51:37 dotcp sshd[18852]: debug1: server_input_channel_req: channel 0 request window-change reply 0

 

Copied the entire sshd-config from a working slave over the master and restarted service but the same results.
Will try creating a key with puttygen and see if that will works.
Thx

 

Created a private key with puttygen and tried logging in that way instead of manually logging in but same error.

Should I create a new Stretch vm and install same version of ISPConfig on it as I currently have and then change the IP and copy over a current dbispconfig db?

 

Since this problem started after dist-upgrading jessie to stretch, have you made sure the upgrade has finished without errors?
What shows

Code:

apt-get dist-upgrade

now?

 

Tried with same results.

 

root@ispcfgcp:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@ispcfgcp:~#

 

I've resigned myself to create a new standalone master with Strech and the same exact version of ispconfig (3.1.13) and after completed restore a current dbisoconfig db and change the IP to my current master.
Of course before I move anything verify it works with putty. I use putty and Winscp quite a bit and without being able to use them I feel a little lost.

Any thoughts on anything else I need to move?
Thx

 

Try this config for pass and no keys. Also I had some problems in Stretch, although finally I got access. I did not make modifications in the system, just configure this sshd_config:
(* inside /root/.sshd I have just an empty file "authorized_keys")

Code:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 22
Protocol 2

# your server ip
ListenAddress 1.1.1.1

Compression yes

SyslogFacility AUTH
LogLevel INFO

LoginGraceTime 30
PermitRootLogin yes
StrictModes yes

MaxSessions 2

PasswordAuthentication yes
PermitEmptyPasswords no

ChallengeResponseAuthentication no

UsePAM yes

GatewayPorts no
X11Forwarding no

PrintMotd no
PrintLastLog yes

UseDNS no

AcceptEnv LANG LC_*

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

also, I don't know if your ssh sofware is old but in that case try with adding this at the end:

Code:

KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

 

I can connect without keys. I have 9.8... Maybe in the next version (10)?

 

That means you are using the sshd_config from Jessie. The dist-upgrade asks whether to use maintainers version or keep the old. If you keep the old, you should review the maintainers version to see what changes are supposed to be in the new version.
Stretch definitely has this feature where root by default can not log in with password. It can be changed in the sshd_config, but I would advice against it. What my memory was not sure about, was whether this was the case already in Jessie. Now that I try to confirm this, it looks like this PermitRootLogin without-password default was introduced in Jessie. But still, it is possible the problems stem from not using the maintainers version of sshd_config.
What I do during dist-upgrades of Debian, is to show the differences between current and maintainers version, accept the maintainers version and when upgrade is finished I insert my modifications back if need be. The upgrade process saves the old config file with .dpkg-old suffix.

 

Maxt, thanks for suggestion. Used your config but same results. I have removed openssh-server and re-installed from scratch so have all the latest entries for Stretch in sshd-config.
Pretty much given up and started over and created a replace vm with fresh copy of Stretch and I can connect with now problems so I will probably just install ISPConfig this weekend and move over the dbispconfig db and the users as Till recommended. Since this is a standalone master it should not be too bad (famous last words ;-)

 

ok, I understand, thanks for your explanation. Yes, for sure you are right about using keys.... in everywhere it appears like the best recommendation. Maybe still I keep the password because no problems until today.. Neither I have a situation to favour the use of keys, like travelling or a business with many servers. Then I use a complex long pass of 100 characters+one word from my head.
I think in change to keys+password in the future... Although you can see I'm not an expert and I'm more worried for basic things for the system which still I lack skills

thx!

 

I did try using auth keys and got the same error