From degreane at gmail.com Sat Jun 2 23:29:23 2007 From: degreane at gmail.com (Faysal Banna) Date: Sat, 02 Jun 2007 16:29:23 +0300 Subject: ssh tunnel proxy setup Message-ID: <466170B3.6010109@gmail.com> Hi all.. am trying to incorporate a tunnel from over a slow setup ........ /-------------------------/ /-------------------------------/ | host1 |=========//Tunnel ssh //====================| Host2 | | squid parent | | squid http_port 3128 | | 127.0.0.1:8080 | | acl accept all | \-------------------------\ \-------------------------------\ Host1 configuration : ssh -L 8080:127.0.0.1:3128 -C -N -f client at host2 The tunnel goes through the link and forwards port 8080 to 3128 from host1 to host2 main reason is that the actual link size is 2Mbit/s and i need to pass the data in compression to gain maximum http transparent proxied data transfer from Host2 to Host1. It works fine as long as i don't have heavy load but when i connect Host1 to the local home network i start having some delay after a certain amount of time i believe when the clients establish sessions through squid which redirected to parents over the Tunnel session created . i have separated the logs squid log shows normal connectivity but on the console after ssh established i got this message channel 149: open failed: connect failed: Connection timed out channel 111: open failed: connect failed: Connection timed out channel 176: open failed: connect failed: Connection timed out channel 193: open failed: connect failed: Connection timed out and afterwards the connectivity degrades remarkably .... anyone has got any clue for what this might be.. thanks in advance :) Regards F.B. From degreane at gmail.com Sun Jun 3 07:09:38 2007 From: degreane at gmail.com (Faysal Banna) Date: Sun, 03 Jun 2007 00:09:38 +0300 Subject: Channel setup Message-ID: <4661DC92.7020702@gmail.com> Hi all am setting up a Forward Tunnel from one machine to another machine can anyone Guide me what this might be its degrading performance on a busy server load channel 968: open failed: administratively prohibited: open failed channel 969: open failed: administratively prohibited: open failed channel 973: open failed: administratively prohibited: open failed channel 975: open failed: administratively prohibited: open failed channel 976: open failed: administratively prohibited: open failed channel 977: open failed: administratively prohibited: open failed channel 978: open failed: administratively prohibited: open failed channel 980: open failed: administratively prohibited: open failed channel 981: open failed: administratively prohibited: open failed channel 982: open failed: administratively prohibited: open failed channel 983: open failed: administratively prohibited: open failed channel 984: open failed: administratively prohibited: open failed channel 987: open failed: administratively prohibited: open failed channel 988: open failed: administratively prohibited: open failed channel 989: open failed: administratively prohibited: open failed channel 990: open failed: administratively prohibited: open failed channel 991: open failed: administratively prohibited: open failed channel 997: open failed: administratively prohibited: open failed channel 1001: open failed: administratively prohibited: open failed channel 1002: open failed: administratively prohibited: open failed channel 1003: open failed: administratively prohibited: open failed channel 1004: open failed: administratively prohibited: open failed channel 1006: open failed: administratively prohibited: open failed channel 1007: open failed: administratively prohibited: open failed channel 1009: open failed: administratively prohibited: open failed channel 1012: open failed: administratively prohibited: open failed channel 1018: open failed: administratively prohibited: open failed channel 1020: open failed: administratively prohibited: open failed channel 1021: open failed: administratively prohibited: open failed channel 1028: open failed: administratively prohibited: open failed Regards From degreane at gmail.com Sun Jun 3 07:21:37 2007 From: degreane at gmail.com (Faysal Banna) Date: Sun, 03 Jun 2007 00:21:37 +0300 Subject: Tunnel connection channel Setup with proxy server Message-ID: <4661DF61.5060605@gmail.com> Hi all.. am trying to incorporate a tunnel from over a slow setup ........ /-------------------------/ /-------------------------------/ | host1 |=========//Tunnel ssh //====================| Host2 | | squid parent | | squid http_port 3128 | | 127.0.0.1:8080 | | acl accept all | \-------------------------\ \-------------------------------\ Host1 configuration : ssh -L 8080:127.0.0.1:3128 -C -N -f client at host2 The tunnel goes through the link and forwards port 8080 to 3128 from host1 to host2 main reason is that the actual link size is 2Mbit/s and i need to pass the data in compression to gain maximum http transparent proxied data transfer from Host2 to Host1. It works fine as long as i don't have heavy load but when i connect Host1 to the local home network i start having some delay after a certain amount of time i believe when the clients establish sessions through squid which redirected to parents over the Tunnel session created . i have separated the logs squid log shows normal connectivity but on the console after ssh established i got this message channel 149: open failed: connect failed: Connection timed out channel 111: open failed: connect failed: Connection timed out channel 176: open failed: connect failed: Connection timed out channel 193: open failed: connect failed: Connection timed out and afterwards the connectivity degrades remarkably .... anyone has got any clue for what this might be.. thanks in advance :) Regards F.B. From dtucker at zip.com.au Tue Jun 5 00:16:39 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Jun 2007 00:16:39 +1000 Subject: [PATCH] Add support for ldns In-Reply-To: <20070529110130.74f25c80@tx174.tx.local> References: <20070521155507.0c856d78@tx174.tx.local> <20070529110130.74f25c80@tx174.tx.local> Message-ID: <46641EC7.3040104@zip.com.au> Simon Vallet wrote: > nobody on this one ? Sorry for the delay. I started looking at this and then got sidetracked (as usual). > I really think autonomous signature validation capabilities are a useful > feature in an ssh client. In a mobile scenario, simply trusting the next > DNS hop seems only marginally better as having no signed records at all. > > I'm willing to spend more time on this patch if necessary, so any > feedback is welcome I have no objection to this in principle. LDNS seems to be under a 3-clause BSD style license so there's no potential license hassles. About the patch itself, I would probably wait until the required features make it into a released version of the software so there's more likelihood of the interface being stable. I would also like someone more familiar with DNSSEC than me to sanity check it. You added the additional functionality to one of the files that we try to keep in sync with its OpenBSD counterpart, so that's a potential maintenance hassle. I think it would be better in its own file, which according to the existing convention would be bsd-getrrsetbyname.c. Also, I'm not wild about the use of debug() calls in the compat library but I can see why you've used them. We try to avoid them in code that replaces library functions so the code is usable in other things. There's also a few style nits (lines >80 chars, indentation, spaces instead of tabs). Nothing major, but if you haven't already then please read http://www.openbsd.org/cgi-bin/man.cgi?query=style . > Simon > > On Mon, 21 May 2007 15:55:07 +0200 > Simon Vallet wrote: > >> Hi, >> >> as discussed before, we're trying to make use of SSHFP records (RFC >> 4255) to publish host key fingerprints in the DNS. >> >> However, some non-OpenBSD platforms don't support DNSSEC in the native >> resolver (e.g. glibc), which renders the whole thing quite useless, >> since openssh correctly requires the RRs to be signed and validated. >> >> The following patch adds support for ldns, an external resolver >> library, with the following functionality: >> - Set DO on the SSHFP query >> - Support AD if the answer comes from a validating resolver >> - Support autonomous validation using a configured trust anchor in case >> the answer is not marked as authentic. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From cornick at us.ibm.com Fri Jun 1 23:17:39 2007 From: cornick at us.ibm.com (Pat Cornick) Date: Fri, 1 Jun 2007 09:17:39 -0400 Subject: Need to sftp with automatic login from 1 aix machine to another, the id on the target is a DCE(DFS) id Message-ID: Hi, I had a question and can not find out on the web where anyone might have done this. I am sftping between one AIX machine and another using automatic login. I have created the id_rsa.pub on the source server and added it to the /.ssh/authorized_keys file on the target server. The problem we are having seems to be that because the target id is a DCE(DFS) id and it's home directory is /fs/home/bondbpex instead of /home/bondbpex it can't find the /.ssh/authorized_keys file. The permissions on the .ssh directory is 700 and the authorized_keys file is 600. Is this possible to be able to do this? Thanks for any help you can give me. /home/bondbrdg> sftp -v -v -v bondbpex at d03ftp101.boulder.ibm.com Connecting to d03ftp101.boulder.ibm.com... OpenSSH_4.3p2, OpenSSL 0.9.7l 28 Sep 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): Could not load module /usr/krb5/lib/libkrb5.a(libkrb5.a.so). System error: No such file or directory debug1: Error loading Kerberos, disabling Kerberos auth. debug2: ssh_connect: needpriv 0 debug1: Connecting to d03ftp101.boulder.ibm.com [9.17.187.85] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/bondbrdg/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/bondbrdg/.ssh/id_rsa type 1 debug1: identity file /home/bondbrdg/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1 p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 137/256 debug2: bits set: 493/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/bondbrdg/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/bondbrdg/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'd03ftp101.boulder.ibm.com' is known and matches the DSA host key. debug1: Found key in /home/bondbrdg/.ssh/known_hosts:1 debug2: bits set: 507/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/bondbrdg/.ssh/id_rsa (20067368) debug2: key: /home/bondbrdg/.ssh/id_dsa (0) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/bondbrdg/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/bondbrdg/.ssh/id_dsa debug3: no such identity: /home/bondbrdg/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password bondbpex at d03ftp101.boulder.ibm.com's password: Regards, Pat Global Business Services Procurement Infrastructure Team T/L 8-620-3470 (607) 429-3470 Pat Cornick/Endicott/IBM at IBMUS cornick at us.ibm.com(Internet address IBMUSM09(CORNICK) From stuge-openssh-unix-dev at cdy.org Tue Jun 5 05:18:41 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 4 Jun 2007 21:18:41 +0200 Subject: Need to sftp with automatic login from 1 aix machine to another, the id on the target is a DCE(DFS) id In-Reply-To: References: Message-ID: <20070604191841.7753.qmail@cdy.org> On Fri, Jun 01, 2007 at 09:17:39AM -0400, Pat Cornick wrote: > The problem we are having seems to be that because the target id is > a DCE(DFS) id and it's home directory is /fs/home/bondbpex instead > of /home/bondbpex it can't find the /.ssh/authorized_keys file. So put authorized_keys in the correct directory then. > The permissions on the .ssh directory is 700 and the > authorized_keys file is 600. That's all good. Check that the owner is correct too. > Is this possible to be able to do this? Yes, it works. > /home/bondbrdg> sftp -v -v -v bondbpex at d03ftp101.boulder.ibm.com This shows no problem. We also need sshd -ddd output from d03ft101. //Peter From dtucker at zip.com.au Tue Jun 5 08:11:33 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Jun 2007 08:11:33 +1000 Subject: Need to sftp with automatic login from 1 aix machine to another, the id on the target is a DCE(DFS) id In-Reply-To: References: Message-ID: <46648E15.3060904@zip.com.au> Pat Cornick wrote: > Hi, > > I had a question and can not find out on the web where anyone might have > done this. I am sftping > between one AIX machine and another using automatic login. I have created > the id_rsa.pub on the > source server and added it to the /.ssh/authorized_keys file on the target > server. The problem we > are having seems to be that because the target id is a DCE(DFS) id and it's > home directory is > /fs/home/bondbpex instead of /home/bondbpex it can't find the > /.ssh/authorized_keys file. As long as getpwnam() and friends return the correct home dir that should work. > The > permissions on the .ssh directory is 700 and the authorized_keys file is > 600. Is this possible to be able > to do this? Thanks for any help you can give me. Is the home directory not mounted until the user presents a kerberos ticket or a password that can get one? If so then sshd isn't going to be able to read the authorized_keys file in the user's home dir. What you can do is set AuthorizedKeysFile in sshd_config to point to a local filesystem (eg /etc/ssh/keys or something) but that's a system-wide parameter so it will affect all users. It would not be hard to make the Match keyword in recent versions support AuthorizedKeysFile but at the moment it doesn't. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From cornick at us.ibm.com Wed Jun 6 23:25:57 2007 From: cornick at us.ibm.com (Pat Cornick) Date: Wed, 6 Jun 2007 09:25:57 -0400 Subject: Need to sftp with automatic login from 1 aix machine to another, the id on the target is a DCE(DFS) id In-Reply-To: <46648E15.3060904@zip.com.au> Message-ID: Hi Darren, Thanks for your help on this. We will be changing the id to a local AIX id to get this to work. Take care. Regards, Pat Darren Tucker To Pat Cornick/Endicott/IBM at IBMUS 06/04/2007 06:11 cc PM openssh-unix-dev at mindrot.org Subject Re: Need to sftp with automatic login from 1 aix machine to another, the id on the target is a DCE(DFS) id Pat Cornick wrote: > Hi, > > I had a question and can not find out on the web where anyone might have > done this. I am sftping > between one AIX machine and another using automatic login. I have created > the id_rsa.pub on the > source server and added it to the /.ssh/authorized_keys file on the target > server. The problem we > are having seems to be that because the target id is a DCE(DFS) id and it's > home directory is > /fs/home/bondbpex instead of /home/bondbpex it can't find the > /.ssh/authorized_keys file. As long as getpwnam() and friends return the correct home dir that should work. > The > permissions on the .ssh directory is 700 and the authorized_keys file is > 600. Is this possible to be able > to do this? Thanks for any help you can give me. Is the home directory not mounted until the user presents a kerberos ticket or a password that can get one? If so then sshd isn't going to be able to read the authorized_keys file in the user's home dir. What you can do is set AuthorizedKeysFile in sshd_config to point to a local filesystem (eg /etc/ssh/keys or something) but that's a system-wide parameter so it will affect all users. It would not be hard to make the Match keyword in recent versions support AuthorizedKeysFile but at the moment it doesn't. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From lehmann at cnm.de Fri Jun 8 02:28:02 2007 From: lehmann at cnm.de (Marten Lehmann) Date: Thu, 07 Jun 2007 16:28:02 -0000 Subject: sftp-server with defaultroot Message-ID: Hello, I searched a while to find out, if there is an sftp-server implementation which provides an option similar to the defaultroot of proftpd. A typical use would be: DefaultRoot = ~ The option does the follwing: Once the use logs in, it determines the home directory of the user .ie /home/u1234 and takes this as the users root. The user cannot escape that root (he can not look at /tmp for example). Each file within his home directory is presented without the home directory prefix (for example: /index.html instead of /home/u1234/index.html). This is very different from the chroot options, because there is no need to have all the libraries and executables within the users home directory. The projects that I found look very strange and not good maintained. Interestingly they are based on the sftp-server of ssh. Why doesn't the openssh sftp-server include this? Are there plans to do it? Are there certain reasons not to include? Regards Marten From stuge-openssh-unix-dev at cdy.org Fri Jun 8 02:44:55 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 7 Jun 2007 18:44:55 +0200 Subject: sftp-server with defaultroot In-Reply-To: References: Message-ID: <20070607164455.9363.qmail@cdy.org> On Mon, May 21, 2007 at 07:36:17PM +0200, Marten Lehmann wrote: > Why doesn't the openssh sftp-server include this? Are there plans > to do it? Are there certain reasons not to include? This functionality needs to be in the shell, since the user's shell is always used by sshd to execute whatever program is requested. (Interactive, single command or subsystem.) See e.g. rssh //Peter From djm at mindrot.org Mon Jun 11 14:43:33 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 11 Jun 2007 14:43:33 +1000 (EST) Subject: Recent MAC improvements Message-ID: Hi, There has been some recent work to improve the speed of the Message Authentication Codes (MACs) that are used in OpenSSH. The first improvement is a change from Markus Friedl to reuse the MAC context, rather than reinitialising it for every packet. This saves two calls to the underlying hash function (e.g. SHA1) for each packet. My tests found that this yielded at 12-16% speedup for bulk transfers to localhost using HMAC-MD5 and arcfour256. HMAC-SHA1 should see an even bigger improvement, because SHA1 is a more expensive hash function. The second improvement is Peter Valchev's addition of a new MAC: Ted Krovetz' UMAC-64[1]. This MAC uses a very different approach than the HMACs that OpenSSH currently supports, and it comes with a nice security proof that guarantees its resistance so long as its underlying block cipher (AES) remains cryptologically intact. Testing (bulk transfers to localhost using arcfour256) found UMAC-64 to perform 20% better than HMAC-MD5, and 28% faster than HMAC-SHA1. This new MAC may be selected by specifying "MACs=umac-64 at openssh.com" in a server or client config. These changes need testing on as many platforms as possible. In particular we are interested in the following corner cases: - Old OpenSSL version (0.9.5ish) - Testing between big and little endian machines (i386 vs. sparc for example) - Testing between previous OpenSSH versions and -current - Testing on strict alignment architectures like Alpha and Itanium Please report your findings to the mailing list. -d [1] http://fastcrypto.org/umac/ From svallet at genoscope.cns.fr Tue Jun 12 00:09:50 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Mon, 11 Jun 2007 16:09:50 +0200 Subject: [PATCH] Add support for ldns In-Reply-To: <46641EC7.3040104@zip.com.au> References: <20070521155507.0c856d78@tx174.tx.local> <20070529110130.74f25c80@tx174.tx.local> <46641EC7.3040104@zip.com.au> Message-ID: <20070611160950.55de7d9d@tx3.tx.local> Hi, On Tue, 05 Jun 2007 00:16:39 +1000 Darren Tucker wrote: > About the patch itself, I would probably wait until the required > features make it into a released version of the software so there's more > likelihood of the interface being stable. I would also like someone > more familiar with DNSSEC than me to sanity check it. OK, I moved getrrsetbyname() in its own file and tried to be closer to style(9) -- for tracking purposes, the new patch is attached to wishlist item #1320 : http://bugzilla.mindrot.org/show_bug.cgi?id=1320 As for sanity checking, there is very little DNSSEC-specific logic in the implementation: I just retrieve the signature RRs and feed them to the lib. But sanity is never a bad thing -- if you find someone willing to spend some time on this, I think it he/she should also take a look at bug #1317. Simon -- Simon Vallet Ing?nieur Syst?mes/R?seaux Genoscope / CNRG T?l. : 01 60 87 36 06 E-mail : svallet at genoscope.cns.fr From rapier at psc.edu Tue Jun 12 03:01:03 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Jun 2007 13:01:03 -0400 Subject: Recent MAC improvements In-Reply-To: References: Message-ID: <466D7FCF.1070905@psc.edu> Should we just use a recent snap or is there a patch to apply against 4.6 canonical? Damien Miller wrote: > Hi, > > There has been some recent work to improve the speed of the Message > Authentication Codes (MACs) that are used in OpenSSH. > > The first improvement is a change from Markus Friedl to reuse the MAC > context, rather than reinitialising it for every packet. This saves two > calls to the underlying hash function (e.g. SHA1) for each packet. My > tests found that this yielded at 12-16% speedup for bulk transfers to > localhost using HMAC-MD5 and arcfour256. HMAC-SHA1 should see an even > bigger improvement, because SHA1 is a more expensive hash function. > > The second improvement is Peter Valchev's addition of a new MAC: Ted > Krovetz' UMAC-64[1]. This MAC uses a very different approach than the > HMACs that OpenSSH currently supports, and it comes with a nice security > proof that guarantees its resistance so long as its underlying block > cipher (AES) remains cryptologically intact. Testing (bulk transfers to > localhost using arcfour256) found UMAC-64 to perform 20% better than > HMAC-MD5, and 28% faster than HMAC-SHA1. This new MAC may be selected > by specifying "MACs=umac-64 at openssh.com" in a server or client config. > > These changes need testing on as many platforms as possible. In particular > we are interested in the following corner cases: > > - Old OpenSSL version (0.9.5ish) > - Testing between big and little endian machines (i386 vs. sparc for example) > - Testing between previous OpenSSH versions and -current > - Testing on strict alignment architectures like Alpha and Itanium > > Please report your findings to the mailing list. > > -d > > [1] http://fastcrypto.org/umac/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From markus.r.friedl at arcor.de Tue Jun 12 04:54:08 2007 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Mon, 11 Jun 2007 20:54:08 +0200 Subject: Recent MAC improvements In-Reply-To: <466D7FCF.1070905@psc.edu> References: <466D7FCF.1070905@psc.edu> Message-ID: <20070611185408.GA2848@folly> On Mon, Jun 11, 2007 at 01:01:03PM -0400, Chris Rapier wrote: > Should we just use a recent snap or is there a patch to apply against > 4.6 canonical? please use a recent snapshot. -m From rapier at psc.edu Tue Jun 12 05:10:21 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Jun 2007 15:10:21 -0400 Subject: Recent MAC improvements In-Reply-To: <20070611185408.GA2848@folly> References: <466D7FCF.1070905@psc.edu> <20070611185408.GA2848@folly> Message-ID: <466D9E1D.6020901@psc.edu> The only problem is that the most recent snapshot I've been able to find for the portable release is from the 28th of May. I checked several mirror sites and that is the most recent I've been able to find so far. The listed master site's most recent is from April 29th. Markus Friedl wrote: > On Mon, Jun 11, 2007 at 01:01:03PM -0400, Chris Rapier wrote: >> Should we just use a recent snap or is there a patch to apply against >> 4.6 canonical? > > please use a recent snapshot. > > -m > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From imorgan at nas.nasa.gov Tue Jun 12 05:38:10 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 11 Jun 2007 12:38:10 -0700 Subject: Recent MAC improvements In-Reply-To: <466D9E1D.6020901@psc.edu> References: <466D7FCF.1070905@psc.edu> <20070611185408.GA2848@folly> <466D9E1D.6020901@psc.edu> Message-ID: <20070611193810.GA28718@linux55.nas.nasa.gov> The snapshots at www.mindrot.org/openssh_snap appear to be recent. On Mon, Jun 11, 2007 at 15:10:21 -0400, Chris Rapier wrote: > The only problem is that the most recent snapshot I've been able to find > for the portable release is from the 28th of May. I checked several > mirror sites and that is the most recent I've been able to find so far. > > The listed master site's most recent is from April 29th. > > Markus Friedl wrote: > > On Mon, Jun 11, 2007 at 01:01:03PM -0400, Chris Rapier wrote: > >> Should we just use a recent snap or is there a patch to apply against > >> 4.6 canonical? > > > > please use a recent snapshot. > > > > -m > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From imorgan at nas.nasa.gov Tue Jun 12 05:42:36 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 11 Jun 2007 12:42:36 -0700 Subject: Recent MAC improvements In-Reply-To: References: Message-ID: <20070611194236.GB28718@linux55.nas.nasa.gov> These sound like very interesting improvements. Is the 20% improvement you quote for UMAC-64 relative to 4.6p1 or to a build that has Markus' improvement? On Mon, Jun 11, 2007 at 14:43:33 +1000, Damien Miller wrote: > Hi, > > There has been some recent work to improve the speed of the Message > Authentication Codes (MACs) that are used in OpenSSH. > > The first improvement is a change from Markus Friedl to reuse the MAC > context, rather than reinitialising it for every packet. This saves two > calls to the underlying hash function (e.g. SHA1) for each packet. My > tests found that this yielded at 12-16% speedup for bulk transfers to > localhost using HMAC-MD5 and arcfour256. HMAC-SHA1 should see an even > bigger improvement, because SHA1 is a more expensive hash function. > > The second improvement is Peter Valchev's addition of a new MAC: Ted > Krovetz' UMAC-64[1]. This MAC uses a very different approach than the > HMACs that OpenSSH currently supports, and it comes with a nice security > proof that guarantees its resistance so long as its underlying block > cipher (AES) remains cryptologically intact. Testing (bulk transfers to > localhost using arcfour256) found UMAC-64 to perform 20% better than > HMAC-MD5, and 28% faster than HMAC-SHA1. This new MAC may be selected > by specifying "MACs=umac-64 at openssh.com" in a server or client config. > > These changes need testing on as many platforms as possible. In particular > we are interested in the following corner cases: > > - Old OpenSSL version (0.9.5ish) > - Testing between big and little endian machines (i386 vs. sparc for example) > - Testing between previous OpenSSH versions and -current > - Testing on strict alignment architectures like Alpha and Itanium > > Please report your findings to the mailing list. > > -d > > [1] http://fastcrypto.org/umac/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From rapier at psc.edu Tue Jun 12 06:03:25 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Jun 2007 16:03:25 -0400 Subject: Recent MAC improvements In-Reply-To: <20070611193810.GA28718@linux55.nas.nasa.gov> References: <466D7FCF.1070905@psc.edu> <20070611185408.GA2848@folly> <466D9E1D.6020901@psc.edu> <20070611193810.GA28718@linux55.nas.nasa.gov> Message-ID: <466DAA8D.4030202@psc.edu> Excellent. I didn't know about this repository - its not on the list. Thanks! Iain Morgan wrote: > The snapshots at www.mindrot.org/openssh_snap appear to be recent. > > On Mon, Jun 11, 2007 at 15:10:21 -0400, Chris Rapier wrote: >> The only problem is that the most recent snapshot I've been able to find >> for the portable release is from the 28th of May. I checked several >> mirror sites and that is the most recent I've been able to find so far. >> >> The listed master site's most recent is from April 29th. >> >> Markus Friedl wrote: >>> On Mon, Jun 11, 2007 at 01:01:03PM -0400, Chris Rapier wrote: >>>> Should we just use a recent snap or is there a patch to apply against >>>> 4.6 canonical? >>> please use a recent snapshot. >>> >>> -m >>> _______________________________________________ >>> openssh-unix-dev mailing list >>> openssh-unix-dev at mindrot.org >>> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Tue Jun 12 07:04:20 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 12 Jun 2007 07:04:20 +1000 (EST) Subject: Recent MAC improvements In-Reply-To: <20070611194236.GB28718@linux55.nas.nasa.gov> References: <20070611194236.GB28718@linux55.nas.nasa.gov> Message-ID: On Mon, 11 Jun 2007, Iain Morgan wrote: > These sound like very interesting improvements. > > Is the 20% improvement you quote for UMAC-64 relative to > 4.6p1 or to a build that has Markus' improvement? Sorry, I should have mentioned this: the 20% improvement was measured after Markus patch was applied. -d From rapier at psc.edu Tue Jun 12 08:22:58 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Jun 2007 18:22:58 -0400 Subject: Recent MAC improvements: Test Results In-Reply-To: References: Message-ID: <466DCB42.7060501@psc.edu> Environment: OpenSSH 4.6p1 1Gb/s 1.12ms RTT Linux 2.6.18-web100 to Linux 2.6.16-web100 Autotuning enabled. 2.4Ghz Xeon SMP 20 iterations of 2GB scp transfer. Disk to /dev/null scp -caes256-cbc -P 42222 ~/2gb rapier at delta:/dev/null MAC - avg 25.0MB/s (1:22) STD - avg 24.0MB/s (1:25) So its definitely an improvement. If you eliminate the outliers the average of the MAC runs improves to 25.1MB/s. I haven't tried the UMAC yet but when I do I'll post it here. There are some Itaniums and other architectures I can try it against here. I'll try to get to those tomorrow. I've included the raw data below if anyone wants it. Chris ps. I did also try the HPN patch. That got me 25.36MB/s. I'm guessing that might be more due to a change in the scp pipe buffer size I made than the channel buffer tuning. I'll rerun it tomorrow by catting through ssh and see if I can factor that out. STD 2gb 100% 2048MB 23 1:29 24.035 2gb 100% 2048MB 24.4 1:24 1:25 2gb 100% 2048MB 22.8 1:30 2gb 100% 2048MB 22.5 1:31 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 22.8 1:30 2gb 100% 2048MB 23.3 1:28 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.7 1:23 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 2gb 100% 2048MB 24.4 1:24 MAC 2gb 100% 2048MB 25.3 1:21 24.9952381 2gb 100% 2048MB 24.7 1:23 1:22 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 22.5 1:31 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25 1:22 2gb 100% 2048MB 24.7 1:23 2gb 100% 2048MB 25.3 1:21 HPN 2gb 100% 2048MB 25.6 1:20 25.36 2gb 100% 2048MB 25.6 1:20 1:20 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 23.5 1:27 2gb 100% 2048MB 24.1 1:25 2gb 100% 2048MB 25.9 1:19 2gb 100% 2048MB 25.9 1:19 2gb 100% 2048MB 24.1 1:25 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.6 1:20 2gb 100% 2048MB 25.9 1:19 2gb 100% 2048MB 25.9 1:19 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25.3 1:21 2gb 100% 2048MB 25.6 1:20 From djm at mindrot.org Tue Jun 12 08:26:18 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 12 Jun 2007 08:26:18 +1000 (EST) Subject: Recent MAC improvements: Test Results In-Reply-To: <466DCB42.7060501@psc.edu> References: <466DCB42.7060501@psc.edu> Message-ID: On Mon, 11 Jun 2007, Chris Rapier wrote: > Environment: > OpenSSH 4.6p1 > 1Gb/s 1.12ms RTT > Linux 2.6.18-web100 to Linux 2.6.16-web100 > Autotuning enabled. 2.4Ghz Xeon SMP > 20 iterations of 2GB scp transfer. Disk to /dev/null > scp -caes256-cbc -P 42222 ~/2gb rapier at delta:/dev/null > > MAC - avg 25.0MB/s (1:22) > STD - avg 24.0MB/s (1:25) You will see the difference more clearly if you use a faster cipher, like aes128-cbc, aes128-ctr or arcfour256. -d From rapier at psc.edu Tue Jun 12 08:46:49 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Jun 2007 18:46:49 -0400 Subject: Recent MAC improvements: Test Results In-Reply-To: References: <466DCB42.7060501@psc.edu> Message-ID: <466DD0D9.6080101@psc.edu> I ran it a few times earlier with aes128 but the results were inconsistent. I felt it was because I was hitting a disk i/o bottleneck instead of a processor limitation. I'll try it now with arcfour256. Still, even though the difference posted might not seem impressive I actually thought it was. 1MB/s can make a *serious* difference when you are dealing with terabyte datasets. Damien Miller wrote: > On Mon, 11 Jun 2007, Chris Rapier wrote: > >> Environment: >> OpenSSH 4.6p1 >> 1Gb/s 1.12ms RTT >> Linux 2.6.18-web100 to Linux 2.6.16-web100 >> Autotuning enabled. 2.4Ghz Xeon SMP >> 20 iterations of 2GB scp transfer. Disk to /dev/null >> scp -caes256-cbc -P 42222 ~/2gb rapier at delta:/dev/null >> >> MAC - avg 25.0MB/s (1:22) >> STD - avg 24.0MB/s (1:25) > > You will see the difference more clearly if you use a faster cipher, > like aes128-cbc, aes128-ctr or arcfour256. > > -d From dkg-openssh.com at fifthhorseman.net Tue Jun 12 09:35:58 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 11 Jun 2007 19:35:58 -0400 Subject: Recent MAC improvements: Test Results In-Reply-To: <466DD0D9.6080101@psc.edu> (Chris Rapier's message of "Mon, 11 Jun 2007 18:46:49 -0400") References: <466DCB42.7060501@psc.edu> <466DD0D9.6080101@psc.edu> Message-ID: <87ps42qd29.fsf@squeak.fifthhorseman.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon 2007-06-11 18:46:49 -0400, Chris Rapier wrote: > I ran it a few times earlier with aes128 but the results were > inconsistent. I felt it was because I was hitting a disk i/o bottleneck > instead of a processor limitation. I'll try it now with arcfour256. if you're worried that it's a disk I/O bottleneck, you could try sourcing from /dev/zero (by analogy with your current sinking to /dev/null). That would take the disks out of the picture entirely. Alternately, you could use dd to create a huge sparse file that doesn't use any room on the disk. For example, a 1G file that only uses 1K on disk: [0 dkg at squeak ~]$ dd if=/dev/zero bs=1K count=1 seek=1M of=bigfile 1+0 records in 1+0 records out 1024 bytes (1.0 kB) copied, 0.000249195 seconds, 4.1 MB/s [0 dkg at squeak ~]$ ls -la bigfile - -rw-r--r-- 1 dkg dkg 1073742848 2007-06-11 19:33 bigfile [0 dkg at squeak ~]$ If it turns out that the MAC algorithms you're testing work differently when the cleartext stream is all the same byte, this won't work, of course. --dkg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ iD8DBQFGbdxbiXTlFKVLY2URAnNcAJ42T5NUAP3REkSi5aMOZh/Rd2+UogCgthpe 07btFUyNCE4phhhUbv7gEGk= =5y6v -----END PGP SIGNATURE----- From djm at mindrot.org Tue Jun 12 11:21:32 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 12 Jun 2007 11:21:32 +1000 (EST) Subject: Recent MAC improvements In-Reply-To: References: Message-ID: On Mon, 11 Jun 2007, Damien Miller wrote: > These changes need testing on as many platforms as possible. In particular > we are interested in the following corner cases: > > - Old OpenSSL version (0.9.5ish) > - Testing between big and little endian machines (i386 vs. sparc for example) > - Testing between previous OpenSSH versions and -current > - Testing on strict alignment architectures like Alpha and Itanium One more case: - Interoperability against non-OpenSSH implementations This applies mainly for the MAC reuse change, as no other implementations would support UMAC yet. If other implementors want to support UMAC, there is a specification for how OpenSSH does it at [1] which is awaiting publication (assuming I have the IETF boilerplate de jour correct this time). OpenSSH uses a slightly tweaked version of the UMAC reference implementation[2]. -d [1] http://www.mindrot.org/~djm/internet-drafts/draft-miller-secsh-umac-00.txt [2] http://www.fastcrypto.org/umac/2004/code.html From rapier at psc.edu Wed Jun 13 06:50:47 2007 From: rapier at psc.edu (Chris Rapier) Date: Tue, 12 Jun 2007 16:50:47 -0400 Subject: Recent MAC improvements: Test Results In-Reply-To: References: <466DCB42.7060501@psc.edu> Message-ID: <466F0727.4060105@psc.edu> I did some more tests on this. I used the June 13 (sic) snapshot. First though I determined what the base rate was. Using nc I was able to transfer a 2GB file at ~51 MB/s (thats an average of 20 runs). Using Iperf I was able to establish the network baseline at ~115MB/s. I was able to get this even using a 32KB receive window. So at this point I'm thinking that neither Disk I/O nor the TCP stack are going to be significant bottlenecks. I reran some of the tests by catting a 2GB file over ssh. This time I used the arcfour256 cipher. The results were much more clear. MAC 38.9MB/s (0:52.6) STD 31.0MB/s (1:06.0) UMAC 38.3MB/s (0:52.7) HPN 34.1MB/s (1:00.6) Time reported the following for user time, 40.8, 37.6, 38.2, and 36.9 respectively. Sys time was 7.23, 8.2, 7.7, and 8.6 again respectively. I was surprised that UMAC didn't actually produce a performance boost though. I might have screwed something up but I did verify that the umac-64 hash was being used. I'm going to rerun all of my previous tests with the latest snapshot and I'll be running them in parallel as well - to see what impact a heavy load might have. I also noticed that the default buffer size has been increased pretty drastically (to 2MB up from 128KB). This should be welcome news to a good number of users. The window adjust message timing has been changed as well (from when 50% of buffer consumed to once every 3 packets). I was wondering what is the expected impact of making that change? Chris Damien Miller wrote: > On Mon, 11 Jun 2007, Chris Rapier wrote: > >> Environment: >> OpenSSH 4.6p1 >> 1Gb/s 1.12ms RTT >> Linux 2.6.18-web100 to Linux 2.6.16-web100 >> Autotuning enabled. 2.4Ghz Xeon SMP >> 20 iterations of 2GB scp transfer. Disk to /dev/null >> scp -caes256-cbc -P 42222 ~/2gb rapier at delta:/dev/null >> >> MAC - avg 25.0MB/s (1:22) >> STD - avg 24.0MB/s (1:25) > > You will see the difference more clearly if you use a faster cipher, > like aes128-cbc, aes128-ctr or arcfour256. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From matt at malloc.org Wed Jun 13 07:27:08 2007 From: matt at malloc.org (Matt Anderson) Date: Tue, 12 Jun 2007 17:27:08 -0400 Subject: Recent MAC improvements In-Reply-To: References: Message-ID: <20070612212708.GF44708@eris.discordians.net> On Tue, Jun 12, 2007 at 11:21:32AM +1000, Damien Miller wrote: > On Mon, 11 Jun 2007, Damien Miller wrote: > > > These changes need testing on as many platforms as possible. In particular > > we are interested in the following corner cases: > > > > - Old OpenSSL version (0.9.5ish) > > - Testing between big and little endian machines (i386 vs. sparc for example) > > - Testing between previous OpenSSH versions and -current > > - Testing on strict alignment architectures like Alpha and Itanium > > - Interoperability against non-OpenSSH implementations I built the openssh-SNAP-20070613.tar.gz on a RHEL5 Itanium system and was able to successfully connect to an SSH.com server running on a Tru64 Alpha system (SSH-2.0-3.2.0 on v5.1B of Tru64.) I also was able to use umac-64 at openssh.org when connecting over localhost to my Itanium system. -matt From imorgan at nas.nasa.gov Wed Jun 13 08:40:05 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 12 Jun 2007 15:40:05 -0700 Subject: Recent MAC improvements In-Reply-To: <20070612212708.GF44708@eris.discordians.net> References: <20070612212708.GF44708@eris.discordians.net> Message-ID: <20070612224005.GA19655@linux55.nas.nasa.gov> On Tue, Jun 12, 2007 at 17:27:08 -0400, Matt Anderson wrote: > On Tue, Jun 12, 2007 at 11:21:32AM +1000, Damien Miller wrote: > > On Mon, 11 Jun 2007, Damien Miller wrote: > > > > > These changes need testing on as many platforms as possible. In particular > > > we are interested in the following corner cases: > > > > > > - Old OpenSSL version (0.9.5ish) > > > - Testing between big and little endian machines (i386 vs. sparc for example) > > > - Testing between previous OpenSSH versions and -current > > > - Testing on strict alignment architectures like Alpha and Itanium > > > > - Interoperability against non-OpenSSH implementations > > I built the openssh-SNAP-20070613.tar.gz on a RHEL5 Itanium system and > was able to successfully connect to an SSH.com server running on a > Tru64 Alpha system (SSH-2.0-3.2.0 on v5.1B of Tru64.) > > I also was able to use umac-64 at openssh.org when connecting over > localhost to my Itanium system. > > -matt > Matt, How's the performance on Itanium using UMAC-64 versus HMAC-MD5? -- Iain Morgan From vinschen at redhat.com Wed Jun 13 18:36:00 2007 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 13 Jun 2007 10:36:00 +0200 Subject: Recent MAC improvements In-Reply-To: References: Message-ID: <20070613083600.GA12123@calimero.vinschen.de> On Jun 11 14:43, Damien Miller wrote: > Hi, > > There has been some recent work to improve the speed of the Message > Authentication Codes (MACs) that are used in OpenSSH. > > The first improvement is a change from Markus Friedl to reuse the MAC > context, rather than reinitialising it for every packet. This saves two > calls to the underlying hash function (e.g. SHA1) for each packet. My > tests found that this yielded at 12-16% speedup for bulk transfers to > localhost using HMAC-MD5 and arcfour256. HMAC-SHA1 should see an even > bigger improvement, because SHA1 is a more expensive hash function. > > The second improvement is Peter Valchev's addition of a new MAC: Ted > Krovetz' UMAC-64[1]. This MAC uses a very different approach than the > HMACs that OpenSSH currently supports, and it comes with a nice security > proof that guarantees its resistance so long as its underlying block > cipher (AES) remains cryptologically intact. Testing (bulk transfers to > localhost using arcfour256) found UMAC-64 to perform 20% better than > HMAC-MD5, and 28% faster than HMAC-SHA1. This new MAC may be selected > by specifying "MACs=umac-64 at openssh.com" in a server or client config. > > These changes need testing on as many platforms as possible. In particular > we are interested in the following corner cases: > > - Old OpenSSL version (0.9.5ish) > - Testing between big and little endian machines (i386 vs. sparc for example) > - Testing between previous OpenSSH versions and -current > - Testing on strict alignment architectures like Alpha and Itanium > > Please report your findings to the mailing list. Builds and runs fine on Cygwin w/ openssl 0.9.8e. Exchanging data with Cygwin 4.6p1 and Linux 4.5p1 works fine. UMAC works fine between Cygwin machines. I see a 14% speed improvement in a default scp with no further options, relative to 4.6p1. Using umac-64 the speed improvement is 15%. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rapier at psc.edu Thu Jun 14 01:19:02 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 13 Jun 2007 11:19:02 -0400 Subject: Recent MAC improvements: Test Results In-Reply-To: <466F0727.4060105@psc.edu> References: <466DCB42.7060501@psc.edu> <466F0727.4060105@psc.edu> Message-ID: <46700AE6.3010700@psc.edu> I know everyone is probably sick of these test results but I only have one last set to share. The executive summary is that the mac context recycling really does provide a notable performance boost. The use of umac also provides a boost but not nearly as dramatic. As a note: The client was using OpenSSL 0.9.7e. The server was using 0.9.7a. I also ran tests from and against OpenSSH 3.8.1p1 with no problems except for umac failing. The first line is the test type, average throughput and percent increase in throughput performance compared to STD. The next line is the average time and the standard deviation. The 3rd line is user time and SD, the last is system time and SD. As a note, I'm not comfortable with the results from the /dev/zero tests. There may have been contention on the line causing problems. The large SD may support that. I'm rerunning the tests on a cleaner path. If anyone wants those results just send me some mail. STD /dev/zero 21.3MB/s 0%+ 96.11 19.14251411 37.4725 0.205653643 7.5275 0.207969507 MAC /dev/zero 44.9MB/s 110.9%+ 45.55 0.403944694 34.3865 0.11586176 8.612 0.268241839 UMAC /dev/zero 46.3MB/s 117.1%+ 44.28 2.828852473 32.829 2.936800801 8.765 0.211149735 HPN /dev/zero 22.9MB/s 7.3%+ 89.59 19.79009276 37.468 2.853274389 7.3665 0.456926517 STD scp 30.1MB/s 0%+ 68.06 1.233210935 0.4975 0.032097713 3.999 0.10789371 MAC scp 34.0MB/s 14.0%+ 60.20 4.034492435 0.5455 0.067782547 4.242 0.403453513 UMAC scp 34.6MB/s 15.8%+ 59.26 3.434033381 0.528 0.055212508 4.1835 0.324982186 HPN scp 30.4MB/s 0.9%+ 67.42 1.553637159 0.1445 0.019594575 3.2015 0.087676139 From imorgan at nas.nasa.gov Thu Jun 14 02:12:20 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 13 Jun 2007 09:12:20 -0700 Subject: Recent MAC improvements In-Reply-To: <20070612212708.GF44708@eris.discordians.net> References: <20070612212708.GF44708@eris.discordians.net> Message-ID: <20070613161220.GA9099@linux55.nas.nasa.gov> On Tue, Jun 12, 2007 at 17:27:08 -0400, Matt Anderson wrote: > On Tue, Jun 12, 2007 at 11:21:32AM +1000, Damien Miller wrote: > > On Mon, 11 Jun 2007, Damien Miller wrote: > > > > > These changes need testing on as many platforms as possible. In particular > > > we are interested in the following corner cases: > > > > > > - Old OpenSSL version (0.9.5ish) > > > - Testing between big and little endian machines (i386 vs. sparc for example) > > > - Testing between previous OpenSSH versions and -current > > > - Testing on strict alignment architectures like Alpha and Itanium > > > > - Interoperability against non-OpenSSH implementations > > I built the openssh-SNAP-20070613.tar.gz on a RHEL5 Itanium system and > was able to successfully connect to an SSH.com server running on a > Tru64 Alpha system (SSH-2.0-3.2.0 on v5.1B of Tru64.) > > I also was able to use umac-64 at openssh.org when connecting over > localhost to my Itanium system. > > -matt > This may have simply been a typo, but you refer to 'umac-64 at openssh.org' whereas I believe it should actually be 'umac-64 at openssh.com'. -- Iain Morgan From matt at malloc.org Thu Jun 14 02:50:40 2007 From: matt at malloc.org (Matt Anderson) Date: Wed, 13 Jun 2007 12:50:40 -0400 Subject: Recent MAC improvements In-Reply-To: <20070613161220.GA9099@linux55.nas.nasa.gov> References: <20070612212708.GF44708@eris.discordians.net> <20070613161220.GA9099@linux55.nas.nasa.gov> Message-ID: <20070613165040.GA85335@eris.discordians.net> On Wed, Jun 13, 2007 at 09:12:20AM -0700, Iain Morgan wrote: > On Tue, Jun 12, 2007 at 17:27:08 -0400, Matt Anderson wrote: > > On Tue, Jun 12, 2007 at 11:21:32AM +1000, Damien Miller wrote: > > > On Mon, 11 Jun 2007, Damien Miller wrote: > > > > > > > These changes need testing on as many platforms as possible. In particular > > > > we are interested in the following corner cases: > > > > > > > > - Old OpenSSL version (0.9.5ish) > > > > - Testing between big and little endian machines (i386 vs. sparc for example) > > > > - Testing between previous OpenSSH versions and -current > > > > - Testing on strict alignment architectures like Alpha and Itanium > > > > > > - Interoperability against non-OpenSSH implementations > > > > I built the openssh-SNAP-20070613.tar.gz on a RHEL5 Itanium system and > > was able to successfully connect to an SSH.com server running on a > > Tru64 Alpha system (SSH-2.0-3.2.0 on v5.1B of Tru64.) > > > > I also was able to use umac-64 at openssh.org when connecting over > > localhost to my Itanium system. > > > > -matt > > > > This may have simply been a typo, but you refer to 'umac-64 at openssh.org' > whereas I believe it should actually be 'umac-64 at openssh.com'. You're right, I guess my fingers are biased towards typing .org. I just did some simple transfers and saw a 16.6% improvement on itanium when using umac-64 at openssh.com over hmac-md5. -matt From imorgan at nas.nasa.gov Thu Jun 14 03:48:38 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 13 Jun 2007 10:48:38 -0700 Subject: Recent MAC improvements In-Reply-To: References: Message-ID: <20070613174838.GA10825@linux55.nas.nasa.gov> On Tue, Jun 12, 2007 at 11:21:32 +1000, Damien Miller wrote: > On Mon, 11 Jun 2007, Damien Miller wrote: > > > These changes need testing on as many platforms as possible. In particular > > we are interested in the following corner cases: > > > > - Old OpenSSL version (0.9.5ish) > > - Testing between big and little endian machines (i386 vs. sparc for example) > > - Testing between previous OpenSSH versions and -current > > - Testing on strict alignment architectures like Alpha and Itanium > > One more case: > > - Interoperability against non-OpenSSH implementations > > This applies mainly for the MAC reuse change, as no other implementations > would support UMAC yet. > > If other implementors want to support UMAC, there is a specification > for how OpenSSH does it at [1] which is awaiting publication (assuming > I have the IETF boilerplate de jour correct this time). OpenSSH uses a > slightly tweaked version of the UMAC reference implementation[2]. > > -d > > [1] http://www.mindrot.org/~djm/internet-drafts/draft-miller-secsh-umac-00.txt > [2] http://www.fastcrypto.org/umac/2004/code.html > I just did a test scp'ing a 10GB file using the 20070613 snapshot to a server running the 4.2.1.1 rev of SSH.COM's product. The MAC reuse did not appear to be a problem. -- Iain Morgan From jurnettv at juridico.net Sat Jun 9 10:53:00 2007 From: jurnettv at juridico.net (=?ISO-8859-1?Q?Jur=EDdicoNet?=) Date: Fri, 8 Jun 2007 19:53:00 -0500 Subject: JurNet TV - JuridicoNet Message-ID: <20070613113553.3A8A069AB6@natsu.mindrot.org> Lo invitamos a conocer el nuevo concepto JurnetTV de Jur?dicoNet. Presentamos nuestro proyecto Libro Jurnet donde podr? ver los beneficios adicionales que damos a nuestras obras publicadas. Visite por favor la siguiente liga de internet http://www.juridico.net/contactoautores En caso de que usted no est? directamente relacionado con alguna de las disciplinas del Derecho o rama del conocimiento jur?dico, por favor reenv?e esta comunicaci?n a quien usted considera que puede serle ?til. Reciba un saludo cordial de sus amigos y servidores. JurnetTV - Jur?dicoNet Luis E Jim?nez R Director General Jur?dicoNet Insurgentes Sur 576 Mezzanine 2 Col. Del Valle M?xico, D.F. 03100 Tel. (55) 5682 6189 / 5682 7505 01 800 702 0909 www.juridico.net Este mensaje se env?a en acuerdo con la nueva legislaci?n sobre correo electr?nico: Por secci?n 301, p?rrafo (a) (2) (C) de S.1618. Bajo el decreto S.1618 titulo 3ro. Aprobado por el 105? Congreso base de las normativas internacionales sobre SPAM, este E-mail no podr? ser considerado SPAM mientras incluya una forma de ser removido. Envio/080607 Si deseas dejar de recibir este correo, envie un mensaje a http://www.jurnettv at juridico.net con la palabra REMOVE en el campo Asunto o Subjet. From richard.brewer at navy.mil Thu Jun 14 05:12:55 2007 From: richard.brewer at navy.mil (Brewer, Richard V. USNCIV NAVAIR N/A) Date: Wed, 13 Jun 2007 15:12:55 -0400 Subject: OPENSSH Support Policies Message-ID: Do you have a limitation on providing support for the older versions of OPENSSH? The version in question is 4.3P2 Thanks, Rick Brewer NAWC-AD 6.8.4 301-757-8871 From rapier at psc.edu Fri Jun 15 01:30:10 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 14 Jun 2007 11:30:10 -0400 Subject: Recent MAC improvements - stalls In-Reply-To: <20070613174838.GA10825@linux55.nas.nasa.gov> References: <20070613174838.GA10825@linux55.nas.nasa.gov> Message-ID: <46715F02.9060009@psc.edu> I've been seeing intermittent stalls with the June 13th snapshot. I've been able to recreate them pretty consistently and I've only been able to do it with the June 13th snapshot. I've included the level 1 debug output. I hit enter around once a second to show the progress and where it stalls. This is happening when I am using the mac recycling code as a client side sink. It happens when I connect to a mac recycling server or a standard install. During the tests I ran over the last hour it would sometimes happen every other transfer and other times it would happen *maybe* one out of 15 times. This is happening with the default mac and the new umac-64 It *may* be due to the fact that we're running the default interface with a 9K MTU but its connecting to a 1.5K MTU source. I did try it over one of the 1.5K MTU NICs but saw the same problem. However, I'm not seeing these stalls with a std to std transfer. I've no idea if this is a problem specific to my install on this machine or not. I'm thinking it is because I was unable to recreate the problem in the other direction. However, I thought you should be aware of it. environment: client - OpenSSH_4.6p1-snap20070613, OpenSSL 0.9.8b 04 May 2006 servers - OpenSSH_4.6p1-snap20070613, OpenSSL 0.9.7a Feb 19 2003 OpenSSH_4.6p1, OpenSSL 0.9.7a Feb 19 2003 Host information - Linux brillo 2.6.20-web100 #6 SMP Wed Mar 21 14:35:36 EDT 2007 i686 GNU/Linux - Xeon 2 CPU dual core at 2.8Ghz. 1Gb connection traversing 1 switch. rtt min/avg/max/mdev = 0.054/0.108/0.171/0.035 ms (syskonnect) skge eth2: Link is up at 1000 Mbps, full duplex, flow control rx only Machine is multihomed. command: ssh46-mac/scp -S ssh46-mac/ssh -oMacs=umac-64 at openssh.com -carcfour256 -v -P 42222 rapier at delta:~/2gb /dev/null Executing: program ssh46-mac/ssh host delta, user rapier, command scp -v -f ~/2gb OpenSSH_4.6p1-snap20070613, OpenSSL 0.9.8b 04 May 2006 debug1: Connecting to delta [128.182.66.67] port 42222. debug1: Connection established. debug1: identity file /home/pscnoc/.ssh/identity type -1 debug1: identity file /home/pscnoc/.ssh/id_rsa type -1 debug1: identity file /home/pscnoc/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.6 debug1: match: OpenSSH_4.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client arcfour256 hmac-md5 none debug1: kex: client->server arcfour256 hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: checking without port identifier debug1: Host 'delta' is known and matches the RSA host key. debug1: Found key in /home/pscnoc/.ssh/known_hosts:5 debug1: found matching key w/out port debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/pscnoc/.ssh/identity debug1: Trying private key: /home/pscnoc/.ssh/id_rsa debug1: Offering public key: /home/pscnoc/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 433 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending command: scp -v -f ~/2gb Sending file modes: C0644 2147483648 2gb Sink: C0644 2147483648 2gb 2gb 2% 55MB 54.9MB/s 00:36 ETA 2gb 5% 110MB 54.9MB/s 00:35 ETA 2gb 8% 165MB 55.0MB/s 00:34 ETA 2gb 10% 220MB 55.0MB/s 00:33 ETA 2gb 13% 275MB 55.0MB/s 00:32 ETA 2gb 13% 276MB 49.6MB/s 00:35 ETA 2gb 13% 276MB 44.6MB/s 00:39 ETA 2gb 13% 276MB 40.2MB/s 00:44 ETA 2gb 13% 276MB 32.5MB/s 00:54 ETA 2gb 13% 276MB 29.3MB/s 01:00 ETA 2gb 13% 276MB 26.4MB/s 01:07 ETA 2gb 13% 276MB 23.7MB/s 01:14 ETA 2gb 13% 276MB 21.4MB/s 01:22 ETA 2gb 13% 276MB 19.2MB/s 01:32 ETA 2gb 13% 278MB 17.5MB/s 01:41 ETA 2gb 13% 278MB 15.7MB/s 01:52 ETA From djm at mindrot.org Fri Jun 15 09:48:16 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Jun 2007 09:48:16 +1000 (EST) Subject: OPENSSH Support Policies In-Reply-To: References: Message-ID: On Wed, 13 Jun 2007, Brewer, Richard V. USNCIV NAVAIR N/A wrote: > Do you have a limitation on providing support for the older versions of > OPENSSH? The version in question is 4.3P2 The OpenSSH team only supports the latest released version, in that we don't go out of our way to provide fixes for previous versions (though often the fix for the latest version will apply anyway). If you need long-term support for a fixed version, you can seek it through your operating system vendor or contract an interested developer directly. -d From valerio.balbi at gmail.com Mon Jun 18 11:48:06 2007 From: valerio.balbi at gmail.com (valerio balbi) Date: Mon, 18 Jun 2007 03:48:06 +0200 Subject: patch for triggering SFTP process_write Message-ID: <4675E456.3060404@gmail.com> Hi Damien! I produced a little patch to the package ver. 4.6p1 for linux. My company, for many bureaucratic reasons, was interested in triggering each uploaded file to the server using sftp subsystem. In Internet and in ML, all folks solve the problem using a script joining sftp command section to ssh command section, but unfortunately isn't my case. The patch consist in a modification of sshd_config file. In this file I add two new directive for each user who want to trigger the write mechanism. The new items in configuration file are essentially skipped by serverconf.c module: I'll try to be the less invasive I can... In the other hand, SFTP-server re-read configuration file to catch the new items only if the config line contains pw->pw_name, i.e. the authenticated user of this sftp session. Only in this case a new struct, called Trigger, is filled with path and filename of the script to be triggered after the OKwrite event. When calling the triggered script I check the F_OK and the X_OK status and, eventually, exit with error: so the client can notice the error too. If all OK, I perform a fork+execv calling what indicated by struct Trigger. With many user, I can perform different personalized procedures. (thinking at my case this is cool!) Many stylistic enhancements can take place... but I'm a sysadm :P I think this patch should be a usefull feature, in this case: nice to support the community! Valerio Balbi (aka pvb265) -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.6p1-pvb265p1.patch.bz2 Type: application/x-bzip Size: 3245 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070618/efcc7943/attachment-0001.bin From dot at dotat.at Tue Jun 19 02:50:15 2007 From: dot at dotat.at (Tony Finch) Date: Mon, 18 Jun 2007 17:50:15 +0100 Subject: [PATCH] incorrect #include in ssh-rand-helper.c Message-ID: --- ssh-rand-helper.c.orig Mon Jun 18 16:48:13 2007 +++ ssh-rand-helper.c Mon Jun 18 16:47:32 2007 @@ -31,7 +31,7 @@ #include #include -#include +#include #include #include Tony. -- f.a.n.finch http://dotat.at/ SHANNON ROCKALL: EAST OR NORTHEAST 3 OR 4, INCREASING 5 TO 7. MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From dot at dotat.at Tue Jun 19 02:56:27 2007 From: dot at dotat.at (Tony Finch) Date: Mon, 18 Jun 2007 17:56:27 +0100 Subject: [PATCH] sftp-server argument error handling Message-ID: When you give sftp-server a bogus -l or -f parameter, it logs a useful error message then blunders on to call log_init() with the bogus value. log_init() then prints a less useful message to stderr and exits. The following patch tidies this up by only printing the more useful error to stderr and not blundering on afterwards. --- sftp-server.c.orig Mon Jun 18 16:37:46 2007 +++ sftp-server.c Mon Jun 18 16:39:14 2007 @@ -1220,7 +1220,8 @@ sanitise_stdfd(); __progname = ssh_get_progname(argv[0]); - log_init(__progname, log_level, log_facility, log_stderr); + /* Send any argument errors to stderr */ + log_init(__progname, log_level, log_facility, 1); while (!skipargs && (ch = getopt(argc, argv, "C:f:l:che")) != -1) { switch (ch) { @@ -1237,12 +1238,12 @@ case 'l': log_level = log_level_number(optarg); if (log_level == SYSLOG_LEVEL_NOT_SET) - error("Invalid log level \"%s\"", optarg); + fatal("Invalid log level \"%s\"", optarg); break; case 'f': log_facility = log_facility_number(optarg); if (log_level == SYSLOG_FACILITY_NOT_SET) - error("Invalid log facility \"%s\"", optarg); + fatal("Invalid log facility \"%s\"", optarg); break; case 'h': default: Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES: SOUTHEASTERLY, VEERING SOUTHWESTERLY FOR A TIME, 3 OR 4 OCCASIONALLY 5. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD. From dtucker at zip.com.au Tue Jun 19 08:01:35 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Jun 2007 08:01:35 +1000 Subject: [PATCH] incorrect #include in ssh-rand-helper.c In-Reply-To: References: Message-ID: <20070618220135.GA13271@gate.dtucker.net> On Mon, Jun 18, 2007 at 05:50:15PM +0100, Tony Finch wrote: > --- ssh-rand-helper.c.orig Mon Jun 18 16:48:13 2007 > +++ ssh-rand-helper.c Mon Jun 18 16:47:32 2007 > @@ -31,7 +31,7 @@ > #include > > #include > -#include > +#include string.h was recently added (rev 1.41, 2007/03/12). You didn't say why you think that stddef.h is wrong and should be removed. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dot at dotat.at Tue Jun 19 20:35:47 2007 From: dot at dotat.at (Tony Finch) Date: Tue, 19 Jun 2007 11:35:47 +0100 Subject: [PATCH] incorrect #include in ssh-rand-helper.c In-Reply-To: <20070618220135.GA13271@gate.dtucker.net> References: <20070618220135.GA13271@gate.dtucker.net> Message-ID: On Tue, 19 Jun 2007, Darren Tucker wrote: > > string.h was recently added (rev 1.41, 2007/03/12). You didn't say why > you think that stddef.h is wrong and should be removed. You're right, it's needed for offsetof() which my compiler failed to warn about. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: EASTERLY 3 OR 4, OCCASIONALLY 5 LATER. SLIGHT TO MODERATE. SHOWERS, RAIN LATER, FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From rapier at psc.edu Wed Jun 20 07:36:52 2007 From: rapier at psc.edu (Chris Rapier) Date: Tue, 19 Jun 2007 17:36:52 -0400 Subject: Channels In-Reply-To: <466F177D.9000908@zip.com.au> References: <466DCB42.7060501@psc.edu> <466F0727.4060105@psc.edu> <466F177D.9000908@zip.com.au> Message-ID: <46784C74.6070302@psc.edu> I just have a quick question about how channels are managed. As far as I can tell all of the channel structs are stored in channels[]. It seems that ssh cycles through all allocated slots in channels[] is to determine which channels are active and which are just place holders. Is this about right or am I missing something important about channels[]? Thanks for your time Chris From hlein at progressive-comp.com Thu Jun 21 03:28:18 2007 From: hlein at progressive-comp.com (Hank Leininger) Date: Wed, 20 Jun 2007 13:28:18 -0400 (EDT) Subject: "Include" directive in ~/.ssh/config Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like an 'Include' directive or similar for ssh client config files. My ~/.ssh/config file is larger than I would like, 147 Host stanzas currently (and I doubt I set any record there). I have some networks/hosts I access via some pretty complex setups (port-fwded SSH via intermediate hosts, multiple port-fwds for various applications, or just hosts where my username isn't the default or I use an alternate Identity file, etc). And several others, coworkers etc have similar, overlapping needs. I would like to group these logically into 'labname.conf', 'clientname.conf', 'localnet.conf', etc files, and my ~/.ssh/config file could be consolidated with a few: Include localoverrides.conf Include labname.conf Include clientname.conf Include localnet.conf ...or whatever. Then we can share / track via CVS or whatever these .conf files, and not have to muck around with maintaining large, clutter-prone ~/.ssh/config files. An obvious alternative is to build a consolidated ~/.ssh/config file from these individual bits using a perl script, Makefile, etc. Has anybody else got similar needs, and if so have you already solved them with either a patch to openssh, or the script approach? Thanks, Hank Leininger D639 2E70 96A4 96D4 9AB6 95D6 A8FD BA7C 7093 F8F3 -----BEGIN PGP SIGNATURE----- iD8DBQFGeWOyqP26fHCT+PMRAiKeAJ9x17KSabcEX/4cVJOqWHaKwy6REwCcDl+E 1mr7QpKwVdTXYDfkg3eQzoo= =j0ie -----END PGP SIGNATURE----- From stuge-openssh-unix-dev at cdy.org Thu Jun 21 06:32:56 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 20 Jun 2007 22:32:56 +0200 Subject: "Include" directive in ~/.ssh/config In-Reply-To: References: Message-ID: <20070620203256.7083.qmail@cdy.org> On Wed, Jun 20, 2007 at 01:28:18PM -0400, Hank Leininger wrote: > An obvious alternative is to build a consolidated ~/.ssh/config > file from these individual bits using a perl script, Makefile, etc. Or perhaps /etc/ssh/ssh_config if the settings are generic enough to be shared by all? //Peter From babic.domagoj at gmail.com Thu Jun 21 04:06:31 2007 From: babic.domagoj at gmail.com (Domagoj Babic) Date: Wed, 20 Jun 2007 11:06:31 -0700 Subject: NULL ptr dereferences found with Calysto static checker Message-ID: Hi, I've ran my static checker Calysto on openssh and found the following bug: Possible NULL-ptr deref (vc536): @/work/benchmarks/SOURCES/openssh-4.6p1/moduli.c:173 + ptr gtm returned from gmtime dereferenced without checking (gmtime can return NULL). There are probably more possible NULL-ptr dereferences, but Calysto currently does not check the usage of library functions (for instance, if external library function foo dereferences a pointer, Calysto can't figure that out unless the code for foo was compiled into the same module). Specification of external libraries will be done by early Aug. Regards, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/ From stuge-openssh-unix-dev at cdy.org Thu Jun 21 09:06:38 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 21 Jun 2007 01:06:38 +0200 Subject: patch for triggering SFTP process_write In-Reply-To: <4675E456.3060404@gmail.com> References: <4675E456.3060404@gmail.com> Message-ID: <20070620230638.31749.qmail@cdy.org> On Mon, Jun 18, 2007 at 03:48:06AM +0200, valerio balbi wrote: > My company, for many bureaucratic reasons, was interested in > triggering each uploaded file to the server using sftp subsystem. I would suggest using a more general approach, such as inotify in Linux or the equivalent in your system. //Peter From gert at greenie.muc.de Thu Jun 21 16:32:13 2007 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 21 Jun 2007 08:32:13 +0200 Subject: NULL ptr dereferences found with Calysto static checker In-Reply-To: References: Message-ID: <20070621063213.GC12600@greenie.muc.de> Hi, On Wed, Jun 20, 2007 at 11:06:31AM -0700, Domagoj Babic wrote: > I've ran my static checker Calysto on openssh and found the following bug: > > Possible NULL-ptr deref (vc536): > @/work/benchmarks/SOURCES/openssh-4.6p1/moduli.c:173 > + ptr gtm returned from gmtime dereferenced without checking (gmtime can > return NULL). Now this surprises me a bit - I've checked FreeBSD 4 and 6 man pages, and neither mentions that the return ptr could be NULL. Checking older SVR3 man pages, I can see the reason: --------------- quote --------------- Note The return values for ctime, localtime and gmtime point to static data whose content is overwritten by each call. --------------- quote --------------- So under which circumstances can it be NULL? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From gert at greenie.muc.de Thu Jun 21 19:58:07 2007 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 21 Jun 2007 11:58:07 +0200 Subject: NULL ptr dereferences found with Calysto static checker In-Reply-To: References: <20070621063213.GC12600@greenie.muc.de> Message-ID: <20070621095807.GE12600@greenie.muc.de> Hi, On Wed, Jun 20, 2007 at 11:47:59PM -0700, Domagoj Babic wrote: > Please see > > localtime/gmtime in > http://www.gnu.org/software/libc/manual/html_mono/libc.html.gz Indeed, on GNU systems, this can happen: "The return value is the null pointer if time cannot be represented as a broken-down time; typically this is because the year cannot fit into an int." - so, OpenSSH will break in the year 4294967297. Damn. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From babic.domagoj at gmail.com Thu Jun 21 16:47:59 2007 From: babic.domagoj at gmail.com (Domagoj Babic) Date: Wed, 20 Jun 2007 23:47:59 -0700 Subject: NULL ptr dereferences found with Calysto static checker In-Reply-To: <20070621063213.GC12600@greenie.muc.de> References: <20070621063213.GC12600@greenie.muc.de> Message-ID: Please see localtime/gmtime in http://www.gnu.org/software/libc/manual/html_mono/libc.html.gz On 6/20/07, Gert Doering wrote: > Hi, > > On Wed, Jun 20, 2007 at 11:06:31AM -0700, Domagoj Babic wrote: > > I've ran my static checker Calysto on openssh and found the following bug: > > > > Possible NULL-ptr deref (vc536): > > @/work/benchmarks/SOURCES/openssh-4.6p1/moduli.c:173 > > + ptr gtm returned from gmtime dereferenced without checking (gmtime can > > return NULL). > > Now this surprises me a bit - I've checked FreeBSD 4 and 6 man pages, > and neither mentions that the return ptr could be NULL. > > Checking older SVR3 man pages, I can see the reason: > > --------------- quote --------------- > Note > > The return values for ctime, localtime and gmtime point to static data > whose content is overwritten by each call. > --------------- quote --------------- > > So under which circumstances can it be NULL? > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de > -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/ From valerio.balbi at gmail.com Thu Jun 21 20:02:25 2007 From: valerio.balbi at gmail.com (valerio balbi) Date: Thu, 21 Jun 2007 12:02:25 +0200 Subject: patch for triggering SFTP process_write Message-ID: >Peter wrote: >I would suggest using a more general approach, such as inotify in >Linux or the equivalent in your system. Thank's for the suggestion! I don't know inotify before... After a first overview to the documentation I confirm my opinion. It seems easier indicate the script to trigger on write directly into sftp-server. It seems strategic to notifiy the error to the sender directly into the sftp session. NOK if put or trigger fails OK only if put and trigger ok Valerio From babic.domagoj at gmail.com Fri Jun 22 01:33:37 2007 From: babic.domagoj at gmail.com (Domagoj Babic) Date: Thu, 21 Jun 2007 08:33:37 -0700 Subject: NULL ptr dereferences found with Calysto static checker In-Reply-To: <20070621095807.GE12600@greenie.muc.de> References: <20070621063213.GC12600@greenie.muc.de> <20070621095807.GE12600@greenie.muc.de> Message-ID: Hi, On 6/21/07, Gert Doering wrote: > "The return value is the null pointer if time cannot be represented as a > broken-down time; typically this is because the year cannot fit into an int." > > - so, OpenSSH will break in the year 4294967297. Damn. It says 'typically', so, there are probably also other conditions under which that can happen. One way or another, it shouldn't be dereferenced directly without checking. Most high-quality open source projects I've analyzed so far check the result of localtime/gmtime. However, if community strongly feels that this should not be reported as a bug, it's really trivial to tell that to Calysto. Regards, -- Domagoj Babic http://www.domagoj.info/ From masmitty at us.ibm.com Fri Jun 22 02:12:06 2007 From: masmitty at us.ibm.com (Mark G Smith) Date: Thu, 21 Jun 2007 12:12:06 -0400 Subject: OpenSSH_4.3p2 on AIX ssh-agent does not work Message-ID: After installing this OpenSSH build on our AIX v5.2 systems, some users started complaining that their logins failed. We are using the binary build "OpenSSH 4.3p2-r2 for AIX 5.2" posted on http://sourceforge.net/projects/openssh-aix/ Digging deeper, we find that these failing users have their clients configured to use ssh-agent. this appears in the syslog at the time of their attempted login ..... Jun 21 15:57:11 gt0405a sshd[31906]: Accepted password for marks from 68.48.192.132 port 2489 ssh2 Jun 21 15:57:12 gt0405a sshd[45470]: Disconnecting: bind: A system call received a parameter that is not valid. Running "sshd -d" was not very informative, but actually printed the same errno results. When reconfiguring each client for login WITHOUT ssh-agent, logins are once again successfull, & all is well as peace reigns once again in the valley. However, our ssh-agent users are VERY loyal & they want their ssh-agent working again in their part of the valley! How can we fix this? Please advise. -mark- --------------------------------------------- -=<{ Mark Geoffrey Smith }>=- IBM Special Events Web Hosting mailto:masmitty at us.ibm.com (301) 390-6295 home/office From imorgan at nas.nasa.gov Fri Jun 22 07:06:41 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 21 Jun 2007 14:06:41 -0700 Subject: OpenSSH_4.3p2 on AIX ssh-agent does not work In-Reply-To: References: Message-ID: <20070621210641.GA32217@linux55.nas.nasa.gov> On Thu, Jun 21, 2007 at 12:12:06 -0400, Mark G Smith wrote: > > > After installing this OpenSSH build on our AIX v5.2 systems, some users > started complaining that their logins failed. > We are using the binary build "OpenSSH 4.3p2-r2 for AIX 5.2" posted on > http://sourceforge.net/projects/openssh-aix/ > > Digging deeper, we find that these failing users have their clients > configured to use ssh-agent. > this appears in the syslog at the time of their attempted login ..... > Jun 21 15:57:11 gt0405a sshd[31906]: Accepted password for marks from > 68.48.192.132 port 2489 ssh2 > Jun 21 15:57:12 gt0405a sshd[45470]: Disconnecting: bind: A system call > received a parameter that is not valid. > > Running "sshd -d" was not very informative, but actually printed the same > errno results. > > When reconfiguring each client for login WITHOUT ssh-agent, logins are once > again successfull, & all is well as peace reigns once again in the valley. > However, our ssh-agent users are VERY loyal & they want their ssh-agent > working again in their part of the valley! > > How can we fix this? > Please advise. > -mark- > > What is the version of the ssh client? -- Iain Morgan From wmertens at cisco.com Fri Jun 22 20:34:42 2007 From: wmertens at cisco.com (Wout Mertens) Date: Fri, 22 Jun 2007 12:34:42 +0200 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: References: Message-ID: And here's the attachment : -------------- next part -------------- Wout. From wmertens at cisco.com Fri Jun 22 20:33:35 2007 From: wmertens at cisco.com (Wout Mertens) Date: Fri, 22 Jun 2007 12:33:35 +0200 Subject: RFE: idle timeout/auto-daemonize combo Message-ID: Hi there, I would like to have SSH connections be more "sudo-like". With that I mean, when I ssh/scp/sftp to a host and disconnect, the channel is held open for a while in case I reconnect. I wrote a script (attached) that does this. It starts a master SSH daemon for the connection if needed. Then it exec()s SSH. Just put it in your path and use perssh instead of ssh. It has some disadvantages though, like not killing the daemon after an idle timeout, and failed SSH connects if the master quits when the network changes. There's plenty of corner cases in the script to make it unusable as a generic SSH wrapper. So my first RFE is an option for idle timeout, closing the connection when no traffic has passed through for a while. My second RFE is to make the script unnecessary, having an option to automatically create a daemonized master on first connect. Thoughts? Many thanks, Wout. From bwooster47 at gmail.com Sun Jun 24 23:05:09 2007 From: bwooster47 at gmail.com (B Wooster) Date: Sun, 24 Jun 2007 09:05:09 -0400 Subject: IdleTimeout patch did not get in? Message-ID: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> Doing a search in the list archives, I see that in 2001/2002 there was a patch made available for IdleTimeout keyword, for example: http://marc.info/?l=openssh-unix-dev&m=99838019319356&w=2 Looks like that patch did not make it in the following versions of OpenSSH - is there a reason why - any chance of the patch getting back in? I do know about ClientInterval, but I think I need IdleTimeout. The specific circumstance is that I've a SSH2 session from a laptop (PuTTY) to a OpenSSH server. When the laptop goes into standby or hibernates, and then is re-started after around 8 hours, the SSH session gets a network disconnect error". Since hibernate implies the client and the network connection is dormant, I am wondering if the IdleTimeout might help (maybe not?) If anyone has any other options that would allow an server to not disconnect a client even the connection is dormant - or maybe this is not possible? - let me know! Hate having to re-connect every 8 hours! From dtucker at zip.com.au Mon Jun 25 00:13:14 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 Jun 2007 00:13:14 +1000 Subject: IdleTimeout patch did not get in? In-Reply-To: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> Message-ID: <20070624141314.GA15607@gate.dtucker.net> On Sun, Jun 24, 2007 at 09:05:09AM -0400, B Wooster wrote: > Doing a search in the list archives, I see that in 2001/2002 there was > a patch made available for IdleTimeout keyword, for example: > http://marc.info/?l=openssh-unix-dev&m=99838019319356&w=2 > > Looks like that patch did not make it in the following versions of > OpenSSH - is there a reason why - any chance of the patch getting > back in? > > I do know about ClientInterval, but I think I need IdleTimeout. I don't see why, it looks to do pretty much the same thing and you can get the same effect by setting ClientAliveInterval to a large value and ClientAliveCountMax to 1. > The specific circumstance is that I've a SSH2 session from a laptop > (PuTTY) to a OpenSSH server. > > When the laptop goes into standby or hibernates, and then is > re-started after around 8 hours, the SSH session gets a network > disconnect error". Since hibernate implies the client and the network > connection is dormant, I am wondering if the IdleTimeout might help > (maybe not?) > If anyone has any other options that would allow an server to not > disconnect a client even the connection is dormant - or maybe this is > not possible? - let me know! > Hate having to re-connect every 8 hours! What you need to do is remove all keepalives. The problem is that as soon as the server generates any traffic (be that ClientAlive* or TCPKeepAlive) then TCP guarantees that that the data will get to the other end or the application will be notified. Keepalives just guarantee that the (apparent) connection failure will be detected and your connection will be killed when the client becomes unresponsive. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Mon Jun 25 02:11:44 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 24 Jun 2007 18:11:44 +0200 Subject: IdleTimeout patch did not get in? In-Reply-To: <20070624141314.GA15607@gate.dtucker.net> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> <20070624141314.GA15607@gate.dtucker.net> Message-ID: <20070624161144.12514.qmail@cdy.org> On Mon, Jun 25, 2007 at 12:13:14AM +1000, Darren Tucker wrote: > > Hate having to re-connect every 8 hours! > > What you need to do is remove all keepalives. Also I've noticed that Windows tends to kill all TCP connections when the physical link goes down, regardless of whether there is any traffic passing over it or not. Might be worth looking into. //Peter From bwooster47 at gmail.com Mon Jun 25 02:54:27 2007 From: bwooster47 at gmail.com (B Wooster) Date: Sun, 24 Jun 2007 12:54:27 -0400 Subject: IdleTimeout patch did not get in? In-Reply-To: <20070624141314.GA15607@gate.dtucker.net> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> <20070624141314.GA15607@gate.dtucker.net> Message-ID: <204abd770706240954s6d2a4844u13ee1b6f61984a7e@mail.gmail.com> On 6/24/07, Darren Tucker wrote: > On Sun, Jun 24, 2007 at 09:05:09AM -0400, B Wooster wrote: > > I do know about ClientInterval, but I think I need IdleTimeout. > > I don't see why, it looks to do pretty much the same thing and you > can get the same effect by setting ClientAliveInterval to a large > value and ClientAliveCountMax to 1. > ... > > When the laptop goes into standby or hibernates, and then is > > re-started after around 8 hours, the SSH session gets a network ... > What you need to do is remove all keepalives. The problem is that as soon > as the server generates any traffic (be that ClientAlive* or TCPKeepAlive) > then TCP guarantees that that the data will get to the other end or > the application will be notified. Keepalives just guarantee that the > (apparent) connection failure will be detected and your connection will > be killed when the client becomes unresponsive. Thanks - I'll test this out - need 8 hours to test! ClientAliveInterval was set to 0, so that was correct. TCPKeepAlive was set to yes - I've set it to no, and re-started server and re-connected, let's see what happens tomorrow. Anyone know at what interval does the OpenSSH server send the TCPKeepAlive? It is larger than 30 minutes - I sent my machine into standby for 30 minutes, and after waking up, I still had the connection (this was before I changed TCPKeepAlive to no). As for Windows keepalive, yes, there are some registry settings that define that - but I am assuming that should not apply - since the machine has gone to sleep, no keepalives are sent or checked - applications like my AIM messenger (pidgin) don't get a loss of connection. All this should be confirmed tomorrow. From dtucker at zip.com.au Mon Jun 25 07:40:02 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 Jun 2007 07:40:02 +1000 Subject: IdleTimeout patch did not get in? In-Reply-To: <20070624161144.12514.qmail@cdy.org> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> <20070624141314.GA15607@gate.dtucker.net> <20070624161144.12514.qmail@cdy.org> Message-ID: <20070624214002.GA22466@gate.dtucker.net> On Sun, Jun 24, 2007 at 06:11:44PM +0200, Peter Stuge wrote: > On Mon, Jun 25, 2007 at 12:13:14AM +1000, Darren Tucker wrote: > > > Hate having to re-connect every 8 hours! > > > > What you need to do is remove all keepalives. > > Also I've noticed that Windows tends to kill all TCP connections when > the physical link goes down, regardless of whether there is any > traffic passing over it or not. Might be worth looking into. Also when a DHCP lease is renewed, typically when half of the lease time has elapsed. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Jun 25 07:48:05 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 Jun 2007 07:48:05 +1000 Subject: IdleTimeout patch did not get in? In-Reply-To: <204abd770706240954s6d2a4844u13ee1b6f61984a7e@mail.gmail.com> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> <20070624141314.GA15607@gate.dtucker.net> <204abd770706240954s6d2a4844u13ee1b6f61984a7e@mail.gmail.com> Message-ID: <20070624214805.GC22466@gate.dtucker.net> On Sun, Jun 24, 2007 at 12:54:27PM -0400, B Wooster wrote: > On 6/24/07, Darren Tucker wrote: [...] > > What you need to do is remove all keepalives. The problem is that as soon > > as the server generates any traffic (be that ClientAlive* or TCPKeepAlive) > > then TCP guarantees that that the data will get to the other end or > > the application will be notified. Keepalives just guarantee that the > > (apparent) connection failure will be detected and your connection will > > be killed when the client becomes unresponsive. > > Thanks - I'll test this out - need 8 hours to test! > ClientAliveInterval was set to 0, so that was correct. > TCPKeepAlive was set to yes - I've set it to no, and re-started server > and re-connected, let's see what happens tomorrow. > Anyone know at what interval does the OpenSSH server send the > TCPKeepAlive? It is larger than 30 minutes - I sent my machine into > standby for 30 minutes, and after waking up, I still had the > connection (this was before I changed TCPKeepAlive to no). Normally TCP keepalives are enabled or disabled on a per-connection basis, but the keepalive timer is system-wide. On many systems the default value is 2 hours. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bwooster47 at gmail.com Mon Jun 25 20:47:50 2007 From: bwooster47 at gmail.com (B Wooster) Date: Mon, 25 Jun 2007 06:47:50 -0400 Subject: IdleTimeout patch did not get in? In-Reply-To: <20070624214805.GC22466@gate.dtucker.net> References: <204abd770706240605i23415262j5c32756bf295046b@mail.gmail.com> <20070624141314.GA15607@gate.dtucker.net> <204abd770706240954s6d2a4844u13ee1b6f61984a7e@mail.gmail.com> <20070624214805.GC22466@gate.dtucker.net> Message-ID: <204abd770706250347p6714f676o820c67392d815728@mail.gmail.com> On 6/24/07, Darren Tucker wrote: > On Sun, Jun 24, 2007 at 12:54:27PM -0400, B Wooster wrote: > > On 6/24/07, Darren Tucker wrote: > [...] > > > What you need to do is remove all keepalives. The problem is that as soon .... > > Thanks - I'll test this out - need 8 hours to test! > > ClientAliveInterval was set to 0, so that was correct. > > TCPKeepAlive was set to yes - I've set it to no, and re-started server No luck - on coming back from standby, after 8 hours, get the "Network error: software caused abort" type of message. So I presume it must be something on the Windows side that is causing this, not a OpenSSH issue. For now, I've minimized the trouble of re-connecting by using public key authentication, so don't have to manually enter username and password each time I reconnect. From wmertens at cisco.com Mon Jun 25 21:18:23 2007 From: wmertens at cisco.com (Wout Mertens) Date: Mon, 25 Jun 2007 13:18:23 +0200 Subject: IdleTimeout patch did not get in? Message-ID: <3C783D47-4D36-4803-A752-5F164B50ECC7@cisco.com> Darren Tucker wrote: > On Sun, Jun 24, 2007 at 09:05:09AM -0400, B Wooster wrote: > > Doing a search in the list archives, I see that in 2001/2002 > there was > > a patch made available for IdleTimeout keyword, for example: > > http://marc.info/?l=openssh-unix-dev&m=99838019319356&w=2 > > > > Looks like that patch did not make it in the following versions of > > OpenSSH - is there a reason why - any chance of the patch getting > > back in? > > > > I do know about ClientInterval, but I think I need IdleTimeout. > > I don't see why, it looks to do pretty much the same thing and you > can get the same effect by setting ClientAliveInterval to a large > value and ClientAliveCountMax to 1. It's not the same effect at all - IdleTimeout means disconnecting the channel when no messages have been sent for a while. ClientInterval means disconnecting the channel when the client is no longer available. With IdleTimeout, you can create "ssh -MNf" deamonized connections that automatically time out when you're no longer using them. Great for scripting things and speeding things up in general. Is there any chance of IdleTimeout making it into the source? Wout. From the.omprakash at gmail.com Mon Jun 25 21:55:13 2007 From: the.omprakash at gmail.com (om prakash) Date: Mon, 25 Jun 2007 17:25:13 +0530 Subject: No subject Message-ID: