I'm giving a nephew his first linux computer, and I want to be able to connect to it remotely reliably if he runs into trouble, given the potential for travel restrictions in the US. I set up an ssh key on this laptop and an account for it on a vps of mine. I installed the ssh key on the vps, and am planning to wrap autossh in a systemd script. So that any time the system is booted, it will try to keep alive the ssh connection back to my VPS. And that ssh connection will use -R 12345:localhost:22 so that from my vps, I can ssh to his laptop through the reverse port forward. This will avoid him having to negotiate port forwarding. And it will be dependent on no 3rd party services that could change over time. As long as he "can get on the internet" by clicking around networkmanager, it should just connect in the background and stay connected. But I don't want that key to be able to do anything else on my VPS. (shell/or socks proxy regular port forwards. I've done similar locked keys before for other purposes, but never for a reverse port forward. So I looked through some documentation, googled a bit, and found: command="echo 'Port forwarding only account.'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,permitopen="localhost:8080",permitopen="127.0.0.1:8080" ssh-rsa AAAA-blahblahblahb I learned that if I follow no-port-forwarding with a permitopen in authorized-keys it creates specific allowed port forwards and all others will be denied. That sounds like what I want. But it was for regular/forward/-L port forwarding. What I need is a version of permitopen for reverse/-R port forwarding. I tried permitbind and permitlisten, and those were both nonexistant. I searched for a manpage for authorized_keys and didn't find out, but I did find a post on this very mailing list years ago asking for one. I ran sshd through gnu strings and looked for strings adjacent to permitopen that I might try, and nada. How can I accomplish this? (let an ssh key open specific remote port forwards but no local ports forwards, and no non-listed remotes) I'd rather not run a seperate vm/public ip just for this, or a seperate sshd instance in a selinux-limited chroot jail or something crazy like that. I'd really like to solve the key/account lockdown in the authkeys file, or sshd config _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
