Strange SSH behaviour after updating to Cygwin 2.0.1

Strange SSH behaviour after updating to Cygwin 2.0.1

[Achim Gratz]

I'm seeing strange behaviour from SSH after updating both sides to Cygwin
2.0.1.  The symptoms, logging in via a 32bit client into a 32bit or 64bit
sshd instance on the server:

(1005)~ > ssh gratz@server -- tcsh -l
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
term: Undefined variable.
ls -al /dev/tty
crw-rw-rw- 1 gratz Domain Users 5, 0 May  7 08:55 /dev/tty
echo test > /dev/tty
/dev/tty: No such device or address.

The kicker is: if I log in via bash everything works and I can then "exec
tcsh -l" just fine.  While the error seems to be on the server side, it is
actually client dependent; if I log in using the 64bit ssh client into
either sshd on the server, then everything works as expected.

I seem to remember that this has been mentioned before on this list, but I
can't find it.  The part of the strace corresponding to the last command:

echo test >/dev/tty
21556542 405621428 [main] tcsh 6052
fhandler_base_overlapped::wait_overlapped: wfres 0, wores 1, bytes 20
   89 405621517 [main] tcsh 6052 fhandler_base_overlapped::wait_overlapped:
normal read, 20 bytes ispipe() 1
   40 405621557 [main] tcsh 6052 fhandler_base::read: returning 20, binary mode
   35 405621592 [main] tcsh 6052 read: 20 = read(16, 0x28B84F, 20)
   40 405621632 [main] tcsh 6052 fhandler_pipe::lseek: (0, 1)
   33 405621665 [main] tcsh 6052 __set_errno: virtual off_t
fhandler_pipe::lseek(off_t, int):150 setting errno 29
   34 405621699 [main] tcsh 6052 lseek64: -1 = lseek(16, 0, 1), errno 29
  859 405622558 [main] tcsh 6052 alarm: 0 = alarm(0)
  387 405622945 [main] tcsh 6052 close: close(0)
   40 405622985 [main] tcsh 6052 __set_errno:
cygheap_fdget::cygheap_fdget(int, bool, bool):680 setting errno 9
   39 405623024 [main] tcsh 6052 close: -1 = close(0), errno 9
   39 405623063 [main] tcsh 6052 dtable::dup3: dup3 (19, 0, 0x0)
   52 405623115 [main] tcsh 6052 fhandler_base::dup: in fhandler_base dup
   46 405623161 [main] tcsh 6052 fhandler_pipe::dup: res 0
   42 405623203 [main] tcsh 6052 fhandler_base::set_close_on_exec: set
close_on_exec for  to 0
   36 405623239 [main] tcsh 6052 dtable::dup_worker: duped '' old 0xF0, new
0x234
   39 405623278 [main] tcsh 6052 dtable::dup3: newfh->io_handle 0x234,
oldfh->io_handle 0xF0, new win32_name 0x612D8674, old win32_name 0x612D6C88
   41 405623319 [main] tcsh 6052 dtable::dup3: 0 = dup3(19, 0, 0x0)
   38 405623357 [main] tcsh 6052 dup: 0 = dup(19)
   39 405623396 [main] tcsh 6052 fcntl64: fcntl(0, 2, ...)
   43 405623439 [main] tcsh 6052 fhandler_base::set_close_on_exec: set
close_on_exec for  to 0
   37 405623476 [main] tcsh 6052 fcntl64: 0 = fcntl(0, 2, 0x0)
  670 405624146 [main] tcsh 6052 dtable::dup3: dup3 (17, 1, 0x800)
   43 405624189 [main] tcsh 6052 fhandler_base::dup: in fhandler_base dup
   40 405624229 [main] tcsh 6052 fhandler_pipe::dup: res 0
   43 405624272 [main] tcsh 6052 fhandler_base::set_close_on_exec: set
close_on_exec for  to 0
   42 405624314 [main] tcsh 6052 dtable::dup_worker: duped '' old 0xE0, new
0x2E4
   41 405624355 [main] tcsh 6052 dtable::dup3: newfh->io_handle 0x2E4,
oldfh->io_handle 0xE0, new win32_name 0x612D6ED0, old win32_name 0x612D6828
   35 405624390 [main] tcsh 6052 dtable::dup3: 1 = dup3(17, 1, 0x0)
   33 405624423 [main] tcsh 6052 dup2: 1 = dup2(17, 1)
   32 405624455 [main] tcsh 6052 dtable::dup3: dup3 (18, 2, 0x800)
   42 405624497 [main] tcsh 6052 fhandler_base::dup: in fhandler_base dup
   38 405624535 [main] tcsh 6052 fhandler_pipe::dup: res 0
   40 405624575 [main] tcsh 6052 fhandler_base::set_close_on_exec: set
close_on_exec for  to 0
   30 405624605 [main] tcsh 6052 dtable::dup_worker: duped '' old 0xE8, new
0x344
   31 405624636 [main] tcsh 6052 dtable::dup3: newfh->io_handle 0x344,
oldfh->io_handle 0xE8, new win32_name 0x612D8660, old win32_name 0x612D6A58
   31 405624667 [main] tcsh 6052 dtable::dup3: 2 = dup3(18, 2, 0x0)
   35 405624702 [main] tcsh 6052 dup2: 2 = dup2(18, 2)
   34 405624736 [main] tcsh 6052 open: open(/dev/tty, 0x601)
   32 405624768 [main] tcsh 6052 normalize_posix_path: src /dev/tty
   31 405624799 [main] tcsh 6052 normalize_posix_path: /dev/tty =
normalize_posix_path (/dev/tty)
   32 405624831 [main] tcsh 6052 mount_info::conv_to_win32_path:
conv_to_win32_path (/dev/tty)
   39 405624870 [main] tcsh 6052 mount_info::conv_to_win32_path: src_path
/dev/tty, dst /dev/tty, flags 0x2, rc 0
   81 405624951 [main] tcsh 6052 build_fh_pc: fh 0x612D77E8, dev 00050000
  108 405625059 [main] tcsh 6052 __set_errno: virtual int
fhandler_nodevice::open(int, mode_t):21 setting errno 6
   72 405625131 [main] tcsh 6052 open: -1 = open(/dev/tty, 0x8601), errno 6
   43 405625174 [main] tcsh 6052 write: write(18, 0x470580, 37)
   45 405625219 [main] tcsh 6052 fhandler_base_overlapped::wait_overlapped:
wfres 0, wores 1, bytes 37
   32 405625251 [main] tcsh 6052 fhandler_base_overlapped::wait_overlapped:
normal write, 37 bytes ispipe() 1
   30 405625281 [main] tcsh 6052 write: 37 = write(18, 0x470580, 37)
   33 405625314 [main] tcsh 6052 fhandler_pipe::lseek: (0, 2)
   31 405625345 [main] tcsh 6052 __set_errno: virtual off_t
fhandler_pipe::lseek(off_t, int):150 setting errno 29
   46 405625391 [main] tcsh 6052 lseek64: -1 = lseek(16, 0, 2), errno 29
  504 405625895 [main] tcsh 6052 close: close(0)


If anybody has ideas what else to try?


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Strange SSH behaviour after updating to Cygwin 2.0.1

[Stephen John Smoogen]

On 7 May 2015 at 01:15, Achim Gratz <Stromeko@nexgo.de> wrote:
> I'm seeing strange behaviour from SSH after updating both sides to Cygwin
> 2.0.1.  The symptoms, logging in via a 32bit client into a 32bit or 64bit
> sshd instance on the server:
>

I have replicated this using Cygwin ssh to a Linux server. However I
also replicated it using Linux -> Linux

[smooge@seiji ~]$ ssh xanadu -- tcsh -l
X11 forwarding request failed on channel 0
Warning: no access to tty (Bad file descriptor).
Thus no job control in this shell.
^CKilled by signal 2.
[smooge@seiji ~]$ uname -a
Linux seiji.int.smoogespace.com 3.10.0-229.1.2.el7.x86_64 #1 SMP Fri
Mar 27 03:04:26 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

So it might be a 'works as it is supposed to now' even if it is not
the same behaviour as before. Doing a bunch of google hunting.. pretty
much all the places it comes up with are "set your shell to tcsh by
default so the tty is setup by login" or "use bash then go into tcsh".

The Cygwin client I duplicated in on was
CYGWIN_NT-6.1 smooge-PC 2.0.0(0.287/5/3) 2015-04-27 15:30 x86_64 Cygwin


-- 
Stephen J Smoogen.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Strange SSH behaviour after updating to Cygwin 2.0.1

[Achim Gratz]

Stephen John Smoogen writes:
> I have replicated this using Cygwin ssh to a Linux server. However I
> also replicated it using Linux -> Linux

That I already knew, and it's indeed fixed by making tcsh your default
shell over on Cygwin.  I can't do that in the case I mentioned since I
still haven't been able to convince our AD administrators to fill the
respective fields.

> So it might be a 'works as it is supposed to now' even if it is not
> the same behaviour as before. Doing a bunch of google hunting.. pretty
> much all the places it comes up with are "set your shell to tcsh by
> default so the tty is setup by login" or "use bash then go into tcsh".

The interesting part is why it seems to depend on the client while
accessing the same server, all on the same version of Cygwin (login
isn't involved anyway).  Cygwin clearly has the /dev/tty file present,
but for some reason it's not accessible in any way when that happens.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Strange SSH behaviour after updating to Cygwin 2.0.1

[Takashi Yano]

On Thu, 14 May 2015 09:23:34 +0200
Achim Gratz wrote:

> That I already knew, and it's indeed fixed by making tcsh your default
> shell over on Cygwin.  I can't do that in the case I mentioned since I
> still haven't been able to convince our AD administrators to fill the
> respective fields.

Try: ssh -t user@hostname -- tcsh -l

With option -t, it should work as you expected.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Strange SSH behaviour after updating to Cygwin 2.0.1

[Achim Gratz]

Takashi Yano writes:
> Try: ssh -t user@hostname -- tcsh -l
>
> With option -t, it should work as you expected.

Yes it does, thank you very much!  One more problem crossed off the
list.

Meanwhile after another update I actually had that happen when
connecting from the 64bit client also, btw.  So the original question of
why the behaviour was different between a 32bit and 64bit client was
probably due to the phases of the moon or something like that anyway.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple