From rapier at psc.edu Thu Dec 1 02:36:01 2005 From: rapier at psc.edu (Chris Rapier) Date: Wed, 30 Nov 2005 10:36:01 -0500 Subject: Password Option for Windows OpenSSH In-Reply-To: References: <0B0A39652BB0D411BCCF00508B9512EC1DCEB097@tx14exm05.ftw.mot.com> <438D367C.4030102@psc.edu> Message-ID: <438DC6E1.9080006@psc.edu> Which means that they might as well use the packaged versions because thats exactly what they do. They also put it in a nice installer with a script to set everything up for you. As a user level package its a very good solution and there is the added bonus of not having to reinvent the wheel. Someone who is more technically advanced or more interested in being an admin instead of a user might not agree but not everyone is or wants to be in that category. Damien Miller wrote: > On Wed, 30 Nov 2005, Chris Rapier wrote: > >> He might be thinking of the red hat cygwin product. Still, installing all of >> cygwin just to get ssh is a bit like buying a bakery just to get a loaf of >> bread. > > You can install as much, or as little of Cygwin as you like. If you want, > this can be just OpenSSH + OpenSSL + cygwin.dll + bash (pretty much what > the 3rd party repackagings do). > > -d > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From Matthias.Gerstner at nefkom.net Thu Dec 1 04:54:50 2005 From: Matthias.Gerstner at nefkom.net (Matthias Gerstner) Date: Wed, 30 Nov 2005 18:54:50 +0100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438B8AB6.4090206@anl.gov> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> <438B8AB6.4090206@anl.gov> Message-ID: <438DE76A.4070306@nefkom.net> >>Douglas E. Engert wrote: > During login using a password, Kerberos should get you two tickets, > one it the ticket granting ticket, the other is a service ticket for the local > host. The second ticket is need to avoid an attack where a user replaces > the network, and the KDC with ther own version then use the password > stored in their KDC to login to the host. This attack will not > work if the host tries to get the second ticket, as it holds the > real key for the host in the krb5.keytab, and can detect a bogus > KDC. Ok, this part sounds okay to me. Is OpenSSH automatically trying to receive the service ticket? I wonder that I haven't noticed anything about this topic until now. > I bet that with the pam_krb5 you have not set the validate option > or some thing similiar. This option does the above check. On a peronal > workstaion, you may be willing to live with the above attack. > > OpenSSH gets the service ticket. The man sshd_config states > in the kerberosAuthentication sesion that you must have a servtab. > > Also if you use gssapi for authenticaiton you must have the > krb5.keytab or servtab as well. Thank you for this information. I've read the man pages of course but somehow skipped that important part completely. >>> Does the host have a host/@ principal in the >>> krb5.keytab? Just to get this right: Lets say the OpenSSH server's fqdn is ossh.mydomain.net. Then I have to create principal for host/ossh.mydomain.net at MYDOMAIN.NET on the active directory side and extracting a keytrab entry for this principal for use in the krb5.keytab on ossh. If I got this right now then it shouldn't be too hard to get this working. I'll try it as soon as possible. Best regards, Matthias Gerstner From deengert at anl.gov Thu Dec 1 07:48:43 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 30 Nov 2005 14:48:43 -0600 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438DE76A.4070306@nefkom.net> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> <438B8AB6.4090206@anl.gov> <438DE76A.4070306@nefkom.net> Message-ID: <438E102B.1070701@anl.gov> Matthias Gerstner wrote: >>>Douglas E. Engert wrote: > > >>During login using a password, Kerberos should get you two tickets, >>one it the ticket granting ticket, the other is a service ticket for the local >>host. The second ticket is need to avoid an attack where a user replaces >>the network, and the KDC with ther own version then use the password >>stored in their KDC to login to the host. This attack will not >>work if the host tries to get the second ticket, as it holds the >>real key for the host in the krb5.keytab, and can detect a bogus >>KDC. > > > Ok, this part sounds okay to me. Is OpenSSH automatically trying to > receive the service ticket? Sort of. Either pam_krb5 (if using "ChallangeResponse yes") or sshd directly with "KerberosAuthentication yes" will use the username and password to get a ticket granting ticket (TGT). The TGT is then used to get a service ticket for the host. The host will then verify that it is encrypted in the key of the host. Both these tickets both wind up in the ticket cache of the user on the server side. If you are using Kerberos via gssapi, then things work differently. In this case the user on the ssh client side already has Kerberos tickets. They could have been from kinit or login, or a previous sshd doing the above or below. The ssh client calls gssapi the uses the user's ticket cache on the client to get a service ticket for the host then uses this to authenticate to the host which verifies it against the key of the host. This ticket is cached in the client's ticket cache. If the client has "GSSAPIDelegateCredentials yes", the client will request from the KDC a *new* TGT to be usable at the server, The client will send this to TGT to the sshd server, protected by the session key contained in the server ticket. The server will then save this new TGT in the user's ticket cache. In all these cases the user's ticket cache should be pointed at by the KRB5CCNAME environment variable. The TGT could then be used for example by the AFS aklog to get an AFS token (pam_krb5afs, pam_afs2, pam_afs_session can do this) or the user could start an ssh session with gssapi to some other host later on. > I wonder that I haven't noticed anything about this topic until now. The need to verify a host service ticket is well known in the Kerberos community, and is considered standard practice. The fact that your pam_krb5 makes this an option is a security risk. > > >>I bet that with the pam_krb5 you have not set the validate option >>or some thing similiar. This option does the above check. On a peronal >>workstaion, you may be willing to live with the above attack. >> >>OpenSSH gets the service ticket. The man sshd_config states >>in the kerberosAuthentication sesion that you must have a servtab. >> >>Also if you use gssapi for authenticaiton you must have the >>krb5.keytab or servtab as well. > > > Thank you for this information. I've read the man pages of course but > somehow skipped that important part completely. > > >>>>Does the host have a host/@ principal in the >>>>krb5.keytab? > > > Just to get this right: > > Lets say the OpenSSH server's fqdn is ossh.mydomain.net. > > Then I have to create principal for > > host/ossh.mydomain.net at MYDOMAIN.NET > > on the active directory side and extracting a keytrab entry for this > principal for use in the krb5.keytab on ossh. > Yes assuming the AD domain name is mycomain.net. The realm name is the upper case of the AD domain. > If I got this right now then it shouldn't be too hard to get this working. > With AD, you would use the ktpass command to get the keytab. See http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp Its old, but has all the steps. > I'll try it as soon as possible. > > Best regards, > > Matthias Gerstner > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Thu Dec 1 09:56:38 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 1 Dec 2005 09:56:38 +1100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438E102B.1070701@anl.gov> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> <438B8AB6.4090206@anl.gov> <438DE76A.4070306@nefkom.net> <438E102B.1070701@anl.gov> Message-ID: <20051130225638.GB22318@gate.dodgy.net.au> On Wed, Nov 30, 2005 at 02:48:43PM -0600, Douglas E. Engert wrote: > Sort of. Either pam_krb5 (if using "ChallangeResponse yes") or sshd > directly with "KerberosAuthentication yes" will use the username and password > to get a ticket granting ticket (TGT). Minor nitpick: PasswordAuthentication also uses PAM in 3.9p1 and up (and 3.6.1p2 and below), so for current versions the first part of that would more correctly be "UsePAM yes" and either (or both) of "ChallengeResponseAuthentication yes" and "PasswordAuthentication yes". -- 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 deengert at anl.gov Thu Dec 1 23:50:51 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 01 Dec 2005 06:50:51 -0600 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <20051130225638.GB22318@gate.dodgy.net.au> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> <438B8AB6.4090206@anl.gov> <438DE76A.4070306@nefkom.net> <438E102B.1070701@anl.gov> <20051130225638.GB22318@gate.dodgy.net.au> Message-ID: <438EF1AB.3070705@anl.gov> Darren Tucker wrote: > On Wed, Nov 30, 2005 at 02:48:43PM -0600, Douglas E. Engert wrote: > >>Sort of. Either pam_krb5 (if using "ChallangeResponse yes") or sshd >>directly with "KerberosAuthentication yes" will use the username and password >>to get a ticket granting ticket (TGT). > > > Minor nitpick: PasswordAuthentication also uses PAM in 3.9p1 and up > (and 3.6.1p2 and below), so for current versions the first part of > that would more correctly be "UsePAM yes" and either (or both) of > "ChallengeResponseAuthentication yes" and "PasswordAuthentication yes". > It also looks like it depends on if sshd was compled with --with-kerberos5 It looks like in auth-passwd.c in auth_password() will call auth_krb5_password before the test for use_pam. auth_krb5_password calls Kerberos directly. (I am looking at OpenSSH-4.1p1) So in effect it could try the Kerberos password twice once via auth_krb5_password and once via pam_krb5. I think we have seen this, but never knew why! -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From johane at lysator.liu.se Fri Dec 2 00:19:05 2005 From: johane at lysator.liu.se (Johan Gill) Date: Thu, 01 Dec 2005 14:19:05 +0100 Subject: [PATCH] Janitor duties Message-ID: <438EF849.6080207@lysator.liu.se> This patch removes a lot of #include from files in openbsd-compat/ since "includes.h" is included prior to the others and therefore includes the headers first. Is it OK, or is it a design decision to have the includes specific to the c-files in the c-files as well? There is also the correction of an error. In openbsd-compat/readpassphrase.c there was #ifndef HAVE_READPASSPHRASE #include #include I changed to "readpassphrase.h". Cheers Johan Gill -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openbsd-compat.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051201/ded0a700/attachment.ksh From bpsr77 at hotmail.com Fri Dec 2 04:03:08 2005 From: bpsr77 at hotmail.com (olle ollesson) Date: Thu, 01 Dec 2005 18:03:08 +0100 Subject: Sending SSH_MSG_DISCONNECT before dropping connections Message-ID: Hi. >From my understanding the MaxStartups option can be set to limit the number of concurrent sessions the OpenSSH server opens. My concern is how OpenSSH handles the case where this number is reached. >From the code it looks like it simply closes the socket: sshd.c:1440 if (drop_connection(startups) == 1) { debug("drop connection #%d", startups); close(newsock); continue; } Why is there no disconnect message sent that explains to the client why the socket was closed? >From draft-ietf-secsh-transport-24.txt, chapter 11: ---------------------------------------------------------- 11. Additional Messages Either party may send any of the following messages at any time. 11.1 Disconnection Message byte SSH_MSG_DISCONNECT uint32 reason code string description [RFC3629] string language tag [RFC3066] This message causes immediate termination of the connection. All implementations MUST be able to process this message; they SHOULD be able to send this message. The sender MUST NOT send or receive any data after this message, and the recipient MUST NOT accept any data after receiving this message. The Disconnection Message 'description' string gives a more specific explanation in a human-readable form. The Disconnection Message 'reason code' gives the reason in a more machine-readable format (suitable for localization), and can have the values as displayed in the table below. Note that the decimal representation is displayed in this table for readability but that the values are actually uint32 values. Symbolic name reason code ------------- ----------- SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 SSH_DISCONNECT_PROTOCOL_ERROR 2 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 SSH_DISCONNECT_RESERVED 4 SSH_DISCONNECT_MAC_ERROR 5 SSH_DISCONNECT_COMPRESSION_ERROR 6 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 SSH_DISCONNECT_CONNECTION_LOST 10 SSH_DISCONNECT_BY_APPLICATION 11 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 SSH_DISCONNECT_ILLEGAL_USER_NAME 15 ---------------------------------------------------------- If a SSH_DISCONNECT_TOO_MANY_CONNECTIONS disconnect message was to be sent before the connection is closed how far would the SSH connection setup need to go before this could be done? The draft says it can be sent at any time. Can we send it before the "Protocol Version Exchange"? Probably not. Before the Key Exchange? I'm not sure. Question is, how far would the ssh negotiation/connection setup need to go in order for the ssh server to refuse the connection in a more controlled way, that is sending the SSH_DISCONNECT_TOO_MANY_CONNECTIONS disconnect message, and still be compliant with the draft standard? Best Regards, Olle _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From markus at openbsd.org Fri Dec 2 05:56:43 2005 From: markus at openbsd.org (Markus Friedl) Date: Thu, 1 Dec 2005 19:56:43 +0100 Subject: Sending SSH_MSG_DISCONNECT before dropping connections In-Reply-To: References: Message-ID: <20051201185643.GB18190@folly> On Thu, Dec 01, 2005 at 06:03:08PM +0100, olle ollesson wrote: > The draft says it can be sent at any time. Can we send it before the > "Protocol Version Exchange"? no > Before the Key Exchange? yes From bpsr77 at hotmail.com Fri Dec 2 08:32:37 2005 From: bpsr77 at hotmail.com (olle ollesson) Date: Thu, 01 Dec 2005 22:32:37 +0100 Subject: Sending SSH_MSG_DISCONNECT before dropping connections In-Reply-To: <20051201185643.GB18190@folly> Message-ID: Hi again, Thanks for the clarifcation Markus. Now the natural next question: Is there any reason to why OpenSSH does not do it that way, that is, sens SSH_MSG_DISCONNECT with an SSH_DISCONNECT_TOO_MANY_CONNECTIONS reason code before closing the socket when the max number of allowed sessions has been reached? What are the pros and cons in doing so? Here's my two cents Pros: >From a client perspective it would be really valuable (at least to me) to get an indication to why the connection setup attempt failed. Note, there could be other reasons besides too many connection like for example SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT which could be handled in the same way. Cons: The "Protocol Version Exchange" messages needs to be sent first. Thanks in advance. Best Regards, Olle >From: Markus Friedl >To: olle ollesson >CC: openssh-unix-dev at mindrot.org >Subject: Re: Sending SSH_MSG_DISCONNECT before dropping connections >Date: Thu, 1 Dec 2005 19:56:43 +0100 > >On Thu, Dec 01, 2005 at 06:03:08PM +0100, olle ollesson wrote: > > The draft says it can be sent at any time. Can we send it before the > > "Protocol Version Exchange"? > no > > Before the Key Exchange? > yes > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From djm at mindrot.org Fri Dec 2 09:34:36 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Dec 2005 09:34:36 +1100 (EST) Subject: Sending SSH_MSG_DISCONNECT before dropping connections In-Reply-To: References: Message-ID: On Thu, 1 Dec 2005, olle ollesson wrote: > Hi again, > > Thanks for the clarifcation Markus. Now the natural next question: > > Is there any reason to why OpenSSH does not do it that way, that is, sens > SSH_MSG_DISCONNECT with an SSH_DISCONNECT_TOO_MANY_CONNECTIONS reason code > before closing the socket when the max number of allowed sessions has been > reached? What are the pros and cons in doing so? MaxStartups is a DoS mitigation setting - i.e. it is supposed to limit the effect of someone flooding a server with connections, while still allowing a real admin a chance of logging in. As such, there is no point in being polite to people you are going to drop. -d From apb at cequrux.com Tue Dec 6 00:18:49 2005 From: apb at cequrux.com (Alan Barrett) Date: Mon, 5 Dec 2005 15:18:49 +0200 Subject: Specification of identity for ssh client to use Message-ID: <20051205131848.GC3638@apb-laptoy.apb.alt.za> Is there any way to tell the openssh client exactly which identity to use for an outgoing commection? I know about "-i identityfile", but it doesn't do what I want. I want to precisely specify the identity to use, not just add an identity to a list of things to try. Whatever mechanism is used should work both for local files and for identities managed by ssh-agent. My ssh client has access to multiple identities (some from files, and some from ssh-agent), and more than one of the available identities would allow me to login to a target account, but different identities have different "command=" restrictions in the target account's .ssh/authorized_keys2 file. So I want to specify on the ssh command line exactly which identity to use; I don't want the client to do just keep trying multiple identities until one of them works, because then it may use an identity that has the wrong "command=" restrictions on the server side. --apb (Alan Barrett) From dtucker at zip.com.au Tue Dec 6 00:37:25 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 6 Dec 2005 00:37:25 +1100 Subject: Specification of identity for ssh client to use In-Reply-To: <20051205131848.GC3638@apb-laptoy.apb.alt.za> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> Message-ID: <20051205133725.GA26372@gate.dodgy.net.au> On Mon, Dec 05, 2005 at 03:18:49PM +0200, Alan Barrett wrote: > [...] So I want to specify on the ssh command > line exactly which identity to use; I don't want the client to do just > keep trying multiple identities until one of them works, because then it > may use an identity that has the wrong "command=" restrictions on the > server side. Does adding the "IdentitiesOnly" option do what you want? -- 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 apb at cequrux.com Tue Dec 6 01:44:51 2005 From: apb at cequrux.com (Alan Barrett) Date: Mon, 5 Dec 2005 16:44:51 +0200 Subject: Specification of identity for ssh client to use In-Reply-To: <20051205133725.GA26372@gate.dodgy.net.au> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> Message-ID: <20051205144451.GE3638@apb-laptoy.apb.alt.za> On Tue, 06 Dec 2005, Darren Tucker wrote: > On Mon, Dec 05, 2005 at 03:18:49PM +0200, Alan Barrett wrote: > > [...] So I want to specify on the ssh command > > line exactly which identity to use; I don't want the client to do just > > keep trying multiple identities until one of them works, because then it > > may use an identity that has the wrong "command=" restrictions on the > > server side. > > Does adding the "IdentitiesOnly" option do what you want? No, that just tells it "don't consult ssh-agent". The identity that I want to use will sometimes be available from ssh-agent, and not available in any readable files. --apb (Alan Barrett) From pedrodrimel at uol.com.br Tue Dec 6 04:36:10 2005 From: pedrodrimel at uol.com.br (Pedro Drimel Neto) Date: Mon, 5 Dec 2005 15:36:10 -0200 Subject: Remote command Message-ID: <008f01c5f9c2$63830630$2f00a8c0@TRINTASETE> Hi all, I'm new on this list, I tried to find the solution or ideas about my doubt but I didn't know what look for. I was thinking to develope a system that is a "Basic Administration" of a Linux Server, the "idea" is: an application in Java running on a worksation, to consult how much space has on disk of server, the application send a command to the server using the SSH Server to send the command but the output of the command must be displayed on workstation screen... Do you think this is possible ? Have more details but the basic to start it is this above... Sorry for my bad english. Regards, Pedro Drimel Neto. From djm at mindrot.org Tue Dec 6 09:20:15 2005 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Dec 2005 09:20:15 +1100 (EST) Subject: Specification of identity for ssh client to use In-Reply-To: <20051205144451.GE3638@apb-laptoy.apb.alt.za> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> Message-ID: On Mon, 5 Dec 2005, Alan Barrett wrote: > On Tue, 06 Dec 2005, Darren Tucker wrote: > No, that just tells it "don't consult ssh-agent". The identity that > I want to use will sometimes be available from ssh-agent, and not > available in any readable files. Specify it as an IdentityFile in .ssh/config - ssh should try keys in the order in which they are listed, preferring ones in the agent if they are present. -d From dtucker at zip.com.au Tue Dec 6 10:32:07 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 6 Dec 2005 10:32:07 +1100 Subject: Specification of identity for ssh client to use In-Reply-To: <20051205144451.GE3638@apb-laptoy.apb.alt.za> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> Message-ID: <20051205233207.GA9142@gate.dodgy.net.au> On Mon, Dec 05, 2005 at 04:44:51PM +0200, Alan Barrett wrote: > On Tue, 06 Dec 2005, Darren Tucker wrote: > > On Mon, Dec 05, 2005 at 03:18:49PM +0200, Alan Barrett wrote: > > > [...] So I want to specify on the ssh command > > > line exactly which identity to use; I don't want the client to do just > > > keep trying multiple identities until one of them works, because then it > > > may use an identity that has the wrong "command=" restrictions on the > > > server side. > > > > Does adding the "IdentitiesOnly" option do what you want? > > No, that just tells it "don't consult ssh-agent". IdentitiesOnly will still use keys from ssh-agent if available. > The identity that > I want to use will sometimes be available from ssh-agent, and not > available in any readable files. You still need a readable copy of the *public* key file to authenticate via a private key stored in ssh-agent. -- 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 Matthias.Gerstner at nefkom.net Wed Dec 7 08:18:53 2005 From: Matthias.Gerstner at nefkom.net (Matthias Gerstner) Date: Tue, 06 Dec 2005 22:18:53 +0100 Subject: OpenSSH and Kerberos / Active Directory authentication problems: Credentials cache permission incorrect / No Credentials Cache found In-Reply-To: <438EF1AB.3070705@anl.gov> References: <4389E478.2010009@nefkom.net> <438B20B1.2080905@anl.gov> <438B66A3.2040402@nefkom.net> <438B8AB6.4090206@anl.gov> <438DE76A.4070306@nefkom.net> <438E102B.1070701@anl.gov> <20051130225638.GB22318@gate.dodgy.net.au> <438EF1AB.3070705@anl.gov> Message-ID: <4396003D.3040107@nefkom.net> > It also looks like it depends on if sshd was compled with --with-kerberos5 > It looks like in auth-passwd.c in auth_password() will call > auth_krb5_password before the test for use_pam. auth_krb5_password calls > Kerberos directly. (I am looking at OpenSSH-4.1p1) > > So in effect it could try the Kerberos password twice once via auth_krb5_password > and once via pam_krb5. I think we have seen this, but never knew why! Just to keep the topic up to date: I've solved the issue with "Credentials cache permission incorrect" when using OpenSSH's internal kerberos support. The problem was caused implicitly by the underlying Active-Directory in our system. Because the Active-Directory only allows read access to the user data in LDAP when the user is already authenticated to the AD we have a keberos keytab entry on every machine that allows getting a ticket for a kind of init user. To get access to LDAP data a valid ticket for this init user is needed. This ticket is obtained automatically from system scripts. OpenSSH wants to have read access to that ticket which is found in /tmp/krb5cc_0 Permissions for /tmp/krb5cc_0 are by default 600 and owner:group is root:root. But the ssh process runs as sshd user and has no access to the ticket file. When the ticket is world readable the login works perfectly. I'll test the process of using LDAP and the service principal keytab entry soon as well. Unfortunately I have no access to the Active-Directory and have to wait till I get the keytab from the responsible person. Greetings, Matthias Gerstner From jmknoble at pobox.com Wed Dec 7 08:50:05 2005 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 6 Dec 2005 16:50:05 -0500 Subject: Remote command In-Reply-To: <008f01c5f9c2$63830630$2f00a8c0@TRINTASETE> References: <008f01c5f9c2$63830630$2f00a8c0@TRINTASETE> Message-ID: <20051206215005.GE4638@crawfish.ais.com> Circa 2005-12-05 12:36 dixit Pedro Drimel Neto: : to consult how much space has on disk of server, the application send a : command to the server using the SSH Server to send the command but the : output of the command must be displayed on workstation screen... Do you : think this is possible ? Yes: ssh server-name-or-ip-address 'df -k' The result is displayed on the standard output. Keep in mind that, if you want to automate this without the user being prompted for a password or passphrase every time, you must do this in conjunction with public-key authentication and the ssh-agent. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From apb at cequrux.com Wed Dec 7 19:05:43 2005 From: apb at cequrux.com (Alan Barrett) Date: Wed, 7 Dec 2005 10:05:43 +0200 Subject: Specification of identity for ssh client to use In-Reply-To: References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> Message-ID: <20051207080543.GO3638@apb-laptoy.apb.alt.za> On Tue, 06 Dec 2005, Damien Miller wrote: > > The identity that I want to use will sometimes be available from > > ssh-agent, and not available in any readable files. > > Specify it as an IdentityFile in .ssh/config - ssh should try keys in > the order in which they are listed, preferring ones in the agent if > they are present. How do I specify an "IdentityFile" that is not a file? For example, what would I put in .ssh/config or on the command line to tell ssh to use the key that "ssh-add -l" reports as 1024 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff user at host (RSA1) where there is no file name at all, or the key that "ssh-add -l" reports as 1024 ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 /wherever/id_dsa (DSA) where the thing that looks like a file name, "/wherever/id_dsa", is not a valid file name on the local host (or perhaps it is a valid file name, but is not readable by the current effective user id)? --apb (Alan Barrett) From djm at mindrot.org Thu Dec 8 07:49:53 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Dec 2005 07:49:53 +1100 Subject: Specification of identity for ssh client to use In-Reply-To: <20051207080543.GO3638@apb-laptoy.apb.alt.za> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> <20051207080543.GO3638@apb-laptoy.apb.alt.za> Message-ID: <43974AF1.4050205@mindrot.org> Alan Barrett wrote: > On Tue, 06 Dec 2005, Damien Miller wrote: > >>>The identity that I want to use will sometimes be available from >>>ssh-agent, and not available in any readable files. >> >>Specify it as an IdentityFile in .ssh/config - ssh should try keys in >>the order in which they are listed, preferring ones in the agent if >>they are present. > > > How do I specify an "IdentityFile" that is not a file? Darren answered that: > You still need a readable copy of the *public* key file to authenticate > via a private key stored in ssh-agent. -d From dkg-openssh.com at fifthhorseman.net Thu Dec 8 08:07:10 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 7 Dec 2005 16:07:10 -0500 Subject: Specification of identity for ssh client to use In-Reply-To: <43974AF1.4050205@mindrot.org> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> <20051207080543.GO3638@apb-laptoy.apb.alt.za> <43974AF1.4050205@mindrot.org> Message-ID: <17303.20222.796834.208510@localhost.localdomain> On December 8, djm at mindrot.org said: > Alan Barrett wrote: > > > How do I specify an "IdentityFile" that is not a file? > > Darren answered that: > > > You still need a readable copy of the *public* key file to authenticate > > via a private key stored in ssh-agent. in particular, if you have a single identity stored in your agent, you can extract the public key into a file with ssh-add -L > ~/.ssh/high-priority-key.pub hth, --dkg From apb at cequrux.com Thu Dec 8 22:10:02 2005 From: apb at cequrux.com (Alan Barrett) Date: Thu, 8 Dec 2005 13:10:02 +0200 Subject: Specification of identity for ssh client to use In-Reply-To: <17303.20222.796834.208510@localhost.localdomain> References: <20051205131848.GC3638@apb-laptoy.apb.alt.za> <20051205133725.GA26372@gate.dodgy.net.au> <20051205144451.GE3638@apb-laptoy.apb.alt.za> <20051207080543.GO3638@apb-laptoy.apb.alt.za> <43974AF1.4050205@mindrot.org> <17303.20222.796834.208510@localhost.localdomain> Message-ID: <20051208111002.GS3638@apb-laptoy.apb.alt.za> On Wed, 07 Dec 2005, Daniel Kahn Gillmor wrote: > in particular, if you have a single identity stored in your agent, you can > extract the public key into a file with > > ssh-add -L > ~/.ssh/high-priority-key.pub Ah! I think that solves my problem. This does what I want (which is to choose exactly one of the keys available from ssh-agent, use that key, and disallow fallback to other keys or other authentication methods): ssh-add -L | grep "uniquestring" >desired-key.pub chmod 400 desired-key.pub ssh -o "PreferredAuthentications publickey" -o "IdentitiesOnly yes" \ -i desired-key.pub user at host See attached ssh-key-selection-demo.sh, which is intended to be run under ssh-agent. Also see the attached patch to the documentation, which previously failed to explain that the file used with "-i" or "IdentityFile" could contain a public key, and failed to explain that "IdentitiesOnly yes" could still use keys available from the agent. --apb (Alan Barrett) -------------- next part -------------- #!/bin/sh # # ssh-key-selection-demo.sh # # Create an empty directory, put this script in the directory, # cd to the directory, and run # ssh-agent sh -x ./ssh-key-selection-demo.sh # # AUTHORIZED_KEYS="${HOME}/.ssh/authorized_keys" DESIREDKEY="key2" for n in 1 2 3 ; do # generate a key (unless it's already there from a previous run) test -f ./key${n} \ || ssh-keygen -t rsa -b 2048 -N "" -C "This is key${n}" -f ./key${n} # ensure the files are readable chmod 400 ./key${n} ./key${n}.pub # add key to authorized_keys (unless it's already there) grep "key${n}" "${AUTHORIZED_KEYS}" >/dev/null \ || printf 'from="localhost",command="/bin/echo %s" %s\n' \ "You used key${n}" "$(cat ./key${n}.pub)" \ >>"${AUTHORIZED_KEYS}" # add the key to ssh-agent ssh-add ./key${n} # ensure files are unreadable chmod 0 ./key${n} ./key${n}.pub done # check what keys are available ssh-add -l # extract the desired key to a local file rm -f desired-key.pub ssh-add -L | grep "${DESIREDKEY}" >desired-key.pub chmod 400 desired-key.pub # Use the desired key. # # Because of the "PreferredAuthentications publickey" and # "IdentitiesOnly yes", the client will not attempt to fall back to any other # keys or password prompts. # # Because of the "command=" override in the ${AUTHORIZED_KEYS} file on # the server side, it should print "You used ${DESIREDKEY}" instead of # printing "hello". # ssh -o "PreferredAuthentications publickey" -o "IdentitiesOnly yes" \ -i desired-key.pub localhost echo hello -------------- next part -------------- Index: ssh.1 =================================================================== --- ssh.1 18 Sep 2005 18:27:28 -0000 1.33 +++ ssh.1 8 Dec 2005 11:01:15 -0000 @@ -561,8 +561,18 @@ should use to communicate with a smartcard used for storing the user's private RSA key. .It Fl i Ar identity_file -Selects a file from which the identity (private key) for -RSA or DSA authentication is read. +Specifies a file from which the identity (public key or private key) for +RSA or DSA authentication can be read. +If an authentication agent is in use (see +.Xr ssh-agent 1 ) , +the +.Ar identity_file +may contain a private key or a public key, +and the file will be used to influence the order in +which the agent offers the keys under its control. +If an authentication agent is not in use, the +.Ar identity_file +must contain a private key. The default is .Pa $HOME/.ssh/identity for protocol version 1, and Index: ssh_config.5 =================================================================== --- ssh_config.5 23 Apr 2005 16:53:29 -0000 1.10 +++ ssh_config.5 8 Dec 2005 11:01:15 -0000 @@ -455,8 +455,18 @@ .Cm HostName specifications). .It Cm IdentityFile -Specifies a file from which the user's RSA or DSA authentication identity -is read. +Specifies a file from which the identity (public key or private key) for +RSA or DSA authentication can be read. +If an authentication agent is in use (see +.Xr ssh-agent 1 ) , +the +.Ar identity_file +may contain a private key or a public key, +and the file will be used to influence the order in +which the agent offers the keys under its control. +If an authentication agent is not in use, the +.Ar identity_file +must contain a private key. The default is .Pa $HOME/.ssh/identity for protocol version 1, and @@ -476,14 +486,21 @@ .Nm ssh should only use the authentication identity files configured in the .Nm -files, -even if the +files or on the +.Nm ssh +command line, +even if .Nm ssh-agent offers more identities. The argument to this keyword must be .Dq yes or .Dq no . +Setting this option to +.Dq yes +does not disable the use of +.Nm ssh-agent , +it merely restricts the set of keys that will be offered. This option is intented for situations where .Nm ssh-agent offers many different identities. From sbotond at gmail.com Thu Dec 8 23:43:38 2005 From: sbotond at gmail.com (Sipos Botond) Date: Thu, 8 Dec 2005 14:43:38 +0200 Subject: OpenSSH stops at "SSH2_MSG_KEX_DH_GEX_GROUP" Message-ID: <80797a220512080443k15ac6f3fh85149b79f6239213@mail.gmail.com> Hello! I also post here this messages, maybe it's a bug. I have a problem with Cygwin OpenSSH, I hope somebody can help me out. Since we reinstalled our machine we can't connect any external hosts, but we can connect the gateway server. The same box is when booted up with linux (Debian unstable) just works fine. The problem is, that ssh stops at "expecting SSH2_MSG_KEX_DH_GEX_GROUP" and remains here forever! I tried to find some answers at google, but I have found nothing. The strange is that I experience the same problems also with putty. I paste the verbose output of ssh below. Thanks, and please if you reply send me a CC. Regards. Botond Sipos -------------------------------------------------------------- OpenSSH_4.2p1, OpenSSL 0.9.8 05 Jul 2005 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to metawire.org [216.147.196.26] port 22. debug1: Connection established. debug1: identity file /cygdrive/d/Users/sb/.ssh/identity type -1 debug1: identity file /cygdrive/d/Users/sb/.ssh/id_rsa type -1 debug1: identity file /cygdrive/d/Users/sb/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-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_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP (and here remains for ever) ------------------------------------------------------------------------------------ From dtucker at zip.com.au Thu Dec 8 23:58:40 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 8 Dec 2005 23:58:40 +1100 Subject: OpenSSH stops at "SSH2_MSG_KEX_DH_GEX_GROUP" In-Reply-To: <80797a220512080443k15ac6f3fh85149b79f6239213@mail.gmail.com> References: <80797a220512080443k15ac6f3fh85149b79f6239213@mail.gmail.com> Message-ID: <20051208125839.GA7509@gate.dodgy.net.au> On Thu, Dec 08, 2005 at 02:43:38PM +0200, Sipos Botond wrote: > I also post here this messages, maybe it's a bug. > > I have a problem with Cygwin OpenSSH, I hope somebody can help me out. > Since we reinstalled our machine we can't connect any external hosts, > but we can connect the gateway server. > The same box is when booted up with linux (Debian unstable) just works fine. > The problem is, that ssh stops at "expecting > SSH2_MSG_KEX_DH_GEX_GROUP" and remains here forever! That's characteristic of a MTU+firewall problem (the MTU is probably configured differently on each of your OSes). See: http://www.snailbook.com/faq/mtu-mismatch.auto.html -- 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 rinsan at lysator.liu.se Fri Dec 9 00:54:17 2005 From: rinsan at lysator.liu.se (Claes Leufven) Date: Thu, 08 Dec 2005 14:54:17 +0100 Subject: "User child is on pid"-logging Message-ID: <87k6efitiu.fsf@rei.outherlimits.org> Hi! I sent a mail a while ago wondering if it was possible to change the loglevel for the "User child is on pid"-message from debug2 to verbose. It would make it easier to trace a connection in the logs when privilege separation is used and sshd uses the user child pid to report that the connection is closing . Is it possible to change this or would it violate the privacy of the users? Regards Claes Leufv?n Here is a patch for the latest(20051208) snapshot of OpenSSH portable: --- sshd.c-orig 2005-12-08 14:35:03.000000000 +0100 +++ sshd.c 2005-12-08 14:35:11.000000000 +0100 @@ -651,7 +651,7 @@ if (pmonitor->m_pid == -1) fatal("fork of unprivileged child failed"); else if (pmonitor->m_pid != 0) { - debug2("User child is on pid %ld", (long)pmonitor->m_pid); + verbose("User child is on pid %ld", (long)pmonitor->m_pid); close(pmonitor->m_recvfd); buffer_clear(&loginmsg); monitor_child_postauth(pmonitor); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051208/99b601d1/attachment.bin From graeme.tattersall at lumison.net Fri Dec 9 01:33:55 2005 From: graeme.tattersall at lumison.net (Graeme Tattersall) Date: Thu, 08 Dec 2005 14:33:55 +0000 Subject: SSH ok, SFTP ok , SCP broken... custom shell Message-ID: <43984453.7070102@lumison.net> Hi, Can anyone explain why a shell-wrapper script of the following form breaks scp? Can this kind of thing be re-worked to fix the breakage? The wrapper does not produce output, and checks a shell.allow file to see if access to a real shell such as bash should be granted. ------------ eg : #!/bin/sh if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] then exec -a - /bin/bash $* else echo "Access Denied - Please request access" fi ------------ Cheers Graeme -- Graeme Tattersall GPG 0x97620D9F, 0xFBBDAB91 Lumison t: 0845 1199 900 d: 0131 514 4053 From dtucker at zip.com.au Fri Dec 9 10:59:49 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 09 Dec 2005 10:59:49 +1100 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <43984453.7070102@lumison.net> References: <43984453.7070102@lumison.net> Message-ID: <4398C8F5.3060908@zip.com.au> Graeme Tattersall wrote: > Hi, > > Can anyone explain why a shell-wrapper script of the following form breaks scp? > Can this kind of thing be re-worked to fix the breakage? > > The wrapper does not produce output, and checks a shell.allow file to see if > access to a real shell such as bash should be granted. > > > ------------ > eg : > > #!/bin/sh > > if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] You don't need the "[]" brackets, they're the equivalent of the "test" command. Also, you should match against a complete line not a substring. If user "foobar" is in shell.allow, then this will permit users "foo" and "bar" as well. You can do this with egrep and regex anchors, eg if egrep "^$LOGNAME$" /etc/shell.allow > then > exec -a - /bin/bash $* This is your problem: you're not preserving the argument quoting. Try: exec -a - /bin/bash "$@" > else > echo "Access Denied - Please request access" > fi -- 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 fcusack at fcusack.com Fri Dec 9 11:19:07 2005 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 08 Dec 2005 16:19:07 -0800 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <4398C8F5.3060908@zip.com.au> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> Message-ID: <88205E7DC35AEFAE8348F125@maguro.local> On December 9, 2005 10:59:49 AM +1100 Darren Tucker wrote: > Graeme Tattersall wrote: >> if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] > > Also, you should match against a complete line not a substring. If user > "foobar" is in shell.allow, then this will permit users "foo" and "bar" > as well. You can do this with egrep and regex anchors, eg > > if egrep "^$LOGNAME$" /etc/shell.allow 'grep -x' is better. -frank From jmknoble at pobox.com Fri Dec 9 12:32:14 2005 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 8 Dec 2005 20:32:14 -0500 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <88205E7DC35AEFAE8348F125@maguro.local> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> Message-ID: <20051209013214.GL4638@crawfish.ais.com> Circa 2005-12-08 19:19 dixit Frank Cusack: : On December 9, 2005 10:59:49 AM +1100 Darren Tucker wrote: : > Graeme Tattersall wrote: : >> if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] : > : > Also, you should match against a complete line not a substring. If user : > "foobar" is in shell.allow, then this will permit users "foo" and "bar" : > as well. You can do this with egrep and regex anchors, eg : > : > if egrep "^$LOGNAME$" /etc/shell.allow : : 'grep -x' is better. Only for certain values of "better". If Graeme were to extend his /etc/shell.allow file to use multiple fields (e.g., the name of the shell as the second field, with fields separated by ':'), then 'grep -x' would no longer be appropriate. The following will work with both the one-user-per-line and the multi-field /etc/shell.allow: if egrep "^$LOGNAME(:.*)?\$" /etc/shell.allow >/dev/null 2>&1 then ... (Note the use of the backslash to escape the '$' used for the regex inside the shell's double quotes, as well as the correct idiom for redirecting stdout and stderr to /dev/null). -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From fcusack at fcusack.com Fri Dec 9 13:02:59 2005 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 08 Dec 2005 18:02:59 -0800 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <20051209013214.GL4638@crawfish.ais.com> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> <20051209013214.GL4638@crawfish.ais.com> Message-ID: <7D383A27861A156A9AD13CBE@maguro.local> On December 8, 2005 8:32:14 PM -0500 Ji Knoble wrote: > Circa 2005-12-08 19:19 dixit Frank Cusack: > > : On December 9, 2005 10:59:49 AM +1100 Darren Tucker wrote: > : > Graeme Tattersall wrote: > : >> if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] > : > > : > Also, you should match against a complete line not a substring. If user > : > "foobar" is in shell.allow, then this will permit users "foo" and "bar" > : > as well. You can do this with egrep and regex anchors, eg > : > > : > if egrep "^$LOGNAME$" /etc/shell.allow > : > : 'grep -x' is better. > > Only for certain values of "better". If Graeme were to extend his Then we'd be talking about something different. For the example given, 'grep -x' (or probably 'fgrep -x') is better, unqualified. -frank From graeme.tattersall at lumison.net Fri Dec 9 20:26:43 2005 From: graeme.tattersall at lumison.net (Graeme Tattersall) Date: Fri, 09 Dec 2005 09:26:43 +0000 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <88205E7DC35AEFAE8348F125@maguro.local> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> Message-ID: <43994DD3.5080601@lumison.net> Frank Cusack wrote: >>> if [ grep $LOGNAME /etc/shell.allow 2>&1 > /dev/null ] >> if egrep "^$LOGNAME$" /etc/shell.allow Hi, Thanks to everyone who responded. I did cut the shell script in my first message short to avoid posting too much to the list. The user's shell is set to this wrapper script in /etc/passwd. SCP fails with a usage message when running to this shell. interactive login (ssh), and sftp though are okay. The script is type #!/bin/sh, running on RHEL3, which I believe is actually bash running in a compatability mode. the if statement is actually : if /bin/grep -qw ^$LOGNAME $ALLOWFILE >/dev/null 2>/dev/null end the exec line is : exec -a - $REALSHELL $* I'll try changing the exec line to use "$@" instead of $* and report back. Cheers Graeme -- Graeme Tattersall GPG 0x97620D9F, 0xFBBDAB91 Lumison t: 0845 1199 900 d: 0131 514 4053 From graeme.tattersall at lumison.net Fri Dec 9 20:55:34 2005 From: graeme.tattersall at lumison.net (Graeme Tattersall) Date: Fri, 09 Dec 2005 09:55:34 +0000 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <43994DD3.5080601@lumison.net> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> <43994DD3.5080601@lumison.net> Message-ID: <43995496.2040000@lumison.net> Graeme Tattersall wrote: > I'll try changing the exec line ... and report back. > Okay, Thanks everyone. got it working. I changed the exec process as follows : #if ok... SHELL=/bin/bash export SHELL exec -a - ${1+"$@"} #.. else... Cheers Graeme -- Graeme Tattersall GPG 0x97620D9F, 0xFBBDAB91 Lumison t: 0845 1199 900 d: 0131 514 4053 From grundman at mip.ups-tlse.fr Sat Dec 10 06:48:44 2005 From: grundman at mip.ups-tlse.fr (MG) Date: Fri, 09 Dec 2005 20:48:44 +0100 Subject: openssh & kerberos difficulties Message-ID: <4399DF9C.9050908@mip.ups-tlse.fr> 1/ When I access with GSSAPIAuthentication & GSSAPIDelegateCredentials the option KerberosGetAFSToken does not work. The tickets are transfered correctly because the AFS tokens are obtained if the command afslog is inserted in /etc/ssh/sshrc file. 2/ When multiple realms are defined in /etc/krb5.conf sshd uses only the first default realm for kerberos password authentication. However gssapi access works with multiple default realms, at least for HEIMDAL. It should be fine if sshd uses all default realms or all realms defined in /etc/krb5.conf. For HEIMDAL I replaced the line "problem = krb5_verify_user(authctxt->krb5_ctx, authctxt->krb5_user, ccache, password, 1, NULL);" by a line "problem = krb5_verify_user_lrealm(authctxt->krb5_ctx, authctxt->krb5_user, ccache, password, 1, NULL);" in the file auth-krb5.c and the Kerberos password authentication takes into account all locally defined realms in /etc/krb5.conf file. I did not try to modify the file for mit-krb5 kerberos distribution. I use heimdal-0.6.5, openssh-4.2_p1 and openafs-1.2.10-r1 from gentoo. I submitted these bugs as https://bugs.gentoo.org/show_bug.cgi?id=115001 and https://bugs.gentoo.org/show_bug.cgi?id=115003 to gentoo. MG From stuge-openssh-unix-dev at cdy.org Mon Dec 12 09:43:37 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 11 Dec 2005 23:43:37 +0100 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <43994DD3.5080601@lumison.net> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> <43994DD3.5080601@lumison.net> Message-ID: <20051211224337.31040.qmail@cdy.org> On Fri, Dec 09, 2005 at 09:26:43AM +0000, Graeme Tattersall wrote: > the if statement is actually : > > if /bin/grep -qw ^$LOGNAME $ALLOWFILE >/dev/null 2>/dev/null > > end the exec line is : > exec -a - $REALSHELL $* I would suggest making sure that these three environment expand correctly: if /bin/grep -qw "^${LOGNAME}" "${ALLOWFILE}" >/dev/null 2>/dev/null .. exec -a - "${REALSHELL}" .. ..you get the picture. Some other time, maybe one of the variables ends up having a space or other unexpected character in them and that would cause a malfunction of the script, even though the data may be valid. And, even with the above quoted grep regex you will erroneously admit user foo when user foobar is the only one listed. If there's a separator after the username, I'd use bash tricks or /bin/cut in order to check the entire username and nothing but the entire username for a match. //Peter From public at meierchristian.de Sun Dec 11 09:29:43 2005 From: public at meierchristian.de (Christian Meier) Date: Sat, 10 Dec 2005 23:29:43 +0100 Subject: Problems with openssh and pam_abl Message-ID: <439B56D7.4020001@meierchristian.de> I want to use sshd together with pam_abl to reduce that logfile spamming with ssh attacks. So the problem is as follows: Setting maxAuthTries to 0 or any other values smaller than the default of 6 changes the behaviour of pam_abl. First, but this also happens with not using maxAuthTries option, is: if the clientside closes connection after for example one failed authentication try then the pam module is not being notified, so no failed login is recorded in pam_abl database. Second, altough client does not close connection until it gets the error notification "Received disconnect from : 2: Too many authentication failures for ..." the pam_abl module does not get any notification of failed login(s). (This second problem only appears when using parameter maxauthtries option) So I hope anybody knows the answer or can say me what to change in source code. I personally think that somewhere there's missing a final cleanup or finishing of pam conversation when connection is getting closed at client side. From dtucker at zip.com.au Mon Dec 12 14:17:38 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 12 Dec 2005 14:17:38 +1100 Subject: Problems with openssh and pam_abl In-Reply-To: <439B56D7.4020001@meierchristian.de> References: <439B56D7.4020001@meierchristian.de> Message-ID: <20051212031738.GA15199@gate.dodgy.net.au> On Sat, Dec 10, 2005 at 11:29:43PM +0100, Christian Meier wrote: > I want to use sshd together with pam_abl to reduce > that logfile spamming with ssh attacks. > > So the problem is as follows: > > Setting maxAuthTries to 0 or any other values smaller than the default > of 6 changes the behaviour of pam_abl. > > First, but this also happens with not using maxAuthTries option, is: > if the clientside closes connection after for example one failed > authentication try then the pam module is not being notified, so no > failed login is recorded in pam_abl database. > > Second, altough client does not close connection until it gets the error > notification "Received disconnect from : 2: Too many authentication > failures for ..." the pam_abl module does not get any notification of > failed login(s). (This second problem only appears when using parameter > maxauthtries option) > > So I hope anybody knows the answer or can say me what to change in > source code. > > I personally think that somewhere there's missing a final cleanup or > finishing of pam conversation when connection is getting closed at > client side. It's probably simpler than that: I suspect that your client is trying non-interactive authentications (eg multiple pubkeys, hostbased), you are reaching the MaxAuthTries limit before any of the PAM-based authentications (password, keyboard-interactive) are reached. (Assuming pam_abl only registers a failure during pam_authenticate, which I haven't checked but is a reasonable guess.) The other thing to be aware of is that the current crop of worms (at at least, the crop that was current last time I looked) perform only a single password authentication attempt and then disconnect. This means that testing with ssh is not representative of the behaviour you'll see in the wild ("ssh -o PreferredAuthentications=password yourserver" will be closer but still not identical.) -- 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 djk at super.org Sun Dec 11 03:14:04 2005 From: djk at super.org (Daniel Kopetzky) Date: Sat, 10 Dec 2005 11:14:04 -0500 (EST) Subject: known_hosts and multiple hosts through a NAT router Message-ID: <200512101614.jBAGE4P05728@ucs1.super.org> The .ssh/known_hosts table cannot handle reaching different sshd servers behind a NAT router. The machines are selected by having the SSHDs respond to differnt ports. A second request would be to allow known_hosts checking solely on the dns name, wildcarding the IP address. This would be useful to avoid continuously warning the user every time you connect to a machine with a changing IP address (e.g. dynamic-ip DSL home machine). Without that you can fall for DNS typo squatters (e.g my fingers found ****.hoemip.net rather than homeip.net and I didn't even notice because I was used to the noise warning that a laptop's IP address had changed. From dkg-openssh.com at fifthhorseman.net Tue Dec 13 02:52:06 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 12 Dec 2005 10:52:06 -0500 Subject: known_hosts and multiple hosts through a NAT router In-Reply-To: <200512101614.jBAGE4P05728@ucs1.super.org> References: <200512101614.jBAGE4P05728@ucs1.super.org> Message-ID: <17309.40102.264768.503988@localhost.localdomain> On December 10, djk at super.org said: > The .ssh/known_hosts table cannot handle reaching different sshd > servers behind a NAT router. The machines are selected by having > the SSHDs respond to differnt ports. > > A second request would be to allow known_hosts checking solely on > the dns name, wildcarding the IP address. This would be useful > to avoid continuously warning the user every time you connect > to a machine with a changing IP address (e.g. dynamic-ip DSL home machine). > Without that you can fall for DNS typo squatters (e.g my > fingers found ****.hoemip.net rather than homeip.net and > I didn't even notice because I was used to the noise warning > that a laptop's IP address had changed. Both of these problems should go away if you have ~/.ssh/config clauses that use HostKeyAlias. for example: Host foo Hostname xyz.homeip.net HostKeyAlias foo Port 2222 Host bar Hostname xyz.homeip.net HostKeyAlias bar Port 3333 this also makes it easier for you from the command line. you just use: ssh foo or ssh bar to connect. hth, --dkg From martin at oneiros.de Tue Dec 13 10:02:48 2005 From: martin at oneiros.de (Martin =?iso-8859-1?Q?Schr=F6der?=) Date: Tue, 13 Dec 2005 00:02:48 +0100 Subject: sftp/scp hangs at connection, but ssh is OK In-Reply-To: <20051102153828.GD16614@lucien.oneiros.kn-bremen.de> References: <20051030154611.GB17112@lucien.oneiros.kn-bremen.de> <20051102153828.GD16614@lucien.oneiros.kn-bremen.de> Message-ID: <20051212230248.GD8447@lucien.oneiros.kn-bremen.de> On 2005-11-02 16:38:28 +0100, Martin Schr?der wrote: > On 2005-10-30 16:46:11 +0100, Martin Schr?der wrote: > > I've read the FAQ and googled, but I'm still stymied: > > ssh localhost works, but scp and sftp both hang. [...] > > The system is a Suse 8.0 (Linux 2.4.18). > > > > Any idea how to fix this? > > I tried this on secureshell, but got only garbage or pointers to > the FAQ. The FAQ doesn't help: > ------------- > > echo +`ssh localhost /bin/true`+ > ++ > ------------- For the archives: I finally found the culprit. I had this in my .bashrc: --------------- if test -z "$SSH_AUTH_SOCK" ; then ssh-agent $SHELL fi --------------- This causes ssh-agent to be also called in non-interactive sessions, which somehow causes scp/sftp to fail. This works: --------------- if [ -z "$SSH_AUTH_SOCK" ] && [ -x /usr/bin/ssh-agent ] && /usr/bin/tty -s ; then ssh-agent $SHELL fi --------------- Best Martin -- http://www.tm.oneiros.de From dtucker at zip.com.au Tue Dec 13 12:04:44 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 13 Dec 2005 12:04:44 +1100 Subject: known_hosts and multiple hosts through a NAT router In-Reply-To: <200512101614.jBAGE4P05728@ucs1.super.org> References: <200512101614.jBAGE4P05728@ucs1.super.org> Message-ID: <20051213010444.GA5124@gate.dodgy.net.au> On Sat, Dec 10, 2005 at 11:14:04AM -0500, Daniel Kopetzky wrote: > The .ssh/known_hosts table cannot handle reaching different sshd > servers behind a NAT router. The machines are selected by having > the SSHDs respond to differnt ports. Someone else has already pointed out HostKeyAlias. There's also an enhancement request to add port identifiers (bug #910). > A second request would be to allow known_hosts checking solely on > the dns name You mean like "CheckHostIP no"? -- 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 chris at ex-parrot.com Wed Dec 14 05:49:33 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Tue, 13 Dec 2005 18:49:33 +0000 Subject: sshd -p option vs ListenAddress Message-ID: If all ListenAddress lines in the sshd_config file specify a port, then the -p option to sshd is silently ignored: # cat test_sshd_config2 ListenAddress 0.0.0.0:22 ListenAddress 0.0.0.0:2222 # `pwd`/sshd -D -d -p 4411 -f test_sshd_config2 debug1: sshd version OpenSSH_4.2p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/path/to/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='4411' debug1: rexec_argv[5]='-f' debug1: rexec_argv[6]='test_sshd_config2' debug1: Bind to port 2222 on 0.0.0.0. debug1: Bind to port 22 on 0.0.0.0. Bind to port 22 on 0.0.0.0 failed: Address already in use. Cannot bind any address. # ^D This seems... counterintuitive, at least. Is it the intended behaviour? -- ``Around 1,500 spectators turned up,... lured by the novel combination of death, an elephant and electricity. Mercifully, Topsy died extremely quickly, and without a trumpet, which may have had something to do with the carrots laced with cyanide that she had been fed.'' (from The Economist) From stuge-openssh-unix-dev at cdy.org Wed Dec 14 23:36:33 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 14 Dec 2005 13:36:33 +0100 Subject: sshd -p option vs ListenAddress In-Reply-To: References: Message-ID: <20051214123633.20557.qmail@cdy.org> On Tue, Dec 13, 2005 at 06:49:33PM +0000, Chris Lightfoot wrote: > If all ListenAddress lines in the sshd_config file specify > a port, then the -p option to sshd is silently ignored: > > # cat test_sshd_config2 > ListenAddress 0.0.0.0:22 > ListenAddress 0.0.0.0:2222 > # `pwd`/sshd -D -d -p 4411 -f test_sshd_config2 [..] > debug1: Bind to port 2222 on 0.0.0.0. > debug1: Bind to port 22 on 0.0.0.0. > Bind to port 22 on 0.0.0.0 failed: Address already in use. > Cannot bind any address. > # ^D > > This seems... counterintuitive, at least. Is it the > intended behaviour? Two different options (Port and ListenAddress) that control the same thing are bound to be at least a little bit confusing. Although sshd_config(5) is somewhat helpful, it doesn't clearly say that ListenAddress has priority over Port, at least with a ListenAddress on host 0. Should Port (or -p when given) options be appended to the ListenAddress list, with a 0 host? //Peter From chris at ex-parrot.com Wed Dec 14 23:48:49 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Wed, 14 Dec 2005 12:48:49 +0000 Subject: sshd -p option vs ListenAddress In-Reply-To: <20051214123633.20557.qmail@cdy.org> References: <20051214123633.20557.qmail@cdy.org> Message-ID: <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> On Wed, Dec 14, 2005 at 01:36:33PM +0100, Peter Stuge wrote: > On Tue, Dec 13, 2005 at 06:49:33PM +0000, Chris Lightfoot wrote: > > If all ListenAddress lines in the sshd_config file specify > > a port, then the -p option to sshd is silently ignored: > > > > # cat test_sshd_config2 > > ListenAddress 0.0.0.0:22 > > ListenAddress 0.0.0.0:2222 > > # `pwd`/sshd -D -d -p 4411 -f test_sshd_config2 > [..] > > debug1: Bind to port 2222 on 0.0.0.0. > > debug1: Bind to port 22 on 0.0.0.0. > > Bind to port 22 on 0.0.0.0 failed: Address already in use. > > Cannot bind any address. > > # ^D > > > > This seems... counterintuitive, at least. Is it the > > intended behaviour? > > Two different options (Port and ListenAddress) that control the same > thing are bound to be at least a little bit confusing. > > Although sshd_config(5) is somewhat helpful, it doesn't clearly say > that ListenAddress has priority over Port, at least with a > ListenAddress on host 0. No -- it's in the case where all ListenAddress directives specify a port, rather than where all specify host = 0. -- If we couldn't laugh at things that didn't make sense, we couldn't react to a lot of the world around us. (Calvin and Hobbes) From stuge-openssh-unix-dev at cdy.org Thu Dec 15 00:25:15 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 14 Dec 2005 14:25:15 +0100 Subject: sshd -p option vs ListenAddress In-Reply-To: <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> Message-ID: <20051214132515.26629.qmail@cdy.org> On Wed, Dec 14, 2005 at 12:48:49PM +0000, Chris Lightfoot wrote: > > Two different options (Port and ListenAddress) that control the same > > thing are bound to be at least a little bit confusing. > > > > Although sshd_config(5) is somewhat helpful, it doesn't clearly say > > that ListenAddress has priority over Port, at least with a > > ListenAddress on host 0. > > No -- it's in the case where all ListenAddress directives > specify a port, rather than where all specify host = 0. Quite right, of course. Is this a bug in code or documentation? //Peter From chris at ex-parrot.com Thu Dec 15 03:41:48 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Wed, 14 Dec 2005 16:41:48 +0000 Subject: sshd -p option vs ListenAddress In-Reply-To: <20051214132515.26629.qmail@cdy.org> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> <20051214132515.26629.qmail@cdy.org> Message-ID: <7X4viEPSsZfe.VZM7oWr+TthSpi2A3m0RMA@sphinx.mythic-beasts.com> On Wed, Dec 14, 2005 at 02:25:15PM +0100, Peter Stuge wrote: > On Wed, Dec 14, 2005 at 12:48:49PM +0000, Chris Lightfoot wrote: > > > Two different options (Port and ListenAddress) that control the same > > > thing are bound to be at least a little bit confusing. > > > > > > Although sshd_config(5) is somewhat helpful, it doesn't clearly say > > > that ListenAddress has priority over Port, at least with a > > > ListenAddress on host 0. > > > > No -- it's in the case where all ListenAddress directives > > specify a port, rather than where all specify host = 0. > > Quite right, of course. > > Is this a bug in code or documentation? Well, if we treat it as a bug in documentation, it's easier to fix :-) That said, it'd be preferable to fix it in the code, since that'd make the command-line more useful. One option (still a bit confusing, but closer to the internal data model) would be to have an analogous -a option to specify a ListenAddress, replacing any already-defined ListenAddress in the same way that -p replaces any already-defined Port. Thoughts? I can do a patch for this if that'd be useful (though not right now). -- ``I believe I am the only living man to deliberately place his hands in the mouth of an attacking cougar.'' (Clarence Hall) From openssh at roumenpetrov.info Thu Dec 15 09:55:17 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 15 Dec 2005 00:55:17 +0200 Subject: sshd -p option vs ListenAddress In-Reply-To: <7X4viEPSsZfe.VZM7oWr+TthSpi2A3m0RMA@sphinx.mythic-beasts.com> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> <20051214132515.26629.qmail@cdy.org> <7X4viEPSsZfe.VZM7oWr+TthSpi2A3m0RMA@sphinx.mythic-beasts.com> Message-ID: <43A0A2D5.3040106@roumenpetrov.info> Chris Lightfoot wrote: > On Wed, Dec 14, 2005 at 02:25:15PM +0100, Peter Stuge wrote: > >>On Wed, Dec 14, 2005 at 12:48:49PM +0000, Chris Lightfoot wrote: >> >>>>Two different options (Port and ListenAddress) that control the same >>>>thing are bound to be at least a little bit confusing. >>>> >>>>Although sshd_config(5) is somewhat helpful, it doesn't clearly say >>>>that ListenAddress has priority over Port, at least with a >>>>ListenAddress on host 0. quote form sshd_config(5): ================================================= ... ListenAddress Specifies the local addresses sshd should listen on. The follow- ing forms may be used: ListenAddress host|IPv4_addr|IPv6_addr ListenAddress host|IPv4_addr:port ListenAddress [host|IPv6_addr]:port If port is not specified, sshd will listen on the address and all ^^^^ ^^^ ^^^^^^^^^ ^^^ prior Port options specified. The default is to listen on all ^^^^^^^^^^ ^^^^^^^^^ local addresses. Multiple ListenAddress options are permitted. Additionally, any Port options must precede this option for non ^^^^^^^^ ^^^^^^^^^^^^ ^^^ port qualified addresses. ^^^^^^^^^^^^^^ ================================================= Is manual page clear or not ? >>> >>>No -- it's in the case where all ListenAddress directives >>>specify a port, rather than where all specify host = 0. >> >>Quite right, of course. >> >>Is this a bug in code or documentation? > > > Well, if we treat it as a bug in documentation, it's > easier to fix :-) > > That said, it'd be preferable to fix it in the code, since > that'd make the command-line more useful. One option > (still a bit confusing, but closer to the internal data > model) would be to have an analogous -a option to specify > a ListenAddress, replacing any already-defined > ListenAddress in the same way that -p replaces any > already-defined Port. Be carefull. Rule is do not override already specified options. Note that -p don't replace any "already-defined Port" ! Also note that sshd accept multiple Port and ListenAddress. Sample: .../sshd -f /dev/null \ -o Port=1234 -p 2345 -o ListenAddress=127.2.2.2 \ -p 3456 -o ListenAddress=127.3.3.3 \ -o ListenAddress=127.1.1.1:4567 \ -D -e -d Sshd work as is described in manual page. Chris, could you specify a test case that show bug in manuals or daemon ? Regards, Roumen From chris at ex-parrot.com Thu Dec 15 10:04:11 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Wed, 14 Dec 2005 23:04:11 +0000 Subject: sshd -p option vs ListenAddress In-Reply-To: <43A0A2D5.3040106@roumenpetrov.info> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> <20051214132515.26629.qmail@cdy.org> <7X4viEPSsZfe.VZM7oWr+TthSpi2A3m0RMA@sphinx.mythic-beasts.com> <43A0A2D5.3040106@roumenpetrov.info> Message-ID: OK, if you want a quote from the man page (sshd(8)) -p port Specifies the port on which the server listens for connections (default 22). Multiple port options are permitted. Ports speci? fied in the configuration file are ignored when a command-line port is specified. but, as stated, this is not true in the case where every ListenAddress line in the configuration file specifies a port. > Note that -p don't replace any "already-defined Port" ! ? sshd.c:981: case 'p': options.ports_from_cmdline = 1; servconf.c:465: case sPort: /* ignore ports from configfile if cmdline specifies ports */ if (options->ports_from_cmdline) return 0; -- ``The English people are like the English beer-- froth on top, dregs at the bottom; the middle, excellent.'' (Voltaire) From rapier at psc.edu Fri Dec 16 03:12:14 2005 From: rapier at psc.edu (Chris Rapier) Date: Thu, 15 Dec 2005 11:12:14 -0500 Subject: Packets Sizes and Information Leakage Message-ID: <43A195DE.2000900@psc.edu> So one of my coworkers is doing a little research on SSH usage in the wild using netflow data. One of the things he's trying to do is determine a way to differentiate between data transfers and interactive sessions. We thought of a couple of ways but we wanted to float them here and see if there are methods incorporated to defeat thi sort of traffic analysis. The first idea is to look at the average number of packets per second over the length of the flow. The idea is that a data transfer would have a significantly higher number of PPS than an interactive session. If we analyze few thousand ssh flows and build a histogram we expect to see two (or maybe 3 peaks) corresponding to various connection types. I think this probably has the best chance of statistically significant results. The second method would be to look at the packet size. The idea being that interactive packets would end up being significantly smaller than full size data packets. I know that some padding is used to protect against plaintext attacks according to the RFC but I didn't know if there was any additional padding on top of that to protect against traffic analysis. Are interactive packets coalesced or padded to the known MTU? I'm going to run some tcpdumps but I wanted to ask here as well. The other method would be to use packet arrival times but we only have flow data and putting a packet sniffer on 10G link is prohibitively expensive for work like this. Please note: If there aren't any countermeasures for this type of traffic analysis I'm not saying that is a problem at all. Knowing a flow is interactive versus a bulk data transfer really doesn't help out an attacker all that much. I'm just curious at this time and my coworker needs the data for a presentation to a center director here. Thanks for your time! Chris Rapier PSC From bob at proulx.com Fri Dec 16 04:09:02 2005 From: bob at proulx.com (Bob Proulx) Date: Thu, 15 Dec 2005 10:09:02 -0700 Subject: SSH ok, SFTP ok , SCP broken... custom shell In-Reply-To: <7D383A27861A156A9AD13CBE@maguro.local> References: <43984453.7070102@lumison.net> <4398C8F5.3060908@zip.com.au> <88205E7DC35AEFAE8348F125@maguro.local> <20051209013214.GL4638@crawfish.ais.com> <7D383A27861A156A9AD13CBE@maguro.local> Message-ID: <20051215170902.GC9151@dementia.proulx.com> Frank Cusack wrote: > > : 'grep -x' is better. > > > > Only for certain values of "better". If Graeme were to extend his > > Then we'd be talking about something different. For the example given, > 'grep -x' (or probably 'fgrep -x') is better, unqualified. As long as we are talking values of better... Using 'grep -F' is better for the future than using 'fgrep'. But I understand that for some legacy systems 'fgrep' is preferred. Bob From bpsr77 at hotmail.com Sat Dec 17 00:55:52 2005 From: bpsr77 at hotmail.com (olle ollesson) Date: Fri, 16 Dec 2005 14:55:52 +0100 Subject: Force TTY Message-ID: Hi all, I'm having problems with getting a tty against an extreme switch. I've tried with the -t flag that is supposed to force a tty but it's not working. I checked the code in ssh.c where this option is parsed: case 't': if (tty_flag) force_tty_flag = 1; tty_flag = 1; break; The tty_flag is initialized to 0 and what I can see this flag is always 0 at this stage in the code. Thus it is impossible to set the force_tty_flag to 1. Is this done intentionally or is it a bug? Why the if statement? Best Regards, Olle _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From dtucker at zip.com.au Sat Dec 17 01:16:23 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 17 Dec 2005 01:16:23 +1100 Subject: Force TTY In-Reply-To: References: Message-ID: <43A2CC37.6030205@zip.com.au> olle ollesson wrote: > I'm having problems with getting a tty against an extreme switch. I've tried > with the -t flag that is supposed to force a tty but it's not working. > > I checked the code in ssh.c where this option is parsed: > > case 't': > if (tty_flag) > force_tty_flag = 1; > tty_flag = 1; > break; > > The tty_flag is initialized to 0 and what I can see this flag is always 0 at > this stage in the code. Thus it is impossible to set the force_tty_flag to > 1. Hint: the case is inside a loop, so that might run more than once. > Is this done intentionally or is it a bug? Why the if statement? "ssh -t -t" forces pty allocation. -- 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 bpsr77 at hotmail.com Sat Dec 17 01:31:33 2005 From: bpsr77 at hotmail.com (olle ollesson) Date: Fri, 16 Dec 2005 15:31:33 +0100 Subject: Force TTY In-Reply-To: <43A2CC37.6030205@zip.com.au> Message-ID: Hi Darren, Yes, I've already figured that out but that seems rather lika a workaround for a bug than an intentional design. The dokumentation says: -t Forces pseudo-tty allocation. This can be used to exe- cute arbitrary screen-based programs on a remote machine, which can be very useful, for example, when implementing menu services. It doesn't state that you need to give this option twice in order for it to have effect. So the question remains, why the if statement? Best Regards, Brian _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ From openssh at roumenpetrov.info Sat Dec 17 09:12:18 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 17 Dec 2005 00:12:18 +0200 Subject: sshd -p option vs ListenAddress In-Reply-To: References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> <20051214132515.26629.qmail@cdy.org> <7X4viEPSsZfe.VZM7oWr+TthSpi2A3m0RMA@sphinx.mythic-beasts.com> <43A0A2D5.3040106@roumenpetrov.info> Message-ID: <43A33BC2.9050704@roumenpetrov.info> Chris Lightfoot wrote: > OK, if you want a quote from the man page (sshd(8)) > > -p port > Specifies the port on which the server listens for connections > (default 22). Multiple port options are permitted. Ports speci? > fied in the configuration file are ignored when a command-line > port is specified. > > but, as stated, this is not true in the case where every > ListenAddress line in the configuration file specifies a > port. > > >>Note that -p don't replace any "already-defined Port" ! > > > ? > > sshd.c:981: > case 'p': > options.ports_from_cmdline = 1; > > servconf.c:465: > case sPort: > /* ignore ports from configfile if cmdline specifies ports */ > if (options->ports_from_cmdline) > return 0; > > Good catch. - About option "Port": Option -p realy don't replace "already-defined Port". With .../sshd -o port=1111 -p 2222 -p 3333 -o ListenAddress=127.3.3.3 and server listen on three ports (1111, 2222 and 3333) - it's ok. But with ../sshd -o port=1111 -p 2222 -o 'port 3333' -o ListenAddress=127.3.3.3 server will listen only on two ports (1111, 2222), but port 3333 is specified on command line too !? What about proposed patch attached as file "openssh-20051214-cmdline_ports.patch" ? - About option "ListenAddress": As I understand you request is behaviour of ListenAddress to be same as Port option. It seems to me reasonable since both options are related. Next request is a new "short" option "-a" for ListenAddress. I don't know :-\ . But I cannot agree with request Port or ListenAddress to replace already defined options, since they are "multiple options" and rule is to ignore when specified. I cann't agree with request port option to replace specified port in a ListenAddress. They are different options. I guess that is clear deference between a option "to be replaced" and "to be ignored when is already specified". - "to be replaced": X:=a X:=b => value of X is b - "to be ignored when is already specified" X:=a X:=b => value of X is a Regards, Roumen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-20051214-cmdline_ports.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051217/283bc1f5/attachment.ksh From djm at mindrot.org Sat Dec 17 09:23:41 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Dec 2005 09:23:41 +1100 (EST) Subject: Force TTY In-Reply-To: References: Message-ID: On Fri, 16 Dec 2005, olle ollesson wrote: > Hi Darren, > > Yes, I've already figured that out but that seems rather lika a workaround > for a bug than an intentional design. The dokumentation says: > > -t Forces pseudo-tty allocation. This can be used to exe- > cute arbitrary screen-based programs on a remote > machine, which can be very useful, for example, when > implementing menu services. > > It doesn't state that you need to give this option twice in order for it to > have effect. So the question remains, why the if statement? It rarely necessary to use it twice. Once will force a tty allocation from the server (when you are using "ssh server command") and is usually all you need. Twice is necessary to force it on the client, e.g. when you are doing "ssh server command < /dev/null". -d From stevesk at pobox.com Sat Dec 17 09:30:12 2005 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 16 Dec 2005 14:30:12 -0800 Subject: Force TTY In-Reply-To: References: <43A2CC37.6030205@zip.com.au> Message-ID: <20051216223012.GA4648@lava.local> On Fri, Dec 16, 2005 at 03:31:33PM +0100, olle ollesson wrote: : Yes, I've already figured that out but that seems rather lika a workaround : for a bug than an intentional design. The dokumentation says: : : -t Forces pseudo-tty allocation. This can be used to exe- : cute arbitrary screen-based programs on a remote : machine, which can be very useful, for example, when : implementing menu services. : : It doesn't state that you need to give this option twice in order for it to : have effect. So the question remains, why the if statement? ssh.1 has stated the following for close to 5 years: -t Force pseudo-tty allocation. This can be used to execute arbi- trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty. From stevesk at pobox.com Sat Dec 17 10:14:07 2005 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 16 Dec 2005 15:14:07 -0800 Subject: sshd -p option vs ListenAddress In-Reply-To: <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> Message-ID: <20051216231407.GB4648@lava.local> On Wed, Dec 14, 2005 at 12:48:49PM +0000, Chris Lightfoot wrote: : On Wed, Dec 14, 2005 at 01:36:33PM +0100, Peter Stuge wrote: : > > This seems... counterintuitive, at least. Is it the : > > intended behaviour? yes. : > Two different options (Port and ListenAddress) that control the same : > thing are bound to be at least a little bit confusing. true. : > Although sshd_config(5) is somewhat helpful, it doesn't clearly say : > that ListenAddress has priority over Port, at least with a : > ListenAddress on host 0. : : No -- it's in the case where all ListenAddress directives : specify a port, rather than where all specify host = 0. Summary as I recall: -p overrides Port ListenAddress :port overrides -p and Port -p or Port only used when no ListenAddress :port The following seem fairly clear to me but I may have written some of it. sshd.8: -p port Specifies the port on which the server listens for connections (default 22). Multiple port options are permitted. Ports speci- fied in the configuration file are ignored when a command-line port is specified. sshd_config.5: ListenAddress Specifies the local addresses sshd should listen on. The follow- ing forms may be used: ListenAddress host|IPv4_addr|IPv6_addr ListenAddress host|IPv4_addr:port ListenAddress [host|IPv6_addr]:port If port is not specified, sshd will listen on the address and all prior Port options specified. The default is to listen on all local addresses. Multiple ListenAddress options are permitted. Additionally, any Port options must precede this option for non port qualified addresses. Port Specifies the port number that sshd listens on. The default is 22. Multiple options of this type are permitted. See also ListenAddress. From chris at ex-parrot.com Sat Dec 17 23:42:32 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Sat, 17 Dec 2005 12:42:32 +0000 Subject: sshd -p option vs ListenAddress In-Reply-To: <20051216231407.GB4648@lava.local> References: <20051214123633.20557.qmail@cdy.org> <8puZoTtWuXC7.Yk1yo2YkUsKejRuQpD+48g@sphinx.mythic-beasts.com> <20051216231407.GB4648@lava.local> Message-ID: <5G+nI6PFRUr5.k7cg4kJoGe/VqIAcJBSdyg@sphinx.mythic-beasts.com> On Fri, Dec 16, 2005 at 03:14:07PM -0800, Kevin Steves wrote: > On Wed, Dec 14, 2005 at 12:48:49PM +0000, Chris Lightfoot wrote: > : On Wed, Dec 14, 2005 at 01:36:33PM +0100, Peter Stuge wrote: > : > > This seems... counterintuitive, at least. Is it the > : > > intended behaviour? > > yes. > > : > Two different options (Port and ListenAddress) that control the same > : > thing are bound to be at least a little bit confusing. > > true. > > : > Although sshd_config(5) is somewhat helpful, it doesn't clearly say > : > that ListenAddress has priority over Port, at least with a > : > ListenAddress on host 0. > : > : No -- it's in the case where all ListenAddress directives > : specify a port, rather than where all specify host = 0. > > Summary as I recall: > -p overrides Port > ListenAddress :port overrides -p and Port > -p or Port only used when no ListenAddress :port > > The following seem fairly clear to me but I may have written some > of it. [...] Yes, it's fine taken all together, but the description in sshd(8) implies that you can make the server listen on a particular port just by giving a -p option. It'd be useful at least to note that this isn't so, for instance by adding, something like, However, this option does not override any port specified as part of a ListenAddress in the configuration file; see sshd_config(5) for more information. -- ``Dear Mr. Gadaffi, You must be very proud. It's not every day that a duck becomes president.'' (from `I'm Sorry, I Haven't A Clue') From nils.hammar at x3-c.com Sun Dec 18 07:57:17 2005 From: nils.hammar at x3-c.com (Nils Hammar) Date: Sat, 17 Dec 2005 21:57:17 +0100 Subject: Automatic blacklist of IP-addresses. Message-ID: <43A47BAD.7030605@x3-c.com> One feature that I haven't seen in OpenSSH (It may be there) is an automatic blacklisting of IP addresses when a certain number of login attempts are reached from that IP address. It seems like it is popular these days to try brute force access on password cracking and automatic blacklisting may limit these attempts. Best regards/Nils Hammar From stuge-openssh-unix-dev at cdy.org Sun Dec 18 23:35:39 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 18 Dec 2005 13:35:39 +0100 Subject: Automatic blacklist of IP-addresses. In-Reply-To: <43A47BAD.7030605@x3-c.com> References: <43A47BAD.7030605@x3-c.com> Message-ID: <20051218123540.31820.qmail@cdy.org> On Sat, Dec 17, 2005 at 09:57:17PM +0100, Nils Hammar wrote: > One feature that I haven't seen in OpenSSH (It may be there) is an > automatic blacklisting of IP addresses when a certain number of > login attempts are reached from that IP address. It seems like it > is popular these days to try brute force access on password > cracking and automatic blacklisting may limit these attempts. This has been suggested before, but rejected. The recommended way to implement this is to monitor log output from OpenSSH and make appropriate changes to the firewall settings. OpenSSH is not a firewall. //Peter From bpsr77 at hotmail.com Tue Dec 20 01:04:35 2005 From: bpsr77 at hotmail.com (olle ollesson) Date: Mon, 19 Dec 2005 15:04:35 +0100 Subject: Force TTY In-Reply-To: <20051216223012.GA4648@lava.local> Message-ID: Hi, My mistake. I was reading the man pages on solaris 9. Apparently they use the older description still. Thanks everyone and keep up the good work. >From: Kevin Steves >To: olle ollesson >CC: openssh-unix-dev at mindrot.org, dtucker at zip.com.au, stevesk at pobox.com >Subject: Re: Force TTY >Date: Fri, 16 Dec 2005 14:30:12 -0800 > >On Fri, Dec 16, 2005 at 03:31:33PM +0100, olle ollesson wrote: >: Yes, I've already figured that out but that seems rather lika a >workaround >: for a bug than an intentional design. The dokumentation says: >: >: -t Forces pseudo-tty allocation. This can be used to exe- >: cute arbitrary screen-based programs on a remote >: machine, which can be very useful, for example, when >: implementing menu services. >: >: It doesn't state that you need to give this option twice in order for it >to >: have effect. So the question remains, why the if statement? > >ssh.1 has stated the following for close to 5 years: > > -t Force pseudo-tty allocation. This can be used to execute >arbi- > trary screen-based programs on a remote machine, which can be > very useful, e.g., when implementing menu services. Multiple >-t > options force tty allocation, even if ssh has no local tty. > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From bsteensr at csc.com Tue Dec 20 03:10:16 2005 From: bsteensr at csc.com (Bjorn Steensrud) Date: Mon, 19 Dec 2005 17:10:16 +0100 Subject: arcfour test fails on HP-UX 11.23 Itanium Message-ID: Building OpenSSH 4.2p1 with the hpn11-none patch, HP-UX 11.23 64-bits ia64, using openssl-0.9.7g compiled from source. Using gcc 4.0.2 from the HP software depot, compilation is uneventful (but fast!) once configuration is set up, but make tests fail with Disconnected messages: Disconnected: bad packet length ... (varying) Write failed: Broken pipe ssh -2 failed with mac hmac-sja1 cipher arcfour Then cycles through the rest of the macs with the same message, apart from packet length. As far as I can see the other ciphers pass the tests, but testing naturally stops after the try-ciphers test. I will of course dig in and try, but has anyone seen this and have a solution? Bj?rn Steensrud From imorgan at nas.nasa.gov Tue Dec 20 03:42:39 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 19 Dec 2005 08:42:39 -0800 (PST) Subject: arcfour test fails on HP-UX 11.23 Itanium In-Reply-To: from "Bjorn Steensrud" at Dec 19, 2005 05:10:16 PM Message-ID: <200512191642.jBJGgdXB024360@sun601.nas.nasa.gov> See bz #1055. Try a more recent version of OpenSSL. On Mon Dec 19 08:10:16 2005, Bjorn Steensrud wrote: > > Building OpenSSH 4.2p1 with the hpn11-none patch, HP-UX 11.23 64-bits > ia64, using openssl-0.9.7g compiled from source. > Using gcc 4.0.2 from the HP software depot, compilation is uneventful > (but fast!) once configuration is set up, but > make tests fail with Disconnected messages: > > Disconnected: bad packet length ... (varying) > Write failed: Broken pipe > ssh -2 failed with mac hmac-sja1 cipher arcfour > > Then cycles through the rest of the macs with the same message, apart from > packet length. > As far as I can see the other ciphers pass the tests, but testing > naturally stops after the try-ciphers test. > > I will of course dig in and try, but has anyone seen this and have a > solution? > > Bj?rn Steensrud > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Iain Morgan From rick.jones2 at hp.com Tue Dec 20 05:52:10 2005 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 19 Dec 2005 10:52:10 -0800 Subject: arcfour test fails on HP-UX 11.23 Itanium In-Reply-To: <200512191642.jBJGgdXB024360@sun601.nas.nasa.gov> References: <200512191642.jBJGgdXB024360@sun601.nas.nasa.gov> Message-ID: <43A7015A.1080109@hp.com> Iain Morgan wrote: > See bz #1055. Try a more recent version of OpenSSL. In particular, try 0.9.8a or even TOT. they contain perf enhancements - although perhaps not for arcfor. 0.9.8a may not have all of them, hence the suggestion to try-out the TOT if you can. rick jones From info at md-systems.ch Tue Dec 20 01:34:05 2005 From: info at md-systems.ch (Miro Dietiker, MD Systems) Date: Mon, 19 Dec 2005 15:34:05 +0100 Subject: OpenSSH traffic accounting ... Message-ID: <025501c604a9$43d478e0$4001a8c0@MDSYSPORT> Since i/we didn't receive any answer on secureshell at securityfocus.com I like to ask this question to you. What's your opinion on this topic? Thanks! Miro +-------------------------------+ +-------------------------------+ | Miro Dietiker | | MD Systems Miro Dietiker | +-------------------------------+ +-------------------------------+ -----Urspr?ngliche Nachricht----- Von: user [mailto:user at dhp.com] Gesendet: Sonntag, 11. Dezember 2005 22:31 An: secureshell at securityfocus.com Betreff: OpenSSH traffic accounting ... There exist patches for OpenSSH that allow it to perform per user traffic accounting. Further, new releases increasingly are being met with the "it still doesn't do per user traffic accounting ?" comment. ( http://it.slashdot.org/comments.pl?sid=161168&cid=13488466 ) Can someone tell me why this is not implemented ? Is it a philosophical question, or is it just low priority ? Perhaps the patches just weren't good ones and nobody wants to redo them ? All comments appreciated. -----Urspr?ngliche Nachricht----- Von: Miro Dietiker, MD Systems [mailto:info at md-systems.ch] Gesendet: Dienstag, 13. Dezember 2005 10:55 An: 'user'; secureshell at securityfocus.com Betreff: AW: OpenSSH traffic accounting ... This topic is also very important to me and I wanted to ask for it... For commercial usage/applications this would be a prerequisite. Would be great to have this feature :-) From chris at ex-parrot.com Wed Dec 21 06:40:04 2005 From: chris at ex-parrot.com (Chris Lightfoot) Date: Tue, 20 Dec 2005 19:40:04 +0000 Subject: OpenSSH traffic accounting ... In-Reply-To: <025501c604a9$43d478e0$4001a8c0@MDSYSPORT> References: <025501c604a9$43d478e0$4001a8c0@MDSYSPORT> Message-ID: On Mon, Dec 19, 2005 at 03:34:05PM +0100, Miro Dietiker, MD Systems wrote: > There exist patches for OpenSSH that allow it to perform per user > traffic > accounting. > > Further, new releases increasingly are being met with the "it still > doesn't do per user traffic accounting ?" comment. > > ( http://it.slashdot.org/comments.pl?sid=161168&cid=13488466 ) > > Can someone tell me why this is not implemented ? Is it a philosophical > question, or is it just low priority ? Perhaps the patches just weren't > good ones and nobody wants to redo them ? > > All comments appreciated. On this topic, I recently updated my accounting patches to apply to 4.2p1: http://caesious.beasts.org/~chris/tmp/20051220/openssh-4.2p1-server-accounting.patch Many thanks to John Kozubik, who paid for this work. I don't know if there's any chance of that making it into the distribution; the patch is a little ugly, but I couldn't see a more attractive way to write the thing. Any comments? -- ``I can't find the [Latin] translation for `responsibility', which might explain a lot of Roman history....'' (Gareth Wilson) From loic-dev at gmx.net Fri Dec 23 21:07:47 2005 From: loic-dev at gmx.net (Loic Domaigne) Date: Fri, 23 Dec 2005 11:07:47 +0100 (MET) Subject: sshd blocks SIGALRM Message-ID: <17195.1135332467@www15.gmx.net> Gidday everbody, We have just found an interesting issue regarding the sshd daemon on our SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM as shown in the /proc/pid/status: $ cat /proc/`cat /var/run/sshd.init.pid`/status Name: sshd State: S (sleeping) SleepAVG: 0% [...] SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000002000 <-- SIGALRM is blocked SigIgn: 0000000000001000 As a result, any descendent processes shall inherit this mask. The bad news is that some commands rely on SIGALRM being unmasked, e.g. those invoking alarm() or similar. If those commands are started from a "ssh shell", then they won't work correctly (e.g. never times out). That's really annoying. Do you have an idea where the problem lies? Below you shall find the relevant information about the system. Thanks in advance! Loic. ******************* System information ****************** * Hardware: HP Proliant, intel PIII 1.4Ghz * SuSE release: SuSE Professional v9.2 * uname -a: Linux mucltpa04 2.6.8-24-smp #1 SMP Wed Oct 6 09:16:23 UTC 2004 i686 i686 i386 GNU/Linux * openssh based on the following RPMs: openssh-3.9p1-3 openssh-askpass-3.9p1-3 * let me know if you need more information -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f?r GMX Partner: http://www.gmx.net/de/go/partner From carson at taltos.org Fri Dec 23 22:42:58 2005 From: carson at taltos.org (Carson Gaspar) Date: Fri, 23 Dec 2005 06:42:58 -0500 Subject: sshd blocks SIGALRM In-Reply-To: <17195.1135332467@www15.gmx.net> References: <17195.1135332467@www15.gmx.net> Message-ID: --On Friday, December 23, 2005 11:07 AM +0100 Loic Domaigne wrote: > We have just found an interesting issue regarding the sshd daemon on our > SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM > as shown in the /proc/pid/status: > > $ cat /proc/`cat /var/run/sshd.init.pid`/status > Name: sshd > State: S (sleeping) > SleepAVG: 0% > [...] > SigPnd: 0000000000000000 > ShdPnd: 0000000000000000 > SigBlk: 0000000000002000 <-- SIGALRM is blocked > SigIgn: 0000000000001000 > > As a result, any descendent processes shall inherit this mask. The bad > news is that some commands rely on SIGALRM being unmasked, e.g. those > invoking alarm() or similar. If those commands are started from a "ssh > shell", then they won't work correctly (e.g. never times out). That's > really annoying. If an application requires SIGALRM, it should explicitly set the signal handler for it. If it doesn't, it's broken. However, looking at the openssh 3.9p1 source code, it never blocks SIGALRM. It uses SIGALRM to regenerate keys. So what you say makes no sense... -- Carson From djm at mindrot.org Fri Dec 23 22:54:22 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Dec 2005 22:54:22 +1100 Subject: sshd blocks SIGALRM In-Reply-To: <17195.1135332467@www15.gmx.net> References: <17195.1135332467@www15.gmx.net> Message-ID: <43ABE56E.6090003@mindrot.org> Loic Domaigne wrote: > Gidday everbody, > > We have just found an interesting issue regarding the sshd daemon on our > SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM as > shown in the /proc/pid/status: > > $ cat /proc/`cat /var/run/sshd.init.pid`/status > Name: sshd > State: S (sleeping) > SleepAVG: 0% > [...] > SigPnd: 0000000000000000 > ShdPnd: 0000000000000000 > SigBlk: 0000000000002000 <-- SIGALRM is blocked > SigIgn: 0000000000001000 you are looking at the wrong thing. You should look at the signal masks of the descendant processes. We clear the ALRM handler in the parent after accept(). From loic-dev at gmx.net Sat Dec 24 08:10:21 2005 From: loic-dev at gmx.net (Loic Domaigne) Date: Fri, 23 Dec 2005 22:10:21 +0100 (MET) Subject: sshd blocks SIGALRM References: <43ABE56E.6090003@mindrot.org> Message-ID: <7117.1135372221@www71.gmx.net> Hello, > > We have just found an interesting issue regarding the sshd daemon on our > > SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM > > as shown in the /proc/pid/status: > > > > $ cat /proc/`cat /var/run/sshd.init.pid`/status > > Name: sshd > > State: S (sleeping) > > SleepAVG: 0% > > [...] > > SigPnd: 0000000000000000 > > ShdPnd: 0000000000000000 > > SigBlk: 0000000000002000 <-- SIGALRM is blocked > > SigIgn: 0000000000001000 > > you are looking at the wrong thing. You should look at the signal masks > of the descendant processes. We clear the ALRM handler in the parent > after accept(). Perhaps I wasn't clear enough. We execute a command in a (remote) bash shell started by the sshd. This command never timed out, because alarm() didn't worked as it should. After some non trivial investigations, we found out that SIGALRM was blocked in the signal set of the remote shell we were using, and hence in our command since the signal mask is inherited accross fork()/exec(). I traced back the process hierarchy going from child to parent to find out who did block SIGALRM in first place, and I found: /usr/sbin/sshd. Note that the same command works fine in a "local" shell (that is a shell that is not started by sshd). This is the same problem than the one discussed in the following thread: http://groups.google.de/group/linux.kernel/browse_thread/thread/8d0527bf96afa479/bf08f9b0faaa8ca6%23bf08f9b0faaa8ca6?sa=X&oi=groupsr&start=0&num=3 Regards, Loic Domaigne. -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl From djm at mindrot.org Sat Dec 24 12:39:52 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 24 Dec 2005 12:39:52 +1100 Subject: sshd blocks SIGALRM In-Reply-To: <7117.1135372221@www71.gmx.net> References: <43ABE56E.6090003@mindrot.org> <7117.1135372221@www71.gmx.net> Message-ID: <43ACA6E8.90809@mindrot.org> Loic Domaigne wrote: > After some non trivial investigations, we found out that SIGALRM was blocked > in the signal set of the remote shell we were using, and hence in our > command since the signal mask is inherited accross fork()/exec(). I don't think it makes any sense to inherit a custom SIGALRM handler across exec(). That sounds like an OS bug. Anyway, try the attached patch. -d -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-sigalarm.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051224/55ee08d5/attachment.ksh From dan at D00M.lightwave.net.ru Sat Dec 24 23:15:42 2005 From: dan at D00M.lightwave.net.ru (Dan Yefimov) Date: Sat, 24 Dec 2005 15:15:42 +0300 (MSK) Subject: sshd blocks SIGALRM In-Reply-To: <7117.1135372221@www71.gmx.net> Message-ID: On Fri, 23 Dec 2005, Loic Domaigne wrote: > Hello, > > > > We have just found an interesting issue regarding the sshd daemon on our > > > SuSE system. For some reasons, the /usr/sbin/sshd process blocks SIGALRM > > > as shown in the /proc/pid/status: > > > > > > $ cat /proc/`cat /var/run/sshd.init.pid`/status > > > Name: sshd > > > State: S (sleeping) > > > SleepAVG: 0% > > > [...] > > > SigPnd: 0000000000000000 > > > ShdPnd: 0000000000000000 > > > SigBlk: 0000000000002000 <-- SIGALRM is blocked > > > SigIgn: 0000000000001000 > > > > you are looking at the wrong thing. You should look at the signal masks > > of the descendant processes. We clear the ALRM handler in the parent > > after accept(). > > Perhaps I wasn't clear enough. We execute a command in a (remote) bash shell > started by the sshd. This command never timed out, because alarm() didn't > worked as it should. > > After some non trivial investigations, we found out that SIGALRM was blocked > in the signal set of the remote shell we were using, and hence in our > command since the signal mask is inherited accross fork()/exec(). > > I traced back the process hierarchy going from child to parent to find out > who did block SIGALRM in first place, and I found: /usr/sbin/sshd. Note that > the same command works fine in a "local" shell (that is a shell that is not > started by sshd). > > This is the same problem than the one discussed in the following > thread: > http://groups.google.de/group/linux.kernel/browse_thread/thread/8d0527bf96afa479/bf08f9b0faaa8ca6%23bf08f9b0faaa8ca6?sa=X&oi=groupsr&start=0&num=3 > Do you engage PAM in authentication? Some poorly written PAM modules can block for some reason SIGALARM while not clearing that blocking before starting user session. If sshd itself never blocks SIGALARM, one or more of PAM modules could be the reason of that. -- Sincerely Your, Dan. From loic-dev at gmx.net Tue Dec 27 03:11:49 2005 From: loic-dev at gmx.net (Loic Domaigne) Date: Mon, 26 Dec 2005 17:11:49 +0100 (MET) Subject: sshd blocks SIGALRM References: <43ACA6E8.90809@mindrot.org> Message-ID: <18598.1135613509@www40.gmx.net> Hi Damien, > > After some non trivial investigations, we found out that SIGALRM was > > blocked in the signal set of the remote shell we were using, and hence > > in our command since the signal mask is inherited accross fork()/exec(). > > I don't think it makes any sense to inherit a custom SIGALRM handler > across exec(). That sounds like an OS bug. I am not speaking about SIGALRM handler, I am speaking about the process signal mask, which is something entirely different. See sigprocmask(). On UNIX, process signal mask is inherited accross fork()/exec() as specified by the Single Unix Specification V3 standard: The new process shall inherit at least the following attributes from the calling process image: * Process ID ... * Process signal mask (see sigprocmask()) ... However, as pointed out by Dan, the problem could come from a broken PAM module that didn't cleared SIGALRM before starting the user session. This is more likely than a bug in sshd, IMHO. Regards, Loic. -- -- << Manager keeps us telling "Do not reinvent the wheel" because they want us to reinvent the car that fits to that wheel. That's definitively more useful than a stupid wheel. >> -- Loic Domaigne. GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl From loic-dev at gmx.net Tue Dec 27 03:30:49 2005 From: loic-dev at gmx.net (Loic Domaigne) Date: Mon, 26 Dec 2005 17:30:49 +0100 (MET) Subject: sshd blocks SIGALRM References: Message-ID: <18352.1135614649@www57.gmx.net> Hi Dan, > > This is the same problem than the one discussed in the following > > thread: > > > http://groups.google.de/group/linux.kernel/browse_thread/thread/8d0527bf96afa479/bf08f9b0faaa8ca6%23bf08f9b0faaa8ca6?sa=X&oi=groupsr&start=0&num=3 > Do you engage PAM in authentication? Some poorly written PAM modules can > block for some reason SIGALARM while not clearing that blocking before starting > user session. If sshd itself never blocks SIGALARM, one or more of PAM modules > could be the reason of that. Yeah, that could be the problem indeed (the thread above mention a possible PAM issue as well). Do you have an idea how I should proceed in order to find out the broken PAM module(s)? TIA, Loic. -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl From dan at D00M.lightwave.net.ru Tue Dec 27 04:57:06 2005 From: dan at D00M.lightwave.net.ru (Dan Yefimov) Date: Mon, 26 Dec 2005 20:57:06 +0300 (MSK) Subject: sshd blocks SIGALRM In-Reply-To: <18352.1135614649@www57.gmx.net> Message-ID: On Mon, 26 Dec 2005, Loic Domaigne wrote: > > Do you engage PAM in authentication? Some poorly written PAM modules can > > block for some reason SIGALARM while not clearing that blocking before > starting > > user session. If sshd itself never blocks SIGALARM, one or more of PAM > modules > > could be the reason of that. > > Yeah, that could be the problem indeed (the thread above mention a possible > PAM issue as well). Do you have an idea how I should proceed in order to > find out the broken PAM module(s)? > The only way I see is plugging all unknown (I mean third party modules, not the modules from the PAM distribution you use) PAM modules out of the corresponding stack and step by step plugging one by one module back in to see where the problem is back again. I recommend you first comparing sshd PAM configuration to, for example, login one (if local login sessions work fine in that respect). Any module present in the former but missing in the latter may be the source of problem. -- Sincerely Your, Dan. From fcusack at fcusack.com Thu Dec 29 14:17:11 2005 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 28 Dec 2005 19:17:11 -0800 Subject: sshd blocks SIGALRM In-Reply-To: <18352.1135614649@www57.gmx.net> References: <18352.1135614649@www57.gmx.net> Message-ID: <88802467C390D0491A994EAF@maguro.local> On December 26, 2005 5:30:49 PM +0100 Loic Domaigne wrote: > Yeah, that could be the problem indeed (the thread above mention a possible > PAM issue as well). Do you have an idea how I should proceed in order to > find out the broken PAM module(s)? Run sshd under gdb (or dtrace on Solaris), on entry to sigaction and sigprocmask print the stack trace. -frank From code at pizzashack.org Sat Dec 31 03:45:36 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 11:45:36 -0500 Subject: rssh: root privilege escalation flaw Message-ID: <20051230164536.GD5740@sophic.org> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/d7923020/attachment.bin From code at pizzashack.org Sat Dec 31 05:01:10 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 20:01:10 +0200 Subject: rssh: root privilege escalation flaw Message-ID: <000101c60d6b$03a7ace0$0600000a@cycan.local> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/c6882e27/attachment.bin From code at pizzashack.org Sat Dec 31 04:30:47 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 18:30:47 +0100 Subject: rssh: root privilege escalation flaw Message-ID: <000001c60d66$c5930610$86c8a8c0@MervaSBS2003.local> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/8a28089a/attachment.bin From code at pizzashack.org Sat Dec 31 08:30:23 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 16:30:23 -0500 Subject: rssh: root privilege escalation flaw Message-ID: <001401c60d88$3de92240$0901a8c0@PlanetNOCcom.local> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/5c0e5cb7/attachment.bin From code at pizzashack.org Sat Dec 31 10:30:46 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 18:30:46 -0500 Subject: rssh: root privilege escalation flaw Message-ID: <000001c60d99$0f0ff820$0901a8c0@PlanetNOCcom.local> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/571c3a8c/attachment.bin From code at pizzashack.org Sat Dec 31 10:30:35 2005 From: code at pizzashack.org (Derek Martin) Date: Fri, 30 Dec 2005 18:30:35 -0500 Subject: rssh: root privilege escalation flaw Message-ID: <000001c60d99$088cf250$1402a8c0@netcentric.local> Affected Software: rssh - all versions prior to 2.3.0 Vulnerability: local user privilege escalation Severity: *CRITICAL* Impact: local users can gain root access Solution: Please upgrade to v2.3.1 Summary ------- rssh is a restricted shell which allows a system administrator to limit users' access to a system via SSH to scp, sftp, rsync, rdist, and cvs. It also allows the system administrator the ability to chroot users to a configurable location. * PLEASE NOTE * This problem was fixed in 2.3.0, but there is another small bug (not security-related) in that version which prompted me to release 2.3.1 today. I will announce that separately in appropriate channels. Please upgrade to the 2.3.1 release, not the 2.3.0 release. Max Vozeler reported a flaw in the design of rssh_chroot_helper whereby it can be exploited to chroot to arbitrary directories and thereby gain root access. If rssh is installed on a system, and non-trusted users on that system have access which is not protected by rssh (i.e. they have full shell access), then they can use rssh_chroot_helper to chroot to arbitrary locations in the file system, and thereby gain root access. Workaround ---------- By careful configuration of file system mounts, it is possible to avoid this problem; but doing so requires a fair amount of contortion which will be difficult to re-engineer after an existing installation has already been configured. The exploit requires the user to be able to write executables in the directory they are chrooting to, and create hard links to SUID binaries within that directory structure, so by preventing either of these two things, the exploit will be foiled. System administrators can accomplish this by careful configuration of filesystem permissions, mount points, and mount options (such as no_exec, no_suid, etc.). I will not go into details since the far better solution is to upgrade. Fix --- The 2.3.0 release of rssh fixes this problem by forcing the chroot helper program to re-parse the config file instead of allowing the chroot home to be specified on the command line. Thus users not listed can not use it to chroot (or will chroot to the default location specified by the sysadmin), and users who are listed will be chrooted to the directories where they are supposed to go only. This version also fixes an unrelated bug which causes rssh_chroot_helper to crash on the ia64 architecture (and possibly others). Numerous people reported a problem with the way va_start/va_end was used in log.c, which causes a segfault on 64-bit Linux platforms. It is believed that this bug is not exploitable, since no code in this module is ever executed with root privileges. However this is also fixed in this release. Thanks -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20051230/e9ecb6ee/attachment.bin