In general I could realtime listen audio on the remote computer as:
ssh me@gate rec -t mp3 - | play -
e.g. on the computer named gate I could execute the command rec (or sox) and the audio-stream is transferred over the network, so I could replay it real-time via the play (or sox) command.
This works OK, especially because I have password-less access to the gate from my notebook (using authorized_keys & authorized_keys2).
But my topology is:
+----+ internet +------+ lan +----------+
| my | ----------> | gate | -----> | internal |
+----+ +------+ +----------+
and I need execute the rec in the internal comp and it's stdout should be piped to the play command in the my computer.
So, when I cascading (nesting) the sshs like:
ssh -t me@gate ssh me@internal rec -t mp3 -
(note the -t for ssh)
- so, the
gateis accessed password-less - on the
gateis executed the second (nested)ssh - so the
internalasks me for the password (-t) - and when I enter the password, the
internalcorrectly starts thereccommand - and I could watch the received binary data-garbage on my local terminal.
Unfortunately, this doesn't works when I trying to pipe to the play, e.g. this
ssh -t me@gate ssh me@internal rec -t mp3 - | play -
doesn't works, because the Password: string got redirected (e.g. I not prompted for the password), and the play got confused.
Setting up password-less access between the me@gate -> me@internal probably could solve the problem, but I don't want this - I want manually enter the password to the internal comp.
Any idea how to solve this?