On 14/04/07, Maxim Veksler <[EMAIL PROTECTED]> wrote:
I assume you are aware of the way you run commands on the server with ssh.
Example for those who don't:
[EMAIL PROTECTED]:/$ ssh localhost "echo ssh-server-side: \$SSH_CLIENT"
ssh-server-side: 127.0.0.1 45116 22
[EMAIL PROTECTED]:/$ CLIENT_SIDE_VAR='This is simple bash interpretation'
[EMAIL PROTECTED]:/$ ssh localhost "echo $CLIENT_SIDE_VAR"
This is simple bash interpretation
[EMAIL PROTECTED]:/$ echo "STDIN redirection example" | ssh localhost "cat"
STDIN redirection example
You can also combine them all into one ssh invocation:
[EMAIL PROTECTED]:/$ echo "STDIN redirection example" | ssh localhost
"echo ssh-server-side: \$SSH_CLIENT; echo $CLIENT_SIDE_VAR; cat"
ssh-server-side: 127.0.0.1 45116 22
This is simple bash interpretation
STDIN redirection example
Thanks for trying to help but this is a bad example, security wise and in
practical terms:
1. I want an automatic process (/etc/ppp/ip-up.d/script) to be able to
connect over ssh to a remote site, that process won't have access to the
passphrase so I need to provide it with an identity which isn't protected by
one.
2. Since the identity used is not cryptographically protected, it is very
dangerous to allow it to do just anything on the remote machine.
SSH provides a good way to overcome this:
1. Create a new specialized identiy without a passphrase:
$ ssh-keygen -b 2048 -C test -f ~/.ssh/test
2. Copy it over to the remote machine and add options to its line in
authorized_keys (ssh-copy-id makes this copying easy, but it leaves the key
unlimited until you edit the .ssh/authorized_keys file). Here is an example
from the remote .ssh/authorized_keys:
from="10.0.0.*",command="date",no-port-forwarding,no-X11-forwarding,no-pty
ssh-rsa AAAA.... (key here)
Now whenever I execute "ssh -i /home/amos/.ssh/test [EMAIL PROTECTED]"
I'll get the output of date and the connection will be closed:
$ ssh -i /home/amos/.ssh/test [EMAIL PROTECTED]
Sat Apr 14 15:46:59 EST 2007
Connection to 10.0.0.5 closed.
Any other command passed to ssh is simply ignored (though I notice a slight
difference in the output when this is attempted - it looks like newlines are
translated to "CRLF", maybe it's a bug with sshd?):
$ ssh -i /home/amos/.ssh/test [EMAIL PROTECTED] cat /etc/passwd
Sat Apr 14 15:53:35 EST 2007
Two more points:
1. The sshd manual (were authorized_keys is documented) says that the "from"
options takes DNS host names, it doesn't mention that IP address work too,
as demonstrated above.
2. In my particular case, I'd create a script which reads the SSH_CLIENT or
SSH_CONNECTION envariables and verifies that they make sense (quad-dot,
from a VPN ip range) before using it. If I go the trivial way and just trust
any input passed from the client and someone manages to break into my home
machine he'll be able to redefine my connection back home from work to
connect to his server of choice (host key can be stolen while he's on my
machine so sshd won't warn me).
That said, I'm not sure that I can trust SSH_CLIENT/SSH_CONNECTION since
they are passed from the client. Maybe a getpeername(2) on stdin/stdout can
be used as a more secure way to obtain the client's IP.
Cheers,
--Amos
