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?
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
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)
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.
I know it's a hassle compared to SSH, but can you migrate the files from the console to the new server?
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.
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
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?
@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.
@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?
@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.
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.
@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.
@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.
@soerenfrisk Awesome! Just a question, when did you last do update of your server? Is it located in SFO?
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.
@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.
@hansen
I don't know if i clarified that i changed it from 0755 to 400 so the permissions is now set to 400
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.
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.