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

Discussion in 'ISPConfig 3 Priority Support' started by webguyz, Apr 6, 2019.

  1. webguyz

    webguyz Active Member HowtoForge Supporter

    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
     
  2. webguyz

    webguyz Active Member HowtoForge Supporter

    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.
     
  3. webguyz

    webguyz Active Member HowtoForge Supporter

    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
     
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
    MaxT likes this.
  5. webguyz

    webguyz Active Member HowtoForge Supporter

    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
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Compare the /etc/ssh/sshd_config files between the systems, maybe you can find a difference there.
     
  7. webguyz

    webguyz Active Member HowtoForge Supporter

    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
     
  8. webguyz

    webguyz Active Member HowtoForge Supporter

    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?
     
    Last edited: Apr 8, 2019
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    Did you try to reinstall openssh-server?

    apt-get install --reinstall openssh-server
     
  10. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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?
     
  11. webguyz

    webguyz Active Member HowtoForge Supporter

    Tried with same results.
     
  12. webguyz

    webguyz Active Member HowtoForge Supporter

    [email protected]:~# 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.
    [email protected]:~#
     
  13. webguyz

    webguyz Active Member HowtoForge Supporter

    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
     
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    This is a master of a multiserver setup? Then don't forget to move the ispcsrv* and additional root users in mysql to the new server as well.
     
  15. MaxT

    MaxT Member HowtoForge Supporter

    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
    
    
    
     
    Last edited: Apr 8, 2019
  16. MaxT

    MaxT Member HowtoForge Supporter

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

    Taleman Well-Known Member HowtoForge Supporter

    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 likes this.
  18. webguyz

    webguyz Active Member HowtoForge Supporter

    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 ;-)
     
  19. MaxT

    MaxT Member HowtoForge Supporter

    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!
     
  20. webguyz

    webguyz Active Member HowtoForge Supporter

    I did try using auth keys and got the same error
     

Share This Page