0

It worked last night, and I haven't rebooted the server since then (it was copying a few hundred GB from one USB hard drive to another, otherwise doing nothing), but now I can only do this:

aaron@aaron-VirtualDesktop:~$ ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_seq=1 ttl=63 time=1.57 ms
64 bytes from 192.168.0.100: icmp_seq=2 ttl=63 time=2.60 ms
64 bytes from 192.168.0.100: icmp_seq=3 ttl=63 time=2.14 ms
64 bytes from 192.168.0.100: icmp_seq=4 ttl=63 time=2.56 ms
64 bytes from 192.168.0.100: icmp_seq=5 ttl=63 time=7.41 ms
^C
--- 192.168.0.100 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 1.575/3.258/7.412/2.109 ms
aaron@aaron-VirtualDesktop:~$ ssh [email protected] -vvv
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.100" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.100 [192.168.0.100] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/aaron/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
ssh_exchange_identification: read: Connection reset by peer
aaron@aaron-VirtualDesktop:~$

The only existing question I could find with the same error messages is this, which was dropped without much discussion and with no answers: https://serverfault.com/q/799207

I really don't want to just pull the plug and reboot, so is there a way to fix this using the current session?

Improve this question
9
  • Looks like the key files are missing! Rebooting won't fix this. You need to restore those key files. Check to make sure that the .ssh directory does indeed exist. Commented Jun 13, 2017 at 19:11
  • They weren't there before, and it worked just fine. Or at least I didn't see them when I was changing the system image behind that IP address, which required me to manually delete the security key so I could reconnect to a new image. Two independent systems do this: the Ubuntu one as shown here, and a Windows port of OpenSSH. All I ever saw in /home/aaron/.ssh/ was known_hosts, which had the key in it. Commented Jun 13, 2017 at 19:19
  • 4
    @AfroJoe That's the client not having those key files, so not able to do pubkey authentication with them. Shouldn't cause this failure. Commented Jun 13, 2017 at 19:27
  • "The current session": Are you still logged into the server somewhere or not? If not, do you have any way to get a console (monitor & keyboard) on the server? Commented Jun 13, 2017 at 19:28
  • @derobert I can get a keyboard, but no monitor. I guess I can try to shut it down blind with the keyboard and see if it comes back up correctly. It's done copying now and not doing anything else. Commented Jun 13, 2017 at 19:31

1 Answer 1

Reset to default
0

Thanks @derobert for helping me out with this.

Turns out that in my case, the system drive became corrupted somehow, so it couldn't find the files it needed to log me in again. I diff'ed the drives that it was copying, and it appears that the copy went okay, I'm guessing because all of the instructions required to do that were already in memory when the drive started going south.

But it looks like the solution here is to re-image the system from a known-good backup onto a different drive. (This is why you make backups.)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.