Question

ssh Server unexpectedly closed network connection

Posted April 24, 2017 25.1k views
Linux Basics DigitalOcean Firewall Ubuntu 16.04 Development

i’m trying to connect to my digital ocean Ubuntu 16.04 server through ssh and sftp using putty and winscp. But i get the error “Server unexpectedly closed network connection”.

I do have access through the digital ocean control panel.

anyone knows what to do in a situation like this?

Add a comment
soerenfrisk
By:
soerenfrisk
Add a comment

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

3 answers
hansen April 24, 2017

Hi @soerenfrisk
Maybe you accidentally activated the firewall or have a too hard configuration of IPS like fail2ban?
If you run this command in the console, what does it tell you?

sudo ufw status numbered
Reply Report
  • soerenfrisk April 24, 2017

    hi @hansen
    i get:
    Status: active
    To Action FROM
    [ 1] 22 LIMIT IN Anywhere
    [ 2] 443 ALLOW IN Anywhere
    [ 3] 80 ALLOW IN Anywhere
    [ 4] 22 (v6) LIMIT IN Anywhere (v6)
    [ 5] 443 (v6) ALLOW IN Anywhere (v6)
    [ 6] 80 (v6) ALLOW IN Anywhere (v6)

    Reply Report
    • hansen April 24, 2017

      @jtittle I cannot remember the UFW commands to list the “LIMIT” of port 22 - can you help :-)

      Reply Report
      • soerenfrisk April 24, 2017

        i just disabled ufw entirely, because i only need to move the files to a new server then i’m shutting it down. But the issue persists.

        Reply Report
      • jtittle1 April 24, 2017

        @soerenfrisk

        I wouldn’t recommend keeping the firewall disabled. Instead, what I would recommend doing is a reset just in case something went wrong.

        First, disable ufw using ufw disable and then do a reset using ufw reset.

        ufw disable

        ufw reset

        From there, I’d setup default policies and then move on to setting up your actual rules.

        ufw default deny incoming \
&& ufw default allow outgoing

        Then:

        ufw allow 22/tcp \
&& ufw allow 80/tcp
&& ufw allow 443/tcp

        Finally, start ufw using ufw enable.

        …

        When you start limiting access via IP, you have to be precise and consistent. That’s one of the many reasons I only connect to my Droplets using a VPN.

        The VPN provides me with a static IP (since my ISP does not). I can then limit access against the VPN IP.

        When you start dealing with dynamic IP’s (i.e. those that often change), which is what most ISP’s use, even on some business accounts (sadly), you may be good for a short while but as soon as that IP changes, you’re going to get locked out.

        Reply Report
        • soerenfrisk April 24, 2017

          hi @jtittle
          thank you very much for your answer, but i have tried just disabling ufw to pin down why i cannot connect to the server remotely. As it is now disabled i still get the error “Server unexpectedly closed network connection”, so i have a hard time seeing how ufw could be the cause of the problem.

          edit:
          I have also tried resetting ufw and allow port 80, 22 and 443. But the issue persists

          Reply Report
          • jtittle1 April 24, 2017

            @soerenfrisk

            Are you able to login to console?

            DigitalOcean CP -> Click on Droplet -> Access -> Launch Console

            …

            Has anything else been configured on this server? Such as Fail2Ban or another IPS?

            Has anything be changed in /etc/ssh/sshd_config by you or another?

            Reply Report
          • soerenfrisk April 24, 2017

            @jtittle i’m replying here because i can’t reply directly to your comment.

            Yes i do have access to the console from digitalocean control panel.

            There is no fail2ban or such configured on the server, and no as far as i can see the sshd_config hasn’t been changed, i am the only one with access to the server and i haven’t changed it for a long time.

            Reply Report
hansen April 24, 2017

@soerenfrisk @jtittle
But if you have access to console and you’re migrating to a new server, can’t you just run the scp commands in the console and then kill off the old server?

Reply Report
  • soerenfrisk April 24, 2017

    @hansen
    That is my last resolve. But it is as much to learn why this is happening so i or others could learn what to do in a situation like this. Not fun having your entire server locked down and no means to do anything about it.

    Reply Report
    • jtittle1 April 24, 2017

      @soerenfrisk

      It’s not normal by any means, especially with the firewall disabled. It’s possible there’s some leftover configuration stuck in iptables, which could be flushed using iptables -F, but that normally isn’t required and resetting ufw generally fixes that.

      Reply Report
    • hansen April 24, 2017

      @soerenfrisk Correct. It would be awesome to find the problem, but since every server is slightly different, it can sometimes be really difficult to troubleshoot.

      I would try this. Login to the console. Then try to login with SSH, so we trigger a failure. Then run the following two command to show the last 20 lines of two log files, where SSH usually logs to.

      tail -20 /var/log/auth.log
tail -20 /var/log/syslog

      Can you see if anything pops out? If yes, then you can take a screenshot and upload to i.e. imgur.com and link it here.

      Reply Report
      • soerenfrisk April 24, 2017

        @hansen
        That helped a lot! There was some errors regarding bad permissions on a private key so i changed the following permissions on:

        ssh_host_ed25519_key
ssh_host_ecdsa_key
ssh_host_dsa_key
ssh_host_rsa_key

        in the /etc/ssh/ folder from 0755 to 400

        and now i can login remotely again!

        why those permissions were changed or why sshd suddenly complained about them is a mystery to me.

        Reply Report
        • hansen April 24, 2017

          @soerenfrisk Awesome! Just a question, when did you last do update of your server? Is it located in SFO?

          Reply Report
          • soerenfrisk April 24, 2017

            oh that must be quite some time ago, it is mostly used for development when i get around to it haha. It is located in AMS3 though.

            It’s just weird because i have had perfectly fine access over the last week. Last i was logged in was yesterday i think.

            Reply Report
          • hansen April 24, 2017

            @soerenfrisk Hmm…okay. Not sure what you’re running on that server, so I don’t know, but I see quite a lot of attacks on all my servers, so I always keep them up-to-date - even the dev servers.

            @jtittle What do you think? It’s working now, but all the keys where changed to chmod 755 instead of the default 400.

            Reply Report
          • soerenfrisk April 24, 2017

            @hansen
            I don’t know if i clarified that i changed it from 0755 to 400 so the permissions is now set to 400

            Reply Report
        • jtittle1 April 24, 2017

          @soerenfrisk

          If we’re talking about /etc/ssh on the server, directory permissions there should be 755 on the directory and 644 on most files.

          The private keys are the only files in that directory that should actually have a chmod of 600.

          If you reduce the permissions down to 400, that’ll definitely cause some issues as 400 only gives read access to the owner (but not the group or other).

          How those would have been changed is beyond me unless it was accident or there was a issue with something executed that caused the change.

          Reply Report
  • jtittle1 April 24, 2017

    @hansen @soerenfrisk

    You should be able to, yes.

    As for not being able to login using SSH, unless something has been modified in your config, I’m not 100% sure why you’d be seeing a random timeout or drop – especially without a firewall in a active state.

    My sessions timeout eventually, but not instantly or near immediately. I just tested this on a clean Droplet and on one which is used for SFTP and storage. The first is a clean sshd_config and the other is only modified for the SFTP setup – neither seem to cause any issues.

    Reply Report
JosepMarxuach June 26, 2018

I had same problem. I did :

cd /etc/ssh
chmod 400 *

What In don’t understand is why those files were with wrong chmod. ???

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help