openssh 2.2, fbsd 4.2: incoming data hangs sshd on tty

[mouring at etoh.eviladmin.org]

I assumed you put in the contrib/sshd.pam.freebsd file in the correct /etc
location (Under most Linux's it's /etc/pam.d/).

Otherwise you would see that type of errors.


On Tue, 26 Dec 2000 mike at hyperreal.org wrote:

> Well with an out-of-the-box compile I get this upon attempted startup of sshd:
> 
> Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service
> Dec 26 13:20:20 chillout sshd[330]: fatal: PAM session setup failed[6]: Permission denied
> Dec 26 13:20:20 chillout sshd[330]: no modules loaded for `sshd' service
> 
> If I reconfigure with --without-pam, I get this during compilation:
> 
> gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-skey.o auth2-skey.o
> auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o
> auth-rsa.o auth-rh-rsa.o dh.o pty.o log-server.o login.o loginrec.o
> servconf.o serverloop.o md5crypt.o session.o -L. -lssh -lopenbsd-compat -lz
> -lutil -lcrypto 
> auth-passwd.o: In function `auth_password':
> /usr/local/src/openssh/auth-passwd.c(.text+0x5a): undefined reference to `crypt'
> 
> mouring at etoh.eviladmin.org wrote:
> > 
> > Can you verify this against the latest snapshot at:
> > http://bass.directhit.com/openssh_snap/  
> > 
> > 2.2.0 is very old release.  Since we are on the verge (from the sounds of
> > it from Markus) of 2.4.0 release.
> > 
> > - Ben
> > 
> > On Mon, 25 Dec 2000 mike at hyperreal.org wrote:
> > 
> > > I wrote:
> > > > sshd, specifically the forked sshd process that is attached to a terminal
> > > > when a connection is made, tends to freeze when receiving data over the link.
> > > > The only way out is to kill -9 this process. It is easily reproducible by
> > > > pasting text into an editor.
> > > 
> > > With the help of someone who advised me to run ktrace on the sshd process
> > > that freezes, I have narrowed down the circumstances under which the problem
> > > is reproducible, and I discovered that sshd does receive a little bit more
> > > data from the paste than I get to see coming back from the editor.
> > > 
> > > It seems to have to do with whatever the pico (yes, pico, old habits die
> > > hard) editor is doing when it is receiving keystrokes and writing out to the
> > > screen. General screen repaints (ctrl-L) are fine; as are individual
> > > keystrokes. But pasting into the editor causes the ssh freeze-up. As I
> > > mentioned, there is no way to get out of it; killing the editor or the shell
> > > don't work; the processes stick around waiting for sshd to let them go or
> > > something. I have to kill the sshd process.
> > > 
> > > Contrary to earlier test results, I am unable to reproduce the problem
> > > outside of pico. Pasting the same text into an echo "..." command in the
> > > shell multiple times yielded no problems.
> > > 
> > > Tail end of the kdump follows. Note that it does not RET from the write() at
> > > the end:
> > > 
> > >    407 sshd     CALL  select(0x6,0xbfbff39c,0xbfbff31c,0,0)
> > >    407 sshd     RET   select 1
> > >    407 sshd     CALL  read(0x4,0xbfbfb2dc,0x4000)
> > >    407 sshd     GIO   fd 4 read 156 bytes
> > >        "\0\0\0>_\M^X__A_8\M^Wl\M^_<s_0_\^B_H\M^A0_\^W"AU\^\\M^]_\fP-_Cfc_\240_\
> > >         _\M^Am<\^P\M^Y_o__oB\M^U_\^N_Ed\^W_\^O_F0_p\0\0\0
> > >         |__x_\M^]____E__<-]\0\0\0>_____\aM_?_4_1_>_\M^M_4\^C__\M^@w_\M^I_Q\^\_\
> > >         _o\M^H\M^YY_A_{=l,e___\fb{_|\M^F\^T___u\M^_\M^S__?_V"
> > >    407 sshd     RET   read 156/0x9c
> > >    407 sshd     CALL  select(0x6,0xbfbff39c,0xbfbff31c,0,0)
> > >    407 sshd     RET   select 1
> > >    407 sshd     CALL  read(0x5,0xbfbfb2dc,0x4000)
> > >    407 sshd     GIO   fd 5 read 8 bytes
> > >        "\^[[19;64H"
> > >    407 sshd     RET   read 8
> > >    407 sshd     CALL  select(0x6,0xbfbff39c,0xbfbff31c,0,0xbfbff2d4)
> > >    407 sshd     RET   select 1
> > >    407 sshd     CALL  write(0x3,0x8082000,0x6ea)
> > > 
> > > Don't know if this is helpful or not.
> > > 
> > 
> > 
> 
>