similar to: sshd gets stuck: select() in packet_read_seqnr waits indefinitely

http://bugzilla.mindrot.org/show_bug.cgi?id=1363 Summary: sshd gets stuck: select() in packet_read_seqnr waits indefinitely Product: Portable OpenSSH Version: 4.2p1 Platform: All URL: http://marc.info/?t=117394251600035 OS/Version: All Status: NEW Keywords: patch Severity: major

While looking for leaks I came across two old packet APIs which are easy to remove. I'm sending patches for each separately. First, there is the packet_set_connection(int fd_in, int fd_out) function in opacket.c The function relies on a behavior in ssh_packet_set_connection() where, when it is passed a NULL pointer, it will implicitely allocate a struct ssh and return it after then set

Hi, ssh clients shows "closed by UNKNOWN" message when a socket is closed by a remote side while ssh is waiting for user's password: $ ssh user at localhost user at localhost's password: Connection closed by UNKNOWN When the packet_read_seqnr() calls get_remote_ipaddr(), a connection's socket is already closed and there's not been any other call of this function yet

Here is my third attempt at the idletimeout patch. I tried to address the points which Marcus Friedl brought up. It is actually bigger than the previous patches, but not as intrusive. It is big because it moves some stuff from serverloop.c to packet.c. - I moved all the logic to packet.c. This means that I also had to move the actual select() call, which used to be in serverloop.c to packet.c.

I apologize, this patch should have been sent awhile ago. Between a lot of things that needed to be completed at work as a sysadmin for the Research Computing group at Purdue University and retiring from work after 38 years at the end of May (2012), I basically ignored it. This patch is from a clone of my workstation that I just activated at home. The patch was primarily written to fix the

Hi, 1. I think you should apply the attached patch to openssh-2.9p1, otherwise ssh-keyscan on linux boxes with glibc-2.1 will experience enormous timeout delays. 2. Is there a program like ssh-keyscan for the Version2 (dsa and rsa) keys?? regards Peter Breitenlohner <peb at mppmu.mpg.de> -------------- next part -------------- diff -ur openssh-2.9p1.orig/ssh-keyscan.c

Hello! I'm hoping that Gmail won't HTML format this mail so that I'll get flamed :) Anyway, my question relates to ssh_config. The problem I find is that the Host pattern is only applied to the argument given on the command line, as outlined in the man page: "The host is the hostname argument given on the command line (i.e. the name is not converted to a canonicalized host name

On Sat, Jan 7, 2017 at 2:30 PM, Peter Moody <mindrot at hda3.com> wrote: > so I spent a bit of time looking at this and it seems like the only > way to go, at least if I want to keep it in ssh_connect_direct(), is > to use pthreads. further, it seems like getting that accepted is > something of a long shot: Sorry, pthreads is a non-starter. I would have thought that using

Hello, I am testing ssh with occasional network disconnection between server and client during these days. I found ssh sometimes hangs if the disconnection happens after the connection is established but before ssh_exchange_identification completes. The ssh configuration files show that both client and server alive options are set. In /etc/ssh/ssh_config: # Send keepalive messages to the server.

Hi! There are configuration knobs (TCPKeepAlive) to enable/disable the use of TCP keepalives both in the ssh client and server. Unfortunately some UNIX systems default to SO_KEEPALIVE=on and some to =off. This may even be settable on a per host basis (OpenBSD default net.inet.tcp.always_keepalive=1 ???). For the TCPKeepAlive configuration knob I would like to propose changes along the lines

Hi folks, I'm currently trying to connect to version 1.2.16 of the commercial server. The server says it supports protocol version 1.4 and that that is incompatible with protocol version 1.5. Is that actually true? The complete output from "ssh -v xxxxxxx" is: $ ./ssh -v xxxxxxx SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug:

Hello, My usage of ProxyCommand just calls the nc utility with various parameters. That in turn after the initial setup just copies copies the data from the network socket to stdin/stdout. This useless coping can be avoided if ssh has an option to receive the socket from the proxy command. I suppose it can improve network error reporting as ssh would talk directly to the network socket rather

In sshconnect.c there are two global variables for server_version_string client_version_string. These are used just in a few functions and can easily be passed as parameters. Also, there is a strange construct, where their memory is allocated to the global pointers, then copies of these pointers are assigned to the kex structure. The kex_free finally frees them via cleanup of the kex

Being rather aggrevated when testing at the enforced 1 second delay between each connection attempt and the useless 1 second delay done after all connection attempts have failed I wrote a patch to make the number of seconds delayed between each connection attempt configurable. Stephen -------------- next part -------------- diff -u --recursive openssh-2.3.0p1/ChangeLog

Folks, I've noticed poor performance using sftp. If anyone has any advice on how to improve performance, I'd like to hear it. Test simply involved transferring a single 143MB MP3 file using defaults for all the program configs. The opensshd 3.0.2p1 server is used in all tests. Software: openssh suite 3.0.2p1 psftp (putty sftp client) latest dev snapshot pscp (putty scp client) latest

https://bugzilla.mindrot.org/show_bug.cgi?id=2256 Bug ID: 2256 Summary: ssh - Connection closed by UNKNOWN Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Hi, The C backend in llc generates code like: static inline int llvm_fcmp_ord(double X, double Y) { return X == X && Y == Y; } static inline int llvm_fcmp_uno(double X, double Y) { return X != X || Y != Y; } First of all it generates a warning by clang and gcc (with certain flags): x.cbe.c:130: warning: comparing floating point with == or != is unsafe Now, C99 provides a macro for this

https://bugzilla.mindrot.org/show_bug.cgi?id=2257 Bug ID: 2257 Summary: ssh - Connection closed by UNKNOWN Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Hi, I'm a newbie to openssh and was trying to read the source code recently. Could anyone tell me why in sshd the connection_in and connection_out are the same(seems to be integer 3 in my machine). connection_in is used in process_input(readset), and connection_out is used in process_output(writeset); But how does it work if it tries to read and write from the same file descriptor? /Bob

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target