From jholland at cs.selu.edu Sat Mar 1 06:42:22 2003 From: jholland at cs.selu.edu (Jason P Holland) Date: Fri, 28 Feb 2003 13:42:22 -0600 (CST) Subject: Hostbased Authentication Question Message-ID: Hi, I am still working on getting hostbased authentication working in OpenSSH 3.5p1. I emailed the user list, and got no response. It seems so simple, yet I have continued to have problems getting it working properly. I've read posts about it on this list, and the openssh-unix-dev list, and nothing I have tried seems to work. My question is this, does it matter which key, either ssh_host_key.pub or ssh_host_rsa_key.pub or ssh_host_dsa_key.pub, you put in /etc/ssh/ssh_known_hosts??? I have tried all three, and continue to get this error from sshd -d -d -d debug1: userauth_hostbased: cuser root chost mckinley. pkalg ssh-dss slen 55 debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x80a4e88 debug2: userauth_hostbased: chost mckinley. resolvedname mckinley ipaddr 192.168.10.1 debug2: stripping trailing dot from chost mckinley. debug2: auth_rhosts2: clientuser root hostname mckinley ipaddr 192.168.10.1 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x80a4e88 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug2: userauth_hostbased: authenticated 0 notice the "key 0x80a4e88 is disallowed" line. If I have all my host keys in /etc/ssh/ssh_known_hosts on the server I'm trying to connect to, it should allow me in. Right? I've tried all 3 at the same time, then seperately, and nothing. I've also tried generating new keys, that didn't work either. Yes I have HostbasedAuthentication set to yes in /etc/ssh/sshd_config on the server i'm connecting to. I do have HostbasedAuthentication set to yes in /etc/ssh/ssh_config on the client i'm coming from. I also have an /etc/ssh/shosts.equiv file on the server. My DSN is setup correctly on both systems, there are no problems doing a reverse looking on either box. I am using fully qualified hostnames, but I removed them from the debug output for security reasons. I have double checked my keys in /etc/ssh/ssh_known_hosts, they are not mangled. Is there anyone on this planet that actually has sshv2 hostbased authentication working in openssh 3.5? I see numerous posts about it, and I cannot seem to get it working. Perhaps this should be in the FAQ? Can anyone help? thanks Jason From levan at epix.net Sat Mar 1 13:47:03 2003 From: levan at epix.net (Philippe Levan) Date: Fri, 28 Feb 2003 21:47:03 -0500 (EST) Subject: Hostbased Authentication Question In-Reply-To: References: Message-ID: Did you try with a different account ? I believe root logins do not use (s)hosts.equiv but require an explicit .[sr]hosts file (which, in turn, requires you to set "IgnoreRhosts no"). Philippe. --- Philippe Levan | Systems Engineering levan at epix.net | epix Internet Services On Fri, 28 Feb 2003, Jason P Holland wrote: > Hi, > I am still working on getting hostbased authentication working in > OpenSSH 3.5p1. I emailed the user list, and got no response. It seems so > simple, yet I have continued to have problems getting it working properly. > I've read posts about it on this list, and the openssh-unix-dev list, and > nothing I have tried seems to work. My question is this, does it matter > which key, either ssh_host_key.pub or ssh_host_rsa_key.pub or > ssh_host_dsa_key.pub, you put in /etc/ssh/ssh_known_hosts??? I have tried > all three, and continue to get this error from sshd -d -d -d > > debug1: userauth_hostbased: cuser root chost mckinley. pkalg ssh-dss slen > 55 > debug3: mm_key_allowed entering > debug3: mm_request_send entering: type 20 > debug3: monitor_read: checking request 20 > debug3: mm_answer_keyallowed entering > debug3: mm_answer_keyallowed: key_from_blob: 0x80a4e88 > debug2: userauth_hostbased: chost mckinley. resolvedname mckinley ipaddr > 192.168.10.1 > debug2: stripping trailing dot from chost mckinley. > debug2: auth_rhosts2: clientuser root hostname mckinley ipaddr > 192.168.10.1 > debug1: temporarily_use_uid: 0/0 (e=0/0) > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 0/0 (e=0/0) > debug1: restore_uid: 0/0 > debug3: mm_answer_keyallowed: key 0x80a4e88 is disallowed > debug3: mm_request_send entering: type 21 > debug3: mm_request_receive entering > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED > debug3: mm_request_receive_expect entering: type 21 > debug3: mm_request_receive entering > debug2: userauth_hostbased: authenticated 0 > > notice the "key 0x80a4e88 is disallowed" line. If I have all my host keys > in /etc/ssh/ssh_known_hosts on the server I'm trying to connect to, it > should allow me in. Right? I've tried all 3 at the same time, then > seperately, and nothing. I've also tried generating new keys, that didn't > work either. > > Yes I have HostbasedAuthentication set to yes in /etc/ssh/sshd_config on > the server i'm connecting to. > > I do have HostbasedAuthentication set to yes in /etc/ssh/ssh_config on the > client i'm coming from. > > I also have an /etc/ssh/shosts.equiv file on the server. > > My DSN is setup correctly on both systems, there are no problems doing a > reverse looking on either box. I am using fully qualified hostnames, but > I removed them from the debug output for security reasons. > > I have double checked my keys in /etc/ssh/ssh_known_hosts, they are not > mangled. > > Is there anyone on this planet that actually has sshv2 hostbased > authentication working in openssh 3.5? I see numerous posts about it, and > I cannot seem to get it working. > > Perhaps this should be in the FAQ? > > Can anyone help? thanks > > Jason > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jholland at cs.selu.edu Sat Mar 1 14:49:33 2003 From: jholland at cs.selu.edu (Jason P Holland) Date: Fri, 28 Feb 2003 21:49:33 -0600 (CST) Subject: Hostbased Authentication Question In-Reply-To: Message-ID: Finally!! That was the one thing I had not tried, AND IT WORKED! If that is documented somewhere, then I missed it or didn't realize it was the problem. Philippe, many, many thanks for your help! Jason > Did you try with a different account ? > > I believe root logins do not use (s)hosts.equiv but require > an explicit .[sr]hosts file (which, in turn, requires you to > set "IgnoreRhosts no"). > > Philippe. > > --- > Philippe Levan | Systems Engineering > levan at epix.net | epix Internet Services > > On Fri, 28 Feb 2003, Jason P Holland wrote: > > > Hi, > > I am still working on getting hostbased authentication working in > > OpenSSH 3.5p1. I emailed the user list, and got no response. It seems so > > simple, yet I have continued to have problems getting it working properly. > > I've read posts about it on this list, and the openssh-unix-dev list, and > > nothing I have tried seems to work. My question is this, does it matter > > which key, either ssh_host_key.pub or ssh_host_rsa_key.pub or > > ssh_host_dsa_key.pub, you put in /etc/ssh/ssh_known_hosts??? I have tried > > all three, and continue to get this error from sshd -d -d -d > > > > debug1: userauth_hostbased: cuser root chost mckinley. pkalg ssh-dss slen > > 55 > > debug3: mm_key_allowed entering > > debug3: mm_request_send entering: type 20 > > debug3: monitor_read: checking request 20 > > debug3: mm_answer_keyallowed entering > > debug3: mm_answer_keyallowed: key_from_blob: 0x80a4e88 > > debug2: userauth_hostbased: chost mckinley. resolvedname mckinley ipaddr > > 192.168.10.1 > > debug2: stripping trailing dot from chost mckinley. > > debug2: auth_rhosts2: clientuser root hostname mckinley ipaddr > > 192.168.10.1 > > debug1: temporarily_use_uid: 0/0 (e=0/0) > > debug1: restore_uid: 0/0 > > debug1: temporarily_use_uid: 0/0 (e=0/0) > > debug1: restore_uid: 0/0 > > debug3: mm_answer_keyallowed: key 0x80a4e88 is disallowed > > debug3: mm_request_send entering: type 21 > > debug3: mm_request_receive entering > > debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED > > debug3: mm_request_receive_expect entering: type 21 > > debug3: mm_request_receive entering > > debug2: userauth_hostbased: authenticated 0 > > > > notice the "key 0x80a4e88 is disallowed" line. If I have all my host keys > > in /etc/ssh/ssh_known_hosts on the server I'm trying to connect to, it > > should allow me in. Right? I've tried all 3 at the same time, then > > seperately, and nothing. I've also tried generating new keys, that didn't > > work either. > > > > Yes I have HostbasedAuthentication set to yes in /etc/ssh/sshd_config on > > the server i'm connecting to. > > > > I do have HostbasedAuthentication set to yes in /etc/ssh/ssh_config on the > > client i'm coming from. > > > > I also have an /etc/ssh/shosts.equiv file on the server. > > > > My DSN is setup correctly on both systems, there are no problems doing a > > reverse looking on either box. I am using fully qualified hostnames, but > > I removed them from the debug output for security reasons. > > > > I have double checked my keys in /etc/ssh/ssh_known_hosts, they are not > > mangled. > > > > Is there anyone on this planet that actually has sshv2 hostbased > > authentication working in openssh 3.5? I see numerous posts about it, and > > I cannot seem to get it working. > > > > Perhaps this should be in the FAQ? > > > > Can anyone help? thanks > > > > Jason > > > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From listS+openssh-unix-dev at niss.com Sun Mar 2 00:25:23 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Sat, 01 Mar 2003 07:25:23 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303011325.h21DPNMe084306@crag.niss.com> Is it possible to use encryption only for authenticate and then switch to no encryption? I've looked at the code for OpenSSH 3.5p1, cipher.c, and it looks like the answer is no, at least for protocol 1. However, I cannot tell if that is a deliberate design limitation of the implementation or if it is inherent in ssh protocol 2. My dilemma is a customer who wants to use their network IDS to monitor all traffic. I can have a VPN tunnel to the edge of their network, but from that point on they want the traffic in the clear so they can monitor it. Does anyone know of a technique that would let me satisfy the customer's requirements? Thank you, Scott From markus at openbsd.org Sun Mar 2 01:09:01 2003 From: markus at openbsd.org (Markus Friedl) Date: Sat, 1 Mar 2003 15:09:01 +0100 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303011325.h21DPNMe084306@crag.niss.com> References: <200303011325.h21DPNMe084306@crag.niss.com> Message-ID: <20030301140900.GA7826@folly> On Sat, Mar 01, 2003 at 07:25:23AM -0600, Scott Bolte wrote: > Is it possible to use encryption only for authenticate and > then switch to no encryption? I've looked at the code for > OpenSSH 3.5p1, cipher.c, and it looks like the answer is > no, at least for protocol 1. However, I cannot tell if that > is a deliberate design limitation of the implementation or > if it is inherent in ssh protocol 2. you could hack openssh to do rekeying for none-encryption. would be about ~20 lines of code. From listS+openssh-unix-dev at niss.com Sun Mar 2 07:41:35 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Sat, 01 Mar 2003 14:41:35 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303012041.h21KfZqg002134@crag.niss.com> On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote: > > > Is it possible to use encryption only for authenticate and > > then switch to no encryption? ... > > you could hack openssh to do rekeying for none-encryption. > > would be about ~20 lines of code. Would you accept such a change and incorporate it back into the standard code base? Scott From mouring at etoh.eviladmin.org Sun Mar 2 09:31:45 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 1 Mar 2003 16:31:45 -0600 (CST) Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303012041.h21KfZqg002134@crag.niss.com> Message-ID: No. - Ben On Sat, 1 Mar 2003, Scott Bolte wrote: > On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote: > > > > > Is it possible to use encryption only for authenticate and > > > then switch to no encryption? ... > > > > you could hack openssh to do rekeying for none-encryption. > > > > would be about ~20 lines of code. > > Would you accept such a change and incorporate it back into > the standard code base? > > Scott > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From listS+openssh-unix-dev at niss.com Sun Mar 2 11:22:17 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Sat, 01 Mar 2003 18:22:17 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303020022.h220MHqg003791@crag.niss.com> > On Sat, 1 Mar 2003, Scott Bolte wrote: > > > On Sat, 1 Mar 2003 15:09:01 +0100, Markus Friedl wrote: > > > > > > > Is it possible to use encryption only for authenticate and > > > > then switch to no encryption? ... > > > > > > you could hack openssh to do rekeying for none-encryption. > > > would be about ~20 lines of code. > > > > Would you accept such a change and incorporate it back into > > the standard code base? > > > > Scott On Sat, 1 Mar 2003 16:31:45 -0600 (CST), Ben Lindstrom wrote: > > No. > > - Ben Why not? Network managers that want to run NIDS can hardly be unique. As long as users are comfortable with their traffic being visible, having the authorization exchange protected is a major step up from the traditional rsh. Scott From dwmw2 at infradead.org Sun Mar 2 20:43:55 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 02 Mar 2003 09:43:55 +0000 Subject: [RFC][PATCH] Require S/KEY before other authentication methods. Message-ID: <1046598234.28523.34.camel@imladris.demon.co.uk> I need a way to make sshd require S/KEY authentication to succeed before allowing either password or public-key authentication. Currently, we can only have S/KEY+password, by using PAM for authentication, and configuring PAM accordingly. But PAM of course can't handle SSH public keys. I thought for a while that ideally we could actually use PAM to tell sshd what methods of authentication to accept at each stage... require pam_ssh_skey.so sufficient pam_ssh_publickey.so sufficient pam_ssh_password.so ...etc. But PAM doesn't actually let us work like that, so it'd end up being something more like... require pam_ssh.so methods=skey require pam_ssh.so methods=publickey,password ...and I suspect it's overkill anyway. I can't really see many other possible combinations that people are likely to want. Instead of going further down this path, I implemented a simple special-case 'ChallengeResponseAuthenticationFirst' option for sshd, which makes it do what I require, offering only skey to a client at first, then offering other auth methods after skey has succeeded. Is there any point in trying to make it more generic? What other setups are people likely to want? Index: auth2-kbdint.c =================================================================== RCS file: /cvs/openssh/auth2-kbdint.c,v retrieving revision 1.1 diff -u -p -r1.1 auth2-kbdint.c --- auth2-kbdint.c 6 Jun 2002 20:27:56 -0000 1.1 +++ auth2-kbdint.c 1 Mar 2003 17:37:41 -0000 @@ -50,7 +50,13 @@ userauth_kbdint(Authctxt *authctxt) authenticated = auth2_challenge(authctxt, devs); #ifdef USE_PAM - if (authenticated == 0 && options.pam_authentication_via_kbd_int) + /* In the normal case, try PAM if challenge-response failed. + However, if this was a prerequisite challenge-response + authentication attempt, and PAM auth is permitted as a + secondary method, then force the client to come back + with a second attempt instead. */ + if (!options.challenge_response_authentication_first && + authenticated == 0 && options.pam_authentication_via_kbd_int) authenticated = auth2_pam(authctxt); #endif xfree(devs); Index: auth2.c =================================================================== RCS file: /cvs/openssh/auth2.c,v retrieving revision 1.112 diff -u -p -r1.112 auth2.c --- auth2.c 24 Feb 2003 00:59:27 -0000 1.112 +++ auth2.c 1 Mar 2003 17:37:41 -0000 @@ -228,16 +228,7 @@ userauth_finish(Authctxt *authctxt, int if (authctxt->postponed) return; - /* XXX todo: check if multiple auth methods are needed */ - if (authenticated == 1) { - /* turn off userauth */ - dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore); - packet_start(SSH2_MSG_USERAUTH_SUCCESS); - packet_send(); - packet_write_wait(); - /* now we can break out */ - authctxt->success = 1; - } else { + if (!authenticated) { if (authctxt->failures++ > AUTH_FAIL_MAX) { packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } @@ -252,6 +243,32 @@ userauth_finish(Authctxt *authctxt, int packet_send(); packet_write_wait(); xfree(methods); + } else if (!options.challenge_response_authentication_first) { + /* Success. turn off userauth */ + dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &dispatch_protocol_ignore); + packet_start(SSH2_MSG_USERAUTH_SUCCESS); + packet_send(); + packet_write_wait(); + /* now we can break out */ + authctxt->success = 1; + } else { + /* Our prereqisite challenge-response authentication has + succeeded. Allow other methods from now on... */ + debug("prerequisite keyboard-interactive auth succeeded"); + + /* And disallow challenge-response authentication so + we don't just accept it twice :) */ + options.challenge_response_authentication_first = 0; + options.challenge_response_authentication = 0; + options.kbd_interactive_authentication = options.pam_authentication_via_kbd_int; + + methods = authmethods_get(); + packet_start(SSH2_MSG_USERAUTH_FAILURE); + packet_put_cstring(methods); + packet_put_char(1); /* XXX partial success, used */ + packet_send(); + packet_write_wait(); + xfree(methods); } } @@ -272,6 +289,11 @@ authmethods_get(void) char *list; int i; + /* If challenge-response is a prerequiste, advertise + that only */ + if (options.challenge_response_authentication_first) + return xstrdup("keyboard-interactive"); + buffer_init(&b); for (i = 0; authmethods[i] != NULL; i++) { if (strcmp(authmethods[i]->name, "none") == 0) @@ -294,6 +316,10 @@ static Authmethod * authmethod_lookup(const char *name) { int i; + + if (options.challenge_response_authentication_first && + strcmp(name, "keyboard-interactive") && strcmp(name, "none")) + return NULL; if (name != NULL) for (i = 0; authmethods[i] != NULL; i++) Index: monitor.c =================================================================== RCS file: /cvs/openssh/monitor.c,v retrieving revision 1.35 diff -u -p -r1.35 monitor.c --- monitor.c 24 Feb 2003 01:03:39 -0000 1.35 +++ monitor.c 1 Mar 2003 17:37:41 -0000 @@ -297,6 +297,15 @@ monitor_child_preauth(struct monitor *pm if (!authenticated) authctxt->failures++; } + if (options.challenge_response_authentication_first && + authenticated && + (!strcmp(auth_method, "skey") || !strcmp(auth_method, "bsdauth"))) { + debug2("prerequisite keyboard-interactive authentication succeeded"); + options.challenge_response_authentication_first = 0; + options.kbd_interactive_authentication = options.pam_authentication_via_kbd_int; + options.challenge_response_authentication = 0; + authenticated = 0; + } } if (!authctxt->valid) Index: servconf.c =================================================================== RCS file: /cvs/openssh/servconf.c,v retrieving revision 1.98 diff -u -p -r1.98 servconf.c --- servconf.c 24 Feb 2003 01:04:34 -0000 1.98 +++ servconf.c 1 Mar 2003 17:37:42 -0000 @@ -100,6 +100,7 @@ initialize_server_options(ServerOptions options->password_authentication = -1; options->kbd_interactive_authentication = -1; options->challenge_response_authentication = -1; + options->challenge_response_authentication_first = -1; options->permit_empty_passwd = -1; options->permit_user_env = -1; options->use_login = -1; @@ -222,6 +223,13 @@ fill_default_server_options(ServerOption options->kbd_interactive_authentication = 0; if (options->challenge_response_authentication == -1) options->challenge_response_authentication = 1; + if (options->challenge_response_authentication_first == -1) + options->challenge_response_authentication_first = 0; + if (options->challenge_response_authentication_first && + !options->challenge_response_authentication) { + error("ChallengeResponse authentication cannot be first if it is disabled"); + options->challenge_response_authentication_first = 0; + } if (options->permit_empty_passwd == -1) options->permit_empty_passwd = 0; if (options->permit_user_env == -1) @@ -289,7 +297,7 @@ typedef enum { #ifdef AFS sAFSTokenPassing, #endif - sChallengeResponseAuthentication, + sChallengeResponseAuthentication, sChallengeResponseAuthenticationFirst, sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, @@ -345,6 +353,7 @@ static struct { { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, { "challengeresponseauthentication", sChallengeResponseAuthentication }, { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ + { "challengeresponseauthenticationfirst", sChallengeResponseAuthenticationFirst }, { "checkmail", sDeprecated }, { "listenaddress", sListenAddress }, { "printmotd", sPrintMotd }, @@ -679,6 +688,10 @@ parse_flag: case sChallengeResponseAuthentication: intptr = &options->challenge_response_authentication; + goto parse_flag; + + case sChallengeResponseAuthenticationFirst: + intptr = &options->challenge_response_authentication_first; goto parse_flag; case sPrintMotd: Index: servconf.h =================================================================== RCS file: /cvs/openssh/servconf.h,v retrieving revision 1.50 diff -u -p -r1.50 servconf.h --- servconf.h 1 Aug 2002 01:28:39 -0000 1.50 +++ servconf.h 1 Mar 2003 17:37:42 -0000 @@ -95,6 +95,9 @@ typedef struct { * authentication. */ int kbd_interactive_authentication; /* If true, permit */ int challenge_response_authentication; + int challenge_response_authentication_first; /* If true, force + clients to use challenge-response + first, before other methods */ int permit_empty_passwd; /* If false, do not permit empty * passwords. */ int permit_user_env; /* If true, read ~/.ssh/environment */ -- dwmw2 From jdennis at law.harvard.edu Tue Mar 4 01:45:05 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 03 Mar 2003 09:45:05 -0500 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303020022.h220MHqg003791@crag.niss.com> References: <200303020022.h220MHqg003791@crag.niss.com> Message-ID: <3E636A71.3000309@law.harvard.edu> >>No. >> >>- Ben > > > Why not? > > Network managers that want to run NIDS can hardly be unique. Shouldn't the IDS be detecting known attacks, not ssh traffic? Unless the attack is directed towards sshd (in which you won't get very far, Thanks Niels) the IDS should behave as normal. I think most of the attacks I remember regarding SSH attacked the authentication process anyway, so encrypting that and nothing else doesn't actually help you much. You'll only leave your users vulnerable to sniffing commands/passwords/directory structures/etc.. and possibly injection commands like what hunt used to do for telnet (http://lin.fsid.cvut.cz/~kra/index.html). > As long as users are comfortable with their traffic being > visible, having the authorization exchange protected is a > major step up from the traditional rsh. SSH is not rsh. What users would be comfortable with the traffic being visible?!? If thats what you _really_ want, maybe look into telnet with kerberos. -James From cjwatson at debian.org Tue Mar 4 03:10:22 2003 From: cjwatson at debian.org (Colin Watson) Date: Mon, 03 Mar 2003 16:10:22 +0000 Subject: IPv6 support? In-Reply-To: <20030226114702.GA1922@bumpern.de> Message-ID: In article <20030226114702.GA1922 at bumpern.de> on chiark.mail.openssh.unix.dev, Michael Schwarz wrote: >Gert Doering wrote: >> Just make sure you don't use a package that was built with "v4 only" >> (like the MacOS X people do *sigh*). > >Well, it was my fault. Ok, not really. It seems that the version which >comes with debian-woody is compiled without v6. I'm trying for about >three hours to get it work. On Debian-Sid everything works fine. Yes, there's a reason for that: some functions in glibc are broken when trying to use IPv6 on Linux 2.2 kernels. I'm surprised that it works without the -6 option in Debian unstable, because it's not supposed to. A workaround (which I still need to test ...) is in OpenSSH portable CVS, so the next Debian release will have --with-ipv4-default finally disabled. If you're not using Linux 2.2, there should be no problem recompiling without --with-ipv4-default. -- Colin Watson [cjwatson at chiark.greenend.org.uk] From uhlr at us.ibm.com Tue Mar 4 05:09:07 2003 From: uhlr at us.ibm.com (Robert A Uhl) Date: Mon, 3 Mar 2003 11:09:07 -0700 Subject: AIX 4.3.3/OpenSSH 3.5p1 Crashing Message-ID: I'm getting core dumps from sshd when logging in using password authentication (using a public key works just fine). The core dump occurs just after entering a password--whether that password is correct or not. It only happens on this one machine. I've tried recompiling the entire setup--zlib, openssl & openssh--and the crash still occurs. It doesn't look like the putty-failure issue discussed in the archives, although it may be related. Anyone have any ideas? This is what it looks like from the client side: [ruhl at pstrain ruhl]$ ssh -p 1212 localhost ruhl at localhost's password: Connection closed by 127.0.0.1 [ruhl at pstrain ruhl]$ And this from the server side: debug3: mm_request_send entering: type 10 debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORDFailed none for ruhl from 127.0.0.1 port 63536 ssh2 debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for ruhl from 127.0.0.1 port 63536 ssh2 debug1: userauth-request for user ruhl service ssh-connection method password debug1: attempt 1 failures 1 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: monitor_read: checking request 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug1: Calling cleanup 0x2000f0f4(0x0) Segmentation fault (core dumped) -- Robert Uhl IBM Global Services @ CoBank 303.694.5882 uhlr at us.ibm.com From Hafermje at osd.pentagon.mil Tue Mar 4 05:34:09 2003 From: Hafermje at osd.pentagon.mil (Haferman, Joyce E,,PERSEREC) Date: Mon, 3 Mar 2003 13:34:09 -0500 Subject: sshd does not start Message-ID: I hope I'm sending this to the correct group for resolution, if not please direct to the appropriate place for openssh problems. I complied openssh-3.5pl.tar on Solaris 8 OS system using gnu. I installed the lastest version of openssl. I did not install /www/gzip.org/zlib because I assumed that I probably have that, since I have gunzip.... Openssh compiled but I kept receiving warnings that I do not have a random generator. After the make install, I did a ps -ef|grep sshd, but sshd was not running. I typed ssh hostname and I received the error: ssh: connect to host...port 22: connection refused I tried to start sshd daemon manually: /usr/local/sbin/sshd I received the error: Privilege separtaion user sshd does not exist. The following is the tail output from the make install command: mkdir /usr/local/etc Generating public/private rsa1 key pair. Your identification has been saved in /usr/local/etc/ssh_host_key. Your public key has been saved in /usr/local/etc/ssh_host_key.pub. The key fingerprint is: c0:4a:f8:f4:a5:5f:3c:6f:a7:e7:57:e0:bf:3a:c1:76 root at cupid Generating public/private dsa key pair. Your identification has been saved in /usr/local/etc/ssh_host_dsa_key. Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub. The key fingerprint is: 9d:62:44:1b:25:40:cd:09:95:8b:fa:24:8f:68:31:10 root at cupid Generating public/private rsa key pair. Your identification has been saved in /usr/local/etc/ssh_host_rsa_key. Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub. The key fingerprint is: 23:c8:01:4a:5a:de:f6:eb:79:2d:5f:32:6d:f4:7c:27 root at cupid /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config Privilege separation user sshd does not exist make: [check-config] Error 255 (ignored) # ps -ef|grep ssh root 12182 4951 0 10:50:36 pts/1 0:00 grep ssh Any help would be greatly appreciated. Is the problem that I do not have zlib installed? Joyce Haferman Computer Systems Analyst (831) 657-3023 FAX (831) 657-0157 email: hafermje at osd.pentagon.mil or Joyce_Haferman at yahoo.com From GILBERT.R.LOOMIS at saic.com Tue Mar 4 06:25:18 2003 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Mon, 3 Mar 2003 14:25:18 -0500 Subject: Problems with OpenSSH compile/run on Solaris 8 (was: sshd does not start) Message-ID: <4E25ECBBC03F874CBAD03399254ADFDE104AC4@US-Columbia-CIST.mail.saic.com> Joyce-- > I did not install /www/gzip.org/zlib because I assumed that I > probably have that, since I have gunzip.... gunzip being present doesn't usually mean that zlib is present, but you might actually have zlib. Look for a libz.a in /usr/local/lib (or appropriate other directory structure depending on where gunzip is on your system...) > Openssh compiled but I kept receiving warnings that I do not > have a random generator. Separate issue. For Solaris 8/SPARC you really need to install patch 112438-01 which provides /dev/random, and ensure that your OpenSSL installation is using it. (That patch is labeled as security-relevant by Sun, but is still *not* included in the Sun recommended patch cluster as of last week--it should be installed on any Solaris 8 box that will ever use OpenSSL or OpenSSH.) Alternatively you could use PRNGd. Feel free to contact me offlist for more info on either. > After the make install, I did a ps -ef|grep sshd, but sshd > was not running. > > I typed ssh hostname > and I received the error: > ssh: connect to host...port 22: connection refused No surprise; you already said that sshd wasn't running, so there was no daemon there to accept the connection. > I tried to start sshd daemon manually: > /usr/local/sbin/sshd > I received the error: > Privilege separtaion user sshd does not exist. > [[Additional diagnostics deleted]] > Any help would be greatly appreciated. > Is the problem that I do not have zlib installed? Nope, you need to create the sshd privilege separation user just like the documentation says or disable privilege separation. The good news is that neither the lack of zlib nor the lack of /dev/random apparently kept things from compiling--I'm a little surprised and I'd still recommend that you go back and install zlib, install the Solaris /dev/random patch, and ensure OpenSSL is using the new /dev/random. Since you're on a PAM-aware platform and to my knowledge there are still issues with some of the PAM calls needing to be run with full root privileges, you might consider disabling privilege separation (in sshd_config, look for PrivilegeSeparation and ensure you have UsePrivilegeSeparation no on that line). Even without the privsep user, you should then be able to start sshd. To make the debugging a little easier, I then recommend you start sshd with sshd -d (which will cause it to run in debugging mode tied to a terminal, instead of going into the background) and then switch to a different virtual terminal and run ssh -v hostname so that both the daemon and client parts are running in the verbose/debugging mode. Good luck and feel free to contact me offlist if you need more help--I'm in the local area. -- Rip Loomis Senior Systems Security Engineer, SAIC Enterprise Security Solutions Brainbench MVP for Internet Security | http://www.brainbench.com From jdennis at law.harvard.edu Tue Mar 4 06:31:40 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 03 Mar 2003 14:31:40 -0500 Subject: sshd does not start In-Reply-To: References: Message-ID: <3E63AD9C.4020003@law.harvard.edu> > After the make install, I did a ps -ef|grep sshd, but sshd was not running. make install does not start the process. It never did. > I typed ssh hostname > and I received the error: > ssh: connect to host...port 22: connection refused > > I tried to start sshd daemon manually: > /usr/local/sbin/sshd > I received the error: > Privilege separtaion user sshd does not exist. You need to create an sshd user. Read the docs. > The following is the tail output from the make install command: > mkdir /usr/local/etc > Generating public/private rsa1 key pair. > Your identification has been saved in /usr/local/etc/ssh_host_key. > Your public key has been saved in /usr/local/etc/ssh_host_key.pub. > The key fingerprint is: > c0:4a:f8:f4:a5:5f:3c:6f:a7:e7:57:e0:bf:3a:c1:76 root at cupid > Generating public/private dsa key pair. > Your identification has been saved in /usr/local/etc/ssh_host_dsa_key. > Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub. > The key fingerprint is: > 9d:62:44:1b:25:40:cd:09:95:8b:fa:24:8f:68:31:10 root at cupid > Generating public/private rsa key pair. > Your identification has been saved in /usr/local/etc/ssh_host_rsa_key. > Your public key has been saved in /usr/local/etc/ssh_host_rsa_key.pub. > The key fingerprint is: > 23:c8:01:4a:5a:de:f6:eb:79:2d:5f:32:6d:f4:7c:27 root at cupid > /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config > Privilege separation user sshd does not exist > make: [check-config] Error 255 (ignored) > # ps -ef|grep ssh > root 12182 4951 0 10:50:36 pts/1 0:00 grep ssh Like I said, the sshd user doesn't exist. Read the install documentation before attempting to install anything, especially if you work for the penagon (Hafermje at osd.pentagon.mi)!! -James From tim at multitalents.net Tue Mar 4 06:49:44 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 3 Mar 2003 11:49:44 -0800 (PST) Subject: sshd does not start In-Reply-To: References: Message-ID: On Mon, 3 Mar 2003, Haferman, Joyce E,,PERSEREC wrote: > I hope I'm sending this to the correct group for resolution, if not please > direct to the appropriate place for openssh problems. > > I complied openssh-3.5pl.tar on Solaris 8 OS system using gnu. > I installed the lastest version of openssl. > I did not install /www/gzip.org/zlib because I assumed that I probably have > that, since I have gunzip.... > > Openssh compiled but I kept receiving warnings that I do not have a random > generator. > Make sure you have patch 112438 installed. [snip] > /usr/local/sbin/sshd -t -f /usr/local/etc/sshd_config > Privilege separation user sshd does not exist > make: [check-config] Error 255 (ignored) > # ps -ef|grep ssh > root 12182 4951 0 10:50:36 pts/1 0:00 grep ssh > > > Any help would be greatly appreciated. > Is the problem that I do not have zlib installed? If you didn't have zlib, openssh would not compile. As the error messege says, you need to create he user sshd or disable Privilege Separation. Your password entry should look something like this. sshd:x:67:67:OpenSSH Virtual User:/:/bin/false > > Joyce Haferman > Computer Systems Analyst > (831) 657-3023 FAX (831) 657-0157 > email: hafermje at osd.pentagon.mil or > Joyce_Haferman at yahoo.com > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From pete_bleix at hotmail.com Tue Mar 4 07:30:12 2003 From: pete_bleix at hotmail.com (Pete Bleix) Date: Mon, 03 Mar 2003 20:30:12 +0000 Subject: I discovered a great site for adults: http://www.HappyHug.com Message-ID: Hi, I was surfing and than I discovered a great site for Adults: http://www.HappyHug.com This is a new site for adults. They are operating since 9 december 2002. I think they can use some visitors. Go and take a look! Pete _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From jbeard at us.ibm.com Tue Mar 4 07:59:46 2003 From: jbeard at us.ibm.com (Jon Beard) Date: Mon, 3 Mar 2003 13:59:46 -0700 Subject: I discovered a great site for adults: http://www.HappyHug.com Message-ID: Peter Bleix: This distribution list is not to be used for Adult only content!!!!!!!!!!!! Please don't use it for distribution of such material again! Best Regards IBM SSG, RMSS RAS, Dept. 4WUA 9000 S. Rita Rd., Tucson, AZ 85744 520-799-2166, T/L 321 Pager: 1-800-946-4646 Pin 1419349 Internet: jbeard at us.ibm.com No disaster is a complete disaster unless you did not learn anything from it. "Pete Bleix" @mindrot.org on 03/03/2003 01:30:12 PM Sent by: openssh-unix-dev-admin at mindrot.org To: openssh-unix-dev at mindrot.org cc: Subject: I discovered a great site for adults: http://www.HappyHug.com Hi, I was surfing and than I discovered a great site for Adults: http://www.HappyHug.com This is a new site for adults. They are operating since 9 december 2002. I think they can use some visitors. Go and take a look! Pete _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From Graham.King at team.ozemail.com.au Tue Mar 4 09:34:45 2003 From: Graham.King at team.ozemail.com.au (Graham King) Date: Tue, 4 Mar 2003 09:34:45 +1100 Subject: I discovered a great site for adults: http://www.HappyHug.com Message-ID: <48DF30BBB73FA74E8F2B6896906F287701CAB2CF@jupiter.internal.ozemail.com.au> I think you'll find "Peter Bleix" doesn't exist. There's a vast number of fictitous hotmail accounts, sending out webspam - innocuous emails that point to porn or junk websites. I get 'em all the bloody time. Cheers Graham -----Original Message----- From: Jon Beard [mailto:jbeard at us.ibm.com] Sent: Tuesday, March 04, 2003 8:00 AM To: Pete Bleix Cc: openssh-unix-dev at mindrot.org Subject: Re: I discovered a great site for adults: http://www.HappyHug.com Peter Bleix: This distribution list is not to be used for Adult only content!!!!!!!!!!!! Please don't use it for distribution of such material again! Best Regards IBM SSG, RMSS RAS, Dept. 4WUA 9000 S. Rita Rd., Tucson, AZ 85744 520-799-2166, T/L 321 Pager: 1-800-946-4646 Pin 1419349 Internet: jbeard at us.ibm.com No disaster is a complete disaster unless you did not learn anything from it. From Hafermje at osd.pentagon.mil Tue Mar 4 10:46:56 2003 From: Hafermje at osd.pentagon.mil (Haferman, Joyce E,,PERSEREC) Date: Mon, 3 Mar 2003 18:46:56 -0500 Subject: Many thanks to all the emails - my sshd works great, now! Message-ID: Thanks for all the emails...no need to send anymore. Very informative. I appreciate all the input. The very first email solved the problem - I needed to create the sshd account. Great user group - I never received so many responses, so quickly, and so accurate. Joyce Haferman Computer Systems Analyst (831) 657-3023 FAX (831) 657-0157 email: hafermje at osd.pentagon.mil or Joyce_Haferman at yahoo.com From dtucker at zip.com.au Tue Mar 4 11:27:26 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 04 Mar 2003 11:27:26 +1100 Subject: AIX 4.3.3/OpenSSH 3.5p1 Crashing References: Message-ID: <3E63F2EE.DC5D18E9@zip.com.au> Robert A Uhl wrote: > I'm getting core dumps from sshd when logging in using password > authentication (using a public key works just fine). The core dump occurs > just after entering a password--whether that password is correct or not. It > only happens on this one machine. I've tried recompiling the entire > setup--zlib, openssl & openssh--and the crash still occurs. It doesn't look > like the putty-failure issue discussed in the archives, although it may be > related. Anyone have any ideas? The core dump might be caused by the fatal_cleanup bug (can't get on to bugzilla right now, but the patch for it is below). If so, the core dump is not the cause of your authentication problem (but might be triggered by it). The other thing you can do is to get a backtrace to show exactly where the failure is ocurring, eg: # gdb ./sshd core (gdb) backtrace -Daz. Index: log.c =================================================================== RCS file: /cvs/openssh/log.c,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- log.c 7 Jan 2003 06:04:18 -0000 1.26 +++ log.c 14 Jan 2003 11:22:43 -0000 1.27 @@ -233,6 +233,7 @@ next_cu = cu->next; xfree(cu); } + fatal_cleanups = NULL; } /* Cleanup and exit */ -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rdrake at sprint.net Tue Mar 4 12:19:39 2003 From: rdrake at sprint.net (Robert Drake) Date: Mon, 3 Mar 2003 20:19:39 -0500 Subject: hashing known_hosts Message-ID: <20030304011939.GZ5216@sprint.net> Scenario: I have access to a semi-public (about 30 users) server where I keep my webpage. Occasionally, especially if I'm on the road. I use this as a bounce point to get to "secured" systems which only allow ssh from certian IP's. (Ignoring the discussion on spoofing, since we have host keys) But host keys are the problem. If anyone gets root on this hypothetical public server they have 30 known_hosts files they can look through to find new hosts to go after. I didn't like that, so my first instinct was to delete my known_hosts file on logout, but then I lose all the benifits of host keys. So how about this? We should hash the , pair and store that in the known_hosts file. Then someone has to know the hash to figure out what host key goes to what. Drawbacks: If a host is only known by IP (no hostname) the attacker only has to check a maximum of 4 billion hashes. I'm running through these now to see how long it takes and how big the dictionary file is. You could get around this by using salt, but since you have no reference you have to check every hash in the known_host file, which could be expensive if you have 300 host keys. Alternatively, you can use DNS everywhere (which you should be doing anyway) since that gives you a hostname,xx.xx.xx.xx hash message, which makes dictionary attacks much less feasible. Another drawback is that it makes key management a bitch, since you can't search you're known_hosts file by hostname. I consider this a problem that can be addressed by ethier an external program, or by adding it into ssh. Personally I think ssh should prompt you for more options when a key comes up as invalid, something like "Host key not found. Do you want to accept new key?" Of course, I'd also like the ability to sign old host keys just to make the trust model safer. I also think this should be an optional configuration option. Something like "HashKnownHosts yes" Test code.. #include #include #include #include #include int uuencode(u_char *src, u_int srclength, char *target, size_t targsize) { return b64_ntop(src, srclength, target, targsize); } static char *pt(unsigned char *md) { int i; static char buf[80]; for (i=0; i /dev/null real 43m44.440s user 19m20.701s sys 0m3.442s revolution:~$ time ./test1 > test-dict.out real 47m53.129s user 20m23.721s sys 1m8.202s revolution:~$ ls -l test-dict.out -rw-r--r-- 1 rdrake other 3498967040 Aug 20 11:42 test-dict.out revolution:~$ ls -l dict.gz -rw-r--r-- 1 rdrake other 2044302219 Aug 20 13:42 dict.gz So, for 2% we have 2 gigs of disk space for the dictionary. A dictionary attack is obviously not too practicle, but definately feasible (especially if they can download the known_hosts file to their machine) Problem: It's hard to remove old hosts because you don't know which ones have changed. Solution: timestamp each entry with a "last accessed time". Any host that hasen't been logged into in over xxx time is later removed (or processed in some other way) Of course, if you wanted effective host management, you could always store the hostname/sha hash pairs in a public-key encrypted file. Then the user would type their passphrase and have access to the hostnames. Adds a whole asston of complications to ssh key management, but alot of it could be in an external program. I wrote this initial email about 6 months ago and finally got around to making a patch. Please let me know if this would be an interesting addition, or if I'm just a retard. Thanks, Robert -- Robert Drake -------------- next part -------------- Common subdirectories: openssh-3.4p1/autom4te-2.53.cache and openssh-3.4p1-hash/autom4te-2.53.cache Common subdirectories: openssh-3.4p1/contrib and openssh-3.4p1-hash/contrib diff -u -p openssh-3.4p1/hostfile.c openssh-3.4p1-hash/hostfile.c --- openssh-3.4p1/hostfile.c Thu Dec 20 20:47:09 2001 +++ openssh-3.4p1-hash/hostfile.c Mon Mar 3 17:28:25 2003 @@ -135,8 +135,13 @@ check_host_in_hostfile(const char *filen ; /* Check if the host name matches. */ +#ifdef HASH_KNOWN_HOSTS + if (match_hashed_hostname(host, cp, (u_int) (cp2 - cp)) != 1) + continue; +#else if (match_hostname(host, cp, (u_int) (cp2 - cp)) != 1) continue; +#endif /* Got a match. Skip host name. */ cp = cp2; diff -u -p openssh-3.4p1/match.c openssh-3.4p1-hash/match.c --- openssh-3.4p1/match.c Mon Mar 4 20:42:43 2002 +++ openssh-3.4p1-hash/match.c Mon Mar 3 17:32:17 2003 @@ -176,6 +176,14 @@ match_hostname(const char *host, const c return match_pattern_list(host, pattern, len, 1); } +#ifdef HASH_KNOWN_HOSTS +int +match_hashed_hostname(const char *host, const char *pattern, u_int len) +{ + return match_pattern_list(host, pattern, len, 0); +} +#endif + /* * returns 0 if we get a negative match for the hostname or the ip * or if we get no match at all. returns 1 otherwise. diff -u -p openssh-3.4p1/match.h openssh-3.4p1-hash/match.h --- openssh-3.4p1/match.h Mon Mar 4 20:42:43 2002 +++ openssh-3.4p1-hash/match.h Mon Mar 3 17:30:44 2003 @@ -20,5 +20,8 @@ int match_hostname(const char *, const int match_host_and_ip(const char *, const char *, const char *); int match_user(const char *, const char *, const char *, const char *); char *match_list(const char *, const char *, u_int *); +#ifdef HASH_KNOWN_HOSTS +int match_hashed_hostname(const char *, const char *, u_int); +#endif #endif Common subdirectories: openssh-3.4p1/openbsd-compat and openssh-3.4p1-hash/openbsd-compat diff -u -p openssh-3.4p1/readconf.c openssh-3.4p1-hash/readconf.c --- openssh-3.4p1/readconf.c Thu Jun 20 20:41:52 2002 +++ openssh-3.4p1-hash/readconf.c Mon Mar 3 17:33:00 2003 @@ -114,6 +114,9 @@ typedef enum { oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, oClearAllForwardings, oNoHostAuthenticationForLocalhost, +#ifdef HASH_KNOWN_HOSTS + oHashKnownHosts, +#endif oDeprecated } OpCodes; @@ -186,6 +189,9 @@ static struct { { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, +#ifdef HASH_KNOWN_HOSTS + { "hashknownhosts", oHashKnownHosts }, +#endif { NULL, oBadOption } }; @@ -380,6 +386,12 @@ parse_flag: intptr = &options->check_host_ip; goto parse_flag; +#ifdef HASH_KNOWN_HOSTS + case oHashKnownHosts: + intptr = &options->hash_known_hosts; + goto parse_flag; +#endif + case oStrictHostKeyChecking: intptr = &options->strict_host_key_checking; arg = strdelim(&s); @@ -793,6 +805,9 @@ initialize_options(Options * options) options->bind_address = NULL; options->smartcard_device = NULL; options->no_host_authentication_for_localhost = - 1; +#ifdef HASH_KNOWN_HOSTS + options->hash_known_hosts = -1; +#endif } /* @@ -907,6 +922,10 @@ fill_default_options(Options * options) clear_forwardings(options); if (options->no_host_authentication_for_localhost == - 1) options->no_host_authentication_for_localhost = 0; +#ifdef HASH_KNOWN_HOSTS + if (options->hash_known_hosts == -1) + options->hash_known_hosts = 0; +#endif /* options->proxy_command should not be set by default */ /* options->user will be set in the main program if appropriate */ /* options->hostname will be set in the main program if appropriate */ diff -u -p openssh-3.4p1/readconf.h openssh-3.4p1-hash/readconf.h --- openssh-3.4p1/readconf.h Sun Jun 9 16:04:03 2002 +++ openssh-3.4p1-hash/readconf.h Wed Aug 21 11:44:59 2002 @@ -100,6 +100,9 @@ typedef struct { Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; int no_host_authentication_for_localhost; +#ifdef HASH_KNOWN_HOSTS + int hash_known_hosts; +#endif } Options; Common subdirectories: openssh-3.4p1/regress and openssh-3.4p1-hash/regress Common subdirectories: openssh-3.4p1/scard and openssh-3.4p1-hash/scard diff -u -p openssh-3.4p1/sshconnect.c openssh-3.4p1-hash/sshconnect.c --- openssh-3.4p1/sshconnect.c Sun Jun 23 17:23:20 2002 +++ openssh-3.4p1-hash/sshconnect.c Mon Mar 3 17:34:04 2003 @@ -17,6 +17,11 @@ RCSID("$OpenBSD: sshconnect.c,v 1.126 20 #include +#ifdef HASH_KNOWN_HOSTS +#include +#include "uuencode.h" +#endif + #include "ssh.h" #include "xmalloc.h" #include "rsa.h" @@ -505,6 +510,11 @@ check_host_key(char *host, struct sockad char msg[1024]; int len, host_line, ip_line; const char *host_file = NULL, *ip_file = NULL; +#ifdef HASH_KNOWN_HOSTS + unsigned char md[SHA_DIGEST_LENGTH]; + char uu[SHA_DIGEST_LENGTH*2]; +#endif + /* * Force accepting of the host key for loopback/localhost. The @@ -579,6 +589,26 @@ check_host_key(char *host, struct sockad * hosts or in the systemwide list. */ host_file = user_hostfile; + +#ifdef HASH_KNOWN_HOSTS + if (options.hash_known_hosts) { + /* + * turn off host ip checking because we take care of it + */ + options.check_host_ip = 0; + + snprintf(hostline, sizeof(hostline), "%s,%s", host,ip); + SHA1(hostline, strlen(hostline), md); + uuencode(md, SHA_DIGEST_LENGTH, uu, SHA_DIGEST_LENGTH*2); + host_status = check_host_in_hostfile(host_file, uu, host_key, + file_key, &host_line); + if (host_status == HOST_NEW) { + host_file = system_hostfile; + host_status = check_host_in_hostfile(host_file, uu, + host_key, file_key, &host_line); + } + } else { +#endif host_status = check_host_in_hostfile(host_file, host, host_key, file_key, &host_line); if (host_status == HOST_NEW) { @@ -586,6 +616,10 @@ check_host_key(char *host, struct sockad host_status = check_host_in_hostfile(host_file, host, host_key, file_key, &host_line); } + +#ifdef HASH_KNOWN_HOSTS + } /* end if options.hash_known_hosts */ +#endif /* * Also perform check for the ip address, skip the check if we are * localhost or the hostname was an ip address to begin with @@ -662,6 +696,10 @@ check_host_key(char *host, struct sockad if (options.check_host_ip && ip_status == HOST_NEW) { snprintf(hostline, sizeof(hostline), "%s,%s", host, ip); hostp = hostline; +#ifdef HASH_KNOWN_HOSTS + } else if (options.hash_known_hosts) { + hostp = uu; +#endif } else hostp = host; From listS+openssh-unix-dev at niss.com Tue Mar 4 12:09:08 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Mon, 03 Mar 2003 19:09:08 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303040109.h24198qg029694@crag.niss.com> On Mon, 03 Mar 2003 09:45:05 -0500, James Dennis wrote: > > Shouldn't the IDS be detecting known attacks, not ssh traffic? Their concern is that the traffic, which will be remote service commands by the way, is completely opaque to them. They feel they need to monitor the internals to make sure it is appropriate traffic and not an unknown 3rd party using the cloak of encryption to hide inappropriate actions. > SSH is not rsh. What users would be comfortable with the traffic being > visible?!? If thats what you _really_ want, maybe look into telnet with > kerberos. What I'm trying to do is standardize on ssh, which is fine with most customers. For those that want to monitor traffic internals, I want to still use my ssh infrastructure, albeit with no encryption after the authorization is complete. I realize it is an odd situation, but I'm not in a position to refuse the customer's insistence. Scott From mouring at etoh.eviladmin.org Wed Mar 5 03:16:11 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 4 Mar 2003 10:16:11 -0600 (CST) Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303040109.h24198qg029694@crag.niss.com> Message-ID: On Mon, 3 Mar 2003, Scott Bolte wrote: > On Mon, 03 Mar 2003 09:45:05 -0500, James Dennis wrote: > > > > Shouldn't the IDS be detecting known attacks, not ssh traffic? > > Their concern is that the traffic, which will be remote > service commands by the way, is completely opaque to them. > They feel they need to monitor the internals to make sure > it is appropriate traffic and not an unknown 3rd party using > the cloak of encryption to hide inappropriate actions. > Stupidity comes in many forms. By weakening their security they think they are improving it. I would never go near such a company. I'm sure anyone with any amount of common sense can outsmart any NIDS system on the face of the earth. > > SSH is not rsh. What users would be comfortable with the traffic being > > visible?!? If thats what you _really_ want, maybe look into telnet with > > kerberos. > > What I'm trying to do is standardize on ssh, which is fine > with most customers. For those that want to monitor traffic > internals, I want to still use my ssh infrastructure, albeit > with no encryption after the authorization is complete. > > I realize it is an odd situation, but I'm not in a position > to refuse the customer's insistence. > Do what most sane people do. Discuss the concept of a basin. So at least your encrypted all the way into their network. Then you can use whatever bridge method you like from there. In any respects, RFC strongly discourages no encryption (none OPTIONAL no encryption; NOT RECOMMENDED). So I doubt we will see -c none for v2 protocol. - Ben From jdennis at law.harvard.edu Wed Mar 5 03:41:25 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Tue, 04 Mar 2003 11:41:25 -0500 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: References: Message-ID: <3E64D735.7040000@law.harvard.edu> Ben Lindstrom wrote: > > On Mon, 3 Mar 2003, Scott Bolte wrote: > > >>On Mon, 03 Mar 2003 09:45:05 -0500, James Dennis wrote: >> >>>Shouldn't the IDS be detecting known attacks, not ssh traffic? >> >> Their concern is that the traffic, which will be remote >> service commands by the way, is completely opaque to them. >> They feel they need to monitor the internals to make sure >> it is appropriate traffic and not an unknown 3rd party using >> the cloak of encryption to hide inappropriate actions. >> > > > Stupidity comes in many forms. By weakening their security they think > they are improving it. I would never go near such a company. I'm sure > anyone with any amount of common sense can outsmart any NIDS system on the > face of the earth. Amen. -James From dwmw2 at infradead.org Wed Mar 5 03:42:17 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 04 Mar 2003 16:42:17 +0000 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: References: Message-ID: <1046796137.12066.49.camel@passion.cambridge.redhat.com> On Tue, 2003-03-04 at 16:16, Ben Lindstrom wrote: > In any respects, RFC strongly discourages no encryption (none > OPTIONAL no encryption; NOT RECOMMENDED). So I doubt we will > see -c none for v2 protocol. Nevertheless, it's not _unconditionally_ stupid. Consider, for example, Host *.mynet.internal ProxyCommand ssh -c none -C bastion.mynet.external netcat %h %p When the client is a 200MHz StrongARM-based PDA, running 'ssh mail.mynet.internal exec imapd' to get at its mail server, there's not a great deal of point in using up its CPU and battery in encrypting the traffic twice, when once would suffice perfectly well. -- dwmw2 From listS+openssh-unix-dev at niss.com Wed Mar 5 13:39:54 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Tue, 04 Mar 2003 20:39:54 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303050239.h252dsqg044958@crag.niss.com> On Tue, 4 Mar 2003 10:16:11 -0600 (CST), Ben Lindstrom wrote: > > Stupidity comes in many forms. By weakening their security they think > they are improving it. ... I agree that they are taking a risk in this case. However, they do have a point. When all traffic is encrypted, it benefits those with malicious intent as much as legitimate users. Statistical process controls to detect aberrant behavior is pretty weak detection. > Do what most sane people do. Discuss the concept of a basin. So > at least your encrypted all the way into their network. Then you can use > whatever bridge method you like from there. Sorry, I thought I had mentioned that earlier. That is what we do. Connections from our network to their network is over VPN. It is only after we surface from the VPN concentrator on their network that the ssh encryption becomes an issue. Scott P.S. Btw, an interesting set of observations wrt privacy can be found in David Brin's "The Transparent Society" (http://www.kithrup.com/brin/tschp1.html) A must read for anyone interested in issues of privacy. From markus at openbsd.org Thu Mar 6 00:33:00 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 5 Mar 2003 14:33:00 +0100 Subject: PermitRootLogin=yes no longer lets root login In-Reply-To: <3E37D1CE.39D02604@zip.com.au> References: <3E37D1CE.39D02604@zip.com.au> Message-ID: <20030305133300.GA20171@folly> OpenBSD's code has int auth_password(Authctxt *authctxt, const char *password) { struct passwd * pw = authctxt->pw; /* deny if no user. */ if (pw == NULL) return 0; if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) return 0; if (*password == '\0' && options.permit_empty_passwd == 0) return 0; ... and this is intentional On Thu, Jan 30, 2003 at 12:06:22AM +1100, Darren Tucker wrote: > Hi All, > While testing another patch, I found that I could not longer log in as > root, even if PermitRootLogin was yes. It seems to be the following > code in auth_password: > > $ cvs diff -r1.48 -r1.49 auth-passwd.c > [snip] > #ifndef HAVE_CYGWIN > - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > + if (pw->pw_uid == 0 && options.permit_root_login != > PERMIT_NO_PASSWD) > return 0; > #endif > [snip] > > Was this intentional? > > -Daz. > > -- > 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. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Thu Mar 6 01:12:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Mar 2003 01:12:41 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030305141241.7774C94227@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From hauser at acm.org 2003-03-06 01:12 ------- Damien, Thanks for the hint. Unfortunately, your suggestion in http://bugzilla.mindrot.org/show_bug.cgi?id=500#c5 appears not to work because in my case, ssh-agent doesn't remove the SSH_AUTH_SOCK file when it dies/gets killed. Thus, next time I log in (e.g. after a re-boot), the socket/file is still there, but no ssh-agent available in memory nor will it be started. It appears that </dev/null 2>&1 || ssh-add>> is working. Furthermore, I am confused that you discarded this documentation enhancement suggestion as "invalid". To me, it appears that you have built an outstanding software with OpenSSH, but for a JoeAnyUser like myself, it is overly hard to get started with it. Assuming that you and your community do care about improving the daily security practices and behaviour of the average users out there, I contend that improving the documentation is by far the cheapest approach to boost more widespread adoption of this wonderful product. In this light, I also suggest not to discard simple and really cheap to implement convenience features to the website such as a search function (see http://bugzilla.mindrot.org/show_bug.cgi?id=478) - for us JoeAnyUsers, things like that matter! Anyway, once I get around it to convert my ssh-agent man-page extension suggestion from html to troff's *.1 (http://bugzilla.mindrot.org/show_bug.cgi?id=481), I'll mention the conclusion of this discussion here too and I hope not to delay/bore the experts too much with that :) Ralf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jdennis at law.harvard.edu Thu Mar 6 01:25:43 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Wed, 05 Mar 2003 09:25:43 -0500 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303050239.h252dsqg044958@crag.niss.com> References: <200303050239.h252dsqg044958@crag.niss.com> Message-ID: <3E6608E7.20409@law.harvard.edu> Scott Bolte wrote: > On Tue, 4 Mar 2003 10:16:11 -0600 (CST), Ben Lindstrom wrote: > >>Stupidity comes in many forms. By weakening their security they think >>they are improving it. ... > > > I agree that they are taking a risk in this case. However, > they do have a point. When all traffic is encrypted, it > benefits those with malicious intent as much as legitimate > users. Statistical process controls to detect aberrant > behavior is pretty weak detection. > If this is what they want, why use ssh? Using SSH here will almost definitly create a false sense of security for people who aren't entirely sure whats going on. "Oh, our logins are encrypted? Cool." as they probably would't know the entire session can be encrypted. I can't help but feel like if you want to watch the traffic of people's ssh session then you are already hacked. Attacks may come in against SSH, but if the authentication process is all that is attacked, and that part is encrypted anyway, so your NIDS won't work. What if you lock SSH down so that people can only connect to it from approved areas. Then also use AllowUsers/AllowGroups to lock it down to users in those areas. I feel like sending traffic cleartext is just a bad idea accross the board. What if someone su's or logs into other systems or exposes database account credentials to something containing personal info and/or credit card numbers from those cleartext ssh sessions?!? Your most likely going to accidentally expose much more than it's worth. NIDS don't seem to work very well (false positives are out of control) and if someone slipped past, they will most likely sniff a little (being passive recon and all) whats going on and your doubly screwed. -James From GILBERT.R.LOOMIS at saic.com Thu Mar 6 01:47:19 2003 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Wed, 5 Mar 2003 09:47:19 -0500 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <4E25ECBBC03F874CBAD03399254ADFDE104ACB@US-Columbia-CIST.mail.saic.com> > I can't help but feel like if you want to watch the traffic > of people's ssh session then you are already hacked. In some realms, particularly financial institutions, there's a requirement that all network traffic in/out of corporate "desktop type" networks must be collected -- so that the institution can prove what it knew when. Think "insider trading" as well as proprietary data. However, most of those organizations don't use SSH in or outbound. In my experience the folks with those sorts of requirements who outsource some of their server/network operations or monitoring provide a separate dedicated network connection for the outsourcing folks, or use a "basin" as Ben already mentioned (although I've heard it called other things). If SSH did support a mode where authentication information was encrypted but terminal sessions were not, it would satisfy a real world requirement IMHO. What's not clear, though, is whether that requirement is worth satisfying in the "stock" portable OpenSSH. > I feel like sending traffic cleartext is just a bad idea accross the > board. What if someone su's or logs into other systems or exposes > database account credentials to something containing personal info > and/or credit card numbers from those cleartext ssh sessions?!? That's a valid concern--as I said, though, the places that want this sort of functionality generally have a good reason (either legal, or based on a full-up risk and threat assessment) why they want to collect it. It might seem strange, but it does happen. -- Rip Loomis Senior Systems Security Engineer, SAIC Enterprise Security Solutions Brainbench MVP for Internet Security | http://www.brainbench.com From markus at openbsd.org Thu Mar 6 02:36:14 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 5 Mar 2003 16:36:14 +0100 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: References: <200303040109.h24198qg029694@crag.niss.com> Message-ID: <20030305153614.GB7308@folly> On Tue, Mar 04, 2003 at 10:16:11AM -0600, Ben Lindstrom wrote: > So I doubt we will see -c none for v2 protocol. I thought about -c none before, especially since it's useful for testing, but it's so easy for people to screw things up if -c none is available... From Stefan.Voelkel at millenux.com Thu Mar 6 03:20:25 2003 From: Stefan.Voelkel at millenux.com (Stefan Voelkel) Date: 05 Mar 2003 17:20:25 +0100 Subject: ACL Support for sftp Message-ID: <1046881224.12984.3.camel@lt-sv> Hello, I would like to see getfacl/setfacl as commands added to sftp. Are there any plans on doing this, or whom should I send patches to? Thanks in advance regards Stefan -- -------------------------------------------------------------------- Stefan V?lkel stefan.voelkel at millenux.com Millenux GmbH mobile: +49.170.79177.17 Lilienthalstra?e 2 phone: +49.711.88770.300 70825 Stuttgart-Korntal fax: +49.711.88770.349 -= linux without limits -=- http://linux.zSeries.org/ =- From markus at openbsd.org Thu Mar 6 06:36:48 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 5 Mar 2003 20:36:48 +0100 Subject: ACL Support for sftp In-Reply-To: <1046881224.12984.3.camel@lt-sv> References: <1046881224.12984.3.camel@lt-sv> Message-ID: <20030305193647.GB11149@folly> draft-ietf-secsh-filexfer-03.txt defines acl attributes, so you have have to extend SSH_FXP_SETSTAT & co there are no plans to support this, but you can send patches here, or use our bugzilla to make sure they don't get lost... -m On Wed, Mar 05, 2003 at 05:20:25PM +0100, Stefan Voelkel wrote: > Hello, > > I would like to see getfacl/setfacl as commands added to sftp. Are there > any plans on doing this, or whom should I send patches to? > > Thanks in advance > > regards > Stefan > > -- > -------------------------------------------------------------------- > Stefan V?lkel stefan.voelkel at millenux.com > Millenux GmbH mobile: +49.170.79177.17 > Lilienthalstra?e 2 phone: +49.711.88770.300 > 70825 Stuttgart-Korntal fax: +49.711.88770.349 > -= linux without limits -=- http://linux.zSeries.org/ =- > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Thu Mar 6 08:53:39 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Mar 2003 08:53:39 +1100 Subject: PermitRootLogin=yes no longer lets root login References: <3E37D1CE.39D02604@zip.com.au> <20030305133300.GA20171@folly> Message-ID: <3E6671E3.3457D923@zip.com.au> Markus Friedl wrote: > On Thu, Jan 30, 2003 at 12:06:22AM +1100, Darren Tucker wrote: > > #ifndef HAVE_CYGWIN > > - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > > + if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_NO_PASSWD) > > > > Was this intentional? > OpenBSD's code has .. > if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > return 0; .. > and this is intentional Um... I was querying the change from PERMIT_YES to PERMIT_NO_PASSWD in -portable, and AFAIK it was changed in error and has long since been fixed (or have I missed something?) -- 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 markus at openbsd.org Thu Mar 6 09:08:17 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 5 Mar 2003 23:08:17 +0100 Subject: PermitRootLogin=yes no longer lets root login In-Reply-To: <3E6671E3.3457D923@zip.com.au> References: <3E37D1CE.39D02604@zip.com.au> <20030305133300.GA20171@folly> <3E6671E3.3457D923@zip.com.au> Message-ID: <20030305220817.GC23396@folly> On Thu, Mar 06, 2003 at 08:53:39AM +1100, Darren Tucker wrote: > Markus Friedl wrote: > > On Thu, Jan 30, 2003 at 12:06:22AM +1100, Darren Tucker wrote: > > > #ifndef HAVE_CYGWIN > > > - if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > > > + if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_NO_PASSWD) > > > > > > Was this intentional? > > > OpenBSD's code has > .. > > if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > > return 0; > .. > > and this is intentional > > Um... I was querying the change from PERMIT_YES to PERMIT_NO_PASSWD in > -portable, and AFAIK it was changed in error and has long since been > fixed (or have I missed something?) hm, password authentication for uid 0 should _only_ be allowed for PERMIT_YES; so if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) return 0; is ok, or what am i missing? From bugzilla-daemon at mindrot.org Thu Mar 6 09:26:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Mar 2003 09:26:04 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030305222604.DBA9D94248@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From djm at mindrot.org 2003-03-06 09:26 ------- The socket should disappear after the server stops listening, if this isn't the case you should chase it up with the cygwin people. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Thu Mar 6 09:48:09 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Mar 2003 09:48:09 +1100 Subject: PermitRootLogin=yes no longer lets root login References: <3E37D1CE.39D02604@zip.com.au> <20030305133300.GA20171@folly> <3E6671E3.3457D923@zip.com.au> <20030305220817.GC23396@folly> Message-ID: <3E667EA9.8324774B@zip.com.au> Markus Friedl wrote: > hm, password authentication for uid 0 should _only_ > be allowed for PERMIT_YES; so > > if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) > return 0; > > is ok, or what am i missing? Yes, I thinks that's OK. For a few days a month ago -portable had PERMIT_NO_PASSWD instead of PERMIT_YES. Damien acknowledged it as a bug and fixed it the same day my original message was sent (30th of January). -- 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 bugzilla-daemon at mindrot.org Thu Mar 6 09:52:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Mar 2003 09:52:16 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030305225216.0325194251@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From markus at openbsd.org 2003-03-06 09:52 ------- the agent's cleanup_socket() should handle this. unless you kill -9.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nicklange at wi.rr.com Thu Mar 6 14:23:15 2003 From: nicklange at wi.rr.com (Nick Lange) Date: Wed, 05 Mar 2003 21:23:15 -0600 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104ACB@US-Columbia-CIST.mail.saic.com> References: <4E25ECBBC03F874CBAD03399254ADFDE104ACB@US-Columbia-CIST.mail.saic.com> Message-ID: <3E66BF23.7020003@wi.rr.com> Afternoon everyone, If everyone is entirely concerned about innocuous commands comming over the ssh session to the shell account, why not just analyze the shell logs for analysis there? Tap the destination, not the transit. [OT, beware] My solution I had been playing with per an article in sysadmin was logging each individual session to a "log" directory broken down by time date etc. You could go one step farther than this however, and mod their favorite shell to flush it's output to a named pipe for analysis by your IDS of choice. [I would go that extra step and modify their shell not autoflush so that if they kill -9 their shell you don't lose the session log (bash)]. the data is still protected in transit to the box, and their admin's can still "sniff" the user's traffic for analysis of bad things. *shrug*, I guess this is an admin philosophy thing. Being in the named below industry, I've also had this discussion before. It usually takes planting the idea in peoples heads and letting it simmer for a while until it makes sense to them; albeit, some poeople refuse to see the pitfalls of cleartext traffic even after being fully informed. Good luck, nick Loomis, Rip wrote: >>I can't help but feel like if you want to watch the traffic >>of people's ssh session then you are already hacked. > > > In some realms, particularly financial institutions, there's > a requirement that all network traffic in/out of corporate > "desktop type" networks must be collected -- so that the > institution can prove what it knew when. Think "insider trading" > as well as proprietary data. > > However, most of those organizations don't use SSH in or outbound. > In my experience the folks with those sorts of requirements who > outsource some of their server/network operations or monitoring > provide a separate dedicated network connection for the > outsourcing folks, or use a "basin" as Ben already mentioned > (although I've heard it called other things). > > If SSH did support a mode where authentication information was > encrypted but terminal sessions were not, it would satisfy a > real world requirement IMHO. What's not clear, though, is whether > that requirement is worth satisfying in the "stock" portable > OpenSSH. > > >>I feel like sending traffic cleartext is just a bad idea accross the >>board. What if someone su's or logs into other systems or exposes >>database account credentials to something containing personal info >>and/or credit card numbers from those cleartext ssh sessions?!? > > > That's a valid concern--as I said, though, the places that want > this sort of functionality generally have a good reason (either > legal, or based on a full-up risk and threat assessment) why they > want to collect it. It might seem strange, but it does happen. > > -- > Rip Loomis > Senior Systems Security Engineer, SAIC Enterprise Security Solutions > Brainbench MVP for Internet Security | http://www.brainbench.com > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Thu Mar 6 17:14:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Mar 2003 17:14:53 +1100 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030306061453.EBFF394256@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vinschen at redhat.com ------- Additional Comments From hauser at acm.org 2003-03-06 17:14 ------- Thx for the hints, in this case, unfortunately shutdown/restart of win2k appear to be equivalent to "kill -9" for the cygwin version of ssh-agent ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ed at membled.com Thu Mar 6 19:09:46 2003 From: ed at membled.com (Ed Avis) Date: Thu, 6 Mar 2003 08:09:46 +0000 (GMT) Subject: encrypt authentication credentials with payload in the clear?Re: In-Reply-To: <20030306010002.29466.62686.Mailman@shitei.mindrot.org> Message-ID: James Dennis wrote: [unencrypted traffic after initial authentication] >If this is what they want, why use ssh? Even if you don't want encryption, ssh is a much better choice than telnet or rsh or any other alternative. The ssh and sshd code is maintained and checked for buffer overruns and other security holes unrelated to eavesdropping or hijacking a connection. I don't think there is any decent implementation of telnetd or rshd still maintained, even if there once was, because all the people who care about security switched to ssh long ago. Apart from security there are also convenience reasons to prefer unencrypted-ssh over telnet or rsh - the user interface of the ssh client is familiar, it supports port forwarding, only one daemon to run instead of two (if you had ssh for encrypted and telnet for unencrypted connections), and so on. Please take it as a compliment that people are keen to use ssh and sshd even without the added security provided by encrypting all traffic. Given that ssh long had a 'fall back to rsh' option I don't think it's too unreasonable to ask for the ssh protocol with no encryption, which will still be far better than running a crusty old rshd. -- Ed Avis From joerg.jans at gwtel.de Thu Mar 6 18:52:09 2003 From: joerg.jans at gwtel.de (=?iso-8859-1?Q?J=F6rg_Jans?=) Date: Thu, 6 Mar 2003 08:52:09 +0100 Subject: New option for ssh-keygen Message-ID: <001701c2e3b5$4d383470$011b16ac@gwtel.de> Hi there, because I needed to automate the generation of keys in a background process without user interaction I implementet a new option -o. If this option is set an existing key will be replaced without a question to the user. Could you please check if this option can be used for forthcoming versions of openssh? Thanks in advance. J?rg Jans -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030306/4fb53d27/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-keygen.c Type: application/octet-stream Size: 24941 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030306/4fb53d27/attachment.obj From bugzilla-daemon at mindrot.org Thu Mar 6 20:46:40 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 6 Mar 2003 20:46:40 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030306094640.44C4C94269@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #234 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-03-06 20:46 ------- Created an attachment (id=240) --> (http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view) passexpire17: AIX & /etc/shadow password expiry Enabled basic PAM password expiry support. This accounts for about half the problems reported with these patches (ie people configuring this patch --with-pam, which didn't work previously). Fixed problem where forced-password changes (passwd -f) did not work when account expiry was not enabled. Re-ordered to test for forced change first. Same patch against 3.5p1 release at http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire17.patch ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From listS+openssh-unix-dev at niss.com Fri Mar 7 00:11:54 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Thu, 06 Mar 2003 07:11:54 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303061311.h26DBsqg065726@crag.niss.com> On Wed, 5 Mar 2003 09:47:19 -0500, "Loomis, Rip" wrote: ... > If SSH did support a mode where authentication information was > encrypted but terminal sessions were not, it would satisfy a > real world requirement IMHO. What's not clear, though, is whether > that requirement is worth satisfying in the "stock" portable > OpenSSH. > > ... > > That's a valid concern--as I said, though, the places that want > this sort of functionality generally have a good reason (either > legal, or based on a full-up risk and threat assessment) why they > want to collect it. It might seem strange, but it does happen. One reason I really want it in the 'stock' OpenSSH is because it enables a migration path. We can satisfy an organization who's current mindset requires monitorable traffic. Then, as we educate them as to the risks they are taking, and address their other requirements in a more elegant manner, we move them towards a more secure use of ssh. Scott From listS+openssh-unix-dev at niss.com Fri Mar 7 00:18:32 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Thu, 06 Mar 2003 07:18:32 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303061318.h26DIWqg065820@crag.niss.com> On Wed, 05 Mar 2003 21:23:15 -0600, Nick Lange wrote: > Afternoon everyone, > If everyone is entirely concerned about innocuous commands comming over > the ssh session to the shell account, why > not just analyze the shell logs for analysis there? Shell access needs to go away IMHO. It is too easy to defeat audit trails if there is unfettered shell access. The long term direction I am trying to go is role based access controls using sets of public/private keys which gain access to a proxy command system. That would allow more reliable logging, with excellent access management, without having to worry about all the end cases a shell entails. Scott From listS+openssh-unix-dev at niss.com Fri Mar 7 00:24:50 2003 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Thu, 06 Mar 2003 07:24:50 -0600 Subject: encrypt authentication credentials with payload in the clear? Message-ID: <200303061324.h26DOoqg065941@crag.niss.com> On Wed, 05 Mar 2003 09:25:43 -0500, James Dennis wrote: > > If this is what they want, why use ssh? Using SSH here will almost > definitly create a false sense of security for people who aren't > entirely sure whats going on. "Oh, our logins are encrypted? Cool." as > they probably would't know the entire session can be encrypted. Why use ssh? Because ssh definitely takes me where I want to go. As I said in a separate message, I want to use forced commands and public/private keys. As I work towards that sophisticated and secure capability, I need stop-gap measures to buy time to educate those organizations with a heavy reliance on NIDS. > I feel like sending traffic cleartext is just a bad idea accross the > board. What if someone su's or logs into other systems or exposes > database account credentials to something containing personal info > and/or credit card numbers from those cleartext ssh sessions?!? ... That's why I want to use forced commands which gain access to a set of proxy services. The proxies will preclude the inadvertent su, or the bare download of sensitive data. Scott From samuel at bcgreen.com Fri Mar 7 07:50:28 2003 From: samuel at bcgreen.com (Stephen Samuel) Date: Thu, 06 Mar 2003 12:50:28 -0800 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303061324.h26DOoqg065941@crag.niss.com> References: <200303061324.h26DOoqg065941@crag.niss.com> Message-ID: <3E67B494.20507@bcgreen.com> Scott Bolte wrote: > On Wed, 05 Mar 2003 09:25:43 -0500, James Dennis wrote: > >>If this is what they want, why use ssh? Using SSH here will almost ..... >>I feel like sending traffic cleartext is just a bad idea accross the >>board. What if someone su's or logs into other systems or exposes >>database account credentials to something containing personal info >>and/or credit card numbers from those cleartext ssh sessions?!? ... > > That's why I want to use forced commands which gain access > to a set of proxy services. The proxies will preclude the > inadvertent su, or the bare download of sensitive data. Perhaps a more sane approach would be to use a key escrow system for ssh. As I remember it, ssh can/does use symetric encryption for session data, so key escrow would allow 'authorized' snoops (unfortunately including people who manage to break into such authorized accounts) to listen in on the session data without exposing it to the entire intervening internet community. -- Stephen Samuel +1(604)876-0426 samuel at bcgreen.com http://www.bcgreen.com/~samuel/ Powerful committed communication, reaching through fear, uncertainty and doubt to touch the jewel within each person and bring it to life. From mouring at etoh.eviladmin.org Fri Mar 7 13:00:42 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 6 Mar 2003 20:00:42 -0600 (CST) Subject: Call for testing for 3.6 Message-ID: We are heading into a lock here. So we need to get people to test their respective platforms if they wish them to be supported out of the tar file. So if you have any patches you need to ensure your platform works speak up. We are looking at a lock on the 17th. I believe I have an AIX/Cray patch and a Tru64 patch sitting in my mailbox that I'll be looking at soon and more than likely commiting. I have no clue what else is in my 400+ worth of email.=) I know NeXT platform is broken. Again, I make a call out to people left in the NeXT community. If you want it working before 3.6 submit your patches ASAP. If I hear no word I'll suggest it be phased out after this release. I'd like to see more tinderbox setups (Darren, I'll be talking to you in private, but I have a Sol9 box I'd like to add to the list soon). It would help to know where we stand for broken platforms. For those new to this process asking themselves, "Where do I find these test version?" http://www.openssh.com/portable.html#mirrors Pick your closest FTP site and go to 'snapshot/' Or for CVS people: export CVSROOT=openssh at anoncvs.be.openbsd.org:/cvs export CVS_RSH=/usr/bin/ssh cvs get openssh - Ben From tim at multitalents.net Fri Mar 7 15:03:36 2003 From: tim at multitalents.net (Tim Rice) Date: Thu, 6 Mar 2003 20:03:36 -0800 (PST) Subject: Call for testing for 3.6 In-Reply-To: References: Message-ID: On Thu, 6 Mar 2003, Ben Lindstrom wrote: > I'd like to see more tinderbox setups (Darren, I'll be talking to you in > private, but I have a Sol9 box I'd like to add to the list soon). It > would help to know where we stand for broken platforms. UnixWare and SCO are broken. I guess I'd better whip up a nanosleep() replacement. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri Mar 7 16:12:41 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 6 Mar 2003 23:12:41 -0600 (CST) Subject: Call for testing for 3.6 In-Reply-To: Message-ID: Can the code be rewriten using usleep() which has is more portable and is easier to revert back to sleep() in the worse case (I have no clue about nanosleep... Never used it before nor seen it used). - Ben On Thu, 6 Mar 2003, Tim Rice wrote: > On Thu, 6 Mar 2003, Ben Lindstrom wrote: > > > I'd like to see more tinderbox setups (Darren, I'll be talking to you in > > private, but I have a Sol9 box I'd like to add to the list soon). It > > would help to know where we stand for broken platforms. > > UnixWare and SCO are broken. > I guess I'd better whip up a nanosleep() replacement. > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > From dtucker at zip.com.au Fri Mar 7 17:38:40 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Mar 2003 17:38:40 +1100 Subject: Call for testing for 3.6: AIX package builder update References: Message-ID: <3E683E70.C52772FF@zip.com.au> Hi All. Ben Lindstrom wrote: > So if you have any patches you need to ensure your platform works speak > up. We are looking at a lock on the 17th. The attached patch updates the AIX package builder in contrib/aix. The patch has been on my page (minus the typo fixes) for a while and I've been using it here so it's relatively well tested. The changes relative to 3.5p1 are: * Adds optional SRC support, based on examples provided by Sandor Sklar and Maarten Kreuger. * Creates size lpp control file: installp should now expand filesystems if required. * Writes ssh entry in /etc/rc.tcpip to match system-provided services. * Ensure correct permissions on new /etc/rc.tcpip * Update readme & fix typos Please review and apply if OK. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- ? config.local Index: contrib/aix/README =================================================================== RCS file: /cvs/openssh/contrib/aix/README,v retrieving revision 1.2 diff -u -r1.2 README --- contrib/aix/README 25 Jun 2002 23:38:48 -0000 1.2 +++ contrib/aix/README 7 Mar 2003 06:14:00 -0000 @@ -6,9 +6,15 @@ Directions: +(optional) create config.local in your build dir ./configure [options] -cd contrib/aix; ./buildbff.sh +contrib/aix/buildbff.sh +The file config.local or the environment is read to set the following options +(default first): +PERMIT_ROOT_LOGIN=[no|yes] +X11_FORWARDING=[no|yes] +AIX_SRC=[no|yes] Acknowledgements: @@ -19,6 +25,8 @@ and for comparison with the output from this script, however no code from lppbuild is included and it is not required for operation. +SRC support based on examples provided by Sandor Sklar and Maarten Kreuger. + Other notes: @@ -26,8 +34,7 @@ appropriate). It seems to work, though...... If there are any patches to this that have not yet been integrated they -may be found at http://www.zip.com.au/~dtucker/openssh/ or -http://home.usf.advantra.com.au/~dtucker/openssh/. +may be found at http://www.zip.com.au/~dtucker/openssh/. Disclaimer: Index: contrib/aix/buildbff.sh =================================================================== RCS file: /cvs/openssh/contrib/aix/buildbff.sh,v retrieving revision 1.4 diff -u -r1.4 buildbff.sh --- contrib/aix/buildbff.sh 18 Jul 2002 01:04:51 -0000 1.4 +++ contrib/aix/buildbff.sh 7 Mar 2003 06:14:00 -0000 @@ -11,10 +11,12 @@ # # Tunable configuration settings -# create a "config.local" in your build directory to override these. +# create a "config.local" in your build directory or set +# environment variables to override these. # -PERMIT_ROOT_LOGIN=no -X11_FORWARDING=no +[ -z "$PERMIT_ROOT_LOGIN" ] || PERMIT_ROOT_LOGIN=no +[ -z "$X11_FORWARDING" ] || X11_FORWARDING=no +[ -z "$AIX_SRC" ] || AIX_SRC=no umask 022 @@ -167,6 +169,18 @@ EOD # +# openssh.size file allows filesystem expansion as required +# generate list of directories containing files +# then calculate disk usage for each directory and store in openssh.size +# +files=`find . -type f -print` +dirs=`for file in $files; do dirname $file; done | sort -u` +for dir in $dirs +do + du $dir +done > ../openssh.size + +# # Create postinstall script # cat <>../openssh.post_i @@ -245,14 +259,42 @@ fi echo -# Add to system startup if required -if grep $sbindir/sshd /etc/rc.tcpip >/dev/null +# Set startup command depending on SRC support +if [ "$AIX_SRC" = "yes" ] then - echo "sshd found in rc.tcpip, not adding." + echo Creating SRC sshd subsystem. + rmssys -s sshd 2>&1 >/dev/null + mkssys -s sshd -p "$sbindir/sshd" -a '-D' -u 0 -S -n 15 -f 9 -R -G tcpip + startupcmd="start $sbindir/sshd \\\"\\\$src_running\\\"" + oldstartcmd="$sbindir/sshd" else - echo >>/etc/rc.tcpip - echo "echo Starting sshd" >>/etc/rc.tcpip - echo "$sbindir/sshd" >>/etc/rc.tcpip + startupcmd="$sbindir/sshd" + oldstartcmd="start $sbindir/sshd \\\"$src_running\\\"" +fi + +# If migrating to or from SRC, change previous startup command +# otherwise add to rc.tcpip +if egrep "^\$oldstartcmd" /etc/rc.tcpip >/dev/null +then + if sed "s|^\$oldstartcmd|\$startupcmd|g" /etc/rc.tcpip >/etc/rc.tcpip.new + then + chmod 0755 /etc/rc.tcpip.new + mv /etc/rc.tcpip /etc/rc.tcpip.old && \ + mv /etc/rc.tcpip.new /etc/rc.tcpip + else + echo "Updating /etc/rc.tcpip failed, please check." + fi +else + # Add to system startup if required + if grep "^\$startupcmd" /etc/rc.tcpip >/dev/null + then + echo "sshd found in rc.tcpip, not adding." + else + echo "Adding sshd to rc.tcpip" + echo >>/etc/rc.tcpip + echo "# Start sshd" >>/etc/rc.tcpip + echo "\$startupcmd" >>/etc/rc.tcpip + fi fi EOF @@ -262,7 +304,7 @@ echo Creating liblpp.a ( cd .. - for i in openssh.al openssh.copyright openssh.inventory openssh.post_i LICENCE README* + for i in openssh.al openssh.copyright openssh.inventory openssh.post_i openssh.size LICENCE README* do ar -r liblpp.a $i rm $i Index: contrib/aix/inventory.sh =================================================================== RCS file: /cvs/openssh/contrib/aix/inventory.sh,v retrieving revision 1.2 diff -u -r1.2 inventory.sh --- contrib/aix/inventory.sh 17 Mar 2002 22:05:25 -0000 1.2 +++ contrib/aix/inventory.sh 7 Mar 2003 06:14:00 -0000 @@ -2,9 +2,9 @@ # # inventory.sh # -# Originall written by Ben Lindstrom, modified by Darren Tucker to use perl +# Originally written by Ben Lindstrom, modified by Darren Tucker to use perl # -# This will produced and AIX package inventory file, which looks like: +# This will produce an AIX package inventory file, which looks like: # # /usr/local/bin: # class=apply,inventory,openssh From dtucker at zip.com.au Fri Mar 7 17:55:47 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Mar 2003 17:55:47 +1100 Subject: Call for testing for 3.6: password expiry? References: Message-ID: <3E684273.2EAB51B4@zip.com.au> Hi again. Ben Lindstrom wrote: > So if you have any patches you need to ensure your platform works speak > up. We are looking at a lock on the 17th. There's a couple of patches in Bugzilla that relate to my pet project: Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view There is some overlap between the two patches and they're out of sync with each other. Can I please get someone to review these and let me know if they're suitable for inclusion in 3.6p1? The expiry patches have been pretty heavily tested (nearly 800 downloads of the patch). I've had about a dozen reports of problems, all of which have been resolved (mostly configuring with pam when it wasn't supported, a couple of genuine problems and a couple of cases of pilot error). If they are likely to go in, please let me know what you'd like done with them (eg, merge them into a single patch or make 2 "stacked" patches to be applied sequentially, and particularly what if anything should be done with the interaction with do_pam_chauthtok). -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Mar 7 18:39:05 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Mar 2003 18:39:05 +1100 Subject: Comments on Bugzilla Message-ID: <3E684C99.4B101943@zip.com.au> Hi All. I've been thinking about Bugzilla and there's a couple of things that occur to me. 1) Bug status information. Bugzilla seems to have been designed on the assumption that a bug would immediately be assigned to a module owner who would categorize, manage then hopefully fix and close them. OpenSSH doesn't seem to work like that. Bugs appear to be community property (witness how many bugs remain assigned to "openssh-unix-dev" and are updated by multiple people), however there are many fewer people who can actually fix the bugs than people updating and/or managing the bugs. It might be useful if there was an easy way for the core developers to recognise that there is a fix attached to the bug to be reviewed and applied or rejected (example: there has been an analysis and proposed fix attached to bug #245 for nearly three months but it's still listed as "NEW" and "critical"). It might be useful if there was a "Proposed Fix" status (or use of "Assigned" or something for that) for the bugs to make them recognisable. (I am hesitant to assign a bug to openssh-unix-dev since I don't own that address or assign it to myself because it implies I have the authority to fix it). 2) Notification email subjects. Currently Bugzilla sends email notifications with subjects like: [Bug bugno] New: Subject of bug (for a new bug) [Bug bugno] Subject of bug (for changes to bug) Additionally, if anyone replies to a notification, it normally appears with "Re: " prepended. If you're trying to follow old discussions in the list archive it's very difficult since the bugzilla notifications are not threaded. Would it be possible to have bugzilla generate subjects like: [Bug bugno] Subject of bug (for a new bug) Re: [Bug bugno]: Subject of bug (for changes to a bug) The list archives and threading mailreaders might be able to do a better job of stringing them together. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jeb at jeremywilkins.freeserve.co.uk Sat Mar 8 01:12:54 2003 From: jeb at jeremywilkins.freeserve.co.uk (Jeremy Wilkins) Date: Fri, 07 Mar 2003 14:12:54 +0000 Subject: gui wrapper for ssh -X Message-ID: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> Hi, I've been attempting to write a gui wrapper to launch ssh -X user at machine application I'm trying to launch ssh and connect to it with pipes so that my front end can enter the password if required (either from a cache or by popping up a dialogue box). I've been having problems with pipes though reading from ssh's stdout, for when it asks for the password. Before I go further down this path, does ssh uses pipes in the standard way, or is this method impossible. Does anyone have a suggestion of another way to go about this, currently I'm trying to use the g_spawn_async_with_pipes call from glib2.0 thanks jeb From dwmw2 at infradead.org Sat Mar 8 01:39:11 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 07 Mar 2003 14:39:11 +0000 Subject: gui wrapper for ssh -X In-Reply-To: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> Message-ID: <1047047950.32200.68.camel@passion.cambridge.redhat.com> On Fri, 2003-03-07 at 14:12, Jeremy Wilkins wrote: > Hi, > > I've been attempting to write a gui wrapper to launch > > ssh -X user at machine application > > I'm trying to launch ssh and connect to it with pipes so that my front > end can enter the password if required (either from a cache or by > popping up a dialogue box). Why not just use $SSH_ASKPASS? Admittedly, there's some brain damage there and you have to explicitly disconnect from your controlling tty to force it to use your askpass program, rather than just passing a '-oaskpass=...' option, but it's not so hard. -- dwmw2 From bugzilla-daemon at mindrot.org Sat Mar 8 01:48:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 01:48:53 +1100 (EST) Subject: [Bug 503] New: Password is echoed when running passwd via ssh Message-ID: <20030307144853.2E84E9428C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=503 Summary: Password is echoed when running passwd via ssh Product: Portable OpenSSH Version: 3.4p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kj at uue.org client and server systems are RedHat 7.2 with openssh-3.1p1-6. When running "ssh passwd ", the password is visible on the console: [root at host1 root]# ssh host2 passwd user1 New password: Retype new password: Changing password for user user1 passwd: all authentication tokens updated successfully I also ran tests with v3.4p1 on RedHat 8.0 as well as with and without public key authentication, where this problem also occured. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From openssh at roumenpetrov.info Sat Mar 8 01:46:54 2003 From: openssh at roumenpetrov.info (openssh at roumenpetrov.info) Date: Fri, 07 Mar 2003 16:46:54 +0200 Subject: gui wrapper for ssh -X References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> Message-ID: <3E68B0DE.8050806@roumenpetrov.info> Look in contrib subdir: - in README: check for "X11 SSH Askpass" or use - gnome-ssh-askpass{1|2}.c Jeremy Wilkins wrote: > Hi, > > I've been attempting to write a gui wrapper to launch > > ssh -X user at machine application > > I'm trying to launch ssh and connect to it with pipes so that my front > end can enter the password if required (either from a cache or by > popping up a dialogue box). > > From bugzilla-daemon at mindrot.org Sat Mar 8 02:04:56 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 02:04:56 +1100 (EST) Subject: [Bug 503] Password is echoed when running passwd via ssh Message-ID: <20030307150456.63F0994294@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=503 kj at uue.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From kj at uue.org 2003-03-08 02:04 ------- just use ssh -t... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From boliset at iitk.ac.in Sat Mar 8 03:34:46 2003 From: boliset at iitk.ac.in (kapileswar rao bolisetti) Date: Fri, 7 Mar 2003 22:04:46 +0530 (IST) Subject: [Bug 503] Password is echoed when running passwd via ssh In-Reply-To: <20030307150456.63F0994294@shitei.mindrot.org> Message-ID: OM SHANTI SHANTI SHANTIHI.... 6 more days to go ....... waiting eagerly.... --kapil On Sat, 8 Mar 2003 bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=503 > > kj at uue.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |FIXED > > > > ------- Additional Comments From kj at uue.org 2003-03-08 02:04 ------- > just use ssh -t... > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- with luv kapil ------------------------------------------------------------------------------- B.KAPILESWAR RAO (M.Tech>, DEPT. OF C.S.E, E-210/HALL IV, IIT KANPUR, KANPUR, INDIA. ------------------------------------------------------------------------------- From boliset at iitk.ac.in Sat Mar 8 03:37:56 2003 From: boliset at iitk.ac.in (kapileswar rao bolisetti) Date: Fri, 7 Mar 2003 22:07:56 +0530 (IST) Subject: [Bug 503] Password is echoed when running passwd via ssh In-Reply-To: Message-ID: Sorry not intended to this list .. happened by mistake... --kapil On Fri, 7 Mar 2003, kapileswar rao bolisetti wrote: > OM SHANTI SHANTI SHANTIHI.... > > 6 more days to go ....... > > waiting eagerly.... > > --kapil > > On Sat, 8 Mar 2003 bugzilla-daemon at mindrot.org wrote: > > > http://bugzilla.mindrot.org/show_bug.cgi?id=503 > > > > kj at uue.org changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|NEW |RESOLVED > > Resolution| |FIXED > > > > > > > > ------- Additional Comments From kj at uue.org 2003-03-08 02:04 ------- > > just use ssh -t... > > > > > > > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- with luv kapil ------------------------------------------------------------------------------- B.KAPILESWAR RAO (M.Tech>, DEPT. OF C.S.E, E-210/HALL IV, IIT KANPUR, KANPUR, INDIA. ------------------------------------------------------------------------------- From jmknoble at pobox.com Sat Mar 8 03:52:04 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 7 Mar 2003 11:52:04 -0500 Subject: Call for testing for 3.6 In-Reply-To: References: Message-ID: <20030307165204.GA22090@crawfish.ais.com> Circa 2003-03-06 23:12:41 -0600 dixit Ben Lindstrom: [Tim Rice: nanosleep() replacement] : Can the code be rewriten using usleep() which has is more portable and is : easier to revert back to sleep() in the worse case (I have no clue about : nanosleep... Never used it before nor seen it used). I had already suggested using usleep(), but Darren Tucker made the (much better) suggestion to use select(): http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104624288131929&w=2 -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030307/47430ea4/attachment.bin From jmknoble at pobox.com Sat Mar 8 04:12:38 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 7 Mar 2003 12:12:38 -0500 Subject: gui wrapper for ssh -X In-Reply-To: <1047047950.32200.68.camel@passion.cambridge.redhat.com> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> Message-ID: <20030307171238.GB22090@crawfish.ais.com> Circa 2003-03-07 14:39:11 +0000 dixit David Woodhouse: : On Fri, 2003-03-07 at 14:12, Jeremy Wilkins wrote: : > I'm trying to launch ssh and connect to it with pipes so that my front : > end can enter the password if required (either from a cache or by : > popping up a dialogue box). Pipes won't work; ssh reads the password or passphrase directly from /dev/tty (the current terminal), unless stdin is not a terminal. : Why not just use $SSH_ASKPASS? : : Admittedly, there's some brain damage there and you have to explicitly : disconnect from your controlling tty to force it to use your askpass : program, rather than just passing a '-oaskpass=...' option, but it's not : so hard. It's *really* not hard: env SSH_ASKPASS=/usr/local/libexec/x11-ssh-askpass \ ssh -X user at machine 'command' /dev/null 2>&1 x11-ssh-askpass is here, in case you don't already have it: http://www.pobox.com/~jmknoble/software/x11-ssh-askpass/ -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030307/5e37bf72/attachment.bin From dwmw2 at infradead.org Sat Mar 8 05:44:17 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 07 Mar 2003 18:44:17 +0000 Subject: gui wrapper for ssh -X In-Reply-To: <20030307171238.GB22090@crawfish.ais.com> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> Message-ID: <1047062656.20822.21.camel@imladris.demon.co.uk> On Fri, 2003-03-07 at 17:12, Jim Knoble wrote: > Circa 2003-03-07 14:39:11 +0000 dixit David Woodhouse: > It's *really* not hard: > > env SSH_ASKPASS=/usr/local/libexec/x11-ssh-askpass \ > ssh -X user at machine 'command' /dev/null 2>&1 Did you try this? On Linux, even with everything redirected to /dev/null, I need to detach from the controlling TTY in order to prevent it from _opening_ /dev/tty and trying to use that. >From my patches to make Evolution handle getting to its IMAP server over ssh instead of making a direct connection... +#ifdef TIOCNOTTY + /* Detach from the controlling tty if we have one. Otherwise, + SSH might do something stupid like trying to use it instead + of running $SSH_ASKPASS. Doh. */ + fd = open("/dev/tty", O_RDONLY); + if (fd != -1) { + ioctl(fd, TIOCNOTTY, NULL); + close(fd); + } +#endif /* TIOCNOTTY */ You also need to export a fake 'DISPLAY' environment variable, even if you're not actually running under X and don't want your askpass program to use X. Both of these bit me when implementing 'opie-ssh-askpass' for the Qt/Embedded PDA stuff. I looked at adding an 'AskPassCommand' configuration option to the ssh client, but readpass.c is used in other programs too, and I couldn't really see a clean way to do it. Note that if you want caching, you'll probably want your askpass program not to bring up a dialog box of its own but to connect somehow to the master program which invoked ssh in the first place, and query that for the password. Do consider using ssh-agent instead though. -- dwmw2 From jmknoble at pobox.com Sat Mar 8 06:36:28 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 7 Mar 2003 14:36:28 -0500 Subject: gui wrapper for ssh -X In-Reply-To: <1047062656.20822.21.camel@imladris.demon.co.uk> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> Message-ID: <20030307193628.GH22090@crawfish.ais.com> Circa 2003-03-07 18:44:17 +0000 dixit David Woodhouse: : On Fri, 2003-03-07 at 17:12, Jim Knoble wrote: : > Circa 2003-03-07 14:39:11 +0000 dixit David Woodhouse: : > It's *really* not hard: : > : > env SSH_ASKPASS=/usr/local/libexec/x11-ssh-askpass \ : > ssh -X user at machine 'command' /dev/null 2>&1 : : Did you try this? On Linux, even with everything redirected to : /dev/null, I need to detach from the controlling TTY in order to prevent : it from _opening_ /dev/tty and trying to use that. Whoops, misread the code in readpass.c. Redirecting stdin only works for ssh-add and ssh-keygen, which set the RP_ALLOW_STDIN flag. You're correct : >From my patches to make Evolution handle getting to its IMAP server over : ssh instead of making a direct connection... : : +#ifdef TIOCNOTTY : + /* Detach from the controlling tty if we have one. Otherwise, : + SSH might do something stupid like trying to use it instead : + of running $SSH_ASKPASS. Doh. */ : + fd = open("/dev/tty", O_RDONLY); : + if (fd != -1) { : + ioctl(fd, TIOCNOTTY, NULL); : + close(fd); : + } : +#endif /* TIOCNOTTY */ You may also be able to use setsid(2) to accomplish the same thing. There also appears to be a setsid(1) command in the util-linux package: $ cat /etc/redhat-release Red Hat Linux release 6.2 (Zoot) $ which setsid /usr/bin/setsid $ rpm -qf `which setsid` util-linux-2.10f-7.6.2 $ ssh otherlinuxsystem $ cat /etc/redhat-release Red Hat Linux release 8.0.93 (Phoebe) $ rpm -qf `which setsid` util-linux-2.11y-2 $ This might be useful in a shell script. On the Red Hat Linux 6.2 machine: (env SSH_ASKPASS=/usr/libexec/openssh/x11-ssh-askpass \ setsid ssh -X localhost xedit &) works. Don't have setsid(1) available under OpenBSD to test. The setsid(2) man page under Red Hat Linux says the following: ERRORS On error, -1 will be returned. The only error which can happen is EPERM. It is returned when the process group ID of any process equals the PID of the calling process. Thus, in particular, setsid fails if the calling process is already a process group leader. NOTES A process group leader is a process with process group ID equal to its PID. In order to be sure that setsid will succeed, fork and exit, and have the child do setsid(). : You also need to export a fake 'DISPLAY' environment variable, even : if you're not actually running under X and don't want your askpass : program to use X. (If you're doing X11 forwarding with 'ssh -X', you ought to be running under X and to already have a DISPLAY). -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030307/2218f63c/attachment.bin From htodd at twofifty.com Sat Mar 8 08:40:51 2003 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 7 Mar 2003 13:40:51 -0800 (PST) Subject: Testing the openssh beta: Sol2.6 errors In-Reply-To: <20030307193628.GH22090@crawfish.ais.com> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> Message-ID: Here are the errors I get running the regressions on a Solaris 2.6 box. Let me know what else I can do. ok try ciphers run test yes-head.sh ... yes: Command not found. yes|head returns 0 lines instead of 2000 yes: Command not found. yes|head returns 0 lines instead of 2000 failed yes pipe head *** Error code 1 make: Fatal error: Command failed for target `t-exec' Current working directory /usr/local/src/openssh/regress *** Error code 1 make: Fatal error: Command failed for target `tests' -- Hisashi T Fujinaka - htodd at twofifty.com BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte From dtucker at zip.com.au Sat Mar 8 09:51:35 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Mar 2003 09:51:35 +1100 Subject: Testing the openssh beta: Sol2.6 errors References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> Message-ID: <3E692277.160C8D48@zip.com.au> Hisashi T Fujinaka wrote: > Here are the errors I get running the regressions on a Solaris 2.6 box. [snip] > yes: Command not found. > yes|head returns 0 lines instead of 2000 You need a copy of the "yes" program on your test host. You can get one from the GNU sh-utils package. -- 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 htodd at twofifty.com Sat Mar 8 11:09:15 2003 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 7 Mar 2003 16:09:15 -0800 (PST) Subject: Testing the openssh beta: Sol2.6 errors In-Reply-To: <3E692277.160C8D48@zip.com.au> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> <3E692277.160C8D48@zip.com.au> Message-ID: Ah. Well, I do have yes, but perhaps the path is wrong? On Sat, 8 Mar 2003, Darren Tucker wrote: > Hisashi T Fujinaka wrote: > > Here are the errors I get running the regressions on a Solaris 2.6 box. > [snip] > > yes: Command not found. > > yes|head returns 0 lines instead of 2000 > > You need a copy of the "yes" program on your test host. You can get one > from the GNU sh-utils package. > > -- Hisashi T Fujinaka - htodd at twofifty.com BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte From dtucker at zip.com.au Sat Mar 8 11:52:13 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Mar 2003 11:52:13 +1100 Subject: Testing the openssh beta: Sol2.6 errors References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> <3E692277.160C8D48@zip.com.au> Message-ID: <3E693EBD.3E308786@zip.com.au> Hisashi T Fujinaka wrote: > Ah. Well, I do have yes, but perhaps the path is wrong? "yes" needs to be in the system path as the test is basically: ssh thishost 'yes | head -2000' | (sleep 3 ; wc -l) It doesn't matter what your current path is as sshd will it as per a normal login (eg from /etc/profile). -- 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 htodd at twofifty.com Sat Mar 8 11:53:25 2003 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 7 Mar 2003 16:53:25 -0800 (PST) Subject: Testing the openssh beta: Sol2.6 errors In-Reply-To: <3E693EBD.3E308786@zip.com.au> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> <3E692277.160C8D48@zip.com.au> <3E693EBD.3E308786@zip.com.au> Message-ID: On Sat, 8 Mar 2003, Darren Tucker wrote: > Hisashi T Fujinaka wrote: > > Ah. Well, I do have yes, but perhaps the path is wrong? > > "yes" needs to be in the system path as the test is basically: > ssh thishost 'yes | head -2000' | (sleep 3 ; wc -l) > > It doesn't matter what your current path is as sshd will it as per a > normal login (eg from /etc/profile). I spoke too soon. I was looking at another machine when I tried yes. :P I'll let you know as soon as I compile/install/run the tests again. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte From htodd at twofifty.com Sat Mar 8 13:36:33 2003 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 7 Mar 2003 18:36:33 -0800 (PST) Subject: Testing the openssh beta: Sol2.6 errors In-Reply-To: <3E693EBD.3E308786@zip.com.au> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> <3E692277.160C8D48@zip.com.au> <3E693EBD.3E308786@zip.com.au> Message-ID: On Sat, 8 Mar 2003, Darren Tucker wrote: > Hisashi T Fujinaka wrote: > > Ah. Well, I do have yes, but perhaps the path is wrong? > > "yes" needs to be in the system path as the test is basically: > ssh thishost 'yes | head -2000' | (sleep 3 ; wc -l) > > It doesn't matter what your current path is as sshd will it as per a > normal login (eg from /etc/profile). Just FYI, the regression suite passes on Sol2.6. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE (6/86) + BSChem (3/95) + BAEnglish (8/95) + $2.50 = mocha latte From bugzilla-daemon at mindrot.org Sat Mar 8 15:16:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:16:26 +1100 (EST) Subject: [Bug 505] New: ssh -V could print a human readable openssl version string Message-ID: <20030308041626.03BD99421F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 Summary: ssh -V could print a human readable openssl version string Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mindrot at ee.lbl.gov It would be nice if "ssh -V" reported a human readable openssl version string (like "openssl version" does) instead of a hex number. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:19:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:19:51 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308041951.8D6B094220@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 ------- Additional Comments From mindrot at ee.lbl.gov 2003-03-08 15:19 ------- Created an attachment (id=241) --> (http://bugzilla.mindrot.org/attachment.cgi?id=241&action=view) patch to ssh.c This patch makes ssh use SSLeay_version(SSLEAY_VERSION) to generate a human readable version string. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:21:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:21:44 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308042144.65848942C6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 ------- Additional Comments From mindrot at ee.lbl.gov 2003-03-08 15:21 ------- Created an attachment (id=242) --> (http://bugzilla.mindrot.org/attachment.cgi?id=242&action=view) proposed output ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:23:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:23:46 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308042346.8B800942CB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 ------- Additional Comments From mindrot at ee.lbl.gov 2003-03-08 15:23 ------- (From update of attachment 242) /tmp/ssh.txt ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:28:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:28:15 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308042815.C0BF5942C8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 mindrot at ee.lbl.gov changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #241 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:28:37 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:28:37 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308042837.63676942D1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 mindrot at ee.lbl.gov changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #242 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:30:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:30:22 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308043022.C1445942D9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 ------- Additional Comments From mindrot at ee.lbl.gov 2003-03-08 15:30 ------- Created an attachment (id=243) --> (http://bugzilla.mindrot.org/attachment.cgi?id=243&action=view) patch to ssh.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 15:31:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 15:31:01 +1100 (EST) Subject: [Bug 505] ssh -V could print a human readable openssl version string Message-ID: <20030308043101.2A1E5942D9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=505 ------- Additional Comments From mindrot at ee.lbl.gov 2003-03-08 15:31 ------- Created an attachment (id=244) --> (http://bugzilla.mindrot.org/attachment.cgi?id=244&action=view) proposed output ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 8 17:11:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 8 Mar 2003 17:11:46 +1100 (EST) Subject: [Bug 506] New: have ssh-agent and ssh-add also support gnupg Message-ID: <20030308061146.6255B942C1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=506 Summary: have ssh-agent and ssh-add also support gnupg Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org using gpg quite a bit, it would be great to also have its private key passwords managed with ssh-agent! Reason: I am maintaining an contact list as an ascii file with one person per line. I am encrypting it with gpg to protect it for the case my laptop gets stolen. I often grep it to find a person "gpg --decrypt addr.gpg | grep $1" and it is annoying to have to type the password all the time ==> there ssh-agent -t would be useful! Or is there a possibility to use openSSH to also perform the local file encryption and let gnupg aside for this purpose altogether? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dwmw2 at infradead.org Sat Mar 8 20:33:35 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 08 Mar 2003 09:33:35 +0000 Subject: gui wrapper for ssh -X In-Reply-To: <20030307193628.GH22090@crawfish.ais.com> References: <3E68A8E6.90006@jeremywilkins.freeserve.co.uk> <1047047950.32200.68.camel@passion.cambridge.redhat.com> <20030307171238.GB22090@crawfish.ais.com> <1047062656.20822.21.camel@imladris.demon.co.uk> <20030307193628.GH22090@crawfish.ais.com> Message-ID: <1047116015.2032.7.camel@imladris.demon.co.uk> On Fri, 2003-03-07 at 19:36, Jim Knoble wrote: > : + ioctl(fd, TIOCNOTTY, NULL); > You may also be able to use setsid(2) to accomplish the same thing. Hmmm. That'd be more portable; I'll do that next time I rebuild Evo. Thanks for pointing it out. > : You also need to export a fake 'DISPLAY' environment variable, even > : if you're not actually running under X and don't want your askpass > : program to use X. > > (If you're doing X11 forwarding with 'ssh -X', you ought to be running > under X and to already have a DISPLAY). True; that's more of a problem if you want to use askpass in a non-X environment or just to open a back-channel to the master program for interaction with the user. -- dwmw2 From rasjidw at mindrot.org Sat Mar 8 23:58:04 2003 From: rasjidw at mindrot.org (rasjidw at mindrot.org) Date: Sat, 8 Mar 2003 23:58:04 +1100 Subject: gui wrapper for ssh -X Message-ID: <200303082358.04145.rasjidw@pc-00100> ---------- Original Message ---------- Message: 7 Date: Fri, 07 Mar 2003 14:12:54 +0000 From: Jeremy Wilkins To: openssh-unix-dev at mindrot.org Subject: gui wrapper for ssh -X Hi, I've been attempting to write a gui wrapper to launch ssh -X user at machine application I'm trying to launch ssh and connect to it with pipes so that my front end can enter the password if required (either from a cache or by popping up a dialogue box). I've been having problems with pipes though reading from ssh's stdout, for when it asks for the password. Before I go further down this path, does ssh uses pipes in the standard way, or is this method impossible. Does anyone have a suggestion of another way to go about this, currently I'm trying to use the g_spawn_async_with_pipes call from glib2.0 thanks jeb -------------------------------------------------- If you are happy to use Python, you could take a look at Pyssh (http://pyssh.sourceforge.net). You can then create a gui with any gui toolkit supported by Python. Cheers, Rasjid. From bugzilla-daemon at mindrot.org Mon Mar 10 11:24:47 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 11:24:47 +1100 (EST) Subject: [Bug 506] have ssh-agent and ssh-add also support gnupg Message-ID: <20030310002447.C9E9D9422B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=506 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2003-03-10 11:24 ------- Won't happen: 1. GNUPG is GPL licensed, OpenSSH is BSD licensed 2. The GNUPG community is working on a "gpg-agent" IIRC ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 11:25:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 11:25:32 +1100 (EST) Subject: [Bug 499] progressmeter.c doesn't build (at least) on Cygwin Message-ID: <20030310002532.AC6B29422F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=499 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-03-10 11:25 ------- Applied a week or two ago. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 11:38:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 11:38:25 +1100 (EST) Subject: [Bug 245] SSH can not log out under Solaris 2.6 Message-ID: <20030310003825.0015394234@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=245 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-03-10 11:38 ------- Applied - thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 11:57:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 11:57:10 +1100 (EST) Subject: [Bug 117] OpenSSH second-guesses PAM Message-ID: <20030310005710.67A2594238@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=117 ------- Additional Comments From djm at mindrot.org 2003-03-10 11:57 ------- Created an attachment (id=245) --> (http://bugzilla.mindrot.org/attachment.cgi?id=245&action=view) Use supplied username in pam_start calls always Make sshd always use supplied username (even if it is invalid) in calls to PAM ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Mon Mar 10 12:04:03 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Mar 2003 12:04:03 +1100 Subject: Comments on Bugzilla In-Reply-To: <3E684C99.4B101943@zip.com.au> References: <3E684C99.4B101943@zip.com.au> Message-ID: <3E6BE483.80506@mindrot.org> Darren Tucker wrote: > It might be useful if there was an easy way for the core developers to > recognise that there is a fix attached to the bug to be reviewed and > applied or rejected (example: there has been an analysis and proposed > fix attached to bug #245 for nearly three months but it's still listed > as "NEW" and "critical"). The CVS version of bugzilla has support for patch review which looks quite nice. When this reaches beta, I'll probably upgrade bugzilla.mindrot.org. > It might be useful if there was a "Proposed Fix" status (or use of > "Assigned" or something for that) for the bugs to make them > recognisable. (I am hesitant to assign a bug to openssh-unix-dev > since I don't own that address or assign it to myself because it > implies I have the authority to fix it). You are looking for the "patch" keyword. That is the intended way to mark bugs with supplied fixes. It is underused, but that doesn't mean it should continue to be. > 2) Notification email subjects. > Currently Bugzilla sends email notifications with subjects like: > [Bug bugno] New: Subject of bug (for a new bug) > [Bug bugno] Subject of bug (for changes to bug) > > Additionally, if anyone replies to a notification, it normally appears > with "Re: " prepended. > > If you're trying to follow old discussions in the list archive it's > very difficult since the bugzilla notifications are not threaded. > > Would it be possible to have bugzilla generate subjects like: > [Bug bugno] Subject of bug (for a new bug) > Re: [Bug bugno]: Subject of bug (for changes to a bug) > > The list archives and threading mailreaders might be able to do a > better job of stringing them together. Good idea - I have changed Bugzilla so it should do this in future. If anyone was relying on the status keyword, you can get at it in the X-Bugzilla-Status header now. -d From bugzilla-daemon at mindrot.org Mon Mar 10 12:06:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 12:06:16 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030310010616.21F7194246@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From djm at mindrot.org 2003-03-10 12:06 ------- The patch looks good, but the only thing that makes me wary is the use of signals for IPC. Would it not be possible to do the chauthtok call earlier? E.g. after the call to do_pam_session() in do_exec_pty()? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 12:17:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 12:17:42 +1100 (EST) Subject: [Bug 117] OpenSSH second-guesses PAM Message-ID: <20030310011742.E818594250@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=117 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- Additional Comments From djm at mindrot.org 2003-03-10 12:17 ------- I'm still not sure whether supplying a bad username to PAM is a good idea, but at least there is a patch that people can try timing attacks against. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 14:35:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 14:35:46 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030310033546.97F4D94230@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-03-10 14:35 ------- Are stdin/out/err even connected to the client at that point? I didn't think they were. If so then yes, that should eliminate the signal stuff and the monitor call from the shell child (which is potentially racy and *bad* according to Markus and Niels, see http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104384154418133). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 15:43:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 15:43:04 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030310044304.5CC7494209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From djm at mindrot.org 2003-03-10 15:43 ------- Created an attachment (id=246) --> (http://bugzilla.mindrot.org/attachment.cgi?id=246&action=view) INCOMPLETE example patch Actually, what I suggested won't work. The chauthtok needs to happen after the tty magic in do_exec_pty. I suppose we could do something horrid like the incomplete attached patch. I.e run a separate subshell for the chauthtok before forking the real child. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 15:49:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 15:49:33 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030310044933.B99B894230@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From djm at mindrot.org 2003-03-10 15:49 ------- Created an attachment (id=247) --> (http://bugzilla.mindrot.org/attachment.cgi?id=247&action=view) Call pam_session after child fork() Hopefully this patch will allow people to gather the feedback necessary to close this bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 15:51:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 15:51:31 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030310045131.E98F794255@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- Additional Comments From djm at mindrot.org 2003-03-10 15:51 ------- If you want to see this bug closed, please try the attached patch and see if things work correctly. We'll need feedback from (at least) Solaris, Linux, HP/UX users. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 10 17:19:09 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 17:19:09 +1100 (EST) Subject: [Bug 506] have ssh-agent and ssh-add also support gnupg Message-ID: <20030310061909.17F0294207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=506 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED ------- Additional Comments From hauser at acm.org 2003-03-10 17:19 ------- It appears that Robbe's q-agent (http://www.vibe.at/tools/secret-agent/) has already an "assh" program that does this (still buggy thus not yet released...) P.S.: If it is so sad that licensing issues prevent easy-to-use-security, why do you label this as "Worksforme" instead of "invalid". Or (not being a licensing expert) is Gnu just taking over BSD in this matter? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Mon Mar 10 17:25:15 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Mar 2003 17:25:15 +1100 Subject: Comments on Bugzilla References: <3E684C99.4B101943@zip.com.au> <3E6BE483.80506@mindrot.org> Message-ID: <3E6C2FCB.9312D183@zip.com.au> Damien Miller wrote: > Darren Tucker wrote: > You are looking for the "patch" keyword. That is the intended way to > mark bugs with supplied fixes. It is underused, but that doesn't mean it > should continue to be. Ah, OK, will do so in future. > > Would it be possible to have bugzilla generate subjects like: > > [Bug bugno] Subject of bug (for a new bug) > > Re: [Bug bugno]: Subject of bug (for changes to a bug) > > Good idea - I have changed Bugzilla so it should do this in future. If > anyone was relying on the status keyword, you can get at it in the > X-Bugzilla-Status header now. It doesn't seem to be doing so yet. -- 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 bugzilla-daemon at mindrot.org Mon Mar 10 17:35:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 17:35:00 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030310063500.098689424A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-03-10 17:34 ------- Hmm, that should work. With a bit of care the same function could run /bin/passwd for non-pam password changes too (although there is less need for that since passwd is setuid, it would reduce duplicated code). I'll make some changes to my patch to do it that way and see how well it works. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Mon Mar 10 18:57:49 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Mar 2003 18:57:49 +1100 Subject: Comments on Bugzilla In-Reply-To: <3E6C2FCB.9312D183@zip.com.au> References: <3E684C99.4B101943@zip.com.au> <3E6BE483.80506@mindrot.org> <3E6C2FCB.9312D183@zip.com.au> Message-ID: <3E6C457D.7010309@mindrot.org> Darren Tucker wrote: >>> Would it be possible to have bugzilla generate subjects like: >>>[Bug bugno] Subject of bug (for a new bug) >>>Re: [Bug bugno]: Subject of bug (for changes to a bug) >> >>Good idea - I have changed Bugzilla so it should do this in future. If >>anyone was relying on the status keyword, you can get at it in the >>X-Bugzilla-Status header now. > > It doesn't seem to be doing so yet. I see, it doesn't do the 'Re:' thing properly. My mailreader (Mozilla) still threads them correctly. -d From jeb at jeremywilkins.freeserve.co.uk Mon Mar 10 22:27:23 2003 From: jeb at jeremywilkins.freeserve.co.uk (Jeremy Wilkins) Date: Mon, 10 Mar 2003 11:27:23 +0000 Subject: gui wrapper for ssh -X Message-ID: <3E6C769B.4030707@jeremywilkins.freeserve.co.uk> Thanks for the answers, I'd not heard of SSH_ASKPASS - I'll look into that, and ssh-agent sounds like it could be useful. cheers jeb From bugzilla-daemon at mindrot.org Mon Mar 10 22:34:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 10 Mar 2003 22:34:19 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030310113419.C6D4F94262@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-03-10 22:34 ------- That approach isn't as easy as it seemed at first... as soon as you wait() for the child the ssh protocol processing stops. If you let it run, you then start the session without the password being changed. I guess you could use a SIGCHLD handler for successful change, but then you need to some way to synchronise the shell child. I can't see any easy way to make this work. How badly do you hate using SIGUSR :-? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 11 03:45:22 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 11 Mar 2003 03:45:22 +1100 (EST) Subject: [Bug 507] Mindrot Bugzilla does not make it clear that this is the Bugzilla for SSH Message-ID: <20030310164522.7AAAE94260@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=507 Summary: Mindrot Bugzilla does not make it clear that this is the Bugzilla for SSH Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: worley at theworld.com The main pages from http://bugzilla.mindrot.org do not state, clearly and at at the top, that this is the Bugzilla for *SSH*. One can tell that once one reaches the "Enter Bug" page, if one looks at the "Product:" item, but looking at http://bugzilla.mindrot.org, it says "Bugzilla" at the top, and "This is Bugzilla: the Mozilla bug system." at the bottom, which can deceive the naive into thinking that this is the place to report Mozilla bugs. (Remember, Bugzilla is famous as the bug reporting system *for Mozilla*.) One solution would be to replace the text at the top of each page, "Bugzilla Version 2.16.2" with something like "Bug reporting for SSH". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From secure_bsd at yahoo.com Tue Mar 11 01:14:19 2003 From: secure_bsd at yahoo.com (Shaji Vinod) Date: Mon, 10 Mar 2003 06:14:19 -0800 (PST) Subject: Significance of displaying known host keys. Message-ID: <20030310141419.69307.qmail@web13307.mail.yahoo.com> Hi all, What is the significance of displaying all known host keys of a particular host when receiving an unkown host key of different type. Thanks Shaji __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From jdennis at law.harvard.edu Tue Mar 11 01:28:05 2003 From: jdennis at law.harvard.edu (James Dennis) Date: Mon, 10 Mar 2003 09:28:05 -0500 Subject: This letter can change your life In-Reply-To: References: Message-ID: <3E6CA0F5.9000400@law.harvard.edu> This sounds good, should it be integrated into OpenSSH? :P A little monday humor for you.. -James Adolph Gorman wrote: > This letter can change your life. In fact, I guarantee it. > > If you had one opportunity to have everything you ever wanted, > would you grab it, or simply walk away? > > I have such an opportunity. One that can change your life forever. > > There is a problem, though, it sounds too good to be true. A great > opportunity can sound exactly like a bad one. How is a person to know > what is real and what is hype, or just a scam? Well, the only way to > know for sure is to try it. That is how I earn my living. > I analyze opportunities, and try the ones that show the most promise. I > can eliminate most of them from the first email (or ad) I read. My years > of experience have taught me how to recognize common marketing tactics > that lead a person to believe something is much better than it actually is. > > CES is a company that is operated on the principal that helping others > to be successful is not only the right thing to do, but the smartest > thing to do, if you really want to be successful. We know we can make > $3,000 to $15,000 a month, in 6 months or less, for you. In fact, we are > so confident in our ability to do this that, if you work with us for six > months and you do not reach your goal, we will double the money that we > recommended you spend on starting and running your own business. We > would have to be very good, or incredibly stupid, to offer this kind of > guarantee if we didn't think we could back it up. We can only benefit if > you are successful. There is no other way for us to benefit. It also > means we have to have a 100% success rate because to even double 1% of > our client's money could be financially devastating. > > Remember, at the beginning of this letter I told you about an > opportunity to change your life forever? > > In order to market successfully, we (CES) have to have a product. It is > that product, combined with our system that creates this amazing > opportunity that anyone can be successful with. You can earn more money > than you ever thought possible. What if you knew, eighteen years ago, > how successful Microsoft would be? Would you have joined them? AOL > started ten years ago - - - would you have become involved knowing what > you know now? > > If you knew for sure you would be making $3,000 to $15,000 per month > within 6 months, would you want to be a part of it? > > Our product has something in common with both AOL and Microsoft. It is a > product that the world undeniably needs. In fact, 98% of the people who > use our product continue to use it month after month. And the reason is > that everyone who owns a computer needs our product. The company that > offers this product has grown faster than any company in history. It's > the first of its kind, and at present, has no competition. By the end of > their first month in business, they already had customers in 73 > countries! So, here is your chance to have everything you ever wanted > --- RISK FREE! Will you grab it, or walk away? > > With our system, we are going to get you 5 members. Then, we are going > to get them > 5 members. It is through this teamwork and our totally automated system > that anyone can use that will make it possible for you to earn $3,000 to > $15,000 a month in only > 6 months. > > Of course, you should also look at the "other side". What's the worst > thing that can happen? You get double your money back. Then, there is > the expense issue. You will have to spend between $42 to $185 to start, > and run, your own business. The guarantee would reimburse you TWICE that > if we don't deliver you the income level promised in six months. So is > it worth it to you to find out if this, indeed, is the opportunity that > will change your life forever? > > If you would like more info on this opportunity, please send us an > email. Your > requested > information will be emailed back to you ASAP. Your email address is used > solely > for the purpose of sending you more information. > Your information will never be sold or traded. > > vgfYwhBxPpjjQZkFhkb -- James Dennis Harvard Law School "Not everything that counts can be counted, and not everything that can be counted counts." From bugzilla-daemon at mindrot.org Tue Mar 11 10:17:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 11 Mar 2003 10:17:11 +1100 (EST) Subject: [Bug 507] Mindrot Bugzilla does not make it clear that this is the Bugzilla for SSH Message-ID: <20030310231711.F022C9421D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=507 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-03-11 10:17 ------- Fixed - some text added to front page. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 11 21:42:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 11 Mar 2003 21:42:24 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030311104224.A51619421C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #246 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 11 22:16:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 11 Mar 2003 22:16:58 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030311111658.4102E94221@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From djm at mindrot.org 2003-03-11 22:16 ------- Well, nothing suggested so far avoids the shell child communicating with the monitor. I agree with Markus and Niels that this is bad. If we accept, for now, the smaller bug of chauthtok-requiring sessions not being able to use port,X11 or agent forwardings, can we make it work with privsep under the above constraint? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 11 23:13:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 11 Mar 2003 23:13:34 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030311121334.63F8394222@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-03-11 23:13 ------- Actually, the first proposal (ssh-chauthtok-helper) by Michael Steffens does not require monitor calls by the shell child. It wasn't very popular, though. The current architecture requires a change after the tty is established in the shell child, which has already setuid to the user. Assuming that it must be done that way (to support protocol 1), changing the password may require privs, and the shell child can't *call* the monitor, some possible options are: 1) A setuid helper (ssh-chauthtok-helper, /bin/passwd), eg, if (use_privsep) exec /bin/passwd else do_pam_chauthtok() 2) Have the monitor fork a child *that does not exit immediately* and return a descriptor connected to it. Have that child wait for a write on the descriptor. When the shell child runs, it writes to the descriptor to wake up the privileged child which runs do_pam_chauthok(), using a little protocol to indicate success or failure. This is fiddly and complex (== bad) but might work. Since there's always *someone* who hates a given solution to this problem, I vote for 1) with /bin/passwd. It's simple and I've already written most of it :-) The PAM purists will hate it but they can turn off privsep if they need the real do_pam_chauthtok, or re-define PATH_PASSWD_PROGRAM and make it run whatever they like. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 12 03:37:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Mar 2003 03:37:30 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030311163730.4C11594209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From rusr at cup.hp.com 2003-03-12 03:37 ------- Regarding the name space collision with the log function, the collision is not in libsec as comment #3 asserts, but is in lib_pamunix. While in trusted mode and attempting to generate passwords for the user, lib_pamunix calls the log(3M) function from the math library. (see also Bug #484). Although you could say that libraries should be statically linked, no one has any real control over dynamically loaded libraries (like all pam libraries). Comapnies can write their own and link them however they wish. For that reason, it is safer to avoid re-using function names that are found in common system libraries. This is why HP-UX trusted mode has failed during do_pam_chauthtok() when the system is generating a password for the user. As far the case where HP-UX trusted mode fails when the user picks a password, see bug #473 (which is marked as a duplicate of this bug) for an explanation of why do_pam_chauthtok() fails. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From sales at bodacion.com Wed Mar 12 06:14:15 2003 From: sales at bodacion.com (Bodacion Technologies) Date: Tue, 11 Mar 2003 11:14:15 -0800 Subject: Reminder: Please join us!! Message-ID: ========================================================== Reminder: Please join us!! ========================================================== Hello, Bodacion Technologies invites you to learn more about our secure Web services appliance, HYDRA. Learn what your network architecture will look like implementing HYDRA, what standards and protocols HYDRA incorporates into its services, and how the cost of owning a HYDRA compares to your current setup. When: Thursday, March 13th at 10:00am CST or 12:30pm CST Who: Given by Bodacion Technologies Where: Online! (At the comfort of your own desk) To join us, simply complete the brief registration form available at http://www.bodacion.com/webinar.html or to register by phone, call Jenny at 847-842-9008. Register now as limited seats remain! - Surrender is Not an Option - Click here for more information! - http://www.bodacion.com/introtowebinar.html Click here to register! - http://www.bodacion.com/webinar.html Bodacion Technologies -- Advanced Solutions in Web Security and Reliability ========================================================== Bodacion Technologies 18-3 East Dundee Road Suite 300 Barrington, IL 60010 Web Site: http://www.bodacion.com Email: sales at bodacion.com Phone: 847-842-9008 Fax: 847-842-1731 _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/sp?c=27695&s=78EFD077557B4CAD&m=7 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 43 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 4176 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 816 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1803 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 43 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/e9aba4c6/attachment-0004.gif From bugzilla-daemon at mindrot.org Wed Mar 12 10:57:07 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 12 Mar 2003 10:57:07 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030311235707.3987294222@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From support at hotel-directory.com Wed Mar 12 11:44:35 2003 From: support at hotel-directory.com (Hotel Directory) Date: Tue, 11 Mar 2003 16:44:35 -0800 Subject: sponsorship Message-ID: <004601c2e830$9179fb80$0701a8c0@AMD> I could not find a relevant email to send this request to so please forgive me and forward as appropriate. I was wondering if you would consider a sponsorship link your main page. Perhaps for a flat monthly fee or something. Please let me know. Thanks. John Economou Hotel Directory http://www.hotel-directory.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030311/efe2c143/attachment.html From wendyp at cray.com Thu Mar 13 07:08:22 2003 From: wendyp at cray.com (Wendy Palm) Date: Wed, 12 Mar 2003 14:08:22 -0600 Subject: Call for testing for 3.6 References: Message-ID: <3E6F93B6.5000500@cray.com> cray is broken also wrt nanosleep(). additionally, there's a stupid locality error that cray is having a problem with in scp.c. a variable "limit" has been added at line 99. this causes an incompatible declaration with cray's limit function defined in /usr/include/sys/resource.h which is included in includes.h. so, i either need to not include in includes.h (which seems to be unnecessary anyway, everything compiles without it) or change the name of the limit variable in scp.c. personally, i'd prefer to rename the variable. i might have missed something important in resource.h. thanks much, wendy Tim Rice wrote: > On Thu, 6 Mar 2003, Ben Lindstrom wrote: > > >>I'd like to see more tinderbox setups (Darren, I'll be talking to you in >>private, but I have a Sol9 box I'd like to add to the list soon). It >>would help to know where we stand for broken platforms. >> > > UnixWare and SCO are broken. > I guess I'd better whip up a nanosleep() replacement. > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From bugzilla-daemon at mindrot.org Thu Mar 13 08:50:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 13 Mar 2003 08:50:58 +1100 (EST) Subject: [Bug 508] Krb4/AFS token passing doesn't work because of mkstemp Message-ID: <20030312215058.A11309420D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=508 Summary: Krb4/AFS token passing doesn't work because of mkstemp Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: ksulliva at psc.edu In auth-krb4.c, in krb4_init(), we have: if ((fd = mkstemp(authctxt->krb4_ticket_file)) != -1) { which tries to create a temporary file to hold kerberos tickets. This file is created some lines above by: snprintf(authctxt->krb4_ticket_file, MAXPATHLEN, "%s%u_%ld", So, mkstemp() is passes something like "/tmp/tkt9036_6294", with no Xs at the end. On a RedHat 8.0, mkstemp() will fail if the file template does not end with at least 6 Xs. To fix this, replace the mkstemp line with: if ((fd = open(authctxt->krb4_ticket_file, O_RDWR|O_CREAT|O_EXCL, 0x600)) != -1) { ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 13 09:43:17 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 13 Mar 2003 09:43:17 +1100 (EST) Subject: [Bug 508] Krb4/AFS token passing doesn't work because of mkstemp Message-ID: <20030312224317.D74E09420D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=508 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-03-13 09:43 ------- Please search existing bug reports before submitting new bugs *** This bug has been marked as a duplicate of 44 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 13 09:43:19 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 13 Mar 2003 09:43:19 +1100 (EST) Subject: [Bug 44] Can't pass KRB4 TGT on RH7.2 due to glibc mkstemp Message-ID: <20030312224319.950989422A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=44 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ksulliva at psc.edu ------- Additional Comments From djm at mindrot.org 2003-03-13 09:43 ------- *** Bug 508 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 13 18:51:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 13 Mar 2003 18:51:58 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20030313075158.0A75C9420E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #240 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-03-13 18:51 ------- Created an attachment (id=248) --> (http://bugzilla.mindrot.org/attachment.cgi?id=248&action=view) passexpire18: AIX & /etc/shadow password expiry Fixed double-change bug when PAM was enabled. Removed resetting forwarding flags via SIGUSR1. Same patch against 3.5p1 release is available at http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire18.patch ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From d_wllms at lanl.gov Fri Mar 14 07:44:50 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Thu, 13 Mar 2003 13:44:50 -0700 Subject: encrypt authentication credentials with payload in the clear? In-Reply-To: <200303011325.h21DPNMe084306@crag.niss.com> References: <200303011325.h21DPNMe084306@crag.niss.com> Message-ID: <3E70EDC2.8060501@lanl.gov> Something for those in this conversation to note: Proposed language to update the Security Conciderations section of the core IETF drafts in the secsh-WG, (I added the underlining) 11.1 Confidentiality This protocol does allow the encryption mechanism to be disabled. Implementors _SHOULD be wary of exposing this_ _feature for any purpose other than debugging_. Users and administrators _SHOULD be explicitly warned anytime the_ _"none" method is enabled_. Dave -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From bugzilla-daemon at mindrot.org Fri Mar 14 09:07:34 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 09:07:34 +1100 (EST) Subject: [Bug 509] slogin.1 is a broken symlink Message-ID: <20030313220734.3C7C99420A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=509 Summary: slogin.1 is a broken symlink Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: trivial Priority: P4 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bugzilla at deprived.org slogin.1 points to ssh.1 , ssh.1 is gzipped, which means its name is ssh.1.gz. root at aliens:/usr/man/man1# ls -l slogin.1 lrwxrwxrwx 1 root root 7 Mar 7 08:12 slogin.1 -> ./ssh.1 root at aliens:/usr/man/man1# ls -l ssh.1 /bin/ls: ssh.1: No such file or directory root at aliens:/usr/man/man1# ls -l ssh.1.gz -rw-r--r-- 1 root root 10309 Oct 17 00:56 ssh.1.gz root at aliens:/usr/man/man1# ahh.. yah, I can hear it now "oops!" - heh ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 14 09:11:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 09:11:06 +1100 (EST) Subject: [Bug 509] slogin.1 is a broken symlink Message-ID: <20030313221106.81D689420A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=509 ------- Additional Comments From bugzilla at deprived.org 2003-03-14 09:11 ------- btw, I am using slackware-current (9.0-beta), with the latest slackware package. openssh-3.5p1-i386-1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 14 10:51:47 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 10:51:47 +1100 (EST) Subject: [Bug 509] slogin.1 is a broken symlink Message-ID: <20030313235147.17CB294208@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=509 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-03-14 10:51 ------- The problem is with Slackware, we don't compress the installed manpages ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 14 19:14:06 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 19:14:06 +1100 (EST) Subject: [Bug 463] PrintLastLog doesn't work in privsep mode Message-ID: <20030314081406.A92889420B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=463 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Keywords| |patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 14 19:18:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 19:18:26 +1100 (EST) Subject: [Bug 396] sshd orphans processes when no pty allocated Message-ID: <20030314081826.5F69F9421B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=396 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Weimer at CERT.Uni-Stuttgart.DE Fri Mar 14 19:46:47 2003 From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer) Date: Fri, 14 Mar 2003 09:46:47 +0100 Subject: Enable RSA blinding Message-ID: <871y1afi88.fsf@Login.CERT.Uni-Stuttgart.DE> After browsing "Remote timing attacks are practical" (Boneh & Brumley, ), I wonder if it might be a good idea to add calls to RSA_blinding_on() before the OpenSSL RSA decryption routines are invoked. The issue is not a LAN-only issue, BTW. Packet delay variation is usually higher in LANs than in WANs. -- Florian Weimer Weimer at CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From bugzilla-daemon at mindrot.org Fri Mar 14 20:47:14 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 20:47:14 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030314094714.BBF5994212@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #239 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2003-03-14 20:47 ------- Created an attachment (id=249) --> (http://bugzilla.mindrot.org/attachment.cgi?id=249&action=view) Update patch to current to fix conflicts ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 14 20:47:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 14 Mar 2003 20:47:35 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20030314094735.CC74D94212@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vdanen at linsec.ca Sat Mar 15 11:28:22 2003 From: vdanen at linsec.ca (Vincent Danen) Date: Fri, 14 Mar 2003 17:28:22 -0700 Subject: restricing port forwarding ports server-side Message-ID: <20030315002822.GH11985@mandrakesoft.com> I'm curious as to whether or not there is a way to restrict forwarded ports server side. For instance, I'm running an IRC server and am allowing users to connect via ssh forwarding (so I can take advantange of using openssh's public key method for authentication). Each client I tell to setup their ~/.ssh/config in a certain way, but the relevant line is: LocalForward 6667 localhost:42000 where port 42000 is what ircd is listening to on the server. This works great, but my concern is a user changing this to localhost:3306 to gain access to MySQL, which is firewalled off. Reading O'Reilly's book on ssh, I see that F-Secure has a config option "AllowForwardingPort" to allow a range of ports that can be forwarded, but no mention of openssh having the same functionality. Basically, what I'd like to see in my (server-side) authorized_keys file is something like: no-pty,command="sleep 20",allowforwardingport="42000" ssh-dss [key] So that I can restrict what ports can be forwarded on a per-account basis (I only want this restriction for this one "general" user that everyone uses to obtain access to the IRC server). I know the book is a little dated, but has anything like this appeared in openssh yet? If not, are there perhaps plans to do something like this? I think it could be invaluable. Or, if there are no plans, does anyone have any ideas how I could implement something like this? Thanks very much in advance. -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030314/ca7e7a82/attachment.bin From Weimer at CERT.Uni-Stuttgart.DE Sat Mar 15 19:39:43 2003 From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer) Date: Sat, 15 Mar 2003 09:39:43 +0100 Subject: restricing port forwarding ports server-side In-Reply-To: <20030315002822.GH11985@mandrakesoft.com> (Vincent Danen's message of "Fri, 14 Mar 2003 17:28:22 -0700") References: <20030315002822.GH11985@mandrakesoft.com> Message-ID: <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> Vincent Danen writes: > I know the book is a little dated, but has anything like this > appeared in openssh yet? We've got a proof-of-concept implementation of global and per-user port forwarding control. We don't use it anymore, so the patches are still against 3.4p1, and they aren't thoroughly tested. -- Florian Weimer Weimer at CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From djm at mindrot.org Sun Mar 16 00:59:41 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2003 00:59:41 +1100 Subject: Enable RSA blinding In-Reply-To: <871y1afi88.fsf@Login.CERT.Uni-Stuttgart.DE> References: <871y1afi88.fsf@Login.CERT.Uni-Stuttgart.DE> Message-ID: <3E7331CD.7020003@mindrot.org> Florian Weimer wrote: > After browsing "Remote timing attacks are practical" (Boneh & Brumley, > ), I > wonder if it might be a good idea to add calls to RSA_blinding_on() > before the OpenSSL RSA decryption routines are invoked. It is on in the snapshots as of tonight (thank Markus). > The issue is not a LAN-only issue, BTW. Packet delay variation is > usually higher in LANs than in WANs. I'm curious about this - do you have a reference or some evidence? -d From djm at mindrot.org Sun Mar 16 01:00:51 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2003 01:00:51 +1100 Subject: restricing port forwarding ports server-side In-Reply-To: <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> References: <20030315002822.GH11985@mandrakesoft.com> <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> Message-ID: <3E733213.8080306@mindrot.org> Florian Weimer wrote: > Vincent Danen writes: > > >>I know the book is a little dated, but has anything like this >>appeared in openssh yet? > > > We've got a proof-of-concept implementation of global and per-user > port forwarding control. We don't use it anymore, so the patches are > still against 3.4p1, and they aren't thoroughly tested. > > See also my even older KeyNote policy patches (check the archives). I'll probably revive them post-3.6. -d From dot at dotat.at Sun Mar 16 01:50:27 2003 From: dot at dotat.at (Tony Finch) Date: Sat, 15 Mar 2003 14:50:27 +0000 Subject: restricing port forwarding ports server-side In-Reply-To: <20030315002822.GH11985@mandrakesoft.com> Message-ID: Vincent Danen wrote: > >I'm curious as to whether or not there is a way to restrict forwarded ports >server side. For instance, I'm running an IRC server and am allowing users >to connect via ssh forwarding (so I can take advantange of using openssh's >public key method for authentication). Each client I tell to setup their >~/.ssh/config in a certain way, but the relevant line is: > >LocalForward 6667 localhost:42000 > >where port 42000 is what ircd is listening to on the server. This works >great, but my concern is a user changing this to localhost:3306 to gain >access to MySQL, which is firewalled off. You can do this with my restricted-environment patch using appropriate PermitTcpConnect options. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104387691708672 Tony. -- f.a.n.finch http://dotat.at/ HUMBER: SOUTHEASTERLY 4 OR 5 DECREASING 3. FAIR. GOOD. From bugzilla-daemon at mindrot.org Sun Mar 16 02:42:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 16 Mar 2003 02:42:01 +1100 (EST) Subject: [Bug 510] corrupted mac address disconnecting Message-ID: <20030315154201.5421F94221@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=510 Summary: corrupted mac address disconnecting Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: semper_eadem at hotmail.com Hardware related with the bug.Cable/dsl Lynksys router, tyan k7x motherboard, dual athlon mp. X11 forwarding fails and ssh disconnects in the LAN when trying to resolve the host by using DNS servers. For example if you try to connect whithin your LAN to your host computer running sshd. (assume that your host has a domainname host.bug.com= 65.92.197.129) and you try: ssh -X -l username host.bug.com this will lead to corrupted MAC address If you are within your LAN you have to use the internal LAN ip of the host. ssh -X -l username 192.168.1.106 (Asuming 192.168.1.106 is the internal ip address of the host. It should be assigned statically by th lynksys router) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Sun Mar 16 03:24:43 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 15 Mar 2003 10:24:43 -0600 (CST) Subject: Enable RSA blinding In-Reply-To: <3E7331CD.7020003@mindrot.org> Message-ID: On Sun, 16 Mar 2003, Damien Miller wrote: > Florian Weimer wrote: > > After browsing "Remote timing attacks are practical" (Boneh & Brumley, > > ), I > > wonder if it might be a good idea to add calls to RSA_blinding_on() > > before the OpenSSL RSA decryption routines are invoked. > > It is on in the snapshots as of tonight (thank Markus). > I saw that.. I'm still interested in a break down to where OpenSSH would be prone to such attacks. I'm sure v1 would easily be, but the complexity of v2 makes me wonder. Still better be safe than sorry. > > The issue is not a LAN-only issue, BTW. Packet delay variation is > > usually higher in LANs than in WANs. > > I'm curious about this - do you have a reference or some evidence? > I don't agree with him. t may take longer for a WAN connection, but you can easily isolate the timing at anytime between two points on a WAN. It has been proven many times. Just because the timing rate changes does not make it impossible. - Ben From bgowrish at riverstonenet.com Sun Mar 16 07:10:47 2003 From: bgowrish at riverstonenet.com (M.B.Gowrishankar) Date: Sat, 15 Mar 2003 12:10:47 -0800 Subject: OpenSSH_3.5 version string. Message-ID: <3E7388C7.90D63130@riverstonenet.com> Hi, We found that the OpenSSH server code sends it version string as "SSH-1.5_OpenSSH_3.5" to the client during the intial phases of connection establishment. Futher more some clients like telnet client displays this version string on error. Like for example if we typed "Telnet host <> port 22" on a solaris workstation, where the host is a machine which is running OpenSSH3.5 ssh server, then, we get the following version string displayed on the console by the telnet client : "SSH-1.5_OpenSSH_3.5" We don't desire to expose this version string or atleast the "OpenSSH_3.5" part of the version string to any client. We see this as a potential secure risk. Someone who comes to know the OpenSSH version that we use, might try to use that to his/her advantage to break the security. But the OpenSSH code seems to rely upon this version string. Besides, removing the "OpenSSH_3.5" from the version string in the server code seems to cause connectivity problems to certain client like ssh communication for protocol 2. Is there a way out if we desire not to send the OpenSSH_3.5 version to the client in the server code ? Any pointers will be greatly appreciated. thanks Gowri From openssh at mobiustech.net Sun Mar 16 09:40:39 2003 From: openssh at mobiustech.net (Phil) Date: Sat, 15 Mar 2003 22:40:39 +0000 Subject: Force reading with SSH_ASKPASS? Message-ID: <200303152240.39197.openssh@mobiustech.net> Hi, I'm looking at integrating sftp into a larger project. It would be nice if there was a way to force read_passphrase() (in readpass.c) to use SSH_ASKPASS regardless of the properties of the terminal. This would be easy enough to do, an environment variable or a new flag definition would achieve this (I'm using an environment variable for convenience at the moment). Would anyone be interested in receiving a patch for this? If so, which apporach would you prefer? Thanks, -phil From bugzilla-daemon at mindrot.org Sun Mar 16 10:09:18 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 16 Mar 2003 10:09:18 +1100 (EST) Subject: [Bug 510] corrupted mac address disconnecting Message-ID: <20030315230918.0084994227@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=510 ------- Additional Comments From djm at mindrot.org 2003-03-16 10:09 ------- You bug report makes _zero_ sense. Corrupted MAC address? Where? This sounds like a network misconfiguration, not any sort of OpenSSH bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Sun Mar 16 10:14:45 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2003 10:14:45 +1100 Subject: OpenSSH_3.5 version string. In-Reply-To: <3E7388C7.90D63130@riverstonenet.com> References: <3E7388C7.90D63130@riverstonenet.com> Message-ID: <3E73B3E5.1070804@mindrot.org> M.B.Gowrishankar wrote: > Hi, > > We found that the OpenSSH server code sends it version string as > "SSH-1.5_OpenSSH_3.5" to the client during the intial phases of > connection establishment. Futher more some clients like telnet client > displays this version string on error. Like for example if we typed > "Telnet host <> port 22" on a solaris workstation, where the host is a > machine which is running OpenSSH3.5 ssh server, then, we get the > following version string displayed on the console by the telnet client : > "SSH-1.5_OpenSSH_3.5" > > We don't desire to expose this version string or atleast the > "OpenSSH_3.5" part of the version string to any client. We see this as a > potential secure risk. Someone who comes to know the OpenSSH version > that we use, might try to use that to his/her advantage to break the > security. Please read the mailing list archives, where this has been covered again and again and again. Short answer: the version string stays. -d From djm at mindrot.org Sun Mar 16 10:16:30 2003 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2003 10:16:30 +1100 Subject: Force reading with SSH_ASKPASS? In-Reply-To: <200303152240.39197.openssh@mobiustech.net> References: <200303152240.39197.openssh@mobiustech.net> Message-ID: <3E73B44E.6030901@mindrot.org> Phil wrote: > Hi, > > I'm looking at integrating sftp into a larger project. It would be nice if > there was a way to force read_passphrase() (in readpass.c) to use SSH_ASKPASS > regardless of the properties of the terminal. Set the DISPLAY environment variable (to anything, it doesn't have to be a valid X socket) and make sure that the ssh invocation has no controlling tty. -d From jaguar_mayor at hotmail.com Sun Mar 16 12:44:34 2003 From: jaguar_mayor at hotmail.com (Brenda) Date: Sat, 15 Mar 2003 17:44:34 -0800 Subject: ¡¡¡Personajes clasicos de disney¡¡¡ Message-ID: <41148-22003301614434770@7> El ingles es para siempre??? "El ingles es para siempre" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030315/b76769d6/attachment.html From tim at multitalents.net Mon Mar 17 11:27:31 2003 From: tim at multitalents.net (Tim Rice) Date: Sun, 16 Mar 2003 16:27:31 -0800 (PST) Subject: scp.c: u_int64_t in bwlimit() Message-ID: u_int64_t has been introduced into scp.c with the new bwlimit function causing some platforms to break. Would this work? ----------------------------------- --- scp.c.old 2003-03-09 17:16:43.000000000 -0800 +++ scp.c 2003-03-16 16:17:57.095520029 -0800 @@ -670,7 +670,7 @@ { static struct timeval bwstart, bwend; static int lamt, thresh = 16384; - u_int64_t wait; + off_t wait; struct timespec ts, rm; if (!timerisset(&bwstart)) { ----------------------------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Mon Mar 17 11:34:52 2003 From: tim at multitalents.net (Tim Rice) Date: Sun, 16 Mar 2003 16:34:52 -0800 (PST) Subject: nanosleep() replacement Message-ID: I put together a nanosleep() for systems without it. Please review/test before I commit. It sems to make UnixWare and Open Server 5 happy. My SCO Open Server 3 box broke so I can't test it there. -------------< cut here >---------------- --- openssh/configure.ac.old 2003-03-09 17:16:43.000000000 -0800 +++ openssh/configure.ac 2003-03-16 15:38:28.520560008 -0800 @@ -1483,6 +1483,8 @@ have_struct_timeval=1 fi +AC_CHECK_TYPES(struct timespec) + # If we don't have int64_t then we can't compile sftp-server. So don't # even attempt to do it. if test "x$ac_cv_have_int64_t" = "xno" -a \ --- openssh/openbsd-compat/bsd-misc.c.old 2003-01-19 19:21:01.000000000 -0800 +++ openssh/openbsd-compat/bsd-misc.c 2003-03-16 14:49:58.740480006 -0800 @@ -135,3 +135,34 @@ } #endif +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) +int nanosleep(const struct timespec *req, struct timespec *rem) +{ + int rc; + extern int errno; + struct timeval tsave, ttmp, time2wait; + + TIMESPEC_TO_TIMEVAL(&time2wait, req) + + gettimeofday(&tsave, NULL); + rc = select(0, NULL, NULL, NULL, &time2wait); + if (rc) { + gettimeofday (&ttmp, NULL); + ttmp.tv_sec -= tsave.tv_sec; + ttmp.tv_usec -= tsave.tv_usec; + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); + if(tsave.tv_sec < 0){ + tsave.tv_sec = 0; + tsave.tv_usec += 1000000L; + } + rc = -1; + } + + TIMEVAL_TO_TIMESPEC(&tsave, rem) + + return(rc); +} + +#endif + --- openssh/openbsd-compat/bsd-misc.h.old 2002-06-20 20:35:30.000000000 -0700 +++ openssh/openbsd-compat/bsd-misc.h 2003-03-16 15:32:29.850560003 -0800 @@ -80,5 +80,14 @@ int setgroups(size_t size, const gid_t *list); #endif +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) +#ifndef HAVE_STRUCT_TIMESPEC +struct timespec { + time_t tv_sec; + long tv_nsec; +}; +#endif +int nanosleep(const struct timespec *req, struct timespec *rem); +#endif #endif /* _BSD_MISC_H */ -------------< end cut >---------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From linux_4ever at yahoo.com Mon Mar 17 15:24:24 2003 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 16 Mar 2003 20:24:24 -0800 (PST) Subject: RAND_bytes return value Message-ID: <20030317042424.30679.qmail@web9605.mail.yahoo.com> Hello, I have been doing some looking at openssl 0.9.7 and openssh3.5p1 and found a minor descrepancy. RAND_bytes() is called around line 69 of openbsd-compat/bsd-arc4random.c. It checks to see if the return is not zero. The RAND_bytes function can also return -1, too. All the code in openssl uses <=0 for the test rather than !. Best Regards, Steve Grubb __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com From djm at mindrot.org Mon Mar 17 16:52:28 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Mar 2003 16:52:28 +1100 Subject: RAND_bytes return value In-Reply-To: <20030317042424.30679.qmail@web9605.mail.yahoo.com> References: <20030317042424.30679.qmail@web9605.mail.yahoo.com> Message-ID: <3E75629C.8000207@mindrot.org> Steve G wrote: > Hello, > > I have been doing some looking at openssl 0.9.7 and > openssh3.5p1 and found a minor descrepancy. RAND_bytes() is > called around line 69 of openbsd-compat/bsd-arc4random.c. > It checks to see if the return is not zero. The RAND_bytes > function can also return -1, too. All the code in openssl > uses <=0 for the test rather than !. Fixed, thanks -d From dtucker at zip.com.au Mon Mar 17 19:32:45 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Mar 2003 19:32:45 +1100 Subject: nanosleep() replacement References: Message-ID: <3E75882D.14B562D8@zip.com.au> Tim Rice wrote: > I put together a nanosleep() for systems without it. > > Please review/test before I commit. I can confirm that this works on Solaris 8 (configured without librt, which is where nanosleep is), however it doesn't seem to cope well with the lower limits. Is this an unavoidable consequence of the lesser precision of select? For comparison here's what I got from: $ scp -l [limit] -o Compression=no openssh-3.5p1.tar.gz localhost:/tmp limit nanosleep select/bsd-misc 1 1 30 8 8 48 64 64 66 128 129 130 256 255 255 (all kbits/sec, calculated from kbytes/sec reported by scp) One other thought: since lots of things (including scp) use ssh as a transport, and bandwidth limiting is more a transport layer function, shouldn't bandwidth limiting be a function of ssh not scp? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Mar 17 22:16:50 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Mar 2003 22:16:50 +1100 Subject: nanosleep() replacement References: <3E75882D.14B562D8@zip.com.au> Message-ID: <3E75AEA2.47F4C94A@zip.com.au> Darren Tucker wrote: > Tim Rice wrote: > > I put together a nanosleep() for systems without it. > > > > Please review/test before I commit. > > I can confirm that this works on Solaris 8 (configured without librt, > which is where nanosleep is), however it doesn't seem to cope well with > the lower limits. This turned out to be because select() is interrupted by SIGALRM and the replacement function does not set errno in this case (gettimeofday resets errno after the select). Scp checks errno for EINTR. The higher speeds were less affected because they had less chance of being interrupted. I did some fiddling and got pretty close to the real nanosleep with the modified function below. limit nanosleep bsd-misc orig bsd-misc modified 1 1 30 1 8 8 48 8 64 64 66 61 128 129 130 129 256 255 255 256 (all kbits/sec, calculated from kbytes/sec reported by scp) -Daz. int nanosleep(const struct timespec *req, struct timespec *rem) { int rc; extern int errno; struct timeval tstart, tstop, tremain, time2wait; TIMESPEC_TO_TIMEVAL(&time2wait, req) gettimeofday(&tstart, NULL); rc = select(0, NULL, NULL, NULL, &time2wait); gettimeofday (&tstop, NULL); tremain.tv_sec = tstop.tv_sec - tstart.tv_sec - time2wait.tv_sec; tremain.tv_usec = tstop.tv_usec - tstart.tv_usec - time2wait.tv_usec; tremain.tv_sec += tremain.tv_usec / 1000000L; tremain.tv_usec %= 1000000L; TIMEVAL_TO_TIMESPEC(&tremain, rem) if (rc < 0) { rc = -1; errno = EINTR; } return(rc); } -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Mar 17 23:07:12 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Mar 2003 23:07:12 +1100 Subject: nanosleep() replacement References: Message-ID: <3E75BA70.BC17EF08@zip.com.au> Tim Rice wrote: > I put together a nanosleep() for systems without it. > > Please review/test before I commit. Before I forget, a couple of things I noticed while playing around with this: [snip] > +int nanosleep(const struct timespec *req, struct timespec *rem) > +{ > + int rc; > + extern int errno; > + struct timeval tsave, ttmp, time2wait; > + > + TIMESPEC_TO_TIMEVAL(&time2wait, req) > + > + gettimeofday(&tsave, NULL); > + rc = select(0, NULL, NULL, NULL, &time2wait); > + if (rc) { Checking for rc == -1, right? Would "if (rc < 0)" be clearer? > + gettimeofday (&ttmp, NULL); This can reset errno so (errno==EINTR) from select can be lost. > + ttmp.tv_sec -= tsave.tv_sec; > + ttmp.tv_usec -= tsave.tv_usec; > + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); > + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); > + if(tsave.tv_sec < 0){ > + tsave.tv_sec = 0; > + tsave.tv_usec += 1000000L; > + } > + rc = -1; > + } > + > + TIMEVAL_TO_TIMESPEC(&tsave, rem) In the case where select returns normally, the remainder is whatever gettimeofday() returned which will be *way* bigger than the requested wait time and any possible remainder. > + return(rc); [snip] -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Mon Mar 17 23:16:21 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 17 Mar 2003 13:16:21 +0100 Subject: nanosleep() replacement In-Reply-To: <3E75AEA2.47F4C94A@zip.com.au> References: <3E75882D.14B562D8@zip.com.au> <3E75AEA2.47F4C94A@zip.com.au> Message-ID: <20030317121621.GP1228@cygbert.vinschen.de> Hi, On Mon, Mar 17, 2003 at 10:16:50PM +1100, Darren Tucker wrote: > I did some fiddling and got pretty close to the real nanosleep with the > modified function below. wouldn't it make sense to return the correct errno like this: > int nanosleep(const struct timespec *req, struct timespec *rem) > { > int rc; int sav_errno; > extern int errno; > struct timeval tstart, tstop, tremain, time2wait; > > TIMESPEC_TO_TIMEVAL(&time2wait, req) > > gettimeofday(&tstart, NULL); > rc = select(0, NULL, NULL, NULL, &time2wait); if (rc < 0) sav_errno = errno; > gettimeofday (&tstop, NULL); > > tremain.tv_sec = tstop.tv_sec - tstart.tv_sec - time2wait.tv_sec; > tremain.tv_usec = tstop.tv_usec - tstart.tv_usec - > time2wait.tv_usec; > tremain.tv_sec += tremain.tv_usec / 1000000L; > tremain.tv_usec %= 1000000L; > TIMEVAL_TO_TIMESPEC(&tremain, rem) > > if (rc < 0) { > rc = -1; errno = sav_errno; > } > return(rc); > } Even though EINTR is the most common error in the degenerated select, it's not necessarily the only error. E. g. EINVAL, which is returned by select if the timer value is invalid. This is also a common error code for nanosleep. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From bugzilla-daemon at mindrot.org Tue Mar 18 00:14:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 00:14:52 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030317131452.12EA69423C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 Summary: PublickKeyAuthentication failures when account password expires Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jim.a.davidson at bt.com Some time ago I reported this problem with AIX and I think Darren Tucker was kind enough to supply a patch,such that even if the account password had expired,we could still use PublicKeyAuthentication to access the remote machine using that account.I now seem to have a similar problem with Solaris.Is there a patch available for Solaris to allow us to do this. We typically usr root account to remotely manage machines and usually set it to PermitRootLogin without-password as well as disabling remote logins in the o/s. We also use non privileged accounts to sftp stuff around in batch mode and do not want to see password change prompts or connection failures because the password has expired. Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Stephan.Hendl at lds.brandenburg.de Tue Mar 18 00:56:47 2003 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Mon, 17 Mar 2003 14:56:47 +0100 Subject: ProxyCommand Message-ID: Hi all, I tried to use the ProxyCommand option in the ~/.ssh/config file like ProxyCommand /usr/local/bin/corkscrew 80 %h %p but it seems th me that the ssh clinet won't use the option .. How can I tell the client to accept the proxy an send all requests to this host, bcause the internet names ("%P") cannot be resolved inside our lan - this must do the proxy. Thanks! Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 mobil: +49-(0)160-90 645 893 EMail: stephan.hendl at lds.brandenburg.de From dwmw2 at infradead.org Tue Mar 18 01:14:03 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 17 Mar 2003 14:14:03 +0000 Subject: ProxyCommand In-Reply-To: References: Message-ID: <1047910442.28282.44.camel@passion.cambridge.redhat.com> On Mon, 2003-03-17 at 13:56, Stephan Hendl wrote: > Hi all, > > I tried to use the ProxyCommand option in the ~/.ssh/config file like > > ProxyCommand /usr/local/bin/corkscrew 80 %h %p > > but it seems th me that the ssh clinet won't use the option > .. How can I tell the client to accept the proxy an send all requests to this host, bcause the internet names ("%P") cannot be resolved inside our lan - this must do the proxy. Works for me in the opposite direction (_into_ RFC1918 network, not out)... Host *..internal ProxyCommand ssh exec netcat %h %p Try.... Host * ProxyCommand /usr/local/bin/corkscrew 80 %h %p -- dwmw2 From bugzilla-daemon at mindrot.org Tue Mar 18 02:35:57 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 02:35:57 +1100 (EST) Subject: [Bug 512] Hostbased authentication bypass PAM Message-ID: <20030317153557.39E0394256@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=512 Summary: Hostbased authentication bypass PAM Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: yaccck at yahoo.com While using hostbased authentication, users are allowed to login, even if i have "auth required /lib/security/pam_deny.so" set in /etc/pam.d/sshd. When i disable hostbased authentication, sshd behaves correctly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Tue Mar 18 04:28:03 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 09:28:03 -0800 (PST) Subject: nanosleep() replacement In-Reply-To: <3E75BA70.BC17EF08@zip.com.au> References: <3E75BA70.BC17EF08@zip.com.au> Message-ID: On Mon, 17 Mar 2003, Darren Tucker wrote: > Tim Rice wrote: > > I put together a nanosleep() for systems without it. > > > > Please review/test before I commit. > > Before I forget, a couple of things I noticed while playing around with > this: > > [snip] > > + gettimeofday(&tsave, NULL); > > + rc = select(0, NULL, NULL, NULL, &time2wait); > > + if (rc) { > > Checking for rc == -1, right? Would "if (rc < 0)" be clearer? Any non 0 means it didn't timeout. > > > + gettimeofday (&ttmp, NULL); > > This can reset errno so (errno==EINTR) from select can be lost. Opps. Good catch. > > + ttmp.tv_sec -= tsave.tv_sec; > > + ttmp.tv_usec -= tsave.tv_usec; > > + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); > > + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); > > + if(tsave.tv_sec < 0){ > > + tsave.tv_sec = 0; > > + tsave.tv_usec += 1000000L; > > + } > > + rc = -1; > > + } > > + > > + TIMEVAL_TO_TIMESPEC(&tsave, rem) > > In the case where select returns normally, the remainder is whatever > gettimeofday() returned which will be *way* bigger than the requested > wait time and any possible remainder. I wouldn't matter for how bwlimit() uses it, but your right, I should have done that correctly. (I was too focused on making bwlimit() work) > > > + return(rc); > [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From VBrimhall at novell.com Tue Mar 18 04:54:29 2003 From: VBrimhall at novell.com (Vince Brimhall) Date: Mon, 17 Mar 2003 10:54:29 -0700 Subject: Changes to OpenSSH for NetWare Message-ID: I have attached a diff file with the changes to existing OpenSSH source files to accomodate the NetWare platform. All changes are #ifdef wrapped using one in one of the following defines: HAVE_NETWARE - Building for NetWare USE_EDIR - Using eDirectory(TM) for authentication. NICI - Using Novell International Cryptography Infrastructure (NICI) I have successfully built the OpenSSH-3.5p1 source with my changes on RedHat 7.2 and 8.0. Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vince Brimhall Senior Software Engineer Web Services 801.861.1724 vbrimhall at novell.com Novell, Inc., The leading provider of Net Business Solutions http://www.novell.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: diff2.out Type: application/octet-stream Size: 39749 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030317/89bf4216/attachment.obj From spartacus at barbuta.net Tue Mar 18 06:50:14 2003 From: spartacus at barbuta.net (James Hammond) Date: Mon, 17 Mar 2003 14:50:14 -0500 Subject: "They Laughed When I Decided To Teach My Children At Home -- Message-ID: <20030317194545.00C079426C@shitei.mindrot.org> From mouring at etoh.eviladmin.org Tue Mar 18 07:04:08 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 17 Mar 2003 14:04:08 -0600 (CST) Subject: Changes to OpenSSH for NetWare In-Reply-To: Message-ID: Too much to audit before 3.6 .. WAY too much. I seem semi-questionable thing and other items that should be considered in every platform. Plus debugging code that should have been stripped. This patch the way it stands would make it even harder for us to keep merged with the OpenBSD tree. Consider revisiting it with the idea that you touch the least amount of code within the main tree and using openbsd-compat/port-netware.[ch] when you can logically do it. I believe I asked you this last time you posted. Also I see stray sprintf() wandering around. We prefer snprinf() (same goes with strncpy() to strlcpy()). BTW.. error(); exit(); should be fatal(); - Ben On Mon, 17 Mar 2003, Vince Brimhall wrote: > I have attached a diff file with the changes to existing OpenSSH source > files to > accomodate the NetWare platform. All changes are #ifdef wrapped using > one in > one of the following defines: > > HAVE_NETWARE - Building for NetWare > USE_EDIR - Using eDirectory(TM) for authentication. > NICI - Using Novell International Cryptography Infrastructure > (NICI) > > I have successfully built the OpenSSH-3.5p1 source with my changes on > RedHat > 7.2 and 8.0. > > Regards, > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Vince Brimhall > Senior Software Engineer > Web Services > 801.861.1724 > vbrimhall at novell.com > > Novell, Inc., The leading provider of Net Business Solutions > http://www.novell.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From mouring at etoh.eviladmin.org Tue Mar 18 07:04:51 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 17 Mar 2003 14:04:51 -0600 (CST) Subject: Missing Tru64 patch. Message-ID: Can I get that tru64 patch sent to me again. It seems during the cleaning spree it vanished and I can't locate it. - Ben From dtucker at zip.com.au Tue Mar 18 08:18:36 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 08:18:36 +1100 Subject: nanosleep() replacement References: <3E75BA70.BC17EF08@zip.com.au> Message-ID: <3E763BAC.EFD33245@zip.com.au> Tim Rice wrote: > On Mon, 17 Mar 2003, Darren Tucker wrote: > > Tim Rice wrote: > > > + gettimeofday(&tsave, NULL); > > > + rc = select(0, NULL, NULL, NULL, &time2wait); > > > + if (rc) { > > > > Checking for rc == -1, right? Would "if (rc < 0)" be clearer? > > Any non 0 means it didn't timeout. True, but since the number of fd's is 0 the only non-zero it'll ever return is -1. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Mar 18 08:24:34 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 08:24:34 +1100 Subject: nanosleep() replacement References: <3E75882D.14B562D8@zip.com.au> <3E75AEA2.47F4C94A@zip.com.au> <20030317121621.GP1228@cygbert.vinschen.de> Message-ID: <3E763D12.11AA2C2E@zip.com.au> Corinna Vinschen wrote: > On Mon, Mar 17, 2003 at 10:16:50PM +1100, Darren Tucker wrote: > > I did some fiddling and got pretty close to the real nanosleep with the > > modified function below. > > wouldn't it make sense to return the correct errno like this: [snip] > Even though EINTR is the most common error in the degenerated select, > it's not necessarily the only error. E. g. EINVAL, which is returned > by select if the timer value is invalid. This is also a common error > code for nanosleep. Good point. I hadn't taken much notice of what different errnos could return, I just added a case to handle what I saw happening. Happily, nanosleep and select return pretty much the same errnos, so what you're suggesting is probably a good idea. -- 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 bugzilla-daemon at mindrot.org Tue Mar 18 08:53:21 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 08:53:21 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030317215321.2985C9424E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 ------- Additional Comments From dtucker at zip.com.au 2003-03-18 08:53 ------- I think you're referring to bug #383, and if so that was about ignoring the AIX-specific "rlogin" attribute for root in favour of PermitRootLogin, not expiring passwords. Is there any reason you can't turn off password expiration for accounts where you don't want failures due to expired passwords? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Tue Mar 18 09:15:46 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 14:15:46 -0800 (PST) Subject: nanosleep() replacement Take 2 In-Reply-To: References: Message-ID: After Darren noticed a couple of problems, I've made a few changes. I'd like to hear from Wendy if this works on cray. Thanks for all the input. -------------< cut >---------------- --- openssh/configure.ac.old 2003-03-09 17:16:43.000000000 -0800 +++ openssh/configure.ac 2003-03-16 15:38:28.520560008 -0800 @@ -1483,6 +1483,8 @@ have_struct_timeval=1 fi +AC_CHECK_TYPES(struct timespec) + # If we don't have int64_t then we can't compile sftp-server. So don't # even attempt to do it. if test "x$ac_cv_have_int64_t" = "xno" -a \ --- openssh/openbsd-compat/bsd-misc.c.old 2003-01-19 19:21:01.000000000 -0800 +++ openssh/openbsd-compat/bsd-misc.c 2003-03-17 14:02:20.905600005 -0800 @@ -135,3 +135,38 @@ } #endif +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) +int nanosleep(const struct timespec *req, struct timespec *rem) +{ + int rc, saverrno; + extern int errno; + struct timeval tsave, ttmp, time2wait; + + TIMESPEC_TO_TIMEVAL(&time2wait, req) + + gettimeofday(&tsave, NULL); + rc = select(0, NULL, NULL, NULL, &time2wait); + if (rc == -1) { + saverrno = errno; + gettimeofday (&ttmp, NULL); + errno = saverrno; + ttmp.tv_sec -= tsave.tv_sec; + ttmp.tv_usec -= tsave.tv_usec; + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); + if(tsave.tv_sec < 0){ + tsave.tv_sec = 0; + tsave.tv_usec += 1000000L; + } + } + else { + tsave.tv_sec = 0; + tsave.tv_usec = 0; + } + TIMEVAL_TO_TIMESPEC(&tsave, rem) + + return(rc); +} + +#endif + --- openssh/openbsd-compat/bsd-misc.h.old 2002-06-20 20:35:30.000000000 -0700 +++ openssh/openbsd-compat/bsd-misc.h 2003-03-16 15:32:29.850560003 -0800 @@ -80,5 +80,14 @@ int setgroups(size_t size, const gid_t *list); #endif +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) +#ifndef HAVE_STRUCT_TIMESPEC +struct timespec { + time_t tv_sec; + long tv_nsec; +}; +#endif +int nanosleep(const struct timespec *req, struct timespec *rem); +#endif #endif /* _BSD_MISC_H */ -------------< end cut >---------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Tue Mar 18 09:14:29 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 09:14:29 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030317221429.68A5694273@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 ------- Additional Comments From jim.a.davidson at bt.com 2003-03-18 09:14 ------- Yes,I was in error. Our Security people insist on passwords being expired on any account that is logged into whether locally or not. If we authenticate using PublicKeyAuthentication do we really need to do the account password checking ? Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gert at greenie.muc.de Tue Mar 18 10:09:37 2003 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 18 Mar 2003 00:09:37 +0100 Subject: nanosleep() replacement Take 2 In-Reply-To: ; from tim@multitalents.net on Mon, Mar 17, 2003 at 02:15:46PM -0800 References: Message-ID: <20030318000937.X4402@greenie.muc.de> Hi, On Mon, Mar 17, 2003 at 02:15:46PM -0800, Tim Rice wrote: > After Darren noticed a couple of problems, I've made a few changes. > > I'd like to hear from Wendy if this works on cray. > > Thanks for all the input. Tested on SCO OSR 3.0. openssh-current (as of right now) with your appended patch. Configures, compiles, and "scp -l " seems to do things that correlate with the specified number (I assume it's kbit/second and the progress bar is Kbyte/second). -l is fairly unprecise, but this is likely due to a fairly slow machine, select()/scheduler granularity, and other things eating CPU. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From dtucker at zip.com.au Tue Mar 18 10:45:21 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 10:45:21 +1100 Subject: nanosleep() replacement Take 2 References: <20030318000937.X4402@greenie.muc.de> Message-ID: <3E765E11.316DF6D2@zip.com.au> Gert Doering wrote: > Tested on SCO OSR 3.0. openssh-current (as of right now) with your > appended patch. Configures, compiles, and "scp -l " seems to > do things that correlate with the specified number (I assume it's > kbit/second and the progress bar is Kbyte/second). Yes that's the case. > -l is fairly unprecise, but this is likely due to a fairly slow machine, > select()/scheduler granularity, and other things eating CPU. I saw that too with Tim's function but I was able to get pretty good results (5% variance or less from specified bandwidth) on a somewhat loaded 170 MHz SPARC. I suspect there's some cases it doesn't handle correctly (I'm trying to find an example). Would you mind trying the following function for comparison? -Daz. int nanosleep(const struct timespec *req, struct timespec *rem) { int rc; extern int errno; int saverrno; struct timeval tstart, tstop, tremain, time2wait; TIMESPEC_TO_TIMEVAL(&time2wait, req) gettimeofday(&tstart, NULL); rc = select(0, NULL, NULL, NULL, &time2wait); saverrno = errno; gettimeofday (&tstop, NULL); tremain.tv_sec = tstop.tv_sec - tstart.tv_sec - time2wait.tv_sec; tremain.tv_usec = tstop.tv_usec - tstart.tv_usec - time2wait.tv_usec; tremain.tv_sec += tremain.tv_usec / 1000000L; tremain.tv_usec %= 1000000L; TIMEVAL_TO_TIMESPEC(&tremain, rem) if (rc < 0) { rc = -1; errno = saverrno; } return(rc); } -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Tue Mar 18 10:58:53 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 15:58:53 -0800 (PST) Subject: nanosleep() replacement Take 2 In-Reply-To: <3E765E11.316DF6D2@zip.com.au> References: <20030318000937.X4402@greenie.muc.de> <3E765E11.316DF6D2@zip.com.au> Message-ID: On Tue, 18 Mar 2003, Darren Tucker wrote: > Gert Doering wrote: > > Tested on SCO OSR 3.0. openssh-current (as of right now) with your > > appended patch. Configures, compiles, and "scp -l " seems to > > do things that correlate with the specified number (I assume it's > > kbit/second and the progress bar is Kbyte/second). > > Yes that's the case. > > > -l is fairly unprecise, but this is likely due to a fairly slow machine, > > select()/scheduler granularity, and other things eating CPU. > > I saw that too with Tim's function but I was able to get pretty good > results (5% variance or less from specified bandwidth) on a somewhat > loaded 170 MHz SPARC. > > I suspect there's some cases it doesn't handle correctly (I'm trying to > find an example). > > Would you mind trying the following function for comparison? > > -Daz. Something isn't quite right with this version. When I try this I get ... scp -l 512 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 84.1KB/s 00:01 scp -l 256 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 42.0KB/s 00:02 scp -l 128 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 42.0KB/s 00:02 scp -l 64 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 42.0KB/s 00:02 scp -l 8 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 42.0KB/s 00:02 scp -l 1 openssh/sshd.o uw711:/tmp sshd.o 100% 84KB 42.0KB/s 00:02 ... > > int nanosleep(const struct timespec *req, struct timespec *rem) > { > int rc; > extern int errno; > int saverrno; > struct timeval tstart, tstop, tremain, time2wait; > > TIMESPEC_TO_TIMEVAL(&time2wait, req) > > gettimeofday(&tstart, NULL); > rc = select(0, NULL, NULL, NULL, &time2wait); > saverrno = errno; > gettimeofday (&tstop, NULL); > > tremain.tv_sec = tstop.tv_sec - tstart.tv_sec - time2wait.tv_sec; > tremain.tv_usec = tstop.tv_usec - tstart.tv_usec - > time2wait.tv_usec; > tremain.tv_sec += tremain.tv_usec / 1000000L; > tremain.tv_usec %= 1000000L; > TIMEVAL_TO_TIMESPEC(&tremain, rem) > > if (rc < 0) { > rc = -1; > errno = saverrno; > } > return(rc); > } > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Tue Mar 18 11:14:25 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 17 Mar 2003 18:14:25 -0600 (CST) Subject: nanosleep() replacement Take 2 In-Reply-To: <3E765E11.316DF6D2@zip.com.au> Message-ID: Mostly -l was designed to allow people to restrict their scp so it does not take over their bandwidth (mainly dialup and low-end DSL). The example was given was a long download that you don't care when it finishes, just you don't want to choke your small pipe while doing it. So I doubt it being 100% perfect is a major deal on some platforms. - Ben On Tue, 18 Mar 2003, Darren Tucker wrote: > Gert Doering wrote: > > Tested on SCO OSR 3.0. openssh-current (as of right now) with your > > appended patch. Configures, compiles, and "scp -l " seems to > > do things that correlate with the specified number (I assume it's > > kbit/second and the progress bar is Kbyte/second). > > Yes that's the case. > > > -l is fairly unprecise, but this is likely due to a fairly slow machine, > > select()/scheduler granularity, and other things eating CPU. > > I saw that too with Tim's function but I was able to get pretty good > results (5% variance or less from specified bandwidth) on a somewhat > loaded 170 MHz SPARC. > > I suspect there's some cases it doesn't handle correctly (I'm trying to > find an example). > > Would you mind trying the following function for comparison? > > -Daz. > > int nanosleep(const struct timespec *req, struct timespec *rem) > { > int rc; > extern int errno; > int saverrno; > struct timeval tstart, tstop, tremain, time2wait; > > TIMESPEC_TO_TIMEVAL(&time2wait, req) > > gettimeofday(&tstart, NULL); > rc = select(0, NULL, NULL, NULL, &time2wait); > saverrno = errno; > gettimeofday (&tstop, NULL); > > tremain.tv_sec = tstop.tv_sec - tstart.tv_sec - time2wait.tv_sec; > tremain.tv_usec = tstop.tv_usec - tstart.tv_usec - > time2wait.tv_usec; > tremain.tv_sec += tremain.tv_usec / 1000000L; > tremain.tv_usec %= 1000000L; > TIMEVAL_TO_TIMESPEC(&tremain, rem) > > if (rc < 0) { > rc = -1; > errno = saverrno; > } > return(rc); > } > > -- > Darren Tucker (dtucker at zip.com.au) > GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Tue Mar 18 11:51:29 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 11:51:29 +1100 Subject: nanosleep() replacement Take 2 References: Message-ID: <3E766D91.723E2A52@zip.com.au> Tim Rice wrote: Combining replies here, [about my modified nanosleep] > Something isn't quite right with this version. > When I try this I get > scp -l 512 openssh/sshd.o uw711:/tmp > sshd.o 100% 84KB 84.1KB/s 00:01 > scp -l 256 openssh/sshd.o uw711:/tmp > sshd.o 100% 84KB 42.0KB/s 00:02 > scp -l 128 openssh/sshd.o uw711:/tmp > sshd.o 100% 84KB 42.0KB/s 00:02 > scp -l 64 openssh/sshd.o uw711:/tmp > sshd.o 100% 84KB 42.0KB/s 00:02 > scp -l 8 openssh/sshd.o uw711:/tmp > sshd.o 100% 84KB 42.0KB/s 00:02 > scp -l 1 openssh/sshd.o uw711:/tmp > sshd 100% 84KB 42.0KB/s 00:02 Difference in select() behaviour between patforms? Here's what I get from the same function on Solaris 8: $ for bw in 512 256 128 64 8 1; do scp -l $bw testfile localhost:/tmp/; done + scp -l 512 testfile localhost:/tmp/ testfile 100% 84KB 80.6KB/s 00:01 + scp -l 256 testfile localhost:/tmp/ testfile 100% 84KB 41.0KB/s 00:02 + scp -l 128 testfile localhost:/tmp/ testfile 100% 84KB 20.7KB/s 00:04 + scp -l 64 testfile localhost:/tmp/ testfile 100% 84KB 9.2KB/s 00:09 + scp -l 8 testfile localhost:/tmp/ testfile 100% 84KB 1.1KB/s 01:16 + scp -l 1 testfile localhost:/tmp/ testfile 57% 48KB 0.1KB/s - stalled [snip] About the original function: > +int nanosleep(const struct timespec *req, struct timespec *rem) > +{ > + int rc, saverrno; > + extern int errno; > + struct timeval tsave, ttmp, time2wait; > + > + TIMESPEC_TO_TIMEVAL(&time2wait, req) > + > + gettimeofday(&tsave, NULL); > + rc = select(0, NULL, NULL, NULL, &time2wait); > + if (rc == -1) { > + saverrno = errno; > + gettimeofday (&ttmp, NULL); > + errno = saverrno; The following can sometimes end up with a tv_usec above 1,000,000 (not sure if that matters). Consider this example: tsave: tv_sec=100, tv_usec=999999 ttmp: tv_sec=101, tv_usec=1 time2wait: tv_sec=2, tv_usec=999999 > + ttmp.tv_sec -= tsave.tv_sec; > + ttmp.tv_usec -= tsave.tv_usec; -> ttmp.tv_usec = -999,998 > + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); > + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); -> tsave.tv_usec = 999,999 - -999,998 = 1,999,997 > + if(tsave.tv_sec < 0){ > + tsave.tv_sec = 0; > + tsave.tv_usec += 1000000L; > + } How about something like: if (rc == -1) { tsave.tv_sec = ttmp.tv_sec - tsave.tv_sec - time2wait.tv_sec; tsave.tv_usec = ttmp.tv_usec - tsave.tv_usec - time2wait.tv_usec; tsave.tv_sec += tsave.tv_usec / 1000000L; tsave.tv_usec %= 1000000L; } else { tsave.tv_sec = 0; tsave.tv_usec = 0; } > + } > + else { " } else {" ? > + tsave.tv_sec = 0; > + tsave.tv_usec = 0; > + } > + TIMEVAL_TO_TIMESPEC(&tsave, rem) > + > + return(rc); > +} -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Mar 18 11:59:33 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 11:59:33 +1100 Subject: nanosleep() replacement Take 2 References: Message-ID: <3E766F75.365F419A@zip.com.au> Ben Lindstrom wrote: > Mostly -l was designed to allow people to restrict their scp so it does > not take over their bandwidth (mainly dialup and low-end DSL). The > example was given was a long download that you don't care when it > finishes, just you don't want to choke your small pipe while doing it. > > So I doubt it being 100% perfect is a major deal on some platforms. I know, but a major variance is an indication of some problem in the nanosleep function and in future someone might use nanosleep where timing matters. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Mar 18 12:36:42 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 12:36:42 +1100 Subject: nanosleep() replacement Take 2 References: <3E766D91.723E2A52@zip.com.au> Message-ID: <3E76782A.87586272@zip.com.au> Darren Tucker wrote: > Difference in select() behaviour between patforms? [snip] Nothing so exotic, just some bugs (sigh). The version I tested had "if (rc < 0) errno=EINTR" and the arithmetic for the remainder was just plain wrong. This returned a negative remainder which caused select to fail next time round with invalid paramters, which the function converted into errno=EINTR. Amazingly, this worked! The following works better for me. -Daz. int nanosleep(const struct timespec *req, struct timespec *rem) { int rc, saverrno; extern int errno; struct timeval tstart, tstop, tremain, time2wait; TIMESPEC_TO_TIMEVAL(&time2wait, req) gettimeofday(&tstart, NULL); rc = select(0, NULL, NULL, NULL, &time2wait); saverrno = errno; gettimeofday (&tstop, NULL); if (rc == -1) { tremain.tv_sec = time2wait.tv_sec - (tstop.tv_sec - tstart.tv_sec); tremain.tv_usec = time2wait.tv_usec - (tstop.tv_usec - tstart.tv_usec); tremain.tv_sec += tremain.tv_usec / 1000000L; tremain.tv_usec %= 1000000L; } else { tremain.tv_sec = 0; tremain.tv_usec = 0; } TIMEVAL_TO_TIMESPEC(&tremain, rem) if (rc == -1) errno = saverrno; return(rc); } -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Tue Mar 18 13:06:10 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 18:06:10 -0800 (PST) Subject: nanosleep() replacement Take 2 In-Reply-To: <3E76782A.87586272@zip.com.au> References: <3E766D91.723E2A52@zip.com.au> <3E76782A.87586272@zip.com.au> Message-ID: On Tue, 18 Mar 2003, Darren Tucker wrote: > Darren Tucker wrote: > > Difference in select() behaviour between patforms? > [snip] > > Nothing so exotic, just some bugs (sigh). > > The version I tested had "if (rc < 0) errno=EINTR" and the arithmetic > for the remainder was just plain wrong. This returned a negative > remainder which caused select to fail next time round with invalid > paramters, which the function converted into errno=EINTR. Amazingly, > this worked! > > The following works better for me. Works better here too. But I think we should have saverrno = errno; gettimeofday (&tstop, NULL); errno = saverrno; inside of if (rc == -1) { and get rid of the second if (rc == -1) (that's how I tested it) > > -Daz. > > int nanosleep(const struct timespec *req, struct timespec *rem) > { > int rc, saverrno; > extern int errno; > struct timeval tstart, tstop, tremain, time2wait; > > TIMESPEC_TO_TIMEVAL(&time2wait, req) > gettimeofday(&tstart, NULL); > rc = select(0, NULL, NULL, NULL, &time2wait); > saverrno = errno; > gettimeofday (&tstop, NULL); > > if (rc == -1) { > tremain.tv_sec = time2wait.tv_sec - (tstop.tv_sec - > tstart.tv_sec); > tremain.tv_usec = time2wait.tv_usec - (tstop.tv_usec - > tstart.tv_usec); > tremain.tv_sec += tremain.tv_usec / 1000000L; > tremain.tv_usec %= 1000000L; > } else { > tremain.tv_sec = 0; > tremain.tv_usec = 0; > } > TIMEVAL_TO_TIMESPEC(&tremain, rem) > > if (rc == -1) > errno = saverrno; > return(rc); > } > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Tue Mar 18 13:26:07 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Mar 2003 13:26:07 +1100 Subject: nanosleep() replacement Take 2 References: <3E766D91.723E2A52@zip.com.au> <3E76782A.87586272@zip.com.au> Message-ID: <3E7683BF.CC1307AC@zip.com.au> Tim Rice wrote: > But I think we should have > saverrno = errno; > gettimeofday (&tstop, NULL); > errno = saverrno; > inside of if (rc == -1) { > and get rid of the second if (rc == -1) > (that's how I tested it) I thought about that (and tried it, it works fine) but wasn't sure. It's certainly neater and it's fine by me. Is there any chance of TIMEVAL_TO_TIMESPEC() ever messing with errno? -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Tue Mar 18 13:51:37 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 18:51:37 -0800 (PST) Subject: nanosleep() replacement Take 2 In-Reply-To: <3E7683BF.CC1307AC@zip.com.au> References: <3E766D91.723E2A52@zip.com.au> <3E76782A.87586272@zip.com.au> <3E7683BF.CC1307AC@zip.com.au> Message-ID: On Tue, 18 Mar 2003, Darren Tucker wrote: > > Is there any chance of TIMEVAL_TO_TIMESPEC() ever messing with errno? No, it's a macro in defines.h -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Tue Mar 18 14:30:43 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 17 Mar 2003 21:30:43 -0600 (CST) Subject: This release or next. Message-ID: I think we need to revisit the whole 64bit integer support. It has crept from sftp over to scp now. And I think we are at a point where [..] # If we don't have int64_t then we can't compile sftp-server. So don't # even attempt to do it. if test "x$ac_cv_have_int64_t" = "xno" -a \ "x$ac_cv_sizeof_long_int" != "x8" -a \ "x$ac_cv_sizeof_long_long_int" = "x0" ; then NO_SFTP='#' else should be changed to state 'Your platform is not supported with your current compile.' I don't think the scp.c can be done without 32bit without fear of overflowing down the road. Other than sco w/out gcc. What platforms does this affect? If it is just sco. I really believe we need to make this move. - Ben From tim at multitalents.net Tue Mar 18 14:58:28 2003 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Mar 2003 19:58:28 -0800 (PST) Subject: This release or next. In-Reply-To: References: Message-ID: On Mon, 17 Mar 2003, Ben Lindstrom wrote: > > I think we need to revisit the whole 64bit integer support. [snip] > should be changed to state 'Your platform is not supported with your > current compile.' > > I don't think the scp.c can be done without 32bit without fear of > overflowing down the road. Fortunately it only affects the -l (bandwidth limit) option now. > > Other than sco w/out gcc. What platforms does this affect? If it is just > sco. I really believe we need to make this move. > > - Ben Any UnixWare < 7.0.0 But gcc is probably easily available for those. I'm OK with making this move. Doesn't anyone know of any code out there for using 64bit data types on machines that only support 32bit data types? But then it would have to be available under BSD license too. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vdanen at linsec.ca Tue Mar 18 15:43:26 2003 From: vdanen at linsec.ca (Vincent Danen) Date: Mon, 17 Mar 2003 21:43:26 -0700 Subject: restricing port forwarding ports server-side In-Reply-To: <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> References: <20030315002822.GH11985@mandrakesoft.com> <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> Message-ID: <20030318044326.GU4797@mandrakesoft.com> On Sat Mar 15, 2003 at 09:39:43AM +0100, Florian Weimer wrote: > > I know the book is a little dated, but has anything like this > > appeared in openssh yet? > > We've got a proof-of-concept implementation of global and per-user > port forwarding control. We don't use it anymore, so the patches are > still against 3.4p1, and they aren't thoroughly tested. > > Sounds like a good starter, but I can't seem to get anything off of this page... -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030317/ed5c7f4d/attachment.bin From vdanen at mandrakesoft.com Tue Mar 18 15:44:39 2003 From: vdanen at mandrakesoft.com (Vincent Danen) Date: Mon, 17 Mar 2003 21:44:39 -0700 Subject: restricing port forwarding ports server-side In-Reply-To: <3E733213.8080306@mindrot.org> References: <20030315002822.GH11985@mandrakesoft.com> <877kb110s0.fsf@Login.CERT.Uni-Stuttgart.DE> <3E733213.8080306@mindrot.org> Message-ID: <20030318044439.GV4797@mandrakesoft.com> On Sun Mar 16, 2003 at 01:00:51AM +1100, Damien Miller wrote: > >>I know the book is a little dated, but has anything like this > >>appeared in openssh yet? > > > > > >We've got a proof-of-concept implementation of global and per-user > >port forwarding control. We don't use it anymore, so the patches are > >still against 3.4p1, and they aren't thoroughly tested. > > > > > > See also my even older KeyNote policy patches (check the archives). I'll > probably revive them post-3.6. Ok, I'll go digging through the archives. Sounds intriguing. =) -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030317/29432931/attachment.bin From vdanen at mandrakesoft.com Tue Mar 18 15:57:06 2003 From: vdanen at mandrakesoft.com (Vincent Danen) Date: Mon, 17 Mar 2003 21:57:06 -0700 Subject: restricing port forwarding ports server-side In-Reply-To: References: <20030315002822.GH11985@mandrakesoft.com> Message-ID: <20030318045706.GW4797@mandrakesoft.com> On Sat Mar 15, 2003 at 02:50:27PM +0000, Tony Finch wrote: > >I'm curious as to whether or not there is a way to restrict forwarded ports > >server side. For instance, I'm running an IRC server and am allowing users > >to connect via ssh forwarding (so I can take advantange of using openssh's > >public key method for authentication). Each client I tell to setup their > >~/.ssh/config in a certain way, but the relevant line is: > > > >LocalForward 6667 localhost:42000 > > > >where port 42000 is what ircd is listening to on the server. This works > >great, but my concern is a user changing this to localhost:3306 to gain > >access to MySQL, which is firewalled off. > > You can do this with my restricted-environment patch using appropriate > PermitTcpConnect options. > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=104387691708672 Very nice! This may be exactly what I'm looking for. The other options look pretty useful as well. Thanks! -- MandrakeSoft Security; http://www.mandrakesecure.net/ Online Security Resource Book; http://linsec.ca/ "lynx -source http://linsec.ca/vdanen.asc | gpg --import" {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030317/fab0993d/attachment.bin From gert at greenie.muc.de Tue Mar 18 19:06:43 2003 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 18 Mar 2003 09:06:43 +0100 Subject: This release or next. In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Mar 17, 2003 at 09:30:43PM -0600 References: Message-ID: <20030318090643.Y4402@greenie.muc.de> Hi, On Mon, Mar 17, 2003 at 09:30:43PM -0600, Ben Lindstrom wrote: > Other than sco w/out gcc. What platforms does this affect? If it is just > sco. I really believe we need to make this move. At least for SCO, requiring gcc would be fine. The original SCO CC is braindead anyway. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From goudal at enseirb.fr Tue Mar 18 19:21:04 2003 From: goudal at enseirb.fr (goudal at enseirb.fr) Date: Tue, 18 Mar 2003 09:21:04 +0100 Subject: Logging sessions. Message-ID: <200303180821.h2I8L5iB017458@artcore.enseirb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii -------- Hello, I upgraded to the last openssh and I have found the followin problem : it is not possible in the logs to match the end of a session with the begining. In the previous versions, with no secure separation, the pid found in syslog could do the job, but now the opening and closing processes are different. I have done an horrible hack to get the info : I have added the print of the ppid in the closing messages, as it appears that the closing process is the son of the opening one. But it's juste an hack. I imagine that this modification does not add a security problem. Could it be possible to attache an id to each session so that it is possible to match opening and closing event ? Or is there an hidden problem that I have not seen ? f.g. From bugzilla-daemon at mindrot.org Tue Mar 18 20:49:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 20:49:43 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030318094943.BD6A894210@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 ------- Additional Comments From dtucker at zip.com.au 2003-03-18 20:49 ------- Currently sshd checks for password/account expiry very early in the login process (before the authentication methods are negotiated, in auth.c:allowed_user()) so it's probably not a trivial change to omit this check for public-key authentication only. I don't think it's a good idea to do this even if it was easy. (Note that I didn't think the AIX rlogin thing was a good idea at first either :-) AIX currently does this (doesn't expire passwords via SSH password or public-key) and I'm trying to get that *fixed*. It's OK until you need to get in some way other than ssh (eg sshd is broken or you're at the console) then you're screwed. Also note that on Solaris cron jobs will fail for accounts with expired passwords (on Solaris 8 you get "! bad user (testuser)..." on cron's log). If you don't want password expiry, don't enable it for those accounts. If you must have it enabled, set the password to something random (eg "openssl rand 6 | mimencode | autopasswd batchaccount") once per month via cron :-). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 18 23:00:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 18 Mar 2003 23:00:27 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030318120027.EDE1094212@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 ------- Additional Comments From jim.a.davidson at bt.com 2003-03-18 23:00 ------- What you are saying makes good sense.Thanks for your assistance,I will make these account passwords non expirable and also locked which should keep our security people happy. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From wendyp at cray.com Wed Mar 19 02:31:58 2003 From: wendyp at cray.com (Wendy Palm) Date: Tue, 18 Mar 2003 09:31:58 -0600 Subject: nanosleep() replacement Take 2 References: Message-ID: <3E773BEE.3090102@cray.com> ok, i finally got it to compile. i'm still having that limit variable problem with bwlimit() in scp.c (unicos and unicos/mk machines have a function limit() defined in resources.h) i'm currently testing the latest version tim sent me and all looks good so far. Tim Rice wrote: > After Darren noticed a couple of problems, I've made a few changes. > > I'd like to hear from Wendy if this works on cray. > > Thanks for all the input. > > -------------< cut >---------------- > --- openssh/configure.ac.old 2003-03-09 17:16:43.000000000 -0800 > +++ openssh/configure.ac 2003-03-16 15:38:28.520560008 -0800 > @@ -1483,6 +1483,8 @@ > have_struct_timeval=1 > fi > > +AC_CHECK_TYPES(struct timespec) > + > # If we don't have int64_t then we can't compile sftp-server. So don't > # even attempt to do it. > if test "x$ac_cv_have_int64_t" = "xno" -a \ > --- openssh/openbsd-compat/bsd-misc.c.old 2003-01-19 19:21:01.000000000 -0800 > +++ openssh/openbsd-compat/bsd-misc.c 2003-03-17 14:02:20.905600005 -0800 > @@ -135,3 +135,38 @@ > } > #endif > > +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) > +int nanosleep(const struct timespec *req, struct timespec *rem) > +{ > + int rc, saverrno; > + extern int errno; > + struct timeval tsave, ttmp, time2wait; > + > + TIMESPEC_TO_TIMEVAL(&time2wait, req) > + > + gettimeofday(&tsave, NULL); > + rc = select(0, NULL, NULL, NULL, &time2wait); > + if (rc == -1) { > + saverrno = errno; > + gettimeofday (&ttmp, NULL); > + errno = saverrno; > + ttmp.tv_sec -= tsave.tv_sec; > + ttmp.tv_usec -= tsave.tv_usec; > + tsave.tv_sec = (time2wait.tv_sec - ttmp.tv_sec); > + tsave.tv_usec = (time2wait.tv_usec - ttmp.tv_usec); > + if(tsave.tv_sec < 0){ > + tsave.tv_sec = 0; > + tsave.tv_usec += 1000000L; > + } > + } > + else { > + tsave.tv_sec = 0; > + tsave.tv_usec = 0; > + } > + TIMEVAL_TO_TIMESPEC(&tsave, rem) > + > + return(rc); > +} > + > +#endif > + > --- openssh/openbsd-compat/bsd-misc.h.old 2002-06-20 20:35:30.000000000 -0700 > +++ openssh/openbsd-compat/bsd-misc.h 2003-03-16 15:32:29.850560003 -0800 > @@ -80,5 +80,14 @@ > int setgroups(size_t size, const gid_t *list); > #endif > > +#if !defined(HAVE_NANOSLEEP) && !defined(HAVE_NSLEEP) > +#ifndef HAVE_STRUCT_TIMESPEC > +struct timespec { > + time_t tv_sec; > + long tv_nsec; > +}; > +#endif > +int nanosleep(const struct timespec *req, struct timespec *rem); > +#endif > > #endif /* _BSD_MISC_H */ > -------------< end cut >---------------- > > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From mouring at etoh.eviladmin.org Wed Mar 19 06:00:19 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 18 Mar 2003 13:00:19 -0600 (CST) Subject: Call for testing for 3.6 In-Reply-To: <3E6F93B6.5000500@cray.com> Message-ID: On Wed, 12 Mar 2003, Wendy Palm wrote: > cray is broken also wrt nanosleep(). > > additionally, there's a stupid locality error that cray is having a problem with in scp.c. > > a variable "limit" has been added at line 99. > this causes an incompatible declaration with cray's limit function defined in /usr/include/sys/resource.h > which is included in includes.h. > Below is the patch I'm planing on commiting to the portable tree here soon (and hopefully upstream if there is no complaints). Index: scp.c =================================================================== RCS file: /var/cvs/openssh/scp.c,v retrieving revision 1.109 diff -u -r1.109 scp.c --- scp.c 10 Mar 2003 00:21:18 -0000 1.109 +++ scp.c 18 Mar 2003 18:36:10 -0000 @@ -96,7 +96,7 @@ arglist args; /* Bandwidth limit */ -off_t limit = 0; +off_t limitbw = 0; /* Name of current file being transferred. */ char *curfile; @@ -251,7 +251,7 @@ speed = strtod(optarg, &endp); if (speed <= 0 || *endp != '\0') usage(); - limit = speed * 1024; + limitbw = speed * 1024; break; case 'p': pflag = 1; @@ -594,7 +594,7 @@ haderr = result >= 0 ? EIO : errno; statbytes += result; } - if (limit) + if (limitbw) bwlimit(amt); } if (showprogress) @@ -688,7 +688,7 @@ return; lamt *= 8; - wait = (double)1000000L * lamt / limit; + wait = (double)1000000L * lamt / limitbw; bwstart.tv_sec = wait / 1000000L; bwstart.tv_usec = wait % 1000000L; @@ -917,7 +917,7 @@ statbytes += j; } while (amt > 0); - if (limit) + if (limitbw) bwlimit(4096); if (count == bp->cnt) { From tim at multitalents.net Wed Mar 19 06:16:34 2003 From: tim at multitalents.net (Tim Rice) Date: Tue, 18 Mar 2003 11:16:34 -0800 (PST) Subject: nanosleep() replacement Take 2 In-Reply-To: <3E773BEE.3090102@cray.com> References: <3E773BEE.3090102@cray.com> Message-ID: I've commited the nanosleep() bits to CVS. Thanks to all for testing/feedback. On Tue, 18 Mar 2003, Wendy Palm wrote: > ok, i finally got it to compile. i'm still having that limit variable problem with bwlimit() in > scp.c (unicos and unicos/mk machines have a function limit() defined in resources.h) > > i'm currently testing the latest version tim sent me and all looks good so far. > [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From hayward at slothmud.org Wed Mar 19 07:42:17 2003 From: hayward at slothmud.org (hayward at slothmud.org) Date: Tue, 18 Mar 2003 14:42:17 -0600 (CST) Subject: Enable RSA blinding In-Reply-To: <20030318202202.15737.13061.Mailman@shitei.mindrot.org> Message-ID: > Florian Weimer wrote: >>> After browsing "Remote timing attacks are practical" (Boneh & Brumley, >> > ), I >> > wonder if it might be a good idea to add calls to RSA_blinding_on() >> > before the OpenSSL RSA decryption routines are invoked. >> >> It is on in the snapshots as of tonight (thank Markus). >> >Ia saw that.. I'm still interested in a break down to where OpenSSH would >be prone to such attacks. I'm sure v1 would easily be, but thecomplexity >of v2 makes me wonder. Still better be safe than sorry. I am interested in this as well. It seems like the attacker has to be able to communicate to the server with it's public key for quite some time before it can determine the private key used by the server. My understanding is that with SSH2, each session gets a different public/private key pair. Wouldn't this mean that the only private key an attacker could ever figure out is the key that allows the attacker to decrypt the data they themselves encrypted? I'm not an expert, I'm hoping someone who is an expert would comment on this topic. Thanks, Brian Hayward From bugzilla-daemon at mindrot.org Wed Mar 19 08:19:08 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 08:19:08 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030318211908.4949594210@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 ------- Additional Comments From dtucker at zip.com.au 2003-03-19 08:19 ------- I suggest using the no-password string "*NP*" in the password field to disable password authentication as the Solaris system accounts do, rather than locking the account with passwd -l. OpenSSH currently allows public-key logins to locked accounts on some platforms, including Solaris, but this may change in future (see bug #442). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 19 10:49:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 10:49:27 +1100 (EST) Subject: [Bug 513] mods for configuring for new cray architecture Message-ID: <20030318234927.05B0C94220@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=513 Summary: mods for configuring for new cray architecture Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wendyp at cray.com cray's new architecture to add to config.guess and config.sub. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 19 10:56:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 10:56:13 +1100 (EST) Subject: [Bug 513] mods for configuring for new cray architecture Message-ID: <20030318235613.A75C99429E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=513 ------- Additional Comments From wendyp at cray.com 2003-03-19 10:56 ------- Created an attachment (id=250) --> (http://bugzilla.mindrot.org/attachment.cgi?id=250&action=view) patch for new cray architecture ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 19 10:56:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 10:56:45 +1100 (EST) Subject: [Bug 513] mods for configuring for new cray architecture Message-ID: <20030318235645.7E87A94294@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=513 ------- Additional Comments From wendyp at cray.com 2003-03-19 10:56 ------- Created an attachment (id=251) --> (http://bugzilla.mindrot.org/attachment.cgi?id=251&action=view) config.sub patch for new cray architecture ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 19 11:00:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 11:00:16 +1100 (EST) Subject: [Bug 514] error in openbsd-compat/bsd-cray.h Message-ID: <20030319000016.A98E2942B2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=514 Summary: error in openbsd-compat/bsd-cray.h Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wendyp at cray.com i made an error when i sent in a previous patch - please apply this one to the current tree. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 19 11:01:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 19 Mar 2003 11:01:55 +1100 (EST) Subject: [Bug 514] error in openbsd-compat/bsd-cray.h Message-ID: <20030319000155.9775394289@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=514 ------- Additional Comments From wendyp at cray.com 2003-03-19 11:01 ------- Created an attachment (id=252) --> (http://bugzilla.mindrot.org/attachment.cgi?id=252&action=view) bsd-cray.h patch for t3e machines the ttold.h file isn't on t3e machines and i somehow missed it when i sent it in before. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From imacat at mail.imacat.idv.tw Wed Mar 19 16:04:24 2003 From: imacat at mail.imacat.idv.tw (imacat) Date: Wed, 19 Mar 2003 13:04:24 +0800 Subject: Agent Socket Directory Message-ID: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> Dear All, Is it possible to move agent sockets to directories other than /tmp? For ex., move to /var/run/ssh? I don't know if anyone has asked for this before. I'm asking this because according to the current FHS 2.2 (http://www.pathname.com/fhs/), PID files and sockets should always go to /var/run. I understand that it is not possible for an ordinary user to write to /var/run, but it is possible to create a subdirectory under /var/run that has the permission of 1777. Besides, I hate to see a lot of annoying things in /tmp. It affects my judgements on suspicious files hackers may create at /tmp. I know ssh-agent can set a custom socket location, but not sshd on the target machine. It is hardcoded in session.c. Also ssh-agent's default socket directory is also hardcoded. It's troublesome to safely change the socket location for all the users. I have tried to make a patch myself to change the socket directory to /var/run/ssh from the source, but I don't think this is a good answer. It should be set in ssh_config and sshd_config, or at least when running configure. Is there a plan to set the socket directory a configurable option? Or is there any reason not to do this? As far as I can tell from the source, it uses a safe OpenBSD strlcpy() to set the socket directory. It should not be too hard to make it configurable (although it may be strange to the users if the directory is truncated due to system limit). I can make a patch to configure.in to do this, with a little time, but I don't know how to make it in the configuration files ssh_config and sshd_config. Is there any suggestion from you developers? Thank you for your patience for this. -- imacat ^_*' imacat at mail.imacat.idv.tw PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Tavern IMACAT's http://www.imacat.idv.tw/ Woman's Voice http://www.wov.idv.tw/ TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030319/8e109c12/attachment.bin From maniac at maniac.nl Wed Mar 19 21:33:15 2003 From: maniac at maniac.nl (Mark Janssen) Date: 19 Mar 2003 11:33:15 +0100 Subject: Agent Socket Directory In-Reply-To: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> References: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> Message-ID: <1048069995.21036.5.camel@shuttle> On Wed, 2003-03-19 at 06:04, imacat wrote: > Is it possible to move agent sockets to directories other than /tmp? > For ex., move to /var/run/ssh? ... > PID files and sockets should always go to /var/run. I understand that > it is not possible for an ordinary user to write to /var/run, but it is > possible to create a subdirectory under /var/run that has the permission > of 1777. Besides, I hate to see a lot of annoying things in /tmp. It Isn't that just moving the problem (to /var/run) and making it bigger in the process, since there will then be _another_ world writable directory, and in /var this time. I'd rather have only 1 world writable directory, /tmp, which I can put in it's own filesystem. -- Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl From mike at enoch.org Thu Mar 20 01:17:43 2003 From: mike at enoch.org (Mike Johnson) Date: Wed, 19 Mar 2003 09:17:43 -0500 Subject: TMPDIR for agent socket? Message-ID: <20030319141743.GB1226@enoch.org> On the subject of moving the directory for the agent socket, is there any reason this couldn't be changed to support $TMPDIR? That would allow people to put the agent socket directory wherever they wanted. I see the -a option, but wouldn't $TMPDIR (to specify the directory in which the agent socket directory would be created) be easier (yes, I'm lazy)? Mike -- "If life hands you lemons, YOU BLOW THOSE LEMONS TO BITS WITH YOUR LASER CANNONS!" -- Brak GNUPG Key fingerprint = ACD2 2F2F C151 FB35 B3AF C821 89C4 DF9A 5DDD 95D1 GNUPG Key = http://www.enoch.org/mike/mike.pubkey.asc From Darren.Moffat at Sun.COM Thu Mar 20 02:23:27 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Wed, 19 Mar 2003 07:23:27 -0800 (PST) Subject: Agent Socket Directory In-Reply-To: <1048069995.21036.5.camel@shuttle> References: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> <1048069995.21036.5.camel@shuttle> Message-ID: On Wed, 19 Mar 2003, Mark Janssen wrote: > On Wed, 2003-03-19 at 06:04, imacat wrote: > > Is it possible to move agent sockets to directories other than /tmp? > > For ex., move to /var/run/ssh? > ... > > PID files and sockets should always go to /var/run. I understand that > > it is not possible for an ordinary user to write to /var/run, but it is > > possible to create a subdirectory under /var/run that has the permission > > of 1777. Besides, I hate to see a lot of annoying things in /tmp. It > > Isn't that just moving the problem (to /var/run) and making it bigger in > the process, since there will then be _another_ world writable > directory, and in /var this time. I'd rather have only 1 world writable > directory, /tmp, which I can put in it's own filesystem. Also the whole point of /var/run is that is it not world writeable and is not intended for random user temp files and sync points. /var/run is intended for system services (system lock files, doors, AF_UNIX sockets) not user stuff. ssh-agent runs as the user not as any priveleged account. -- Darren J Moffat From bugzilla-daemon at mindrot.org Thu Mar 20 04:00:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 20 Mar 2003 04:00:42 +1100 (EST) Subject: [Bug 510] corrupted mac address disconnecting Message-ID: <20030319170042.AD1349424F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=510 ------- Additional Comments From cjwatson at debian.org 2003-03-20 04:00 ------- I think what he actually means is "Corrupted MAC on input" - i.e. Message Authentication Code, not Media Access Control. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From linux_4ever at yahoo.com Thu Mar 20 05:39:07 2003 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 19 Mar 2003 10:39:07 -0800 (PST) Subject: cvs version / testing Message-ID: <20030319183907.12350.qmail@web9603.mail.yahoo.com> Hello, I pulled the latest from cvs today and ran several tests and added more options to the CFLAGS in the Makefile. To start with, I ran valgrind against sshd & it comes up with this: ==24959== 112 bytes in 1 blocks are definitely lost in loss record 297 of 310 ==24959== at 0x40164650: malloc (vg_clientfuncs.c:100) ==24959== by 0x807A0D1: compat_init_setproctitle (setproctitle.c:236) ==24959== by 0x804D606: main (sshd.c:839) ==24959== by 0x403444CD: __libc_start_main (in /lib/libc-2.2.93.so) ==24959== by 0x804C4E0: (within /opt/openssh/sshd) ==24959== ==24959== LEAK SUMMARY: ==24959== definitely lost: 112 bytes in 1 blocks. ==24959== possibly lost: 0 bytes in 0 blocks. ==24959== still reachable: 8532 bytes in 340 blocks. ==24959== suppressed: 0 bytes in 0 blocks. ==24959== Reachable blocks (those to which a pointer was found) are not shown. ==24959== To see them, rerun with: --show-reachable=yes This occurs several times in the output. Next, I ran env_audit against the deamon. The stdin, stdout, & stderr descriptors have changed since version 3.5p1. This is what env_audit finds: Open file descriptor: 0 User ID of File Owner: root Group ID of File Owner: root Descriptor is stdin. No controlling terminal File type: socket Address Family: AF_INET Local address: 192.168.3.30 Local Port: 1, tcpmux NOTICE - connected to a privileged port Peer address: 192.168.3.30 Peer Port: 55290 Now, the local side binds to port 1, which is tcpmux's service port. What happens if someone wanted to so something like this: ssh -l me localhost "telnet localhost tcpmux < command_file" I don't know how often someone would want to do that or run an application that accesses tcpmux remotely, but by using pipes, this problem never existed. If sockets are the way to go, it might be better to use a port higher up/ephemeral so that no service is blocked. I also added -W -Wshadow and found many more places that variables shadow function names. The worst ones were rand & socket. Rather than list them here, you can just add -Wshaow to find them. The last thing, flexelint says that line 207 of vis.c has an assignment of auto variable to outerscope symbol dst. I looked at it and I'm not sure its a problem, but I'd rather pass it along just in case. Hope you find this feedback useful. -Steve Grubb __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From linux_4ever at yahoo.com Thu Mar 20 06:16:46 2003 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 19 Mar 2003 11:16:46 -0800 (PST) Subject: cvs version / testing Message-ID: <20030319191646.45244.qmail@web9607.mail.yahoo.com> Hello, The tcpmux report was a mistake on my part, please ignore that part of the e-mail. I also have some more memory leaks to share from a longer valgrind session: ==31863== 1 bytes in 1 blocks are definitely lost in loss record 1 of 387 ==31863== at 0x40164650: malloc (vg_clientfuncs.c:100) ==31863== by 0x8070044: xmalloc (xmalloc.c:28) ==31863== by 0x80633D9: buffer_get_string (bufaux.c:230) ==31863== by 0x805C6A2: mm_answer_keyallowed (monitor.c:777) ==31863== by 0x805BE89: monitor_read (monitor.c:371) ==31863== by 0x805BB9E: monitor_child_preauth (monitor.c:280) ==31863== by 0x804CF97: privsep_preauth (sshd.c:600) ==31863== by 0x804DEFE: main (sshd.c:1532) ==31863== AND this one: ==31863== 4 bytes in 1 blocks are definitely lost in loss record 6 of 387 ==31863== at 0x40164B3D: calloc (vg_clientfuncs.c:242) ==31863== by 0x4022D162: _copy_env (in /lib/libpam.so.0.75) ==31863== by 0x414348F7: ??? ==31863== by 0x41433D0D: ??? ==31863== by 0x4022ABA8: _pam_dispatch_aux (in /lib/libpam.so.0.75) ==31863== by 0x4022AD32: _pam_dispatch (in /lib/libpam.so.0.75) ==31863== by 0x4022C997: pam_close_session (in /lib/libpam.so.0.75) ==31863== by 0x80613E1: do_pam_cleanup_proc (auth-pam.c:183) These two leaks occur over and over. Hope this helps & sorry for the confusion about tcpmux. -Steev Grubb __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From tim at mcgarry.ch Thu Mar 20 08:58:59 2003 From: tim at mcgarry.ch (Tim McGarry) Date: Wed, 19 Mar 2003 22:58:59 +0100 Subject: Agent Socket Directory References: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> <1048069995.21036.5.camel@shuttle> Message-ID: <006c01c2ee62$bfde0740$ce02a8c0@opf.swissbank.com> I like the idea of using /var/run it's definately where it _should_ be. But, /tmp has already been used for some time and I see no actual advantage in changing it at this stage, so leave it where it always was. One email on this subject suggested using $TMPDIR, what a bad idea, if people are given the choice, at least some of them will choose a place that isn't safe. The one thing I'd like to see is support for defining where an agent gets forwarded to, or perhaps supporting some way of making sure it gets created at the same place as the last session (eg convert the socket to a normal file on exit, an then back to a socket the next time the user connects with a forwarded agent) , this would be particularly useful when forwarding the agent to a host, starting a bunch of stuff (eg screen/vnc sessions) and then disconnecting/reconnecting repeatably. I do this with VNC and have been forced to write a script to create hard links with the appropriate permissions from where the agent was before, to where it is now. Tim McGarry. ----- Original Message ----- From: "Mark Janssen" To: "imacat" Cc: Sent: Wednesday, March 19, 2003 11:33 AM Subject: Re: Agent Socket Directory > On Wed, 2003-03-19 at 06:04, imacat wrote: > > Is it possible to move agent sockets to directories other than /tmp? > > For ex., move to /var/run/ssh? > ... > > PID files and sockets should always go to /var/run. I understand that > > it is not possible for an ordinary user to write to /var/run, but it is > > possible to create a subdirectory under /var/run that has the permission > > of 1777. Besides, I hate to see a lot of annoying things in /tmp. It > > Isn't that just moving the problem (to /var/run) and making it bigger in > the process, since there will then be _another_ world writable > directory, and in /var this time. I'd rather have only 1 world writable > directory, /tmp, which I can put in it's own filesystem. > > -- > Mark Janssen -- maniac(at)maniac.nl -- GnuPG Key Id: 357D2178 > Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT > Maniac.nl Unix-God.Net|Org MarkJanssen.org|nl SyConOS.com|nl > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus at openbsd.org Thu Mar 20 09:29:11 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 19 Mar 2003 23:29:11 +0100 Subject: cvs version / testing In-Reply-To: <20030319191646.45244.qmail@web9607.mail.yahoo.com> References: <20030319191646.45244.qmail@web9607.mail.yahoo.com> Message-ID: <20030319222911.GB16793@folly> On Wed, Mar 19, 2003 at 11:16:46AM -0800, Steve G wrote: > Hello, > > The tcpmux report was a mistake on my part, please ignore > that part of the e-mail. > > I also have some more memory leaks to share from a longer > valgrind session: > > ==31863== 1 bytes in 1 blocks are definitely lost in loss > record 1 of 387 > ==31863== at 0x40164650: malloc (vg_clientfuncs.c:100) > ==31863== by 0x8070044: xmalloc (xmalloc.c:28) > ==31863== by 0x80633D9: buffer_get_string (bufaux.c:230) > ==31863== by 0x805C6A2: mm_answer_keyallowed > (monitor.c:777) > ==31863== by 0x805BE89: monitor_read (monitor.c:371) > ==31863== by 0x805BB9E: monitor_child_preauth > (monitor.c:280) > ==31863== by 0x804CF97: privsep_preauth (sshd.c:600) > ==31863== by 0x804DEFE: main (sshd.c:1532) > ==31863== is this about the 'chost' in: chost = buffer_get_string(m, NULL); this variable gets freed in mm_answer_keyverify(). you could try this patch: Index: monitor.c =================================================================== RCS file: /cvs/openssh_cvs/monitor.c,v retrieving revision 1.36 diff -u -r1.36 monitor.c --- monitor.c 10 Mar 2003 00:21:18 -0000 1.36 +++ monitor.c 19 Mar 2003 22:30:07 -0000 @@ -298,6 +298,7 @@ authctxt->failures++; } } + monitor_reset_key_state(); if (!authctxt->valid) fatal("%s: authenticated invalid user", __func__); From linux_4ever at yahoo.com Thu Mar 20 09:44:10 2003 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 19 Mar 2003 14:44:10 -0800 (PST) Subject: cvs version / testing In-Reply-To: <20030319222911.GB16793@folly> Message-ID: <20030319224410.21114.qmail@web9601.mail.yahoo.com> Hello, The patch didn't fix it for me. You are right, it appears to be chost, but I think there are some paths through the mm_answer_keyallowed function that does not free the buffer or pass the variable to something that ultimately frees it. Its been my experience that lost memory means the pointer gets overwritten by another buffer pointer before the first is ever freed, thereby losing the reference -or- the pointer is local/automatic and is lost when the function returns. I'm just using password authentication if that helps find the path. -Steve Grubb __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From a_keaton at earthlink.net Wed Mar 19 13:43:11 2003 From: a_keaton at earthlink.net (A. Keaton) Date: Tue, 18 Mar 2003 18:43:11 -0800 Subject: would like to link to openssh.com Message-ID: openssh.com (OpenSSH) is ranked #38 for the keyword "secure server". I have a perfect match for your site and I think we should link to each other. This will do two things: 1 - help our users find relevant content 2 - help both our sites rank better in Google (this is an added bonus) Google doesn't just analyze the number of sites linked to you... they also look at how "important' the sites are that are linked to you. My site, is listed in Yahoo. This means that a link from my site will be weighted much heavier than links from other sites. (you can read more on how Google uses links to determine rank here: http://www.google.com/technology/index.html ) If you're interested, please reply and let me know. I'll send you all the info you need and I'll get your info as well. Thanks for your time... I know that this will be worthwhile for you and your site's visitors. Angela From a_keaton at earthlink.net Wed Mar 19 13:43:11 2003 From: a_keaton at earthlink.net (A. Keaton) Date: Tue, 18 Mar 2003 18:43:11 -0800 Subject: would like to link to openssh.com Message-ID: openssh.com (OpenSSH) is ranked #38 for the keyword "secure server". I have a perfect match for your site and I think we should link to each other. This will do two things: 1 - help our users find relevant content 2 - help both our sites rank better in Google (this is an added bonus) Google doesn't just analyze the number of sites linked to you... they also look at how "important' the sites are that are linked to you. My site, is listed in Yahoo. This means that a link from my site will be weighted much heavier than links from other sites. (you can read more on how Google uses links to determine rank here: http://www.google.com/technology/index.html ) If you're interested, please reply and let me know. I'll send you all the info you need and I'll get your info as well. Thanks for your time... I know that this will be worthwhile for you and your site's visitors. Angela From djm at mindrot.org Thu Mar 20 21:05:50 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Mar 2003 21:05:50 +1100 Subject: Agent Socket Directory In-Reply-To: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> References: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> Message-ID: <200303202105.51020.djm@mindrot.org> On Wed, 19 Mar 2003 04:04 pm, imacat wrote: > Dear All, > > Is it possible to move agent sockets to directories other than /tmp? > For ex., move to /var/run/ssh? No. /var/run is for _root_ owned sockets. You can specify a custom path for ssh-agent on the commandline if you wish. -d From wendyp at cray.com Thu Mar 20 10:40:16 2003 From: wendyp at cray.com (Wendy Palm) Date: Wed, 19 Mar 2003 17:40:16 -0600 Subject: Call for testing for 3.6 References: Message-ID: <3E78FFE0.4060102@cray.com> sorry to take so long with the testing. 3.6 version works great on crays using the 0315 snapshot, with tim's nanosleep replacement patch and the 3 cray patches i sent in yesterday. thanks, wendy Ben Lindstrom wrote: > We are heading into a lock here. So we need to get people to test their > respective platforms if they wish them to be supported out of the tar file. > > So if you have any patches you need to ensure your platform works speak > up. We are looking at a lock on the 17th. > > I believe I have an AIX/Cray patch and a Tru64 patch sitting in my mailbox > that I'll be looking at soon and more than likely commiting. I have no > clue what else is in my 400+ worth of email.=) > > I know NeXT platform is broken. Again, I make a call out to people left > in the NeXT community. If you want it working before 3.6 submit your > patches ASAP. If I hear no word I'll suggest it be phased out after this > release. > > I'd like to see more tinderbox setups (Darren, I'll be talking to you in > private, but I have a Sol9 box I'd like to add to the list soon). It > would help to know where we stand for broken platforms. > > For those new to this process asking themselves, "Where do I find these > test version?" > > http://www.openssh.com/portable.html#mirrors > > Pick your closest FTP site and go to 'snapshot/' > > Or for CVS people: > > export CVSROOT=openssh at anoncvs.be.openbsd.org:/cvs > export CVS_RSH=/usr/bin/ssh > cvs get openssh > > - Ben > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From wendyp at cray.com Thu Mar 20 10:58:35 2003 From: wendyp at cray.com (Wendy Palm) Date: Wed, 19 Mar 2003 17:58:35 -0600 Subject: Call for testing for 3.6 References: Message-ID: <3E79042B.8090402@cray.com> this works great. Ben Lindstrom wrote: > On Wed, 12 Mar 2003, Wendy Palm wrote: > > >>cray is broken also wrt nanosleep(). >> >>additionally, there's a stupid locality error that cray is having a problem with in scp.c. >> >>a variable "limit" has been added at line 99. >>this causes an incompatible declaration with cray's limit function defined in /usr/include/sys/resource.h >>which is included in includes.h. >> >> > > Below is the patch I'm planing on commiting to the portable tree here soon > (and hopefully upstream if there is no complaints). > > Index: scp.c > =================================================================== > RCS file: /var/cvs/openssh/scp.c,v > retrieving revision 1.109 > diff -u -r1.109 scp.c > --- scp.c 10 Mar 2003 00:21:18 -0000 1.109 > +++ scp.c 18 Mar 2003 18:36:10 -0000 > @@ -96,7 +96,7 @@ > arglist args; > > /* Bandwidth limit */ > -off_t limit = 0; > +off_t limitbw = 0; > > /* Name of current file being transferred. */ > char *curfile; > @@ -251,7 +251,7 @@ > speed = strtod(optarg, &endp); > if (speed <= 0 || *endp != '\0') > usage(); > - limit = speed * 1024; > + limitbw = speed * 1024; > break; > case 'p': > pflag = 1; > @@ -594,7 +594,7 @@ > haderr = result >= 0 ? EIO : errno; > statbytes += result; > } > - if (limit) > + if (limitbw) > bwlimit(amt); > } > if (showprogress) > @@ -688,7 +688,7 @@ > return; > > lamt *= 8; > - wait = (double)1000000L * lamt / limit; > + wait = (double)1000000L * lamt / limitbw; > > bwstart.tv_sec = wait / 1000000L; > bwstart.tv_usec = wait % 1000000L; > @@ -917,7 +917,7 @@ > statbytes += j; > } while (amt > 0); > > - if (limit) > + if (limitbw) > bwlimit(4096); > > if (count == bp->cnt) { > -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From d_wllms at lanl.gov Thu Mar 20 11:05:27 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Wed, 19 Mar 2003 17:05:27 -0700 Subject: Call for testing for 3.6 In-Reply-To: References: Message-ID: <3E7905C7.8070808@lanl.gov> Tested Platform: Apple OS 10.2.x configure: passed make: passed regress: passed configure options: --with-pam working on getting patches together for --with-kerberos5 Dave -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From bob at proulx.com Thu Mar 20 11:25:11 2003 From: bob at proulx.com (Bob Proulx) Date: Wed, 19 Mar 2003 17:25:11 -0700 Subject: Agent Socket Directory In-Reply-To: <006c01c2ee62$bfde0740$ce02a8c0@opf.swissbank.com> References: <20030319130414.53A9.IMACAT@mail.imacat.idv.tw> <1048069995.21036.5.camel@shuttle> <006c01c2ee62$bfde0740$ce02a8c0@opf.swissbank.com> Message-ID: <20030320002511.GC27915@misery.proulx.com> Tim McGarry wrote: > I like the idea of using /var/run it's definately where it _should_ be. > > But, /tmp has already been used for some time and I see no actual advantage > in changing it at this stage, so leave it where it always was. I could be happy with it somewhere else (not /var/run) but perhaps. But think of this. Right now if you run a tmp cleaner such as 'tmpreaper' or other such thing, or purge on reboot, old dead sockets and directories will get cleaned up from the current /tmp location. If you put that location somewhere else then you need to install an infrastructure to clean up this other place. Otherwise it will eventually fill with trash. That infrastructure already exists for /tmp and it is somewhat nice to keep it in use for this purpose. Also any place which is user writable is a tmp directory. There are already two of those on all systems with /tmp and /var/tmp. Once it is user writable it can't be specified that it only be used for ssh. Adding another tmp dir to the system is something I wish to avoid. Bob From d_wllms at lanl.gov Thu Mar 20 12:05:45 2003 From: d_wllms at lanl.gov (David M. Williams) Date: Wed, 19 Mar 2003 18:05:45 -0700 Subject: Call for testing for 3.6 In-Reply-To: <3E7905C7.8070808@lanl.gov> References: <3E7905C7.8070808@lanl.gov> Message-ID: <3E7913E9.7030100@lanl.gov> I forgot to add a few caveats for OS X: 1. See Bug #504 for OpenSSL header problem 2. 10.2.[1.2.3] require edits to /usr/include/zconf.h. remove reference to TARGET_OS_MAC. BTW: Library/header version mismatches will continue to be a problem with OSX as the stated policy from Apple is, and I quote: Thank you for bringing this problem to our attention. We have received feedback from engineering on your reported issue. Please know that we do not ship headers with Mac OS X Updates. To quote Markus, "Thank you Steven Jobs, thank you" Dave David M. Williams wrote: > Tested Platform: Apple OS 10.2.x > > configure: passed > make: passed > regress: passed > > configure options: --with-pam > > working on getting patches together for --with-kerberos5 > > Dave > -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7428 Los Alamos National Laboratory Email: d_wllms at lanl.gov From Jeff.Koenig at experian.com Thu Mar 20 14:17:27 2003 From: Jeff.Koenig at experian.com (Jeff Koenig) Date: Wed, 19 Mar 2003 21:17:27 -0600 Subject: Call for testing for 3.6: password expiry? Message-ID: I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: http://bugzilla.mindrot.org/show_bug.cgi?id=14 On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: http://bugzilla.mindrot.org/show_bug.cgi?id=125 In fact, both patches work together, apparently. If I have any issues, I'll post them here. Jeff Koenig >>> Darren Tucker 03/07/03 12:55AM >>> Hi again. Ben Lindstrom wrote: > So if you have any patches you need to ensure your platform works speak > up. We are looking at a lock on the 17th. There's a couple of patches in Bugzilla that relate to my pet project: Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view There is some overlap between the two patches and they're out of sync with each other. Can I please get someone to review these and let me know if they're suitable for inclusion in 3.6p1? The expiry patches have been pretty heavily tested (nearly 800 downloads of the patch). I've had about a dozen reports of problems, all of which have been resolved (mostly configuring with pam when it wasn't supported, a couple of genuine problems and a couple of cases of pilot error). If they are likely to go in, please let me know what you'd like done with them (eg, merge them into a single patch or make 2 "stacked" patches to be applied sequentially, and particularly what if anything should be done with the interaction with do_pam_chauthtok). -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From hayward at slothmud.org Thu Mar 20 14:45:02 2003 From: hayward at slothmud.org (hayward at slothmud.org) Date: Wed, 19 Mar 2003 21:45:02 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: Message-ID: I would like to see the expiry patch in as well. We use OpenSSH across a large corporation, with thousands of servers (Solaris, AIX, HP, etc) Our policies require password expiry... What's the point of SSH if you have to use telnet to change your password after it expires...? :-) Thanks for the consideration, Brian Hayward >I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: >http://bugzilla.mindrot.org/show_bug.cgi?id=14 > >On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: >http://bugzilla.mindrot.org/show_bug.cgi?id=125 > >In fact, both patches work together, apparently. > >If I have any issues, I'll post them here. > >Jeff Koenig > >>>> Darren Tucker 03/07/03 12:55AM >>> >Hi again. > >Ben Lindstrom wrote: >> So if you have any patches you need to ensure your platform works speak >> up. We are looking at a lock on the 17th. > >There's a couple of patches in Bugzilla that relate to my pet project: > >Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM >http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view > >Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode >http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > >There is some overlap between the two patches and they're out of sync >with each other. > >Can I please get someone to review these and let me know if they're >suitable for inclusion in 3.6p1? The expiry patches have been pretty >heavily tested (nearly 800 downloads of the patch). I've had about a >dozen reports of problems, all of which have been resolved (mostly >configuring with pam when it wasn't supported, a couple of genuine >problems and a couple of cases of pilot error). > >If they are likely to go in, please let me know what you'd like done >with them (eg, merge them into a single patch or make 2 "stacked" >patches to be applied sequentially, and particularly what if anything >should be done with the interaction with do_pam_chauthtok). > > -- Brian Hayward From mouring at etoh.eviladmin.org Thu Mar 20 14:46:59 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 19 Mar 2003 21:46:59 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: Message-ID: That's nice.. problem is when we normally call for testing.. It means NO NEW FEATURES. As in *RELEASE SOON*... Sorry folks.. These won't be in 3.6. - Ben On Wed, 19 Mar 2003 hayward at slothmud.org wrote: > > I would like to see the expiry patch in as well. We use OpenSSH across a > large corporation, with thousands of servers (Solaris, AIX, HP, etc) Our > policies require password expiry... What's the point of SSH if you have > to use telnet to change your password after it expires...? :-) > > Thanks for the consideration, > Brian Hayward > > > >I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: > >http://bugzilla.mindrot.org/show_bug.cgi?id=14 > > > >On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: > >http://bugzilla.mindrot.org/show_bug.cgi?id=125 > > > >In fact, both patches work together, apparently. > > > >If I have any issues, I'll post them here. > > > >Jeff Koenig > > > >>>> Darren Tucker 03/07/03 12:55AM >>> > >Hi again. > > > >Ben Lindstrom wrote: > >> So if you have any patches you need to ensure your platform works speak > >> up. We are looking at a lock on the 17th. > > > >There's a couple of patches in Bugzilla that relate to my pet project: > > > >Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM > >http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view > > > >Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode > >http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > > > >There is some overlap between the two patches and they're out of sync > >with each other. > > > >Can I please get someone to review these and let me know if they're > >suitable for inclusion in 3.6p1? The expiry patches have been pretty > >heavily tested (nearly 800 downloads of the patch). I've had about a > >dozen reports of problems, all of which have been resolved (mostly > >configuring with pam when it wasn't supported, a couple of genuine > >problems and a couple of cases of pilot error). > > > >If they are likely to go in, please let me know what you'd like done > >with them (eg, merge them into a single patch or make 2 "stacked" > >patches to be applied sequentially, and particularly what if anything > >should be done with the interaction with do_pam_chauthtok). > > > > > > -- > Brian Hayward > From mouring at etoh.eviladmin.org Thu Mar 20 18:13:10 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 20 Mar 2003 01:13:10 -0600 (CST) Subject: Call for testing for 3.6 In-Reply-To: <3E78FFE0.4060102@cray.com> Message-ID: I think this missed the deadline. I'll get them commited to the --head branch when the tree opens back up. - Ben On Wed, 19 Mar 2003, Wendy Palm wrote: > sorry to take so long with the testing. > > 3.6 version works great on crays using the 0315 snapshot, with tim's nanosleep > replacement patch and the 3 cray patches i sent in yesterday. > > thanks, > wendy > > Ben Lindstrom wrote: > > > We are heading into a lock here. So we need to get people to test their > > respective platforms if they wish them to be supported out of the tar file. > > > > So if you have any patches you need to ensure your platform works speak > > up. We are looking at a lock on the 17th. > > > > I believe I have an AIX/Cray patch and a Tru64 patch sitting in my mailbox > > that I'll be looking at soon and more than likely commiting. I have no > > clue what else is in my 400+ worth of email.=) > > > > I know NeXT platform is broken. Again, I make a call out to people left > > in the NeXT community. If you want it working before 3.6 submit your > > patches ASAP. If I hear no word I'll suggest it be phased out after this > > release. > > > > I'd like to see more tinderbox setups (Darren, I'll be talking to you in > > private, but I have a Sol9 box I'd like to add to the list soon). It > > would help to know where we stand for broken platforms. > > > > For those new to this process asking themselves, "Where do I find these > > test version?" > > > > http://www.openssh.com/portable.html#mirrors > > > > Pick your closest FTP site and go to 'snapshot/' > > > > Or for CVS people: > > > > export CVSROOT=openssh at anoncvs.be.openbsd.org:/cvs > > export CVS_RSH=/usr/bin/ssh > > cvs get openssh > > > > - Ben > > > > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > -- > wendy palm > Cray OS Sustaining Engineering, Cray Inc. > wendyp at cray.com, 651-605-9154 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From linux_4ever at yahoo.com Fri Mar 21 02:41:36 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 20 Mar 2003 07:41:36 -0800 (PST) Subject: cvs version / testing In-Reply-To: <20030319222911.GB16793@folly> Message-ID: <20030320154136.57161.qmail@web9602.mail.yahoo.com> Hello, I think I may see what is going on for some of the leaks. My guess is that the privilege separation child processes do not close their pam sessions. I don't know if things can or should be done in a slightly different order or if everyone is satisfied as is. -Steve Grubb __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From deepak.vyas at vinciti.com Fri Mar 21 04:54:54 2003 From: deepak.vyas at vinciti.com (Deepak Vyas) Date: Thu, 20 Mar 2003 23:24:54 +0530 Subject: Frequently occuring sshd Error message Message-ID: <001401c2ef09$d07aad40$674ba8c0@blr.vinciti.com> Hi Marcus, I have OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f installed on my Sun 480R server and frequently get the following error messages in the /var/adm/messages file. Someone please help as to how I can prevent these messages from occuring and how serious they are.... Mar 19 17:21:18 last message repeated 39 times Mar 19 17:21:30 sshd[683]: [ID 800047 auth.error] error: accept: Software caused connection abort Mar 19 17:22:18 last message repeated 5 times Mar 19 17:22:27 su: [ID 810491 auth.crit] 'su root' failed for oracle on /dev/pts/30 Mar 19 17:22:30 sshd[683]: [ID 800047 auth.error] error: accept: Software caused connection abort Mar 19 17:22:58 last message repeated 3 times Mar 19 17:23:00 sshd[29070]: [ID 800047 auth.crit] fatal: Write failed: Broken pipe I have removes the Company hostname for internal reasons.... One more thing to note is that this event actually occurs 4 minutes before Oracle user actually logs out..... any similarities w.r.t this host1# last oracle oracle pts/31 10.33.12.182 Wed Mar 19 16:10 - 17:27 (01:17) oracle pts/30 10.27.5.14 Wed Mar 19 11:47 - 00:39 (12:51) Please help asap. Regards Deepak Vyas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030320/b2cc5945/attachment.html From djm at mindrot.org Fri Mar 21 09:18:03 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Mar 2003 09:18:03 +1100 Subject: Call for testing for 3.6: password expiry? In-Reply-To: References: Message-ID: <3E7A3E1B.7020406@mindrot.org> Jeff Koenig wrote: > I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: > http://bugzilla.mindrot.org/show_bug.cgi?id=14 > > On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: > http://bugzilla.mindrot.org/show_bug.cgi?id=125 > > In fact, both patches work together, apparently. These won't be in the 3.6p1 release. The password expiry issue will be one of the foci of the next release cycle. I haven't yet looked into the BSM patch. > Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode > http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view This will be looked at too. This issue exists in the OpenBSD version too, so it needs to be fixed at the source. -d From djm at mindrot.org Fri Mar 21 09:19:49 2003 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Mar 2003 09:19:49 +1100 Subject: cvs version / testing In-Reply-To: <20030320154136.57161.qmail@web9602.mail.yahoo.com> References: <20030320154136.57161.qmail@web9602.mail.yahoo.com> Message-ID: <3E7A3E85.2020600@mindrot.org> Steve G wrote: > Hello, > > I think I may see what is going on for some of the leaks. > My guess is that the privilege separation child processes > do not close their pam sessions. I don't know if things can > or should be done in a slightly different order or if > everyone is satisfied as is. I wouldn't worry too much about one-off leaks like PAM sessions or things used at init time. Runtime leaks (e.g. per-channel) are far more important. You might also want to check sftp{,-server} and scp. -d From alchemist at magestower.net Tue Mar 18 15:09:10 2003 From: alchemist at magestower.net (alchemist at magestower.net) Date: Mon, 17 Mar 2003 22:09:10 -0600 Subject: Call for testing for 3.6: password expiry? In-Reply-To: <3E7A3E1B.7020406@mindrot.org> Message-ID: While I understand these are 3.6 issues, I'd like to confirm that we're also pleased with Sun's BSM patch. We're currently running it in conjunction with uncommenting the old pam password aging stuff and disabling privsep, so I can't speak to BSM in conjunction with privsep, but by itself, it's good. We're running the BSM patch on Solaris 2.6, 7, and 8. --Jason On Fri, 21 Mar 2003 09:18:03 +1100 Damien Miller wrote: >*This message was transferred with a trial version of >CommuniGate(tm) Pro* >Jeff Koenig wrote: >>I have tried this patch (against 3.5p1) and would very >>much like it to be in the OpenSSH 3.6p1 release, if >>possible: >>http://bugzilla.mindrot.org/show_bug.cgi?id=14 >> >>On that note, I'd like the Sun BSM patch to be included >>also, if possible. I have it working applied to 3.5p1: >>http://bugzilla.mindrot.org/show_bug.cgi?id=125 >> >>In fact, both patches work together, apparently. > >These won't be in the 3.6p1 release. The password expiry >issue will be one of the foci of the next release cycle. >I haven't yet looked into the BSM patch. > >>Bugzilla Bug 463: PrintLastLog doesn't work in privsep >>mode >>http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > >This will be looked at too. This issue exists in the >OpenBSD version too, so it needs to be fixed at the >source. > >-d > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Fri Mar 21 12:06:11 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 21 Mar 2003 12:06:11 +1100 (EST) Subject: [Bug 514] error in openbsd-compat/bsd-cray.h Message-ID: <20030321010611.67FA394209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=514 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2003-03-21 12:06 ------- Applied for 3.6 release ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 21 12:06:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 21 Mar 2003 12:06:36 +1100 (EST) Subject: [Bug 513] mods for configuring for new cray architecture Message-ID: <20030321010636.3F0C09424D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=513 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2003-03-21 12:06 ------- Applied for 3.6 release. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Fri Mar 21 12:45:21 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 20 Mar 2003 19:45:21 -0600 (CST) Subject: 3.6 portable ready. Message-ID: The Cray and tru64 patches I have, have been applied. Unless there is any major "oh my god it does not work". I believe 3.6 should now be ready for release soon. I'd like to thank everyone for providing feedback on the status of their their platform. Hopefully, we have not missed any platform that is commonly used. - Ben From bugzilla-daemon at mindrot.org Fri Mar 21 15:01:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 21 Mar 2003 15:01:26 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030321040126.2B73D9420B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 Summary: BindAddress and -b not working Product: Portable OpenSSH Version: 3.4p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: murple at murple.net I'm trying to install the OpenSSH3.4p1 on an UltraSparc running SunOS 5.6. The program compiled and runs fine with one problem... The system has two IP addresses, one on a secure network and one facing the outside world. I need to have the ssh client use one of these addresses for its outbound connections. With the old SSH 1.2.x I was able to use the SourceAddress directive in ssh_config to do this. Using OpenSSH3.4p1, neither the BindAddress directive in ssh_config nor the -b commandline switch seem to function on Solaris. A search of Bugzilla found that this was a known problem on Solaris with an older version of OpenSSH about one year ago, but there was no mention of a fix or workaround. It is still not working for me. This is something I need functional for work pretty quickly. Please advise if there is a known fix. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vinschen at redhat.com Fri Mar 21 20:21:10 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 21 Mar 2003 10:21:10 +0100 Subject: 3.6 portable ready. In-Reply-To: References: Message-ID: <20030321092110.GS21269@cygbert.vinschen.de> On Thu, Mar 20, 2003 at 07:45:21PM -0600, Ben Lindstrom wrote: > > The Cray and tru64 patches I have, have been applied. Unless there is any > major "oh my god it does not work". I believe 3.6 should now be ready for > release soon. I've just rechecked that current CVS HEAD still works on Cygwin. > I'd like to thank everyone for providing feedback on the status of > their their platform. Hopefully, we have not missed any platform that is > commonly used. Thank *you* for your efforts, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From bugzilla-daemon at mindrot.org Fri Mar 21 23:13:25 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 21 Mar 2003 23:13:25 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030321121325.6323C9420B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 Summary: RhostsAuthentication failing under AIX 4.3.3 Product: Portable OpenSSH Version: 3.5p1 Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Alf.Nicolaysen at web.de It seems to me, that under AIX 4.3.3 ML 10 the Rhostsauthentication fails completely. The files .rhosts, .shosts or even .rhosts.equiv and .shosts.equiv are completely ignored. With my client I ran the following command: /opt/bin/ssh -o RhostsAuthentication=yes -o Protocol=1 -o UsePrivilegedPort=yes And here is the debug output from my server # /opt/sbin/sshd -f /opt/etc/sshd_config -d -d debug1: sshd version OpenSSH_3.5p1 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: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 9.164.18.22 port 943 debug1: Client protocol version 1.5; client software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* debug1: Local version string SSH-1.99-OpenSSH_3.5p1 debug1: permanently_set_uid: 7/204 debug1: Sent 768 bit server key and 1024 bit host key. debug2: Network child is on pid 16256 debug1: Encryption type: 3des debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Received session key; encryption turned on. debug2: monitor_read: 28 used once, disabling now debug2: monitor_read: 30 used once, disabling nowdebug1: Installing crc compensation attack detector. debug1: Attempting authentication for root. debug2: monitor_read: 6 used once, disabling now Failed none for root from 9.164.18.22 port 943 debug2: auth_rhosts2: clientuser root hostname 9.164.18.22 ipaddr 9.164.18.22 debug1: temporarily_use_uid: 0/0 (e=7/204) debug1: restore_uid: (unprivileged) Failed rhosts for root from 9.164.18.22 port 943 ruser root Connection closed by 9.164.18.22 debug1: Calling cleanup 0x200013b0(0x0) The files .rhosts, .shosts and .shosts.equiv are existing with 600 rights on AIX. I compiled the version on myself. regards Alf Nicolaysen ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 22 00:37:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Mar 2003 00:37:13 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030321133713.C06E394212@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 ------- Additional Comments From markus at openbsd.org 2003-03-22 00:37 ------- IgnoreRhosts ... The default is ``yes''. /etc/hosts.equiv ... such users are permitted to log in as any user on this machine (except root). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From linux_4ever at yahoo.com Sat Mar 22 01:38:02 2003 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 21 Mar 2003 06:38:02 -0800 (PST) Subject: cvs version / testing In-Reply-To: <3E7A3E85.2020600@mindrot.org> Message-ID: <20030321143802.7914.qmail@web9604.mail.yahoo.com> Hello, I ran some more tests as you suggested for sftp & scp. I don't see anything new ...its the same stuff. If its OK for priv sep children to have open pam sessions, then I don't see anything bad. It passes mem leak checks. :) -Steve Grubb __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From Jeff.Koenig at experian.com Sat Mar 22 03:15:48 2003 From: Jeff.Koenig at experian.com (Jeff Koenig) Date: Fri, 21 Mar 2003 10:15:48 -0600 Subject: Call for testing for 3.6: password expiry? Message-ID: Why are password expiring and BSM support not in the code by now? People have been talking about these since before 3.5p1? At least, can't they be added and just not on by default? Like having a --password_expire and --bsm_support or something? I don't understand why password expiry and BSM auditing support are not a higher priority. I would think a lot of companies are required to use these features. Is the patch code just not tested enough or something? I'm just a little frustrated. Anyway, thanks for all the work you guys have done so far, by the way. Jeff >>> Ben Lindstrom 03/19/03 09:46PM >>> That's nice.. problem is when we normally call for testing.. It means NO NEW FEATURES. As in *RELEASE SOON*... Sorry folks.. These won't be in 3.6. - Ben On Wed, 19 Mar 2003 hayward at slothmud.org wrote: > > I would like to see the expiry patch in as well. We use OpenSSH across a > large corporation, with thousands of servers (Solaris, AIX, HP, etc) Our > policies require password expiry... What's the point of SSH if you have > to use telnet to change your password after it expires...? :-) > > Thanks for the consideration, > Brian Hayward > > > >I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: > >http://bugzilla.mindrot.org/show_bug.cgi?id=14 > > > >On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: > >http://bugzilla.mindrot.org/show_bug.cgi?id=125 > > > >In fact, both patches work together, apparently. > > > >If I have any issues, I'll post them here. > > > >Jeff Koenig > > > >>>> Darren Tucker 03/07/03 12:55AM >>> > >Hi again. > > > >Ben Lindstrom wrote: > >> So if you have any patches you need to ensure your platform works speak > >> up. We are looking at a lock on the 17th. > > > >There's a couple of patches in Bugzilla that relate to my pet project: > > > >Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM > >http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view > > > >Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode > >http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > > > >There is some overlap between the two patches and they're out of sync > >with each other. > > > >Can I please get someone to review these and let me know if they're > >suitable for inclusion in 3.6p1? The expiry patches have been pretty > >heavily tested (nearly 800 downloads of the patch). I've had about a > >dozen reports of problems, all of which have been resolved (mostly > >configuring with pam when it wasn't supported, a couple of genuine > >problems and a couple of cases of pilot error). > > > >If they are likely to go in, please let me know what you'd like done > >with them (eg, merge them into a single patch or make 2 "stacked" > >patches to be applied sequentially, and particularly what if anything > >should be done with the interaction with do_pam_chauthtok). > > > > > > -- > Brian Hayward > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at etoh.eviladmin.org Sat Mar 22 04:36:14 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 21 Mar 2003 11:36:14 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: Message-ID: On Fri, 21 Mar 2003, Jeff Koenig wrote: > Why are password expiring and BSM support not in the code by now? > People have been talking about these since before 3.5p1? At least, > can't they be added and just not on by default? Like having a > --password_expire and --bsm_support or something? > First off BSM is for a single platform and requires us to UNDERSTAND what it is doing. And no one on the OpenSSH portable team has made it a priority to understand the code. > I don't understand why password expiry and BSM auditing support are not > a higher priority. I would think a lot of companies are required to use > these features. Is the patch code just not tested enough or something? > Why password expiry? Have you looked at the RFC? If we implement v2 password expiry the way the RFC requires we will break a lot of platform and the code would be massive. Darren and I have already gone through this. Therefor there has to be a lot of discussion about this. (Which a lot has already happen on and off list.) If you've been paying attention you'd realize that this is not as easy as slapping 10 lines of code in place and saying "finished". It sounds like 3.7 that password expiring will become a priority. I think that a lot of the issue in regards to when/where to break the RFC for sanity have been concluded. > I'm just a little frustrated. > And it does not frustrate me to hear people complain and whine about this on multiple lists? =) Things take time. I'm sure if there was funding for a full time position that it would be easier to handle such things. I know my time will be extremely limited until Jan 2004 with paid projects. - Ben > Anyway, thanks for all the work you guys have done so far, by the way. > > Jeff > > >>> Ben Lindstrom 03/19/03 09:46PM >>> > > That's nice.. problem is when we normally call for testing.. It means NO > NEW FEATURES. As in *RELEASE SOON*... > > Sorry folks.. These won't be in 3.6. > > - Ben > > On Wed, 19 Mar 2003 hayward at slothmud.org wrote: > > > > > I would like to see the expiry patch in as well. We use OpenSSH across a > > large corporation, with thousands of servers (Solaris, AIX, HP, etc) Our > > policies require password expiry... What's the point of SSH if you have > > to use telnet to change your password after it expires...? :-) > > > > Thanks for the consideration, > > Brian Hayward > > > > > > >I have tried this patch (against 3.5p1) and would very much like it to be in the OpenSSH 3.6p1 release, if possible: > > >http://bugzilla.mindrot.org/show_bug.cgi?id=14 > > > > > >On that note, I'd like the Sun BSM patch to be included also, if possible. I have it working applied to 3.5p1: > > >http://bugzilla.mindrot.org/show_bug.cgi?id=125 > > > > > >In fact, both patches work together, apparently. > > > > > >If I have any issues, I'll post them here. > > > > > >Jeff Koenig > > > > > >>>> Darren Tucker 03/07/03 12:55AM >>> > > >Hi again. > > > > > >Ben Lindstrom wrote: > > >> So if you have any patches you need to ensure your platform works speak > > >> up. We are looking at a lock on the 17th. > > > > > >There's a couple of patches in Bugzilla that relate to my pet project: > > > > > >Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM > > >http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view > > > > > >Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode > > >http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > > > > > >There is some overlap between the two patches and they're out of sync > > >with each other. > > > > > >Can I please get someone to review these and let me know if they're > > >suitable for inclusion in 3.6p1? The expiry patches have been pretty > > >heavily tested (nearly 800 downloads of the patch). I've had about a > > >dozen reports of problems, all of which have been resolved (mostly > > >configuring with pam when it wasn't supported, a couple of genuine > > >problems and a couple of cases of pilot error). > > > > > >If they are likely to go in, please let me know what you'd like done > > >with them (eg, merge them into a single patch or make 2 "stacked" > > >patches to be applied sequentially, and particularly what if anything > > >should be done with the interaction with do_pam_chauthtok). > > > > > > > > > > -- > > Brian Hayward > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim at multitalents.net Sat Mar 22 05:11:47 2003 From: tim at multitalents.net (Tim Rice) Date: Fri, 21 Mar 2003 10:11:47 -0800 (PST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: References: Message-ID: On Fri, 21 Mar 2003, Ben Lindstrom wrote: > > On Fri, 21 Mar 2003, Jeff Koenig wrote: > > > Why are password expiring and BSM support not in the code by now? > > People have been talking about these since before 3.5p1? At least, > > can't they be added and just not on by default? Like having a > > --password_expire and --bsm_support or something? > > > > First off BSM is for a single platform and requires us to UNDERSTAND what > it is doing. And no one on the OpenSSH portable team has made it a > priority to understand the code. I've considered looking into the BSM patches a few times but these days I find my 85Mhz Sparcstation 5 a little frustrating to use. So Solaris ends up being the last platform I look at here. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Fri Mar 21 23:11:20 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Mar 2003 23:11:20 +1100 Subject: 3.6 portable ready. References: Message-ID: <3E7B0168.E2638F2@zip.com.au> Ben Lindstrom wrote: > I'd like to thank everyone for providing feedback on the status of > their their platform. Hopefully, we have not missed any platform that is > commonly used. For the record, I can confirm the following platforms configure, build and regression test OK according to the tinderbox[1]: AIX 4.2.1, 4.3.3 & 5.1 Solaris 8 (PAM & non-PAM) NetBSD/sparc 1.6 Redhat 8 (PAM & non-PAM) HP-UX 11.00 (PAM & non-PAM) Cygwin on NT4 [plug] Your favourite platform not listed? Running the tests is easy and automatic! You too can find new bugs fast! Put those spare cycles to use! Email me for details. -Daz. [1] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.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 bugzilla-daemon at mindrot.org Sat Mar 22 08:27:44 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Mar 2003 08:27:44 +1100 (EST) Subject: [Bug 419] HP-UX PAM problems with 3.5p1 Message-ID: <20030321212744.1F37494207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=419 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 22 08:29:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Mar 2003 08:29:53 +1100 (EST) Subject: [Bug 419] HP-UX PAM problems with 3.5p1 Message-ID: <20030321212953.AE64B94207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=419 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-03-22 08:29 ------- This is more like bug #83, but please list only one bug per report in future. *** This bug has been marked as a duplicate of 83 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 22 08:29:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 22 Mar 2003 08:29:55 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030321212955.74F089421D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael_steffens at hp.com ------- Additional Comments From djm at mindrot.org 2003-03-22 08:29 ------- *** Bug 419 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Sat Mar 22 09:34:33 2003 From: djm at mindrot.org (Damien Miller) Date: Sat, 22 Mar 2003 09:34:33 +1100 Subject: Call for testing for 3.6: password expiry? In-Reply-To: References: Message-ID: <3E7B9379.5040801@mindrot.org> Jeff Koenig wrote: > Why are password expiring and BSM support not in the code by > now? People have been talking about these since before 3.5p1? Because we didn't get time to get them understand them + get them to a point where we are comfortable with them + merge them in time. > At least, can't they be added and just not on by default? > Like having a --password_expire and --bsm_support or something? No, we don't want more compile-time options. We have way too many #ifdefs already. > I'm just a little frustrated. So are we, do you think that we _like_ having open bug reports (especially ones with reasonable patches)? [I refer more to the password expiry issue than BSM auditing, which I haven't looked into at all. Password expiry is a higher priority as it affects everyone.] This is my TODO list for the next release: 1. Merge improved PAM code from FreeBSD 2. Password expiry (using /usr/bin/passwd) 3. Rewrite sftp progressmeter support (make it a callback, rather than signal-triggered) 4. Ressurect my KeyNote patches 5. Implement new draft-secsh-filexfer stuff I'll leave BSM to someone with more consistent access to Solaris platforms. -d From jstockdale at stanford.edu Sat Mar 22 11:58:51 2003 From: jstockdale at stanford.edu (John Stockdale) Date: Fri, 21 Mar 2003 16:58:51 -0800 Subject: Transfer rate issues with OpenSSH SFTP Server - Verified on Mac OS X 10.2.X and FreeBSD 5.0 Message-ID: <002301c2f00e$349e8e90$3d2c0c80@quenya> First, I have what I consider to be decent experience with SSH, and have been running VanDyke's VShell SSH server for considerable time under Windows 2000/XP. Recently, I have been working with Mac OS X and FreeBSD and have been using OpenSSH 3.4p1 The sftp server seems to have major issues when serving files, specifically, if one data stream is used the transfer rates fluxuate between 80 and 200 KB/s. Keep in mind that this is over a 100Mbit switched link. If multiple transfers are performed at once over one login session, the transfer rates of both files increases to 800-1000KB/s still below what it should be but substantially better. Performing similar transfers in the other direction, using the VShell sftp server and sftp clients on the other boxes, the transfer rate is in the order of 3000-4000KB/s. These are all modern boxes that should beable to do AES-256/Twofish at more than adequate rates to sustain the transfer, so the only thing I can think of that would be causing the problem would be some bug in the OpenSSH sftp server. Any thoughts? Thanks -John From cmadams at hiwaay.net Sat Mar 22 14:35:09 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Mar 2003 21:35:09 -0600 Subject: 3.6 portable ready. In-Reply-To: References: Message-ID: <20030322033509.GA946972@hiwaay.net> Once upon a time, Ben Lindstrom said: > The Cray and tru64 patches I have, have been applied. Unless there is any > major "oh my god it does not work". I believe 3.6 should now be ready for > release soon. I've built Tru64 with the 20030321 snapshot and it builds and runs. I have yet to look into the regression tests (okay, so I'm always behind on what I want to do - this is the fifth Monday this week, and only two more Mondays until Monday). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Sat Mar 22 14:40:20 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Mar 2003 21:40:20 -0600 Subject: Call for testing for 3.6: password expiry? In-Reply-To: References: Message-ID: <20030322034020.GC946972@hiwaay.net> Once upon a time, Ben Lindstrom said: > Why password expiry? Have you looked at the RFC? If we implement v2 > password expiry the way the RFC requires we will break a lot of platform > and the code would be massive. As Tru64 is kind of odd... how does password expiry work in the RFC that might break platforms? As it stands now, the Tru64 system password expiration methods work, at least when OpenSSH is built with SIA support (and when running in Enhanced Security mode; I don't think Base Security on Tru64 supports password expiration). If I try to open a TTY connection (I don't know what happens on non-interactive sessions) and my password has expired, I get the Tru64 prompts for changing my password. Even if I use a key to connect, I have to enter my old password before changing it. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From djm at mindrot.org Sat Mar 22 14:43:21 2003 From: djm at mindrot.org (Damien Miller) Date: Sat, 22 Mar 2003 14:43:21 +1100 Subject: Transfer rate issues with OpenSSH SFTP Server - Verified on Mac OS X 10.2.X and FreeBSD 5.0 In-Reply-To: <002301c2f00e$349e8e90$3d2c0c80@quenya> References: <002301c2f00e$349e8e90$3d2c0c80@quenya> Message-ID: <200303221443.21282.djm@mindrot.org> On Sat, 22 Mar 2003 11:58 am, John Stockdale wrote: > First, I have what I consider to be decent experience with SSH, and have > been running VanDyke's VShell SSH server for considerable time under > Windows 2000/XP. Recently, I have been working with Mac OS X and FreeBSD > and have been using OpenSSH 3.4p1 The sftp server seems to have major > issues when serving files, specifically, if one data stream is used the > transfer rates fluxuate between 80 and 200 KB/s. Keep in mind that this > is over a 100Mbit switched link. If multiple transfers are performed at > once over one login session, the transfer rates of both files increases > to 800-1000KB/s still below what it should be but substantially better. > > Performing similar transfers in the other direction, using the VShell > sftp server and sftp clients on the other boxes, the transfer rate is in > the order of 3000-4000KB/s. These are all modern boxes that should > beable to do AES-256/Twofish at more than adequate rates to sustain the > transfer, so the only thing I can think of that would be causing the > problem would be some bug in the OpenSSH sftp server. > > Any thoughts? What sftp client are you using? I get consistent 2.8Mbps with OpenSSH client & server with arcfour cipher. Also, please retry your tests with a recent version. In a couple of days, you have 3.6p1 to try... -d From mouring at etoh.eviladmin.org Sat Mar 22 15:15:38 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 21 Mar 2003 22:15:38 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: <20030322034020.GC946972@hiwaay.net> Message-ID: On Fri, 21 Mar 2003, Chris Adams wrote: > Once upon a time, Ben Lindstrom said: > > Why password expiry? Have you looked at the RFC? If we implement v2 > > password expiry the way the RFC requires we will break a lot of platform > > and the code would be massive. > > As Tru64 is kind of odd... how does password expiry work in the RFC that > might break platforms? > I still don't know enough about SIA, but the way the RFC works is they want the password change to occur in an non-interactive way to try and remove timing attacks for passwording guessing. So for us to implement (in general) RFC SecSH v2 password change method it would mean we would not only need the generic strucor handling it, but also checks for every method that you could expire passwords (PAM, shadow, SIA, HP/UX Trust, etc) plus feed through any of those systems for password changing. So the code base would bloat massively. Also, keep in mind that if you are not using some system level API to enforce password rules we end up with people whining because their passwd policies (enforced by /bin/passwd) are being ignored. As a result, we pretty much agreed that we will be opening up a TTY before the session starts and do password change the same as v1 did. BTW.. the other thing we have to watch out for is that all port forwarding and advanced ssh features are denied or delayed until the password has been changed. Then the question comes up. Password expires and your using public key? do you deny the public key and require them to change their password first? Do you warn them? Do you allow the public key to be done ignoring all expiration? These are some of the issue that all need to be discussed and agreed on (not just community/portable, but with OpenBSD group too). And I'm sure all of this will be rehashed again before the final patches are commited. - Ben From dtucker at zip.com.au Sun Mar 23 15:04:14 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 23 Mar 2003 15:04:14 +1100 Subject: Call for testing for 3.6: password expiry? References: Message-ID: <3E7D323E.B113971D@zip.com.au> Hi All. Before I follow up Ben's post I wanted to say that, for anyone who hasn't been following the saga, dealing with the password expiration issue is *not* as simple as it seems at first glance. Indeed, I thought it was simple when I started on it, but that was roughly 5 months and 20 patches ago :-). Every solution to involves some compromise. Although I'm disappointed that the patch didn't make 3.6p1 I do understand the reasons why. I will work to get it merged post-3.6 and will maintain the patch until then. I will also publish a patch against 3.6p1 for those who can't wait. Ben Lindstrom wrote: [about password expiry] > I still don't know enough about SIA, but the way the RFC works is they > want the password change to occur in an non-interactive way to try and > remove timing attacks for passwording guessing. Could you elaborate on these timing attacks, and would password change via keyboard-interactive be succeptible to them? > So for us to implement (in general) RFC SecSH v2 password change method it > would mean we would not only need the generic strucor handling it, but > also checks for every method that you could expire passwords (PAM, shadow, > SIA, HP/UX Trust, etc) plus feed through any of those systems for password > changing. So the code base would bloat massively. You need the checks for expired passwords anyway (and some of them are already there) but yes, the platform-specific change functions do add a lot of code (50-120 lines or so per platform) that runs as root. > Also, keep in mind that if you are not using some system level API to > enforce password rules we end up with people whining because their passwd > policies (enforced by /bin/passwd) are being ignored. Also true. > As a result, we pretty much agreed that we will be opening up a TTY before > the session starts and do password change the same as v1 did. Yep, this gives you the maximum coverage (ie protocols 1&2) for the smallest amount of code. Doing it any other way results in fewer platforms/configurations supported, more code, or both. > Then the question comes up. Password expires and your using public key? > do you deny the public key and require them to change their password > first? Do you warn them? Do you allow the public key to be done ignoring > all expiration? Well at the moment an expired password (on the platforms that currently support them, eg /etc/shadow) will result in an authentication failure even with public-key. Warning and forcing a change in that case seems reasonable, and that's what I would recommend. I've also had some experience with the no-expiry-on-public-key scheme (on AIX which is not supported for password expiry yet). It's fine until you need to get in some way other than ssh (eg on the console when the network is broken) and your password has been expired too long then you are well and truly snookered. > And I'm sure all of this will be rehashed again before the final patches > are commited. Agreed! There's no ideal solution to it, all the solutions we've looked at so far have pros and cons. -- 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 mouring at etoh.eviladmin.org Sun Mar 23 15:28:11 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 22 Mar 2003 22:28:11 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: <3E7D323E.B113971D@zip.com.au> Message-ID: On Sun, 23 Mar 2003, Darren Tucker wrote: [..] > > Ben Lindstrom wrote: > [about password expiry] > > I still don't know enough about SIA, but the way the RFC works is they > > want the password change to occur in an non-interactive way to try and > > remove timing attacks for passwording guessing. > > Could you elaborate on these timing attacks, and would password change > via keyboard-interactive be succeptible to them? > If you follow all of the discussion in regards to cryptology and the idea that you can 'leak' information based on timing of activities. Then you can come to see that the RFC decided to avoid the pit falls by having the password sent as a single encrypted block instead of as a stream of smaller blocks. http://paris.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf That paper discusses some of the methods that could be implemented in an attempt to gleam what the user is doing. Granted, I'm not sure how realist some of these timing attacks are. As for the relationship to Keyboard Interaction. I've not gotten around to that aspect of SSH. So I can't comment. - Ben From bugzilla-daemon at mindrot.org Sun Mar 23 20:24:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 23 Mar 2003 20:24:58 +1100 (EST) Subject: [Bug 511] PublickKeyAuthentication failures when account password expires Message-ID: <20030323092458.4DEA994211@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=511 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From dtucker at zip.com.au 2003-03-23 20:24 ------- Closing as "INVALID". Unfortunately there doesn't seem to be a "NOTABUG" or "FEATURE" :-). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 23 21:00:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 23 Mar 2003 21:00:00 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030323100000.D913F94211@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From dtucker at zip.com.au 2003-03-23 20:59 ------- Confirmed with 3.5p1 on Solaris 2.6. Does not occur on Solaris 8 (ie -b works as expected). I note that Solaris 8 has a real getaddrinfo whereas 2.6 does not and uses the compatibility one from openbsd-compat, so there may be something funny going on there. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 01:07:26 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 01:07:26 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030323140726.50C369423B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 ------- Additional Comments From dtucker at zip.com.au 2003-03-24 01:07 ------- Created an attachment (id=253) --> (http://bugzilla.mindrot.org/attachment.cgi?id=253&action=view) Comment out AI_PASSIVE from sshconnect.c It looks like getaddrinfo() in openbsd-compat doesn't do the right thing when AI_PASSIVE is set. It will always return a null address even when an address is specified (either via ssh -b or sshd's ListenAddress). The patch fixes the ssh -b thing (should AI_PASSIVE be set on a socket that's not going to be listening?) but fake-getaddrinfo seems to need some work for the sshd ListenAddress case too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 10:20:30 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 10:20:30 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030323232030.94DFB9420A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 ------- Additional Comments From djm at mindrot.org 2003-03-24 10:20 ------- Created an attachment (id=254) --> (http://bugzilla.mindrot.org/attachment.cgi?id=254&action=view) Try to fix AI_PASSIVE support This (untested) patch may help to fix fake-getaddrinfo's AI_PASSIVE support ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 12:05:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 12:05:35 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030324010535.C9C9C94208@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 ------- Additional Comments From dtucker at zip.com.au 2003-03-24 12:05 ------- Don't have a copy of the CVS tree on my Solaris 2.6 machine. Applied patch to 3.5p1 (minor reject of "u_long addr;", easily fixed). Apart from a missing semicolon at the end of "addr = htonl(0x00000000)" this works for ssh -b and sshd -o ListenAddress. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 13:34:51 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 13:34:51 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030324023451.42F2F9421A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #253 is|0 |1 obsolete| | Attachment #254 is|0 |1 obsolete| | ------- Additional Comments From djm at mindrot.org 2003-03-24 13:34 ------- Created an attachment (id=255) --> (http://bugzilla.mindrot.org/attachment.cgi?id=255&action=view) Fixed patch Here is a corrected patch. It will be applied to -current. Users of 3.6p1 (and earlier) will want to apply this if using BindAddress. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 13:36:20 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 13:36:20 +1100 (EST) Subject: [Bug 515] BindAddress and -b not working Message-ID: <20030324023620.B074994226@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=515 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-03-24 13:36 ------- Applied to -current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 15:38:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 15:38:58 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030324043858.6561294209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 Summary: bad "put" arg parsing Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: djm at mindrot.org From bugzilla-daemon at mindrot.org Mon Mar 24 16:54:39 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 16:54:39 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030324055439.7FCF494209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 ------- Additional Comments From Alf.Nicolaysen at web.de 2003-03-24 16:54 ------- Yes, I set the option "IgnoreRhosts no" in the sshd_config. I also set the option "strictModes no" to prevent a failing here. Nothing helps. Alf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 20:41:02 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 20:41:02 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030324094102.66AC294216@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From dtucker at zip.com.au 2003-03-24 20:41 ------- Seems to be a privsep thing. Try running sshd with "-o UsePrivilegeSeparation=no". I can get rhosts authentication to work if I disable privsep. It works as a non-root user with shosts.equiv and with /.shosts as root. With privsep enabled, it fails. I will attach a debug log. I also needed to make ssh setuid root so it could bind to a privileged port. Also, the man page fragment that Markus quoted does not seem clear on root logins with hosts.equiv, however. With a bit more context, it says: "/etc/hosts.equiv This file is used during .rhosts authentication. In the simplest form, this file contains host names, one per line. Users on those hosts are permitted to log in without a password, provided they have the same user name on both machines. The host name may also be followed by a user name; such users are permitted to log in as any user on this machine (except root)." To me, the last sentence seems to say the exception for root applies only when the the optional username follows the hostname. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 20:58:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 20:58:16 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030324095816.6326E9424A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 ------- Additional Comments From dtucker at zip.com.au 2003-03-24 20:58 ------- Created an attachment (id=256) --> (http://bugzilla.mindrot.org/attachment.cgi?id=256&action=view) sshd & ssh debug traces for rhosts authentication ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 22:43:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 22:43:43 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing under AIX 4.3.3 Message-ID: <20030324114343.618B894250@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|AIX |All Platform|PPC |All ------- Additional Comments From dtucker at zip.com.au 2003-03-24 22:43 ------- Reproduced on Redhat 8 too, this does not seem to be specific to AIX. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 24 23:13:18 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 24 Mar 2003 23:13:18 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing with privsep Message-ID: <20030324121318.159E494255@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|RhostsAuthentication failing|RhostsAuthentication failing |under AIX 4.3.3 |with privsep ------- Additional Comments From markus at openbsd.org 2003-03-24 23:13 ------- ok, there is no privsep code for rhosts authentication. should it be added? rhosts is insecure and there are alternatives like rhosts-rsa or hostbased. should rhosts be dropped? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From netchannel at 24i.net Mon Mar 24 23:19:55 2003 From: netchannel at 24i.net (net-master) Date: Mon, 24 Mar 2003 21:19:55 +0900 Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8C=C0=92=E8=93=C1=95=CA=8F=A4=95i=81I=95K=8C=A9=81I=81I?= Message-ID: <20030324121326.0B34F94258@shitei.mindrot.org> ?l?b?g?`?????l?????????? 090-8130-1117 ???????? ???????????????g?b?v???i!?E????????!?E???l?C!?E?\??????!?????i?? ?????????????????????????v???????I?I?K???? ???L???????A?h???X?????????????????I . http://tarou7.tripod.com/ http://www.geocities.co.jp/Hollywood-Studio/3408/ http://red.ribbon.to/~netxxx7/ . ???????????????????????? . . . . . ???????M???~?????]?????????? ?K?????????u573ro62???~?v???L?????????M?????????????B ?????????M?????~?v???????B ?????????[???????????????K?????????????M???????????B From jrojo at alumnos.euitt.upm.es Tue Mar 25 04:26:19 2003 From: jrojo at alumnos.euitt.upm.es (Jesus Rojo Martinez) Date: Mon, 24 Mar 2003 18:26:19 +0100 Subject: SSH Source Code Documentation Message-ID: <20030324172619.GA2602@coyote.asoc.euitt.upm.es> Hello, I'm studying I. T. Science and I'm developing my final work to get my degree. I need to know about SSH (specially, SSH 2.0 protocol) so I've been studing deeply openssh-3.5 source code, because it could help me a lot to develop my work. I'm going to crypt communications between a close machine group within a bigger network. The task takes place over a Netgraph architecture at FreeBSD (between network interfaces and devices drivers). It means that I develop at link layer although I crypt over network layer. The main problem I have is I find difficult to understand the source code so I would thank any help you may give me. I need to know specially the SSH transport layer, beacuse of its machine authentication, key exchange and crypting task. I need as well the modular design to get a general view. May you send me any documents or URLs relating to it? (Modular design, layers organization -Transport,User Authentication,Connection-, etc). It would be useful to help me understanding the source code as well as knowing which part of it could be usefull in my work. Thank you in advance. -- --- Jes?s Rojo Mart?nez. --- ********************************************************************************** ********************************************************************************** Buenas, Estoy estudiando Ingenier?a de Telecomunicaciones (especialidad Telem?tica), y estoy realizando mi Proyecto Final de Carrera (PFC) para obtener el t?tulo. Necesito conocer y entender SSH (especialmente, el protocolo SSH 2.0), por lo que he estado mirando profundamente el c?digo fuente de openssh-3.5, debido a que podr?a ayudarme bastante en el desarrollo de mi trabajo. Mi PFC consiste en cifrar las comunicaciones entre un "grupo cerrado de m?quinas" dentro de una red mayor. La tarea tiene lugar en la arquitectura Netgraph para FreeBSD (entre las interfaces de red y los controladores de los dispositivos). Lo que significa que desarrollar? en la capa de enlace, aunque cifrar? sobre la capa de red. El principal problema que tengo es la dificultad para entender el c?digo, asi que agradecer?a cualquier ayuda que pudieran prestarme. Necesito conocer especialmente la "capa de transporte de SSH", debido a su labor de autenticaci?n de m?quinas, intercambio de claves y cifrado. Necesito tambi?n el dise?o modular para obtener una visi?n general. ?Podr?an enviarme documentos o URLs relacionados con esto? (Dise?o modular, organizaci?n de las capas -Transporte,Autenticaci?n de Usuarios,Conexi?n-, etc). Me ser?a muy ?til para entender el c?digo fuente, as? como para ver qu? parte del c?digo ser?a ?til en mi proyecto. Muchas gracias de antemano. -- --- Jes?s Rojo Mart?nez. --- -------------- 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/20030324/36825843/attachment.bin From jpuckett at lamuscompany.com Tue Mar 25 04:45:20 2003 From: jpuckett at lamuscompany.com (James Puckett) Date: Mon, 24 Mar 2003 12:45:20 -0500 Subject: Transfer rate issues with OpenSSH SFTP Server - Verified on Mac OS X 10.2.X and FreeBSD 5.0 In-Reply-To: <002301c2f00e$349e8e90$3d2c0c80@quenya> References: <002301c2f00e$349e8e90$3d2c0c80@quenya> Message-ID: <3E7F4430.5050602@lamuscompany.com> I have been dealing with they same problem for at least a year now, and probably should have brought it up sooner. I use OpenSSH at work and at home on Apple, x86 and Sun systems ranging from from a K6-III/400 to uber-v880s, and no matter what system I use or which user is tranferring files, the throughput I get from the sftp server is pathetic. I work around this problem by just using scp wherever possible, because scp does *not* suffer a noticeable performance hit. If this is just a simple cipher selection option, it needs to be documented somewhere obvious, because users and sysadmins just are not aware of it. -james John Stockdale wrote: > First, I have what I consider to be decent experience with SSH, and have > been running VanDyke's VShell SSH server for considerable time under > Windows 2000/XP. Recently, I have been working with Mac OS X and FreeBSD > and have been using OpenSSH 3.4p1 The sftp server seems to have major > issues when serving files, specifically, if one data stream is used the > transfer rates fluxuate between 80 and 200 KB/s. Keep in mind that this > is over a 100Mbit switched link. If multiple transfers are performed at > once over one login session, the transfer rates of both files increases > to 800-1000KB/s still below what it should be but substantially better. > > Performing similar transfers in the other direction, using the VShell > sftp server and sftp clients on the other boxes, the transfer rate is in > the order of 3000-4000KB/s. These are all modern boxes that should > beable to do AES-256/Twofish at more than adequate rates to sustain the > transfer, so the only thing I can think of that would be causing the > problem would be some bug in the OpenSSH sftp server. > > Any thoughts? > > Thanks > > -John > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- James Puckett System Administrator The Lamus Company 703-268-3109 +---+ http://news.com.com/2010-1071-980462.html +---+ "...They have as king over them the angel of the bottomless pit; his name in Hebrew is Abad'don..." ~Revelation, Chapter 9, Verse 11 +---+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4684 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030324/9e80d893/attachment.bin From openssh at roumenpetrov.info Tue Mar 25 04:44:12 2003 From: openssh at roumenpetrov.info (openssh at roumenpetrov.info) Date: Mon, 24 Mar 2003 19:44:12 +0200 Subject: SSH Source Code Documentation References: <20030324172619.GA2602@coyote.asoc.euitt.upm.es> Message-ID: <3E7F43EC.3030501@roumenpetrov.info> http://www.ietf.org/ids.by.wg/secsh.html From bugzilla-daemon at mindrot.org Tue Mar 25 04:54:10 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 04:54:10 +1100 (EST) Subject: [Bug 518] _PATH_STDPATH can get redefined in includes.h if paths.h exists Message-ID: <20030324175410.7FD239425A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=518 Summary: _PATH_STDPATH can get redefined in includes.h if paths.h exists Product: Portable OpenSSH Version: 3.5p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rvz at lucent.com In versions of openssh 3.2.3p1 and later, the defines.h file was modified and the following was added: #ifdef HAVE_PATHS_H # include /* For _PATH_XXX */ #endif Unfortunately the above comes after the inclusion of defines.h (through config.h) which sets _PATH_STDPATH to USER_PATH if it has been defined in the configure file. The result of which resets _PATH_STDPATH back to the system default and not what was computed during the configure run. Once compiled, this results in execution failures if the command being run is not located under the PATH of the system default _PATH_STDPATH. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From srinidhi_h at hotmail.com Tue Mar 25 05:32:52 2003 From: srinidhi_h at hotmail.com (Srinidhi H) Date: Tue, 25 Mar 2003 00:02:52 +0530 Subject: multiple password prompts for a locked account Message-ID: An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030325/6e363858/attachment.html From scott.burch at camberwind.com Tue Mar 25 05:49:29 2003 From: scott.burch at camberwind.com (Scott Burch) Date: 24 Mar 2003 12:49:29 -0600 Subject: Transfer rate issues with OpenSSH SFTP Server - Verified on Mac OS X 10.2.X and FreeBSD 5.0 In-Reply-To: <3E7F4430.5050602@lamuscompany.com> References: <002301c2f00e$349e8e90$3d2c0c80@quenya> <3E7F4430.5050602@lamuscompany.com> Message-ID: <1048531768.9621.9.camel@localhost> Hello, I have dealt with this issue and discovered that it has a lot to do with the compiler used to build openssh (or possibly the compiler flags). Below is some discussion I had with people inside my company regarding this issue and how I resolved the problem on Solaris: (If you want more details let me know.) (Internal discussion of this issue below) I had a discussion with [name removed] regarding performance issues of my openssh package; I confirmed there was indeed a problem. I have discovered that compiling the components with Sun's compiler is the source of the problem. The version I compiled with gcc 3.2 works great. This morning I did a test from my Windows 2000 PC with Secure FX 2.1 transferring the same 137 MB file below....my throughput was over 430 KB/s; obviously Solaris w/openssh client is much faster than Secure FX on our 2000 builds, but the throughput I got was almost 2x faster than [name removed] transfer (using Secure FX on his laptop) to [server name removed] (running ssh.com's 2.2.0). -Scott > -----Original Message----- > From: Burch, Scott > Subject: You can't beat this openssh performance > > > sftp from a machine (Sun servers running Solaris 8) on one subnet to another: > > Transferred 137 Megabytes in 60 seconds which translates to: > > 2338.133333 kilobytes/second > > I'll test with securefx in the morning. The client and server > in this test are running openssh 3.4p1 components built with > gcc 3.2. [name removed] demonstrated that the same software compiled > with Sun Developer 7 performed miserably. I will test with > securefx in the morning, to ensure that it is not an issue > with securefx. [name removed] and I saw miserable performance between > securefx and openssh 3.4p1 compiled with Sun Developer 7. (End Discussion) On Mon, 2003-03-24 at 11:45, James Puckett wrote: > I have been dealing with they same problem for at least a year now, and > probably should have brought it up sooner. I use OpenSSH at work and at > home on Apple, x86 and Sun systems ranging from from a K6-III/400 to > uber-v880s, and no matter what system I use or which user is tranferring > files, the throughput I get from the sftp server is pathetic. I work > around this problem by just using scp wherever possible, because scp > does *not* suffer a noticeable performance hit. > > If this is just a simple cipher selection option, it needs to be > documented somewhere obvious, because users and sysadmins just are not > aware of it. > > -james > > John Stockdale wrote: > > First, I have what I consider to be decent experience with SSH, and have > > been running VanDyke's VShell SSH server for considerable time under > > Windows 2000/XP. Recently, I have been working with Mac OS X and FreeBSD > > and have been using OpenSSH 3.4p1 The sftp server seems to have major > > issues when serving files, specifically, if one data stream is used the > > transfer rates fluxuate between 80 and 200 KB/s. Keep in mind that this > > is over a 100Mbit switched link. If multiple transfers are performed at > > once over one login session, the transfer rates of both files increases > > to 800-1000KB/s still below what it should be but substantially better. > > > > Performing similar transfers in the other direction, using the VShell > > sftp server and sftp clients on the other boxes, the transfer rate is in > > the order of 3000-4000KB/s. These are all modern boxes that should > > beable to do AES-256/Twofish at more than adequate rates to sustain the > > transfer, so the only thing I can think of that would be causing the > > problem would be some bug in the OpenSSH sftp server. > > > > Any thoughts? > > > > Thanks > > > > -John > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Scott Burch From djm at mindrot.org Tue Mar 25 09:27:15 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Mar 2003 09:27:15 +1100 Subject: multiple password prompts for a locked account In-Reply-To: References: Message-ID: <3E7F8643.90000@mindrot.org> Srinidhi H wrote: > Hi, > > Please forgive me if this the wrong list for my query or if this topic > is already covered. I searched through the archive but could not find > any information. > > Here is my problem. If I enable more than one authentication method (say > public key, keyboard interaction,password) at my SSH server and try to > login using a locked/expired user account, server prompts for password > for each authentication method . Since user is already locked isn't it > better to stop at the first authentication method (i.e. publickey) with > a appropriate error message? Otherwise this unnecessarily forces the > user to enter password for each authentication method even though it is > known that all the methods will fail. > > Is there any reason why it is implemented this way? (which I am obviosly > missing here) To stop early would allow probing of existing usernames and allowed authentication methods. -d From markus at openbsd.org Tue Mar 25 10:03:55 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 25 Mar 2003 00:03:55 +0100 Subject: Transfer rate issues with OpenSSH SFTP Server - Verified on Mac OS X 10.2.X and FreeBSD 5.0 In-Reply-To: <3E7F4430.5050602@lamuscompany.com> References: <002301c2f00e$349e8e90$3d2c0c80@quenya> <3E7F4430.5050602@lamuscompany.com> Message-ID: <20030324230355.GA17255@folly> > If this is just a simple cipher selection option, it needs to be > documented somewhere obvious, because users and sysadmins just are not > aware of it. do you have numbers to show? what ciphers are you using? how large are the sftp buffers? how many parallel requests are you sending? it 'ssh host cat file' slow as well? -m From bugzilla-daemon at mindrot.org Tue Mar 25 11:36:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 11:36:36 +1100 (EST) Subject: [Bug 519] parsing bug in host.allow element of login.conf(5) Message-ID: <20030325003636.6843094207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=519 Summary: parsing bug in host.allow element of login.conf(5) Product: Portable OpenSSH Version: 3.5p1 Platform: All URL: http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ssh/ auth.c#rev1.18 OS/Version: NetBSD Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: lukem at netbsd.org There's a bug in the parser code for the "host.allow" element of login.conf(5). If you have more than one hostname in a comma separated argument to "host.allow=", and there's not a positive or negative match on the first element, sshd will infinitely loop because there's a missing strtok() to advance to the next field. The URL quoted above contains the cvs commit message I made to NetBSD-current to fix the problem there. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 12:46:59 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 12:46:59 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325014659.F31C394229@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-25 12:46 ------- Created an attachment (id=257) --> (http://bugzilla.mindrot.org/attachment.cgi?id=257&action=view) Patch to fix problems fetching filenames with quotes in sftp ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 12:55:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 12:55:31 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325015531.77D1094229@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-25 12:55 ------- The above patch replaces strchr with strrchr so that the get_pathname will look for the last ' or " for the filepath and not the first " or ' it comes to. Test/Proof: (Current SFTP) sftp> dir silly""file''2 this"is' asillyname sftp> get "silly\"\"file\'\'2" Couldn't stat remote file: No such file or directory File "/home/jason/silly\" not found. sftp> get "thCouldn't stat remote file: No such file or directory File "/home/jason/this\" not found. is\"is\' asillyname" (Patched SFTP) sftp> dir silly""file''2 sftp> get "silly\"\"file\'\'2" silly""file''2 100% 3 0.4KB/s 00:00 Fetching /home/jason/this"is' asillyname to this"is' asillyname sftp> exit Only thing is that the filename seems to mess up the progress meter. This changed didn't seem to break any fetches and solves every " or ' problem I could throw at it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 13:02:57 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 13:02:57 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325020257.4596394229@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-25 13:02 ------- Created an attachment (id=258) --> (http://bugzilla.mindrot.org/attachment.cgi?id=258&action=view) Test case showing results of patched sftp This is the results of sftp operations before and after the sftp patch. The originals I put into the comment came out all funny. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 13:52:40 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 13:52:40 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325025240.27FA194231@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From mouring at eviladmin.org 2003-03-25 13:52 ------- As we are currently discussion on irc this fails to work for get "foo" "bar" case. I think the strchr() is correct, just needs to be wrapped into a loop until you find (*end) != '\\'. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:02:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:02:45 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325030245.1AD3D94231@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From djm at mindrot.org 2003-03-25 14:02 ------- hm, maybe I should rewrite the line parser using lex/yacc ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:11:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:11:05 +1100 (EST) Subject: [Bug 520] Recursive operations Message-ID: <20030325031105.6438894264@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=520 Summary: Recursive operations Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: djm at mindrot.org The sftp client should support recursive operations. For example, "get -R somedir" should copy the directory tree rooted at somedir. Probably achieve this by forking a copy of OpenBSD's fts routines (libc/gen/fts.c) and teach them sftp. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:46:16 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:46:16 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325034616.3124894264@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-25 14:46 ------- Or maybe I shouldn't make silly assumptions or have brain farts as to the syntax of get and put. Ben's got a better fix. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:46:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:46:41 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325034641.1A51B94267@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #257 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:46:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:46:58 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325034658.BB3A294264@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #258 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 14:51:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 14:51:24 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325035124.997CF94286@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From mouring at eviladmin.org 2003-03-25 14:51 ------- Created an attachment (id=259) --> (http://bugzilla.mindrot.org/attachment.cgi?id=259&action=view) More correct version I believe that this is more what we want. I've only lightly tested it, but it support get "foo\"bar" "dog" correctly. The logic is just to loop through and skip the char quot; if the character before it is a \. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 25 17:07:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 25 Mar 2003 17:07:24 +1100 (EST) Subject: [Bug 125] with BSM auditing, cron editing thru ssh session causes cron jobs to fail Message-ID: <20030325060724.256589425C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=125 dleach at securenet.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dleach at securenet.com.au ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jfh at cise.ufl.edu Wed Mar 26 00:14:43 2003 From: jfh at cise.ufl.edu (James F.Hranicky) Date: Tue, 25 Mar 2003 08:14:43 -0500 Subject: Call for testing for 3.6: password expiry? Message-ID: <20030325081443.79d281b4.jfh@cise.ufl.edu> > Bugzilla Bug 14: Can't change expired /etc/shadow password without PAM > http://bugzilla.mindrot.org/attachment.cgi?id=240&action=view > > Bugzilla Bug 463: PrintLastLog doesn't work in privsep mode > http://bugzilla.mindrot.org/attachment.cgi?id=235&action=view > > There is some overlap between the two patches and they're out of sync > with each other. Can I please get someone to review these and let me > know if they're suitable for inclusion in 3.6p1? The expiry patches have > been pretty heavily tested (nearly 800 downloads of the patch). I've had > about a dozen reports of problems, all of which have been resolved (mostly > configuring with pam when it wasn't supported, a couple of genuine > problems and a couple of cases of pilot error). Here are my observations about the latest version of the patch (passexpire18). Platform : Solaris 8 Auth Type : PAM PAM Module : Cusack pam_krb5 (v1.0) Kerberos Ver : MIT 1.2.6 - Without privsep o PASSWD_PROGRAM_PATH defined as "kpasswd": - the PAM module doesn't appear to create the ccache before kpasswd is called, and kpasswd requires a valid ccache to change passwords o PASSWD_PROGRAM_PATH defined as "kinit": - the program is called successfully, but requires the user to enter Old PW New PW New PW even though the user already logged in with "Old PW" - With privsep o default: - sshd returns "Password changing is currently unsupported with privilege separation" o with this commented out in do_pam_chauthtok(), thereby calling pam_chauthtok() --------- if (password_change_required) { #if 0 if (use_privsep) fatal("Password changing is currently unsupported" " with privilege separation"); #endif pamstate = OTHER; pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK); --------- - sshd successfully changes the password, although it exits immediately afterward I can do more testing if anyone's interested. FYI. ---------------------------------------------------------------------- | Jim Hranicky, Senior SysAdmin UF/CISE Department | | E314D CSE Building Phone (352) 392-1499 | | jfh at cise.ufl.edu http://www.cise.ufl.edu/~jfh | ---------------------------------------------------------------------- "Given a choice between a complex, difficult-to-understand, disconcerting explanation and a simplistic, comforting one, many prefer simplistic comfort if it's remotely plausible, especially if it involves blaming someone else for their problems." -- Bob Lewis, _Infoworld_ From hayward at slothmud.org Wed Mar 26 03:12:00 2003 From: hayward at slothmud.org (hayward at slothmud.org) Date: Tue, 25 Mar 2003 10:12:00 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: <20030325081443.79d281b4.jfh@cise.ufl.edu> Message-ID: This is how password changing works on solaris through "telnet" as well. This is frustrating to users but may not be something easily solved in an openssh password expiry solution. -- Brian Hayward >Here are my observations about the latest version of the patch (passexpire18). > > Platform : Solaris 8 > Auth Type : PAM > PAM Module : Cusack pam_krb5 (v1.0) > Kerberos Ver : MIT 1.2.6 > >- Without privsep > > o PASSWD_PROGRAM_PATH defined as "kpasswd": > > - the PAM module doesn't appear to create the ccache > before kpasswd is called, and kpasswd requires a > valid ccache to change passwords > > o PASSWD_PROGRAM_PATH defined as "kinit": > > - the program is called successfully, but requires the user > to enter > > Old PW > New PW > New PW > > even though the user already logged in with "Old PW" > >- With privsep > > o default: > > - sshd returns "Password changing is currently unsupported with > privilege separation" > > o with this commented out in do_pam_chauthtok(), thereby calling > pam_chauthtok() > >--------- > if (password_change_required) { > #if 0 > if (use_privsep) > fatal("Password changing is currently unsupported" > " with privilege separation"); > #endif > pamstate = OTHER; > pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK); >--------- > > - sshd successfully changes the password, although it exits > immediately afterward > >I can do more testing if anyone's interested. > >FYI. > >---------------------------------------------------------------------- >| Jim Hranicky, Senior SysAdmin UF/CISE Department | >| E314D CSE Building Phone (352) 392-1499 | >| jfh at cise.ufl.edu http://www.cise.ufl.edu/~jfh | >---------------------------------------------------------------------- > >"Given a choice between a complex, difficult-to-understand, disconcerting > explanation and a simplistic, comforting one, many prefer simplistic > comfort if it's remotely plausible, especially if it involves blaming > someone else for their problems." > -- Bob Lewis, _Infoworld_ > > > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Brian Hayward From mouring at etoh.eviladmin.org Wed Mar 26 04:28:12 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 25 Mar 2003 11:28:12 -0600 (CST) Subject: Call for testing for 3.6: password expiry? In-Reply-To: Message-ID: Personally, it is not frustrating as much as very poor wording. Once I explain it to my solaris users they understood it. However the term 'Login Password' throws them for a loop. - Ben On Tue, 25 Mar 2003 hayward at slothmud.org wrote: > This is how password changing works on solaris through "telnet" as well. > This is frustrating to users but may not be something easily solved in an > openssh password expiry solution. > > -- > Brian Hayward > > >Here are my observations about the latest version of the patch (passexpire18). > > > > Platform : Solaris 8 > > Auth Type : PAM > > PAM Module : Cusack pam_krb5 (v1.0) > > Kerberos Ver : MIT 1.2.6 > > > >- Without privsep > > > > o PASSWD_PROGRAM_PATH defined as "kpasswd": > > > > - the PAM module doesn't appear to create the ccache > > before kpasswd is called, and kpasswd requires a > > valid ccache to change passwords > > > > o PASSWD_PROGRAM_PATH defined as "kinit": > > > > - the program is called successfully, but requires the user > > to enter > > > > Old PW > > New PW > > New PW > > > > even though the user already logged in with "Old PW" > > > >- With privsep > > > > o default: > > > > - sshd returns "Password changing is currently unsupported with > > privilege separation" > > > > o with this commented out in do_pam_chauthtok(), thereby calling > > pam_chauthtok() > > > >--------- > > if (password_change_required) { > > #if 0 > > if (use_privsep) > > fatal("Password changing is currently unsupported" > > " with privilege separation"); > > #endif > > pamstate = OTHER; > > pam_retval = pam_chauthtok(__pamh, PAM_CHANGE_EXPIRED_AUTHTOK); > >--------- > > > > - sshd successfully changes the password, although it exits > > immediately afterward > > > >I can do more testing if anyone's interested. > > > >FYI. > > > >---------------------------------------------------------------------- > >| Jim Hranicky, Senior SysAdmin UF/CISE Department | > >| E314D CSE Building Phone (352) 392-1499 | > >| jfh at cise.ufl.edu http://www.cise.ufl.edu/~jfh | > >---------------------------------------------------------------------- > > > >"Given a choice between a complex, difficult-to-understand, disconcerting > > explanation and a simplistic, comforting one, many prefer simplistic > > comfort if it's remotely plausible, especially if it involves blaming > > someone else for their problems." > > -- Bob Lewis, _Infoworld_ > > > > > > > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > Brian Hayward > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Wed Mar 26 05:04:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 05:04:58 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030325180458.AA08194270@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From djast at cs.toronto.edu 2003-03-26 05:04 ------- This fails to handle cases like "foo\\" where the quote is preceded by a backslash but should not be escaped. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 13:47:40 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 13:47:40 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030326024740.CED2294207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #259 is|0 |1 obsolete| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 13:50:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 13:50:27 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030326025027.5AB8294207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-26 13:50 ------- Created an attachment (id=260) --> (http://bugzilla.mindrot.org/attachment.cgi?id=260&action=view) Patch to fix escapes of escapes I think this *might* be the winner (?). It seems to pass all the following filename tests: test test test"\ "\ test"one test\ test\"2 test\\\"""' test\\\\ Can anyone come up with another test? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 13:54:55 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 13:54:55 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030326025455.4B75A94207@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #260 is|0 |1 obsolete| | ------- Additional Comments From jason at devrandom.org 2003-03-26 13:54 ------- Created an attachment (id=261) --> (http://bugzilla.mindrot.org/attachment.cgi?id=261&action=view) Patch to fix escaping of quotes Ummm.. a little tired here and uploaded the wrong .patch file. This is the correct one that passes all of the following tests: test test test"\ "\ test"one test\ test\"2 test\\\"""' test\\\\ ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From alexandrefabre at azentis.com Wed Mar 26 16:37:52 2003 From: alexandrefabre at azentis.com (Alexandre Fabre) Date: Wed, 26 Mar 2003 06:37:52 +0100 Subject: Photos souvenir... Message-ID: <20030326052135.031769420F@shitei.mindrot.org> Si ce message ne s'affiche pas correctement cliquez ici : http://www.scanreflex.com/mail.htm Num?risez vos photos papiers et partagez les avec vos proches ! Faites revivre vos vieux albums souvenirs... Les avantages de notre services : Scanreflex num?rise vos photos ? partir de leur support papier (Nous n'avons pas besoin de vos n?gatifs) Scanreflex transfert vos photos sur un Cdrom dot? de toutes les fonctionnalit?s pour envoyer vos photos et r?aliser le diaporama de vos vacances, de votre mariage ou de votre anniversaire. Scanreflex vous propose des tarifs d?fiant toute concurrence sur le march? ! Scanreflex vous garantit une qualit? de traitement exemplaire et des d?lais de livraison tr?s rapide. Pour en savoir plus sur notre service, nous vous invitons ? Consulter notre site : http://www.scanreflex.com Contactez-nous au : 01-42-77-21-02 Alexandre Fabre Responsable d?veloppement Vous disposez d'un droit d'acc?s, de modification, de rectification et de suppression des donn?es qui vous concernent (article 34 de la loi "Informatique et Libert?s" du 6 janvier 1978). Si vous ne souhaitez plus recevoir ces messages, cliquez ici. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/000f9091/attachment.html From bugzilla-daemon at mindrot.org Wed Mar 26 19:11:36 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 19:11:36 +1100 (EST) Subject: [Bug 516] RhostsAuthentication failing with privsep Message-ID: <20030326081136.5144094210@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=516 Alf.Nicolaysen at web.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From Alf.Nicolaysen at web.de 2003-03-26 19:11 ------- Yes, indeed. With this option it worked. As I do not know, if it ever will be fixed or not, I switch to RSARhostsAuthentication and leave the RhostsAuthentication in this state. Thanx for your help Alf Nicolaysen ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 21:10:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 21:10:45 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20030326101045.A2DCD94227@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 astrand at lysator.liu.se changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |astrand at lysator.liu.se ------- Additional Comments From astrand at lysator.liu.se 2003-03-26 21:10 ------- >hmmm, alternately you can fake it by setting "DISPLAY=foo" But this is an ugly workaround. Then *other* applications might think that there actually is a working Xserver available. Face it: The need for transmitting a password to SSH in a secure way has *nothing* to do with X11 or terminal ttys, at all. Most applications have some good mechanism for doing this (vncviewer, rdesktop, smbclient, etc); it's just crazy that OpenSSH doesn't. Personally, I prefer a new option instead of SSH_ALWAYS_ASKPASS, but that is no big issue. I also think that the host key confirmation should not use SSH_ASKPASS, but another variable (for example, SSH_KEY_CONFIRM). The current GUI which requires the user to type "yes" is very un-intuitive. People just don't understand it. The GUI should have a "Yes/No" button dialog instead, just like Putty have. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 21:29:28 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 21:29:28 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20030326102928.1DB119422E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From dwmw2 at infradead.org 2003-03-26 21:29 ------- This bug also affects use of openssh under the Opie palmtop environment, and the current hackish workaround is to set the DISPLAY variable -- which _can_ have the effect of confusing some programs into thinking they're running in an X environment instead of under Opie, and doing the wrong thing. The presence or absence of a $DISPLAY should be entirely irrelevant to ssh when deciding whether to use $SSH_ASKPASS or not. There's certainly a case for contining the 'if a tty is available, use it' behaviour, but it should certainly be _possible_ to override that in some way other than actually detaching from the tty to prevent ssh from trying to use it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 22:59:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 22:59:04 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20030326115904.5462F94221@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From markus at openbsd.org 2003-03-26 22:59 ------- i don't think DISPLAY is confusing if you just set it for ssh. other programs don't care. as to typing "YES", this is intentional, since users should _think_ not click. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 26 23:42:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 26 Mar 2003 23:42:24 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20030326124224.DEC2594297@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From astrand at lysator.liu.se 2003-03-26 23:42 ------- Even if the DISPLAY requirement is not removed, we still need some method to trigger askpass usage if the tty is a terminal. Regarding the host key confirmation GUI: Having a non-intuitive GUI does not make people think more. Instead, they becomes occupied with the task of getting rid of the dialog. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dwmw2 at infradead.org Wed Mar 26 23:59:49 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 12:59:49 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326115904.5462F94221@shitei.mindrot.org> References: <20030326115904.5462F94221@shitei.mindrot.org> Message-ID: <1048683589.12528.266.camel@passion.cambridge.redhat.com> > i don't think DISPLAY is confusing if you just set it for ssh. > other programs don't care. But that's not really the way it works -- what actually happens is you set DISPLAY before running whatever programs (MUA, CVS GUI, other...) are going to invoke ssh, rather than having the hackish workaround in _every_ such user of ssh. I suppose we could have a shell script wrapper around SSH alone, which does nothing but set a DISPLAY variable if none is set, add '-x' to the options to prevent ssh itself from misinterpreting it, detach from the controlling tty, etc... Or alternatively we could just fix ssh ;) > as to typing "YES", this is intentional, since users should _think_ > not click. I agree. And it's not really hard for the ssh-askpass program to recognise the question text and do something other than the normal 'ask for textual input' anyway. -- dwmw2 From markus at openbsd.org Thu Mar 27 00:46:55 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 14:46:55 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048683589.12528.266.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> Message-ID: <20030326134654.GA848@folly> of course, you just set DISPLAY for ssh. On Wed, Mar 26, 2003 at 12:59:49PM +0000, David Woodhouse wrote: > > > i don't think DISPLAY is confusing if you just set it for ssh. > > other programs don't care. > > But that's not really the way it works -- what actually happens is you > set DISPLAY before running whatever programs (MUA, CVS GUI, other...) > are going to invoke ssh, rather than having the hackish workaround in > _every_ such user of ssh. > > I suppose we could have a shell script wrapper around SSH alone, which > does nothing but set a DISPLAY variable if none is set, add '-x' to the > options to prevent ssh itself from misinterpreting it, detach from the > controlling tty, etc... > > Or alternatively we could just fix ssh ;) > > > as to typing "YES", this is intentional, since users should _think_ > > not click. > > I agree. And it's not really hard for the ssh-askpass program to > recognise the question text and do something other than the normal 'ask > for textual input' anyway. > > > -- > dwmw2 From dwmw2 at infradead.org Thu Mar 27 00:55:43 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 13:55:43 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326134654.GA848@folly> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> Message-ID: <1048686943.12528.281.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 13:46, Markus Friedl wrote: > of course, you just set DISPLAY for ssh. You're advocating the option I gave below?...: > On Wed, Mar 26, 2003 at 12:59:49PM +0000, David Woodhouse wrote: > > I suppose we could have a shell script wrapper around SSH alone, which > > does nothing but set a DISPLAY variable if none is set, add '-x' to the > > options to prevent ssh itself from misinterpreting it, detach from the > > controlling tty, etc... I consider that an evil hack to work around the bug. What purpose does it serve to obey $SSH_ASKPASS only if $DISPLAY is also set? For what reason is it not acceptable to have a SIMON_SAYS_SSH_ASKPASS (or perhaps less sarcastically named) option in addition to SSH_ASKPASS, if it _is_ really necessary for $SSH_ASKPASS to be conditional on $DISPLAY? -- dwmw2 From markus at openbsd.org Thu Mar 27 02:01:07 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 16:01:07 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048686943.12528.281.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> Message-ID: <20030326150107.GA23703@folly> i'm talking about what you have not what's nice to have. On Wed, Mar 26, 2003 at 01:55:43PM +0000, David Woodhouse wrote: > On Wed, 2003-03-26 at 13:46, Markus Friedl wrote: > > of course, you just set DISPLAY for ssh. > > You're advocating the option I gave below?...: > > > On Wed, Mar 26, 2003 at 12:59:49PM +0000, David Woodhouse wrote: > > > I suppose we could have a shell script wrapper around SSH alone, which > > > does nothing but set a DISPLAY variable if none is set, add '-x' to the > > > options to prevent ssh itself from misinterpreting it, detach from the > > > controlling tty, etc... > > I consider that an evil hack to work around the bug. > > What purpose does it serve to obey $SSH_ASKPASS only if $DISPLAY is also > set? > > For what reason is it not acceptable to have a SIMON_SAYS_SSH_ASKPASS > (or perhaps less sarcastically named) option in addition to SSH_ASKPASS, > if it _is_ really necessary for $SSH_ASKPASS to be conditional on > $DISPLAY? > > -- > dwmw2 From bugzilla-daemon at mindrot.org Thu Mar 27 01:59:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 01:59:32 +1100 (EST) Subject: [Bug 521] PAM authentication not working in privilege seperation mode running in trusted system on hp-ux Message-ID: <20030326145932.655259422E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=521 Summary: PAM authentication not working in privilege seperation mode running in trusted system on hp-ux Product: Portable OpenSSH Version: 3.5p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Todd.Bowden at atosorigin.com The problem Im having is the following: System is running in trusted mode on hp-ux 11.0 SSHD is running in privlege seperation mode If I dont do anything to the source I get the following error: fatal: PAM session setup failed[33]: General Commercial Security error If I use the patch from BUG #14 passexpire18 I get the error: fatal: Password changing is currently unsupported with privilege separation If I take it out of privilege seperation mode it works. Is there a way to make it all work together (i.e., trusted system, privilege seperation)? What has HP done to the source of OpenSSH in order for theirs to work? Thanks for any help you can provide. Todd ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dwmw2 at infradead.org Thu Mar 27 02:07:23 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 15:07:23 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326150107.GA23703@folly> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> Message-ID: <1048691243.12528.321.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 15:01, Markus Friedl wrote: > i'm talking about what you have not what's nice to have. OK, then in that case I agree with you. We _do_ put random noise into $DISPLAY for the benefit of SSH, to work around the brokenness of SSH. I thought we were originally talking about what's nice to have -- which is for SSH to not require $DISPLAY to be set :) -- dwmw2 From markus at openbsd.org Thu Mar 27 03:17:59 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 17:17:59 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048691243.12528.321.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> Message-ID: <20030326161759.GA403@folly> it's not brokeness, it's never been intented this way. On Wed, Mar 26, 2003 at 03:07:23PM +0000, David Woodhouse wrote: > On Wed, 2003-03-26 at 15:01, Markus Friedl wrote: > > i'm talking about what you have not what's nice to have. > > OK, then in that case I agree with you. We _do_ put random noise into > $DISPLAY for the benefit of SSH, to work around the brokenness of SSH. > > I thought we were originally talking about what's nice to have -- which > is for SSH to not require $DISPLAY to be set :) > > -- > dwmw2 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From mjt at tls.msk.ru Thu Mar 27 03:25:25 2003 From: mjt at tls.msk.ru (Michael Tokarev) Date: Wed, 26 Mar 2003 19:25:25 +0300 Subject: Changing PAM service name in sshd_config, or running sshd as non-root Message-ID: <3E81D475.5030503@tls.msk.ru> Currently, openssh's PAM service name is a compile-time choice. That's fine when one uses one sshd to serve normal shell logins and the like. But this will not work IF sshd is nor run as root (which I don't want it to do), because pam_open_session usually requires access to one's shadow information (for account expiration perhaps?), and there is no way (and need: this sshd is installed to handle a specific task (or a set of tasks, really), where NO pam work is needed at all - to only allow port forwarding for several authorized (via keys) parties, something like tunnels - just to give an example) to give this information to a non-root process. So, sshd fails: debug1: ssh_rsa_verify: signature correct PAM rejected by account configuration[9]: Authentication service cannot retrieve authentication info. Accepted publickey for mjt from 127.0.0.1 port 1101 ssh2 Failed publickey for mjt from 127.0.0.1 port 1101 ssh2 (note the order of messages - PAM failure first, pubkey acceptance is second). So, that to say - why there is no e.g. PamServiceName configuration option in sshd_config? Thanks. /mjt From dwmw2 at infradead.org Thu Mar 27 03:29:06 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 16:29:06 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326161759.GA403@folly> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> Message-ID: <1048696146.14203.15.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 16:17, Markus Friedl wrote: > it's not brokeness, it's never been intented this way. I disagree. Requiring the entirely irrelevant $DISPLAY variable to be set in order to persuade ssh to honour the $SSH_ASKPASS variable is gratuitous, counterintuitive, and otherwise broken. IMHO. Are there reasons for it which I've missed? Do you have a reason to want it to stay the way it is? -- dwmw2 From markus at openbsd.org Thu Mar 27 03:38:19 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 17:38:19 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048696146.14203.15.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> Message-ID: <20030326163819.GA32266@folly> because it was intended that SSH_ASKPASS points to a x11 program. On Wed, Mar 26, 2003 at 04:29:06PM +0000, David Woodhouse wrote: > On Wed, 2003-03-26 at 16:17, Markus Friedl wrote: > > it's not brokeness, it's never been intented this way. > > I disagree. Requiring the entirely irrelevant $DISPLAY variable to be > set in order to persuade ssh to honour the $SSH_ASKPASS variable is > gratuitous, counterintuitive, and otherwise broken. IMHO. > > Are there reasons for it which I've missed? Do you have a reason to want > it to stay the way it is? > > -- > dwmw2 From dwmw2 at infradead.org Thu Mar 27 03:42:57 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 16:42:57 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326163819.GA32266@folly> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> <20030326163819.GA32266@folly> Message-ID: <1048696976.14203.20.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 16:38, Markus Friedl wrote: > because it was intended that SSH_ASKPASS points to a x11 program. You are not being clear. I ask not for the reason why it came to be this way -- I ask if there are reasons why it should _stay_ this way. Are you saying that it _IS_ intended that SSH_ASKPASS points to an X11 program, and that anyone trying to use it for any other purpose is abusing the mechanism? In which case, there is an outstanding feature request for something more generic than the existing X11-only SSH_ASKPASS. Or are you saying something else? -- dwmw2 From markus at openbsd.org Thu Mar 27 03:49:00 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 17:49:00 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048696976.14203.20.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> <20030326163819.GA32266@folly> <1048696976.14203.20.camel@passion.cambridge.redhat.com> Message-ID: <20030326164900.GA31720@folly> On Wed, Mar 26, 2003 at 04:42:57PM +0000, David Woodhouse wrote: > On Wed, 2003-03-26 at 16:38, Markus Friedl wrote: > > because it was intended that SSH_ASKPASS points to a x11 program. > > You are not being clear. I ask not for the reason why it came to be this > way -- I ask if there are reasons why it should _stay_ this way. > > Are you saying that it _IS_ intended that SSH_ASKPASS points to an X11 > program, and that anyone trying to use it for any other purpose is > abusing the mechanism? yes. > In which case, there is an outstanding feature request for something > more generic than the existing X11-only SSH_ASKPASS. > > Or are you saying something else? you are claiming that's it's broken the way it is. but it's not broken because it's the way it's intented. the original intentions need to be revised, that's all. From bugzilla-daemon at mindrot.org Thu Mar 27 03:47:01 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 03:47:01 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030326164701.42747942B7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 Todd.Bowden at atosorigin.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |todd.bowden at atosorigin.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From kingstrider78 at yahoo.com Thu Mar 27 03:59:25 2003 From: kingstrider78 at yahoo.com (kingstrider) Date: Wed, 26 Mar 2003 08:59:25 -0800 (PST) Subject: OpenSSH api Message-ID: <20030326165925.80673.qmail@web41004.mail.yahoo.com> Hello: I want to use OpenSSH to convert my application that uses telnet into SSH. Currently I have a VB client that communicates with a remote database server using Informix-4GL. This communication is done using a telnet session developed by Winsock api. I need to convert this into SSH. Is there any OpenSSH api/library available that can help me in doing this ( i know u can do it by OpenSSL) For example: instead of send(Socket, .....,.....); i need ssl_send(key,...,Socket...) Thanks, FRS --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/cd385375/attachment.html From sales at bodacion.com Thu Mar 27 03:59:38 2003 From: sales at bodacion.com (Bodacion Technologies) Date: Wed, 26 Mar 2003 08:59:38 -0800 Subject: Reminder: Please join us! Message-ID: ========================================================== Reminder: Please join us! ========================================================== Hello, Bodacion Technologies invites you to learn more about our secure Web services appliance, HYDRA. Learn what your network architecture will look like implementing HYDRA, what standards and protocols HYDRA incorporates into its services, and how the cost of owning a HYDRA compares to your current setup. When: Friday, March 28th at 10:00am CST or 12:30pm CST Who: Given by Bodacion Technologies Where: Online! (At the comfort of your own desk) Why: To learn about the most secure Web services appliance on the planet! To join us, simply complete the brief registration form available at http://www.bodacion.com/webinar.html or to register by phone, call Jenny at 847-842-9008. Register now as limited seats remain! - Surrender is Not an Option - Click here for more information! - http://www.bodacion.com/introtowebinar.html Click here to register! - http://www.bodacion.com/webinar.html Bodacion Technologies -- Advanced Solutions in Web Security and Reliability ========================================================== Bodacion Technologies 18- 3 E. Dundee Road Suite 300 Barrington, IL 60010 Web Site: http://www.bodacion.com Email: sales at bodacion.com Phone: 847-842-9008 Fax: 847-842-1731 _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/sp?c=27695&s=55E53ECCE39BD5A1&m=9 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 43 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 4176 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 816 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1803 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 43 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/37da2aa1/attachment-0004.gif From bugzilla-daemon at mindrot.org Thu Mar 27 04:11:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 04:11:27 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030326171127.BAD50942B5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From Todd.Bowden at atosorigin.com 2003-03-27 04:11 ------- The system is configured as HP-UX 11.0 in trusted system mode, running OpenSSH 3.5p1 in privilege seperation mode. If the user is forced to change their password it exits immediately. I have tried using the patch supplied by Damien Miller on HP-UX. The results were the following: error messages in the syslog.log: Mar 26 12:10:30 uspenp4 sshd[25577]: PAM rejected by account configuration[10]: Get new authentication token Mar 26 12:10:30 uspenp4 sshd[25577]: fatal: monitor_read: unsupported request: 24 output of ssh -v -v -l : OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to uspenp4 [130.140.173.134] port 22. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.5p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 140/256 debug1: bits set: 1580/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'uspenp4' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:1 debug1: bits set: 1608/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard- interactive debug1: next auth method to try is publickey debug1: try privkey: /.ssh/identity debug1: try privkey: /.ssh/id_rsa debug1: try privkey: /.ssh/id_dsa debug2: we did not send a packet, disable method debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard- interactive debug2: we did not send a packet, disable method debug1: next auth method to try is password us14592 at uspenp4's password: debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: channel_free: channel 0: client-session, nchannels 1 Connection to uspenp4 closed by remote host. Connection to uspenp4 closed. debug1: Transferred: stdin 0, stdout 0, stderr 77 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1291.6 debug1: Exit status -1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jfh at cise.ufl.edu Thu Mar 27 04:32:45 2003 From: jfh at cise.ufl.edu (James F.Hranicky) Date: Wed, 26 Mar 2003 12:32:45 -0500 Subject: Password expiry in auth-krb5.c Message-ID: <20030326123245.50a8a170.jfh@cise.ufl.edu> Due to difficulties in getting PAM (with krb5) password expiry working consistently on multiple platforms, I'd like to see if I could hack something into auth-krb5.c to do so. Here's a backtrace when stopped in auth_krb5_password: #0 auth_krb5_password (authctxt=0x8e148, password=0x90250 "XXXXXXXX") at auth-krb5.c:270 #1 0x274d8 in auth_password (authctxt=0x8e148, password=0x90250 "XXXXXXXX") at auth-passwd.c:140 #2 0x380fc in mm_answer_authpassword (socket=9, m=0xffbeef28) at monitor.c:608 #3 0x376c4 in monitor_read (pmonitor=0x8bec0, ent=0x84150, pent=0xffbeefbc) at monitor.c:371 #4 0x37244 in monitor_child_preauth (pmonitor=0x8bec0) at monitor.c:280 #5 0x1aaac in privsep_preauth () at sshd.c:603 #6 0x1d45c in main (ac=3, av=0xffbefaac) at sshd.c:1497 At first, I simply tried to add the stock Kerberos prompter to krb5_get_init_creds_password: problem = krb5_get_init_creds_password(authctxt->krb5_ctx, &creds, authctxt->krb5_user, (char *)password, krb5_prompter_posix, NULL, 0, NULL, NULL); however, this returned KRB5_LIBOS_CANTREADPWD due to the fact that fds 0 and 1 are closed and not connected to a socket. From dwmw2 at infradead.org Thu Mar 27 04:54:27 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 26 Mar 2003 17:54:27 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326164900.GA31720@folly> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> <20030326163819.GA32266@folly> <1048696976.14203.20.camel@passion.cambridge.redhat.com> <20030326164900.GA31720@folly> Message-ID: <1048701266.14203.89.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 16:49, Markus Friedl wrote: > you are claiming that's it's broken the way it is. > but it's not broken because it's the way it's intented. > > the original intentions need to be revised, that's all. Ok, ok -- so it's a perfect implementation of an _intention_ which now turns out to be broken w.r.t. the real world :) I didn't realise that distinction really mattered. The assumption that the ability to fork a separate process to handle password/passphrase/interaction requests is only required by X11-capable clients is not valid. Therefore, the requirement for $DISPLAY to be set is not useful. Bug #69 has a patch attached which fixes this. Can we apply it? -- dwmw2 From bafolabi at olumo.net Thu Mar 27 07:16:11 2003 From: bafolabi at olumo.net (B A) Date: Wed, 26 Mar 2003 15:16:11 -0500 Subject: Fund Message-ID: <200303262016.h2QKGBY02453@host14.apollohosting.com> MR. BAYO AFOLABI TRADE BANK PLC ALTERNATIVE EMAIL: bafolabi at olumo.net CORE INVESTMENT STRATEGY It is with trust and confidence that I make this urgent and important proposal to you in view of the fact that you are trust worthy and reliable. Currently I have a business that I think would be of interest to you and your company. I am the Western District Bank Manager of TRADE BANK PLC of Nigeria. However, there is an account opened in the bank in 1993 and since 1998, no body has operated this account again. After careful investigation, I discovered that the owner of this account was the president of ARC CONSTRUCTION COMPANY LTD, a foreigner who died in 1998. The account has no beneficiary at present and investigation has proved that his company does not know anything about the account, the total amount is US$25. 5 (Twenty Five Point Five Million United States Dollars Only). In light of the above fact, I need your assistance to handle this transaction with you, thereby providing your bank account or any account of your choice where this fund will be remitted. Your assistance as a foreigner is necessary because the management is ready to welcome anybody preferably a foreigner who has the correct information of the account which I will give you immediately, if you are capable to conclude this transaction with me. Now that the management of the bank has ordered that all dormant account to be frozen. On the strength of this order, I wish to take advantage of this situation and present your company as beneficiary and get it transferred to your designated account. Be informed that all documents related to this transaction will be destroyed immediately after the transfer, since every arrangement to transfer this fund to any account you will provide has been concluded. Furthermore, on receiving your positive response, I will apply for annual leave for our fact to face meeting in your country for the sharing. I will give you 20% of the fund for your assistance though the percentage is negotiable and I will not contact any other person until I am convinced that you are not interested. I will like to have your phone and fax number for easy communication. Best regards, BAYO AFOLABI US INTERNET FAX NUMBER FOR QUICK CONTACT: 18012178347 From jmknoble at pobox.com Thu Mar 27 07:20:16 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 26 Mar 2003 15:20:16 -0500 Subject: Changing PAM service name in sshd_config, or running sshd as non-root In-Reply-To: <3E81D475.5030503@tls.msk.ru> References: <3E81D475.5030503@tls.msk.ru> Message-ID: <20030326202016.GA10577@crawfish.ais.com> Circa 2003-03-26 19:25:25 +0300 dixit Michael Tokarev: : Currently, openssh's PAM service name is a compile-time choice. [...] : So, that to say - why there is no e.g. PamServiceName configuration : option in sshd_config? There is one, it's just called something different: ln -s /path/to/sshd /path/to/your-favorite-ssh-service-name OpenSSH's sshd uses the basename of argv[0] as the service name, as you would know if you were to read the INSTALL file that accompanies OpenSSH-3.5p1. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/49f654fe/attachment.bin From jmknoble at pobox.com Thu Mar 27 07:32:49 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 26 Mar 2003 15:32:49 -0500 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048683589.12528.266.camel@passion.cambridge.redhat.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> Message-ID: <20030326203249.GB10577@crawfish.ais.com> Circa 2003-03-26 12:59:49 +0000 dixit David Woodhouse: : > as to typing "YES", this is intentional, since users should _think_ : > not click. : : I agree. And it's not really hard for the ssh-askpass program to : recognise the question text and do something other than the normal 'ask : for textual input' anyway. Actually, i would rather not have ssh-askpass try to do anything with the text it's given except display it. Right now, x11-ssh-askpass only displays 8-bit text in the POSIX locale (i.e., ISO-8859-1), but i have plans in the works to make it work with whatever the locale is and whatever fontset is configured for that locale, so that eventually it will be able to display at least UTF-8 text. If you want a separate behavior, that request should be explicit: either an explicit option to ssh-askpass (e.g., 'ssh-askpass --yesno') or (probably better) a separate program (e.g., 'ssh-confirm'). Care to come up with a specification? As for difficulty, once i've internationalized x11-ssh-askpass, creating x11-ssh-confirm isn't difficult, but it is a matter of time, which is in short supply for me at the moment. A current alternative for x11-ssh-confirm might be a suitable wrapper around Xdialog: http://freshmeat.net/projects/xdialog/ -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) Stop the War on Freedom ... Start the War on Poverty! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030326/b9790652/attachment.bin From djm at mindrot.org Thu Mar 27 08:34:07 2003 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2003 08:34:07 +1100 Subject: OpenSSH api In-Reply-To: <20030326165925.80673.qmail@web41004.mail.yahoo.com> References: <20030326165925.80673.qmail@web41004.mail.yahoo.com> Message-ID: <3E821CCF.90309@mindrot.org> kingstrider wrote: > Hello: > > I want to use OpenSSH to convert my application that uses telnet into > SSH. Currently I have a VB client that communicates with a remote > database server using Informix-4GL. This communication is done using a > telnet session developed by Winsock api. I need to convert this into > SSH. Is there any OpenSSH api/library available that can help me in > doing this ( i know u can do it by OpenSSL) > > For example: instead of send(Socket, .....,.....); > > i need ssl_send(key,...,Socket...) There is not SSH API at present, you need to open an instance of OpenSSH in a subprocess and use it to do the communication for you. See sftp.c for an example of this. -d From markus at openbsd.org Thu Mar 27 08:56:13 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Mar 2003 22:56:13 +0100 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <1048701266.14203.89.camel@passion.cambridge.redhat.com> References: <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> <20030326163819.GA32266@folly> <1048696976.14203.20.camel@passion.cambridge.redhat.com> <20030326164900.GA31720@folly> <1048701266.14203.89.camel@passion.cambridge.redhat.com> Message-ID: <20030326215613.GA11953@folly> On Wed, Mar 26, 2003 at 05:54:27PM +0000, David Woodhouse wrote: > On Wed, 2003-03-26 at 16:49, Markus Friedl wrote: > > you are claiming that's it's broken the way it is. > > but it's not broken because it's the way it's intented. > > > > the original intentions need to be revised, that's all. > > Ok, ok -- so it's a perfect implementation of an _intention_ which now > turns out to be broken w.r.t. the real world :) > > I didn't realise that distinction really mattered. > > The assumption that the ability to fork a separate process to handle > password/passphrase/interaction requests is only required by X11-capable > clients is not valid. Therefore, the requirement for $DISPLAY to be set > is not useful. Bug #69 has a patch attached which fixes this. Can we > apply it? after the 3.6 release From bugzilla-daemon at mindrot.org Thu Mar 27 09:06:07 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 09:06:07 +1100 (EST) Subject: [Bug 520] Recursive operations Message-ID: <20030326220607.B58AA94214@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=520 ------- Additional Comments From mouring at eviladmin.org 2003-03-27 09:06 ------- fts would be easy enough to use for recursive. I think 'put' can be written in a matter of a night or two (Assuming one is awake ), but there is one minor downfall to fts. It assuming all access is local. And unlike glob it does not support the ability to override opendir(), readdir(), closedir(), lstat () and stat(). Unless there is something I'm missing get and put can't both use fts effectly without forking the code and rewriting small chunks of it. Would be nice if fts could be modified to support virtualizing those function calls, but with it having a chance of going into POSIX (some century) I doubt the API can change much. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 15:49:27 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 15:49:27 +1100 (EST) Subject: [Bug 522] terse message prompt when ssh-add fails Message-ID: <20030327044927.44E3C9420D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=522 Summary: terse message prompt when ssh-add fails Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-add AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: donfede at casagrau.org I (and surely others) have multiple keys which I add to my ssh-agent upon starting X. I use ssh-askpass to display a pretty password prompt, and it normally works very well. Unfortunately, the "error" or "retry" message prompted when a passphrase is incorrectly entered, does not RE-display the key to which the passphrase is being entered. It can be difficult to tell which key the passphrase prompt was for. Below is a simple patch to solve this problem. The solution lies with ssh-add, since ssh-askpass is simply passing the text to the user. thanks, donfede #################### donfede at xwing:~/projects/hack_ssh-agent/openssh$ cvs diff -u ssh-add.c Index: ssh-add.c =================================================================== RCS file: /cvs/openssh/ssh-add.c,v retrieving revision 1.71 diff -u -r1.71 ssh-add.c --- ssh-add.c 10 Mar 2003 00:21:18 -0000 1.71 +++ ssh-add.c 27 Mar 2003 04:36:59 -0000 @@ -164,7 +164,8 @@ if (private != NULL) break; clear_pass(); - strlcpy(msg, "Bad passphrase, try again: ", sizeof msg); + snprintf(msg, sizeof msg, "Bad passphrase, try again for %.200s: ", + comment); } } ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 15:52:41 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 15:52:41 +1100 (EST) Subject: [Bug 522] terse message prompt when ssh-add fails Message-ID: <20030327045241.D938494213@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=522 ------- Additional Comments From donfede at casagrau.org 2003-03-27 15:52 ------- Created an attachment (id=262) --> (http://bugzilla.mindrot.org/attachment.cgi?id=262&action=view) a simple fix Here is the same patch, but in an attachment (the web form munged of the lines). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From leonard.raphael at sonera.com Thu Mar 27 18:23:03 2003 From: leonard.raphael at sonera.com (Raphael Leonard) Date: Thu, 27 Mar 2003 09:23:03 +0200 Subject: Fund Message-ID: WARNING!! Guys the letter below is fake. It is usually sent by some Nigerian frauds to steal money from Foreigners. Please ignore the mail below and don't give any attention to it. The sender might be one of those criminals from Nigeria trying to get money from people. I am also a Nigerian but not one of those. So, please be warned and stay clear. Just for your information. Have a great week there!! //Leonard -----Original Message----- From: B A [mailto:bafolabi at olumo.net] Sent: Wed 26.3.2003 22:16 To: openssh-unix-dev at mindrot.org Cc: Subject: Re: Fund MR. BAYO AFOLABI TRADE BANK PLC ALTERNATIVE EMAIL: bafolabi at olumo.net CORE INVESTMENT STRATEGY It is with trust and confidence that I make this urgent and important proposal to you in view of the fact that you are trust worthy and reliable. Currently I have a business that I think would be of interest to you and your company. I am the Western District Bank Manager of TRADE BANK PLC of Nigeria. However, there is an account opened in the bank in 1993 and since 1998, no body has operated this account again. After careful investigation, I discovered that the owner of this account was the president of ARC CONSTRUCTION COMPANY LTD, a foreigner who died in 1998. The account has no beneficiary at present and investigation has proved that his company does not know anything about the account, the total amount is US$25. 5 (Twenty Five Point Five Million United States Dollars Only). In light of the above fact, I need your assistance to handle this transaction with you, thereby providing your bank account or any account of your choice where this fund will be remitted. Your assistance as a foreigner is necessary because the management is ready to welcome anybody preferably a foreigner who has the correct information of the account which I will give you immediately, if you are capable to conclude this transaction with me. Now that the management of the bank has ordered that all dormant account to be frozen. On the strength of this order, I wish to take advantage of this situation and present your company as beneficiary and get it transferred to your designated account. Be informed that all documents related to this transaction will be destroyed immediately after the transfer, since every arrangement to transfer this fund to any account you will provide has been concluded. Furthermore, on receiving your positive response, I will apply for annual leave for our fact to face meeting in your country for the sharing. I will give you 20% of the fund for your assistance though the percentage is negotiable and I will not contact any other person until I am convinced that you are not interested. I will like to have your phone and fax number for easy communication. Best regards, BAYO AFOLABI US INTERNET FAX NUMBER FOR QUICK CONTACT: 18012178347 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From dwmw2 at infradead.org Thu Mar 27 20:11:54 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 27 Mar 2003 09:11:54 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326215613.GA11953@folly> References: <20030326134654.GA848@folly> <1048686943.12528.281.camel@passion.cambridge.redhat.com> <20030326150107.GA23703@folly> <1048691243.12528.321.camel@passion.cambridge.redhat.com> <20030326161759.GA403@folly> <1048696146.14203.15.camel@passion.cambridge.redhat.com> <20030326163819.GA32266@folly> <1048696976.14203.20.camel@passion.cambridge.redhat.com> <20030326164900.GA31720@folly> <1048701266.14203.89.camel@passion.cambridge.redhat.com> <20030326215613.GA11953@folly> Message-ID: <1048756314.14203.101.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 21:56, Markus Friedl wrote: > On Wed, Mar 26, 2003 at 05:54:27PM +0000, David Woodhouse wrote: > Bug #69 has a patch attached which fixes this. Can we apply it? > > after the 3.6 release Cool. Thank you. -- dwmw2 From dwmw2 at infradead.org Thu Mar 27 20:20:37 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: 27 Mar 2003 09:20:37 +0000 Subject: [Bug 69] Generalize SSH_ASKPASS In-Reply-To: <20030326203249.GB10577@crawfish.ais.com> References: <20030326115904.5462F94221@shitei.mindrot.org> <1048683589.12528.266.camel@passion.cambridge.redhat.com> <20030326203249.GB10577@crawfish.ais.com> Message-ID: <1048756837.14203.114.camel@passion.cambridge.redhat.com> On Wed, 2003-03-26 at 20:32, Jim Knoble wrote: > Circa 2003-03-26 12:59:49 +0000 dixit David Woodhouse: > > : > as to typing "YES", this is intentional, since users should _think_ > : > not click. > : > : I agree. And it's not really hard for the ssh-askpass program to > : recognise the question text and do something other than the normal 'ask > : for textual input' anyway. > > Actually, i would rather not have ssh-askpass try to do anything with > the text it's given except display it. Yeah, I suppose you're probably right. Parsing text strings isn't really ideal, especially if they're localised. I'm not too bothered about typing 'yes', and I can sort of see the point in forcing the user to do that explicitly although I suspect it's a little OTT -- but I really do want ssh-askpass to handle s/key for me :) > If you want a separate behavior, that request should be explicit: > either an explicit option to ssh-askpass (e.g., 'ssh-askpass --yesno') > or (probably better) a separate program (e.g., 'ssh-confirm'). > > Care to come up with a specification? Hmmm. We really do have to be careful about backwards compatibility. So a separate program probably accompanied by a separate environment variable for it (SSH_CONFIRM?) is likely to be the best way forward. -- dwmw2 From bugzilla-daemon at mindrot.org Thu Mar 27 20:34:04 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 20:34:04 +1100 (EST) Subject: [Bug 523] ssh saves only host/ip information in known_hosts while port information is missing Message-ID: <20030327093404.39E6E9420D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=523 Summary: ssh saves only host/ip information in known_hosts while port information is missing Product: Portable OpenSSH Version: 3.5p1 Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: misiek at pld.org.pl ssh saves only host/ip information in known_hosts while port information is missing. When using masquerade I often use destination nat (DNAT) under Linux to allow connections from Internet to hosts behind masquerade like this: iptables -A PREROUTING -t nat -p tcp -d 12.12.12.12 --dport 11022 -j DNAT --to 172.16.100.4:22 That works wery well but ssh doesn't save information about port and then when connecting to 12.12.12.12 port 22 or port 11022 (different sshd's) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for some.host.pl has changed, and the key for the according IP address 12.12.12.12 has a different value. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. Offending key for IP in /home/users/misiek/.ssh/known_hosts:79 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is a6:64:aa:6c:da:af:b5:be:99:d3:fc:21:0b:84:47:7a. Please contact your system administrator. Add correct host key in /home/users/misiek/.ssh/known_hosts to get rid of this message. That message is of course not correct since there are two different sshd (on different machines) using the same IP. I think that solution would be to add port number information to known_hosts when it's different than default one (22). That maybe won't break compatibility with other ssh software and will avoid such problems like mine. Is that proposition ok with you? (then I'll think about preparing patch :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 20:53:13 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 20:53:13 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030327095313.48D40942B5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From misiek at pld.org.pl 2003-03-27 20:53 ------- I've applied patch posted here but it doesn't change nothing since still do_pam_session() is not called as root! See strace here: http://bugzilla.mindrot.org/show_bug.cgi?id=301 And this: [misiek at arm ~/rpm/BUILD/openssh-3.5p1]$ diff -u ~/rpm/SOURCES/openssh-3.5p1/session.c session.c --- /home/users/misiek/rpm/SOURCES/openssh-3.5p1/session.c Thu Mar 27 10:46:17 2003 +++ session.c Thu Mar 27 10:52:33 2003 @@ -604,6 +604,7 @@ close(ttyfd); #if defined(USE_PAM) + log("uid=%d, euid=%d\n", getuid(), geteuid()); do_pam_session(s->pw->pw_name, s->tty); do_pam_setcred(1); #endif Mar 27 10:53:18 arm sshd[3951]: Accepted password for misiek from ::ffff:127.0.0.1 port 4992 ssh2 Mar 27 10:53:18 arm sshd[4645]: uid=1000, euid=1000 Mar 27 10:53:18 arm sshd(pam_unix)[4645]: session opened for user misiek by misiek(uid=1000) Mar 27 10:53:18 arm sshd[4645]: fatal: PAM session setup failed[6]: Permission denied You _cannot_ increase your limits (like core size limit) when you are not root. See bug 301 for details. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 21:35:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 21:35:43 +1100 (EST) Subject: [Bug 523] ssh saves only host/ip information in known_hosts while port information is missing Message-ID: <20030327103543.8068F9420D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=523 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2003-03-27 21:35 ------- Please check existing bug reports *** This bug has been marked as a duplicate of 454 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 21:35:45 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 21:35:45 +1100 (EST) Subject: [Bug 454] SSH doesn't consider distinguish ports for host-key verification Message-ID: <20030327103545.414A6942B5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=454 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |misiek at pld.org.pl ------- Additional Comments From djm at mindrot.org 2003-03-27 21:35 ------- *** Bug 523 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 21:50:31 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 21:50:31 +1100 (EST) Subject: [Bug 521] PAM authentication not working in privilege seperation mode running in trusted system on hp-ux Message-ID: <20030327105031.E06A3942E0@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=521 ------- Additional Comments From dtucker at zip.com.au 2003-03-27 21:50 ------- Try one of the HP-UX specific patches attached to bug #423 (eg attachment #163). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 22:05:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 22:05:53 +1100 (EST) Subject: [Bug 524] Keyboard-interactive PAM back end hides information Message-ID: <20030327110553.22A56942DF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=524 Summary: Keyboard-interactive PAM back end hides information Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: pont_bug_mindrot at soua.net The mapping from pam_message to SSH_MSG_USERAUTH_INFO_REQUEST currently puts anything that isn't a prompt (information request) into the first prompt. As prompts may be truncated that isn't really the right thing to do, this patch puts those in the instruction field instead. (Lost information is normally not a problem, but with a PAM module that puts the challenge in one of those message it may be, and I can't think of any reason it's better to have the text in the first prompt). I did the patch for someone else and now there seems to be some other problem with using PAM from sshd on my system, so consider it untested. --CUT-- --- auth2-pam.c.old Fri Mar 21 11:10:57 2003 +++ auth2-pam.c Thu Mar 27 10:52:08 2003 @@ -84,7 +84,14 @@ packet_start(SSH2_MSG_USERAUTH_INFO_REQUEST); packet_put_cstring(""); /* Name */ - packet_put_cstring(""); /* Instructions */ + + if (text) { + packet_put_cstring(text); + xfree(text); + text = NULL; + } else + packet_put_cstring(""); /* Instructions */ + packet_put_cstring(""); /* Language */ packet_put_int(context_pam2.num_expected); @@ -96,12 +103,7 @@ continue; context_pam2.prompts[j++] = i; - if (text) { - message_cat(&text, PAM_MSG_MEMBER(msg, i, msg)); - packet_put_cstring(text); - text = NULL; - } else - packet_put_cstring(PAM_MSG_MEMBER(msg, i, msg)); + packet_put_cstring(PAM_MSG_MEMBER(msg, i, msg)); packet_put_char(style == PAM_PROMPT_ECHO_ON); } packet_send(); --CUT-- ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 27 22:08:38 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 27 Mar 2003 22:08:38 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030327110838.40ADE94242@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From djm at mindrot.org 2003-03-27 22:08 ------- Created an attachment (id=263) --> (http://bugzilla.mindrot.org/attachment.cgi?id=263&action=view) Call pam_session after fork, before setusercontext This moves the call to pam_session to after the fork() but before the call to do_setusercontext (which gives up root privs). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 00:43:58 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 00:43:58 +1100 (EST) Subject: [Bug 521] PAM authentication not working in privilege seperation mode running in trusted system on hp-ux Message-ID: <20030327134358.5E68594217@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=521 Todd.Bowden at atosorigin.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From Todd.Bowden at atosorigin.com 2003-03-28 00:43 ------- *** This bug has been marked as a duplicate of 423 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 00:44:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 00:44:00 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030327134400.217C59424A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 Todd.Bowden at atosorigin.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Todd.Bowden at atosorigin.com ------- Additional Comments From Todd.Bowden at atosorigin.com 2003-03-28 00:43 ------- *** Bug 521 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 00:45:35 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 00:45:35 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030327134535.0C22C94250@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From misiek at pld.org.pl 2003-03-28 00:45 ------- but whole do_exec_pty() is run with user rights: Mar 27 14:51:53 arm sshd[16580]: Accepted password for misiek from ::ffff:127.0.0.1 port 1354 ssh2 Mar 27 14:51:53 arm sshd[10120]: server_input_channel_req: uid=1000 euid=1000 Mar 27 14:51:53 arm sshd[10120]: server_input_channel_req: uid=1000 euid=1000 Mar 27 14:51:53 arm sshd[10120]: session_shell_req: uid=1000 euid=1000 Mar 27 14:51:53 arm sshd[10120]: do_exec_pty: uid=1000 euid=1000 Mar 27 14:51:53 arm sshd[21054]: just before do_pam_session() uid=1000 euid=1000 Mar 27 14:51:53 arm sshd(pam_unix)[21054]: session opened for user misiek by misiek(uid=1000) Mar 27 14:51:53 arm sshd[21054]: fatal: PAM session setup failed[6]: Permission denied separation enabled of course ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 00:46:42 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 00:46:42 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20030327134642.91FED942ED@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From Todd.Bowden at atosorigin.com 2003-03-28 00:46 ------- The patch id-162 has fixed my problem of changing passwords running in privileged seperation mode and in a trusted system on HP-UX 11. Thanks for all the help. Todd ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 01:14:24 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 01:14:24 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030327141424.EB64E942ED@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 Todd.Bowden at atosorigin.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|Todd.Bowden at atosorigin.com | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From doctor at doctor.nk.ca Fri Mar 28 02:17:04 2003 From: doctor at doctor.nk.ca (The Doctor) Date: Thu, 27 Mar 2003 08:17:04 -0700 Subject: Fund In-Reply-To: ; from leonard.raphael@sonera.com on Thu, Mar 27, 2003 at 09:23:03AM +0200 References: Message-ID: <20030327081704.E1329@doctor.nk.ca> Just reporter spamer to pamcop and be done with it. On Thu, Mar 27, 2003 at 09:23:03AM +0200, Raphael Leonard wrote: > WARNING!! > > Guys the letter below is fake. It is usually sent by some Nigerian frauds to steal money from Foreigners. Please ignore the mail below and don't give any attention to it. The sender might be one of those criminals from Nigeria trying to get money from people. > > I am also a Nigerian but not one of those. So, please be warned and stay clear. > > Just for your information. Have a great week there!! > > //Leonard > > > > -----Original Message----- > From: B A [mailto:bafolabi at olumo.net] > Sent: Wed 26.3.2003 22:16 > To: openssh-unix-dev at mindrot.org > Cc: > Subject: Re: Fund > MR. BAYO AFOLABI > TRADE BANK PLC > ALTERNATIVE EMAIL: bafolabi at olumo.net > > CORE INVESTMENT STRATEGY > > It is with trust and confidence that I make this urgent and important proposal to you in view of the fact that you are trust worthy and reliable. Currently I have a business that I think would be of interest to you and your company. > > I am the Western District Bank Manager of TRADE BANK PLC of Nigeria. However, there is an account opened in the bank in 1993 and since 1998, no body has operated this account again. After careful investigation, I discovered that the owner of this account was the president of ARC CONSTRUCTION COMPANY LTD, a foreigner who died in 1998. The account has no beneficiary at present and investigation has proved that his company does not know anything about the account, the total amount is US$25. 5 (Twenty Five Point Five Million United States Dollars Only). > > In light of the above fact, I need your assistance to handle this transaction with you, thereby providing your bank account or any account of your choice where this fund will be remitted. Your assistance as a foreigner is necessary because the management is ready to welcome anybody preferably a foreigner who has the correct information of the account which I will give you immediately, if you are capable to conclude this transaction with me. > > Now that the management of the bank has ordered that all dormant account to be frozen. On the strength of this order, I wish to take advantage of this situation and present your company as beneficiary and get it transferred to your designated account. Be informed that all documents related to this transaction will be destroyed immediately after the transfer, since every arrangement to transfer this fund to any account you will provide has been concluded. > > Furthermore, on receiving your positive response, I will apply for annual leave for our fact to face meeting in your country for the sharing. I will give you 20% of the fund for your assistance though the percentage is negotiable and I will not contact any other person until I am convinced that you are not interested. > > I will like to have your phone and fax number for easy communication. > > Best regards, > BAYO AFOLABI > US INTERNET FAX NUMBER FOR QUICK CONTACT: 18012178347 > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Quebec - elir les gagnant qui peut deplacer le PQ la plus vite From jpuckett at lamuscompany.com Fri Mar 28 02:54:42 2003 From: jpuckett at lamuscompany.com (James Puckett) Date: Thu, 27 Mar 2003 10:54:42 -0500 Subject: Fund In-Reply-To: <20030327081704.E1329@doctor.nk.ca> References: <20030327081704.E1329@doctor.nk.ca> Message-ID: <3E831EC2.1040805@lamuscompany.com> On that topic, does anyone mind if I call the marketing departments of the companies that have been subscribing this list to their announcement mailing lists and demand that they stop spamming us? The Doctor wrote: > Just reporter spamer to pamcop and be done with it. > > On Thu, Mar 27, 2003 at 09:23:03AM +0200, Raphael Leonard wrote: > >>WARNING!! >> >>Guys the letter below is fake. It is usually sent by some Nigerian frauds to steal money from Foreigners. Please ignore the mail below and don't give any attention to it. The sender might be one of those criminals from Nigeria trying to get money from people. >> >>I am also a Nigerian but not one of those. So, please be warned and stay clear. >> >>Just for your information. Have a great week there!! >> >>//Leonard >> >> >> >>-----Original Message----- >>From: B A [mailto:bafolabi at olumo.net] >>Sent: Wed 26.3.2003 22:16 >>To: openssh-unix-dev at mindrot.org >>Cc: >>Subject: Re: Fund >>MR. BAYO AFOLABI >>TRADE BANK PLC >>ALTERNATIVE EMAIL: bafolabi at olumo.net >> >>CORE INVESTMENT STRATEGY >> >>It is with trust and confidence that I make this urgent and important proposal to you in view of the fact that you are trust worthy and reliable. Currently I have a business that I think would be of interest to you and your company. >> >>I am the Western District Bank Manager of TRADE BANK PLC of Nigeria. However, there is an account opened in the bank in 1993 and since 1998, no body has operated this account again. After careful investigation, I discovered that the owner of this account was the president of ARC CONSTRUCTION COMPANY LTD, a foreigner who died in 1998. The account has no beneficiary at present and investigation has proved that his company does not know anything about the account, the total amount is US$25. 5 (Twenty Five Point Five Million United States Dollars Only). >> >> In light of the above fact, I need your assistance to handle this transaction with you, thereby providing your bank account or any account of your choice where this fund will be remitted. Your assistance as a foreigner is necessary because the management is ready to welcome anybody preferably a foreigner who has the correct information of the account which I will give you immediately, if you are capable to conclude this transaction with me. >> >>Now that the management of the bank has ordered that all dormant account to be frozen. On the strength of this order, I wish to take advantage of this situation and present your company as beneficiary and get it transferred to your designated account. Be informed that all documents related to this transaction will be destroyed immediately after the transfer, since every arrangement to transfer this fund to any account you will provide has been concluded. >> >>Furthermore, on receiving your positive response, I will apply for annual leave for our fact to face meeting in your country for the sharing. I will give you 20% of the fund for your assistance though the percentage is negotiable and I will not contact any other person until I am convinced that you are not interested. >> >>I will like to have your phone and fax number for easy communication. >> >>Best regards, >>BAYO AFOLABI >>US INTERNET FAX NUMBER FOR QUICK CONTACT: 18012178347 >> >> >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > -- James Puckett System Administrator The Lamus Company 703-268-3109 +---+ http://news.com.com/2010-1071-980462.html +---+ "...They have as king over them the angel of the bottomless pit; his name in Hebrew is Abad'don..." ~Revelation, Chapter 9, Verse 11 +---+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4684 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030327/6dd347b8/attachment.bin From delete_russue at alltel.net Thu Mar 27 23:16:42 2003 From: delete_russue at alltel.net (delete_russue at alltel.net) Date: Thu, 27 Mar 03 12:16:42 GMT Subject: Cheap solution to bad cell phone service. qhzdiiciqcv sez Message-ID: An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030327/ef0f85c0/attachment.html From frederic.peters at free.fr Fri Mar 28 08:37:51 2003 From: frederic.peters at free.fr (fp) Date: Thu, 27 Mar 2003 22:37:51 +0100 Subject: [PATCH] authentication with x509 certificate Message-ID: <200303272237.51943.frederic.peters@free.fr> Hi, I have made new small patch. He use X509 certificate to authenticate users. This patch use some features which are coded by Eric Auge (see ldap patch http://ldappubkey.gcu-squad.org/). You could find the patch on http://traceroute.free.fr/articles.php?id=24 regards, Fred. From bugzilla-daemon at mindrot.org Fri Mar 28 10:48:38 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 10:48:38 +1100 (EST) Subject: [Bug 83] PAM limits applied incorrectly (pam_session being called as non-root) Message-ID: <20030327234838.6B4AB94212@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 ------- Additional Comments From djm at mindrot.org 2003-03-28 10:48 ------- Most of session.c runs with user privs in privsep mode. if you need to raise ulimits, you may need to raise the hard-limits for sshd itself. The last patch may help if you are not using privsep. There are two issues here: 1) That all pam_limits calls are happening in the server process, rather than the child (this is the greater problem) 2) the ulimit calls are happening as non-root. 2) is arguably not a bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 28 11:28:05 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 28 Mar 2003 11:28:05 +1100 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030328002805.06B9594208@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #261 is|0 |1 obsolete| | ------- Additional Comments From jason at devrandom.org 2003-03-28 11:28 ------- (From update of attachment 261) No valid in several cases. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From marry1479cay at ballam.fsworld.co.uk Fri Mar 28 23:00:18 2003 From: marry1479cay at ballam.fsworld.co.uk (Kimberley Verburg) Date: Fri, 28 Mar 2003 07:00:18 -0500 Subject: openssh-unix-dev@mindrot.org , Swiss Group Switzerland ! Earn up to 2 daily in the Swish Stock Exchange ! Message-ID: <14791479rshqvvk0xql{0ghyCplqgurw1ruj@12.255.55.211> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030328/c0bac85e/attachment.html From markus at openbsd.org Sat Mar 29 04:39:55 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 28 Mar 2003 18:39:55 +0100 Subject: PRIVSEP annoys me. In-Reply-To: References: Message-ID: <20030328173955.GB31786@folly> what's the point of using a new message type if it's the same as RSAAuthentication? the stat() fails because the process that reads from the network is chrooted. check PRIVSEP() in auth-rsa.c to figure out how RSAAuthentication works with PRIVSEP. On Fri, Mar 28, 2003 at 03:42:06PM +0800, ???? ???? wrote: > > I added a new authentication method to openssh called ICCAuthentication(IC > card). > When server receives SSH_CMSG_AUTH_ICC, it reads the rsa public key file in > the user's home dir(e. g. /home/peter/.icc/authorized_key), gets the > pubkey, > generates an 32 8-bit long random number, encrypts it with the pubkey, and > send > it to the client as an challenge, just like RSAAuthentication. The client > then > decrypts the challenge with the private key in the user's IC card, and send > a > response to the server. > > Here is the auth_icc_prepare_key() function in my auth-icc.c. > This function gets the pubkey in the ~/.icc/authorized_key file. > > int > auth_icc_prepare_key(struct passwd *pw, Key **rkey) > { > char line[8192], file[MAXPATHLEN]; > u_char n_e[131]; > FILE *f; > struct stat st; > Key *key; > > /* Temporarily use the user's uid. */ > temporarily_use_uid(pw); > > /* The authorized key file. */ > snprintf( file, sizeof file, "%.500s/%.100s", pw->pw_dir, > _PATH_SSH_USER_ICC_PERMITTED_KEY ); > > debug("trying public RSA key file %s", file); > > /* Fail quietly if file does not exist */ > /* If UsePriviledgeSeperation is yes, stat() always fails. */ > if (stat(file, &st) < 0) { > /* Restore the privileged uid. */ > debug("Public key file does not exist."); > restore_uid(); > return 0; > } > > /* Open the file containing the authorized keys. */ > f = fopen(file, "r"); > if (!f) { > packet_send_debug("Could not open file %.900s > for reading.",file); > packet_send_debug("If your home is on an NFS volume, > it may need to be world-readable."); > /* Restore the privileged uid. */ > restore_uid(); > return 0; > } > > if (options.strict_modes && > secure_filename(f, file, pw, line, sizeof(line)) != 0) { > fclose(f); > log("Authentication refused: %s", line); > restore_uid(); > return 0; > } > > key = key_new(KEY_RSA); > > /* > * Get the public key from the file. If ok, perform a > * challenge-response dialog to verify that the user has > * the right IC card. > */ > if( fread( n_e, 131, 1, f ) < 1 ) { > restore_uid(); > packet_send_debug("Read file %.900s error.",file); > return 0; > } > key->rsa->n = BN_bin2bn( n_e, 128, NULL ); > key->rsa->e = BN_bin2bn( n_e+128, 3, NULL ); > > /* Restore the privileged uid. */ > restore_uid(); > > /* Close the file. */ > fclose(f); > > /* return key if allowed */ > if ( rkey != NULL ) { > *rkey = key; > return 1; > } else { > key_free(key); > return 0; > } > } > > Everything is ok if in sshd_config: "UsePriviledgeSeperation no". > If I set "UsePriviledgeSeperation" yes, the stat() in the function always > returns <0, but the file does exists. > I set the file as: > /home/peter/.icc/authorized_key peter.peter rw-r--r-- > > Why in privsep the sshd cannot access the file? > Please help me. > Thank you. > > xhtech. Beijing > > > > > > _________________________________________________________________ > ?????????????????????????????? MSN Hotmail?? http://www.hotmail.com > From annai-dm at 24i.net Sat Mar 29 19:34:56 2003 From: annai-dm at 24i.net (info-dm) Date: Sat, 29 Mar 2003 17:34:56 +0900 Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=95K=8C=A9=81I=81I=93=C1=95=CA=8F=EE=95=F1=81I=81I=8D=8B=89=D8=8C=9C=8F=DC=95t=82=AB=81I=81I?= Message-ID: <200303290834.h2T8Ydv88637@postoffice.telstra.net> ?@?V?c?@?O?@http://www.tekipaki.jp/~lovexxx/DMinfo/ ~ ?l?b?g?`?????l???????????@http://www3.hyo-ka.net/~all-guidance/top.html ~ ???????????@?{?s?K?? ?????????????]?????????????A?????@ ???????????L?????[?????z?M???~?????]?????????A???????u?z?M???~?v?????????? ???????[???????M?????????????B???????M?????A?h???X?????????z?M?????~???????????B annai-dm at 24i.net ~ ~ ???????????????????????????????@?{???@???????????????????????????????? ~ ?y???E?????????????t???c?l?z ~ ?????????????I?I ?\?????????i?I?I?????????I?I?\???????I?I?K???I?I?I?I?I ~ ?????????g?o?????I ~ http://www3.hyo-ka.net/~all-guidance/top.html ~ ?????????????????????????????????????????????????????????????????????? ~ ~ ?????????g?o???`???????I From bugzilla-daemon at mindrot.org Sun Mar 30 05:13:20 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 30 Mar 2003 05:13:20 +1000 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030329191320.93EAB94208@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 ------- Additional Comments From jason at devrandom.org 2003-03-30 05:13 ------- Created an attachment (id=264) --> (http://bugzilla.mindrot.org/attachment.cgi?id=264&action=view) Parsing filenames surrounded in quotes. Please test this patch. Works for all above tests as well as doesn't break on non-terminated quotes and filenames ending with a \. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dirk.meyer at dinoex.sub.org Mon Mar 31 01:34:21 2003 From: dirk.meyer at dinoex.sub.org (Dirk Meyer) Date: Sun, 30 Mar 2003 17:34:21 +0200 Subject: 3.6 portable ready. References: <3E7B0168.E2638F2@zip.com.au> Message-ID: Hallo Darren Tucker, > [plug] Your favourite platform not listed? Running the tests is easy > and automatic! You too can find new bugs fast! Put those spare cycles > to use! Email me for details. I like to get the tests working on FreeBSD too. Is there any way to configure them? I use (3.5p1) (cd ${WRKSRC}/regress && ${SETENV} ${MAKE_ENV} \ PATH=${PREFIX}/bin:${PREFIX}/sbin:${PATH} \ ${MAKE} ${MAKE_FLAGS} ${MAKEFILE} ${MAKE_ARGS} ) kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer at dinoex.sub.org],[dirk.meyer at guug.de],[dinoex at FreeBSD.org] sh /data/image/usr/ports/current/openssh-portable/work/openssh-3.5p1/regress/test-exec.sh /data/image/usr/ports/current/openssh-portable/work/openssh-3.5p1/regress /data/image/usr/ports/current/openssh-portable/work/openssh-3.5p1/regress/connect.sh Permission denied. ssh connect with protocol 1 failed Permission denied (publickey,password,keyboard-interactive). ssh connect with protocol 2 failed failed simple connect *** Error code 1 comamnd: ssh -o Protocol=1 -F /data/image/usr/ports/current/openssh-portable/work/openssh-3.5p1/regress/ssh_config somehost true From bugzilla-daemon at mindrot.org Mon Mar 31 11:36:33 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 11:36:33 +1000 (EST) Subject: [Bug 517] bad "put" arg parsing Message-ID: <20030331013633.45AD194209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=517 jason at devrandom.org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #264 is|0 |1 obsolete| | ------- Additional Comments From jason at devrandom.org 2003-03-31 11:36 ------- Created an attachment (id=265) --> (http://bugzilla.mindrot.org/attachment.cgi?id=265&action=view) Patch for bux - minor fixes Replaces check for " with quot for correct behavior. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Mon Mar 31 15:38:40 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 31 Mar 2003 15:38:40 +1000 Subject: 3.6 portable ready. References: <3E7B0168.E2638F2@zip.com.au> Message-ID: <3E87D460.6BD37B88@zip.com.au> Dirk Meyer wrote: > I like to get the tests working on FreeBSD too. > Is there any way to configure them? The regression tests that ship with OpenSSH Portable are the OpenBSD SSH tests and aren't particularly portable. There are patches to improve the portability and some more info at [1], including a "fast start for the impatient" cheatsheet. I suspect that with the "regressport2" patch it will work on FreeBSD without further work (and if it doesn't, let me know and I'll help figure it out). I should do a v3 patch to incorporate the few minor things (see the TODO list on [1]). I encourage anyone interested in running the regression tests to apply this patch and try it. I've had it running on Cygwin in addition to many Unix flavours, and I've also had a report of it working on Mac OS X. [1] http://www.zip.com.au/~dtucker/openssh/regress/ -- 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 bugzilla-daemon at mindrot.org Mon Mar 31 16:50:53 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 16:50:53 +1000 (EST) Subject: [Bug 525] ad a "cygwin-port" product or component to this bugzilla Message-ID: <20030331065053.7ECD694209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=525 Summary: ad a "cygwin-port" product or component to this bugzilla Product: Portable OpenSSH Version: older versions Platform: All URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=831 09 OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hauser at acm.org It appears that RedHat is moving very slow on getting beyond the sophistication of a mailing list for managing RFEs and bugs (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83109), therefore, I suggest to (temporarily) host this here. I am aware that this is not leading edge for the core of openssh, but since this is a potentially important user community, I suggest this is hosted here until a better place is found. This way, there would be an appropriate state-of-the-art bug-tracker for bugs like http://bugzilla.mindrot.org/show_bug.cgi?id=500 (how to start-up ssh-agent by default), http://bugzilla.mindrot.org/show_bug.cgi?id=498 (cygwin's default id file location configuration), http://bugzilla.mindrot.org/show_bug.cgi?id=506 (extend ssh-agent approach also to file/mail encryption), etc. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 31 16:56:43 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 16:56:43 +1000 (EST) Subject: [Bug 496] add a timeout function to ssh-agent Message-ID: <20030331065643.D4E1094219@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=496 ------- Additional Comments From hauser at acm.org 2003-03-31 16:56 ------- Created an attachment (id=266) --> (http://bugzilla.mindrot.org/attachment.cgi?id=266&action=view) Readme.txt for the japanese win-ssh-agent.exe/win-ssh-askpass.exe proofread by Nayuta ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 31 17:01:00 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 17:01:00 +1000 (EST) Subject: [Bug 500] show how to start-up ssh-agent by default... Message-ID: <20030331070100.CDB2C94209@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=500 ------- Additional Comments From hauser at acm.org 2003-03-31 17:00 ------- BTW, http://bugzilla.mindrot.org/attachment.cgi?id=266&action=edit describes another option how to start it by default under windows. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 31 17:26:15 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 17:26:15 +1000 (EST) Subject: [Bug 525] ad a "cygwin-port" product or component to this bugzilla Message-ID: <20030331072615.AEB5D9421E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=525 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2003-03-31 17:26 ------- No. Way. Please don't "volunteer" this bug tracking system for any more that it is already doing. This isn't the place for distribution specific bugs at all. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 31 20:18:46 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 20:18:46 +1000 (EST) Subject: [Bug 525] ad a "cygwin-port" product or component to this bugzilla Message-ID: <20030331101846.B827594208@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=525 ------- Additional Comments From vinschen at redhat.com 2003-03-31 20:18 ------- Note that Red Hat has nothing to do with the OpenSSH port to Cygwin. It's entirely a volunteering effort from my side. There's no official Red Hat support for Cygwin, except if you contracted Red Hat to do so. Cygwin is not Red Hat Linux and there's no official "Red Hat Cygwin" package. If you want help with Cygwin issues, the project mailing list cygwin at cygwin.com is the right place. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mgregis at sorint.it Mon Mar 31 20:28:13 2003 From: mgregis at sorint.it (Max Gregis) Date: Mon, 31 Mar 2003 12:28:13 +0200 Subject: PAM support & openssh Message-ID: <14112298794.20030331122813@sorint.it> Hi,, i'd want to do a question about PAM&Openssh. My OS is a Solaris 8. If i compile Openssh with ---with-pam option..... are there any spcifice SSH entries i have to put in my /etc/pam.conf file for using SSH&PAM better? Thanks in advance Max From bugzilla-daemon at mindrot.org Mon Mar 31 21:28:52 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 21:28:52 +1000 (EST) Subject: [Bug 525] ad a "cygwin-port" product or component to this bugzilla Message-ID: <20030331112852.9B60694224@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=525 hauser at acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vinschen at redhat.com ------- Additional Comments From hauser at acm.org 2003-03-31 21:28 ------- Corinna, Thanks for this great volunteering achievement. Mailing lists are just soooo noisy (low signal-to-noise ratio) compared to a bugzilla where you only hear about the bugs you care. As we are talking volunteering anyway: I have setup my own little bugzilla under http://bugzilla.privasphere.com/index.cgi a while ago and put a mycygwin category in there. I am happy to create a component "openssh" with you as the component owner. Interested? Rgds Ralf ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 31 22:16:32 2003 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 31 Mar 2003 22:16:32 +1000 (EST) Subject: [Bug 525] ad a "cygwin-port" product or component to this bugzilla Message-ID: <20030331121632.0944B9421F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=525 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Mar 31 22:48:59 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 31 Mar 2003 14:48:59 +0200 Subject: OpenSSH 3.6 released Message-ID: <20030331124859.GA4497@folly> OpenSSH 3.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.5: ============================ * RSA blinding is now used by ssh(1), sshd(8) and ssh-agent(1). in order to avoid potential timing attacks against the RSA keys. Older versions of OpenSSH have been using RSA blinding in ssh-keysign(1) only. Please note that there is no evidence that the SSH protocol is vulnerable to the OpenSSL/TLS timing attack described in http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf * ssh-agent(1) optionally requires user confirmation if a key gets used, see '-c' in ssh-add(1). * sshd(8) now handles PermitRootLogin correctly when UsePrivilegeSeparation is enabled. * sshd(8) now removes X11 cookies when a session gets closed. * ssh-keysign(8) is disabled by default and only enabled if the new EnableSSHKeysign option is set in the global ssh_config(5) file. * ssh(1) and sshd(8) now handle 'kex guesses' correctly (key exchange guesses). * ssh(1) no longer overwrites SIG_IGN. This matches behaviour from rsh(1) and is used by backup tools. * setting ProxyCommand to 'none' disables the proxy feature, see ssh_config(5). * scp(1) supports add -1 and -2. * scp(1) supports bandwidth limiting. * sftp(1) displays a progressmeter. * sftp(1) has improved error handling for scripting. Checksums: ========== - MD5 (openssh-3.6p1.tar.gz) = 72ef1134d521cb6926c99256dad17fe0 - MD5 (openssh-3.6.tgz) = 758822b888c5c3f83a98045aef904254 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From des at ofug.org Mon Mar 31 23:05:51 2003 From: des at ofug.org (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 31 Mar 2003 15:05:51 +0200 Subject: resource leak in ssh1 challenge-response authentication Message-ID: If an ssh1 client initiates challenge-response authentication but does not submit a response to the challenge, and instead switches to some other authentication method, verify_response() will never run, and the kbdint device context will never be freed. In some cases (such as when the FreeBSD PAM authentication code is being used) this may cause a resource leak leading to a denial of service. The attached patch adds abandon_challenge_response() to auth-chall.c, and code to auth1.c to call it if challenge-response authentication was initiated but not completed. DES -- Dag-Erling Sm?rgrav - des at ofug.org -------------- next part -------------- A non-text attachment was scrubbed... Name: sshd-auth-chall.diff Type: text/x-patch Size: 2030 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030331/688687f8/attachment.bin From markus at openbsd.org Mon Mar 31 23:58:44 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 31 Mar 2003 15:58:44 +0200 Subject: resource leak in ssh1 challenge-response authentication In-Reply-To: References: Message-ID: <20030331135844.GA18977@folly> On Mon, Mar 31, 2003 at 03:05:51PM +0200, Dag-Erling Sm?rgrav wrote: > If an ssh1 client initiates challenge-response authentication but does > not submit a response to the challenge, and instead switches to some > other authentication method, verify_response() will never run, and the > kbdint device context will never be freed. In some cases (such as > when the FreeBSD PAM authentication code is being used) this may cause > a resource leak leading to a denial of service. > > The attached patch adds abandon_challenge_response() to auth-chall.c, > and code to auth1.c to call it if challenge-response authentication > was initiated but not completed. ah, i see, someone is still using ssh1, good. similar code should be in auth2_challenge_stop()...