4

Linux box a is connected to a home DSL line with dynamic DNS registration, hosting a tmux session to which multiple clients connect in read-only mode over SSH. All users connect using the same credentials: user b.

Example: ssh b@a.dynip.org tmux attach -t screencast

It all works fine but I have had a user do "naughty" stuff from the box out to the Internet. That's unacceptable as I am responsible for my Internet contract with the ISP; how do I completely jail every user apart from granting the ability to use the account b, over ssh, using tmux to watch session screencast on my a machine?

I am thinking about updating ipchains straight after a user connects over ssh, allowing traffic back to that ip address only but... with multiple viewers sharing the same account?

1 Answers1

1

I don't completely understand your requirements: which machine are the users to be jailed on? Can they do anything that doesn't involve the network? Nonetheless I think I can tell you what the necessary building blocks are.

To restrict a user to specific network connections, see How to restrict internet access for a particular user on the lan using iptables in Linux. In short, to restrict user 1234's network traffic to connecting to 192.0.2.42 (the IP address of machine A) via ssh:

iptables -t mangle -A OUTPUT -o eth0 -m owner --uid-owner 1234 -d 192.0.2.42 --dport 22 -j ACCEPT
iptables -t mangle -A OUTPUT -o eth0 -m owner --uid-owner 1234 -j DROP

Remember to block IPv6 as well if you have it.

On machine A, to restrict the restricted users to the account B, the most effective method is to arrange for these users not to have credentials to other accounts. You can use Match directives in sshd_config to restrict connections from certain IP addresses to authenticating certain users, but this may not be a good thing as it would prevent you from obtaining administrative access.

Match 192.0.2.99
    AllowTCPForwarding No
    AllowUsers B
    PasswordAuthentication No
    X11Forwarding No

To restrict account B to a single command, there are two ways:

  • Give the users a private key (preferably one per user), and set restrictions for this key in the authorized_keys file with a command= directive.

    command="tmux attach-session -r -t screencast" ssh-rsa …
    
  • Set the user's shell to a script that launches tmux with the right arguments. This has the advantage that you can allow password authentication, but may be harder to get right in a way that doesn't allow the user to break out to a shell prompt.

I think tmux that tmux doesn't allow shell escapes in a read-only session, but I'm not sure, check that users can't escape at that point.