1

Something has happened with the SSH process on a remote server so that now when trying to connect it rants:

kex_exchange_identification: read: Connection reset by peer

It looks like the SSH daemon just needs to be restarted.

But the problem is that there is no access to the server other than via SSH. The only option is abrupt reboot which is undesirable.

However, the remote server's filesystem is mounted locally via sshfs and that continues to work fine.

Is there any way to use the existing sshfs session to run commands on the remote?

Related:

Greendrake
  • 355
  • 1
    What remote user does the existing connection use? Is it root? Is the remote /etc/crontab accessible? What interesting is accessible? (/proc? /sys?). – Kamil Maciorowski Jul 28 '23 at 15:58

1 Answers1

1

sshfs is a "filesystem", and can do most of what filesystems do.

Depending on which directories yoursshfs can access, you could:

  • write a script to restart sshd (use full paths, /bin/ls rather than ls),
  • store it on the server (through sshfs)
  • hand-knit a batch, at, or crontab queue entry for the remote system to invoke the script.
  • put your job into the queue directory.
  • Wait.

Is your userid on the remote server sudo enabled? Study the workings of at, batch, and cron on a working Linux, before subverting them on the remote server.

OTOH, the increasing undesirability of being unable to access via SSH may eventually exceed the undesirability of a reboot.

Use this time to redesign your process.

Just before I make a Russian Roulette change to a remote system, I enqueue an at job that restores the old, but working, configuration to run at "now + 15 minutes". Then, I have 15 minutes to pull the trigger, "find out", reconnect/ login, and cancel the at job. If I don't/can't, the old config is restored in 15 minutes.

Of course, this requires understanding of the remote system, and the changes being made (apt-get changelog packagename), and writing the undo script. It also helps to narrow the focus of "undo" - many application updates don't risk connectivity/access, and (probably) won't need to be undone.

waltinator
  • 4,865