similar to: ssh-keyscan: xmalloc out of memory error

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

In the past 2 months another change occurred in the CVS code that broke my ssh-keyscan patch. Here's an updated version that tweaks the changed name (in the Kex struct) and also causes an attempt to grab an ssh2 key from an older server (without ssh2 support) to fail earlier and without an error message (Stuart Pearlman emailed me some code for this). This patch is based on the BSD CVS

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:

Hi, I am behind a firewall which does not permit connections to port 22, so I run my ssh server on port 23. :-) Unfortunately, the stupid firewall prints a few lines of junk when you make a connection to port 23 before actually starting the connection. This confuses ssh. Attached is an (ugly) patch against openssh-1.2pre15 which makes it ignore a configurable number of lines while looking for

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

I'm in the midst of coding a patch set for consideration that will bump the protocol version and have a couple of observations. The current minimum backwards-compatible protocol is 15 but we have code that checks for protocol versions as old as 12. If someone else doesn't beat me to it i'm considering cleaning out the pre-15 compatibility code. A backwards compatibility patch could

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

Hey all, I installed OpenSSH on a redhat 6.0 box using the 1.2.2 i386 rpms, and I can't connect to it from other machines. I edited the sshd_config file and changed the ListenAddress from 0.0.0.0 to the machine's IP number. The error I have been getting at first confused me, so I checked out the code, and found the function in the sshconnect.c file. The strange thing is that sometimes

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

http://bugzilla.mindrot.org/show_bug.cgi?id=809 Summary: ssh-keyscan breaks too obscurely when remote isn't an SSH server Product: Portable OpenSSH Version: 3.8p1 Platform: All URL: http://bugs.debian.org/228828 OS/Version: Linux Status: NEW Severity: normal Priority: P2

Hi * I'm using rsync to mirror software from one Sun Workstation (mecc27) to the other (mecc29). (solaris 5.7) worked perfect... 'til 1 week ago !! Everybody claims nothing has been changed in the configs of the machines (couldn't find anything, though), but rsync is doing nothing at all. just after being called it exits without any error message, warning, whatever.. here the log

https://bugzilla.mindrot.org/show_bug.cgi?id=2195 Bug ID: 2195 Summary: ssh-copy-id hangs when using shared connection Product: Portable OpenSSH Version: 6.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-copy-id Assignee:

I am working on a proxy which can be hosted on a single IP address and dispatch requests to different backends depending on which hostname the client used to connect to this IP address. Currently such a proxy can be build to support HTTP, HTTPS, SMTP, and DNS. However SSH support is impossible due to the ssh client not sending the information such a proxy would need. I am not the first to want

Hello, On doing "$ rsync --progress --archive --partial -vvv rsync://carroll.cac.psu.edu/redhat-ftp/redhat/linux/7.3/en/iso/i386/valhalla -i386-disc1.iso ", I got the following output <--------------------------------------------------------------------------- ------> local_version=24 remote_version=26 receiving file list ... recv_file_name(valhalla-i386-disc1.iso) received 1

FYI, We've been using the 2.4.7pre1 release for several days now, with nary a hang problem. We haven't seen the EOF bug at all, which was what we upgraded for. This is with transfers of as much as 50GB to set up an initial mirror. The only thing we did was set timeout=0 -- which I guess is unnecessary. The semantics of this flag are a bit unclear. We thought was 'time since

Hi! I am doing backups from a number of machines to an rsync server. For some time I was trying to come up with a solution, which would prevent users from peeking at each other's files, which are backed up. Finally, I've hacked rsync, introducing a new option "write only" for rsyncd.conf. When set to true, this option forbids the transfers from server to the client, thus solving

Hello, I'd like to inform you that the next release of WinSCP SFTP client (version 5.7.5) will support Diffie-Hellman group exchange as specified by RFC 4419. http://winscp.net/tracker/show_bug.cgi?id=1345 So I'd like to ask you to kindly update the check in compat_datafellows() to WinSCP_release_4* WinSCP_release_5.0* WinSCP_release_5.1* WinSCP_release_5.2* WinSCP_release_5.5*

The problem is caused because rsync does not close its sockets, and WinSock is a quite strict on this. The solution is to shutdown and close the fd. This is a 5-minute hack I've done to fix the obvious occurrences of the problem. It might be better to extend rsyncs cleanup functions for this, but here it is anyway to alert people to the problem and its fix. Max. BEGIN PATCH diff -mru

Author of the message didn't include rsync@lists.samba.org in the reply, and I think this message is in topic. -------- Original Message -------- Subject: Re: rsync windows -> unix still hanging :( Date: Mon, 30 Dec 2002 17:24:47 -0800 From: Jim Kleckner <jek_subs@kleckner.net> To: Mike Rubel <mrubel@galcit.caltech.edu> CC: cygwin@cygwin.com References:

dear rsyncists, rsync is superb! but did i actually find a bug? i did: $ rsync -vRHSPa rsync://rsync.mirror.ac.uk/updates.redhat.com/7.3/en/os/SRPMS . into an empty local directory the result was 140 bogus hardlinks of the same file: -rw-rw-r-- 140 g g 6147582 2002/12/04 16:55:24 Canna-3.5b2-62.7.3.src.rpm -rw-rw-r-- 140 g g 6147582 2002/12/04 16:55:24