One way to do this is by specifying -o PasswordAuthentication=No as part of your SSH command:
ssh -o PasswordAuthentication=no user@server
This removes PasswordAuthentication from the list of authentication choices that the SSH client has to talk to the server, prevent you from sticking on the Password prompt. Note that this also allows other authentication mechanisms other than PubkeyAuthentication to work (RHostsRSAAuthentication, etc). If you want to use PubkeyAuthentication only...
ssh -o PreferredAuthentications=publickey user@server
When you run ssh with no command, it sets up a pseudo-terminal on the server side and runs an interactive shell in that terminal. When you pass a command, the command is executed with its input and output directly connected to the SSH channel, there is no remote terminal. If you pass the -t option, then a terminal is created on the remote side, and you will get a password prompt where you can type your password.
ssh -t ve "cd clients/ ; git pull"
However, this is not a convenient way to do it. The convenient way is to run an SSH agent on your local machine, and forward that agent's connection.
First, you need to use public key authentication, not password authentication, on the second connection (to the git server). You're already doing this so I won't go into more detail.
Copy the private key for the second server (/home/v3ed2/.ssh/id_rsa on the intermediate machine) to your local machine. Alternatively, on the git server, authorize a public key for which you have the private key on your local machine. Alternatively, first run ssh -t ve ssh-add .ssh/id_rsa to register the intermediate machine's key with your local agent.
Some distributions and desktop environments already set up an SSH agent. Check if you have one running with ssh-add -l. If this tells you you have no agent running, you'll need to start one with your session. Either run ssh-agent your-session-manager instead of calling your-session-manager directly, or run eval $(ssh-agent) in your session startup script, or tick the “run SSH agent” checkbox in your GUI configuration. You need to do two things: start the ssh-agent program, and get the SSH_AUTH_SOCK variable that it sets or prints into your session's environment. The details of how to do this are very specific to your distribution and desktop environment.
Once you have the SSH agent running locally, make sure that it is forwarded. It may or may not be forwarded by default. Run ssh ev ssh-add -l to check whether the agent is forwarded. If it isn't, add the line ForwardAgent yes to your local ~/.ssh/config.
If you're running Windows with PuTTY locally, it comes with a key agent too, Pageant. See the PuTTY manual for instructions.
When you have a working SSH agent setup, register your key(s) with the agent once per session, with the command ssh-add ~/.ssh/id_rsa (or whatever the path to the private key is). After this, you can use the key with no prompting for the remainder of the session.
Best Answer
Had the exact same problem - your question and investigations actually helped me find the answer.
Start celery with
celery_detach- and, poof! Things work!ie.
manage.py celery_detach --params --settings=fooIt returns immediately, with a proper line break, and the things that fabric is looking for.