3 ms·
You were lucky scp uses a binary that typically lives outside /bin - in /usr/lib/openssh/ or some such. Many years ago, I've got to recover a remote server whe
by kees99 2y ago
You were lucky scp uses a binary that typically lives outside /bin - in /usr/lib/openssh/ or some such.
Many years ago, I've got to recover a remote server where /usr was nuked (and /bin, /sbin, and /lib were all symlinks into now-empty /usr). Ended up writing a one-liner perl to convert /bin/busybox-static from my local machine into a series of:
echo -ne "\x7f\x45..." >>~/busybox-static
...and copy-pasting that, chunk-by-chunk, into a single surviving ssh/bash connection, and then used that busybox binary to pull in from a backup.
- deleted 2y ago[deleted]
- hinkley 2y agoI have learned through hard experience that is you ever user sudo to edit the sudoers file, create two shell windows logged in as root before doing so. Use visudo to edit the file of course, because not doing so can blow everything up by rendering the sudoers file unparseable and then everyone is gonna have a bad time. But also the temptation when altering sudo is to immediately log out as super user and try using sudo to do the new command. If you’ve fucked up the file you might not be able to sudo anymore. So now use your second shell window to undo whatever you just did in the first window.
- ryao 2y agoI have setup ssh remote forwards to a jump host in the past to allow remote access through a firewall. daemontools executes scripts exec’ing ssh. ExitOnForwardFailure and ServerAliveInterval are set client side with ClientAliveInterval and ClientAliveCountMax set server side to enable rapid recovery if something goes wrong. Whenever one of the daemon tools scripts doing remote forwards needs to be modified, a second reverse forward script is added and the reverse forward from that is used for ssh, before changing the original script. The second script is removed only after confirming the first still works after the edit. This procedure prevents fatfingering from locking out remote access, since if something goes wrong, you just need to redo the previous step(s) until you get things working. If anyone wants to replicate that, I suggest setting -nNT as arguments to ssh and restricting what the user login can do via sshd_config.
- hinkley 2y agoSSH is probably where I picked up this trick. It’s the same problem. Now you have to find someone with more privs or physical access to fix your fuckup. Meanwhile people are waiting for whatever you were trying to do.