restricting the SOCKS server - SSH

This is a discussion on restricting the SOCKS server - SSH ; I have a somewhat unique request regarding using SOCKS. I'm currently using OpenSSH with SOCKS "-D port" just fine to talk to a Web server that is also running the SSH server. My goal is to use SSH/SOCKS tunneling to ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: restricting the SOCKS server

  1. restricting the SOCKS server

    I have a somewhat unique request regarding using SOCKS. I'm currently
    using OpenSSH with SOCKS "-D port" just fine to talk to a Web server
    that is also running the SSH server. My goal is to use SSH/SOCKS
    tunneling to permit secure access to the website running on this
    server. I'm able to configure my browser to use the proxy when I
    specify a certain URL prefix. I do this using a PAC file that matches
    the prefix and only forwards on a match. This works perfectly as my
    browser session is tunneled via SSH/SOCKS whenever I access this
    website. For other sites, it avoids the SOCKS proxy.

    The problem I have is twofold:

    1. I want to configure the server such that it only permits access to
    the one website. Currently, there's nothing I can do to prevent a
    valid SSH session being used to SOCKS proxy to any Internet
    destination. For example, someone configures SOCKS for all sites by
    not using the PAC file. I only want my users to use the proxy for the
    one website I am providing. I'm open to looking at other SOCKS proxy
    servers besides the one built into OpenSSH. The only restriction, is
    that it must allow restricting of user access via certificates that
    are also used for SSH sessions.

    2. Each user actually needs to go to a slightly different website on
    the same server. For example, user1 goes to site1.website.com, and
    user2 goes to site2.website.com. I can of course partition the
    websites using port numbers also. How can I control SOCKS proxy
    destinations to a specific site or port?

    These 2 solutions would permit user routing to multiple websites on a
    single webserver, while also preventing use of the proxy for general
    Internet websites.


  2. Re: restricting the SOCKS server

    On 2007-02-28, dmulter wrote:
    > I have a somewhat unique request regarding using SOCKS. I'm currently
    > using OpenSSH with SOCKS "-D port" just fine to talk to a Web server
    > that is also running the SSH server. My goal is to use SSH/SOCKS
    > tunneling to permit secure access to the website running on this
    > server.

    [...]
    > the same server. For example, user1 goes to site1.website.com, and
    > user2 goes to site2.website.com. I can of course partition the
    > websites using port numbers also. How can I control SOCKS proxy
    > destinations to a specific site or port?


    Starting in OpenSSH 4.4 there's a PermitOpen directive which controls
    which hosts port forwards, including dynamic port forwards, are permitted
    to talk to. You could implement[1] what you describe above with:

    PermitOpen site1.website.com:80 site2.website.com:80

    If they're on separate IPs you could even restrict by user too with
    the Match directive (but note that this isn't guaranteed to work if
    all the sites are virtually hosted on a single IP).

    Match User user1
    PermitOpen site1.website.com:80
    Match User user2
    PermitOpen site2.website.com:80

    Depending on whether or not the SOCKS client send hostname or IP address
    (SOCKS4 only supports IPs, and is what most browsers use) you may need
    to list the IP address instead of or in addition to the hostname.

    [1] there's a bug in 4.4 and 4.5 that stops the second and subsequent
    PermitOpen specifications on a single line from working but there's a
    patch available, it's fixed in the snapshots and it will be fixed in
    the soon-to-be-released 4.6p1.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread