On 08/10/2010 0:28, Willie Wong wrote: >> You can't do that on a per-command basis. You'd be trying to control the >> authentication method accepted by sshd on B according to which command >> is run on A -- something sshd on B knows nothing about. >> > > That's partially false. See my response in this thread.
Why? SSH can do a lot of things, but when used in the way we're discussing here it just sets up one or more authenticated and encrypted channels between two endpoints; ignoring the details, each one of these roughly acts as a couple of pipes, mutually connecting stdin/stdout of a pair of processes. When you ssh to a remote host, the remote host's sshd will run a command and attach the newly created process to the remote end of the connection; The name of the command is usually passed by the client, but can be overridden on the server either through the sshd configuration files (globally or per-client) or with a per-key 'command' option. Now, the remote sshd is never sent any information about what is connected to the local end of the pipe (which is not even known to ssh!), so there is no way to alter its behavior depending on that. IOW, nothing in the setup you and I proposed prevents the user from piping an arbitrary command into ssh (or even using a ssh-invoking wrapper such as scp or rsync) and getting successfully authenticated on the server. You are only guaranteed that the server will run tar in place of whatever remote command the client requests, so that the connection will break if the client side sends non-tar data. In my opinion this is quite different from "[allowing] only one single command from a single cronjob to operate passwordless", but then I might just be splitting hairs. andrea
