[Solved] SSH tunneling

qinohe · 2019-01-23 15:59:47

Hi all, have this strange issue with SSH. I have a server running Ampache music-server+MPD & a second MPD for playing local music, it has just grown this way. Everything is working fine I can play both streams from all devices.
The clients(3) have a SSH tunnel setup, running and 2 are working trough this one-liner

ssh -M -S socket-mpd -fNT -L 6001:localhost:6001 -L 8000:localhost:8000 -L 8001:localhost:8001 mark@10.10.100.6

and than shutdown with this one

ssh -S socket-mpd -O exit 10.10.100.6

My workstation=Arch, however, doesn't like this method and I always first need to setup the connection directly.
This is inconvinient because I'm not able to close the SSH connection to the server if I want to leave ncmpcpp and moc open.
The command used is fairly default and working:

ssh -L 6601:localhost:6601 -L 8000:localhost:8000 -L 8001:localhost:8001 mark@10.10.100.6

Using the first one-liner, opening ncmpcpp just mumbles 'connection refused'

Might be I am overlooking something but for now I have no clue, do you?
Thanks, mark

Last edited by qinohe (2019-01-29 16:39:03)

Starclimber · 2019-01-27 16:01:55

I'm not sure if what you have above is a typo, but the port numbers used in your two commands differ.

Assuming that was a typo, do your other clients also use ncmpcpp? Are all the client configurations for SSH the same?

Last edited by Starclimber (2019-01-27 16:04:40)

qinohe · 2019-01-28 00:18:59

As far as I can tell the ports are the same

Yes I can reach ncmpcpp from every client but only the master controls it so all other clients only get 8000 & 8001
Port 6000 is already taken by ampache which I can control with my desktop browser and phone.
The clients are setup with a password-less key, all the same the config.

Starclimber · 2019-01-29 04:30:27

Sorry, I might just be confused by your setup. To clarify, I'm referring to the ports 6001 and 6601 you wrote in your original post.

I quickly made a mock setup of what you have with mpd, ssh, and ncmpcpp with a virtual machine (both host and guest are Arch Linux) and had no problems using a socket or direct connection. If I had to guess, you have something misconfigured somewhere (might be mpd, ssh, ncmpcpp, routing, firewall, etc.). To narrow down what it could be you'll need to do some debugging (i.e. verbose SSH output, monitor mpd logs / change log level, etc.)

qinohe · 2019-01-29 15:16:16

Hi Starclimber, Thanks so much for trying this setup, now at least I know it should work. Yes, that port is a typo it's not in my alias(es).

I definitely think there's something wrong in the config 'somewhere', it's not ncmpcpp or mpd or the routing, I'm sure because I am able to get a connection, though, it's not the way I like it but it will connect and play.
There's something wrong with the way I set it up, my host being the 'control master' and using a back grounded socket connection at the same time. Works on all other machines only not on the one a wish to control everything with.
The server I'm connecting to has far more connections(SSH) to other hosts, nagios mpd and the terminal based one(s), without a glitch...

I will further investigate the verbose outputs and post back here if I can't fix it or if I discover the culprit of course, thanks so far.

seth · 2019-01-29 15:31:20

Does "mpc -p 6001 status" mumble something different?
Also what about "ssh -M -S socket-mpd -N -L …"? Does ssh mumble stuff when you attempt to *mpc*?

qinohe · 2019-01-29 16:34:26

Hi seth, thanks for joining and help solving my problem, you did But why? why did I need to remove 'fT' backgrounding and disable pseudo-terminal allocation.
On other hosts this clearly works, baffled... Anyway thanks, very much appreciated.
Of course, Strarclimber thanks for helping, you did.

edit: on my other hosts I need 'ssh -M -S socket-mpd -fNT -L', won't work without '-fT', just tested it..

Last edited by qinohe (2019-01-29 19:04:58)

seth · 2019-01-29 20:53:52

Just a fluke. I wanted to get the stuff out of the equation and at the same time try to get some output from ssh.
I assume the critical bit is "-T", you can try whether just forking works and if so
a) check the port states w/ and w/o a PTTY (nmap)
b) check the behavior of the mpc client (instead of ncmpcpp) - which however would be inconclusive on likewise failure. You could also try to close the stdin of the ncmpcpp process ("0<&-", though i've no idea how it will react, but you probably won't be able to interact w/ the curses interface. It's just to figure why the connection fails)

The ptty behavior is largely driven by the server, so it's a bit weird that it differs depending on the clients (thus we should seek to figure whether it's because of the clients ssh or ncmpcpp version)

qinohe · 2019-01-30 01:32:03

Oh man I feel like a%$H%$e right now, after running nmap on the various hosts that run this setup I didn't notice any difference, accept for the correct ports being open for me.
Than on the troubled host I thought this can't be happening, I open the connection with an alias (the -fNT one) which works. Then to test I use a command which I scroll up in my terminal....@Starclimber was already on to something, that one contained the 6001 and not the 6601, oh man.
But still @seth later on I tried again and discovered only '-fN' will actually work on all hosts I can lose the ptty but not the forking, only 'N' will hang in the terminal, the connection may be usable haven't checked. Thanks again @Starclimber & @seth

Arch Linux

#1 2019-01-23 15:59:47

[Solved] SSH tunneling

#2 2019-01-27 16:01:55

Re: [Solved] SSH tunneling

#3 2019-01-28 00:18:59

Re: [Solved] SSH tunneling

#4 2019-01-29 04:30:27

Re: [Solved] SSH tunneling

#5 2019-01-29 15:16:16

Re: [Solved] SSH tunneling

#6 2019-01-29 15:31:20

Re: [Solved] SSH tunneling

#7 2019-01-29 16:34:26

Re: [Solved] SSH tunneling

#8 2019-01-29 20:53:52

Re: [Solved] SSH tunneling

#9 2019-01-30 01:32:03

Re: [Solved] SSH tunneling

Board footer