Mailing List Archive

Thanks and Suggestions
OK you will likely be able to tell I am a newb when it comes to mailing lists, so please forgive me if I have sent this to the wrong place or have used the wrong format. While i do not know how likely a dev will read this, maybe someone closer can pass this along.

I have been using ssh for a while and recently discovered how ssh is so much more. I have appreciated how programs like scp, sftp and rsync use ssh for authentication and security and then I have played a little with ssh-fs. However, now I have discovered things like local and reverse forwarding, dynamic socks forwarding, tunneling, etc. and all I can say is WOW! So all can say is things to the devs and all of you that have helped make ssh all that it is. It's feature rich, stable and secure. I do have a couple of suggestions and some questions.

Suggestions

1) Add an option for Reverse dynamic forwards.

2) Add more options for the GatewayPorts settings in the sshd_config file. Currently, no, clientspecified and yes are the only options. I think there should be a yes option, that allows the client to specify localhost only. This would allow the client to force localhost only even when the gatewayport settings is to a version of yes that would normally allow on all addresses.

2a) Maybe this should be 2 options to cover if the client requests multiple bind addresses and the gatewayports option is ones of these new versions of yes. It would only open localhost if the client specified just localhost or localhost + multiple other bind addresses. The other would open up only localhost if the client specified only localhost, but open all addresses if the client specified local host + multiple other bind addresses. If the client did not specify localhost, all addresses would be open with either option.

2b) I would like to see a 2nd clientspecified option. One that only opens all addresses if the client specifically requests it. I am not sure if the ssh client currently specifies all or 0.0.0.0 if I do not specify a bind address or if it just leaves that field blank. If it's blank, this is easy, if the new clientspecified option is set and the bind address field is empty, it only opens the forward to localhost. If the bind address feild cannot be blank, I am not sure what can be done to maintain compatibility unless the ssh client is already using a bind address term not used by end users, meaning not all or 0.0.0.0.

2c) It would also be nice if in the GatewayPorts, I could set specific bind addresses.

2d) There should be an equivalent of these options for the client side to ignore or cancel the forward if the bind ports are not what it wants. e.g. The client could specify all ports and if the server forces this to localhost, the end user could set an option to cancel the forward in that case. If the end user sets multiple binds, he/she could specify absolutes, so that if all the ones marked absolute are not allowed, the forward is canceled. Also, the client should be able to set an if more than these addresses are allowed option so that if more than the requested addresses are allowed, the forward is canceled. Both options should be able to be used at the same time and the latter should only have to be used on one of the forward options for it to apply to all of them.

3) Maybe this already exits, so maybe this is not a request. Would like an easy to use command that lets us see all the forwards and tunnels on a computer. I should be able to limit to one or multiple types, local, remote, dynamic, remote dynamic (if my request is added), tunnels initiated locally and tunnels initiated remotely. Should be options for all forwards only, all tunnels only everything and if you could use the inclusive options and exclude ones you do not want in the list. It would be great if I could set a specific log just for this and so that ever time thius changes it updates that log with the change or all the connections with the changes highlighted. e.g. added in front of each that was added and removed for those that were closed. No, gSTM (http://sourceforge.net/projects/gstm/) is not an alternative for what I am suggesting.

4) Command that can show all ssh connections, remote and local.

Question

Is there a way to send a command via ssh that stays open even if the the ssh session that created it closes? I have this figured out already, I think, but my problem is that my ssh session does not close like it normally does after a command is run and completed. So maybe my real question is, how do I do this and have the ssh session close after the command is run? e.g. If I run the following command, I get output and the ssh command closes. Of course the command I am running in this example, has an end, but the one I want to use does not.

ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN"

However, if run one of the following commands, the remote command works, but am not returned to the command prompt. I have to kill the ssh connection to be returned to a prompt and the remote command stays running after I kill the initial connection, but this does not help me in a script.

$ ssh -p 4731 root@localhost 'ssh -q -N -D 1873 -p 3731 sshd@localhost &'
$ ssh -p 4731 root@localhost ssh -q -N -f -D 1873 -p 3731 sshd@localhost

Btw, the fact that I am using localhost does not mean that all connections are to the same computer. The ports are forwards. I know I can send the local command to the background, but there is no need to keep it open, i want to to close like it does with ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN".

Thanks,

Chris
_________________________________________________________________
Windows Live™ Hotmail®:…more than just e-mail.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_022009
Re: Thanks and Suggestions [ In reply to ]
I am not an OpenSSH developer...

On Fri, Feb 27, 2009 at 8:03 PM, Chris Mirchandani <novashadow@msn.com> wrote:
> 3) Maybe this already exits, so maybe this is not a request. Would like an easy to use
> command that lets us see all the forwards and tunnels on a computer. I should be
> able to limit to one or multiple types, local, remote, dynamic, remote dynamic (if
> my request is added), tunnels initiated locally and tunnels initiated remotely. Should
> be options for all forwards only, all tunnels only everything and if you could use the
> inclusive options and exclude ones you do not want in the list. It would be great if
> I could set a specific log just for this and so that ever time thius changes it updates
> that log with the change or all the connections with the changes highlighted. e.g.
> added in front of each that was added and removed for those that were closed. No,
> gSTM (http://sourceforge.net/projects/gstm/) is not an alternative for what I am suggesting.

I believe this would be a huge security information leak. And would
advise against
implementation.

> 4) Command that can show all ssh connections, remote and local.

If you need more than what "ps" or "netstat -anp", then I will refer
you to my answer to
suggestion 3.

>
> Question
>
> Is there a way to send a command via ssh that stays open even if the the ssh session
> that created it closes? I have this figured out already, I think, but my problem is that my
> ssh session does not close like it normally does after a command is run and completed.
> So maybe my real question is, how do I do this and have the ssh session close after the
> command is run? e.g. If I run the following command, I get output and the ssh command
> closes. Of course the command I am running in this example, has an end, but the one I
> want to use does not.
>
> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN"
>
> However, if  run one of the following commands, the remote command works, but  am
> not returned to the command prompt. I have to kill the ssh connection to be returned to
> a prompt and the remote command stays running after I kill the initial connection, but
> this does not help me in a script.
>
> $ ssh -p 4731 root@localhost 'ssh -q -N -D 1873 -p 3731 sshd@localhost &'
> $ ssh -p 4731 root@localhost ssh -q -N -f -D 1873 -p 3731 sshd@localhost
>
> Btw, the fact that I am using localhost does not mean that all connections are to the
> same computer. The ports are forwards. I know I can send the local command to the
> background, but there is no need to keep it open, i want to to close like it does with
> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN".

OpenSSH will close its connection, when no-one else has the terminal/pipe open.
This means more than just backgrounding the job. ("&")

You must redirect STDIN, STDOUT and STDERR to somewhere else and background
the job.

$ date
Sat Feb 28 03:18:38 PST 2009
$ ssh joe@example.com "sleep 1000 < /dev/null > /dev/null 2>&1 &"
$ date
Sat Feb 28 03:18:41 PST 2009

So, with that, I redirected STDIN ("< /dev/null") and STDOUT (">
/dev/null") then
made STDERR (2) go to the same place as STDOUT (1) ("2>&1"). Then the whole
command gets backgrounded ("&").

--
And, did Galoka think the Ulus were too ugly to save?
-Centauri
RE: Thanks and Suggestions [ In reply to ]
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.

Of course this brings up another suggestion, forwards that are per user limited.

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?

----------------------------------------
> Date: Sat, 28 Feb 2009 03:28:18 -0800
> Subject: Re: Thanks and Suggestions
> From: robert.lanning@gmail.com
> To: secureshell@securityfocus.com
>
> I am not an OpenSSH developer...
>
> On Fri, Feb 27, 2009 at 8:03 PM, Chris Mirchandani wrote:
>> 3) Maybe this already exits, so maybe this is not a request. Would like an easy to use
>> command that lets us see all the forwards and tunnels on a computer. I should be
>> able to limit to one or multiple types, local, remote, dynamic, remote dynamic (if
>> my request is added), tunnels initiated locally and tunnels initiated remotely. Should
>> be options for all forwards only, all tunnels only everything and if you could use the
>> inclusive options and exclude ones you do not want in the list. It would be great if
>> I could set a specific log just for this and so that ever time thius changes it updates
>> that log with the change or all the connections with the changes highlighted. e.g.
>> added in front of each that was added and removed for those that were closed. No,
>> gSTM (http://sourceforge.net/projects/gstm/) is not an alternative for what I am suggesting.
>
> I believe this would be a huge security information leak. And would
> advise against
> implementation.
>
>> 4) Command that can show all ssh connections, remote and local.
>
> If you need more than what "ps" or "netstat -anp", then I will refer
> you to my answer to
> suggestion 3.
>
>>
>> Question
>>
>> Is there a way to send a command via ssh that stays open even if the the ssh session
>> that created it closes? I have this figured out already, I think, but my problem is that my
>> ssh session does not close like it normally does after a command is run and completed.
>> So maybe my real question is, how do I do this and have the ssh session close after the
>> command is run? e.g. If I run the following command, I get output and the ssh command
>> closes. Of course the command I am running in this example, has an end, but the one I
>> want to use does not.
>>
>> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN"
>>
>> However, if run one of the following commands, the remote command works, but am
>> not returned to the command prompt. I have to kill the ssh connection to be returned to
>> a prompt and the remote command stays running after I kill the initial connection, but
>> this does not help me in a script.
>>
>> $ ssh -p 4731 root@localhost 'ssh -q -N -D 1873 -p 3731 sshd@localhost &'
>> $ ssh -p 4731 root@localhost ssh -q -N -f -D 1873 -p 3731 sshd@localhost
>>
>> Btw, the fact that I am using localhost does not mean that all connections are to the
>> same computer. The ports are forwards. I know I can send the local command to the
>> background, but there is no need to keep it open, i want to to close like it does with
>> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN".
>
> OpenSSH will close its connection, when no-one else has the terminal/pipe open.
> This means more than just backgrounding the job. ("&")
>
> You must redirect STDIN, STDOUT and STDERR to somewhere else and background
> the job.
>
> $ date
> Sat Feb 28 03:18:38 PST 2009
> $ ssh joe@example.com "sleep 1000 < /dev/null> /dev/null 2>&1 &"
> $ date
> Sat Feb 28 03:18:41 PST 2009
>
> So, with that, I redirected STDIN ("< /dev/null") and STDOUT (">
> /dev/null") then
> made STDERR (2) go to the same place as STDOUT (1) ("2>&1"). Then the whole
> command gets backgrounded ("&").
>
> --
> And, did Galoka think the Ulus were too ugly to save?
> -Centauri
_________________________________________________________________
Windows Live™ Contacts: Organize your contact list.
http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009
Re: Thanks and Suggestions [ In reply to ]
On Sat, Feb 28, 2009 at 9:33 AM, Chris Mirchandani <novashadow@msn.com> wrote:
>
> OK you will likely be able to tell I am a newb when it comes to mailing lists, so please forgive me if I have sent this to the wrong place or have used the wrong format. While i do not know how likely a dev will read this, maybe someone closer can pass this along.
>
> I have been using ssh for a while and recently discovered how ssh is so much more. I have appreciated how programs like scp, sftp and rsync use ssh for authentication and security and then I have played a little with ssh-fs. However, now I have discovered things like local and reverse forwarding, dynamic socks forwarding, tunneling, etc. and all I can say is WOW! So all  can say is things to the devs and all of you that have helped make ssh all that it is. It's feature rich, stable and secure. I do have a couple of suggestions and some questions.
>
> Suggestions
>
> 1) Add an option for Reverse dynamic forwards.
>
> 2) Add more options for the GatewayPorts settings in the sshd_config file. Currently, no, clientspecified and yes are the only options. I think there should be a yes option, that allows the client to specify localhost only. This would allow the client to force localhost only even when the gatewayport settings is to a version of yes that would normally allow on all addresses.
>
> 2a) Maybe this should be 2 options to cover if the client requests multiple bind addresses and the gatewayports option is ones of these new versions of yes. It would only open localhost if the client specified just localhost or localhost + multiple other bind addresses. The other would open up only localhost if the client specified only localhost, but open all addresses if the client specified local host + multiple other bind addresses. If the client did not specify localhost, all addresses would be open with either option.
>
> 2b) I would like to see a 2nd clientspecified option. One that only opens all addresses if the client specifically requests it. I am not sure if the ssh client currently specifies all or 0.0.0.0 if I do not specify a bind address or if it just leaves that field blank. If it's blank, this is easy, if the new clientspecified option is set and the bind address field is empty, it only opens the forward to localhost. If the bind address feild cannot be blank, I am not sure what can be done to maintain compatibility unless the ssh client is already using a bind address term not used by end users, meaning not all or 0.0.0.0.
>
> 2c) It would also be nice if in the GatewayPorts, I could set specific bind addresses.
>
> 2d) There should be an equivalent of these options for the client side to ignore or cancel the forward if the bind ports are not what it wants. e.g. The client could specify all ports and if the server forces this to localhost, the end user could set an option to cancel the forward in that case. If the end user sets multiple binds, he/she could specify absolutes, so that if all the ones marked absolute are not allowed, the forward is canceled. Also, the client should be able to set an if more than these addresses are allowed option so that if more than the requested addresses are allowed, the forward is canceled. Both options should be able to be used at the same time and the latter should only have to be used on one of the forward options for it to apply to all of them.
>
> 3) Maybe this already exits, so maybe this is not a request. Would like an easy to use command that lets us see all the forwards and tunnels on a computer. I should be able to limit to one or multiple types, local, remote, dynamic, remote dynamic (if my request is added), tunnels initiated locally and tunnels initiated remotely. Should be options for all forwards only, all tunnels only everything and if you could use the inclusive options and exclude ones you do not want in the list. It would be great if I could set a specific log just for this and so that ever time thius changes it updates that log with the change or all the connections with the changes highlighted. e.g. added in front of each that was added and removed for those that were closed. No, gSTM (http://sourceforge.net/projects/gstm/) is not an alternative for what I am suggesting.
>
> 4) Command that can show all ssh connections, remote and local.
>
> Question
>
> Is there a way to send a command via ssh that stays open even if the the ssh session that created it closes? I have this figured out already, I think, but my problem is that my ssh session does not close like it normally does after a command is run and completed. So maybe my real question is, how do I do this and have the ssh session close after the command is run? e.g. If I run the following command, I get output and the ssh command closes. Of course the command I am running in this example, has an end, but the one I want to use does not.
>
> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN"
>
> However, if  run one of the following commands, the remote command works, but  am not returned to the command prompt. I have to kill the ssh connection to be returned to a prompt and the remote command stays running after I kill the initial connection, but this does not help me in a script.
>
> $ ssh -p 4731 root@localhost 'ssh -q -N -D 1873 -p 3731 sshd@localhost &'
> $ ssh -p 4731 root@localhost ssh -q -N -f -D 1873 -p 3731 sshd@localhost
>
> Btw, the fact that I am using localhost does not mean that all connections are to the same computer. The ports are forwards. I know I can send the local command to the background, but there is no need to keep it open, i want to to close like it does with ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN".

Use the "lsof" on the remote server and you can see that STDIN
,STDOUT, STDERR are being used from the newly started daemon process
on the remote side (in your case sshd). So, your ssh client will not
exit till this daemon is stopped. So, redirect these descriptors to
/dev/null to exit immediately.

Regards,
Bala

>
> Thanks,
>
> Chris
> _________________________________________________________________
> Windows Live™ Hotmail®:…more than just e-mail.
> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_022009
Re: Thanks and Suggestions [ In reply to ]
On Sat, Feb 28, 2009 at 8:44 PM, Chris Mirchandani <novashadow@msn.com> 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@example.com "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
RE: Thanks and Suggestions [ In reply to ]
Thank you Mr. Lanning,

I tried your suggestion, see below, and it does work like I want, but I have 2 questions.

> ssh joe@example.com "sleep 1000 < /dev/null> /dev/null 2>&1 &"

1) I see a lot of scripts use the form /dev/null> /dev/null 2>&1 rather than < /dev/null> /dev/null 2>&1. Why don't you want/need the latter in scripts?

2) If I enable logging for my remote ssh command, which is an ssh command, will < /dev/null> /dev/null 2>&1 change logging in any way?

> Date: Sat, 28 Feb 2009 03:28:18 -0800
> Subject: Re: Thanks and Suggestions
> From: robert.lanning@gmail.com
> To: secureshell@securityfocus.com
>
> I am not an OpenSSH developer...
>
> On Fri, Feb 27, 2009 at 8:03 PM, Chris Mirchandani wrote:
>> 3) Maybe this already exits, so maybe this is not a request. Would like an easy to use
>> command that lets us see all the forwards and tunnels on a computer. I should be
>> able to limit to one or multiple types, local, remote, dynamic, remote dynamic (if
>> my request is added), tunnels initiated locally and tunnels initiated remotely. Should
>> be options for all forwards only, all tunnels only everything and if you could use the
>> inclusive options and exclude ones you do not want in the list. It would be great if
>> I could set a specific log just for this and so that ever time thius changes it updates
>> that log with the change or all the connections with the changes highlighted. e.g.
>> added in front of each that was added and removed for those that were closed. No,
>> gSTM (http://sourceforge.net/projects/gstm/) is not an alternative for what I am suggesting.
>
> I believe this would be a huge security information leak. And would
> advise against
> implementation.
>
>> 4) Command that can show all ssh connections, remote and local.
>
> If you need more than what "ps" or "netstat -anp", then I will refer
> you to my answer to
> suggestion 3.
>
>>
>> Question
>>
>> Is there a way to send a command via ssh that stays open even if the the ssh session
>> that created it closes? I have this figured out already, I think, but my problem is that my
>> ssh session does not close like it normally does after a command is run and completed.
>> So maybe my real question is, how do I do this and have the ssh session close after the
>> command is run? e.g. If I run the following command, I get output and the ssh command
>> closes. Of course the command I am running in this example, has an end, but the one I
>> want to use does not.
>>
>> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN"
>>
>> However, if run one of the following commands, the remote command works, but am
>> not returned to the command prompt. I have to kill the ssh connection to be returned to
>> a prompt and the remote command stays running after I kill the initial connection, but
>> this does not help me in a script.
>>
>> $ ssh -p 4731 root@localhost 'ssh -q -N -D 1873 -p 3731 sshd@localhost &'
>> $ ssh -p 4731 root@localhost ssh -q -N -f -D 1873 -p 3731 sshd@localhost
>>
>> Btw, the fact that I am using localhost does not mean that all connections are to the
>> same computer. The ports are forwards. I know I can send the local command to the
>> background, but there is no need to keep it open, i want to to close like it does with
>> ssh -p 4731 root@localhost netstat -an | egrep "tcp.*:3731.*LISTEN".
>
> OpenSSH will close its connection, when no-one else has the terminal/pipe open.
> This means more than just backgrounding the job. ("&")
>
> You must redirect STDIN, STDOUT and STDERR to somewhere else and background
> the job.
>
> $ date
> Sat Feb 28 03:18:38 PST 2009
> $ ssh joe@example.com "sleep 1000 < /dev/null> /dev/null 2>&1 &"
> $ date
> Sat Feb 28 03:18:41 PST 2009
>
> So, with that, I redirected STDIN ("< /dev/null") and STDOUT (">
> /dev/null") then
> made STDERR (2) go to the same place as STDOUT (1) ("2>&1"). Then the whole
> command gets backgrounded ("&").
>
> --
> And, did Galoka think the Ulus were too ugly to save?
> -Centauri

_________________________________________________________________
Windows Live™ Contacts: Organize your contact list.
http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009
Re: Thanks and Suggestions [ In reply to ]
On Sun, Mar 1, 2009 at 7:09 PM, Chris Mirchandani <novashadow@msn.com> wrote:
>
> Thank you Mr. Lanning,
>
> I tried your suggestion, see below, and it does work like I want, but I have 2 questions.
>
>> ssh joe@example.com "sleep 1000 < /dev/null> /dev/null 2>&1 &"
>
> 1) I see a lot of scripts use the form /dev/null> /dev/null 2>&1 rather than < /dev/null
> > /dev/null 2>&1. Why don't you want/need the latter in scripts?

This actually depends on the command running.

< /dev/null
This redirects STDIN (usually the keyboard) to read from /dev/null.
/dev/null is a special
file (called a device file) that gives the End Of File marker every
time it is read. If you
want the command to read from a file, then you replace "/dev/null"
with /path/to/file.
>/dev/null
This redirects STDOUT (usually the screen) to /dev/null. Anything
written to /dev/null
is just discarded. So, if you want to save the output to a file,
then you replace "/dev/null"
with /path/to/output/file. You do have to be careful, as the ">"
operator truncates the file
when it opens it for writing.
This copies file descriptors.
STDIN is file descriptor 0
STDOUT is file descriptor 1
STDERR is file descriptor 2
So, 2>&1 copies file descriptor 1 to file descriptor 2, thus makes
STDERR goto the same
place as STDOUT.
If you want STDERR to goto a different file than STDOUT, then you can use
"2> /path/to/error/file"

If you don't use "< /dev/null" then the command will still have the
terminal open for reading.
Sometimes this is just fine, as the command does not do anything with
the terminal (ie. read
from it.) Sometimes it isn't, if the command tries to read from
STDIN, it will interrupt your
shell.

If you want to close your shell completely, then you will need to
redirect STDIN for
the command, as the terminal will disappear (if it is a network or
Xwindow session.) In this
case, you will also want to use "nohup" to run the command. This will
set the process flag
to ignore the HangUp (SIGHUP) signal, that the shell sends to all it's
child processes upon
exit. Commands that do not specifically handle SIGHUP will default to
exiting upon
receiving the HUP signal.

In Linux, you can get a list of all available POSIX Signals via the
"kill -l" command or
looking in /usr/include/linux/signal.h.

> 2) If I enable logging for my remote ssh command, which is an ssh command, will
> < /dev/null> /dev/null 2>&1 change logging in any way?

This all depends on how logging is implemented.

If it uses Syslog or writes directly to a file, no. If it logs to
STDOUT or STDERR, then yes.

See above for what happens to STDOUT and STDERR, if logging is done
via either of
those.

If it uses Syslog or writes directly to a file, then the log will be
on the remote machine,
only.

--
And, did Galoka think the Ulus were too ugly to save?
-Centauri
Re: Thanks and Suggestions [ In reply to ]
On Sun, Mar 01, 2009 at 10:09:51PM -0500, Chris Mirchandani wrote:
> 2) If I enable logging for my remote ssh command, which is an ssh command, will < /dev/null> /dev/null 2>&1 change logging in any way?

If you'd like to log the output to a file instead of throwing it away,
then use this instead:

yourcommand </dev/null >yourlogfile 2>&1 &