SSH : server unexpectedly closed network connection
 

Hi

I am using Ubuntu 18.04 and I started getting server unexpectedly closed network connection error while trying to connect using Putty.

As this is hosted bare metal server I am not able to check further but tried to boot server into rescue mode and checked the files

/etc/ssh/sshd_config
/etc/hosts.deny
/etc/securetty

I have verified these files with my other server along with the permission and it looks same.

I have also checked logs but it doesn't show me any thing.

Can any one suggest what should be done further in this case any help would be good.


Thanks.

Not clear on what you're having a problem with; you mention putty, and Ubuntu 18.04 on a hosted server...are you connecting via VPN or directly over Internet? Is the SSH server on the Ubuntu system, or are you SSH'ing FROM that box to somewhere else? Has this ever worked, or is this a new installation? And have you checked the contents of those files, versus just the permissions? What user are you using to log in, and have you tried others??

Not sure about how to do it with putty, but a typical Linux ssh client will let you run in verbose mode by using it as "ssh -vvv user@address". Putty appears to have some options, but I don't use it so I can't verify:
https://www.ssh.com/ssh/putty/putty-.../Chapter3.html

There appears to be an event log. May want to check it for any clues. And you say it's a hosted server...has your host allowed SSH to that system?

I am not using vpn I am connecting to server directly and server is having SSH server installed on it. It was working since last 2 months from today I have started facing this issue.

There is no update happen, no change in files happen.

Ok, so a direct connection from your PC running putty to Ubuntu. And it was working previously, so obviously *SOMETHING* has changed somewhere. And the previous questions about checking the SSH connection logs, asking your host about any changes, and what user(s) you're using to log in as remain.

Can you post the ENTIRE error message you receive when trying to connect, and the answers to the questions asked? The SSH connection logs too, in CODE tags please.

systemctl status sshd.service will show whats wrong

Again, wrong. It will show the status of the SSH service and unless it's NOT running, you'll see nothing more than the service status. Errors are logged via the journal, and you may see a portion of an error with that command, but probably not enough to diagnose a problem. Again, networking is complicated, which you don't seem to realize; there can be a LOT of different things that cause connectivity problems, including permissions on the user identity files.

very wrong decision, do not do things of this guy, he is Photoshop user here)) systemctl status shows exactly same as journalctl))) as i told he has fake Guru :)

Yes, there are many possible things going wrong. Starting with the low-hanging fruit, the SSH daemon's logs should be checked for a single session. One way to quckly grab a set of logs related to a single SSH session is to fire up a one-off instance of the SSH daemon and connect to that instead:

The -ddd will put it into the most verbose debugging mode. The -E will save that debugging information to the designated file. The -p overrides the default port and listens on another. Everything else remains the same, including the configuration file and its keys and other settings.

So to connect to that, you'd connect to port 2222 and stay with it untill you get the disconnection. That way, when the session ends, the daemon quits and the log file closes and will contain only the one session, and it alone, from start to end.

Wrong yet again; as I said clearly before, it shows *SOME* (as in, 3-5 lines) of journalctl. Not all...and if there are no errors in the sshd startup, it will show *ABSOLUTELY NOTHING* that would give anyone a clue why a remote connection won't start. In short, it's next to useless to run what you suggested, aside from just check to see if ssh is started.

You have been giving really bad advice here and in other threads.

reported

@TB0ne: I'm sure a statement like "systemctl status sshd.service will show whats wrong" is overly simplifying things, but it's not wrong per se, and I'm a little unsure about your subsequent elaborations - that command will show information about a running sshd process.

Reported, as pars pro toto.
Frankly, I'm not even sure if "Photoshop user" is an insult, or what it even means, but I'm sure marliyev meant it like that and they display plenty of report-worthy behaviour.

@marliev: If you want to persevere in this dispute you should lay off the personal insults. Use your brain.

its second time u r commenting me, am asking again, who r u and what do you want? :)

Getting back to the OP...
I’ve most often seen that kind of error in putty when there were problems on the Windows box or with the connectivity at the local ISP.
Has either of those things changed? Do you have connectivity problems with any other remote server?
Putty’s help is excellent. You can log the connection from there.

Please stop bickering, personal attacks will not be tolerated.

I agree with TB0ne. By default all you get are the basic AUTH status messages as written to the log files which does not include any verbose debug messages. You can change the loglevel to add debug messages in the sshd_config file which requires a restart.

Manually running the sshd daemon from the command line as posted above will also add the debug messages.

Indeed, and I noted that in one of my replies. It also shows a few lines of the journal, but typically not enough to do any sort of diagnostics past blatant config file errors..which lead to service not starting. There's just not enough info from a status command to do anything but say SSH is running or not.
Given marliev's behavior in this and other threads, it is likely they'll continue on, but like you, I always hope they will turn into a valuable contributor.