On Sat, Feb 28, 2009 at 8:44 PM, Chris Mirchandani <novashadow@xxxxxxx> wrote:
>
> Response to the response to suggestions 3 & 4. 1) In a way these functions are already
> security holes as anyone with access to the system with the forwards can access these
> ports and based on how they are presented in PS, they are relatively easy to locate.
> The program or option to ssh I suggest would be based on user access. A user could
> only see the details of forwards and tunnels created using his/her own username or a
> username for which he/she has a password. The root user would be able to see them
> all. 2) In most cases, the remote service will be password protected and in a
> unsecured system, this should always be the case.
It comes down to what is controllable by the developers. You can't
hide open sockets
(without kernel modifications), but, you don't need to make it easier
for a cracker.
> Of course this brings up another suggestion, forwards that are per user limited.
Not possible for TCP/IP. All IP sockets are global, unless a kernel
modification does
something different. If you prepend user authentication upon
connection to a TCP/IP
forwarded socket, you break protocols. You will have to modify every
application that
you use to support this authentication step, before going on with the
normal protocol.
The only possibility would be the dynamic port forwarding, because is uses the
SOCKS5 proxy protocol specifically and that protocol supports user
authentication.
Unix Domain sockets can have user/group permissions, as they are implemented in
the filesystem. But you can't telnet or browse (via web browser) to Unix Domain
sockets.
> Response to the response to my question. I would want the STDIN, STDOUT and
> STDERR for the remote command to be the same as if I ran it locally. Would
> changed the STDIN, STDOUT and STDERR of the local call command and not
> the remote command do what I want?
Then you are stuck with the ssh command not returning, until the daemon (or
backgrounded process) ends or closes it's STDIN, STDOUT and STDERR.
For the output to be forwarded to your local machine, the ssh
connection must still
be up. For the ssh connection to stay up, the ssh client must still be running.
The only way that ssh knows that there is no more output to come, is
that the output
channels have been closed.
You can background your local ssh command:
$ ssh joe@xxxxxxxxxxx "sleep 1000" < /dev/null > outfile 2>&1 &
That will background the local ssh command and return your prompt. The ssh
command will still not really exit, until the command on the remote machine
ends.
--
And, did Galoka think the Ulus were too ugly to save?
-Centauri
