Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Meta
Q&A
Posts Tags Edits
Ask Question

Post History

50%
+0 −0
Q&A Nerf an SSH login outside expected IP range

authorized_keys You can make restrictions, but it's clunky and not well-standardized. A command stanza on an authorized key works like the ForceCommand on SSHD Config. It runs the one specified co...

posted 7mo ago by Michael‭  ·  edited 7mo ago by Michael‭

Answer
#4: Post edited by user avatar Michael‭ · 2024-05-08T21:20:49Z (7 months ago)
Sample code
  • ## *authorized_keys*
  • You can make restrictions, but it's clunky and not well-standardized. A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND`, to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose whether to execute it, to execute something else, or to just quit. There doesn't seem to be a standard for performing this validation.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • ## *sudoers* doesn't work
  • In the specific case of `sudo`, one might notice that there are IP and host restrictions mentioned in the documentation for the *sudoers* file. Those restrictions **do not help here.** They are for the IP or resolved name of the computer you SSH into, not the place you SSH from. Those restrictions help administrators make a single *sudoers* policy and push it to a whole network of computers.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
  • ## *authorized_keys*
  • You can make restrictions, but it's clunky and not well-standardized. A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND`, to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose whether to execute it, to execute something else, or to just quit. There doesn't seem to be a standard for performing this validation.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • ```none
  • from="1.2.3.4/26" ssh-rsa AAAAB3N9Q== Normal IP for you@example
  • from="!1.2.3.4/26",command="sshdo" ssh-rsa AAAAB3N9Q== Weird IP for you@example
  • ```
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • ## *sudoers* doesn't work
  • In the specific case of `sudo`, one might notice that there are IP and host restrictions mentioned in the documentation for the *sudoers* file. Those restrictions **do not help here.** They are for the IP or resolved name of the computer you SSH into, not the place you SSH from. Those restrictions help administrators make a single *sudoers* policy and push it to a whole network of computers.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
#3: Post edited by user avatar Michael‭ · 2024-05-08T21:13:28Z (7 months ago)
Internally consistent Markdown formatting
  • ## `authorized_keys`
  • You can make restrictions, but it's clunky and not well-standardized. A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND`, to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose whether to execute it, to execute something else, or to just quit. There doesn't seem to be a standard for performing this validation.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • ## `sudoers` doesn't work
  • In the specific case of `sudo`, one might notice that there are IP and host restrictions mentioned in the documentation for the `sudoers` file. Those restrictions _do not help here._ They are for the IP or resolved name of the computer you SSH into, not the place you SSH from. Those restrictions help administrators make a single `sudoers` policy and push it to a whole network of computers.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
  • ## *authorized_keys*
  • You can make restrictions, but it's clunky and not well-standardized. A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND`, to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose whether to execute it, to execute something else, or to just quit. There doesn't seem to be a standard for performing this validation.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • ## *sudoers* doesn't work
  • In the specific case of `sudo`, one might notice that there are IP and host restrictions mentioned in the documentation for the *sudoers* file. Those restrictions **do not help here.** They are for the IP or resolved name of the computer you SSH into, not the place you SSH from. Those restrictions help administrators make a single *sudoers* policy and push it to a whole network of computers.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
#2: Post edited by user avatar Michael‭ · 2024-05-08T21:11:08Z (7 months ago)
Note that sudoers IP restrictions are not what you're looking for
  • **Yes.** A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND` to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose to execute it, execute something else, or just quit. There doesn't seem to be a standard practice for these.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
  • ## `authorized_keys`
  • You can make restrictions, but it's clunky and not well-standardized. A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND`, to the user's requested command.
  • If the `ForceCommand` is a script, it can validate the original command and choose whether to execute it, to execute something else, or to just quit. There doesn't seem to be a standard for performing this validation.
  • - Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)
  • - Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).
  • **Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.
  • ## `sudoers` doesn't work
  • In the specific case of `sudo`, one might notice that there are IP and host restrictions mentioned in the documentation for the `sudoers` file. Those restrictions _do not help here._ They are for the IP or resolved name of the computer you SSH into, not the place you SSH from. Those restrictions help administrators make a single `sudoers` policy and push it to a whole network of computers.
  • [forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
  • [case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
  • [case-bad]: https://security.stackexchange.com/a/118694/56961
  • [only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
  • [sshdo]: https://raf.org/sshdo/manual/sshdo.8.html
#1: Initial revision by user avatar Michael‭ · 2024-04-30T14:59:53Z (7 months ago) 
**Yes.** A `command` stanza on an authorized key works like the [`ForceCommand` on SSHD Config][forcecommand]. It runs the one specified command _instead of_ your requested command or interactive session and then closes the connection. Obviously this is pretty restrictive, and no one would want to make one key per allowlisted command. But SSH sets an environment variable, `$SSH_ORIGINAL_COMMAND` to the user's requested command.

If the `ForceCommand` is a script, it can validate the original command and choose to execute it, execute something else, or just quit. There doesn't seem to be a standard practice for these.

- Some people roll [their own `case` statement][case] with a list of allowed commands. (Some people accidentally [do it wrong][case-bad].)

- Other people have written longer scripts to manage the allowlists ([`only`][only], [`sshdo`][sshdo]).

**Care should be taken not to allow the user to escalate their own privileges** or learn things to formulate a subsequent attack. If they can edit their _authorized_keys_ to remove the hobbling, they can do _anything else,_ right after.


[forcecommand]: https://man.openbsd.org/OpenBSD-current/man5/sshd_config.5#ForceCommand
[case]: https://web.archive.org/web/20101102234241/https://binblog.info/2008/10/20/openssh-going-flexible-with-forced-commands/
[case-bad]: https://security.stackexchange.com/a/118694/56961
[only]:https://at.magma-soft.at/sw/blog/posts/The_Only_Way_For_SSH_Forced_Commands/
[sshdo]: https://raf.org/sshdo/manual/sshdo.8.html