Alternatives for port forwarding - SSH

This is a discussion on Alternatives for port forwarding - SSH ; I've been thinking about some ideas I'd like to do with port forwarding like what SSH can do. But what I wanted to do is more complex and seems to exceed what SSH can accomplish. Maybe someone has an idea ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Alternatives for port forwarding

  1. Alternatives for port forwarding

    I've been thinking about some ideas I'd like to do with port forwarding
    like what SSH can do. But what I wanted to do is more complex and seems
    to exceed what SSH can accomplish. Maybe someone has an idea how to do
    this with SSH anyway?

    The objective is to make a server node that users can log into through
    a normal SSH client, with multiple logins from two or more different
    computer hosts, and have port forwarding rerouted from one machine to
    any other in the "cluster" of those logged in. I know this can be done
    by a combination of remote and local forwarding through listens active
    on the common server. However, this can be an administrative mess if
    a number of users are involved. For one thing it ties up a resource
    that needs to be carefully allocated but cannot be enforced: ports
    If one user is having host A log in with a remote forward listening on
    port 10000, with the intent of logging in from host B with a local forward
    to reach that port 10000 to make a connection through to host A, it is
    possible some other user could beat them to using port 10000. Host A
    could in theory pick some other port, but how would host B know what it
    is?

    The dream solution is some kind of service that can be used to handle the
    network traffic on forwarded ports without actually having any listening
    being done on the server, or any connections to a port on the server.
    And the ideal would be to keep it all isolated within a group of users
    so that users of another group cannot connect over. I'm not sure how
    the connections would be appropriately identified (e.g. how would host
    B indicate it wants to forward through to host A even though all these
    SSH connections are really to the central server). One thing that is
    essential is that these destination identities need to be separate from
    any other user group, including the other group being able to use the
    same exact identity without any inter-group collision or breach.

    I suspect this may require some big additions to the sshd code to handle
    it. Or maybe it's better to just not use SSH and to develop another SSL
    based protocol. Any ideas?

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-05-2128@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: Alternatives for port forwarding

    phil-news-nospam@ipal.net writes:

    > I've been thinking about some ideas I'd like to do with port forwarding
    > like what SSH can do. But what I wanted to do is more complex and seems
    > to exceed what SSH can accomplish. Maybe someone has an idea how to do
    > this with SSH anyway?
    >
    > The objective is to make a server node that users can log into through
    > a normal SSH client, with multiple logins from two or more different
    > computer hosts, and have port forwarding rerouted from one machine to
    > any other in the "cluster" of those logged in. I know this can be done
    > by a combination of remote and local forwarding through listens active
    > on the common server. However, this can be an administrative mess if
    > a number of users are involved. For one thing it ties up a resource
    > that needs to be carefully allocated but cannot be enforced: ports
    > If one user is having host A log in with a remote forward listening on
    > port 10000, with the intent of logging in from host B with a local forward
    > to reach that port 10000 to make a connection through to host A, it is
    > possible some other user could beat them to using port 10000. Host A
    > could in theory pick some other port, but how would host B know what it
    > is?
    >
    > The dream solution is some kind of service that can be used to handle the
    > network traffic on forwarded ports without actually having any listening
    > being done on the server, or any connections to a port on the server.
    > And the ideal would be to keep it all isolated within a group of users
    > so that users of another group cannot connect over. I'm not sure how
    > the connections would be appropriately identified (e.g. how would host
    > B indicate it wants to forward through to host A even though all these
    > SSH connections are really to the central server). One thing that is
    > essential is that these destination identities need to be separate from
    > any other user group, including the other group being able to use the
    > same exact identity without any inter-group collision or breach.
    >
    > I suspect this may require some big additions to the sshd code to handle
    > it. Or maybe it's better to just not use SSH and to develop another SSL
    > based protocol. Any ideas?


    I think yer onto something at the end. This doesn't sound like a job
    for SSH.

    Can you define your connection needs in terms of a user's identity?
    Are you familiar with VPN capabilities? I suspect that an
    appopriately selected VPN solution would be a much better fit for your
    goals than anything based on SSH.

    Best Regards,
    --
    Todd H.
    http://www.toddh.net/

  3. Re: Alternatives for port forwarding

    On 05 Feb 2008 23:02:17 -0600 Todd H. wrote:

    | I think yer onto something at the end. This doesn't sound like a job
    | for SSH.
    |
    | Can you define your connection needs in terms of a user's identity?
    | Are you familiar with VPN capabilities? I suspect that an
    | appopriately selected VPN solution would be a much better fit for your
    | goals than anything based on SSH.

    Each user would be in a group. A group would have one or more users.
    The distinction of users is so that each can have their own password
    and identity for access control and logging. Everyone within a group
    can make connections to each other.

    I'm not familiar with how (well) SSH handles VPNs. From the docs I see
    it is creating a tunnel device. But that would imply managing routing
    and such with it. Maybe this is the way to go as it would open up many
    things like users having full network capability amongst themselves.
    Casual attempts to use this feature via -w have resulted in nothing
    happening. I don't see any tunnels or messages about having any or it
    not being allowed or failing. Beyond that I am entirely unfamiliar with
    it. But even if it worked in clients, it still seems I'd somehow have
    to get the tunnel data stream into my program rather than creating a
    real tunnel interface on the server end. I did once envision making a
    network where 100's of VPN tunnels would converge on a process on one
    machine. But security was the big issue and I did not pursue it. I
    want to avoid having to making my own security code of ssh can do this.

    Right now, ssh can effectively forward stdin/stdout to a program on the
    remote end, or it can forward ports to connections made to the remote
    end, or tunnel a "tun" interface to one on the other end. What would be
    more useful would be a feature to allow the forwarded ports and tunnels
    to be passed in to the program started on the remote end. That way the
    "tun" interface is created on the client end, but all the packets going
    to and from it are handled by the process started on the server end, or
    over a connection to a process within that server (but that central
    daemon would need a way to authenticate the user by identity to know
    which IP address (range) is allowed).

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-02-05-2331@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread