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 ssh
s like:
ssh -t me@gate ssh me@internal rec -t mp3 -
(note the -t
for ssh
)
- so, the
gate
is accessed password-less - on the
gate
is executed the second (nested)ssh
- so the
internal
asks me for the password (-t
) - and when I enter the password, the
internal
correctly starts therec
command - 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?
-t
doesn't ask for a password... "Disable pseudo-terminal allocation."