search for: have_pty

Hello, I just ran upon this problem and couldn't find it in bugzilla. SSH crashes (abort trap) if all of the following conditions are met: (a) option -f is used (crash happens when going to background), (b) reverse port forwarding is set up (option -R), (c) option ExitOnForwardFailure is enabled, (d) there are no actual port-forwarding failures. The problem can be reproduced by

...hing creds"); + pam_retval = pam_setcred((pam_handle_t *)pamh, PAM_ESTABLISH_CRED); + if (pam_retval != PAM_SUCCESS) + fatal("PAM setcred failed: %.200s", PAM_STRERROR((pam_handle_t *)pamh, pam_retval)); +} #endif /* USE_PAM */ /* @@ -1903,6 +1920,9 @@ packet_set_interactive(have_pty || display != NULL, options.keepalives); +#ifdef USE_PAM + do_pam_setcred(); +#endif if (forced_command != NULL) goto do_forced_command; debug("Forking shell."); @@ -1918,6 +1938,9 @@ packet_set_interactive(have_pty || display != NULL, option...

...*/ @@ -377,8 +379,11 @@ packet_integrity_check(plen, 0, type); } if (forced_command != NULL) { + saved_command = command; command = forced_command; debug("Forced command '%.500s'", forced_command); + } else { + saved_command = NULL; } if (have_pty) do_exec_pty(s, command, pw); @@ -1042,6 +1047,9 @@ env = xmalloc(envsize * sizeof(char *)); env[0] = NULL; + if (saved_command) { + child_set_env(&env, &envsize, "command", saved_command); + } if (!options.use_login) { /* Set basic environment. */ child_set_en...

...onnection is interactive. */ int packet_is_interactive(void); --- sv0/session.c Fri Oct 27 20:19:58 2000 +++ session.c Tue Jan 2 16:40:45 2001 @@ -405,8 +405,7 @@ case SSH_CMSG_EXEC_SHELL: case SSH_CMSG_EXEC_CMD: /* Set interactive/non-interactive mode. */ - packet_set_interactive(have_pty || s->display != NULL, - options.keepalives); + packet_set_interactive(have_pty || s->display != NULL); if (type == SSH_CMSG_EXEC_CMD) { command = packet_get_string(&dlen); --- sv0/ssh.c Fri Oct 27 20:19:58 2000 +++ ssh.c Tue Jan 2 16:42:51 2001 @@ -843,7 +843,7 @@...

Compiled OK, and operating nicely on CentOS 6.6, both 32/64 bit. Really appreciate the UpdateHostkeys feature! One issue I noticed, the screen output gets garbled if the user has been "asked" to "Accept" the new hostkeys. Looks like the screen output is missing the CR's, and only LF's get presented. [root at be2 .ssh]# ssh be1 ls -l Warning: Permanently added

Hi, I noticed that Markus has fixed the temporary file cleanup problems in OpenSSH cvs. What files need patching for this ? I only noticed changes in: session.c, channels.h and channels.c. -Jarno -- Jarno Huuskonen <Jarno.Huuskonen at uku.fi>

...i Apr 20 08:50:51 2001 +++ clientloop.c Sun May 20 22:55:35 2001 @@ -814,7 +814,7 @@ signal(SIGINT, signal_handler); signal(SIGQUIT, signal_handler); signal(SIGTERM, signal_handler); - signal(SIGPIPE, SIG_IGN); + /* signal(SIGPIPE, SIG_IGN); */ if (have_pty) signal(SIGWINCH, window_change_handler); ... and got the correct behavior: [root at nilda test-restore]# ssh meili 'cat nildadump-boot.gz' | \ gunzip -c | restore xf - kernel.h root at meili's password: set owner/mode for '.'? [yn] n Broken pipe I not...

...9;t overwrite SIG_IGN, matches behaviour from rsh(1) + */ + if (signal(SIGINT, SIG_IGN) != SIG_IGN) + signal(SIGINT, signal_handler); + if (signal(SIGQUIT, SIG_IGN) != SIG_IGN) + signal(SIGQUIT, signal_handler); + if (signal(SIGTERM, SIG_IGN) != SIG_IGN) + signal(SIGTERM, signal_handler); if (have_pty) signal(SIGWINCH, window_change_handler);

I am testing with a 5.4p1 client and have noticed, on the server side, that sometimes an SSH_MSG_DISCONNECT message is received with the following 28-byte long payload: 0x00 0x00 0x00 0x0b Reason: SSH_DISCONNECT_BY_APPLICATION 0x00 0x00 0x00 0x14 Description string length: 20 bytes 0x64 0x69 0x73 0x63 0x6f 0x6e 0x6e 0x65

..._fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0; - char buf[100]; + char *signame, buf[100]; debug("Entering interactive session."); @@ -819,6 +844,10 @@ client_init_dispatch(); + /* for protocol v2 we try to send the signal to the remote host */ + if (compat20 && !have_pty && ssh2_chan_id != -1) + send_signal = 1; + /* Set signal handlers to restore non-blocking mode. */ signal(SIGINT, signal_handler); signal(SIGQUIT, signal_handler); @@ -899,6 +928,18 @@ xxx_kex->done = 0; kex_send_kexinit(xxx_kex); need_rekeying = 0; + } + if (...

...set=0xb8234df0) at ../channels.c:1522 #10 0xb7fcce65 in channel_post_open (c=0xb8235240, readset=0xb8233828, writeset= 0xb8234df0) at ../channels.c:1729 #11 0xb7fd0e1b in channel_handler (ftab=0xb7ffd680, readset=0xb8233828, writeset =0xb8234df0) at ../channels.c:1872 #12 0xb7fbb3d8 in client_loop (have_pty=1, escape_char_arg=126, ssh2_chan_id=0) at ../clientloop.c:1430 #13 0xb7fb3dcd in main (ac=0, av=0xbf9f476c) at ../ssh.c:1231 (gdb) -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the...

Hi! I am resending the following message about problems with utmp handling. * In the meantime I had some request in private mail from people asking whether I have new information. * The problem is still persistant in 2.9p2. * My own new investigations show, that the problem only appears with protocol 2, not with protocol 1, I therefore only started to note it when protocol 2 became the

http://bugzilla.mindrot.org/show_bug.cgi?id=1273 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX CC|

...losed: id %d != session_ident %d", id, session_ident); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -776,6 +798,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -840,7 +863,8 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat...

...d", id, session_ident); channel_cancel_cleanup(id); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -785,6 +801,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -848,7 +865,8 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat...

Using OpenSSH_8.3p1 I had an open (working) connection to some other box; after a bit of inactivity, some device in the middle seems to have forgotten about the TCP connection (NAT) and broke it. I've got an EscapeChar defined, though; so first I tried to send a BREAK and, when that didn't help (TCP already gone, packets get lost!), I tried (just out of curiosity) a Rekey. Now I can see

...losed: id %d != session_ident %d", id, session_ident); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -778,6 +799,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -842,7 +864,8 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat...

Hi! as I just noted, after scp the connection does not shut down properly. When I do a "scp file targethost:path", on targethost a "sshd" process is left running. I do use --with-default-path="/usr/local/openssh/bin:/usr/bin:/usr/local/bin" to assure, that the corrensponding openssh-scp is used. It also seems, that normal sessions are not always closed properly.

..._fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0; - char buf[100]; + char *signame, buf[100]; debug("Entering interactive session."); @@ -819,6 +844,10 @@ client_init_dispatch(); + /* for protocol v2 we try to send the signal to the remote host */ + if (compat20 && !have_pty && ssh2_chan_id != -1) + send_signal = 1; + /* Set signal handlers to restore non-blocking mode. */ signal(SIGINT, signal_handler); signal(SIGQUIT, signal_handler); @@ -899,6 +928,18 @@ xxx_kex->done = 0; kex_send_kexinit(xxx_kex); need_rekeying = 0; + } + if (...

In the changelog, there is an entry: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Does this mean that this is regarded as expected (and correct) behavior, that should not change in the future, or does it mean that this behavior is a known problem that someone will eventually fix? --Adam -- Adam McKenna