search for: ka9q

Hi. When I discovered rsync, it immediately became one of my most indispensable utilities. It's a real godsend on bandwidth-limited links, especially digital cellular. It works remarkably well in the general case, but I think the algorithm could be improved for one very important special case. Many (or even most) of the updated files I transfer with rsync change only by stuff being appending

I just confirmed that data corruption can occasionally occur with rsync 2.5.0 when the -z option is used. My command was the following: rsync -vaz --partial --block-size=65536 --checksum remote:/path/ /localdir The files consisted of a year's worth of email (262MB), broken into one file for each day. At least this doesn't seem to occur silently; I get the message "ERROR: file

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openssh-1.2.1pre20 has been released at: http://violet.ibs.com.au/openssh/files/ This release integrates more of Andre Lucas' portability patch, Ben Taylor's utmpx patch and some cleanups and bugfixes of my own. The auth-passwd failures should be fixed, as should lastlog support on NetBSD. Since Andre Lucas' patch included platform

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 openssh-1.2.1pre20 has been released at: http://violet.ibs.com.au/openssh/files/ This release integrates more of Andre Lucas' portability patch, Ben Taylor's utmpx patch and some cleanups and bugfixes of my own. The auth-passwd failures should be fixed, as should lastlog support on NetBSD. Since Andre Lucas' patch included platform

Scenario: Use the ssh-keygen utility in openssh-1.2pre17 to generate a host key Kill and restart sshd Remove the old host key from ~/.ssh/known_hosts Connect to the host using ssh. I get this: homer.ka9q.ampr.org$ ssh 199.106.106.3 who The authenticity of host '199.106.106.3' can't be established. Key fingerprint is 1024 a0:8d:17:f0:fa:a9:9f:6f:b5:d0:1c:d6:02:92:bd:5e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '199.106.106.3' to the li...

There's one vulnerability that's bugged me for some time. It applies to nearly all crypto software, including ssh. That's the swapping of sensitive info (such as keys and key equivalents) onto hard drives where they could possibly be recovered later. The Linux kernel provides a system call, mlock(), that inhibits swapping of a specified region of virtual memory. It locks it into real

...rent 2.5.3 release under Debian "testing" and the 2.4.19-pre2 Linux kernel. As you can see from the appended build log, I get many compiler warnings. More seriously, when I install and try to use the resulting binaries over ssh, things bomb horribly, e,g: bash-2.05a$ rsync -vaz homer-rr.ka9q.net:wwv_wwvh . receiving file list ... done wwv_wwvh rsync: connection unexpectedly closed (69 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(151) bash-2.05a$ This was with 2.5.3 on both ends. Here's the build log: Script started on Mon Mar 11 19:17:26...

Has any consideration been given to support for external file attributes, at least on file systems that implement them? At the very least I'd find it VERY useful if the FLAC command simply copied any extended file attributes between source and destination files. My application is a program that records and plays raw I/Q sample streams in a software defined radio system. I/Q signal streams

I ran into a nasty gotcha today with scp from openssh-1.2pre17. If you use scp to copy a file between machines when the local and remote file args correspond to the same physical file (e.g., exported by a NFS mount) the file is trashed. E.g., if your home directories on "homer" and "bart" share the same NFS-mounted volume and you do homer$ scp foo bart:foo file

Hi. I saw a new release appear today, and I pulled it down to see if some residual problems in port forwarding from openssh-1.2.3 were fixed. The configure script had trouble finding the openssl package, even though I had it installed in the standard place (/usr/local/ssl). I investigated and found that the failed test compile was caused by two nonfatal compiler warnings that memset and RAND_add

I'm still seeing problems when I use TCP connection forwarding across SSH to surf the web. I see lots of error messages of the form channel 1: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected And I see occasional connection lockups. Both ends are running openssh-2.1.1p1. Phil

I'm using Opus for a networked ham radio communications receiver. Kudos on the whole project; it sounds excellent even at low bit rates and the API was surprisingly simple and easy to use. And god knows the world needs a really good, general purpose, non-proprietary codec. One question, though. Depending on the mode my receiver can generate mono or stereo. Most operating modes are mono, but a

Has anyone heavily exercised the TCP connection forwarding features in openssh? I use this feature quite extensively for secure web surfing. I run a ssh command like this: ssh -c blowfish -L3128:127.0.0.1:3128 squidmachine Then I set up Netscape on my local machine to use 127.0.0.1:3128 as a proxy server. Needless to say, this exercises the TCP connection forwarding feature quite heavily. This

For some time I have routinely websurfed across a forwarded TCP connection using SSH. The other end of the TCP tunnel connects to a Squid proxy cache on the same machine. This usually works. But I see lots of error messages on each end of the form Jun 13 13:22:02 tunnel sshd[32378]: error: channel 0: chan_shutdown_read: shutdown() failed for fd5 [i1 o128]: Transport endpoint is not connected

When I encounter the problem with TCP port forwarding locking up, I'll see this on the client window (if I haven't invoked ssh with -q): chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected chan_shutdown_read failed for #1/fd6: Transport endpoint is not connected This is with Blowfish encryption. I have to kill and restart the client when this happens. Phil

Hi. To compartmentalize things a bit (e.g., to help limit the damage should one of my machines be hacked and my private RSA keys stolen) I use different RSA key pairs on my different client machines. So it occurs to me that it would be nice if ssh could log which key was used when logging in to a particular account that has more than one entry in .ssh/authorized_keys. Right now it simply says