2

I am setting up the following for some of my users.

  • Machine A, running OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips
  • Machine B, running OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f
  • Both servers are Linux, and I administer the latter.

Users have accounts on both machines and they manually ssh from B to A, e.g. by typing ssh A and do work on A. Their ~/.ssh/config looks like:

Host *
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%

While running other stuff on B, they also (indirectly) run commands like ssh -tt A xxx (where xxx is some complicated stuff) because while doing whatever they are doing on B, it needs to find some things that needs to be found that way. Thanks to control master they are not bothered all the time with password requests (machine A is not under my control and does not accept key-based logins). Note that xxx invoke some code that would not work if I would not use -tt. You may claim that such a code is broken and I might agree, but forcing the tty makes it happy.

Everything works just fine, however the manual connection they opened from B to A becomes littered (and practically not usable) by messages:

process_mux_new_session: tcgetattr: Inappropriate ioctl for device

This seemed related to https://stackoverflow.com/questions/1495776/ and https://bugzilla.mindrot.org/show_bug.cgi?id=1686

Is there any way to silence these messages to make the first connection useful without them needing to open another one?

Community
  • 1
Davide
  • 151
  • 8

2 Answers2

1

Elevating @MarkWagner comment to status of answer.

Based on the patch in the bug you need to add -q to the one of ssh invocations (I'm not sure which.) – May 19 at 19:42

Based on some quick tests, it seems that the manual connection opened from B to A is the one that needs the -q

Davide
  • 151
  • 8
0

I would look for MaxSessions on the server-A

grep MaxSessions /etc/ssh/sshd_config

and on clients ~/.ssh/config ControlPersist timeouts

Host *
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r
ControlPersist 10m

You might also prefer ControlPath ~/tmp/ssh_mux_%h_%p_%r to prevent users overwriting each others' files

Also, the controlpath uses hostname '%h' which might vary on invocation.

Another potential solution could be found tweaking terminal settings

ssh server_A TERM=tn3270 /opt/wierd/complex_command.cobol

Or even running it under screen https://www.youtube.com/watch?v=hB6Y72DK8mc https://www.rackaid.com/blog/linux-screen-tutorial-and-how-to/

jmullee
  • 208
  • 1
  • 8
  • How would screen help? Are you suggesting that I change how the `xxx` things are run by using expect within a screen session? – Davide May 20 '17 at 20:54
  • Hard to know how your xxx program interacts with the terminal environment, perhaps screen could provide tty functionality that wouldn't be present in a raw ssh session. – jmullee May 22 '17 at 16:38
  • The raw ssh session works just fine when started with `-t -t` the problems are just the warnings. – Davide May 22 '17 at 21:22