I tried to use SFTP using sudo to make changes in a file, following instruction:
Adding this line was a fix for me and comment the existing
subsystemline:
/etc/ssh/sshd_config:Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-serversudo systemctl restart sshd
Now, I can't connect to the server at all, not via SFTP or SSH, and want to revert the change to be able to connect via SSH; how can I do this?
Find another way to connect to the server that is not SSH.
If it has a remote management agent running (such as Salt-Minion): Use it to remotely run commands on the server.
If it's a virtual machine: Use the 'remote console' access provided by the VM host to log in as if using a local terminal. (Most competent 'cloud' hosts have this feature; look for "console" or "noVNC" or "Lish", etc.)
If it's a physical server: Connect to its console through the 'remote KVM' feature if it has one.
Physical servers have a management controller (IPMI/iLO/iDRAC/AMT/vPro); dedicated-server hosting companies often provide remote console access under various names (e.g. "KVM Console" in Hetzner Robot).
(Some hosting companies, such as OVH, don't offer remote console for dedicated servers but do offer net-boot into a rescue ISO.)
If it's a physical server without remote console: Walk/drive to it and log in at the console, or find a person who can do that for you.
Look at the system logs to find out why your change failed.
Edit the file to undo your changes, then restart sshd.
mosh foo will run ssh foo mosh-server to set up the UDP port). Salt, on other hand, has two modes – it's possible to use it agentless via SSH but the primary way is to run a "salt-minion" agent service that keeps a ZeroMQ connection back to the master, over which you can push states or adhoc actions (e.g. file.copy or cmd.run) that the service will perform as root, even if all inbound connections are blocked.
sudo systemctl restart sshdshouldn't have terminated your existing connection. Is the connection still alive? Or did you and can you log in directly without SSH?sshd_config(or even with.bashrcor so), do not disconnect until you verify you are able to connect anew. Similarly (it's not your case though) when you play withsudoers, start a backup elevated shell and exit it only after making sure you can still usesudofrom a non-elevated shell.