Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- authorized_keys and command=
- David Magda
June 18, 2004, 8:42 pm
rate this thread
Trying to use the command="" keyword in OpenSSH 3.4p1 (Debian woody)
and having a small issue.
----- /\/\/\/\/\ -----
| A |---< Internet >----| B |
----- \/\/\/\/\/ -----
I can't get to B directly, so I'm creating a tunnel from B to A so I
can log into B.
B:~$ ssh -R 10000:localhost:22 vpn@A
On A, I can now connect to port 10,000 and reach sshd(8) on B.
To increase security a bit I have a special user ("vpn") setup on A
that allows public-key logins, but has a disabled password. To keep
the connection going, I have the vmstat(8) command running (to
minimize issues with connections timing out).
My A:~vpn/.ssh/authorized_keys looks like this:
command="vmstat 3 > /dev/null" ssh-dss AAAAB3Nzaakdghkas ... Vw== user@B
When I kill the login on B (with a ^C), the vmstat is still running
on A. However, if I get rid of the redirection to /dev/null and ^C
the connection then the vmstat dies.
How is the /dev/null redirection changing the behaviour of the shell
(It's not a big deal for me to get rid of it, I just want to
understand what's occuring.)
Thanks for any info.
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca /
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Re: authorized_keys and command=
Hm, I don't see how a command that has its output redirected to
/dev/null helps with "keep the connection going", anymore than (e.g.)
sleep 999999999 or the -N option of ssh (OpenSSH).
The vmstat isn't killed "directly" by the ^C in either case - that just
kills your local ssh process => the connection is closed. When the non-
/dev/null'ed vmstat tries to write to the now closed connection, it gets
SIGPIPE/EPIPE and dies.
- » ssh on command line: force using a group size (prime size) of 1024 (and no...
- — Newest thread in » Secure Shell Forum