search for: have_pti

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

I've attached two patches. The first just changes the output of "ssh -V" to print that it was built against rsaref if libRSAglue (which is built as part of openssl only when it is built against rsaref) is present at build-time. The second adds appropriate calls to pam_setcred() in sshd. Without them, our systems can't access AFS because the PAM modules only get tokens at a

I am not 100% positive of the security implications of this, but I really can't see any potential for harm. If this patch is applied (I coded it against the now-current openssh-2.2.0p1), then if (a) the authorized_keys entry has command="whatever" to force a specific command, and also (b) the invoker specified some command on their ssh cmdline, then the invoked command will be

I mentioned this problem in a previous post (in November). This time I'm including a patch. Version: OpenSSH_2.3.0p1 Keywords: setsockopt keepalive hang masquerade interactive Symptom: For protocol 2, socket options (especially keepalive) are not being properly set for OpenSSH_2.3.0p1, even when request in the config files. Furthermore (for either protocol), keepalive is only set for

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>

Hi. I'm writing an article on network backups, and instead of using my old ssh1 software, I decided to go with openssh all the way. I got the hang of the openssh way of doing protocol 2 public key authentication, but ssh is failing to terminate when a pipe is broken. I am ssh-ing to a remote host and doing a cat or zcat of a dump file, then on the localhost, I'm using restore to extract

hi, please test this. if ssh is called with SIGINT ignored (e.g. from a backup system, with rmt) then ssh should not overwrite set it's own handler. Index: clientloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v retrieving revision 1.104 diff -u -r1.104 clientloop.c --- clientloop.c 22 Aug 2002 19:38:42 -0000 1.104 +++

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

comments? allows % ssh host 'tail -f /var/log/messages | grep bla' ^C Index: clientloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v retrieving revision 1.86 diff -u -r1.86 clientloop.c --- clientloop.c 24 Oct 2001 19:57:40 -0000 1.86 +++ clientloop.c 29 Oct 2001 19:08:37 -0000 @@ -103,6 +103,8 @@ */ static

https://bugzilla.mindrot.org/show_bug.cgi?id=1548 Summary: Double free in OpenSSH clientloop.c/xmalloc.c via cmdline port forwarding Product: Portable OpenSSH Version: 5.1p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo:

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|

Here is a patch to implement a handy new feature proposed by John Hardin <johnh at aproposretail.com>. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this

Here is a patch to implement an exit delay in OpenSSH-3.0.2p1, proposed by John Hardin. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this causes the ssh client

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

As you are now probably aware, the portability team for openssh still has not fixed the hang-on-exit bug in the 2.9.9p2 release. Attached is a patch for 2.9.9p2 that fixes the hang-on-exit bug for Linux systems. It also adds a useful exit delay feature that has also not yet been incorporated into the main sources. For more information, see the SNFS (secure NFS) web page:

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.

does somebody like this? Index: Makefile.inc =================================================================== RCS file: /cvs/src/usr.bin/ssh/Makefile.inc,v retrieving revision 1.21 diff -u -r1.21 Makefile.inc --- Makefile.inc 30 Oct 2001 20:32:31 -0000 1.21 +++ Makefile.inc 16 Nov 2001 12:07:22 -0000 @@ -10,7 +10,7 @@ CDIAGFLAGS+= -Wmissing-prototypes CDIAGFLAGS+= -Wunused -#DEBUG=-g

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