3

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 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 the rec 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?

2
  • -t doesn't ask for a password... "Disable pseudo-terminal allocation."
    – Attie
    Jan 19, 2018 at 14:20
  • Side note: I think you may have the knowledge to answer this old question. Jan 19, 2018 at 14:28

2 Answers 2

1

I assume internal listens on the standard 22 port.

First build a tunnel:

ssh -N -L localhost:2222:internal:22 me@gate
# you can put it to background with &

Then connect through the tunnel. This connection will end up at internal:

ssh -p 2222 me@localhost rec -t mp3 - | play -

You should be asked for your password to internal despite the pipe being used.


ssh -L … is explained in my answer to another question.

0

I presume that the password prompt doesn't get in the way if your laptop is able to access internal directly?

If so, have a play with the ProxyCommand configuration option.

Put something like this in your ~/.ssh/config

Host internal-via-gate
    User me
    Hostname internal
    Port 22
    ProxyCommand ssh gate nc %h %p

This should allow you to simply run ssh internal-via-gate, as if you were connecting directly.


If not, then maybe consider port forwarding:

Host internal-via-gate
    User me
    Hostname internal
    Port 22
    ProxyCommand ssh gate nc %h %p
    LocalForward 27015 localhost:27015

Then, connect and authenticate (ssh internal-via-gate).

Once you're logged in, run:

  • rec -t mp3 - | nc -l 27015 on the remote, and
  • nc localhost 27015 | play - on the local machine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .