Re: Alternatives for port forwarding
- From: phil-news-nospam@xxxxxxxx
- Date: 6 Feb 2008 05:49:18 GMT
On 05 Feb 2008 23:02:17 -0600 Todd H. <comphelp@xxxxxxxxx> 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@xxxxxxxx |
|------------------------------------/-------------------------------------|
.
- References:
- Alternatives for port forwarding
- From: phil-news-nospam
- Re: Alternatives for port forwarding
- From: Todd H.
- Alternatives for port forwarding
- Prev by Date: Re: Alternatives for port forwarding
- Next by Date: Re: SSH failover
- Previous by thread: Re: Alternatives for port forwarding
- Index(es):
Relevant Pages
|
|
