From Thomas.Spence at pentagon.af.mil Tue Feb 1 02:59:46 2011 From: Thomas.Spence at pentagon.af.mil (Spence, Thomas CIV 844 CS/SCOX) Date: Mon, 31 Jan 2011 10:59:46 -0500 Subject: Openssh 5.7p1 Message-ID: Hello everyone... This is my FIRST time... I am using GCC 4.3.5 on AIX 5.3... I compiled with openssh but got the error messages. Here is: gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/lib -Wl,-blibpath:/usr/lib:/lib -lssh -lopenbsd-compat -lcrypto -lz ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2427) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2430) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2688) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2691) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2718) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2721) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2724) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2727) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2730) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2733) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2736) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2739) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2742) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2745) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2748) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2751) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2754) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2757) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 735) in object sshtty.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1004) in object roaming_common.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1007) in object roaming_common.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1283) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1286) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1289) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1292) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1295) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1298) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1301) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2930) in object ./libssh.a[channels.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 710) in object ./libssh.a[cipher-acss.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 777) in object ./libssh.a[cipher-acss.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 753) in object ./libssh.a[cipher-bf1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 778) in object ./libssh.a[cipher-bf1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 728) in object ./libssh.a[cipher-ctr.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 820) in object ./libssh.a[cipher-ctr.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 732) in object ./libssh.a[cipher-3des1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 825) in object ./libssh.a[cipher-3des1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 932) in object ./libssh.a[hostfile.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1164) in object ./libssh.a[hostfile.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 920) in object ./libssh.a[log.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2998) in object ./libssh.a[packet.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 3001) in object ./libssh.a[packet.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 791) in object ./libssh.a[mac.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 886) in object ./libssh.a[mac.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 767) in object ./libssh.a[kexdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 790) in object ./libssh.a[kexdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 771) in object ./libssh.a[kexgex.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 795) in object ./libssh.a[kexgex.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 782) in object ./libssh.a[kexecdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 845) in object ./libssh.a[kexecdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 790) in object openbsd-compat//libopenbsd-compat.a[bsd-arc4random.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 772) in object openbsd-compat//libopenbsd-compat.a[readpassphrase.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. collect2: ld returned 12 exit status make: *** [ssh] Error 1 --------------- Tom Spence ABIDES SYSTEM SUPPORT 844th CS/SCOX From postgres at sabes.net Tue Feb 1 04:51:59 2011 From: postgres at sabes.net (M Sabin) Date: Mon, 31 Jan 2011 12:51:59 -0500 Subject: Openssh 5.7p1 FIPS patch Message-ID: I was wondering if anyone has built a FIPS patch for the 5.7p1 version of OpenSSH. Thanks M. Sabin From mike at pair.com Tue Feb 1 07:30:19 2011 From: mike at pair.com (Mike Kelly) Date: Mon, 31 Jan 2011 15:30:19 -0500 Subject: Questions about ChrootDirectory In-Reply-To: <20110117104058.3eb9dde4@pit84.pair.com> References: <20110117104058.3eb9dde4@pit84.pair.com> Message-ID: <20110131153019.5bf70811@pit84.pair.com> My apologizes if I'm asking on the wrong list, but where might be the right place to find answers to my questions? On Mon, 17 Jan 2011 10:40:58 -0500 Mike Kelly wrote: > Hello, > > I'm aware of the fact that ChrootDirectory requires that the target > directory is root-owned, and I think I've mostly understood why that > is necessary, at least within the context of someone who has full > shell access. However, I am wondering if that possibility for > privilege escalation still exists with a configuration like this: > > Match Group sftp > ForceCommand internal-sftp > ChrootDirectory %h > > Assuming some patch were applied to openssh to allow ChrootDirectory > to work here on a non-root-owned home directory, wouldn't this mean > that any user in the sftp group would only be able to manipulate files > within their home directory, and nothing else? Is there some potential > for privilege escalation or execution of commands that I've missed? > > And, just to confirm, am I correct in understanding that scp will not > work with this configuration, since scp wants a shell? > > Thanks. > -- Mike Kelly From dtucker at zip.com.au Tue Feb 1 09:39:17 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 01 Feb 2011 09:39:17 +1100 Subject: Openssh 5.7p1 In-Reply-To: References: Message-ID: <4D473A15.7020908@zip.com.au> On 1/02/11 2:59 AM, Spence, Thomas CIV 844 CS/SCOX wrote: > This is my FIRST time... I am using GCC 4.3.5 on AIX 5.3... I > compiled with openssh but got the error messages. Here is: > > gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/lib -Wl,-blibpath:/usr/lib:/lib -lssh -lopenbsd-compat -lcrypto -lz > ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2427) in object clientloop.o: > The symbol refers to a csect with symbol number 0, which was not > found. The new symbol cannot be associated with a csect and > is being ignored. I've never seen it, but after some digging this seems to be a bug/interaction between GCC and the AIX linker: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 The problem seems to be triggered by static variables without explicit initializers. -- 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 Tue Feb 1 09:52:03 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 01 Feb 2011 09:52:03 +1100 Subject: Openssh 5.7p1 In-Reply-To: <4D473A15.7020908@zip.com.au> References: <4D473A15.7020908@zip.com.au> Message-ID: <4D473D13.2010607@zip.com.au> On 1/02/11 9:39 AM, Darren Tucker wrote: > On 1/02/11 2:59 AM, Spence, Thomas CIV 844 CS/SCOX wrote: >> This is my FIRST time... I am using GCC 4.3.5 on AIX 5.3... I >> compiled with openssh but got the error messages. Here is: >> >> gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o >> sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o >> -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/lib >> -Wl,-blibpath:/usr/lib:/lib -lssh -lopenbsd-compat -lcrypto -lz >> ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2427) in object >> clientloop.o: >> The symbol refers to a csect with symbol number 0, which was not >> found. The new symbol cannot be associated with a csect and >> is being ignored. > > I've never seen it, but after some digging this seems to be a > bug/interaction between GCC and the AIX linker: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 > > The problem seems to be triggered by static variables without explicit > initializers. Reading it a bit more, it seems to only happen on debug builds, so one possible workaround would be to disable debug symbols in OpenSSH: $ CFLAGS="-O2" ../../configure && make -- 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 djm at mindrot.org Tue Feb 1 10:27:42 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2011 10:27:42 +1100 (EST) Subject: [PATCH] fix copy'n'paste error in PROTOCOL.mux In-Reply-To: <3f0bbca1f844d62087c958a2ef84aea6a5bcb752.1296460738.git.bert.wesarg@googlemail.com> References: <3f0bbca1f844d62087c958a2ef84aea6a5bcb752.1296460738.git.bert.wesarg@googlemail.com> Message-ID: applied - thanks On Mon, 31 Jan 2011, Bert Wesarg wrote: > --- > PROTOCOL.mux | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/PROTOCOL.mux b/PROTOCOL.mux > index 3d6f818..88f95b3 100644 > --- a/PROTOCOL.mux > +++ b/PROTOCOL.mux > @@ -122,7 +122,7 @@ For dynamically allocated listen port the server replies with > > Note: currently unimplemented (server will always reply with MUX_S_FAILURE). > > -A client may request the master to establish a port forward: > +A client may request the master to close a port forward: > > uint32 MUX_C_CLOSE_FWD > uint32 request id > -- > 1.7.3.3.1603.g7f137 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Tue Feb 1 10:29:20 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2011 10:29:20 +1100 (EST) Subject: Questions about ChrootDirectory In-Reply-To: <20110131153019.5bf70811@pit84.pair.com> References: <20110117104058.3eb9dde4@pit84.pair.com> <20110131153019.5bf70811@pit84.pair.com> Message-ID: the considerations relating to root-ownership of the chrootdirectory have been discussed quite extensively on this list before, please check the archives. On Mon, 31 Jan 2011, Mike Kelly wrote: > My apologizes if I'm asking on the wrong list, but where might be the > right place to find answers to my questions? > > On Mon, 17 Jan 2011 10:40:58 -0500 > Mike Kelly wrote: > > > Hello, > > > > I'm aware of the fact that ChrootDirectory requires that the target > > directory is root-owned, and I think I've mostly understood why that > > is necessary, at least within the context of someone who has full > > shell access. However, I am wondering if that possibility for > > privilege escalation still exists with a configuration like this: > > > > Match Group sftp > > ForceCommand internal-sftp > > ChrootDirectory %h > > > > Assuming some patch were applied to openssh to allow ChrootDirectory > > to work here on a non-root-owned home directory, wouldn't this mean > > that any user in the sftp group would only be able to manipulate files > > within their home directory, and nothing else? Is there some potential > > for privilege escalation or execution of commands that I've missed? > > > > And, just to confirm, am I correct in understanding that scp will not > > work with this configuration, since scp wants a shell? > > > > Thanks. > > > > > > -- > Mike Kelly > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From vinschen at redhat.com Tue Feb 1 19:56:25 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 1 Feb 2011 09:56:25 +0100 Subject: Generate SSH1 host key by default? In-Reply-To: <4D46A58E.4050800@zip.com.au> References: <20110131105405.GA6215@calimero.vinschen.de> <4D46A58E.4050800@zip.com.au> Message-ID: <20110201085625.GN1057@calimero.vinschen.de> On Jan 31 23:05, Darren Tucker wrote: > On 31/01/2011 9:54 PM, Corinna Vinschen wrote: > >the OpenSSH installation script for Cygwin still creates a SSH1 host key > >by default. > > > >My question is, wouldn't it make more sense to drop all auto-generation > >of SSH1 keys from the default installation procedure? I mean, nobody > >should use SSH1 anymore, right? Or should the script stick to it for > >some reason? > > Although the server now defaults to not enabling SSH1 for new > installs (and has for a couple of releases) the client could > conceivably need an SSH1 key, eg for RhostsRSAAuthentication. The > admin could also enable Protocol 1 in the server (although it might > be reasonable to give them the responsibility of creating the key in > that case). Ok, so I keep the SSH1 keys generation in. Would you mind to apply the below patch? It adds ECDSA key generation for host and user and simplifies the ssh-user-config script. Thanks, Corinna Index: contrib/cygwin//ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.29 diff -u -p -r1.29 ssh-host-config --- contrib/cygwin//ssh-host-config 24 Mar 2010 02:03:32 -0000 1.29 +++ contrib/cygwin//ssh-host-config 1 Feb 2011 08:55:59 -0000 @@ -63,6 +63,12 @@ create_host_keys() { csih_inform "Generating ${SYSCONFDIR}/ssh_host_dsa_key" ssh-keygen -t dsa -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null fi + + if [ ! -f "${SYSCONFDIR}/ssh_host_ecdsa_key" ] + then + csih_inform "Generating ${SYSCONFDIR}/ssh_host_ecdsa_key" + ssh-keygen -t ecdsa -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null + fi } # --- End of create_host_keys --- # # ====================================================================== Index: contrib/cygwin//ssh-user-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-user-config,v retrieving revision 1.7 diff -u -p -r1.7 ssh-user-config --- contrib/cygwin//ssh-user-config 29 Jul 2009 14:21:13 -0000 1.7 +++ contrib/cygwin//ssh-user-config 1 Feb 2011 08:55:59 -0000 @@ -39,85 +39,34 @@ pwdhome= with_passphrase= # ====================================================================== -# Routine: create_ssh1_identity -# optionally create ~/.ssh/identity[.pub] +# Routine: create_identity +# optionally create identity of type argument in ~/.ssh # optionally add result to ~/.ssh/authorized_keys # ====================================================================== -create_ssh1_identity() { - if [ ! -f "${pwdhome}/.ssh/identity" ] +create_identity() { + local file="$1" + local type="$2" + local name="$3" + if [ ! -f "${pwdhome}/.ssh/${file}" ] then - if csih_request "Shall I create an SSH1 RSA identity file for you?" + if csih_request "Shall I create a ${name} identity file for you?" then - csih_inform "Generating ${pwdhome}/.ssh/identity" + csih_inform "Generating ${pwdhome}/.ssh/${file}" if [ "${with_passphrase}" = "yes" ] then - ssh-keygen -t rsa1 -N "${passphrase}" -f "${pwdhome}/.ssh/identity" > /dev/null + ssh-keygen -t "${type}" -N "${passphrase}" -f "${pwdhome}/.ssh/${file}" > /dev/null else - ssh-keygen -t rsa1 -f "${pwdhome}/.ssh/identity" > /dev/null + ssh-keygen -t "${type}" -f "${pwdhome}/.ssh/${file}" > /dev/null fi if csih_request "Do you want to use this identity to login to this machine?" then csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" - cat "${pwdhome}/.ssh/identity.pub" >> "${pwdhome}/.ssh/authorized_keys" + cat "${pwdhome}/.ssh/${file}.pub" >> "${pwdhome}/.ssh/authorized_keys" fi fi fi } # === End of create_ssh1_identity() === # -readonly -f create_ssh1_identity - -# ====================================================================== -# Routine: create_ssh2_rsa_identity -# optionally create ~/.ssh/id_rsa[.pub] -# optionally add result to ~/.ssh/authorized_keys -# ====================================================================== -create_ssh2_rsa_identity() { - if [ ! -f "${pwdhome}/.ssh/id_rsa" ] - then - if csih_request "Shall I create an SSH2 RSA identity file for you?" - then - csih_inform "Generating ${pwdhome}/.ssh/id_rsa" - if [ "${with_passphrase}" = "yes" ] - then - ssh-keygen -t rsa -N "${passphrase}" -f "${pwdhome}/.ssh/id_rsa" > /dev/null - else - ssh-keygen -t rsa -f "${pwdhome}/.ssh/id_rsa" > /dev/null - fi - if csih_request "Do you want to use this identity to login to this machine?" - then - csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" - cat "${pwdhome}/.ssh/id_rsa.pub" >> "${pwdhome}/.ssh/authorized_keys" - fi - fi - fi -} # === End of create_ssh2_rsa_identity() === # -readonly -f create_ssh2_rsa_identity - -# ====================================================================== -# Routine: create_ssh2_dsa_identity -# optionally create ~/.ssh/id_dsa[.pub] -# optionally add result to ~/.ssh/authorized_keys -# ====================================================================== -create_ssh2_dsa_identity() { - if [ ! -f "${pwdhome}/.ssh/id_dsa" ] - then - if csih_request "Shall I create an SSH2 DSA identity file for you?" - then - csih_inform "Generating ${pwdhome}/.ssh/id_dsa" - if [ "${with_passphrase}" = "yes" ] - then - ssh-keygen -t dsa -N "${passphrase}" -f "${pwdhome}/.ssh/id_dsa" > /dev/null - else - ssh-keygen -t dsa -f "${pwdhome}/.ssh/id_dsa" > /dev/null - fi - if csih_request "Do you want to use this identity to login to this machine?" - then - csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" - cat "${pwdhome}/.ssh/id_dsa.pub" >> "${pwdhome}/.ssh/authorized_keys" - fi - fi - fi -} # === End of create_ssh2_dsa_identity() === # -readonly -f create_ssh2_dsa_identity +readonly -f create_identity # ====================================================================== # Routine: check_user_homedir @@ -311,9 +260,10 @@ fi check_user_homedir check_user_dot_ssh_dir -create_ssh1_identity -create_ssh2_rsa_identity -create_ssh2_dsa_identity +create_identity id_rsa rsa "SSH2 RSA" +create_identity id_dsa dsa "SSH2 DSA" +create_identity id_ecdsa ecdsa "SSH2 ECDSA" +create_identity identity rsa1 "(deprecated) SSH1 RSA" fix_authorized_keys_perms echo -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From oliver at obeattie.com Tue Feb 1 20:52:36 2011 From: oliver at obeattie.com (Oliver Beattie) Date: Tue, 1 Feb 2011 11:52:36 +0200 Subject: Multiple forced commands being executed Message-ID: Hi, Sorry to post this here again, I already posted it in the users mailing list but haven't got very far. I really need to get this resolved ASAP, as it's causing a big security headache for us. If anyone can help that would be wonderful. The original thread is here: http://marc.info/?l=secure-shell&m=129562817820176&w=2 I am having a very strange problem with SSH. Essentially, I'm using forced commands to restrict access based on public key (there are around 2000 public keys). It appears to work okay, but when I look at the ssh -v output I see that the client/server is actually executing all the forced commands for RSA keys (I am connecting with an RSA key) until it "hits" my key. Anyone have any idea why this is happening? I have no clue where to even look for hints as to what would cause this? Here's an example of the output I am seeing (condensed, the real output is ~3000 lines): OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009 debug1: Authentication succeeded (publickey). debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug1: Remote: Forced command: gitosis-serve osjokine debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. [... hundreds more like this ...] debug1: Remote: Forced command: gitosis-serve obeattie debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. debug1: Remote: Forced command: gitosis-serve osjokine debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. [... hundreds more again ...] debug1: Remote: Forced command: gitosis-serve obeattie debug1: Remote: Port forwarding disabled. debug1: Remote: X11 forwarding disabled. debug1: Remote: Agent forwarding disabled. debug1: Remote: Pty allocation disabled. debug2: callback start ?Oliver From dtucker at zip.com.au Tue Feb 1 21:45:11 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 01 Feb 2011 21:45:11 +1100 Subject: Multiple forced commands being executed In-Reply-To: References: Message-ID: <4D47E437.3010505@zip.com.au> On 1/02/11 8:52 PM, Oliver Beattie wrote: > Hi, > > Sorry to post this here again, I already posted it in the users > mailing list but haven't got very far. I really need to get this > resolved ASAP, as it's causing a big security headache for us. If > anyone can help that would be wonderful. The original thread is here: > http://marc.info/?l=secure-shell&m=129562817820176&w=2 > > I am having a very strange problem with SSH. Essentially, I'm using > forced commands to restrict access based on public key (there are > around 2000 public keys). It appears to work okay, but when I look at > the ssh -v output I see that the client/server is actually executing > all the forced commands for RSA keys (I am connecting with an RSA key) > until it "hits" my key. > > Anyone have any idea why this is happening? I have no clue where to > even look for hints as to what would cause this? Do you actually see the command being executed? Looking at the code, that output is just from the option parser, not the actual execution (in auth-options.c:auth_parse_options()). The forced command that is actually executed gets logged on the server side as "Forced command (key option) " (at loglevel debug and above, in session.c). If you are actually seeing the command executed multiple times, could you please post a small sample of the authorized_keys file (feel free to elide the actual keys). -- 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 oliver at obeattie.com Tue Feb 1 22:08:18 2011 From: oliver at obeattie.com (Oliver Beattie) Date: Tue, 1 Feb 2011 13:08:18 +0200 Subject: Multiple forced commands being executed In-Reply-To: <4D47E437.3010505@zip.com.au> References: <4D47E437.3010505@zip.com.au> Message-ID: Hi Darren, Thanks so much for getting back to me. Yes, you're absolutely right, on the server only the "proper" command gets executed. However, it is a security problem for us to reveal all/many of the usernames that can potentially access these machine(s). Is there some way we can prevent this from being sent to the client? ?Oliver On 1 February 2011 12:45, Darren Tucker wrote: > On 1/02/11 8:52 PM, Oliver Beattie wrote: >> >> Hi, >> >> Sorry to post this here again, I already posted it in the users >> mailing list but haven't got very far. I really need to get this >> resolved ASAP, as it's causing a big security headache for us. If >> anyone can help that would be wonderful. The original thread is here: >> http://marc.info/?l=secure-shell&m=129562817820176&w=2 >> >> I am having a very strange problem with SSH. Essentially, I'm using >> forced commands to restrict access based on public key (there are >> around 2000 public keys). It appears to work okay, but when I look at >> the ssh -v output I see that the client/server is actually executing >> all the forced commands for RSA keys (I am connecting with an RSA key) >> until it "hits" my key. >> >> Anyone have any idea why this is happening? I have no clue where to >> even look for hints as to what would cause this? > > Do you actually see the command being executed? ?Looking at the code, that > output is just from the option parser, not the actual execution (in > auth-options.c:auth_parse_options()). ? The forced command that is actually > executed gets logged on the server side as "Forced command (key option) " > (at loglevel debug and above, in session.c). > > If you are actually seeing the command executed multiple times, could you > please post a small sample of the authorized_keys file (feel free to elide > the actual keys). > > -- > 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 djm at mindrot.org Tue Feb 1 22:34:39 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2011 22:34:39 +1100 (EST) Subject: Multiple forced commands being executed In-Reply-To: References: <4D47E437.3010505@zip.com.au> Message-ID: On Tue, 1 Feb 2011, Oliver Beattie wrote: > Hi Darren, > > Thanks so much for getting back to me. Yes, you're absolutely right, > on the server only the "proper" command gets executed. However, it is > a security problem for us to reveal all/many of the usernames that can > potentially access these machine(s). Is there some way we can prevent > this from being sent to the client? The bug that caused the authorized_keys file to be parsed in this way was fixed in openssh-5.6 (or possibly earlier). You should try the most recent release (5.7) -d From oliver at obeattie.com Tue Feb 1 22:37:35 2011 From: oliver at obeattie.com (Oliver Beattie) Date: Tue, 1 Feb 2011 13:37:35 +0200 Subject: Multiple forced commands being executed In-Reply-To: References: <4D47E437.3010505@zip.com.au> Message-ID: On 1 February 2011 13:34, Damien Miller wrote: > > The bug that caused the authorized_keys file to be parsed in this way > was fixed in openssh-5.6 (or possibly earlier). You should try the most > recent release (5.7) Hmm? we are bound to using Debian packages, I guess it was a little earlier, as we are using the latest in Squeeze which is 5.5: http://packages.debian.org/squeeze/openssh-server I'll see what can be done about upgrading. Thank you for your help in getting to the bottom of this! ?Oliver From djm at mindrot.org Wed Feb 2 10:33:01 2011 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Feb 2011 10:33:01 +1100 (EST) Subject: Multiple forced commands being executed In-Reply-To: References: <4D47E437.3010505@zip.com.au> Message-ID: On Tue, 1 Feb 2011, Oliver Beattie wrote: > On 1 February 2011 13:34, Damien Miller wrote: > > > > The bug that caused the authorized_keys file to be parsed in this way > > was fixed in openssh-5.6 (or possibly earlier). You should try the most > > recent release (5.7) > > Hmm? we are bound to using Debian packages, I guess it was a little > earlier, as we are using the latest in Squeeze which is 5.5: > http://packages.debian.org/squeeze/openssh-server > > I'll see what can be done about upgrading. You might try building the source packages from a more recent Debian distribution, or you can backport the fix itself: http://hg.mindrot.org/openssh/raw-rev/d86d6f9b448a -d From contact at setit.rnu.tn Wed Feb 2 16:24:03 2011 From: contact at setit.rnu.tn (Med Salim BOUHLEL) Date: Wed, 2 Feb 2011 06:24:03 +0100 Subject: Updated information about SETIT 2011 Message-ID: <16861673760734610353@salm-2db062c067> The scientific and organization committees of SETIT have decided to postpone the conference to May 12-15, 2011. So the submission is reopened to February 15th 2011. Updated information about the conference can be found at: http://www.setit.rnu.tn ============================================================================= This email is sent out to all those on the SETIT database. If you want to be removed from this database, please send an email to unsubscribe.setit at gmail.com with subject Unsubscribe. ============================================================================= Mohamed Salim BOUHLEL General Co-Chair, SETIT 2011 Director of the Higher Institute of Electronics and Communication of Sfax Head of Research Unit:Sciences & Technologies of Image and Telecommunications ( Sfax University ) Tel: +216 20 200005 From jhui6124 at rogers.com Thu Feb 3 09:23:35 2011 From: jhui6124 at rogers.com (jhui6124 at rogers.com) Date: Wed, 2 Feb 2011 14:23:35 -0800 (PST) Subject: Porting openssh to Windows natively Message-ID: <489879.11868.qm@web88005.mail.re2.yahoo.com> Hi All, I was assigned a project to port the openssh 5.4p1 to Windows.? There has been discussion about Cygwin and SUA on Windows, but the conclusion is to avoid a unix layer.? So came the project.? I was being assigned not because I am familir with openssh, but because I am a Windows application developer.? BTW, the objective is to have a windows sshd daemon, no client is needed at this stage. To make it short, I have spent a couple of months working on this and at the present stage i can ssh from a unix box using SSH protocol 2 submitting commands, using password authentication.? What I am having trouble is the interactive sessions.? At first I thought the unix side is hung because nothing responds on my telnet terminal ( I am telnetting to the unix box, then test the ssh connection from there).? However, after turning on the PACKET_DEBUG on my ssh server, I realize that every keystroke being pressed at the terminal was sent across the wire.? (Is this what is called by a raw mode?).? and the command was actually received by my WIndows SSHD.? And also, the "enter" keystroke was not recognised by the server as a command submission (CRLF).? I have to explicitly press Ctrl-J to submit the command.? Interesting enough, if I fool the unix ssh client by using "ssh username at hostname.com " "" (an empty command) to force the server side to go through the do_exec_no_pty function, I can actually do what I want interactively if I keep the windows cmd.exe around without exiting.? Even the "enter" key and "local echo" is there.? Can anyone tell what is missing for my interactive session?? Ah, I have to back up a bit about what I did for the interactive session.? Since on windows, there is no concept of tty, instead of allocating a pty, I just created a sockpair to hook up the ptyfd and ttyfd when forking the child from do_exec_pty.? The ttyfd contains one of the socket of the socket pair, and the socket handle was passed? as the stdin/stdout/stderr of the windows cmd shell that is started by the child.? Could that be the reason?? Is the client always working on the raw mode?? Or it detected some setting being sent back from the server which put it into the raw mode? As you can tell I am not a unix developer either.? Thanks for your patience and thanks for any advice in advance. Jack From djm at cvs.openbsd.org Fri Feb 4 12:24:00 2011 From: djm at cvs.openbsd.org (Damien Miller) Date: Thu, 3 Feb 2011 18:24:00 -0700 (MST) Subject: OpenSSH security advisory: legacy certificate signing in 5.6/5.7 Message-ID: <201102040124.p141O0Cp002026@cvs.openbsd.org> OpenSSH Security Advisory: legacy-certs.adv This document may be found at: http://www.openssh.com/txt/legacy-cert.adv 1. Vulnerability Legacy certificates generated by OpenSSH might contain data from the stack thus leaking confidential information. 2. Affected configurations OpenSSH 5.6 and OpenSSH 5.7 only when generating legacy certificates. These must be specifically requested using the "-t" option on the ssh-keygen CA command-line. 3. Mitigation Avoid generating legacy certificates using OpenSSH 5.6 or 5.7 If legacy certificates have been issued with a vulnerable OpenSSH version, consider rotating any CA key used. 4. Details When generating legacy *-cert-v00 at openssh.com certificates, the nonce field was not being correctly filled with random data but was left uninitialised, containing the contents of the stack. The contents of the stack at this point in ssh-keygen's execution do not appear to leak the CA private key or other sensitive data, but this possibility cannot be excluded on all platforms and library versions. If certificates are generated using user-specified contents (as opposed to the CA specifying all fields) then they will be less resistant to hash collision attacks. Fortunately, such attacks are not currently considered practical for the SHA family of hashes used to sign these certificates. 5. Credit This issue was privately reported by Mateusz Kocielski on January 26, 2011. 6. Fix OpenSSH 5.8 contains a fix for this vulnerability. Users who prefer to continue to use OpenSSH 5.6 or 5.7 may apply this patch: Index: key.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.c,v retrieving revision 1.95 diff -u -r1.95 key.c --- key.c 10 Nov 2010 01:33:07 -0000 1.95 +++ key.c 3 Feb 2011 06:52:33 -0000 @@ -1823,8 +1823,8 @@ buffer_put_cstring(&k->cert->certblob, key_ssh_name(k)); /* -v01 certs put nonce first */ + arc4random_buf(&nonce, sizeof(nonce)); if (!key_cert_is_legacy(k)) { - arc4random_buf(&nonce, sizeof(nonce)); buffer_put_string(&k->cert->certblob, nonce, sizeof(nonce)); } From djm at cvs.openbsd.org Fri Feb 4 12:25:17 2011 From: djm at cvs.openbsd.org (Damien Miller) Date: Thu, 3 Feb 2011 18:25:17 -0700 (MST) Subject: Announce: OpenSSH 5.8 released Message-ID: <201102040125.p141PHNL021580@cvs.openbsd.org> OpenSSH 5.8 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 5.7 ========================= Security: * Fix vulnerability in legacy certificate signing introduced in OpenSSH-5.6 and found by Mateusz Kocielski. Legacy certificates signed by OpenSSH 5.6 or 5.7 included data from the stack in place of a random nonce field. The contents of the stack do not appear to contain private data at this point, but this cannot be stated with certainty for all platform, library and compiler combinations. In particular, there exists a risk that some bytes from the privileged CA key may be accidentally included. A full advisory for this issue is available at: http://www.openssh.com/txt/legacy-cert.adv Portable OpenSSH Bugfixes: * Fix compilation failure when enableing SELinux support. * Do not attempt to call SELinux functions when SELinux is disabled. bz#1851 Checksums: ========== - SHA1 (openssh-5.8.tar.gz) = 205dece2c8b41c69b082eb65320d359987aae25b - SHA1 (openssh-5.8p1.tar.gz) = adebb2faa9aba2a3a3c8b401b2b19677ab53f0de Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From amk at spamfence.net Fri Feb 4 13:22:24 2011 From: amk at spamfence.net (Andreas M. Kirchwitz) Date: Fri, 4 Feb 2011 02:22:24 +0000 (UTC) Subject: Announce: OpenSSH 5.8 released References: <201102040125.p141PHNL021580@cvs.openbsd.org> Message-ID: Damien Miller wrote: > Portable OpenSSH Bugfixes: > > * Fix compilation failure when enableing SELinux support. > > * Do not attempt to call SELinux functions when SELinux is disabled. > bz#1851 Thanks for fixing this. Unfortunately, it went wrong somehow. If configured on Linux (Fedora 14) with SELinux, compilation fails: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -fno-builtin-memset -fstack-protector-all -I. -I.. -I. -I./.. -I/usr/local/ssl/include -DHAVE_CONFIG_H -c port-linux.c port-linux.c: In function ?ssh_selinux_setfscreatecon?: port-linux.c:212:21: warning: unused variable ?context? port-linux.c: At top level: port-linux.c:220:2: error: expected identifier or ?(? before ?if? port-linux.c:222:1: error: expected identifier or ?(? before ?}? token make[1]: *** [port-linux.o] Error 1 make[1]: Leaving directory `/usr/local/src/openssh-5.8p1/openbsd-compat' make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 This patch fixes the problem: --- ./openbsd-compat/port-linux.c_orig 2011-02-04 01:43:08.000000000 +0100 +++ ./openbsd-compat/port-linux.c 2011-02-04 03:06:21.060012941 +0100 @@ -213,7 +213,7 @@ if (!ssh_selinux_enabled()) return; - if (path == NULL) + if (path == NULL) { setfscreatecon(NULL); return; } I really hope that you don't hate me for all this Linux weirdness. ;-) Greetings, Andreas From vinschen at redhat.com Fri Feb 4 21:01:05 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 4 Feb 2011 11:01:05 +0100 Subject: Generate SSH1 host key by default? In-Reply-To: <20110201085625.GN1057@calimero.vinschen.de> References: <20110131105405.GA6215@calimero.vinschen.de> <4D46A58E.4050800@zip.com.au> <20110201085625.GN1057@calimero.vinschen.de> Message-ID: <20110204100105.GB26580@calimero.vinschen.de> Ping? This would have been nice to have in 5.8p1, too. Corinna On Feb 1 09:56, Corinna Vinschen wrote: > [...] > Ok, so I keep the SSH1 keys generation in. Would you mind to apply > the below patch? It adds ECDSA key generation for host and user and > simplifies the ssh-user-config script. > > > Thanks, > Corinna > > > Index: contrib/cygwin//ssh-host-config > =================================================================== > RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v > retrieving revision 1.29 > diff -u -p -r1.29 ssh-host-config > --- contrib/cygwin//ssh-host-config 24 Mar 2010 02:03:32 -0000 1.29 > +++ contrib/cygwin//ssh-host-config 1 Feb 2011 08:55:59 -0000 > @@ -63,6 +63,12 @@ create_host_keys() { > csih_inform "Generating ${SYSCONFDIR}/ssh_host_dsa_key" > ssh-keygen -t dsa -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null > fi > + > + if [ ! -f "${SYSCONFDIR}/ssh_host_ecdsa_key" ] > + then > + csih_inform "Generating ${SYSCONFDIR}/ssh_host_ecdsa_key" > + ssh-keygen -t ecdsa -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null > + fi > } # --- End of create_host_keys --- # > > # ====================================================================== > Index: contrib/cygwin//ssh-user-config > =================================================================== > RCS file: /cvs/openssh/contrib/cygwin/ssh-user-config,v > retrieving revision 1.7 > diff -u -p -r1.7 ssh-user-config > --- contrib/cygwin//ssh-user-config 29 Jul 2009 14:21:13 -0000 1.7 > +++ contrib/cygwin//ssh-user-config 1 Feb 2011 08:55:59 -0000 > @@ -39,85 +39,34 @@ pwdhome= > with_passphrase= > > # ====================================================================== > -# Routine: create_ssh1_identity > -# optionally create ~/.ssh/identity[.pub] > +# Routine: create_identity > +# optionally create identity of type argument in ~/.ssh > # optionally add result to ~/.ssh/authorized_keys > # ====================================================================== > -create_ssh1_identity() { > - if [ ! -f "${pwdhome}/.ssh/identity" ] > +create_identity() { > + local file="$1" > + local type="$2" > + local name="$3" > + if [ ! -f "${pwdhome}/.ssh/${file}" ] > then > - if csih_request "Shall I create an SSH1 RSA identity file for you?" > + if csih_request "Shall I create a ${name} identity file for you?" > then > - csih_inform "Generating ${pwdhome}/.ssh/identity" > + csih_inform "Generating ${pwdhome}/.ssh/${file}" > if [ "${with_passphrase}" = "yes" ] > then > - ssh-keygen -t rsa1 -N "${passphrase}" -f "${pwdhome}/.ssh/identity" > /dev/null > + ssh-keygen -t "${type}" -N "${passphrase}" -f "${pwdhome}/.ssh/${file}" > /dev/null > else > - ssh-keygen -t rsa1 -f "${pwdhome}/.ssh/identity" > /dev/null > + ssh-keygen -t "${type}" -f "${pwdhome}/.ssh/${file}" > /dev/null > fi > if csih_request "Do you want to use this identity to login to this machine?" > then > csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" > - cat "${pwdhome}/.ssh/identity.pub" >> "${pwdhome}/.ssh/authorized_keys" > + cat "${pwdhome}/.ssh/${file}.pub" >> "${pwdhome}/.ssh/authorized_keys" > fi > fi > fi > } # === End of create_ssh1_identity() === # > -readonly -f create_ssh1_identity > - > -# ====================================================================== > -# Routine: create_ssh2_rsa_identity > -# optionally create ~/.ssh/id_rsa[.pub] > -# optionally add result to ~/.ssh/authorized_keys > -# ====================================================================== > -create_ssh2_rsa_identity() { > - if [ ! -f "${pwdhome}/.ssh/id_rsa" ] > - then > - if csih_request "Shall I create an SSH2 RSA identity file for you?" > - then > - csih_inform "Generating ${pwdhome}/.ssh/id_rsa" > - if [ "${with_passphrase}" = "yes" ] > - then > - ssh-keygen -t rsa -N "${passphrase}" -f "${pwdhome}/.ssh/id_rsa" > /dev/null > - else > - ssh-keygen -t rsa -f "${pwdhome}/.ssh/id_rsa" > /dev/null > - fi > - if csih_request "Do you want to use this identity to login to this machine?" > - then > - csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" > - cat "${pwdhome}/.ssh/id_rsa.pub" >> "${pwdhome}/.ssh/authorized_keys" > - fi > - fi > - fi > -} # === End of create_ssh2_rsa_identity() === # > -readonly -f create_ssh2_rsa_identity > - > -# ====================================================================== > -# Routine: create_ssh2_dsa_identity > -# optionally create ~/.ssh/id_dsa[.pub] > -# optionally add result to ~/.ssh/authorized_keys > -# ====================================================================== > -create_ssh2_dsa_identity() { > - if [ ! -f "${pwdhome}/.ssh/id_dsa" ] > - then > - if csih_request "Shall I create an SSH2 DSA identity file for you?" > - then > - csih_inform "Generating ${pwdhome}/.ssh/id_dsa" > - if [ "${with_passphrase}" = "yes" ] > - then > - ssh-keygen -t dsa -N "${passphrase}" -f "${pwdhome}/.ssh/id_dsa" > /dev/null > - else > - ssh-keygen -t dsa -f "${pwdhome}/.ssh/id_dsa" > /dev/null > - fi > - if csih_request "Do you want to use this identity to login to this machine?" > - then > - csih_inform "Adding to ${pwdhome}/.ssh/authorized_keys" > - cat "${pwdhome}/.ssh/id_dsa.pub" >> "${pwdhome}/.ssh/authorized_keys" > - fi > - fi > - fi > -} # === End of create_ssh2_dsa_identity() === # > -readonly -f create_ssh2_dsa_identity > +readonly -f create_identity > > # ====================================================================== > # Routine: check_user_homedir > @@ -311,9 +260,10 @@ fi > > check_user_homedir > check_user_dot_ssh_dir > -create_ssh1_identity > -create_ssh2_rsa_identity > -create_ssh2_dsa_identity > +create_identity id_rsa rsa "SSH2 RSA" > +create_identity id_dsa dsa "SSH2 DSA" > +create_identity id_ecdsa ecdsa "SSH2 ECDSA" > +create_identity identity rsa1 "(deprecated) SSH1 RSA" > fix_authorized_keys_perms > > echo > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From arif at mail.nih.gov Sat Feb 5 03:44:05 2011 From: arif at mail.nih.gov (Anthony R Fletcher) Date: Fri, 4 Feb 2011 11:44:05 -0500 Subject: logging the public key Message-ID: <20110204164405.GA30423@cosy.cit.nih.gov> Can openssh log which public key, as listed in the authorized keys file, was used to log in? If so, how? I don't see a config option, so I'm currently using a custom command via COMMAND="....." ssh-dss AAAAB3Nza..... key1 COMMAND="....." ssh-dss AAAABFFFF..... key2 to log the key. It would be nice if there was a better way. Suggestions? Anthony. -- Anthony R Fletcher Room 2033, Building 12A, http://dcb.cit.nih.gov/~arif National Institutes of Health, arif at mail.nih.gov 12A South Drive, Bethesda, Phone: (+1) 301 402 1741. MD 20892-5624, USA. From dkg at fifthhorseman.net Sat Feb 5 07:48:46 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 04 Feb 2011 15:48:46 -0500 Subject: logging the public key In-Reply-To: <20110204164405.GA30423@cosy.cit.nih.gov> References: <20110204164405.GA30423@cosy.cit.nih.gov> Message-ID: <4D4C662E.40404@fifthhorseman.net> On 02/04/2011 11:44 AM, Anthony R Fletcher wrote: > Can openssh log which public key, as listed in the authorized keys file, > was used to log in? If so, how? > > I don't see a config option, so I'm currently using a custom command via > COMMAND="....." ssh-dss AAAAB3Nza..... key1 > COMMAND="....." ssh-dss AAAABFFFF..... key2 > to log the key. It would be nice if there was a better way. > Suggestions? setting the LogLevel to verbose (usually in /etc/ssh/sshd_config) should log the fingerprint of the key used. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From jan.pechanec at oracle.com Sat Feb 5 09:04:49 2011 From: jan.pechanec at oracle.com (jan.pechanec at oracle.com) Date: Fri, 4 Feb 2011 14:04:49 -0800 (PST) Subject: Auto Reply: Re: logging the public key Message-ID: Hi, I'm off on vacation or/and in transit till Feb 6. I'll read your message when I come back. Regards, Jan. From f_mohr at yahoo.de Sat Feb 5 09:03:53 2011 From: f_mohr at yahoo.de (Frank Mohr) Date: Fri, 04 Feb 2011 23:03:53 +0100 Subject: logging the public key In-Reply-To: <20110204164405.GA30423@cosy.cit.nih.gov> References: <20110204164405.GA30423@cosy.cit.nih.gov> Message-ID: <4D4C77C9.8050609@yahoo.de> Hi, On 02/04/2011 05:44 PM, Anthony R Fletcher wrote: > Can openssh log which public key, as listed in the authorized keys file, > was used to log in? If so, how? There where several patches on the list to log the key comment, but they where not included in openssh. Without patching, you can run the sshd with LogLevel=VERBOSE. This will log the fingerprint of the key used for authentication. (With "ssh-keygen -l -f authorized_keys" you get all fingerprints of the public keys in the file) Frank __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com From dtucker at zip.com.au Sun Feb 6 13:38:12 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 06 Feb 2011 13:38:12 +1100 Subject: Generate SSH1 host key by default? In-Reply-To: <20110204100105.GB26580@calimero.vinschen.de> References: <20110131105405.GA6215@calimero.vinschen.de> <4D46A58E.4050800@zip.com.au> <20110201085625.GN1057@calimero.vinschen.de> <20110204100105.GB26580@calimero.vinschen.de> Message-ID: <4D4E0994.1020207@zip.com.au> On 4/02/11 9:01 PM, Corinna Vinschen wrote: > Ping? > > This would have been nice to have in 5.8p1, too. Sorry, have been slacking. Applied, but 5.8p1 is already out so it'll be in the next release. -- 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 bert.wesarg at googlemail.com Mon Feb 7 22:56:32 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 7 Feb 2011 12:56:32 +0100 Subject: [PATCH] PROTOCOL.mux: fix typo Message-ID: <74dc3e1e0cb6997739ef6be57693cec270a72f78.1297063624.git.bert.wesarg@googlemail.com> --- PROTOCOL.mux | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/PROTOCOL.mux b/PROTOCOL.mux index 3d6f818..5074993 100644 --- a/PROTOCOL.mux +++ b/PROTOCOL.mux @@ -149,7 +149,7 @@ The client then sends its standard input and output file descriptors The contents of "reserved" are currently ignored. -A server may reply with a MUX_S_SESSION_OPEED, a MUX_S_PERMISSION_DENIED +A server may reply with a MUX_S_SESSION_OPENED, a MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE. 8. Status messages -- 1.7.3.3.1603.g7f137 From alaric at caerllewys.net Tue Feb 8 03:25:16 2011 From: alaric at caerllewys.net (Brother Railgun of Reason) Date: Mon, 7 Feb 2011 11:25:16 -0500 Subject: Possible ssh -D bug in 5.8p1 (on Gentoo Linux) In-Reply-To: References: Message-ID: <20110207162516.GA18211@babylon5.babcom.com> On Fri, Feb 04, 2011 at 12:26:08PM +1100, Damien Miller wrote: > OpenSSH 5.8 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. I seem to have found a bug in 5.8p1. I work remotely, and use three SSH tunnels, two of the form ssh -L port:host:destport -f -N -q -l remoteuser remotehost, and one of the form ssh -D port -f -C -q -N -l remoteuser remotehost, the latter a web tunnel that I may access any of several web hosts through. When I upgraded to OpenSSH 5.8p1 this morning, the ssh -D tunnel ceased to work; it would connect correctly, then stop responding within 30 seconds to a minute, and the ssh process would not die on a SIGTERM, requiring a SIGKILL. When I backed out to 5.7p1 and restarted my tunnels again, the ssh -D tunnel worked again. The two ssh -L tunnels continued to work normally. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 alaric at caerllewys.net alaric at metrocast.net phil at co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. From djm at mindrot.org Tue Feb 8 07:57:55 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 8 Feb 2011 07:57:55 +1100 (EST) Subject: Possible ssh -D bug in 5.8p1 (on Gentoo Linux) In-Reply-To: <20110207162516.GA18211@babylon5.babcom.com> References: <20110207162516.GA18211@babylon5.babcom.com> Message-ID: On Mon, 7 Feb 2011, Brother Railgun of Reason wrote: > On Fri, Feb 04, 2011 at 12:26:08PM +1100, Damien Miller wrote: > > OpenSSH 5.8 has just been released. It will be available from the > > mirrors listed at http://www.openssh.com/ shortly. > > I seem to have found a bug in 5.8p1. > > I work remotely, and use three SSH tunnels, two of the form ssh -L > port:host:destport -f -N -q -l remoteuser remotehost, and one of the > form ssh -D port -f -C -q -N -l remoteuser remotehost, the latter a web > tunnel that I may access any of several web hosts through. When I > upgraded to OpenSSH 5.8p1 this morning, the ssh -D tunnel ceased to > work; it would connect correctly, then stop responding within 30 seconds > to a minute, and the ssh process would not die on a SIGTERM, requiring a > SIGKILL. When I backed out to 5.7p1 and restarted my tunnels again, the > ssh -D tunnel worked again. The two ssh -L tunnels continued to work > normally. That's pretty unlikely, because there was no channels or forwarding- related code changed between 5.7 and 5.8. If you aren't using SELinux, the substantive diff is literally one line in the key certification code. -d From bert.wesarg at googlemail.com Tue Feb 8 08:11:58 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 7 Feb 2011 22:11:58 +0100 Subject: [PATCH] ssh: set proctitle for mux master Message-ID: Preserving the command line from the invoking ssh command doesn't make much sense, so use setproctitle() to hide the arguments. --- ssh.c | 20 +++++++++++++++++--- 1 files changed, 17 insertions(+), 3 deletions(-) diff --git a/ssh.c b/ssh.c index d32ef78..8ebcc88 100644 --- a/ssh.c +++ b/ssh.c @@ -230,12 +230,25 @@ main(int ac, char **av) struct servent *sp; Forward fwd; - /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ - sanitise_stdfd(); - __progname = ssh_get_progname(av[0]); init_rng(); +#ifndef HAVE_SETPROCTITLE + /* Prepare for later setproctitle emulation */ + { + /* Save argv. Duplicate so setproctitle emulation doesn't clobber it */ + char **saved_argv = xcalloc(ac + 1, sizeof(*saved_argv)); + for (i = 0; i < ac; i++) + saved_argv[i] = xstrdup(av[i]); + saved_argv[i] = NULL; + compat_init_setproctitle(ac, av); + av = saved_argv; + } +#endif + + /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ + sanitise_stdfd(); + /* * Discard other fds that are hanging around. These can cause problem * with backgrounded ssh processes started by ControlPersist. @@ -965,6 +978,7 @@ control_persist_detach(void) if (devnull > STDERR_FILENO) close(devnull); } + setproctitle("%s [mux]", options.control_path); } /* Do fork() after authentication. Used by "ssh -f" */ -- 1.7.3.3.1603.g7f137 From cyrille.lefevre-lists at laposte.net Tue Feb 8 08:56:29 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Mon, 07 Feb 2011 22:56:29 +0100 Subject: feature request Message-ID: <4D506A8D.7070603@laposte.net> Hi, how about to provide a simple way to forward raw file descriptors through ssh tunnels. something which may provide a way to write something like : (echo 3; read > out3) |& exec 3<&p 4>&p echo 5 >| out5 exec 5<> out5 echo 1 | ssh -d 3:rd -d 4:wr -d 5:rw ' read <&3; echo $REPLY >&4 read; echo $REPLY read <&5; echo $REPLY >&5 ' > out1 the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. PS : hope the sample is right :-) Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From imorgan at nas.nasa.gov Tue Feb 8 11:41:42 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 7 Feb 2011 16:41:42 -0800 Subject: feature request In-Reply-To: <4D506A8D.7070603@laposte.net> References: <4D506A8D.7070603@laposte.net> Message-ID: <20110208004142.GC4614@linux124.nas.nasa.gov> On Mon, Feb 07, 2011 at 15:56:29 -0600, Cyrille Lefevre wrote: > > Hi, > > how about to provide a simple way to forward raw file descriptors > through ssh tunnels. > > something which may provide a way to write something like : > > (echo 3; read > out3) |& > exec 3<&p 4>&p > echo 5 >| out5 > exec 5<> out5 > echo 1 | > ssh -d 3:rd -d 4:wr -d 5:rw ' > read <&3; echo $REPLY >&4 > read; echo $REPLY > read <&5; echo $REPLY >&5 > ' > out1 > > the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. > > PS : hope the sample is right :-) > > Regards, > > Cyrille Lefevre > -- > mailto:Cyrille.Lefevre-lists at laposte.net > What problem are you hoping to solve with this? -- Iain Morgan From alaric at caerllewys.net Tue Feb 8 22:47:44 2011 From: alaric at caerllewys.net (Brother Railgun of Reason) Date: Tue, 8 Feb 2011 06:47:44 -0500 Subject: Possible ssh -D bug in 5.8p1 (on Gentoo Linux) In-Reply-To: References: <20110207162516.GA18211@babylon5.babcom.com> Message-ID: <20110208114744.GA32174@babylon5.babcom.com> On Tue, Feb 08, 2011 at 07:57:55AM +1100, Damien Miller wrote: > On Mon, 7 Feb 2011, Brother Railgun of Reason wrote: > > I seem to have found a bug in 5.8p1. > > > > I work remotely, and use three SSH tunnels, two of the form ssh -L > > port:host:destport -f -N -q -l remoteuser remotehost, and one of the > > form ssh -D port -f -C -q -N -l remoteuser remotehost, the latter a web > > tunnel that I may access any of several web hosts through. When I > > upgraded to OpenSSH 5.8p1 this morning, the ssh -D tunnel ceased to > > work; it would connect correctly, then stop responding within 30 seconds > > to a minute, and the ssh process would not die on a SIGTERM, requiring a > > SIGKILL. When I backed out to 5.7p1 and restarted my tunnels again, the > > ssh -D tunnel worked again. The two ssh -L tunnels continued to work > > normally. > > That's pretty unlikely, because there was no channels or forwarding- > related code changed between 5.7 and 5.8. If you aren't using SELinux, > the substantive diff is literally one line in the key certification code. Nevertheless, I have one tunnel, set up in a specific way different from my other two, that worked under 5.6 and 5.7, stops working when I upgrade to 5.8, and works again as soon as I downgrade back to 5.7. I'm filing a bug report with Gentoo in case it was introduced there. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 alaric at caerllewys.net alaric at metrocast.net phil at co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. From cyrille.lefevre-lists at laposte.net Tue Feb 8 20:41:21 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Tue, 08 Feb 2011 10:41:21 +0100 Subject: feature request In-Reply-To: <20110208004142.GC4614@linux124.nas.nasa.gov> References: <4D506A8D.7070603@laposte.net> <20110208004142.GC4614@linux124.nas.nasa.gov> Message-ID: <4D510FC1.3010408@laposte.net> Le 08/02/2011 01:41, Iain Morgan a ?crit : > > On Mon, Feb 07, 2011 at 15:56:29 -0600, Cyrille Lefevre wrote: >> >> Hi, >> >> how about to provide a simple way to forward raw file descriptors >> through ssh tunnels. >> >> something which may provide a way to write something like : >> >> (echo 3; read> out3) |& >> exec 3<&p 4>&p >> echo 5>| out5 >> exec 5<> out5 >> echo 1 | >> ssh -d 3:rd -d 4:wr -d 5:rw ' >> read<&3; echo $REPLY>&4 >> read; echo $REPLY >> read<&5; echo $REPLY>&5 >> '> out1 >> >> the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. >> >> PS : hope the sample is right :-) > > What problem are you hoping to solve with this? the ability to have more than the 3 standard file descriptors in remote shell scripting. a common case I use is : exec 9>&1 var=$(script) where script output its result on fd 1, error messages of fd 2 and informational messages on fd 9. don't ask why, it's like that. thing impossible through ssh w/o playing w/ something to multiplex standard file descriptors through fd 2 using fifos, tags and loops. https://groups.google.com/group/fr.comp.os.unix/browse_thread/thread/8acc88b475b324b6/21d2e2f1bf85c5a7?hl=fr&ie=UTF-8&q=cyrille+lefevre+PreSshFilterLog&pli=1 I've tryed netpipesw/o success and even if that worked, that will require to have netpipes on every host which is not possible in my production environment. Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From mansourmoufid at gmail.com Tue Feb 8 23:30:30 2011 From: mansourmoufid at gmail.com (Mansour Moufid) Date: Tue, 8 Feb 2011 07:30:30 -0500 Subject: Possible ssh -D bug in 5.8p1 (on Gentoo Linux) In-Reply-To: <20110208114744.GA32174@babylon5.babcom.com> References: <20110207162516.GA18211@babylon5.babcom.com> <20110208114744.GA32174@babylon5.babcom.com> Message-ID: On Tue, Feb 8, 2011 at 6:47 AM, Brother Railgun of Reason wrote: > On Tue, Feb 08, 2011 at 07:57:55AM +1100, Damien Miller wrote: >> On Mon, 7 Feb 2011, Brother Railgun of Reason wrote: >> > I seem to have found a bug in 5.8p1. >> > >> > I work remotely, and use three SSH tunnels, two of the form ssh -L >> > port:host:destport -f -N -q -l remoteuser remotehost, and one of the >> > form ssh -D port -f -C -q -N -l remoteuser remotehost, the latter a web >> > tunnel that I may access any of several web hosts through. ?When I >> > upgraded to OpenSSH 5.8p1 this morning, the ssh -D tunnel ceased to >> > work; it would connect correctly, then stop responding within 30 seconds >> > to a minute, and the ssh process would not die on a SIGTERM, requiring a >> > SIGKILL. ?When I backed out to 5.7p1 and restarted my tunnels again, the >> > ssh -D tunnel worked again. ?The two ssh -L tunnels continued to work >> > normally. >> >> That's pretty unlikely, because there was no channels or forwarding- >> related code changed between 5.7 and 5.8. If you aren't using SELinux, >> the substantive diff is literally one line in the key certification code. > > Nevertheless, I have one tunnel, set up in a specific way different from > my other two, that worked under 5.6 and 5.7, stops working when I > upgrade to 5.8, and works again as soon as I downgrade back to 5.7. > > I'm filing a bug report with Gentoo in case it was introduced there. Perhaps. The HPN patch in Portage was switched to on by default between 5.7 and 5.8 (see [1,2,3]). Try setting the -hpn USE flag explicitly and see if the problem persists. Sharing this here so more knowledgeable people could comment on [3]. [1] [2] [3] From Roman.Fiedler at ait.ac.at Tue Feb 8 23:51:45 2011 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 8 Feb 2011 13:51:45 +0100 Subject: AW: feature request In-Reply-To: <4D510FC1.3010408@laposte.net> References: <4D506A8D.7070603@laposte.net> <20110208004142.GC4614@linux124.nas.nasa.gov> <4D510FC1.3010408@laposte.net> Message-ID: <9F69795E29C890408AC2DAF646C89BB37999105ABB@MAILBOX.arc.local> > -----Urspr?ngliche Nachricht----- > Von: openssh-unix-dev-bounces+roman.fiedler=ait.ac.at at mindrot.org > [mailto:openssh-unix-dev-bounces+roman.fiedler=ait.ac.at at mindrot.org] > Im Auftrag von Cyrille Lefevre > Gesendet: Dienstag, 8. Februar 2011 10:41 > An: openssh-unix-dev at mindrot.org > Betreff: Re: feature request > > > Le 08/02/2011 01:41, Iain Morgan a ?crit : > > > > On Mon, Feb 07, 2011 at 15:56:29 -0600, Cyrille Lefevre wrote: > >> > >> Hi, > >> > >> how about to provide a simple way to forward raw file descriptors > >> through ssh tunnels. > >> > >> something which may provide a way to write something like : > >> > >> (echo 3; read> out3) |& > >> exec 3<&p 4>&p > >> echo 5>| out5 > >> exec 5<> out5 > >> echo 1 | > >> ssh -d 3:rd -d 4:wr -d 5:rw ' > >> read<&3; echo $REPLY>&4 > >> read; echo $REPLY > >> read<&5; echo $REPLY>&5 > >> '> out1 > >> > >> the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. > >> > >> PS : hope the sample is right :-) > > > > What problem are you hoping to solve with this? > > the ability to have more than the 3 standard file descriptors in remote > shell scripting. > > a common case I use is : > > exec 9>&1 > var=$(script) > > where script output its result on fd 1, error messages of fd 2 and > informational messages on fd 9. don't ask why, it's like that. > > thing impossible through ssh w/o playing w/ something to multiplex > standard file descriptors through fd 2 using fifos, tags and loops. > > https://groups.google.com/group/fr.comp.os.unix/browse_thread/thread/8 > acc88b475b324b6/21d2e2f1bf85c5a7?hl=fr&ie=UTF- > 8&q=cyrille+lefevre+PreSshFilterLog&pli=1 > > I've tryed netpipesw/o success and even if that worked, that will > require to have netpipes on every host which is not possible in my > production environment. I've had the same problem with ssh. I'll check the netpipes, perhaps they could be used. At the moment a primitive multiplexer based on "xxd -p", "grep", "sed" is in use. From rhammond at databit7.com Wed Feb 9 02:43:29 2011 From: rhammond at databit7.com (Robin David Hammond) Date: Tue, 08 Feb 2011 15:43:29 +0000 Subject: feature request In-Reply-To: <4D510FC1.3010408@laposte.net> References: <4D506A8D.7070603@laposte.net> <20110208004142.GC4614@linux124.nas.nasa.gov> <4D510FC1.3010408@laposte.net> Message-ID: <4D5164A1.2080200@databit7.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 perhaps you can use netcat as an interim measure. On 2011-02-08 09:41, Cyrille Lefevre wrote: > > Le 08/02/2011 01:41, Iain Morgan a ?crit : >> >> On Mon, Feb 07, 2011 at 15:56:29 -0600, Cyrille Lefevre wrote: >>> >>> Hi, >>> >>> how about to provide a simple way to forward raw file descriptors >>> through ssh tunnels. >>> >>> something which may provide a way to write something like : >>> >>> (echo 3; read> out3) |& >>> exec 3<&p 4>&p >>> echo 5>| out5 >>> exec 5<> out5 >>> echo 1 | >>> ssh -d 3:rd -d 4:wr -d 5:rw ' >>> read<&3; echo $REPLY>&4 >>> read; echo $REPLY >>> read<&5; echo $REPLY>&5 >>> '> out1 >>> >>> the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. >>> >>> PS : hope the sample is right :-) >> >> What problem are you hoping to solve with this? > > the ability to have more than the 3 standard file descriptors in remote > shell scripting. > > a common case I use is : > > exec 9>&1 > var=$(script) > > where script output its result on fd 1, error messages of fd 2 and > informational messages on fd 9. don't ask why, it's like that. > > thing impossible through ssh w/o playing w/ something to multiplex > standard file descriptors through fd 2 using fifos, tags and loops. > > https://groups.google.com/group/fr.comp.os.unix/browse_thread/thread/8acc88b475b324b6/21d2e2f1bf85c5a7?hl=fr&ie=UTF-8&q=cyrille+lefevre+PreSshFilterLog&pli=1 > > > I've tryed netpipesw/o success and even if that worked, that will > require to have netpipes on every host which is not possible in my > production environment. > > Regards, > > Cyrille Lefevre - -- _ ASCII ribbon campaign ( ) | Robin-David Hammond %KB3IEN against HTML e-mail X | CCNA / \ databit7.com VoIP: Sales, Consulting VPN, Backups and Monitoring -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNUWShAAoJELbrs44SuiR02oEP/26p6rgRia4DRXPdHMPzKS2U 57MNQ1kS5ZyFPtkpYa/4Dbqxa6J3S/OZz2FdNfUzyzxgkajSFSKI++ggEaqgVB6b tCY5NlQG5vUhg6B4qBXvG6b5MCe812iY9HMSndPirjvWMYy/BA78bhvQwGVu+vZT +0PcsZvdbrj4bp6qORpN8XDiWZdU7SJe0sQOMlbEYoqqf2ed1bNyIBjeSyyZ7ZTR XBlpOyJxwI46/JiWCuzQ7TVlURg8orAORtviz/ZkFC9O5rPzCRMMpiNobQwxfogL 9vrMes5RZ6Te3xoSLk2QDD7BJ+aKIJ63DWbwb7wFblVFuWXfrA63qeiUyzJFQPK+ j3hWEKLF+j8orIFXnZhBjbJphgjluupYx/huKYZ86bEI0UMmJCfJ95oc2nQ+ReYZ Q0ZTS7pGY1H3UmUa8NhhYF0UmTrBI+UsG1ZhQ1LK5euxSZZxu+FFmXc6l+Q+gVpe rkdv5HaJGfTOiNpGc70xq1wMbC9VSFhy53lWBliM+bMft28HUtJSfoXJh8EcvtX4 pb8ImuclHlYWI3NMhxs2hb+hh0fBbAvHauCIYodzF5XbDZ1L63pgKHOLH1FWKOoW 8KKmI9WeGbP5U2Jvw+sWTBDvlVSPuUddLccN4sPbVF3RF3R44O6msiuP3ELgfOnr II4FB3erwkNvmdu/XXMT =E8el -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: rhammond.vcf Type: text/x-vcard Size: 234 bytes Desc: not available URL: From mfriedl at gmail.com Wed Feb 9 04:01:26 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 8 Feb 2011 18:01:26 +0100 Subject: feature request In-Reply-To: <4D506A8D.7070603@laposte.net> References: <4D506A8D.7070603@laposte.net> Message-ID: does this help for you? -W host:port Requests that standard input and output on the client be forwarded to host on port over the secure channel. Implies -N, -T, ExitOnForwardFailure and ClearAllForwardings and works with Protocol version 2 only. On Mon, Feb 7, 2011 at 10:56 PM, Cyrille Lefevre wrote: > > Hi, > > how about to provide a simple way to forward raw file descriptors through > ssh tunnels. > > something which may provide a way to write something like : > > (echo 3; read > out3) |& > exec 3<&p 4>&p > echo 5 >| out5 > exec 5<> out5 > echo 1 | > ssh -d 3:rd -d 4:wr -d 5:rw ' > ? ? ? ?read <&3; echo $REPLY >&4 > ? ? ? ?read; echo $REPLY > ? ? ? ?read <&5; echo $REPLY >&5 > ' > out1 > > the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. > > PS : hope the sample is right :-) > > Regards, > > Cyrille Lefevre > -- > mailto:Cyrille.Lefevre-lists at laposte.net > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cyrille.lefevre-lists at laposte.net Wed Feb 9 07:51:03 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Tue, 08 Feb 2011 21:51:03 +0100 Subject: feature request In-Reply-To: References: <4D506A8D.7070603@laposte.net> Message-ID: <4D51ACB7.2030709@laposte.net> Le 08/02/2011 18:01, Markus Friedl a ?crit : >does this help for you? > > -W host:port no since the other end has to be a socket... Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From cyrille.lefevre-lists at laposte.net Wed Feb 9 07:57:54 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Tue, 08 Feb 2011 21:57:54 +0100 Subject: feature request In-Reply-To: <4D5164A1.2080200@databit7.com> References: <4D506A8D.7070603@laposte.net> <20110208004142.GC4614@linux124.nas.nasa.gov> <4D510FC1.3010408@laposte.net> <4D5164A1.2080200@databit7.com> Message-ID: <4D51AE52.2020503@laposte.net> Le 08/02/2011 16:43, Robin David Hammond a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > perhaps you can use netcat as an interim measure. also tried w/o success. another problem is the port assignment, the more you need extra dfs, the more you need netcat processes and ports. also, same problem as netpipes, not available anywhere. IMHO, the inside ssh solution is the more appropriate since anything seems to be here, if ssh maintainers are ok to integrate this feature, I may try to add it to ssh. Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From mfriedl at gmail.com Wed Feb 9 09:14:59 2011 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 8 Feb 2011 23:14:59 +0100 Subject: feature request In-Reply-To: <4D51ACB7.2030709@laposte.net> References: <4D506A8D.7070603@laposte.net> <4D51ACB7.2030709@laposte.net> Message-ID: so you just want to multiplex several file descriptors over a single ssh connection? -M can do that for you. or do you need a single process on the remote host? On Tue, Feb 8, 2011 at 9:51 PM, Cyrille Lefevre wrote: > > Le 08/02/2011 18:01, Markus Friedl a ?crit : >> >> does this help for you? > >> >> ? ? ?-W host:port > > no since the other end has to be a socket... > > Regards, > > Cyrille Lefevre > -- > mailto:Cyrille.Lefevre-lists at laposte.net > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cyrille.lefevre-lists at laposte.net Wed Feb 9 10:23:17 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Wed, 09 Feb 2011 00:23:17 +0100 Subject: feature request In-Reply-To: References: <4D506A8D.7070603@laposte.net> <4D51ACB7.2030709@laposte.net> Message-ID: <4D51D065.9040401@laposte.net> Le 08/02/2011 23:14, Markus Friedl a ?crit : > > so you just want to multiplex several file descriptors over a single > ssh connection? > -M can do that for you. or do you need a single process on the remote host? neither, I already know and use -M in another circonstance. -M allow you to multiplex several child connexions over a single master connexion, this has nothing to do w/ file descriptors. imagine that I want to communicate w/ a remote process w/ more than the only 3 standard file descriptors. Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From mark.cavage at joyent.com Wed Feb 9 11:03:26 2011 From: mark.cavage at joyent.com (Mark Cavage) Date: Tue, 8 Feb 2011 16:03:26 -0800 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: Message-ID: I would like to implement a feature whereby users can write their own plugins for authorizing use of a public key. ?I've got a private branch of this working, but would like feedback before submitting a patch (starting with whether the community would want this). Essentially, I've added a line in sshd_config like: PubKeyPlugin ~/local/dev/plugin/libsshplugin.so Which dlopen's said plugin and looks for a function that checks access for RSA public keys (function defined below). It would not be a stretch to add DSA et al., but I didn't want to bother unless this gets blessed. The function gets invoked in auth2-pubkey only if the authorized_keys file checks failed. I did this as the only other functionality like this I saw were things like the LPK/Fed-SSH patches that assume one is running LDAP; this mechanism allows a user to run whatever arbitrary things they want to determine what keys map to what users (or by group, etc.). Thank you! /** ?* NAME: ?* ? ? int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd, const char *fingerprint) ?* ?* DESCRIPTION: ?* ? ? Determines whether or not the specified key is allowed to authenticate as the user in pwd ?* ?* INPUTS: ?* ? ? ?RSA * rsa ? ? ? ? ? ? ? ? ? ? ?The RSA public key used by the remote party (signature check has already passed) ?* ? ? ?struct passwd * pwd ? ? ? The user record the remote party is attempting to login as ?* ? ? ?const char * fingerprint ? ?MD5 fingerprint of the RSA public key (for convenience) ?* ?* OUTPUTS: ?* ? ? [0] ? ?Not Allowed ?* ? ? [1] ? ?Allowed ?* ?* NOTES: ?* ? ? Developers are expected to link against OpenSSL, and include. * There is no dependency on OpenSSH. ?*/ int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd,?const char *fingerprint); From mark.cavage at joyent.com Wed Feb 9 10:19:52 2011 From: mark.cavage at joyent.com (Mark Cavage) Date: Tue, 8 Feb 2011 15:19:52 -0800 Subject: Feature Request: Plugin Model for authorizing public keys Message-ID: I would like to implement a feature whereby users can write their own plugins for authorizing use of a public key. I've got a private branch of this working, but would like feedback before submitting a patch (starting with whether the community would want this). Essentially, I've added a line in sshd_config like: PubKeyPlugin ~/local/dev/plugin/libsshplugin.so/dylib/. .. Which dlopen's said plugin and looks for a function that checks access for RSA public keys (function defined below). It would not be a stretch to add DSA et al., but I didn't want to bother unless this gets blessed. The function gets invoked in auth2-pubkey only if the authorized_keys file checks failed. I did this as the only other functionality like this I saw were things like the LPK/Fed-SSH patches that assume one is running LDAP; this mechanism allows a user to run whatever arbitrary things they want to determine what keys map to what users (or by group, etc.). Thank you! /** * NAME: * int sshd_user_rsa_key_allowed(RSA *rsa, struct passwd *pwd, const char *fingerprint) * * DESCRIPTION: * Determines whether or not the specified key is allowed to authenticate as the user in pwd * * INPUTS: * RSA * rsa The RSA public key used by the remote party (signature check has already passed) * struct passwd * pwd The user record the remote party is attempting to login as * const char * fingerprint MD5 fingerprint of the RSA public key (for convenience) * * OUTPUTS: * [0] Not Allowed * [1] Allowed * * NOTES: * Developers are expected to link against OpenSSL, and include. There is no dependency on OpenSSH. */ int sshd_user_rsa_key_allowed(RSA *rsa, struct passwd *pwd, const char *fingerprint); From dan at doxpara.com Wed Feb 9 12:33:43 2011 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 8 Feb 2011 17:33:43 -0800 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: Message-ID: This would be a more elegant mechanism for adding DNSSEC support than my present patch. For synchrony though, perhaps this should be a ProxyCommand style executable? On Tue, Feb 8, 2011 at 4:03 PM, Mark Cavage wrote: > I would like to implement a feature whereby users can write their own > plugins for authorizing use of a public key. ?I've got a private > branch of this working, but would like feedback before submitting a > patch (starting with whether the community would want this). > Essentially, I've added a line in sshd_config like: > > PubKeyPlugin ~/local/dev/plugin/libsshplugin.so > > Which dlopen's said plugin and looks for a function that checks access > for RSA public keys (function defined below). It would not be a > stretch to add DSA et al., but I didn't want to bother unless this > gets blessed. The function gets invoked in auth2-pubkey only if the > authorized_keys file checks failed. > > I did this as the only other functionality like this I saw were things > like the LPK/Fed-SSH patches that assume one is running LDAP; this > mechanism allows a user to run whatever arbitrary things they want to > determine what keys map to what users (or by group, etc.). > > Thank you! > > /** > ?* NAME: > ?* ? ? int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd, > const char *fingerprint) > ?* > ?* DESCRIPTION: > ?* ? ? Determines whether or not the specified key is allowed to > authenticate as the user in pwd > ?* > ?* INPUTS: > ?* ? ? ?RSA * rsa ? ? ? ? ? ? ? ? ? ? ?The RSA public key used by the > remote party (signature check has already passed) > ?* ? ? ?struct passwd * pwd ? ? ? The user record the remote party is > attempting to login as > ?* ? ? ?const char * fingerprint ? ?MD5 fingerprint of the RSA public > key (for convenience) > ?* > ?* OUTPUTS: > ?* ? ? [0] ? ?Not Allowed > ?* ? ? [1] ? ?Allowed > ?* > ?* NOTES: > ?* ? ? Developers are expected to link against OpenSSL, and > include. > ?* ? ? There is no dependency on OpenSSH. > ?*/ > int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd,?const char > *fingerprint); > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mark.cavage at joyent.com Wed Feb 9 12:45:04 2011 From: mark.cavage at joyent.com (Mark Cavage) Date: Tue, 8 Feb 2011 17:45:04 -0800 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: Message-ID: I'm not sure I follow - this is an sshd proposal (i.e., I mainly hacked up sshd/auth2-pubkey.c) so that the target host doesn't need a ~/.ssh/authorized_keys file. On Tue, Feb 8, 2011 at 5:33 PM, Dan Kaminsky wrote: > This would be a more elegant mechanism for adding DNSSEC support than > my present patch. ?For synchrony though, perhaps this should be a > ProxyCommand style executable? > > On Tue, Feb 8, 2011 at 4:03 PM, Mark Cavage wrote: >> I would like to implement a feature whereby users can write their own >> plugins for authorizing use of a public key. ?I've got a private >> branch of this working, but would like feedback before submitting a >> patch (starting with whether the community would want this). >> Essentially, I've added a line in sshd_config like: >> >> PubKeyPlugin ~/local/dev/plugin/libsshplugin.so >> >> Which dlopen's said plugin and looks for a function that checks access >> for RSA public keys (function defined below). It would not be a >> stretch to add DSA et al., but I didn't want to bother unless this >> gets blessed. The function gets invoked in auth2-pubkey only if the >> authorized_keys file checks failed. >> >> I did this as the only other functionality like this I saw were things >> like the LPK/Fed-SSH patches that assume one is running LDAP; this >> mechanism allows a user to run whatever arbitrary things they want to >> determine what keys map to what users (or by group, etc.). >> >> Thank you! >> >> /** >> ?* NAME: >> ?* ? ? int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd, >> const char *fingerprint) >> ?* >> ?* DESCRIPTION: >> ?* ? ? Determines whether or not the specified key is allowed to >> authenticate as the user in pwd >> ?* >> ?* INPUTS: >> ?* ? ? ?RSA * rsa ? ? ? ? ? ? ? ? ? ? ?The RSA public key used by the >> remote party (signature check has already passed) >> ?* ? ? ?struct passwd * pwd ? ? ? The user record the remote party is >> attempting to login as >> ?* ? ? ?const char * fingerprint ? ?MD5 fingerprint of the RSA public >> key (for convenience) >> ?* >> ?* OUTPUTS: >> ?* ? ? [0] ? ?Not Allowed >> ?* ? ? [1] ? ?Allowed >> ?* >> ?* NOTES: >> ?* ? ? Developers are expected to link against OpenSSL, and >> include. >> ?* ? ? There is no dependency on OpenSSH. >> ?*/ >> int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd,?const char >> *fingerprint); >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > From dan at doxpara.com Wed Feb 9 13:43:25 2011 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 8 Feb 2011 18:43:25 -0800 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: Message-ID: I'm saying that most other extensions to OpenSSH are executables, not in-proc libraries. On Tue, Feb 8, 2011 at 5:45 PM, Mark Cavage wrote: > I'm not sure I follow - this is an sshd proposal (i.e., I mainly > hacked up sshd/auth2-pubkey.c) so that the target host doesn't need a > ~/.ssh/authorized_keys file. > > On Tue, Feb 8, 2011 at 5:33 PM, Dan Kaminsky wrote: >> This would be a more elegant mechanism for adding DNSSEC support than >> my present patch. ?For synchrony though, perhaps this should be a >> ProxyCommand style executable? >> >> On Tue, Feb 8, 2011 at 4:03 PM, Mark Cavage wrote: >>> I would like to implement a feature whereby users can write their own >>> plugins for authorizing use of a public key. ?I've got a private >>> branch of this working, but would like feedback before submitting a >>> patch (starting with whether the community would want this). >>> Essentially, I've added a line in sshd_config like: >>> >>> PubKeyPlugin ~/local/dev/plugin/libsshplugin.so >>> >>> Which dlopen's said plugin and looks for a function that checks access >>> for RSA public keys (function defined below). It would not be a >>> stretch to add DSA et al., but I didn't want to bother unless this >>> gets blessed. The function gets invoked in auth2-pubkey only if the >>> authorized_keys file checks failed. >>> >>> I did this as the only other functionality like this I saw were things >>> like the LPK/Fed-SSH patches that assume one is running LDAP; this >>> mechanism allows a user to run whatever arbitrary things they want to >>> determine what keys map to what users (or by group, etc.). >>> >>> Thank you! >>> >>> /** >>> ?* NAME: >>> ?* ? ? int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd, >>> const char *fingerprint) >>> ?* >>> ?* DESCRIPTION: >>> ?* ? ? Determines whether or not the specified key is allowed to >>> authenticate as the user in pwd >>> ?* >>> ?* INPUTS: >>> ?* ? ? ?RSA * rsa ? ? ? ? ? ? ? ? ? ? ?The RSA public key used by the >>> remote party (signature check has already passed) >>> ?* ? ? ?struct passwd * pwd ? ? ? The user record the remote party is >>> attempting to login as >>> ?* ? ? ?const char * fingerprint ? ?MD5 fingerprint of the RSA public >>> key (for convenience) >>> ?* >>> ?* OUTPUTS: >>> ?* ? ? [0] ? ?Not Allowed >>> ?* ? ? [1] ? ?Allowed >>> ?* >>> ?* NOTES: >>> ?* ? ? Developers are expected to link against OpenSSL, and >>> include. >>> ?* ? ? There is no dependency on OpenSSH. >>> ?*/ >>> int sshd_user_rsa_key_allowed(RSA *rsa,?struct passwd *pwd,?const char >>> *fingerprint); >>> _______________________________________________ >>> openssh-unix-dev mailing list >>> openssh-unix-dev at mindrot.org >>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >>> >> > From dkg at fifthhorseman.net Wed Feb 9 15:57:08 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Feb 2011 23:57:08 -0500 Subject: AuthorizedKeysCommand [was: Re: Feature Request: Plugin Model for authorizing public keys] In-Reply-To: References: Message-ID: <4D521EA4.8060101@fifthhorseman.net> On 02/08/2011 09:43 PM, Dan Kaminsky wrote: > I'm saying that most other extensions to OpenSSH are executables, not > in-proc libraries. There is an outstanding bug report addressing this issue, with a patch providing AuthorizedKeysCommand functionality: https://bugzilla.mindrot.org/show_bug.cgi?id=1663 It sounds like this is already adopted by Fedora and RedHat downstream. The semantics are slightly different than those proposed by Mark Cavage, though: * AuthorizedKeysCommand, invoked with a single argument (the username) produces output identical to (and interpreted as) a standard AuthorizedKeysFile. * if the offered key is *not* found in the output of AuthorizedKeysCommand, then AuthorizedKeysFile continues as usual. This lets an AuthorizedKeysCommand implementor provide options like no-pty, etc. However, it also requires that such an implementation exhaustively enumerate all acceptable keys. i suspect an argument could be made for a different resolution to this feature request: have AuthorizedKeysCommand accept the offered key on stdin, write any restricting options to stdout, and have the return code of the process indicate acceptance or not. Such an argument would be more convincing with some code to back it up, of course ;) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Wed Feb 9 21:38:28 2011 From: peter at stuge.se (Peter Stuge) Date: Wed, 9 Feb 2011 11:38:28 +0100 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: Message-ID: <20110209103828.13523.qmail@stuge.se> Mark Cavage wrote: > I would like to implement a feature whereby users can write their own > plugins for authorizing use of a public key. .. > would like feedback before submitting a patch (starting with > whether the community would want this). At FOSDEM we had a short discussion about a similar simple way of also extending host key lookups, in lieu of the more intrusive GSSAPI kex patch which seems to take a different approach. Maybe there's a chance to unify the key lookups a bit at the same time as doing this? //Peter From sxw at inf.ed.ac.uk Wed Feb 9 22:04:38 2011 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 9 Feb 2011 11:04:38 +0000 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: <20110209103828.13523.qmail@stuge.se> References: <20110209103828.13523.qmail@stuge.se> Message-ID: On 9 Feb 2011, at 10:38, Peter Stuge wrote: > At FOSDEM we had a short discussion about a similar simple way of > also extending host key lookups, in lieu of the more intrusive GSSAPI > kex patch which seems to take a different approach. The GSSAPI kex patch (an implementation of RFC4462) is designed to remove the need for host keys entirely, rather than just making it easier to verify that the key you've been given is valid. On large sites - and some of the sites with GSSAPI key exchange deployed have tens of thousands of machines - removing the need for ssh host key management is a significant saving. Cheers, Simon. From peter at stuge.se Wed Feb 9 23:17:46 2011 From: peter at stuge.se (Peter Stuge) Date: Wed, 9 Feb 2011 13:17:46 +0100 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: References: <20110209103828.13523.qmail@stuge.se> Message-ID: <20110209121746.28948.qmail@stuge.se> Simon Wilkinson wrote: >> At FOSDEM we had a short discussion about a similar simple way of >> also extending host key lookups, in lieu of the more intrusive GSSAPI >> kex patch which seems to take a different approach. > > The GSSAPI kex patch (an implementation of RFC4462) is designed to remove > the need for host keys entirely, rather than just making it easier to > verify that the key you've been given is valid. Right! We were briefly discussing why it might not yet have gotten included into OpenSSH. > On large sites - and some of the sites with GSSAPI key exchange > deployed have tens of thousands of machines - removing the need for > ssh host key management is a significant saving. Yes! Our thought was that maybe the same problem could be solved in a simpler fashion, not going quite all the way. Ie. still having host keys, but at least being able to validate them centrally using an already-acquired kerberos ticket. //Peter From dkg at fifthhorseman.net Thu Feb 10 02:35:54 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 09 Feb 2011 10:35:54 -0500 Subject: KnownHostsCommand [was: Re: Feature Request: Plugin Model for authorizing public keys] In-Reply-To: <20110209103828.13523.qmail@stuge.se> References: <20110209103828.13523.qmail@stuge.se> Message-ID: <4D52B45A.306@fifthhorseman.net> On 02/09/2011 05:38 AM, Peter Stuge wrote: > At FOSDEM we had a short discussion about a similar simple way of > also extending host key lookups, in lieu of the more intrusive GSSAPI > kex patch which seems to take a different approach. > > Maybe there's a chance to unify the key lookups a bit at the same > time as doing this? There is an open ticket requesting a KnownHostsCommand feature for the ssh client: https://bugzilla.mindrot.org/show_bug.cgi?id=KnownHostsCommand Alas, no one has written up a patch for it yet. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From mark.cavage at joyent.com Thu Feb 10 03:26:55 2011 From: mark.cavage at joyent.com (Mark Cavage) Date: Wed, 9 Feb 2011 08:26:55 -0800 Subject: Feature Request: Plugin Model for authorizing public keys In-Reply-To: <20110209121746.28948.qmail@stuge.se> References: <20110209103828.13523.qmail@stuge.se><20110209121746.28948.qmail@stuge.se> Message-ID: The purpose of this patch was to enable cases where there is not a Kerberos deployment to manage keys centrally. So, I don't view this and the kex patch as mutually exclusive. I read through the bugzilla report regarding AuthorizedKeysCommand; while my personal preference for this sort of mechanism is an in-process plugin, I'm obviously not on the core team and have no real concerns about that. I do think the semantics are not what I would have expected though, as having the facility to effectively generate an authorized_keys file on the fly is almost achievable with some clever crons anyway. I would make the case that the functionality I would want to see would be a process version of what I proposed originally; that is given a key/user pair, a boolean value is returned back to sshd. Also, I would want the existing authorized_keys file checks to run first, not later, since with distributed deployments I tend to think of per-host rules as overrides, as opposed to fallbacks. I won't argue as strongly on the second point however. What is the status/thoughts on the AuthorizedKeyCommand patch going into mainline? If it's already blessed and going to get merged in I can go ahead and create a patch off of that patch (assuming there is agreement to my proposal above); the ticket is over a year old though and being new to the list I don't know where that stands. ~Mark On Wed, Feb 9, 2011 at 4:17 AM, Peter Stuge wrote: > Simon Wilkinson wrote: >>> At FOSDEM we had a short discussion about a similar simple way of >>> also extending host key lookups, in lieu of the more intrusive GSSAPI >>> kex patch which seems to take a different approach. >> >> The GSSAPI kex patch (an implementation of RFC4462) is designed to remove >> the need for host keys entirely, rather than just making it easier to >> verify that the key you've been given is valid. > > Right! We were briefly discussing why it might not yet have gotten > included into OpenSSH. > > >> On large sites - and some of the sites with GSSAPI key exchange >> deployed have tens of thousands of machines - removing the need for >> ssh host key management is a significant saving. > > Yes! Our thought was that maybe the same problem could be solved in a > simpler fashion, not going quite all the way. Ie. still having host > keys, but at least being able to validate them centrally using an > already-acquired kerberos ticket. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From philipp_subx at redfish-solutions.com Thu Feb 10 10:06:02 2011 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 09 Feb 2011 15:06:02 -0800 Subject: QoS marking for Openssh (review wanted) In-Reply-To: <4BFD8DB4.1090000@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BDA3708.1040307@redfish-solutions.com> <4BFD8DB4.1090000@redfish-solutions.com> Message-ID: <4D531DDA.4030901@redfish-solutions.com> Well, it looks like my fix for QoS got badly mangled... which is what happens when it sits on the shelf for 10 months I suppose, so no surprise there. Looking at: $ cvs diff -u -r1.162 -r1.163 defines.h Index: defines.h =================================================================== RCS file: /cvs/openssh/defines.h,v retrieving revision 1.162 retrieving revision 1.163 diff -u -r1.162 -r1.163 --- defines.h 25 Oct 2010 05:54:28 -0000 1.162 +++ defines.h 23 Nov 2010 23:50:05 -0000 1.163 @@ -25,7 +25,7 @@ #ifndef _DEFINES_H #define _DEFINES_H -/* $Id: defines.h,v 1.162 2010/10/25 05:54:28 dtucker Exp $ */ +/* $Id: defines.h,v 1.163 2010/11/23 23:50:05 djm Exp $ */ /* Constants */ @@ -42,6 +42,9 @@ # define SHUT_RDWR SHUT_RDWR #endif +/* + * Definitions for IP type of service (ip_tos) + */ #ifndef IPTOS_LOWDELAY # define IPTOS_LOWDELAY 0x10 # define IPTOS_THROUGHPUT 0x08 @@ -49,6 +52,40 @@ # define IPTOS_LOWCOST 0x02 # define IPTOS_MINCOST IPTOS_LOWCOST #endif /* IPTOS_LOWDELAY */ + +/* + * Definitions for DiffServ Codepoints as per RFC2474 + */ +#include +#include +#ifndef IPTOS_DSCP_AF11 +# define IPTOS_DSCP_AF11 0x28 +# define IPTOS_DSCP_AF12 0x30 +# define IPTOS_DSCP_AF13 0x38 +# define IPTOS_DSCP_AF21 0x48 +# define IPTOS_DSCP_AF22 0x50 +# define IPTOS_DSCP_AF23 0x58 +# define IPTOS_DSCP_AF31 0x68 +# define IPTOS_DSCP_AF32 0x70 +# define IPTOS_DSCP_AF33 0x78 +# define IPTOS_DSCP_AF41 0x88 +# define IPTOS_DSCP_AF42 0x90 +# define IPTOS_DSCP_AF43 0x98 +# define IPTOS_DSCP_EF 0xb8 +#endif /* IPTOS_DSCP_AF11 */ +#ifndef IPTOS_DSCP_CS0 +# define IPTOS_DSCP_CS0 0x00 +# define IPTOS_DSCP_CS1 0x20 +# define IPTOS_DSCP_CS2 0x40 +# define IPTOS_DSCP_CS3 0x60 +# define IPTOS_DSCP_CS4 0x80 +# define IPTOS_DSCP_CS5 0xa0 +# define IPTOS_DSCP_CS6 0xc0 +# define IPTOS_DSCP_CS7 0xe0 +#endif /* IPTOS_DSCP_CS0 */ +#ifndef IPTOS_DSCP_EF +# define IPTOS_DSCP_EF 0xb8 +#endif /* IPTOS_DSCP_EF */ #ifndef MAXPATHLEN # ifdef PATH_MAX This is very different from the defines of IPTOS_CLASS_CS0 ... IPTOS_CLASS_CS7 which I had in my patch, and which I identified with the comment: /* * Temporarily needed file until glibc 2.12 becomes ubiquitous. */ So the provenance of the names would be clear, and exactly what we were trying to match against. Note also that the Class-Selectors predated the definition of Differentiated Services Code Points by several years, hence the different naming. I'll file a couple of bugs to fix this and another issue. Not sure if it's worth attaching a patch if it's going to end up being ignored and eventually replaced with some that introduced what can only euphemistically be called "divergence". -Philip On 5/26/10 2:08 PM, Philip A. Prindeville wrote: > Still being patient... do we have an estimate on when you might get to it? > > Thanks. > > > On 04/29/2010 08:03 PM, Damien Miller wrote: >> we'll get to it - please be patient. >> >> On Thu, 29 Apr 2010, Philip Prindeville wrote: >> >>> On 3/24/10 12:45 PM, Philip A. Prindeville wrote: >>>> Anyone want to code review: >>>> >>>> https://bugzilla.mindrot.org/show_bug.cgi?id=1733 >>>> >>>> There's a patch attached. We're currently using it on astlinux. >>>> >>>> Thanks. >>>> >>> Still looking to get a code-review and approval. >>> >>> Thanks. > From 1989.gaurav at googlemail.com Thu Feb 10 22:07:42 2011 From: 1989.gaurav at googlemail.com (gaurav gupta) Date: Thu, 10 Feb 2011 16:37:42 +0530 Subject: Behaviour of OpenSSH while login as root and non-root account In-Reply-To: References: Message-ID: Hello Friends, I am writing a PAM module for SSH to enforce one more layer of authentication. For that I need terminal ID in close_session() and pam_sm_setcred() function in PAM module while OpenSSH hardcoded it "ssh". I made few changes in OpenSSh code so it can set terminal ID properly. These changes were : added do_pam_set_tty() in session_pty_req(Session *s) function in session.c and added do_pam_set_tty() in mm_pty_allocate() function in monitor_wrap.c It works fine for root and I get appropriate tty in pam_sm_cred() and pam_sm_close_session() function. But using same code, when I try to ssh through a non root account I am getting tty in pam_sm_close_session() but not in pam_sm_cred(). I am not sure why ssh is behaving differently for root and non-root accounts. Is there anything which triggers SSH behavior for root and non-root accounts or can anyone suggest me what can be wrong here. I have no idea how can I proceed and it would be great if someone can give me some pointers. -- Thanks & Regards, Gaurav Gupta From alaric at caerllewys.net Fri Feb 11 00:35:21 2011 From: alaric at caerllewys.net (Brother Railgun of Reason) Date: Thu, 10 Feb 2011 08:35:21 -0500 Subject: Possible ssh -D bug in 5.8p1 (on Gentoo Linux) In-Reply-To: References: <20110207162516.GA18211@babylon5.babcom.com> Message-ID: <20110210133521.GA21697@babylon5.babcom.com> On Tue, Feb 08, 2011 at 07:57:55AM +1100, Damien Miller wrote: > On Mon, 7 Feb 2011, Brother Railgun of Reason wrote: > > > On Fri, Feb 04, 2011 at 12:26:08PM +1100, Damien Miller wrote: > > > OpenSSH 5.8 has just been released. It will be available from the > > > mirrors listed at http://www.openssh.com/ shortly. > > > > I seem to have found a bug in 5.8p1. [...] > That's pretty unlikely, because there was no channels or forwarding- > related code changed between 5.7 and 5.8. If you aren't using SELinux, > the substantive diff is literally one line in the key certification code. Seems the problem was specific to the Gentoo net-misc/openssh-5.8p1 ebuild. It is fixed in net-misc/openssh-5.8p1-r1. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 alaric at caerllewys.net alaric at metrocast.net phil at co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. From val.baranov at duke.edu Fri Feb 11 11:08:31 2011 From: val.baranov at duke.edu (Val baranov) Date: Fri, 11 Feb 2011 00:08:31 +0000 (UTC) Subject: Compilation error: SEVERE ERROR: Symbol =?utf-8?b?Q19CU1RBVA==?= (entry 2175) in object clientloop.o Message-ID: Previous version compiled successfully was 5.5p1. Now compiling 5.8p1 on the same machine "AIX 5.3 TL12 SP2" via GNU make with gcc 4.2.0 - got an error, can someone help with this? gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -L/usr/local/lib -Wl,-blibpath:/usr/lib:/lib: /usr/local/lib -lssh -lopenbsd-compat -lcrypto -lz ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2175) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2178) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2418) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2421) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2448) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2451) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2454) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2457) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2460) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2463) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2466) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2469) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2472) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2475) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2478) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2481) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2484) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2487) in object clientloop.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 708) in object sshtty.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 977) in object roaming_common.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 980) in object roaming_common.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1098) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1101) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1104) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1107) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1110) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1113) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1116) in object roaming_client.o: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 3393) in object ./libssh.a[channels.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 683) in object ./libssh.a[cipher-acss.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 750) in object ./libssh.a[cipher-acss.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 704) in object ./libssh.a[cipher-bf1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 731) in object ./libssh.a[cipher-bf1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 701) in object ./libssh.a[cipher-ctr.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 794) in object ./libssh.a[cipher-ctr.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 705) in object ./libssh.a[cipher-3des1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 798) in object ./libssh.a[cipher-3des1.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 904) in object ./libssh.a[hostfile.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 1148) in object ./libssh.a[hostfile.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 899) in object ./libssh.a[log.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2635) in object ./libssh.a[packet.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2638) in object ./libssh.a[packet.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 764) in object ./libssh.a[mac.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 859) in object ./libssh.a[mac.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 740) in object ./libssh.a[kexdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 763) in object ./libssh.a[kexdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 744) in object ./libssh.a[kexgex.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 768) in object ./libssh.a[kexgex.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 755) in object ./libssh.a[kexecdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 818) in object ./libssh.a[kexecdh.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 761) in object openbsd-compat//libopenbsd-compat.a[bsd-arc4random.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 745) in object openbsd-compat//libopenbsd-compat.a[readpassphrase.o]: The symbol refers to a csect with symbol number 0, which was not found. The new symbol cannot be associated with a csect and is being ignored. collect2: ld returned 12 exit status gmake: *** [ssh] Error 1 From djm at mindrot.org Fri Feb 11 13:01:10 2011 From: djm at mindrot.org (Damien Miller) Date: Fri, 11 Feb 2011 13:01:10 +1100 (EST) Subject: QoS marking for Openssh (review wanted) In-Reply-To: <4D531DDA.4030901@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BDA3708.1040307@redfish-solutions.com> <4BFD8DB4.1090000@redfish-solutions.com> <4D531DDA.4030901@redfish-solutions.com> Message-ID: On Wed, 9 Feb 2011, Philip Prindeville wrote: > This is very different from the defines of IPTOS_CLASS_CS0 ... IPTOS_CLASS_CS7 > which I had in my patch, and which I identified with the comment: > > /* > * Temporarily needed file until glibc 2.12 becomes ubiquitous. > */ > > So the provenance of the names would be clear, and exactly what we > were trying to match against. I used the defines available on BSD systems instead of glibc's. > Note also that the Class-Selectors predated the definition of > Differentiated Services Code Points by several years, hence the > different naming. > > I'll file a couple of bugs to fix this and another issue. What is the issue you are talking about? That we internally use different define names, or incorrect values? -d From djm at mindrot.org Fri Feb 11 13:02:31 2011 From: djm at mindrot.org (Damien Miller) Date: Fri, 11 Feb 2011 13:02:31 +1100 (EST) Subject: Behaviour of OpenSSH while login as root and non-root account In-Reply-To: References: Message-ID: On Thu, 10 Feb 2011, gaurav gupta wrote: > Hello Friends, > > I am writing a PAM module for SSH to enforce one more layer of > authentication. For that I need terminal ID in close_session() and > pam_sm_setcred() function in PAM module while OpenSSH hardcoded it "ssh". I > made few changes in OpenSSh code so it can set terminal ID properly. These > changes were : > > added do_pam_set_tty() in session_pty_req(Session *s) function in session.c > and added do_pam_set_tty() in mm_pty_allocate() function in monitor_wrap.c > > It works fine for root and I get appropriate tty in pam_sm_cred() and > pam_sm_close_session() function. > > But using same code, when I try to ssh through a non root account I am > getting tty in pam_sm_close_session() but not in pam_sm_cred(). I am not > sure why ssh is behaving differently for root and non-root accounts. > > Is there anything which triggers SSH behavior for root and non-root accounts > or can anyone suggest me what can be wrong here. I have no idea how can I > proceed and it would be great if someone can give me some pointers. Yes, post-auth privilege separation is skipped for root users. See Niels' paper for more details: http://www.citi.umich.edu/u/provos/papers/privsep.pdf From dtucker at zip.com.au Fri Feb 11 14:58:24 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Feb 2011 14:58:24 +1100 Subject: Compilation error: SEVERE ERROR: Symbol C_BSTAT (entry 2175) in object clientloop.o In-Reply-To: References: Message-ID: <4D54B3E0.20000@zip.com.au> On 11/02/11 11:08 AM, Val baranov wrote: > Previous version compiled successfully was 5.5p1. Now compiling 5.8p1 on > the same machine "AIX 5.3 TL12 SP2" via GNU make with gcc 4.2.0 - got > an error, can someone help with this? > > gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o > sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. > -Lopenbsd-compat/ -L/usr/local/lib -Wl,-blibpath:/usr/lib:/lib: > /usr/local/lib -lssh -lopenbsd-compat -lcrypto -lz > ld: 0711-593 SEVERE ERROR: Symbol C_BSTAT (entry 2175) in object > clientloop.o: It's a bug in either gcc or recent versions of AIX's linker that manifests with static variables when debug symbols are enabled. I suspect disabling debug symbols at build time would help: CFLAGS="-O2" ./configure && make but it's not been confirmed either way. http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-February/029298.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 -- 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 philipp_subx at redfish-solutions.com Fri Feb 11 15:05:33 2011 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 10 Feb 2011 20:05:33 -0800 Subject: QoS marking for Openssh (review wanted) In-Reply-To: References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BDA3708.1040307@redfish-solutions.com> <4BFD8DB4.1090000@redfish-solutions.com> <4D531DDA.4030901@redfish-solutions.com> Message-ID: <4D54B58D.1070007@redfish-solutions.com> On 2/10/11 6:01 PM, Damien Miller wrote: > On Wed, 9 Feb 2011, Philip Prindeville wrote: > >> This is very different from the defines of IPTOS_CLASS_CS0 ... IPTOS_CLASS_CS7 >> which I had in my patch, and which I identified with the comment: >> >> /* >> * Temporarily needed file until glibc 2.12 becomes ubiquitous. >> */ >> >> So the provenance of the names would be clear, and exactly what we >> were trying to match against. > I used the defines available on BSD systems instead of glibc's. > >> Note also that the Class-Selectors predated the definition of >> Differentiated Services Code Points by several years, hence the >> different naming. >> >> I'll file a couple of bugs to fix this and another issue. > What is the issue you are talking about? That we internally use different > define names, or incorrect values? > > -d Didn't have access to a BSD box at the time (it had a hard drive go bad), and didn't realize that BSD didn't use the same values as the glibc headers. The values that you used are correct. It's just a shame that there's a schism now between linux (and other platforms using glibc) and BSD. The other issue is that you're still using 'lowdelay' and 'throughput' as the default values, which were obsoleted in 1998... -Philip From bert.wesarg at googlemail.com Fri Feb 11 19:05:23 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Fri, 11 Feb 2011 09:05:23 +0100 Subject: experimental mercurial repository available In-Reply-To: References: Message-ID: Hi, On Mon, Jan 3, 2011 at 05:23, Damien Miller wrote: > Hi, > > Quite a few people have asked to be able to access OpenSSH sources using a > DVCS, so I have made a Mercurial repository available at > http://hg.mindrot.org/openssh > > You can fetch a copy using: > > ? ?hg clone http://hg.mindrot.org/openssh openssh > > You can also view the web interface directly, which might be handy for > fetching diffs of changesets to cherry-pick. > > The repository is synchronised from CVS using "hg convert" automatically > after every commit and updates within 30 minutes. The last update seems to be 2 weeks old. Does this experiment failed? I hope not. Bert From jchadima at redhat.com Sat Feb 12 08:40:11 2011 From: jchadima at redhat.com (Jan Chadima) Date: Fri, 11 Feb 2011 16:40:11 -0500 (EST) Subject: openssh-5.8p1 does not compille with --with-selinux In-Reply-To: <871824726.286621.1297460331662.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1251072402.286631.1297460411803.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi there is unpaired brackets in port_linux_compat.c in ssh_selinux_setfscreatecon if (path == NULL) setfscreatecon(NULL); return; } -- JFCh From djm at mindrot.org Sat Feb 12 17:29:38 2011 From: djm at mindrot.org (Damien Miller) Date: Sat, 12 Feb 2011 17:29:38 +1100 (EST) Subject: experimental mercurial repository available In-Reply-To: References: Message-ID: On Fri, 11 Feb 2011, Bert Wesarg wrote: > Hi, > > On Mon, Jan 3, 2011 at 05:23, Damien Miller wrote: > > Hi, > > > > Quite a few people have asked to be able to access OpenSSH sources using a > > DVCS, so I have made a Mercurial repository available at > > http://hg.mindrot.org/openssh > > > > You can fetch a copy using: > > > > hg clone http://hg.mindrot.org/openssh openssh > > > > You can also view the web interface directly, which might be handy for > > fetching diffs of changesets to cherry-pick. > > > > The repository is synchronised from CVS using "hg convert" automatically > > after every commit and updates within 30 minutes. > > The last update seems to be 2 weeks old. Does this experiment failed? > I hope not. No, I had just failed to add the magic command lines to let me push updates after creating a new branch. It should be fixed and syncing again now. -d From bert.wesarg at googlemail.com Tue Feb 15 03:56:05 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 14 Feb 2011 17:56:05 +0100 Subject: [PATCH] ssh: set proctitle for mux master In-Reply-To: References: Message-ID: On Mon, Feb 7, 2011 at 22:11, Bert Wesarg wrote: > Preserving the command line from the invoking ssh command doesn't > make much sense, so use setproctitle() to hide the arguments. > --- > ?ssh.c | ? 20 +++++++++++++++++--- > ?1 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/ssh.c b/ssh.c > index d32ef78..8ebcc88 100644 > --- a/ssh.c > +++ b/ssh.c > @@ -230,12 +230,25 @@ main(int ac, char **av) > ? ? ? ?struct servent *sp; > ? ? ? ?Forward fwd; > > - ? ? ? /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ > - ? ? ? sanitise_stdfd(); > - > ? ? ? ?__progname = ssh_get_progname(av[0]); > ? ? ? ?init_rng(); > > +#ifndef HAVE_SETPROCTITLE > + ? ? ? /* Prepare for later setproctitle emulation */ > + ? ? ? { > + ? ? ? ? ? ? ? /* Save argv. Duplicate so setproctitle emulation doesn't clobber it */ > + ? ? ? ? ? ? ? char **saved_argv = xcalloc(ac + 1, sizeof(*saved_argv)); > + ? ? ? ? ? ? ? for (i = 0; i < ac; i++) > + ? ? ? ? ? ? ? ? ? ? ? saved_argv[i] = xstrdup(av[i]); > + ? ? ? ? ? ? ? saved_argv[i] = NULL; > + ? ? ? ? ? ? ? compat_init_setproctitle(ac, av); > + ? ? ? ? ? ? ? av = saved_argv; > + ? ? ? } > +#endif > + > + ? ? ? /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ > + ? ? ? sanitise_stdfd(); > + > ? ? ? ?/* > ? ? ? ? * Discard other fds that are hanging around. These can cause problem > ? ? ? ? * with backgrounded ssh processes started by ControlPersist. > @@ -965,6 +978,7 @@ control_persist_detach(void) > ? ? ? ? ? ? ? ?if (devnull > STDERR_FILENO) > ? ? ? ? ? ? ? ? ? ? ? ?close(devnull); > ? ? ? ?} > + ? ? ? setproctitle("%s [mux]", options.control_path); I would also suggest that the mux master chdir into /. Bert > ?} > > ?/* Do fork() after authentication. Used by "ssh -f" */ > -- > 1.7.3.3.1603.g7f137 > > From cyrille.lefevre-lists at laposte.net Wed Feb 16 09:48:20 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Tue, 15 Feb 2011 23:48:20 +0100 Subject: feature request In-Reply-To: <4D51AE52.2020503@laposte.net> References: <4D506A8D.7070603@laposte.net> <20110208004142.GC4614@linux124.nas.nasa.gov> <4D510FC1.3010408@laposte.net> <4D5164A1.2080200@databit7.com> <4D51AE52.2020503@laposte.net> Message-ID: <4D5B02B4.1090309@laposte.net> Le 08/02/2011 21:57, Cyrille Lefevre a ?crit : > Le 08/02/2011 16:43, Robin David Hammond a ?crit : >> perhaps you can use netcat as an interim measure. > > also tried w/o success. another problem is the port assignment, > the more you need extra dfs, the more you need netcat processes and > ports. also, same problem as netpipes, not available anywhere. > > IMHO, the inside ssh solution is the more appropriate since anything > seems to be here, if ssh maintainers are ok to integrate this feature, I > may > try to add it to ssh. up Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From sfandino at yahoo.com Wed Feb 16 21:19:39 2011 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 16 Feb 2011 11:19:39 +0100 Subject: feature request In-Reply-To: <4D506A8D.7070603@laposte.net> References: <4D506A8D.7070603@laposte.net> Message-ID: On 02/07/2011 10:56 PM, Cyrille Lefevre wrote: > > Hi, > > how about to provide a simple way to forward raw file descriptors > through ssh tunnels. > > something which may provide a way to write something like : > > (echo 3; read > out3) |& > exec 3<&p 4>&p > echo 5 >| out5 > exec 5<> out5 > echo 1 | > ssh -d 3:rd -d 4:wr -d 5:rw ' > read <&3; echo $REPLY >&4 > read; echo $REPLY > read <&5; echo $REPLY >&5 > ' > out1 > > the expected result is 1 in out1, 3 in out3 and 5\n5 in out5. > > PS : hope the sample is right :-) > > Regards, > > Cyrille Lefevre Being able to forward extra streams could also be used to forward /dev/pty decoupled from stdin and stdout. For instance, with the current implementation, if the following command... $ ssh foo -t ssh bar cat /var/data >/tmp/data ... is run from some account requiring password authentication on "bar" the password prompt generated by the ssh client running on "foo" doesn't appear on the local console but goes into "/tmp/data". Also, on some operating systems (i.e. HP-UX or AIX) ptys are not reliable and may silently drop data when internal buffers overflow so piping data trough them as in the example above may corrupt the local "/tmp/data". A decoupled forwarding of /dev/pty would solve both problems. - Salva From oren at held.org.il Wed Feb 16 21:27:36 2011 From: oren at held.org.il (Oren Held) Date: Wed, 16 Feb 2011 12:27:36 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 Message-ID: <20110216102735.GB12486@orenhe-laptop> Hi, As I haven't seen any related discussion here (or bug in bugzilla), I thought it'll be good to do a heads-up for a recently introduced problem in 5.8p1 (or at least after 5.5.x). Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 Arch Linux: https://bugs.archlinux.org/task/22897?project=1 Any other information needed? Shall I file a bug in bugzilla? Best Regards Oren From dtucker at zip.com.au Wed Feb 16 21:46:07 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Feb 2011 21:46:07 +1100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216102735.GB12486@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> Message-ID: <4D5BAAEF.3040002@zip.com.au> On 16/02/11 9:27 PM, Oren Held wrote: > Hi, > > As I haven't seen any related discussion here (or bug in bugzilla), I thought > it'll be good to do a heads-up for a recently introduced problem in 5.8p1 (or at > least after 5.5.x). > > Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 > Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 > Arch Linux: https://bugs.archlinux.org/task/22897?project=1 > > Any other information needed? Shall I file a bug in bugzilla? Can you reproduce the problem with an unmodified tarball from openssh.com? -- 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 oren at held.org.il Wed Feb 16 22:03:10 2011 From: oren at held.org.il (Oren Held) Date: Wed, 16 Feb 2011 13:03:10 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5BAAEF.3040002@zip.com.au> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> Message-ID: <20110216110309.GD12486@orenhe-laptop> On Wed, Feb 16, 2011 at 09:46:07PM +1100, Darren Tucker wrote: > On 16/02/11 9:27 PM, Oren Held wrote: > >Hi, > > > >As I haven't seen any related discussion here (or bug in bugzilla), I thought > >it'll be good to do a heads-up for a recently introduced problem in 5.8p1 (or at > >least after 5.5.x). > > > >Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 > >Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 > >Arch Linux: https://bugs.archlinux.org/task/22897?project=1 > > > >Any other information needed? Shall I file a bug in bugzilla? > > Can you reproduce the problem with an unmodified tarball from openssh.com? Yes. I've just compiled a "vanilla" 5.8p1, and same result: orenhe at orenhe-laptop:/tmp/openssh-5.8p1$ /opt/ssh/bin/ssh root at blade-8.ps Read from socket failed: Connection reset by peer As for my compile flags, I used simple ./configure --prefix=/opt/ssh: User binaries: /opt/ssh/bin System binaries: /opt/ssh/sbin Configuration files: /opt/ssh/etc Askpass program: /opt/ssh/libexec/ssh-askpass Manual pages: /opt/ssh/share/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/opt/ssh/bin Manpage format: doc PAM support: no OSF SIA support: no KerberosV support: no SELinux support: no Smartcard support: S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no Solaris process contract support: no Solaris project support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY From dtucker at zip.com.au Thu Feb 17 00:27:04 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Feb 2011 00:27:04 +1100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216110309.GD12486@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> Message-ID: <4D5BD0A8.20306@zip.com.au> On 16/02/11 10:03 PM, Oren Held wrote: > On Wed, Feb 16, 2011 at 09:46:07PM +1100, Darren Tucker wrote: >> On 16/02/11 9:27 PM, Oren Held wrote: >>> Hi, >>> >>> As I haven't seen any related discussion here (or bug in bugzilla), I thought >>> it'll be good to do a heads-up for a recently introduced problem in 5.8p1 (or at >>> least after 5.5.x). >>> >>> Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 >>> Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 >>> Arch Linux: https://bugs.archlinux.org/task/22897?project=1 >>> >>> Any other information needed? Shall I file a bug in bugzilla? >> >> Can you reproduce the problem with an unmodified tarball from openssh.com? > > Yes. I've just compiled a "vanilla" 5.8p1, and same result: > > orenhe at orenhe-laptop:/tmp/openssh-5.8p1$ /opt/ssh/bin/ssh root at blade-8.ps > Read from socket failed: Connection reset by peer When this happens, does it happen immediately or is there a delay before you get the "reset by peer" ? Could you please collect both server and client side debug output? (note that you'll need to use sshd -ddde to make sure you get all the server output on stderr) -- 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 oren at held.org.il Thu Feb 17 00:52:24 2011 From: oren at held.org.il (Oren Held) Date: Wed, 16 Feb 2011 15:52:24 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5BD0A8.20306@zip.com.au> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> Message-ID: <20110216135222.GF12486@orenhe-laptop> On Thu, Feb 17, 2011 at 12:27:04AM +1100, Darren Tucker wrote: > On 16/02/11 10:03 PM, Oren Held wrote: > >On Wed, Feb 16, 2011 at 09:46:07PM +1100, Darren Tucker wrote: > >>On 16/02/11 9:27 PM, Oren Held wrote: > >>>Hi, > >>> > >>>As I haven't seen any related discussion here (or bug in bugzilla), I thought > >>>it'll be good to do a heads-up for a recently introduced problem in 5.8p1 (or at > >>>least after 5.5.x). > >>> > >>>Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 > >>>Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 > >>>Arch Linux: https://bugs.archlinux.org/task/22897?project=1 > >>> > >>>Any other information needed? Shall I file a bug in bugzilla? > >> > >>Can you reproduce the problem with an unmodified tarball from openssh.com? > > > >Yes. I've just compiled a "vanilla" 5.8p1, and same result: > > > >orenhe at orenhe-laptop:/tmp/openssh-5.8p1$ /opt/ssh/bin/ssh root at blade-8.ps > >Read from socket failed: Connection reset by peer > > When this happens, does it happen immediately or is there a delay > before you get the "reset by peer" ? Yes. It's very quick. > Could you please collect both server and client side debug output? > (note that you'll need to use sshd -ddde to make sure you get all > the server output on stderr) Attaching two files, one for the server's log and one for the client's. One more note: the problem occurs when SSHing to *older* servers (I tried 4.3p2, 5.1p1). When SSHing to v5.8p1 it works smoothly. -------------- next part -------------- debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 517 debug2: parse_server_config: config /etc/ssh/sshd_config len 517 debug1: sshd version OpenSSH_4.3p2 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddde' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2222' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2222 on ::. Server listening on :: port 2222. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 2222 on 0.0.0.0. Bind to port 2222 on 0.0.0.0 failed: Address already in use. debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 517 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug3: recv_rexec_state: done debug2: parse_server_config: config rexec len 517 debug1: sshd version OpenSSH_4.3p2 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: inetd sockets after dupping: 3, 3 debug3: Normalising mapped IPv4 in IPv6 address Connection from 9.151.133.53 port 46862 debug1: Client protocol version 2.0; client software version OpenSSH_5.8 debug1: match: OpenSSH_5.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug2: Network child is on pid 1403 debug3: preauth child monitor started debug3: mm_request_receive entering Read from socket failed: Connection reset by peer debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering -------------- next part -------------- OpenSSH_5.8p1, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /home/orenhe/.ssh/config debug1: Reading configuration data /opt/ssh/etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to blade-8.ps [9.151.146.103] port 2222. debug1: Connection established. debug1: identity file /home/orenhe/.ssh/id_rsa type -1 debug1: identity file /home/orenhe/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/orenhe/.ssh/id_dsa" as a RSA1 public key debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' 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 debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/orenhe/.ssh/id_dsa type 2 debug1: identity file /home/orenhe/.ssh/id_dsa-cert type -1 debug1: identity file /home/orenhe/.ssh/id_ecdsa type -1 debug1: identity file /home/orenhe/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [blade-8.ps]:2222 debug3: load_hostkeys: loading entries for host "[blade-8.ps]:2222" from file "/home/orenhe/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,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-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 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Write failed: Connection reset by peer From dtucker at zip.com.au Thu Feb 17 01:42:45 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Feb 2011 01:42:45 +1100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216135222.GF12486@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> Message-ID: <4D5BE265.9030906@zip.com.au> On 17/02/11 12:52 AM, Oren Held wrote: [...] > One more note: the problem occurs when SSHing to *older* servers (I tried 4.3p2, > 5.1p1). When SSHing to v5.8p1 it works smoothly. I have tried to reproduce with fresh-built 4.3p1 and 5.1p1 servers and failed. Are the servers configured with any non-default options or source code changes? -- 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 oren at held.org.il Thu Feb 17 08:15:35 2011 From: oren at held.org.il (Oren Held) Date: Wed, 16 Feb 2011 23:15:35 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5BE265.9030906@zip.com.au> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> Message-ID: <20110216211533.GA25449@orenhe-laptop> On Thu, Feb 17, 2011 at 01:42:45AM +1100, Darren Tucker wrote: > On 17/02/11 12:52 AM, Oren Held wrote: > [...] > >One more note: the problem occurs when SSHing to *older* servers (I tried 4.3p2, > >5.1p1). When SSHing to v5.8p1 it works smoothly. > > I have tried to reproduce with fresh-built 4.3p1 and 5.1p1 servers > and failed. Are the servers configured with any non-default options > or source code changes? New findings: it happens only when compiling and running *the server* on relatively old environments: e.g. RedHat 5.5, and I think that also Debian Lenny (5.0.8). While the client is running on a new environment (Debian sid, aka unstable) It even happened when connecting from 5.8p1 on my Debian unstable to 5.8p1 (same version!) on RHEL5.5. - Both are x86_64 OSes. - Both were vanilla openssh that I compiled by myself with no special compile parameters. - (Server) Happened even when sshd_config was empty but also with the default RHEL one - (Client) happened with empty ~/.ssh and no /etc/ssh_config I'm starting to suspect it has to do with some library and not openssh itself. ldd spotted some notable difference: Server is linked to libcrypto.so.6 (RHEL5 default) Client is linkde to libcrypto.so.0.9.8 (Debian sid default) From cyrille.lefevre-lists at laposte.net Thu Feb 17 08:25:46 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Wed, 16 Feb 2011 22:25:46 +0100 Subject: feature request In-Reply-To: References: <4D506A8D.7070603@laposte.net> Message-ID: <4D5C40DA.50206@laposte.net> Le 16/02/2011 11:19, Salvador Fandino a ?crit : > For instance, with the current implementation, if the following command... > > $ ssh foo -t ssh bar cat /var/data>/tmp/data > > ... is run from some account requiring password authentication on "bar" > the password prompt generated by the ssh client running on "foo" doesn't > appear on the local console but goes into "/tmp/data". I suspect you reached the problem described here... subject : su password prompt to stdout instead of /dev/tty http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/054560.html which os are you running ? are you using pam ? Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From cyrille.lefevre-lists at laposte.net Thu Feb 17 08:35:34 2011 From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre) Date: Wed, 16 Feb 2011 22:35:34 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216135222.GF12486@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> Message-ID: <4D5C4326.1030803@laposte.net> Le 16/02/2011 14:52, Oren Held a ?crit : >> Could you please collect both server and client side debug output? >> (note that you'll need to use sshd -ddde to make sure you get all >> the server output on stderr) on the server side, binding to IPv6 seems to be ok. debug1: Bind to port 2222 on ::. Server listening on :: port 2222. but why can't you bind to port 2222 IPv4 ? debug1: Bind to port 2222 on 0.0.0.0. Bind to port 2222 on 0.0.0.0 failed: Address already in use. could you try another port or kill the other process waiting on this port and try again ? your client side try to connect to IPv4 which isn't listenning, so the connexion is dropped. debug1: Connecting to blade-8.ps [9.151.146.103] port 2222. try ssh -6 if possible. Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists at laposte.net From oren at held.org.il Thu Feb 17 10:30:18 2011 From: oren at held.org.il (Oren Held) Date: Thu, 17 Feb 2011 01:30:18 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216211533.GA25449@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> Message-ID: <20110216233017.GC29655@orenhe-laptop> On Wed, Feb 16, 2011 at 11:15:35PM +0200, Oren Held wrote: > On Thu, Feb 17, 2011 at 01:42:45AM +1100, Darren Tucker wrote: > > On 17/02/11 12:52 AM, Oren Held wrote: > > [...] > > >One more note: the problem occurs when SSHing to *older* servers (I tried 4.3p2, > > >5.1p1). When SSHing to v5.8p1 it works smoothly. > > > > I have tried to reproduce with fresh-built 4.3p1 and 5.1p1 servers > > and failed. Are the servers configured with any non-default options > > or source code changes? [...] > > I'm starting to suspect it has to do with some library and not openssh itself. > ldd spotted some notable difference: > Server is linked to libcrypto.so.6 (RHEL5 default) > Client is linkde to libcrypto.so.0.9.8 (Debian sid default) Additionally, I've refined the diff's: 5.6p1 connects perfectly well to all ssh servers, the problem begins with 5.7p1. From dtucker at zip.com.au Thu Feb 17 14:00:32 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Feb 2011 14:00:32 +1100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5C4326.1030803@laposte.net> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5C4326.1030803@laposte.net> Message-ID: <4D5C8F50.9000105@zip.com.au> On 17/02/11 8:35 AM, Cyrille Lefevre wrote: > debug1: Bind to port 2222 on ::. > Server listening on :: port 2222. > > but why can't you bind to port 2222 IPv4 ? On some platforms (eg Linux) listening on an IPv6 socket will also get you IPv4 connections as mapped 4-in-6 addresses. sshd will latter unmap it (look for ipv64_normalise_mapped in canohost.c). It's not related to the problem in this thread. -- 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 vinschen at redhat.com Thu Feb 17 22:34:48 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 17 Feb 2011 12:34:48 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110216233017.GC29655@orenhe-laptop> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> Message-ID: <20110217113448.GA29762@calimero.vinschen.de> On Feb 17 01:30, Oren Held wrote: > On Wed, Feb 16, 2011 at 11:15:35PM +0200, Oren Held wrote: > > On Thu, Feb 17, 2011 at 01:42:45AM +1100, Darren Tucker wrote: > > > On 17/02/11 12:52 AM, Oren Held wrote: > > > [...] > > > >One more note: the problem occurs when SSHing to *older* servers (I tried 4.3p2, > > > >5.1p1). When SSHing to v5.8p1 it works smoothly. > > > > > > I have tried to reproduce with fresh-built 4.3p1 and 5.1p1 servers > > > and failed. Are the servers configured with any non-default options > > > or source code changes? > > [...] > > > > I'm starting to suspect it has to do with some library and not openssh itself. > > ldd spotted some notable difference: > > Server is linked to libcrypto.so.6 (RHEL5 default) > > Client is linkde to libcrypto.so.0.9.8 (Debian sid default) > > Additionally, I've refined the diff's: 5.6p1 connects perfectly well to all > ssh servers, the problem begins with 5.7p1. As an additional datapoint, we had a couple of similar bug reports after I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of them even comes with a set of debug output of working (5.6p1) and non-working (5.8p1) connection attempts: http://cygwin.com/ml/cygwin/2011-02/msg00317.html Another one just shows the output of a failed attempt: http://cygwin.com/ml/cygwin/2011-02/msg00233.html However, I tried with various older versions of SSH running on Cygwin, Linux and Solaris to connect from 5.8p1 myself, and I'm unable to reproduce this problem. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Thu Feb 17 23:27:47 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Feb 2011 23:27:47 +1100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110217113448.GA29762@calimero.vinschen.de> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> Message-ID: <4D5D1443.6050101@zip.com.au> On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > As an additional datapoint, we had a couple of similar bug reports after > I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > them even comes with a set of debug output of working (5.6p1) and > non-working (5.8p1) connection attempts: [...] > However, I tried with various older versions of SSH running on Cygwin, > Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > reproduce this problem. Thanks for the extra info. I haven't been able to reproduce either. I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle missing... I diffed the working and non working clients, and one difference is: debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY although I'm not sure that's significant since Oren's output had SSH2_MSG_KEX_DH_GEX_GROUP. You could try forcing it with "ssh -vvv -o KexAlgorithms=diffie-hellman-group-exchange-sha1 server" (aside: I now want to add OpenSSL's version output to the server debug output) -- 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 ndk.clanbo at gmail.com Thu Feb 17 22:49:50 2011 From: ndk.clanbo at gmail.com (NdK) Date: Thu, 17 Feb 2011 12:49:50 +0100 Subject: PKCS11: selecting which key to use Message-ID: <4D5D0B5E.3020208@gmail.com> Hello. Just popping in (not subscribed, please CC) to ask if it's planned to add "identity selection" when using a PKCS#11 provider. To be more clear: I have a (working) reader+smartcard, handled by PKCS11Provider /usr/lib/opensc-pkcs11.so statement in config file. Card is "formatted" w/ "pkcs15-init -C", and got a couple PINs, some mail certs and some keypairs added. Seems it works as expected *IF* the only (or first) on-card keypair is the one to be used for SSH. If it's after other keys/certs there's no way (I know of) to avoid testing all the preceeding keys (that's really heavy: I have had 58 2048bit RSA keypairs on a single MyEID card during test phase!). The result is that I always get a "Too many authentication failures" error. Maybe a semantic extension for '-i' parameter, to use the given key ID? Please, don't tell me "use a card only for SSH"... That would be just a workaround and a real waste (of money and resources)... Tks. BYtE! From vinschen at redhat.com Fri Feb 18 01:25:32 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 17 Feb 2011 15:25:32 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5D1443.6050101@zip.com.au> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> Message-ID: <20110217142532.GF29762@calimero.vinschen.de> On Feb 17 23:27, Darren Tucker wrote: > On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > >As an additional datapoint, we had a couple of similar bug reports after > >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > >them even comes with a set of debug output of working (5.6p1) and > >non-working (5.8p1) connection attempts: > [...] > >However, I tried with various older versions of SSH running on Cygwin, > >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > >reproduce this problem. > > Thanks for the extra info. I haven't been able to reproduce either. > I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL > 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle > missing... What I'm missing in the debug output is a clear statement of the side which closes the connection, *why* the connection has been closed. In Andrew's debug output The server side just contains: debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Read from socket failed: Software caused connection abort and the client side just contains: debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer In Oren's debug output, server: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Write failed: Connection reset by peer client: debug1: SSH2_MSG_KEXINIT sent debug2: Network child is on pid 1403 debug3: preauth child monitor started debug3: mm_request_receive entering Read from socket failed: Connection reset by peer What happened here? The socket got closed, but why? In theory at least one side of the connection should know... Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From laurent at ksperis.com Fri Feb 18 03:38:36 2011 From: laurent at ksperis.com (Laurent Barbe) Date: Thu, 17 Feb 2011 17:38:36 +0100 Subject: pkcs11 : extract pubkey from x509 certificates Message-ID: <1297960716.27836.26.camel@BENCH496> Hello all, About PKCS11, some provider allows only the use of X509 certificate. Are there plans to add the ability to extract the public key from certificates when there is no public key? Thank you Sincerely, Laurent From dkg at fifthhorseman.net Fri Feb 18 03:49:47 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 17 Feb 2011 11:49:47 -0500 Subject: pkcs11 : extract pubkey from x509 certificates In-Reply-To: <1297960716.27836.26.camel@BENCH496> References: <1297960716.27836.26.camel@BENCH496> Message-ID: <4D5D51AB.8000409@fifthhorseman.net> On 02/17/2011 11:38 AM, Laurent Barbe wrote: > About PKCS11, some provider allows only the use of X509 > certificate. > Are there plans to add the ability to extract the public key from > certificates when there is no public key? I'm not sure this question makes sense. All X.509 certificates have a public key (the subject's public key) in them by definition. Do you mean something else? (apologies if this is a simple typo that i should be able to guess what you mean -- this stuff is confusing enough that being really clear and explicit is helpful, though) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From sbade at austin.ibm.com Fri Feb 18 03:59:19 2011 From: sbade at austin.ibm.com (Steven Bade) Date: Thu, 17 Feb 2011 11:59:19 -0500 Subject: pkcs11 : extract pubkey from x509 certificates In-Reply-To: <4D5D51AB.8000409@fifthhorseman.net> References: <1297960716.27836.26.camel@BENCH496> <4D5D51AB.8000409@fifthhorseman.net> Message-ID: <4D5D53E7.6070305@austin.ibm.com> Daniel Kahn Gillmor wrote: > On 02/17/2011 11:38 AM, Laurent Barbe wrote: >> About PKCS11, some provider allows only the use of X509 >> certificate. >> Are there plans to add the ability to extract the public key from >> certificates when there is no public key? > > I'm not sure this question makes sense. All X.509 certificates have a > public key (the subject's public key) in them by definition. > > Do you mean something else? (apologies if this is a simple typo that i > should be able to guess what you mean -- this stuff is confusing enough > that being really clear and explicit is helpful, though) > > --dkg > > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev I think that they are saying that the PKCS#11 token will not allow access to the public key object (it may not even exist), some tokens only allow access to the public key through the certificate object.. but its been a while since i've delved into P11 in great detail. I know the implementations I worked on allowed access to the public key object. From cjc5 at cwru.edu Fri Feb 18 02:17:26 2011 From: cjc5 at cwru.edu (Craig J Copi) Date: Thu, 17 Feb 2011 10:17:26 -0500 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110217142532.GF29762@calimero.vinschen.de> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110217142532.GF29762@calimero.vinschen.de> Message-ID: <20110217151726.896792771D@aether.phys.cwru.edu> In message <20110217142532.GF29762 at calimero.vinschen.de>, Corinna Vinschen writes: >What I'm missing in the debug output is a clear statement of the >side which closes the connection, *why* the connection has been >closed. In Andrew's debug output The server side just contains: I have seen something similar but attributed it to a local error (undiscovered source). I have 3 OpenBSD machines and 2 Ubuntu machines all running 5.8. All can ssh to each other EXCEPT to one of the ubuntu machines. The two ubuntu machines should be identical (same versions of the distribution, same configuration files, ...). My "solution" was to put HostKeyAlgorithms ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss in my ~/.ssh/config file. In particular I found that removing the keys ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com allows for all machines to interconnect. I don't know why this is the case. Craig From laurent at ksperis.com Fri Feb 18 05:08:51 2011 From: laurent at ksperis.com (Laurent Barbe) Date: Thu, 17 Feb 2011 19:08:51 +0100 Subject: pkcs11 : extract pubkey from x509 certificates In-Reply-To: <4D5D53E7.6070305@austin.ibm.com> References: <1297960716.27836.26.camel@BENCH496> <4D5D51AB.8000409@fifthhorseman.net> <4D5D53E7.6070305@austin.ibm.com> Message-ID: <1297966131.1857.37.camel@mini9> Yes, the certificates do contain the public key. I'll try to be a little more specific: The problem is that openssh does not seem to find them and use them. For example, I made tests with tokens of 72k at SafeNet (formerly Aladdin), the pkcs11 libeTPkcs11.so provided by the middleware Safenet does not list the public key certificates only. In the search function objects ssh-pkcs11.c:pkcs11_fetch_keys() the object to search is public key and not certificates : line 400: "CK_OBJECT_CLASS pubkey_class = CKO_PUBLIC_KEY;" and not "CKO_CERTIFICATE. It is therefore not able to retrieve the public key of certificates, and for these tokens I am not able to store key RSA classics. I do not know much about the structure and functioning of pkcs11, perhaps someone can tell me. On versions <5.4 with the patch pkcs11 Alon Bar-Lev, without the support X.509, such use was possible. On Windows, Putty-CAC is also able to retrieve public key from certificates, unlike PuttySC. "Public certificates include public keys, but the implementation in PuTTY SC will not extract those public keys from the certificates. PuTTY-CAC fixes this." http://www.risacher.org/putty-cac/ Sincerly, Laurent Le jeudi 17 f?vrier 2011 ? 11:59 -0500, Steven Bade a ?crit : > Daniel Kahn Gillmor wrote: > > On 02/17/2011 11:38 AM, Laurent Barbe wrote: > >> About PKCS11, some provider allows only the use of X509 > >> certificate. > >> Are there plans to add the ability to extract the public key from > >> certificates when there is no public key? > > > > I'm not sure this question makes sense. All X.509 certificates have a > > public key (the subject's public key) in them by definition. > > > > Do you mean something else? (apologies if this is a simple typo that i > > should be able to guess what you mean -- this stuff is confusing enough > > that being really clear and explicit is helpful, though) > > > > --dkg > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > I think that they are saying that the PKCS#11 token will not allow > access to the public key object (it may not even exist), some tokens > only allow access to the public key through the certificate object.. but > its been a while since i've delved into P11 in great detail. I know the > implementations I worked on allowed access to the public key object. From laurent at ksperis.com Fri Feb 18 07:08:42 2011 From: laurent at ksperis.com (Laurent Barbe) Date: Thu, 17 Feb 2011 21:08:42 +0100 Subject: pkcs11 : extract pubkey from x509 certificates In-Reply-To: <4D5D53E7.6070305@austin.ibm.com> References: <1297960716.27836.26.camel@BENCH496> <4D5D51AB.8000409@fifthhorseman.net> <4D5D53E7.6070305@austin.ibm.com> Message-ID: <1297973322.2024.2.camel@mini9> Sorry, I had not seen your answer. Yes, that is what I meant. I just have a look to the sources, do you think it would be complex to implement ? Thank you. Laurent Le jeudi 17 f?vrier 2011 ? 11:59 -0500, Steven Bade a ?crit : > Daniel Kahn Gillmor wrote: > > On 02/17/2011 11:38 AM, Laurent Barbe wrote: > >> About PKCS11, some provider allows only the use of X509 > >> certificate. > >> Are there plans to add the ability to extract the public key from > >> certificates when there is no public key? > > > > I'm not sure this question makes sense. All X.509 certificates have a > > public key (the subject's public key) in them by definition. > > > > Do you mean something else? (apologies if this is a simple typo that i > > should be able to guess what you mean -- this stuff is confusing enough > > that being really clear and explicit is helpful, though) > > > > --dkg > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > I think that they are saying that the PKCS#11 token will not allow > access to the public key object (it may not even exist), some tokens > only allow access to the public key through the certificate object.. but > its been a while since i've delved into P11 in great detail. I know the > implementations I worked on allowed access to the public key object. From peter at stuge.se Fri Feb 18 13:52:11 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Feb 2011 03:52:11 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <4D5D0B5E.3020208@gmail.com> References: <4D5D0B5E.3020208@gmail.com> Message-ID: <20110218025211.26342.qmail@stuge.se> NdK wrote: > Just popping in (not subscribed, please CC) to ask if it's planned to > add "identity selection" when using a PKCS#11 provider. For lack of better alternatives I guess PKCS#11 URI may be the way to go. //Peter From ndk.clanbo at gmail.com Fri Feb 18 16:40:43 2011 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 18 Feb 2011 06:40:43 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <20110218025211.26342.qmail@stuge.se> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> Message-ID: <4D5E065B.4060305@gmail.com> On 18/02/2011 03:52, Peter Stuge wrote: >> Just popping in (not subscribed, please CC) to ask if it's planned to >> add "identity selection" when using a PKCS#11 provider. > For lack of better alternatives I guess PKCS#11 URI may be the way to go. Uhm... remember that there already are at least four ways to identify a specific key on a card: - by key ID (combined w/ "slot" or not, whatever is your idea of what a "slot" is) - by label - by matching part of certificate CN - by file path I don't like the first if it's used as slot:id 'cause "slot" is not well defined (is it a key or a PIN? I could find both interpretations). If w/o slot it could be ambiguous if the same key ID is on more than one card (quite a rare case: needs multiple readers connected). The second is IMVHO the most versatile, just a mnemonic ID... same cons of using ID. The third is like the second, but even less probable to have the same cert on multiple cards. But it requires to setup a CA to issue certs, or have certs issued by an external CA. The fourth is IMHO too "low level" to be actually useful, but could be used to say "always use the first key on card"... What could a pkcs11 URI look like? BYtE! From peter at stuge.se Fri Feb 18 16:58:35 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Feb 2011 06:58:35 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <4D5E065B.4060305@gmail.com> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E065B.4060305@gmail.com> Message-ID: <20110218055835.23896.qmail@stuge.se> NdK wrote: >>> Just popping in (not subscribed, please CC) to ask if it's planned to >>> add "identity selection" when using a PKCS#11 provider. >> For lack of better alternatives I guess PKCS#11 URI may be the way to go. > What could a pkcs11 URI look like? http://www.opensc-project.org/opensc/attachment/wiki/FOSDEM2011/talk-199.pdf http://video.fosdem.org/2011/devrooms/security/security_1600__pkcs11__mavrogiannopoulos.webm //Peter From ndk.clanbo at gmail.com Fri Feb 18 20:25:09 2011 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 18 Feb 2011 10:25:09 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <20110218055835.23896.qmail@stuge.se> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E065B.4060305@gmail.com> <20110218055835.23896.qmail@stuge.se> Message-ID: <4D5E3AF5.9040103@gmail.com> On 18/02/2011 06:58, Peter Stuge wrote: >>> For lack of better alternatives I guess PKCS#11 URI may be the way to go. >> What could a pkcs11 URI look like? > http://www.opensc-project.org/opensc/attachment/wiki/FOSDEM2011/talk-199.pdf > http://video.fosdem.org/2011/devrooms/security/security_1600__pkcs11__mavrogiannopoulos.webm Didn't know about it. Seems the correct way to follow. And hope that apps start following it, too (expecially mozilla ones). BYtE! From aris at 0xbadc0de.be Fri Feb 18 20:36:29 2011 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Fri, 18 Feb 2011 10:36:29 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <20110218025211.26342.qmail@stuge.se> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> Message-ID: <4D5E3D9D.2000405@0xbadc0de.be> Le 18/02/11 03:52, Peter Stuge a ?crit : > NdK wrote: >> Just popping in (not subscribed, please CC) to ask if it's planned to >> add "identity selection" when using a PKCS#11 provider. > > For lack of better alternatives I guess PKCS#11 URI may be the way to go. Hi Peter, this seems perfect to me, on the condition that PKCS#11 URL are easy to obtain. Being able to set a PKCS#11 URL inside a .ssh/config file seem very important to me. The specifications are to be found in here : http://tools.ietf.org/html/draft-pechanec-pkcs11uri-03 I'm still looking forward a reference implementation, because it doesn't look trivial to implement. Aris From peter at stuge.se Fri Feb 18 23:02:08 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Feb 2011 13:02:08 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <4D5E3D9D.2000405@0xbadc0de.be> <4D5E3AF5.9040103@gmail.com> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E3D9D.2000405@0xbadc0de.be> <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E065B.4060305@gmail.com> <20110218055835.23896.qmail@stuge.se> <4D5E3AF5.9040103@gmail.com> Message-ID: <20110218120208.25628.qmail@stuge.se> Hi, NdK wrote: > >>> For lack of better alternatives I guess PKCS#11 URI may be the > >>> way to go. .. > Didn't know about it. Seems the correct way to follow. > And hope that apps start following it, too (expecially mozilla ones). Aris Adamantiadis wrote: > this seems perfect to me, on the condition that PKCS#11 URL are easy > to obtain. Well, personally I hope we can do better, using the config and refcounting layer that Stef introduced also in the FOSDEM devroom. More about that in a little bit. :) > Being able to set a PKCS#11 URL inside a .ssh/config file seem very > important to me. At least to specify a cert+key id, yes. > The specifications are to be found in here : > http://tools.ietf.org/html/draft-pechanec-pkcs11uri-03 Thanks! //Peter From ndk.clanbo at gmail.com Fri Feb 18 23:38:38 2011 From: ndk.clanbo at gmail.com (NdK) Date: Fri, 18 Feb 2011 13:38:38 +0100 Subject: PKCS11: selecting which key to use In-Reply-To: <20110218120208.25628.qmail@stuge.se> References: <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E3D9D.2000405@0xbadc0de.be> <4D5D0B5E.3020208@gmail.com> <20110218025211.26342.qmail@stuge.se> <4D5E065B.4060305@gmail.com> <20110218055835.23896.qmail@stuge.se> <4D5E3AF5.9040103@gmail.com> <20110218120208.25628.qmail@stuge.se> Message-ID: <4D5E684E.7090500@gmail.com> Il 18/02/2011 13:02, Peter Stuge ha scritto: >> Being able to set a PKCS#11 URL inside a .ssh/config file seem very >> important to me. > > At least to specify a cert+key id, yes. Or to specify a simple key (w/o a cert). Just like id_rsa file. So in many cases there won't be need for a full PKI. BYtE! From philipp_subx at redfish-solutions.com Sat Feb 19 09:03:44 2011 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 18 Feb 2011 14:03:44 -0800 Subject: Code review request: Drop obsolete RFC-791 markings for QoS markings Message-ID: <4D5EECC0.3060401@redfish-solutions.com> Here's the bug and proposed patch. It's pretty trivial. https://bugzilla.mindrot.org/show_bug.cgi?id=1856 Quoting RFC-2474: A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. [...] The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. and: No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791]. Also note that the patch that was originally proposed (but not accepted as-is) for bug 1733 attempted to disallow user setting of the QoS bits, also in accordance with RFC-2474: Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." From imorgan at nas.nasa.gov Sat Feb 19 10:04:51 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 18 Feb 2011 15:04:51 -0800 Subject: Code review request: Drop obsolete RFC-791 markings for QoS markings In-Reply-To: <4D5EECC0.3060401@redfish-solutions.com> References: <4D5EECC0.3060401@redfish-solutions.com> Message-ID: <20110218230451.GE4614@linux124.nas.nasa.gov> According to www.rfc-editor.org, RFC 791 is not obsolete and is still a standard, although it is updated by RFC 1349. Whereas RFC 2474 is only a proposed standard. Is that correct? On Fri, Feb 18, 2011 at 16:03:44 -0600, Philip Prindeville wrote: > Here's the bug and proposed patch. It's pretty trivial. > > https://bugzilla.mindrot.org/show_bug.cgi?id=1856 > > > Quoting RFC-2474: > > A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. [...] The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. > > and: > > No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791]. > > Also note that the patch that was originally proposed (but not accepted as-is) for bug 1733 attempted to disallow user setting of the QoS bits, also in accordance with RFC-2474: > > Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From philipp_subx at redfish-solutions.com Sat Feb 19 10:16:50 2011 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 18 Feb 2011 15:16:50 -0800 Subject: Code review request: Drop obsolete RFC-791 markings for QoS markings In-Reply-To: <20110218230451.GE4614@linux124.nas.nasa.gov> References: <4D5EECC0.3060401@redfish-solutions.com> <20110218230451.GE4614@linux124.nas.nasa.gov> Message-ID: <4D5EFDE2.2020806@redfish-solutions.com> Not sure what your point is: lots of things are marked "proposed standard" that are prevalent and ubiquitous. PPP-IPCP and Telnet Linemode are "proposed standard" status, but you won't find an implementation of PPP or Telnet that omits either. Of the network operators doing traffic shaping, more do QoS (DSCP) than do ToS. On 2/18/11 3:04 PM, Iain Morgan wrote: > According to www.rfc-editor.org, RFC 791 is not obsolete and is still a > standard, although it is updated by RFC 1349. Whereas RFC 2474 is only a > proposed standard. > > Is that correct? > > On Fri, Feb 18, 2011 at 16:03:44 -0600, Philip Prindeville wrote: >> Here's the bug and proposed patch. It's pretty trivial. >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=1856 >> >> >> Quoting RFC-2474: >> >> A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. [...] The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. >> >> and: >> >> No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791]. >> >> Also note that the patch that was originally proposed (but not accepted as-is) for bug 1733 attempted to disallow user setting of the QoS bits, also in accordance with RFC-2474: >> >> Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." >> >> From oren at held.org.il Sun Feb 20 03:22:58 2011 From: oren at held.org.il (Oren Held) Date: Sat, 19 Feb 2011 18:22:58 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110217151726.896792771D@aether.phys.cwru.edu> References: <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110217142532.GF29762@calimero.vinschen.de> <20110217151726.896792771D@aether.phys.cwru.edu> Message-ID: <20110219162257.GA8908@orenhe-laptop> On Thu, Feb 17, 2011 at 10:17:26AM -0500, Craig J Copi wrote: > In message <20110217142532.GF29762 at calimero.vinschen.de>, Corinna Vinschen writes: > > >What I'm missing in the debug output is a clear statement of the > >side which closes the connection, *why* the connection has been > >closed. In Andrew's debug output The server side just contains: > > I have seen something similar but attributed it to a local error > (undiscovered source). I have 3 OpenBSD machines and 2 Ubuntu > machines all running 5.8. All can ssh to each other EXCEPT to one of > the ubuntu machines. The two ubuntu machines should be identical > (same versions of the distribution, same configuration files, ...). > My "solution" was to put > HostKeyAlgorithms ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss > in my ~/.ssh/config file. In particular I found that removing the keys > ecdsa-sha2-nistp256-cert-v01 at openssh.com, > ecdsa-sha2-nistp384-cert-v01 at openssh.com, > ecdsa-sha2-nistp521-cert-v01 at openssh.com > allows for all machines to interconnect. 1. I confirm that above fix works for me also. Alternatively, as reported in Debian bug #612607, adding '-c aes128-ctr' to the ssh command line does the trick as well. 2. I narrowed it a bit down: it only occurs when *running* ssh v5.[7,8]p1 client on my Debian-sid (unstable) box. It's a run-time, and not a compile-time thing. Copying binaries to and fro my box to Ubuntu 10.10 box proved that it only matter where it's being run, not where it's being compiled. In that case, I guess it's something in my environment and not in openssh - but possibly not openssl, because I tried 0.9.8o on both Ubuntu and Debian, and it fails only in the latter. However, some change in the code of 5.7p1 had triggered this problem. Oren From as.amr.saad at gmail.com Mon Feb 21 05:22:41 2011 From: as.amr.saad at gmail.com (Amr Saad) Date: Sun, 20 Feb 2011 13:22:41 -0500 Subject: openssh as a proxy: ForceCommand limitations & speed penalty Message-ID: I've hit two roadblocks while using openssh -D as a general proxy: - openssh doesn't have an internal-null, so the options are to either give the user account a real shell and ForceCommand, or set the shell to something like /bin/cat and ChrootDirectory. I don't want proxy-only accounts to have a shell at all. - Comparing mini-httpd SSL/aes256 vs mini-httpd (localhost/no SSL) via openssh -D/aes256 shows a c. 20% speed penalty on urandom blocks. Is this expected? From vinschen at redhat.com Mon Feb 21 21:18:49 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 21 Feb 2011 11:18:49 +0100 Subject: [PATCH/cygwin]: Revised sshh-host-config script Message-ID: <20110221101849.GA16140@calimero.vinschen.de> Hi, could somebody with checkin rights please apply the below patch? It would be helpful to have this in 5.9p1. I revamped the Cygwin-specific service installer script ssh-host-config. The actual functionality is the same, the revisited version is just more exact when it comes to check for problems which disallow to run certain aspects of the script. So, part of this script and the also rearranged service helper script library "csih" is to check if all the tools required to run the script are available on the system. The new script also is more thorough to inform the user why the script failed. TIA, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.30 diff -u -p -r1.30 ssh-host-config --- contrib/cygwin/ssh-host-config 6 Feb 2011 02:31:25 -0000 1.30 +++ contrib/cygwin/ssh-host-config 21 Feb 2011 10:16:28 -0000 @@ -1,6 +1,6 @@ #!/bin/bash # -# ssh-host-config, Copyright 2000-2009 Red Hat Inc. +# ssh-host-config, Copyright 2000-2011 Red Hat Inc. # # This file is part of the Cygwin port of OpenSSH. # @@ -19,12 +19,39 @@ # ====================================================================== # Initialization # ====================================================================== -PROGNAME=$(basename $0) -_tdir=$(dirname $0) -PROGDIR=$(cd $_tdir && pwd) CSIH_SCRIPT=/usr/share/csih/cygwin-service-installation-helper.sh +# List of apps used. This is checkad for existance in csih_sanity_check +# Don't use *any* transient commands before sourcing the csih helper script, +# otherwise the sanity checks are short-circuited. +declare -a csih_required_commands=( + /usr/bin/basename coreutils + /usr/bin/cat coreutils + /usr/bin/chmod coreutils + /usr/bin/dirname coreutils + /usr/bin/id coreutils + /usr/bin/mv coreutils + /usr/bin/rm coreutils + /usr/bin/cygpath cygwin + /usr/bin/mount cygwin + /usr/bin/ps cygwin + /usr/bin/setfacl cygwin + /usr/bin/umount cygwin + /usr/bin/cmp diffutils + /usr/bin/grep grep + /usr/bin/awk gawk + /usr/bin/ssh-keygen openssh + /usr/sbin/sshd openssh + /usr/bin/sed sed +) +csih_sanity_check_server=yes +source ${CSIH_SCRIPT} + +PROGNAME=$(/usr/bin/basename $0) +_tdir=$(/usr/bin/dirname $0) +PROGDIR=$(cd $_tdir && pwd) + # Subdirectory where the new package is being installed PREFIX=/usr @@ -32,8 +59,6 @@ PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var -source ${CSIH_SCRIPT} - port_number=22 privsep_configured=no privsep_used=yes @@ -46,29 +71,48 @@ opt_force=no # Routine: create_host_keys # ====================================================================== create_host_keys() { + local ret=0 + if [ ! -f "${SYSCONFDIR}/ssh_host_key" ] then csih_inform "Generating ${SYSCONFDIR}/ssh_host_key" - ssh-keygen -t rsa1 -f ${SYSCONFDIR}/ssh_host_key -N '' > /dev/null + if ! /usr/bin/ssh-keygen -t rsa1 -f ${SYSCONFDIR}/ssh_host_key -N '' > /dev/null + then + csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!" + let ++ret + fi fi if [ ! -f "${SYSCONFDIR}/ssh_host_rsa_key" ] then csih_inform "Generating ${SYSCONFDIR}/ssh_host_rsa_key" - ssh-keygen -t rsa -f ${SYSCONFDIR}/ssh_host_rsa_key -N '' > /dev/null + if ! /usr/bin/ssh-keygen -t rsa -f ${SYSCONFDIR}/ssh_host_rsa_key -N '' > /dev/null + then + csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!" + let ++ret + fi fi if [ ! -f "${SYSCONFDIR}/ssh_host_dsa_key" ] then csih_inform "Generating ${SYSCONFDIR}/ssh_host_dsa_key" - ssh-keygen -t dsa -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null + if ! /usr/bin/ssh-keygen -t dsa -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null + then + csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!" + let ++ret + fi fi if [ ! -f "${SYSCONFDIR}/ssh_host_ecdsa_key" ] then csih_inform "Generating ${SYSCONFDIR}/ssh_host_ecdsa_key" - ssh-keygen -t ecdsa -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null + if ! /usr/bin/ssh-keygen -t ecdsa -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null + then + csih_warning "Generating ${SYSCONFDIR}/ssh_host_key failed!" + let ++ret + fi fi + return $ret } # --- End of create_host_keys --- # # ====================================================================== @@ -81,61 +125,58 @@ update_services_file() { local _spaces local _serv_tmp local _wservices + local ret=0 - if csih_is_nt - then - _win_etcdir="${SYSTEMROOT}\\system32\\drivers\\etc" - _services="${_my_etcdir}/services" - # On NT, 27 spaces, no space after the hash - _spaces=" #" - else - _win_etcdir="${WINDIR}" - _services="${_my_etcdir}/SERVICES" - # On 9x, 18 spaces (95 is very touchy), a space after the hash - _spaces=" # " - fi + _win_etcdir="${SYSTEMROOT}\\system32\\drivers\\etc" + _services="${_my_etcdir}/services" + _spaces=" #" _serv_tmp="${_my_etcdir}/srv.out.$$" - mount -o text,posix=0,noacl -f "${_win_etcdir}" "${_my_etcdir}" + /usr/bin/mount -o text,posix=0,noacl -f "${_win_etcdir}" "${_my_etcdir}" # Depends on the above mount _wservices=`cygpath -w "${_services}"` # Remove sshd 22/port from services - if [ `grep -q 'sshd[ \t][ \t]*22' "${_services}"; echo $?` -eq 0 ] + if [ `/usr/bin/grep -q 'sshd[ \t][ \t]*22' "${_services}"; echo $?` -eq 0 ] then - grep -v 'sshd[ \t][ \t]*22' "${_services}" > "${_serv_tmp}" + /usr/bin/grep -v 'sshd[ \t][ \t]*22' "${_services}" > "${_serv_tmp}" if [ -f "${_serv_tmp}" ] then - if mv "${_serv_tmp}" "${_services}" + if /usr/bin/mv "${_serv_tmp}" "${_services}" then csih_inform "Removing sshd from ${_wservices}" else csih_warning "Removing sshd from ${_wservices} failed!" + let ++ret fi - rm -f "${_serv_tmp}" + /usr/bin/rm -f "${_serv_tmp}" else csih_warning "Removing sshd from ${_wservices} failed!" + let ++ret fi fi # Add ssh 22/tcp and ssh 22/udp to services - if [ `grep -q 'ssh[ \t][ \t]*22' "${_services}"; echo $?` -ne 0 ] + if [ `/usr/bin/grep -q 'ssh[ \t][ \t]*22' "${_services}"; echo $?` -ne 0 ] then - if awk '{ if ( $2 ~ /^23\/tcp/ ) print "ssh 22/tcp'"${_spaces}"'SSH Remote Login Protocol\nssh 22/udp'"${_spaces}"'SSH Remote Login Protocol"; print $0; }' < "${_services}" > "${_serv_tmp}" + if /usr/bin/awk '{ if ( $2 ~ /^23\/tcp/ ) print "ssh 22/tcp'"${_spaces}"'SSH Remote Login Protocol\nssh 22/udp'"${_spaces}"'SSH Remote Login Protocol"; print $0; }' < "${_services}" > "${_serv_tmp}" then - if mv "${_serv_tmp}" "${_services}" + if /usr/bin/mv "${_serv_tmp}" "${_services}" then csih_inform "Added ssh to ${_wservices}" else csih_warning "Adding ssh to ${_wservices} failed!" + let ++ret fi - rm -f "${_serv_tmp}" + /usr/bin/rm -f "${_serv_tmp}" else csih_warning "Adding ssh to ${_wservices} failed!" + let ++ret fi fi - umount "${_my_etcdir}" + /usr/bin/umount "${_my_etcdir}" + return $ret } # --- End of update_services_file --- # # ====================================================================== @@ -144,51 +185,57 @@ update_services_file() { # ====================================================================== sshd_privsep() { local sshdconfig_tmp + local ret=0 if [ "${privsep_configured}" != "yes" ] then - if csih_is_nt + csih_inform "Privilege separation is set to yes by default since OpenSSH 3.3." + csih_inform "However, this requires a non-privileged account called 'sshd'." + csih_inform "For more info on privilege separation read /usr/share/doc/openssh/README.privsep." + if csih_request "Should privilege separation be used?" then - csih_inform "Privilege separation is set to yes by default since OpenSSH 3.3." - csih_inform "However, this requires a non-privileged account called 'sshd'." - csih_inform "For more info on privilege separation read /usr/share/doc/openssh/README.privsep." - if csih_request "Should privilege separation be used?" + privsep_used=yes + if ! csih_create_unprivileged_user sshd then - privsep_used=yes - if ! csih_create_unprivileged_user sshd - then - csih_warning "Couldn't create user 'sshd'!" - csih_warning "Privilege separation set to 'no' again!" - csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" - privsep_used=no - fi - else + csih_error_recoverable "Couldn't create user 'sshd'!" + csih_error_recoverable "Privilege separation set to 'no' again!" + csih_error_recoverable "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret privsep_used=no fi else - # On 9x don't use privilege separation. Since security isn't - # available it just adds useless additional processes. privsep_used=no fi fi # Create default sshd_config from skeleton files in /etc/defaults/etc or # modify to add the missing privsep configuration option - if cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 + if /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 then csih_inform "Updating ${SYSCONFDIR}/sshd_config file" sshdconfig_tmp=${SYSCONFDIR}/sshd_config.$$ - sed -e "s/^#UsePrivilegeSeparation yes/UsePrivilegeSeparation ${privsep_used}/ + /usr/bin/sed -e "s/^#UsePrivilegeSeparation yes/UsePrivilegeSeparation ${privsep_used}/ s/^#Port 22/Port ${port_number}/ s/^#StrictModes yes/StrictModes no/" \ < ${SYSCONFDIR}/sshd_config \ > "${sshdconfig_tmp}" - mv "${sshdconfig_tmp}" ${SYSCONFDIR}/sshd_config + if ! /usr/bin/mv "${sshdconfig_tmp}" ${SYSCONFDIR}/sshd_config + then + csih_warning "Setting privilege separation to 'yes' failed!" + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret + fi elif [ "${privsep_configured}" != "yes" ] then echo >> ${SYSCONFDIR}/sshd_config - echo "UsePrivilegeSeparation ${privsep_used}" >> ${SYSCONFDIR}/sshd_config + if ! echo "UsePrivilegeSeparation ${privsep_used}" >> ${SYSCONFDIR}/sshd_config + then + csih_warning "Setting privilege separation to 'yes' failed!" + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret + fi fi + return $ret } # --- End of sshd_privsep --- # # ====================================================================== @@ -201,72 +248,82 @@ update_inetd_conf() { local _sshd_inetd_conf="${_inetcnf_dir}/sshd-inetd" local _sshd_inetd_conf_tmp="${_inetcnf_dir}/sshd-inetd.$$" local _with_comment=1 + local ret=0 if [ -d "${_inetcnf_dir}" ] then # we have inetutils-1.5 inetd.d support if [ -f "${_inetcnf}" ] then - grep -q '^[ \t]*ssh' "${_inetcnf}" && _with_comment=0 + /usr/bin/grep -q '^[ \t]*ssh' "${_inetcnf}" && _with_comment=0 # check for sshd OR ssh in top-level inetd.conf file, and remove # will be replaced by a file in inetd.d/ - if [ `grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -eq 0 ] + if [ `/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -eq 0 ] then - grep -v '^[# \t]*ssh' "${_inetcnf}" >> "${_inetcnf_tmp}" + /usr/bin/grep -v '^[# \t]*ssh' "${_inetcnf}" >> "${_inetcnf_tmp}" if [ -f "${_inetcnf_tmp}" ] then - if mv "${_inetcnf_tmp}" "${_inetcnf}" + if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}" then csih_inform "Removed ssh[d] from ${_inetcnf}" else csih_warning "Removing ssh[d] from ${_inetcnf} failed!" + let ++ret fi - rm -f "${_inetcnf_tmp}" + /usr/bin/rm -f "${_inetcnf_tmp}" else csih_warning "Removing ssh[d] from ${_inetcnf} failed!" + let ++ret fi fi fi csih_install_config "${_sshd_inetd_conf}" "${SYSCONFDIR}/defaults" - if cmp "${SYSCONFDIR}/defaults${_sshd_inetd_conf}" "${_sshd_inetd_conf}" >/dev/null 2>&1 + if /usr/bin/cmp "${SYSCONFDIR}/defaults${_sshd_inetd_conf}" "${_sshd_inetd_conf}" >/dev/null 2>&1 then if [ "${_with_comment}" -eq 0 ] then - sed -e 's/@COMMENT@[ \t]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + /usr/bin/sed -e 's/@COMMENT@[ \t]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + else + /usr/bin/sed -e 's/@COMMENT@[ \t]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + fi + if /usr/bin/mv "${_sshd_inetd_conf_tmp}" "${_sshd_inetd_conf}" + then + csih_inform "Updated ${_sshd_inetd_conf}" else - sed -e 's/@COMMENT@[ \t]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + csih_warning "Updating ${_sshd_inetd_conf} failed!" + let ++ret fi - mv "${_sshd_inetd_conf_tmp}" "${_sshd_inetd_conf}" - csih_inform "Updated ${_sshd_inetd_conf}" fi elif [ -f "${_inetcnf}" ] then - grep -q '^[ \t]*sshd' "${_inetcnf}" && _with_comment=0 + /usr/bin/grep -q '^[ \t]*sshd' "${_inetcnf}" && _with_comment=0 # check for sshd in top-level inetd.conf file, and remove # will be replaced by a file in inetd.d/ - if [ `grep -q '^[# \t]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] + if [ `/usr/bin/grep -q '^[# \t]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] then - grep -v '^[# \t]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" + /usr/bin/grep -v '^[# \t]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" if [ -f "${_inetcnf_tmp}" ] then - if mv "${_inetcnf_tmp}" "${_inetcnf}" + if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}" then csih_inform "Removed sshd from ${_inetcnf}" else csih_warning "Removing sshd from ${_inetcnf} failed!" + let ++ret fi - rm -f "${_inetcnf_tmp}" + /usr/bin/rm -f "${_inetcnf_tmp}" else csih_warning "Removing sshd from ${_inetcnf} failed!" + let ++ret fi fi # Add ssh line to inetd.conf - if [ `grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -ne 0 ] + if [ `/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -ne 0 ] then if [ "${_with_comment}" -eq 0 ] then @@ -274,115 +331,186 @@ update_inetd_conf() { else echo '# ssh stream tcp nowait root /usr/sbin/sshd sshd -i' >> "${_inetcnf}" fi - csih_inform "Added ssh to ${_inetcnf}" + if [ $? -eq 0 ] + then + csih_inform "Added ssh to ${_inetcnf}" + else + csih_warning "Adding ssh to ${_inetcnf} failed!" + let ++ret + fi fi fi + return $ret } # --- End of update_inetd_conf --- # # ====================================================================== +# Routine: check_service_files_ownership +# Checks that the files in /etc and /var belong to the right owner +# ====================================================================== +check_service_files_ownership() { + local run_service_as=$1 + local ret=0 + + if [ -z "${run_service_as}" ] + then + accnt_name=$(/usr/bin/cygrunsrv -VQ sshd | /usr/bin/sed -ne 's/^Account *: *//gp') + if [ "${accnt_name}" = "LocalSystem" ] + then + # Convert "LocalSystem" to "SYSTEM" as is the correct account name + accnt_name="SYSTEM:" + elif [[ "${accnt_name}" =~ ^\.\\ ]] + then + # Convert "." domain to local machine name + accnt_name="U-${COMPUTERNAME}${accnt_name#.}," + fi + run_service_as=$(/usr/bin/grep -Fi "${accnt_name}" /etc/passwd | /usr/bin/awk -F: '{print $1;}') + if [ -z "${run_service_as}" ] + then + csih_warning "Couldn't determine name of user running sshd service from /etc/passwd!" + csih_warning "As a result, this script cannot make sure that the files used" + csih_warning "by the sshd service belong to the user running the service." + csih_warning "Please re-run the mkpasswd tool to make sure the /etc/passwd" + csih_warning "file is in a good shape." + return 1 + fi + fi + for i in "${SYSCONFDIR}"/ssh_config "${SYSCONFDIR}"/sshd_config "${SYSCONFDIR}"/ssh_host_*key "${SYSCONFDIR}"/ssh_host_*key.pub + do + if [ -f "$i" ] + then + if ! chown "${run_service_as}".544 "$i" >/dev/null 2>&1 + then + csih_warning "Couldn't change owner of $i!" + let ++ret + fi + fi + done + if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/empty >/dev/null 2>&1 + then + csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/empty!" + let ++ret + fi + if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/lastlog >/dev/null 2>&1 + then + csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/log/lastlog!" + let ++ret + fi + if [ -f ${LOCALSTATEDIR}/log/sshd.log ] + then + if ! chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/sshd.log >/dev/null 2>&1 + then + csih_warning "Couldn't change owner of ${LOCALSTATEDIR}/log/sshd.log!" + let ++ret + fi + fi + if [ $ret -ne 0 ] + then + csih_warning "Couldn't change owner of important files to ${run_service_as}!" + csih_warning "This may cause the sshd service to fail! Please make sure that" + csih_warning "you have suufficient permissions to change the ownership of files" + csih_warning "and try to run the ssh-host-config script again." + fi + return $ret +} # --- End of check_service_files_ownership --- # + +# ====================================================================== # Routine: install_service # Install sshd as a service # ====================================================================== install_service() { local run_service_as local password + local ret=0 - if csih_is_nt + echo + if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 then - if ! cygrunsrv -Q sshd >/dev/null 2>&1 + csih_inform "Sshd service is already installed." + check_service_files_ownership "" || let ret+=$? + else + echo -e "${_csih_QUERY_STR} Do you want to install sshd as a service?" + if csih_request "(Say \"no\" if it is already installed as a service)" then - echo - echo - csih_warning "The following functions require administrator privileges!" - echo - echo -e "${_csih_QUERY_STR} Do you want to install sshd as a service?" - if csih_request "(Say \"no\" if it is already installed as a service)" + csih_get_cygenv "${cygwin_value}" + + if ( csih_is_nt2003 || [ "$csih_FORCE_PRIVILEGED_USER" = "yes" ] ) then - csih_get_cygenv "${cygwin_value}" + csih_inform "On Windows Server 2003, Windows Vista, and above, the" + csih_inform "SYSTEM account cannot setuid to other users -- a capability" + csih_inform "sshd requires. You need to have or to create a privileged" + csih_inform "account. This script will help you do so." + echo + + [ "${opt_force}" = "yes" ] && opt_f=-f + [ -n "${user_account}" ] && opt_u="-u ""${user_account}""" + csih_select_privileged_username ${opt_f} ${opt_u} sshd - if ( csih_is_nt2003 || [ "$csih_FORCE_PRIVILEGED_USER" = "yes" ] ) + if ! csih_create_privileged_user "${password_value}" then - csih_inform "On Windows Server 2003, Windows Vista, and above, the" - csih_inform "SYSTEM account cannot setuid to other users -- a capability" - csih_inform "sshd requires. You need to have or to create a privileged" - csih_inform "account. This script will help you do so." - echo - - [ "${opt_force}" = "yes" ] && opt_f=-f - [ -n "${user_account}" ] && opt_u="-u ""${user_account}""" - csih_select_privileged_username ${opt_f} ${opt_u} sshd - - if ! csih_create_privileged_user "${password_value}" - then - csih_error_recoverable "There was a serious problem creating a privileged user." - csih_request "Do you want to proceed anyway?" || exit 1 - fi + csih_error_recoverable "There was a serious problem creating a privileged user." + csih_request "Do you want to proceed anyway?" || exit 1 + let ++ret fi + fi - # never returns empty if NT or above - run_service_as=$(csih_service_should_run_as) + # Never returns empty if NT or above + run_service_as=$(csih_service_should_run_as) - if [ "${run_service_as}" = "${csih_PRIVILEGED_USERNAME}" ] + if [ "${run_service_as}" = "${csih_PRIVILEGED_USERNAME}" ] + then + password="${csih_PRIVILEGED_PASSWORD}" + if [ -z "${password}" ] then - password="${csih_PRIVILEGED_PASSWORD}" - if [ -z "${password}" ] - then - csih_get_value "Please enter the password for user '${run_service_as}':" "-s" - password="${csih_value}" - fi + csih_get_value "Please enter the password for user '${run_service_as}':" "-s" + password="${csih_value}" fi + fi - # at this point, we either have $run_service_as = "system" and $password is empty, - # or $run_service_as is some privileged user and (hopefully) $password contains - # the correct password. So, from here out, we use '-z "${password}"' to discriminate - # the two cases. + # At this point, we either have $run_service_as = "system" and + # $password is empty, or $run_service_as is some privileged user and + # (hopefully) $password contains the correct password. So, from here + # out, we use '-z "${password}"' to discriminate the two cases. - csih_check_user "${run_service_as}" + csih_check_user "${run_service_as}" - if [ -n "${csih_cygenv}" ] + if [ -n "${csih_cygenv}" ] + then + cygwin_env=( -e "CYGWIN=${csih_cygenv}" ) + fi + if [ -z "${password}" ] + then + if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + -a "-D" -y tcpip "${cygwin_env[@]}" then - cygwin_env=( -e "CYGWIN=${csih_cygenv}" ) + echo + csih_inform "The sshd service has been installed under the LocalSystem" + csih_inform "account (also known as SYSTEM). To start the service now, call" + csih_inform "\`net start sshd' or \`cygrunsrv -S sshd'. Otherwise, it" + csih_inform "will start automatically after the next reboot." fi - if [ -z "${password}" ] + else + if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + -a "-D" -y tcpip "${cygwin_env[@]}" \ + -u "${run_service_as}" -w "${password}" then - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ - -a "-D" -y tcpip "${cygwin_env[@]}" - then - echo - csih_inform "The sshd service has been installed under the LocalSystem" - csih_inform "account (also known as SYSTEM). To start the service now, call" - csih_inform "\`net start sshd' or \`cygrunsrv -S sshd'. Otherwise, it" - csih_inform "will start automatically after the next reboot." - fi - else - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ - -a "-D" -y tcpip "${cygwin_env[@]}" \ - -u "${run_service_as}" -w "${password}" - then - echo - csih_inform "The sshd service has been installed under the '${run_service_as}'" - csih_inform "account. To start the service now, call \`net start sshd' or" - csih_inform "\`cygrunsrv -S sshd'. Otherwise, it will start automatically" - csih_inform "after the next reboot." - fi + echo + csih_inform "The sshd service has been installed under the '${run_service_as}'" + csih_inform "account. To start the service now, call \`net start sshd' or" + csih_inform "\`cygrunsrv -S sshd'. Otherwise, it will start automatically" + csih_inform "after the next reboot." fi + fi - # now, if successfully installed, set ownership of the affected files - if cygrunsrv -Q sshd >/dev/null 2>&1 - then - chown "${run_service_as}" ${SYSCONFDIR}/ssh* - chown "${run_service_as}".544 ${LOCALSTATEDIR}/empty - chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/lastlog - if [ -f ${LOCALSTATEDIR}/log/sshd.log ] - then - chown "${run_service_as}".544 ${LOCALSTATEDIR}/log/sshd.log - fi - else - csih_warning "Something went wrong installing the sshd service." - fi - fi # user allowed us to install as service - fi # service not yet installed - fi # csih_is_nt + if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 + then + check_service_files_ownership "${run_service_as}" || let ret+=$? + else + csih_error_recoverable "Installing sshd as a service failed!" + let ++ret + fi + fi # user allowed us to install as service + fi # service not yet installed + return $ret } # --- End of install_service --- # # ====================================================================== @@ -494,21 +622,71 @@ done # Check for running ssh/sshd processes first. Refuse to do anything while # some ssh processes are still running -if ps -ef | grep -q '/sshd\?$' +if /usr/bin/ps -ef | /usr/bin/grep -q '/sshd\?$' then echo csih_error "There are still ssh processes running. Please shut them down first." fi +# Make sure the user is running in an administrative context +admin=$(/usr/bin/id -G | /usr/bin/grep -Eq '\<544\>' && echo yes || echo no) +if [ "${admin}" != "yes" ] +then + echo + csih_warning "Running this script typically requires administrator privileges!" + csih_warning "However, it seems your account does not have these privileges." + csih_warning "Here's the list of groups in your user token:" + echo + for i in $(/usr/bin/id -G) + do + /usr/bin/awk -F: "/[^:]*:[^:]*:$i:/{ print \" \" \$1; }" /etc/group + done + echo + csih_warning "This usually means you're running this script from a non-admin" + csih_warning "desktop session, or in a non-elevated shell under UAC control." + echo + csih_warning "Make sure you have the appropriate privileges right now," + csih_warning "otherwise parts of this script will probably fail!" + echo + echo -e "${_csih_QUERY_STR} Are you sure you want to continue? (Say \"no\" if you're not sure" + if ! csih_request "you have the required privileges)" + then + echo + csih_inform "Ok. Exiting. Make sure to switch to an administrative account" + csih_inform "or to start this script from an elevated shell." + exit 1 + fi +fi + +echo + +warning_cnt=0 + # Check for ${SYSCONFDIR} directory csih_make_dir "${SYSCONFDIR}" "Cannot create global configuration files." -chmod 775 "${SYSCONFDIR}" -setfacl -m u:system:rwx "${SYSCONFDIR}" +if ! /usr/bin/chmod 775 "${SYSCONFDIR}" >/dev/null 2>&1 +then + csih_warning "Can't set permissions on ${SYSCONFDIR}!" + let ++warning_cnt +fi +if ! /usr/bin/setfacl -m u:system:rwx "${SYSCONFDIR}" >/dev/null 2>&1 +then + csih_warning "Can't set extended permissions on ${SYSCONFDIR}!" + let ++warning_cnt +fi # Check for /var/log directory csih_make_dir "${LOCALSTATEDIR}/log" "Cannot create log directory." -chmod 775 "${LOCALSTATEDIR}/log" -setfacl -m u:system:rwx "${LOCALSTATEDIR}/log" +if ! /usr/bin/chmod 775 "${LOCALSTATEDIR}/log" >/dev/null 2>&1 +then + csih_warning "Can't set permissions on ${LOCALSTATEDIR}/log!" + let ++warning_cnt +fi +if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/log" >/dev/null 2>&1 +then + csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/log!" + let ++warning_cnt +fi # Create /var/log/lastlog if not already exists if [ -e ${LOCALSTATEDIR}/log/lastlog -a ! -f ${LOCALSTATEDIR}/log/lastlog ] @@ -519,26 +697,33 @@ then fi if [ ! -e ${LOCALSTATEDIR}/log/lastlog ] then - cat /dev/null > ${LOCALSTATEDIR}/log/lastlog - chmod 644 ${LOCALSTATEDIR}/log/lastlog + /usr/bin/cat /dev/null > ${LOCALSTATEDIR}/log/lastlog + if ! /usr/bin/chmod 644 ${LOCALSTATEDIR}/log/lastlog >/dev/null 2>&1 + then + csih_warning "Can't set permissions on ${LOCALSTATEDIR}/log/lastlog!" + let ++warning_cnt + fi fi # Create /var/empty file used as chroot jail for privilege separation csih_make_dir "${LOCALSTATEDIR}/empty" "Cannot create ${LOCALSTATEDIR}/empty directory." -chmod 755 "${LOCALSTATEDIR}/empty" -setfacl -m u:system:rwx "${LOCALSTATEDIR}/empty" +if ! /usr/bin/chmod 755 "${LOCALSTATEDIR}/empty" >/dev/null 2>&1 +then + csih_warning "Can't set permissions on ${LOCALSTATEDIR}/empty!" + let ++warning_cnt +fi +if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/empty" >/dev/null 2>&1 +then + csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/empty!" + let ++warning_cnt +fi # host keys -create_host_keys - -# use 'cmp' program to determine if a config file is identical -# to the default version of that config file -csih_check_program_or_error cmp diffutils - +create_host_keys || let warning_cnt+=$? # handle ssh_config -csih_install_config "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults" -if cmp "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/ssh_config" >/dev/null 2>&1 +csih_install_config "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt +if /usr/bin/cmp "${SYSCONFDIR}/ssh_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/ssh_config" >/dev/null 2>&1 then if [ "${port_number}" != "22" ] then @@ -549,19 +734,24 @@ then fi # handle sshd_config (and privsep) -csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" -if ! cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 +csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt +if ! /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 then - grep -q UsePrivilegeSeparation ${SYSCONFDIR}/sshd_config && privsep_configured=yes + /usr/bin/grep -q UsePrivilegeSeparation ${SYSCONFDIR}/sshd_config && privsep_configured=yes fi -sshd_privsep - +sshd_privsep || let warning_cnt+=$? - -update_services_file -update_inetd_conf -install_service +update_services_file || let warning_cnt+=$? +update_inetd_conf || let warning_cnt+=$? +install_service || let warning_cnt+=$? echo -csih_inform "Host configuration finished. Have fun!" - +if [ $warning_cnt -eq 0 ] +then + csih_inform "Host configuration finished. Have fun!" +else + csih_warning "Host configuration exited with ${warning_cnt} errors or warnings!" + csih_warning "Make sure that all problems reported are fixed," + csih_warning "then re-run ssh-host-config." +fi +exit $warning_cnt -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Mon Feb 21 21:43:08 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 21 Feb 2011 21:43:08 +1100 Subject: [PATCH/cygwin]: Revised sshh-host-config script In-Reply-To: <20110221101849.GA16140@calimero.vinschen.de> References: <20110221101849.GA16140@calimero.vinschen.de> Message-ID: <4D6241BC.7010400@zip.com.au> On 21/02/11 9:18 PM, Corinna Vinschen wrote: > could somebody with checkin rights please apply the below patch? > > It would be helpful to have this in 5.9p1. [...] Thanks, applied to both HEAD and the 5.8 branch so it'll be in the next release either way. -- 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 vinschen at redhat.com Mon Feb 21 22:38:34 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 21 Feb 2011 12:38:34 +0100 Subject: [PATCH/cygwin]: Revised sshh-host-config script In-Reply-To: <4D6241BC.7010400@zip.com.au> References: <20110221101849.GA16140@calimero.vinschen.de> <4D6241BC.7010400@zip.com.au> Message-ID: <20110221113834.GC17868@calimero.vinschen.de> On Feb 21 21:43, Darren Tucker wrote: > On 21/02/11 9:18 PM, Corinna Vinschen wrote: > > >could somebody with checkin rights please apply the below patch? > > > >It would be helpful to have this in 5.9p1. > [...] > > Thanks, applied to both HEAD and the 5.8 branch so it'll be in the > next release either way. Thank you! Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tevfik.karagulle at gmail.com Mon Feb 21 23:22:25 2011 From: tevfik.karagulle at gmail.com (Tevfik Karagulle) Date: Mon, 21 Feb 2011 13:22:25 +0100 Subject: A possible typo in sshd(8) ? Message-ID: >>>> AUTHORIZED*_**KEYS FILE* FORMAT *AuthorizedKeysFile* specifies the file containing public keys for public key authentication; if none is specified, the default is *~/.ssh/authorized_keys*. Each line of the file contains one key (empty lines and lines starting with a `#' are ignored as comments). Protocol 1 public keys consist of the following space-separated fields: options, bits, exponent, modulus, comment. Protocol 2 public key consist of: options, keytype, base64-encoded key, comment. The options field is optional; its presence is determined by whether the line starts with a number or not (the options field never starts with a number). The bits, exponent, modulus, and comment fields give the RSA key for protocol version 1; the comment field is not used for anything (but may be convenient for the user to identify the key). For protocol version 2 the keytype is ``ecdsa-sha2-nistp256'', ``ecdsa-sha2-nistp384'', ``ecdsa-sha2-nistp521'', ``ssh-dss'' or ``ssh-rsa''. >>>> last line: ecdsa-sha2-nistp521 -???-> ecdsa-sha2-nistp512 Tev From araghuraman1 at gmail.com Tue Feb 22 18:54:47 2011 From: araghuraman1 at gmail.com (Ananth Raghuraman) Date: Tue, 22 Feb 2011 02:54:47 -0500 Subject: receiving empty prompt from openssh server Message-ID: Hi all, I am using the Ganymed-SSH2 Java library to access openssh. I have enabled Keyboard Interactive authentication. After successfully returning the correct answer for the first challenge ( "[Password:]" ) the openssh server issues another challenge. The second time, the prompt is empty! The name, instruction are also empty. In addition the number of prompts variable is 0. I am not sure whats going on here. Any insights would be well appreciated! Thanks! From aris at 0xbadc0de.be Wed Feb 23 01:47:28 2011 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 22 Feb 2011 15:47:28 +0100 Subject: receiving empty prompt from openssh server In-Reply-To: References: Message-ID: <4D63CC80.3030308@0xbadc0de.be> Hello, We got this too when implementing keyboard-interactive within libssh. Just send an empty response and you will be given a SSH_SMSG_AUTHENTICATION_SUCCESS packet. Aris Le 22/02/11 08:54, Ananth Raghuraman a ?crit : > Hi all, > > I am using the Ganymed-SSH2 Java library to access openssh. > I have enabled Keyboard Interactive authentication. > After successfully returning the correct answer for > the first challenge ( "[Password:]" ) the openssh server > issues another challenge. The second time, the > prompt is empty! The name, instruction are also empty. > In addition the number of prompts variable is 0. I am not sure > whats going on here. Any insights would be well appreciated! > > Thanks! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Wed Feb 23 07:01:04 2011 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Feb 2011 07:01:04 +1100 (EST) Subject: openssh as a proxy: ForceCommand limitations & speed penalty In-Reply-To: References: Message-ID: On Sun, 20 Feb 2011, Amr Saad wrote: > I've hit two roadblocks while using openssh -D as a general proxy: > > - openssh doesn't have an internal-null, so the options are to either > give the user account a real shell and ForceCommand, or set the shell > to something like /bin/cat and ChrootDirectory. I don't want > proxy-only accounts to have a shell at all. You shouldn't have to give proxy-only accounts a shell. Additionally you can ForceCommand /dev/null in case they request one. Normally a proxy user should be using "ssh -nN" anyway. > - Comparing mini-httpd SSL/aes256 vs mini-httpd (localhost/no SSL) via > openssh -D/aes256 shows a c. 20% speed penalty on urandom blocks. Is > this expected? I haven't looked, but I wouldn't be surprised. Have you tried a faster MAC, such as umac-64 at openssh.com? -d From djm at mindrot.org Wed Feb 23 07:02:18 2011 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Feb 2011 07:02:18 +1100 (EST) Subject: A possible typo in sshd(8) ? In-Reply-To: References: Message-ID: On Mon, 21 Feb 2011, Tevfik Karagulle wrote: > last line: ecdsa-sha2-nistp521 -???-> ecdsa-sha2-nistp512 No, that is correct. Our "large" curve field is 521 bits, not 512. -d From as.amr.saad at gmail.com Wed Feb 23 09:56:10 2011 From: as.amr.saad at gmail.com (Amr Saad) Date: Tue, 22 Feb 2011 17:56:10 -0500 Subject: openssh as a proxy: ForceCommand limitations & speed penalty In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 3:01 PM, Damien Miller wrote: > You shouldn't have to give proxy-only accounts a shell. Additionally you can > ForceCommand /dev/null in case they request one. Normally a proxy user > should be using "ssh -nN" anyway. ssh -nN is the best option, but ups the support burden if its absence breaks users. I ended up with: $ echo 'main() {for(;;) sleep();}'|cc -xc -static -onoshell - to combine ForceCommand & ChrootDirectory. >> - Comparing mini-httpd SSL/aes256 vs mini-httpd (localhost/no SSL) via >> openssh -D/aes256 shows a c. 20% speed penalty on urandom blocks. Is >> this expected? > > I haven't looked, but I wouldn't be surprised. Have you tried a faster MAC, > such as umac-64 at openssh.com? Will try it, but neither host was cpu-bound. From andrew at nglee.co.uk Wed Feb 23 22:18:31 2011 From: andrew at nglee.co.uk (Andrew Ng) Date: Wed, 23 Feb 2011 11:18:31 +0000 (UTC) Subject: ssh 'connection reset by peer' problem since 5.8p1 References: <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110217142532.GF29762@calimero.vinschen.de> <20110217151726.896792771D@aether.phys.cwru.edu> <20110219162257.GA8908@orenhe-laptop> Message-ID: Oren Held held.org.il> writes: > 1. I confirm that above fix works for me also. Alternatively, as reported in > Debian bug #612607, adding '-c aes128-ctr' to the ssh command line does the > trick as well. The '-c aes128-ctr' workaround also works for Cygwin OpenSSH 5.8p1 connection issues. I tried using the '-c' option with the default list of ciphers from the SSH man page and this once again caused the connection issue. I then tried trimming down the list and this appeared to also fix the connection issue. So could it be somehow related to this list of ciphers? Regards, Andrew From oren at held.org.il Thu Feb 24 03:38:22 2011 From: oren at held.org.il (Oren Held) Date: Wed, 23 Feb 2011 18:38:22 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: References: <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110217142532.GF29762@calimero.vinschen.de> <20110217151726.896792771D@aether.phys.cwru.edu> <20110219162257.GA8908@orenhe-laptop> Message-ID: <20110223163821.GA11143@orenhe-laptop> On Wed, Feb 23, 2011 at 11:18:31AM +0000, Andrew Ng wrote: > Oren Held held.org.il> writes: > > > 1. I confirm that above fix works for me also. Alternatively, as reported in > > Debian bug #612607, adding '-c aes128-ctr' to the ssh command line does the > > trick as well. > > The '-c aes128-ctr' workaround also works for Cygwin OpenSSH 5.8p1 connection > issues. I tried using the '-c' option with the default list of ciphers from the > SSH man page and this once again caused the connection issue. I then tried > trimming down the list and this appeared to also fix the connection issue. > > So could it be somehow related to this list of ciphers? I've researched it a bit deeper. Surprisingly it's not a matter of which cipher to choose, but of *how long the list of ciphers is*. I'll explain: Doesn't work: -c 'aes128-ctr' and 94 commas (i.e. -c 'aes128-ctr,,,,,,,,,,,,,,,,,,' etc), Does work: -c 'aes128-ctr' and 95 commas Now the number above varies. On my home computer it was 105 commas vs. 104 commas. So eventually I bet it has to do with SSH packet size. For instance in my place, according to Wireshark, SSH "Client: Key Exchange Init" packet length is 1044+10(padding) in the bad case, 1036+4 in the good case. So to sum it all up: 1. Problem started with 5.7p1 2. Occurs on specific, bleeding edge Linux clients (probably some lib involved) 3. Occurs when connecting to specific old Linux ssh servers. 4. Long cipher list triggers the problem, shortening cipher list works around it. Length of doom is relative to the client or its network configuration. #2 + #3 are still not clear to me - what environment is needed for reproduction. Oren From oren at held.org.il Thu Feb 24 07:24:04 2011 From: oren at held.org.il (Oren Held) Date: Wed, 23 Feb 2011 22:24:04 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110223163821.GA11143@orenhe-laptop> References: <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110217142532.GF29762@calimero.vinschen.de> <20110217151726.896792771D@aether.phys.cwru.edu> <20110219162257.GA8908@orenhe-laptop> <20110223163821.GA11143@orenhe-laptop> Message-ID: <20110223202403.GB18984@orenhe-laptop> > > > 1. I confirm that above fix works for me also. Alternatively, as reported in > > > Debian bug #612607, adding '-c aes128-ctr' to the ssh command line does the > > > trick as well. > > > > The '-c aes128-ctr' workaround also works for Cygwin OpenSSH 5.8p1 connection > > issues. I tried using the '-c' option with the default list of ciphers from the > > SSH man page and this once again caused the connection issue. I then tried > > trimming down the list and this appeared to also fix the connection issue. > > > > So could it be somehow related to this list of ciphers? > > I've researched it a bit deeper. Surprisingly it's not a matter of which cipher to > choose, but of *how long the list of ciphers is*. I'll explain: > Doesn't work: > -c 'aes128-ctr' and 94 commas (i.e. -c 'aes128-ctr,,,,,,,,,,,,,,,,,,' etc), > Does work: > -c 'aes128-ctr' and 95 commas Just a correction, I meant the opposite: the shorter string (94 in this case) DOES work, longer string DOESN'T. From dkg at fifthhorseman.net Fri Feb 25 08:45:20 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Feb 2011 16:45:20 -0500 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase Message-ID: <4D66D170.2080707@fifthhorseman.net> I just opened a bug report about this, but i thought i'd bring it to the group if anyone has any concerns about the idea: https://bugzilla.mindrot.org/show_bug.cgi?id=1871 currently, ssh-askpass is used in some situations to actually ask the user for a passphrase. in other situations, it is used to prompt for simple confirmation (e.g. ControlMaster=ask, ssh-add -c). Providing the exact same UI for both scenarios is not only surprising for new users; it is also potentially problematic. For example, grabbing the X11 keyboard is a pretty invasive operation (and it is warranted, to avoid other X processes snooping on the passphrase). A prompt for confirmation doesn't need to grab the keyboard, though. I'm proposing to extend the ssh-askpass interface with an environment variable SSH_ASKPASS_CONFIRMATION_ONLY. If this environment variable is set, the ssh-askpass can choose to display a simpler/non-kbd-grabbing UI. ssh, ssh-add, and ssh-agent would need to know to set or clear that environment variable depending on the type of prompt. Another approach would be to define a command line argument, but existing ssh-agent implementations appear to treat multiple arguments differently (e.g. gnome-ssh-askpass concatenates them all into the string prompt; jim knoble's x11-ssh-askpass accepts old-school X11-style arguments). So an environment variable seems cleaner. This would be an optional UI enhancement -- ssh-askpass implementations that don't know about it or don't care would't need to make any changes. Any thoughts? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From jrollins at finestructure.net Fri Feb 25 09:04:36 2011 From: jrollins at finestructure.net (Jameson Rollins) Date: Thu, 24 Feb 2011 14:04:36 -0800 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <4D66D170.2080707@fifthhorseman.net> References: <4D66D170.2080707@fifthhorseman.net> Message-ID: <87ipw9ytqj.fsf@servo.finestructure.net> On Thu, 24 Feb 2011 16:45:20 -0500, Daniel Kahn Gillmor wrote: > I just opened a bug report about this, but i thought i'd bring it to the > group if anyone has any concerns about the idea: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1871 > > currently, ssh-askpass is used in some situations to actually ask the > user for a passphrase. > > in other situations, it is used to prompt for simple confirmation (e.g. > ControlMaster=ask, ssh-add -c). > > Providing the exact same UI for both scenarios is not only surprising > for new users; it is also potentially problematic. One of the particularly problematic aspects of using the same UI for confirmation is that askpass prompts for password when simply asking for confirmation. Furthermore, it seems to be sensitive to what is actually typed in to that prompt. Obviously this doesn't make any sense when it's actually just asking for a yes/no response. I think Daniel's suggestion of using an environment variable to change to UI to one that just asks for a yes/no response (and doesn't grab the keyboard) is definitely the way to go. Thanks for the suggestion, Daniel. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From peter at stuge.se Fri Feb 25 14:28:16 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 25 Feb 2011 04:28:16 +0100 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <87ipw9ytqj.fsf@servo.finestructure.net> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> Message-ID: <20110225032816.1564.qmail@stuge.se> Jameson Rollins wrote: > I think Daniel's suggestion of using an environment variable to change > to UI to one that just asks for a yes/no response (and doesn't grab the > keyboard) is definitely the way to go. Absolute no go for me. Would be unacceptable for me to not be able to hit enter without first focusing on the prompt to agree. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 25 14:46:41 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Feb 2011 22:46:41 -0500 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <20110225032816.1564.qmail@stuge.se> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> Message-ID: <4D672621.6080005@fifthhorseman.net> On 02/24/2011 10:28 PM, Peter Stuge wrote: > Jameson Rollins wrote: >> I think Daniel's suggestion of using an environment variable to change >> to UI to one that just asks for a yes/no response (and doesn't grab the >> keyboard) is definitely the way to go. > > Absolute no go for me. Would be unacceptable for me to not be able to > hit enter without first focusing on the prompt to agree. there are a lot of negatives here, Peter, so i'm having a hard time parsing what you mean. I think you're saying "I want to be able to just hit enter without having to focus on the prompt." Is that right? I think jamie's proposal is that it would take focus (like most new windows do) but that it wouldn't "grab the keyboard" in the old X11 sense of a modal/global keyboard lock. This kind of keyboard grab is critical for actual passphrase entry (so that other clients sharing your X11 session can't snoop on the keystrokes), but not for confirmation prompts. The problem with "grabbing the keyboard" for confirmation prompts is that only one application in the entire session can do it at once. So, for example, if you are using confirmation prompting (ControlMaster=ask) for already-established connections to hosts a and b, and you do: scp -3 a:foo b:bar Then two prompts come up concurrently. If they're both trying to grab the keyboard, one of them (at least) must lose, which is considered a "cancel" by every ssh-askpass implementation i've seen. This causes the scp connection to fail, even though there was no need for keyboard grab in the first place. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Fri Feb 25 15:11:40 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 25 Feb 2011 05:11:40 +0100 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <4D672621.6080005@fifthhorseman.net> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> Message-ID: <20110225041140.11392.qmail@stuge.se> Daniel Kahn Gillmor wrote: > there are a lot of negatives here, Peter, so i'm having a hard time > parsing what you mean. :) > I think you're saying "I want to be able to just hit enter without > having to focus on the prompt." Is that right? Right. > I think jamie's proposal is that it would take focus (like most new > windows do) Strictly focus follows mouse here on my desktop, with the exception of x11-ssh-askpass. > but that it wouldn't "grab the keyboard" I'm not sure that this works the way I would like. (For me.) > So, for example, if you are using confirmation prompting > (ControlMaster=ask) for already-established connections to hosts a > and b, and you do: > > scp -3 a:foo b:bar Understand the problem. I don't use this, but I see what you mean. > Then two prompts come up concurrently. If they're both trying to grab > the keyboard, one of them (at least) must lose, which is considered a > "cancel" by every ssh-askpass implementation i've seen. Is the solution to proxy askpass invocations through a serializer? //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 25 15:41:00 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 24 Feb 2011 23:41:00 -0500 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <20110225041140.11392.qmail@stuge.se> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> <20110225041140.11392.qmail@stuge.se> Message-ID: <4D6732DC.5000101@fifthhorseman.net> On 02/24/2011 11:11 PM, Peter Stuge wrote: > Strictly focus follows mouse here on my desktop, with the exception > of x11-ssh-askpass. I use focus-follows-mouse as well (or, technically "sloppy focus" if the wikipedia article [0] vocab is correct). but when new windows open (e.g. if i type "xterm" from a running xterm), the new window gets focus, even though the pointer hasn't moved. Is this not the case for you? if so, what window manager/desktop environment do you use? I'm using openbox, fwiw. >> but that it wouldn't "grab the keyboard" > > I'm not sure that this works the way I would like. (For me.) could you try applying the patch here for gnome-ssh-askpass2.c: https://bugzilla.mindrot.org/attachment.cgi?id=2003 and then launch it from a terminal emulator with: env SSH_ASKPASS_CONFIRMATION_ONLY=true gnome-ssh-askpass2 'test test' does that cause the problem you're expecting to see? >> Then two prompts come up concurrently. If they're both trying to grab >> the keyboard, one of them (at least) must lose, which is considered a >> "cancel" by every ssh-askpass implementation i've seen. > > Is the solution to proxy askpass invocations through a serializer? hm, that might be one approach. Another approach could be to change ssh-askpass behavior to wait patiently for its turn to grab the X keyboard, instead of failing after four seconds of trying to grab. Neither of these seem ideal to me, though, and neither of them addresses the confusion that arises from prompting for a password when all that is really needed is a yes/no confirmation. Do you agree at least that it would be good for ssh-askpass to know that a given prompt is a confirmation prompt instead of an actual password prompt? does the SSH_ASKPASS_CONFIRMATION_ONLY environment variable seem reasonable as a mechanism to signal that? We can decouple decisions about specific ssh-askpass behavior from the question of the signalling approach. --dkg [0] https://secure.wikimedia.org/wikipedia/en/wiki/Focus_(computing) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Fri Feb 25 15:55:01 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 25 Feb 2011 05:55:01 +0100 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <4D6732DC.5000101@fifthhorseman.net> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> <20110225041140.11392.qmail@stuge.se> <4D6732DC.5000101@fifthhorseman.net> Message-ID: <20110225045501.22404.qmail@stuge.se> Daniel Kahn Gillmor wrote: > > Strictly focus follows mouse here on my desktop, with the exception > > of x11-ssh-askpass. > > I use focus-follows-mouse as well (or, technically "sloppy focus" if the > wikipedia article [0] vocab is correct). but when new windows open > (e.g. if i type "xterm" from a running xterm), the new window gets > focus, even though the pointer hasn't moved. > > Is this not the case for you? No. The new window will only get focus if it opened under the pointer. > if so, what window manager/desktop environment do you use? fvwm2 > >> but that it wouldn't "grab the keyboard" > > > > I'm not sure that this works the way I would like. (For me.) > > could you try applying the patch here for gnome-ssh-askpass2.c: > > https://bugzilla.mindrot.org/attachment.cgi?id=2003 > > and then launch it from a terminal emulator with: > > env SSH_ASKPASS_CONFIRMATION_ONLY=true gnome-ssh-askpass2 'test test' > > does that cause the problem you're expecting to see? Afraid I don't have/use gnome-ssh-askpass2 (any more) because x11-ssh-askpass is significantly simpler prettier and last but not least snappier. > > Is the solution to proxy askpass invocations through a serializer? > > hm, that might be one approach. Another approach could be to change > ssh-askpass behavior to wait patiently for its turn to grab the X > keyboard, instead of failing after four seconds of trying to grab. Nod. > Neither of these seem ideal to me, though, I think they're both very reasonable solutions to the scp -3 problem. > and neither of them addresses the confusion that arises from > prompting for a password when all that is really needed is a yes/no > confirmation. > > Do you agree at least that it would be good for ssh-askpass to know > that a given prompt is a confirmation prompt instead of an actual > password prompt? Sure, although I don't care about it for myself I agree it's stupid to ask for a password when that is not what is needed. However on my system with x11-ssh-askpass, that's not what happens. I've added a private key using ssh-add -c. When ssh wants to use that key, x11-ssh-askpass prompts me with: Allow use of key .../id_rsa? Key fingerprint 11:22:33:44.. [OK] [Cancel] I can click OK, hit enter, or type yes and hit enter, to allow. Anything else Cancels. This looks good to me, although I know it's not the case you had problems with. > does the SSH_ASKPASS_CONFIRMATION_ONLY environment variable > seem reasonable as a mechanism to signal that? I think so, if it is really needed. I'm actually happy with the prompt I get, but I think I haven't tried your use case. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 25 16:54:19 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Feb 2011 00:54:19 -0500 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <20110225045501.22404.qmail@stuge.se> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> <20110225041140.11392.qmail@stuge.se> <4D6732DC.5000101@fifthhorseman.net> <20110225045501.22404.qmail@stuge.se> Message-ID: <4D67440B.6060308@fifthhorseman.net> On 02/24/2011 11:55 PM, Peter Stuge wrote: > No. The new window will only get focus if it opened under the > pointer. [...] > fvwm2 ok, thanks, that's good to know. Do you know if there's a way to get X11 focus without doing a full keyboard grab? > Afraid I don't have/use gnome-ssh-askpass2 (any more) because > x11-ssh-askpass is significantly simpler prettier and last but not > least snappier. heh. i use x11-ssh-askpass myself. Attached is a patch to modify the behavior of x11-ssh-askpass to do the same thing i'm describing here. Would you mind trying that out (same approach as before) and seeing if it lets you accept directly by hitting enter? If that doesn't work for you, perhaps all that's needed is an XSetInputFocus instead of an XGrabKeyboard for the confirmation_prompt case? I'd be happy to try that if you tell me this version doesn't work for you. > Sure, although I don't care about it for myself I agree it's stupid > to ask for a password when that is not what is needed. > > However on my system with x11-ssh-askpass, that's not what happens. > I've added a private key using ssh-add -c. When ssh wants to use that > key, x11-ssh-askpass prompts me with: > > Allow use of key .../id_rsa? > Key fingerprint 11:22:33:44.. > > [OK] [Cancel] it still shows you the "indicator" boxes, though, right? and when you type, they light up, in the same way that they light up when you're entering a passphrase? that's the equivalent of the "stars in a text box" for this askpass implementation, aiui. ...thinking and reading a bit more... it seems that "XGrabKeyboard is not a security interface" (at least not against X11 trusted clients which can XQueryKeymap): http://archive.cert.uni-stuttgart.de/bugtraq/2005/06/msg00002.html So it's probably worth re-phrasing the keyboard grab as a protection against inadvertent mistakes like accidentally typing your passphrase into a backgrounded-but-focused web form when you thought you were typing in the askpass box. This is still more of an argument against needing to grab the keyboard in these situations, though. I'm curious what ideas you'd have for actually implementing askpass serialization -- would it be something in the filesystem? a per-X11-session serializing daemon? Something else? These all seem likely to introduce opportunities for other kinds of subtle failure. as for the wait-longer-to-grab approach, i think there are some timing conflicts between needing to make a window visible to even try to grab the keyboard and how long you wait/try again. Is there a way to cleanly/simply wait for an XUngrabKeyboard() event? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: support-SSH_ASKPASS_CONFIRMATION_ONLY.diff Type: text/x-diff Size: 5253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From keisial at gmail.com Sat Feb 26 04:56:45 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 25 Feb 2011 18:56:45 +0100 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <4D67440B.6060308@fifthhorseman.net> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> <20110225041140.11392.qmail@stuge.se> <4D6732DC.5000101@fifthhorseman.net> <20110225045501.22404.qmail@stuge.se> <4D67440B.6060308@fifthhorseman.net> Message-ID: <4D67ED5D.8010401@gmail.com> Daniel Kahn Gillmor wrote: > On 02/24/2011 11:55 PM, Peter Stuge wrote: >> No. The new window will only get focus if it opened under the >> pointer. > [...] >> fvwm2 > ok, thanks, that's good to know. Do you know if there's a way to get > X11 focus without doing a full keyboard grab? If a XGrabKeyboard is really needed, what about grabbing it and immediatly releasing it? > I'm curious what ideas you'd have for actually implementing askpass > serialization -- would it be something in the filesystem? a > per-X11-session serializing daemon? Something else? These all seem > likely to introduce opportunities for other kinds of subtle failure. Aren't both instances spawned by ssh-agent? It seems the agent task to ensure they will not conflict (or maybe respawn the failed one when there's no more pending dialogs). From dkg at fifthhorseman.net Sat Feb 26 05:06:38 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Feb 2011 13:06:38 -0500 Subject: ssh-askpass should be able to distinguish between a prompt for confirmation and a prompt for an actual passphrase In-Reply-To: <4D67ED5D.8010401@gmail.com> References: <4D66D170.2080707@fifthhorseman.net> <87ipw9ytqj.fsf@servo.finestructure.net> <20110225032816.1564.qmail@stuge.se> <4D672621.6080005@fifthhorseman.net> <20110225041140.11392.qmail@stuge.se> <4D6732DC.5000101@fifthhorseman.net> <20110225045501.22404.qmail@stuge.se> <4D67440B.6060308@fifthhorseman.net> <4D67ED5D.8010401@gmail.com> Message-ID: <4D67EFAE.8010007@fifthhorseman.net> On 02/25/2011 12:56 PM, ?ngel Gonz?lez wrote: > If a XGrabKeyboard is really needed, what about grabbing it and > immediatly releasing it? hm, that's an idea, though if XSetInputFocus() is sufficient, i'd rather not play games with anything that does global locks. > Aren't both instances spawned by ssh-agent? It seems the agent task to > ensure they will > not conflict (or maybe respawn the failed one when there's no more > pending dialogs). The ControlMaster=ask situations are invoking ssh-askpass from the socket-multiplexing ssh connections themselves, not from ssh-agent. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From obb33 at verizon.net Sat Feb 26 01:44:14 2011 From: obb33 at verizon.net (obb33 at verizon.net) Date: Fri, 25 Feb 2011 09:44:14 -0500 Subject: problem with tunnels Message-ID: <20110225144414.GC20288@verizon.net> I use ssh tunnels extensively. recently I upgraded my linux kernel from 2.6.18 to 2.6.37 and a problem with tunnels has resulted. prior to the upgrade use of ssh tunN devices was rock solid. the problem manifests as the tunnel from the initiator end ceasing to transfer data to the remote after a quantity of data is sent. it is necessary to create a new tunnel after destroying the old to get data to flow again, which after time jams also. i tested this with linux kernels back to 2.6.31 and they all have the problem.however, tunnels opened TO systems using these kernels work fine from the 2.6.18 kernel system, but if the initiator side is any of the above kernels the data flow jam occurs. what's weird about this is that the remote end can still send data that is received on the initiator side after the jam occurs on the initiator side. i have tested this on different hardware and the results are the same, only the kernel version on the initiator end is relevant. it's not clear that this is an openssh problem as opposed to a kernel problem. please tell me what additional information you need to resolve this and i will send it. TIA B Stone From openssh-dev at kutek.info Sat Feb 26 09:13:40 2011 From: openssh-dev at kutek.info (openssh-dev at kutek.info) Date: Fri, 25 Feb 2011 17:13:40 -0500 Subject: problem with tunnels Message-ID: <20110225221340.GC21047@verizon.net> I use ssh tunnels extensively. recently I upgraded my linux kernel from 2.6.18 to 2.6.37 and a problem with tunnels has resulted. prior to the upgrade use of ssh tunN devices was rock solid. the problem manifests as the tunnel, from the initiator end, ceasing to transfer data to the remote after a quantity of data is sent. it is necessary to create a new tunnel after destroying the old to get data to flow again, which after time jams also. i tested this with linux kernels back to 2.6.31 and they all have the problem.however, tunnels opened TO systems using these kernels work fine from the 2.6.18 kernel system, but if the initiator side is any of the above kernels the data flow jam occurs. what's weird about this is that the remote end can still send data to the initiator side, after the jam occurs on the initiator side. i have tested this on different hardware and the results are the same, only the kernel version on the initiator end is relevant. it's not clear that this is an openssh problem as opposed to a kernel problem. looking at the datastream on the network with tcpdump there are no packet frag issues, and the tests were done with all firewalls turned off. please tell me what additional information you need to help resolve this and i will send it.i need to get this working again, fast B Stone From gert at greenie.muc.de Sat Feb 26 21:47:32 2011 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 26 Feb 2011 11:47:32 +0100 Subject: problem with tunnels In-Reply-To: <20110225221340.GC21047@verizon.net> References: <20110225221340.GC21047@verizon.net> Message-ID: <20110226104732.GU9835@greenie.muc.de> Hi, On Fri, Feb 25, 2011 at 05:13:40PM -0500, openssh-dev at kutek.info wrote: > it's not clear that this is an openssh problem as opposed to a kernel > problem. > > looking at the datastream on the network with tcpdump there are no packet frag > issues, and the tests were done with all firewalls turned off. Have you tried tcpdumping on the tun0 interface? Any difference between "working" and "non-working" systems? 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 openssh-dev at kutek.info Sun Feb 27 00:13:52 2011 From: openssh-dev at kutek.info (openssh-dev at kutek.info) Date: Sat, 26 Feb 2011 08:13:52 -0500 Subject: problem with tunnels Message-ID: <20110226131352.GE21047@verizon.net> ok. i have reconfigured my setup on the 2.6.37.2 kernel to use ethernet tunnels instead of point-to-point and everything is working beautifully, i may have been mistaken in my statement last message about tap on the 2.6.37.1 kernel. this solves my immediate practical problem but not the p2p issue. i will assist in resolving that, if in fact it is an issue with openssh or the kernel. From openssh-dev at kutek.info Sat Feb 26 23:17:53 2011 From: openssh-dev at kutek.info (openssh-dev at kutek.info) Date: Sat, 26 Feb 2011 07:17:53 -0500 Subject: problem with tunnels In-Reply-To: <20110226104732.GU9835@greenie.muc.de> References: <20110225221340.GC21047@verizon.net> <20110226104732.GU9835@greenie.muc.de> Message-ID: <20110226121753.GD21047@verizon.net> first, my apologies to the list for the dupe message, this list and it's user control moves messages extremely slowly , and before i received confirmation of the address confirmation i had already sent the second message thinking the first was lost. second, I neglected to mention that this problem happens with both 5.6p1 and 5.8p1, both of which otherwise work perfectly on the 2.6.18 kernel. i don't think i have to regress any further. third,a search has not turned up any complaints anywhere else of this problem nor kernel developers addressing the issue except perhaps this: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.34 search at that page on the word "undefinitely" (with that spelling) to see the relevant comment fourth, i compiled up the latest gdb intending to debug openssh at which point i discovered i compiled glibc without the debugging libraries and it's going to be a big production to do that fifth, problem happens whether the tunnel is tun or tap. sixth, i have now installed 2.6.37.2, and the situation is unchanged. Gert, i will generate that data and post, and my intention is to install VTUN also and see what happens, which is going to take a bit of time to learn. by tun0 i am assumimg you mean the tunnel creation side. this is very frustrating because the openssh tunnels worked so well previously and were so easy to set up and use, i would hate to have to move to ipsec. however the linux tun/tap code has changed considerably since 2.6.18 as a diff on tun.c will show. >On Sat, Feb 26, 2011 at 11:47:32AM +0100, Gert Doering wrote: > > Have you tried tcpdumping on the tun0 interface? Any difference between > "working" and "non-working" systems? From djm at mindrot.org Mon Feb 28 12:21:36 2011 From: djm at mindrot.org (Damien Miller) Date: Mon, 28 Feb 2011 12:21:36 +1100 (EST) Subject: problem with tunnels In-Reply-To: <20110226121753.GD21047@verizon.net> References: <20110225221340.GC21047@verizon.net> <20110226104732.GU9835@greenie.muc.de> <20110226121753.GD21047@verizon.net> Message-ID: On Sat, 26 Feb 2011, openssh-dev at kutek.info wrote: > search at that page on the word "undefinitely" (with that spelling) to see > the relevant comment Sounds perfectly cromulent to me From openssh-dev at kutek.info Mon Feb 28 14:41:47 2011 From: openssh-dev at kutek.info (openssh-dev at kutek.info) Date: Sun, 27 Feb 2011 22:41:47 -0500 Subject: problem with tunnels In-Reply-To: References: <20110225221340.GC21047@verizon.net> <20110226104732.GU9835@greenie.muc.de> <20110226121753.GD21047@verizon.net> Message-ID: <20110228034147.GA24668@verizon.net> On Mon, Feb 28, 2011 at 12:21:36PM +1100, Damien Miller wrote: > On Sat, 26 Feb 2011, openssh-dev at kutek.info wrote: > > > search at that page on the word "undefinitely" (with that spelling) to see > > the relevant comment > > Sounds perfectly cromulent to me i never devalue the unique in searching thru or specifying something in the haystack, it actually makes things much much easier. ;-) i have been experimenting further. i have not sent the tcpdump traces because it turns out that no data flow on the tunnel point-to-point interface has to occur at all for the interface to stop functioning. just a variable period of time, about 25 seconds. after that time passes, sending data to the client will not work, but data can still be received from the client. apparently the keep alive messages alone will trigger the interface freeze (i'm using both types). the client does not notice anything and ssh does not die. ssh ethernet tunnels,otoh, work perfectly. there is no other weirdness on the system(s) happening. with either IF type.