From rac at tenzing.org Thu Jan 3 06:34:27 2002 From: rac at tenzing.org (Roger Cornelius) Date: Wed, 2 Jan 2002 14:34:27 -0500 Subject: SCO OpenServer password issue Message-ID: <200201021934.g02JYRe12816@tenzing.org> If SCO OpenServer is configured for large passwords, i.e. u_pwseg is greater than 1 in /etc/auth/system/default, then user authentication in auth-passwd.c will fail for users whose passwords are longer than 8 characters. The "traditional" level of security installs with u_pwseg#1, so most users would never encounter this problem. This has been an issue in openssh since I started using it several versions ago. The fix is to use bigcrypt() rather than crypt() for OpenServer. bigcrypt() works in all cases I believe, regardless of password size or u_pwseg setting. Below is a patch to auth-passwd.c which corrects the problem. I subscribed to the openssh-unix-dev list just today to receive any replies/comments to this post. Apologies if this has been addressed before. man default(F), prpw(F), secdefs(ADM) *** auth-passwd.c-orig Wed Jul 4 00:21:15 2001 --- auth-passwd.c Wed Jan 2 14:17:21 2002 *************** *** 212,218 **** --- 212,222 ---- else encrypted_password = crypt(password, salt); # else + # ifdef HAVE_SCO_PROTECTED_PW + encrypted_password = bigcrypt(password, salt); + # else encrypted_password = crypt(password, salt); + # endif /* HAVE_SCO_PROTECTED_PW */ # endif /* __hpux */ #endif /* HAVE_MD5_PASSWORDS */ -- Roger Cornelius rac at tenzing.org From paul.l.allen at boeing.com Thu Jan 3 07:06:45 2002 From: paul.l.allen at boeing.com (Paul Allen) Date: Wed, 02 Jan 2002 12:06:45 -0800 Subject: ssh References: <20011222222335.A12258@spawar.navy.mil> Message-ID: <3C336855.436E67F8@boeing.com> Chris Seberino wrote: > > Hello! I would really appreciate any hints > to a little puzzle that has been gnawing at me > about remote sessions with ssh... > (and likely all connectivity programs...) > > Because network connections can only talk in > ASCII, Ummm... Not sure why you say this. My network connections generally talk 8-bit binary that I sometimes choose to interpret as ASCII. :-) > there is no way to tell the difference > between TAB and "Ctrl-i" (i.e. pressing Ctrl and i keys > together). BOTH are transmitted as same ASCII > code. Likewise, Ctrl-m and RETURN key both > are transmitted as the same ASCII character > by ssh and every other network connection > probably. Well, this has nothing to do with network connections. It is generally more useful to use ASCII than keyboard scan codes. > Is there ANY way to tweak ssh program or something > else so that something DIFFERENT is sent > to distinguish between Ctrl-i and TAB and > to distinguish between Ctrl-m and RETURN????? > > It would REALLY make my day. If you're running X, have a look at xmodmap. Your X server knows about key press and release events. It also knows the difference between the tab key and control plus I. The xmodmap utility lets you control the translation between keyboard events and transmitted characters. Paul Allen -- Boeing Phantom Works \ Paul L. Allen, (425) 865-3297 Math & Computing Technology \ paul.l.allen at boeing.com POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group From dan at doxpara.com Thu Jan 3 07:27:11 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 2 Jan 2002 12:27:11 -0800 Subject: ssh References: <20011222222335.A12258@spawar.navy.mil> <3C336855.436E67F8@boeing.com> Message-ID: <00d101c193cb$db729bd0$1701000a@effugas> > If you're running X, have a look at xmodmap. Your X server knows about > key press and release events. It also knows the difference between the > tab key and control plus I. The xmodmap utility lets you control the > translation between keyboard events and transmitted characters. > > Paul Allen I looked a small bit into this; turns out Win32 uses DirectInput to reveal exact keypress events. It appears to require a decent amount of infrastructure to support detailed keymap data -- a termcap based system isn't going to cut it here, but SSH tunneling full on X should. I'm betting that one of the commercial X-Servers, like eXceed, would work out of the box with this requirement. --Dan From mandar at webchat.chatsystems.com Thu Jan 3 08:49:08 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Wed, 2 Jan 2002 15:49:08 -0600 (CST) Subject: auth*.c In-Reply-To: <20011227130130.C25982@folly> Message-ID: Markus - here's the debug snippet I put in (note the debug2 line). It _never_ gets displayed when the server runs in debug, the reason being authctxt-> failures doesn't exceed AUTH_FAIL_MAX. Interestingly enough on this system, the number of times the methods were tried were different - none (authctxt->failures==0), keyboard-interactive (1), password (2), password (3), password (4)...five attempts in all. The last time I compiled openssh on a different aix box, it ran 7 attempts (0-6). Haven't dug into the source to figure out what defines the order and reptitions for each method. In any case, what I was figuring to do was add a catch-all i.e. if _all_ methods have been tried and failed, increment unsuccessful login count - I'm assuming that was the intent of the original code. #2 of course was individual increments for the password method failures. - Mandar debug2("userauth_finish: authctxt->failures = %d", authctxt->failures); if (authctxt->failures++ > AUTH_FAIL_MAX) { debug2("userauth_finish: authctxt->failures is %d and exceeds max!", authctxt->failures); #ifdef WITH_AIXAUTHENTICATE loginfailed(authctxt->user, get_canonical_hostname(options.reverse_mapping_check),"ssh"); #endif /* WITH_AIXAUTHENTICATE */ packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } On the client: =============== bigdog:/suptools/bin # lssec -f /etc/security/lastlog -a unsuccessful_login_count -s tuser tuser unsuccessful_login_count=0 bigdog:/usr/src/openssh-3.0.2p1 #./ssh -l tuser -p 9900 localhost tuser at localhost's password: Permission denied, please try again. tuser at localhost's password: Permission denied, please try again. tuser at localhost's password: Permission denied (publickey,password,keyboard-interactive). bigdog:/usr/src/openssh-3.0.2p1 #lssec -f /etc/security/lastlog -a unsuccessful_login_count -s tuser tuser unsuccessful_login_count=0 On the server: =============== debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 39415 debug1: Client protocol version 2.0; client software version OpenSSH_3.0.2p1 debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 debug1: Rhosts Authentication disabled, originating port 39415 not trusted. debug1: list_hostkey_types: ssh-dss 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-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-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,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-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 debug2: kex_parse_kexinit: none 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: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 131/256 debug1: bits set: 993/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1036/2049 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user tuser service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for tuser debug2: input_userauth_request: try method none Failed none for tuser from 127.0.0.1 port 39415 ssh2 debug2: userauth_finish: authctxt->failures = 0 debug1: userauth-request for user tuser service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=tuser devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for tuser from 127.0.0.1 port 39415 ssh2 debug2: userauth_finish: authctxt->failures = 1 debug1: userauth-request for user tuser service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Failed password for tuser from 127.0.0.1 port 39415 ssh2 debug2: userauth_finish: authctxt->failures = 2 debug1: userauth-request for user tuser service ssh-connection method password debug1: attempt 3 failures 3 debug2: input_userauth_request: try method password Failed password for tuser from 127.0.0.1 port 39415 ssh2 debug2: userauth_finish: authctxt->failures = 3 debug1: userauth-request for user tuser service ssh-connection method password debug1: attempt 4 failures 4 debug2: input_userauth_request: try method password Failed password for tuser from 127.0.0.1 port 39415 ssh2 debug2: userauth_finish: authctxt->failures = 4 Connection closed by 127.0.0.1 debug1: Calling cleanup 0x20011bac(0x0) debug1: Calling cleanup 0x20011d28(0x0) debug1: writing PRNG seed to file //.ssh/prng_seed On Thu, 27 Dec 2001, Markus Friedl wrote: > Date: Thu, 27 Dec 2001 13:01:30 +0100 > From: Markus Friedl > To: mandar at webchat.chatsystems.com > Cc: openssh-unix-dev at mindrot.org > Subject: Re: auth*.c > > On Tue, Dec 25, 2001 at 06:34:36PM -0600, mandar at webchat.chatsystems.com wrote: > > Folks, > > > > During testing, we found a couple of issues with openssh3.0.2p1: > > > > 1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c), > > the foll. check: > > > > if (authctxt->failures++ > AUTH_FAIL_MAX) > > > > is never satisfied and thus packet_disconnect() never gets called. I > > suspect the code just drops out of the dispatch_run function list instead. > > This should be an == instead of >. While looking at the debug output > > when deliberately entering wrong passwords, I noticed one try for none, > > three for password, and then three for keyboard-interactive, at which point > > authctxt->failures is 6, and then the loop completes. > > sorry, i don't understand. > From mandar at webchat.chatsystems.com Thu Jan 3 09:17:19 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Wed, 2 Jan 2002 16:17:19 -0600 (CST) Subject: [openssh-unix-dev] auth*.c In-Reply-To: <200112281726.fBSHQNU15968@fire.its.uiowa.edu> Message-ID: Dave - great to hear someone already working on this ;) Re: #1, how do you increment unsuccessful_login_count for non-password method failures? Re: /etc/nologin, why not stat() the file before calling loginrestrictions()? - Mandar On Fri, 28 Dec 2001, David Bronder wrote: > Date: Fri, 28 Dec 2001 11:26:23 -0600 (CST) > From: David Bronder > To: openssh-unix-dev at mindrot.org > Cc: mandar at webchat.chatsystems.com > Subject: Re: [openssh-unix-dev] auth*.c > > I've been working on some patches to address these same issues > with OpenSSH and AIX. In the process, though, I've uncovered > some further complications. > > The current incarnation of my patch does the following things: > > * Moves the AIX loginfailed() call into the auth_log() call as > in your point (2) below. This effectively addresses your point > (1) as well; your fix for that point doesn't cover it since the > client decides how many or few authentication attempts to make > (the client may try fewer methods or fewer retries). > > * Moves the AIX loginsuccess() call down in session.c to after the > record_login() call, which made more sense to me. > > I haven't submitted the patch yet because of new problems that it > uncovered. The problems have to do with how /etc/nologin is handled > under AIX in particular, and "invalid" users in general. If these > problems can be resolved (or maybe even if they can't), I'll post > the patch after I've finished testing. > > The first problem is that the AIX loginrestrictions() call returns > failure if /etc/nologin exists and the user is not root. So in > OpenSSH, a non-root user will be marked as invalid, and will never > reach the normal nologin handling. There is no way to tell from > loginrestrictions() what condition(s) caused the failure. So the > connection attempt will fail but the client will get no indication > of why. > > The other problem is that OpenSSH allows an invalid user to continue > retrying authentication, even though all the authentication methods > immediately fail when authctxt->valid is false or authctxt->pw is > NULL. In the case of AIX and /etc/nologin, the user inflates the > unsuccessful login counter, but gets no feedback as to what's going > on. > > My question to the developers is this: Should login attempts by an > invalid user behave this way? Or should the invalid user check be > made after a successful authentication instead of before, and then > cause the disconnect? The latter seems more correct to me. > > Also, I'll take any advice offered on how to handle the /etc/nologin > feedback issue under AIX... > > =Dave > > mandar at webchat.chatsystems.com wrote: > > > > During testing, we found a couple of issues with openssh3.0.2p1: > > > > 1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c), > > the foll. check: > > > > if (authctxt->failures++ > AUTH_FAIL_MAX) > > > > is never satisfied and thus packet_disconnect() never gets called. I > > suspect the code just drops out of the dispatch_run function list instead. > > This should be an == instead of >. While looking at the debug output > > when deliberately entering wrong passwords, I noticed one try for none, > > three for password, and then three for keyboard-interactive, at which point > > authctxt->failures is 6, and then the loop completes. > > > > 2. I'd like to move loginfailed() within the #ifdef WITH_AIXAUTHENTICATE > > of auth1.c and auth2.c to auth_log() instead, and call it on every > > password method failure, as well as an overall authctxt->failures == > > AUTH_FAIL_MAX check for the other methods. This should clean up the code a > > bit, and should fix the issue of the unsuccessful login counter not being > > incremented on each unsucessful try. > > > -- > Hello World. David Bronder - Systems Admin > Segmentation Fault ITS-SPA, Univ. of Iowa > Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu > From Network.Admin at act.gov.au Thu Jan 3 12:14:32 2002 From: Network.Admin at act.gov.au (Network Admin) Date: Thu, 3 Jan 2002 11:14:32 +1000 Subject: Compiling OpenSSH_3.0.2p1 on BSDI version 3.0 Message-ID: FYI, I managed to install Version OpenSSH_3.0.2p1 on BSDI 3.0. we needed this for an old Gauntlet Firewall. I received an the following error during make install (cd scard && make DESTDIR= install) make: don't know how to make ./Ssh.bin. Stop *** Error code 2 I edited the scard/Makefile.in file and changed install: $(srcdir)/Ssh.bin to install: Ssh.bin Then I made a distclean and started again. Worked like a charm. From tsn at gbdev.net Thu Jan 3 11:51:13 2002 From: tsn at gbdev.net (Tomas Svensson) Date: Thu, 3 Jan 2002 01:51:13 +0100 Subject: TCP_NODELAY or not Message-ID: <14648204834.20020103015113@gbdev.net> Hi, Why not turn off TCP_NODELAY in OpenSSH, atleast in the server->client direction? If a user is doing 'ls -l' over an Internet link that has some latency, he/she is flooded with a burst of small packets that can cause congestion and packet loss. Quite many people have been noticing this behaviour when doing ls -l resulting in etc, but they usually think that the link is bad. SSH Inc's sshd 3.0.1 does not use TCP_NODELAY (by default) and does not show the behaviour either. -Tomas From david-bronder at uiowa.edu Thu Jan 3 12:23:56 2002 From: david-bronder at uiowa.edu (David Bronder) Date: Wed, 2 Jan 2002 19:23:56 -0600 (CST) Subject: [openssh-unix-dev] auth*.c In-Reply-To: from "mandar@webchat.chatsystems.com" at Jan 02, 2002 04:17:19 PM Message-ID: <200201030123.g031NuC20704@fire.its.uiowa.edu> mandar at webchat.chatsystems.com wrote: > > Dave - great to hear someone already working on this ;) Re: #1, how do you > increment unsuccessful_login_count for non-password method failures? Short answer: I don't. :) In practice, I found that incrementing unsuccessful_login_count for other methods is painful, especially if you actually _use_ unsuccessful_login_count. Not all failures of the other methods make sense to count, at least not all the time. > Re: /etc/nologin, why not stat() the file before calling > loginrestrictions()? Because OpenSSH already does /etc/nologin handling elsewhere in the code. It doesn't seem right to add a second check for it, and it also doesn't seem right to check for /etc/nologin on all platforms in allowed_user() where loginrestrictions() is currently called. =Dave -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From markus at openbsd.org Thu Jan 3 23:15:36 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 3 Jan 2002 13:15:36 +0100 Subject: auth*.c In-Reply-To: ; from mandar@webchat.chatsystems.com on Wed, Jan 02, 2002 at 03:49:08PM -0600 References: <20011227130130.C25982@folly> Message-ID: <20020103131536.E26976@folly> it's not called because the client decices to close the connection. On Wed, Jan 02, 2002 at 03:49:08PM -0600, mandar at webchat.chatsystems.com wrote: > > Markus - here's the debug snippet I put in (note the debug2 line). It > _never_ gets displayed when the server runs in debug, the reason being > authctxt-> failures doesn't exceed AUTH_FAIL_MAX. > > Interestingly enough on this system, the number of times the methods were > tried were different - none (authctxt->failures==0), keyboard-interactive > (1), password (2), password (3), password (4)...five attempts in all. The > last time I compiled openssh on a different aix box, it ran 7 attempts > (0-6). > > Haven't dug into the source to figure out what defines the order and > reptitions for each method. In any case, what I was figuring to do was add > a catch-all i.e. if _all_ methods have been tried and failed, increment > unsuccessful login count - I'm assuming that was the intent of the > original code. #2 of course was individual increments for the password > method failures. > > - Mandar > > > debug2("userauth_finish: authctxt->failures = %d", authctxt->failures); > if (authctxt->failures++ > AUTH_FAIL_MAX) { > debug2("userauth_finish: authctxt->failures is %d > and exceeds max!", authctxt->failures); > #ifdef WITH_AIXAUTHENTICATE > loginfailed(authctxt->user, > get_canonical_hostname(options.reverse_mapping_check),"ssh"); > #endif /* WITH_AIXAUTHENTICATE */ > packet_disconnect(AUTH_FAIL_MSG, authctxt->user); > } > > > On the client: > =============== > > bigdog:/suptools/bin # lssec -f /etc/security/lastlog -a > unsuccessful_login_count -s tuser > tuser unsuccessful_login_count=0 > > bigdog:/usr/src/openssh-3.0.2p1 #./ssh -l tuser -p 9900 localhost > tuser at localhost's password: > Permission denied, please try again. > tuser at localhost's password: > Permission denied, please try again. > tuser at localhost's password: > Permission denied (publickey,password,keyboard-interactive). > > bigdog:/usr/src/openssh-3.0.2p1 #lssec -f /etc/security/lastlog -a > unsuccessful_login_count -s tuser > tuser unsuccessful_login_count=0 > > > On the server: > =============== > debug1: Server will not fork when running in debugging mode. > Connection from 127.0.0.1 port 39415 > debug1: Client protocol version 2.0; client software version > OpenSSH_3.0.2p1 > debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 > debug1: Rhosts Authentication disabled, originating port 39415 not > trusted. > debug1: list_hostkey_types: ssh-dss > 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-dss > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-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,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-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 > debug2: kex_parse_kexinit: none > 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: client->server aes128-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 131/256 > debug1: bits set: 993/2049 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 1036/2049 > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 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: KEX done > debug1: userauth-request for user tuser service ssh-connection method none > debug1: attempt 0 failures 0 > debug2: input_userauth_request: setting up authctxt for tuser > debug2: input_userauth_request: try method none > Failed none for tuser from 127.0.0.1 port 39415 ssh2 > debug2: userauth_finish: authctxt->failures = 0 > debug1: userauth-request for user tuser service ssh-connection method > keyboard-interactive > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method keyboard-interactive > debug1: keyboard-interactive devs > debug1: auth2_challenge: user=tuser devs= > debug1: kbdint_alloc: devices '' > debug2: auth2_challenge_start: devices > Failed keyboard-interactive for tuser from 127.0.0.1 port 39415 ssh2 > debug2: userauth_finish: authctxt->failures = 1 > debug1: userauth-request for user tuser service ssh-connection method > password > debug1: attempt 2 failures 2 > debug2: input_userauth_request: try method password > Failed password for tuser from 127.0.0.1 port 39415 ssh2 > debug2: userauth_finish: authctxt->failures = 2 > debug1: userauth-request for user tuser service ssh-connection method > password > debug1: attempt 3 failures 3 > debug2: input_userauth_request: try method password > Failed password for tuser from 127.0.0.1 port 39415 ssh2 > debug2: userauth_finish: authctxt->failures = 3 > debug1: userauth-request for user tuser service ssh-connection method > password > debug1: attempt 4 failures 4 > debug2: input_userauth_request: try method password > Failed password for tuser from 127.0.0.1 port 39415 ssh2 > debug2: userauth_finish: authctxt->failures = 4 > Connection closed by 127.0.0.1 > debug1: Calling cleanup 0x20011bac(0x0) > debug1: Calling cleanup 0x20011d28(0x0) > debug1: writing PRNG seed to file //.ssh/prng_seed > > > > On Thu, 27 Dec 2001, Markus Friedl wrote: > > > Date: Thu, 27 Dec 2001 13:01:30 +0100 > > From: Markus Friedl > > To: mandar at webchat.chatsystems.com > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: auth*.c > > > > On Tue, Dec 25, 2001 at 06:34:36PM -0600, mandar at webchat.chatsystems.com wrote: > > > Folks, > > > > > > During testing, we found a couple of issues with openssh3.0.2p1: > > > > > > 1. In userauth_finish() in auth2.c (as well as in do_authloop in auth1.c), > > > the foll. check: > > > > > > if (authctxt->failures++ > AUTH_FAIL_MAX) > > > > > > is never satisfied and thus packet_disconnect() never gets called. I > > > suspect the code just drops out of the dispatch_run function list instead. > > > This should be an == instead of >. While looking at the debug output > > > when deliberately entering wrong passwords, I noticed one try for none, > > > three for password, and then three for keyboard-interactive, at which point > > > authctxt->failures is 6, and then the loop completes. > > > > sorry, i don't understand. > > > From odie at rotta.media.sonera.net Thu Jan 3 23:30:02 2002 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Thu, 03 Jan 2002 14:30:02 +0200 Subject: DISPLAY=localhost In-Reply-To: Your message of "Wed, 05 Dec 2001 13:16:25 PST." Message-ID: <200201031230.g03CU2P05023@rotta.tmt.tele.fi> Hi! > this can be applied to the latest portable CVS. by default bind sshd fake Thanks! This patch seems to be nice. I tested it on my workstation and it seems to be working ok (I could open one xterm). One minor issue is that if I compile it without --with-ipv4-default configure option, it won't work on my linux. If I leave the option out and try to run it then it binds it to ipv6 address. lsof says it like this: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 4071 root 6u IPv6 297828004 TCP [::1]:6012 (LISTEN) I'll test your patch more soon. Any chance that it might end up into openssh? -- Osmo Paananen From markus at openbsd.org Thu Jan 3 23:41:18 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 3 Jan 2002 13:41:18 +0100 Subject: SCO OpenServer password issue In-Reply-To: <200201021934.g02JYRe12816@tenzing.org>; from rac@tenzing.org on Wed, Jan 02, 2002 at 02:34:27PM -0500 References: <200201021934.g02JYRe12816@tenzing.org> Message-ID: <20020103134118.A19168@folly> > *** auth-passwd.c-orig Wed Jul 4 00:21:15 2001 > --- auth-passwd.c Wed Jan 2 14:17:21 2002 i'd like to see less ifdefs in auth-passwd.c ... From douglas.kingston at db.com Fri Jan 4 03:14:38 2002 From: douglas.kingston at db.com (Doug Kingston) Date: Thu, 03 Jan 2002 16:14:38 +0000 Subject: hang on exit bug under Linux Message-ID: <3C34836E.4090203@db.com> Markus et al., Please pardon me if I've missed anything, but coming into this a bit late... The hanging of ssh connections with openssh where a job has been "detached" (backgrounded) is a real concern here as well. We have lots of existing ssh and rsh scripts that we are converting over to later versions of openssh, and have started running into this with startling frequency, and its operational impact is serious when compounded by regular invocations. We wind up with large numbers of waiting sshd's on one side and/or hung scripts on the client side. My understanding from reading code and the archives is that the current behaviour we are seeing (a hang) is by design - and is intended to ensure that any output from that spawned task is dutifully carried back to the originating ssh client for appropriate dispostion. The goal is to avoid losing any data in the "end game" as things die off and connections are closed. However, the prior behavior of rsh and ssh was different, and the termination of the remote connection was governed by the death of all child processes (or the only child process). It is this behaviour that people would like to see again. I agree that technically (in the sense of not losing data), the new behavior is more correct, and users should wrap programs they are trying to detach to close all FDs (easily done with a Perl program and probably shell as well). People would like to control this on the client side, but its completely server side behavior and currently there is no way for the client to influence this other than to recode their scripts (which in our case is 1000's of scripts). What we need is a way to support the old functionality but in a way that lets us migrate smoothly over time to the new behavior. I believe that a few modifcations can be made to the client and server to support both the new and old behavior, and the controlling of the default behavior. First the server side changes: 1. add an option to terminate when the primary or all child processes die. 2. add an option to set the default for this flag in the sshd_config file (default should probably be for the old behavior to be compatible with v1.3 and 1.5 clients) 3. add code to allow the client side to set this option (client should overide server) (I think this needs to be a SSH2_MSG_GLOBAL_REQUEST) Only ssh v2.0 clients will be able to set this option. Client side changes: 1. add code to send new option described above. 2. add code to set the default setting of the option in ssh_config 3. add command line processing to override default and send desired option setting to server. We need to be aware that there are many different versions of ssh client code out there, much of it beyond our control, and we need to ensure that it continues to operate as expected when we upgrade the server (backwards compatability). This means making the default server behavior accomodate the older client expectations unless it knows its got a newer client that wants the new behavior. Once a site has converted their environment, they can change the default to wait for all output FDs to close before exiting. How does this proposal sound to folks? Markus? What have I missed... -Doug- -- Douglas Kingston Director Global Unix Engineering Manager Deutsche Bank AG London 6 Bishopsgate London EC2N 4DA Work: +44-20-7545-3907 Mobile: +44-7767-616-028 From markus at openbsd.org Fri Jan 4 03:28:19 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 3 Jan 2002 17:28:19 +0100 Subject: hang on exit bug under Linux In-Reply-To: <3C34836E.4090203@db.com> References: <3C34836E.4090203@db.com> Message-ID: <20020103172818.A15928@faui02> for rlogin-like behaviour (i.e. a pty is allocated) it might be an option to discard data, like telnetd/rlogind do. for rsh-like behaviour data loss is not acceptable. for example, $ rsh host broken-daemon blocks too (on many platforms, if not, please show me relevant rshd code). and it should block for ssh-1.2.32. From stevesk at pobox.com Fri Jan 4 04:42:02 2002 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 3 Jan 2002 09:42:02 -0800 (PST) Subject: DISPLAY=localhost In-Reply-To: <200201031230.g03CU2P05023@rotta.tmt.tele.fi> Message-ID: On Thu, 3 Jan 2002, Osmo Paananen wrote: :> this can be applied to the latest portable CVS. by default bind sshd fake : :Thanks! This patch seems to be nice. I tested it on my workstation and :it seems to be working ok (I could open one xterm). a version of this is in openbsd and portable CVS. can you try that? there is more work to be done, but i think yours is only the 2nd feedback i have seen for portable. todo: . fix ssh DISPLAY parsing for localhost case . x11address or something else instead of overloading gatewayports :One minor issue is that if I compile it without --with-ipv4-default :configure option, it won't work on my linux. If I leave the option out :and try to run it then it binds it to ipv6 address. : :lsof says it like this: : :COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME :sshd 4071 root 6u IPv6 297828004 TCP [::1]:6012 (LISTEN) i don't understand the linux ipv6 issues. but we do use IPv4or6 in channels.c for the fake socket family. From tori at ringstrom.mine.nu Fri Jan 4 10:41:01 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Fri, 4 Jan 2002 00:41:01 +0100 (CET) Subject: [PATCH] Improving sftp client performance Message-ID: The included patch for openssh 3.0.2p1 implements overlapping read requests for the sftp client. It should be able to handle weird cases such as shriking files and reordered responses. This is only the first shot, and I'd be happy for any comments. I plan to implement something similar for the write path if this works out well. The maximum number of outstanding requests is quite high at the moment (6). I used that number since it gave the best performance on my 1 GHz Athlon using the looback interface in Linux 2.4, and it did not degrade perfomce over 100Mb/s ethernet or 700 kb/s ADSL which is what I have easy access to at the moment. The drawback of many outstanding requests is that when we detect an error, we must wait for the responses to our outstanding requests. I should also mention that the code starts with only one request, and increases the number by one for each successful reply up to the maximum (6). That makes sure we do not waste packets for short files or some obvious error cases. There are two ideas I have not tried yet. the first is not to use the file size from the stat call to avoid issuing more than one request past the presumed end-of-file. The other idea is to start with COPY_SIZE requests, but to use the size of the responses (which might be less then COPY_SIZE) for future requests. The reason for doing this is to avoid non-sequential requests to servers with small maximum responses sizes. That way we could also increase COPY_SIZE to something more efficient. Does anyone here have any comments on reading from or writing to non-regular files using the sftp protocol? The offset argument to the read and write requests seems to indicate that the protocol is only intended for regular files. Should the sftp server and client verify that, or is that too anal? /Tobias diff -ru openssh-3.0.2p1.orig/sftp-client.c openssh-3.0.2p1/sftp-client.c --- openssh-3.0.2p1.orig/sftp-client.c Wed Jul 18 17:45:45 2001 +++ openssh-3.0.2p1/sftp-client.c Fri Jan 4 00:09:44 2002 @@ -45,6 +45,15 @@ /* How much data to read/write at at time during copies */ /* XXX: what should this be? */ #define COPY_SIZE 8192 +/* Maximum number of outstanding requests */ +#define REQUEST_QUEUE_SIZE 6 + +/* A read/write request */ +struct request { + u_int id; + u_int len; + u_int64_t offset; +}; /* Message ID */ static u_int msg_id = 1; @@ -215,6 +224,44 @@ return(a); } +static int +find_request(struct request *rq, int num, u_int id) +{ + int i; + + for (i = 0; i < num; ++i) { + if (rq[i].id == id) + break; + } + + if (i == num) + fatal("Request ID mismatch (%d)", id); + + return i; +} + +static void +remove_request(struct request *rq, int *num, int i) +{ + memmove(rq + i, rq + i + 1, (*num - i - 1) * sizeof(struct request)); + --*num; +} + +static void +send_request(int fd, const char *handle, u_int handle_len, int type, + const struct request *rq, Buffer *m) +{ + buffer_clear(m); + buffer_put_char(m, SSH2_FXP_READ); + buffer_put_int(m, rq->id); + buffer_put_string(m, handle, handle_len); + buffer_put_int64(m, rq->offset); + buffer_put_int(m, rq->len); + send_msg(fd, m); + debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", + rq->id, rq->offset, rq->len); +} + int do_init(int fd_in, int fd_out) { @@ -674,12 +721,15 @@ int pflag) { int local_fd; - u_int expected_id, handle_len, mode, type, id; + u_int handle_len, mode, type, id; u_int64_t offset; char *handle; Buffer msg; Attrib junk, *a; int status; + struct request req[REQUEST_QUEUE_SIZE]; + int num_req = 0, max_req = 1, reply; + int write_error = 0, read_error = 0, write_errno; a = do_stat(fd_in, fd_out, remote_path, 0); if (a == NULL) @@ -726,87 +776,103 @@ /* Read from remote and write to local */ offset = 0; - for(;;) { - u_int len; + while (num_req > 0 || max_req > 0) { char *data; + u_int len; - id = expected_id = msg_id++; - - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_READ); - buffer_put_int(&msg, id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_int(&msg, COPY_SIZE); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", - id, (u_int64_t)offset, COPY_SIZE); + /* Send some more requests */ + while (num_req < max_req) { + req[num_req].id = msg_id++; + req[num_req].len = COPY_SIZE; + req[num_req].offset = offset; + offset += req[num_req].len; + num_req++; + send_request(fd_out, handle, handle_len, SSH2_FXP_READ, + &req[num_req - 1], &msg); + } buffer_clear(&msg); - get_msg(fd_in, &msg); type = buffer_get_char(&msg); id = buffer_get_int(&msg); debug3("Received reply T:%d I:%d", type, id); - if (id != expected_id) - fatal("ID mismatch (%d != %d)", id, expected_id); - if (type == SSH2_FXP_STATUS) { + reply = find_request(req, num_req, id); + + switch (type) { + case SSH2_FXP_STATUS: status = buffer_get_int(&msg); + if (status != SSH2_FX_EOF) + read_error = 1; + max_req = 0; + remove_request(req, &num_req, reply); + break; + case SSH2_FXP_DATA: + data = buffer_get_string(&msg, &len); + if (len > req[reply].len) + fatal("Received more data than asked for " + "%d > %d", len, req[reply].len); + + debug3("In read loop, got %d offset %llu", + len, req[reply].offset); + if ((lseek(local_fd, req[reply].offset, SEEK_SET) == -1 || + atomicio(write, local_fd, data, len) != len) && + !write_error) { + write_errno = errno; + write_error = 1; + max_req = 0; + } + xfree(data); - if (status == SSH2_FX_EOF) - break; + if (len == req[reply].len) + remove_request(req, &num_req, reply); else { - error("Couldn't read from remote " - "file \"%s\" : %s", remote_path, - fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - goto done; + /* Resend the request for the missing data */ + req[reply].id = msg_id++; + req[reply].len -= len; + req[reply].offset += len; + send_request(fd_out, handle, handle_len, + SSH2_FXP_READ, &req[reply], &msg); } - } else if (type != SSH2_FXP_DATA) { + if (max_req > 0 && max_req < REQUEST_QUEUE_SIZE) + ++max_req; + break; + default: fatal("Expected SSH2_FXP_DATA(%d) packet, got %d", - SSH2_FXP_DATA, type); - } - - data = buffer_get_string(&msg, &len); - if (len > COPY_SIZE) - fatal("Received more data than asked for %d > %d", - len, COPY_SIZE); - - debug3("In read loop, got %d offset %llu", len, - (u_int64_t)offset); - if (atomicio(write, local_fd, data, len) != len) { - error("Couldn't write to \"%s\": %s", local_path, - strerror(errno)); - do_close(fd_in, fd_out, handle, handle_len); - status = -1; - xfree(data); - goto done; + SSH2_FXP_DATA, type); } - - offset += len; - xfree(data); } - status = do_close(fd_in, fd_out, handle, handle_len); - /* Override umask and utimes if asked */ + if (read_error) { + error("Couldn't read from remote " + "file \"%s\" : %s", remote_path, + fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + } else if (write_error) { + error("Couldn't write to \"%s\": %s", local_path, + strerror(write_errno)); + status = -1; + do_close(fd_in, fd_out, handle, handle_len); + } else { + status = do_close(fd_in, fd_out, handle, handle_len); + + /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD - if (pflag && fchmod(local_fd, mode) == -1) + if (pflag && fchmod(local_fd, mode) == -1) #else - if (pflag && chmod(local_path, mode) == -1) + if (pflag && chmod(local_path, mode) == -1) #endif /* HAVE_FCHMOD */ - error("Couldn't set mode on \"%s\": %s", local_path, - strerror(errno)); - if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { - struct timeval tv[2]; - tv[0].tv_sec = a->atime; - tv[1].tv_sec = a->mtime; - tv[0].tv_usec = tv[1].tv_usec = 0; - if (utimes(local_path, tv) == -1) - error("Can't set times on \"%s\": %s", local_path, - strerror(errno)); + error("Couldn't set mode on \"%s\": %s", local_path, + strerror(errno)); + if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { + struct timeval tv[2]; + tv[0].tv_sec = a->atime; + tv[1].tv_sec = a->mtime; + tv[0].tv_usec = tv[1].tv_usec = 0; + if (utimes(local_path, tv) == -1) + error("Can't set times on \"%s\": %s", + local_path, strerror(errno)); + } } - -done: close(local_fd); buffer_free(&msg); xfree(handle); From stuge at cdy.org Fri Jan 4 18:59:48 2002 From: stuge at cdy.org (Peter Stuge) Date: Fri, 4 Jan 2002 08:59:48 +0100 Subject: hang on exit bug under Linux In-Reply-To: <3C34836E.4090203@db.com>; from douglas.kingston@db.com on Thu, Jan 03, 2002 at 04:14:38PM +0000 References: <3C34836E.4090203@db.com> Message-ID: <20020104085947.A1025@foo.birdnet.se> On Thu, Jan 03, 2002 at 04:14:38PM +0000, Doug Kingston wrote: > Markus et al., > > Please pardon me if I've missed anything, but coming into this a bit late... > > The hanging of ssh connections with openssh where a job has been > "detached" (backgrounded) is a real concern here as well. We have lots Use my patch, then. It will let you configure the ssh client to terminate or go to background beside keeping the current behaviour. In SSH2 this is a matter of the client, not the server. //Peter -- irc: CareBear\ irl: Peter Stuge From stuge at cdy.org Fri Jan 4 19:15:26 2002 From: stuge at cdy.org (Peter Stuge) Date: Fri, 4 Jan 2002 09:15:26 +0100 Subject: hang on exit bug under Linux In-Reply-To: <20020103172818.A15928@faui02>; from markus@openbsd.org on Thu, Jan 03, 2002 at 05:28:19PM +0100 References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> Message-ID: <20020104091526.B1025@foo.birdnet.se> On Thu, Jan 03, 2002 at 05:28:19PM +0100, Markus Friedl wrote: > for rlogin-like behaviour (i.e. a pty is allocated) it might > be an option to discard data, like telnetd/rlogind do. I could fix up my patch to only apply when ssh is invoked as slogin and change the configuration directive name to reflect this.. Should I bother? Also, since the background mode isn't working the way I want it to and I don't know enough to fix it, I'd very much appreciate pointers.. Nicolas mentioned some Stevens books? What are they? Available online? (The deal is that I want to make a certain PID a child of a different PID than it is right now.) //Peter -- irc: CareBear\ irl: Peter Stuge From markus at openbsd.org Sat Jan 5 00:09:50 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 4 Jan 2002 14:09:50 +0100 Subject: [PATCH] Improving sftp client performance In-Reply-To: ; from tori@ringstrom.mine.nu on Fri, Jan 04, 2002 at 12:41:01AM +0100 References: Message-ID: <20020104140950.D1282@folly> On Fri, Jan 04, 2002 at 12:41:01AM +0100, Tobias Ringstrom wrote: > The included patch for openssh 3.0.2p1 implements overlapping read > requests for the sftp client. nice, Jean-Pierre is also working on this. From chombier at mac.com Sat Jan 5 00:21:01 2002 From: chombier at mac.com (Jean-Pierre) Date: Fri, 04 Jan 2002 14:21:01 +0100 Subject: [PATCH] Improving sftp client performance In-Reply-To: <20020104140950.D1282@folly> Message-ID: Le 4/01/02 14:09, ??Markus Friedl?? a ?crit?: > On Fri, Jan 04, 2002 at 12:41:01AM +0100, Tobias Ringstrom wrote: >> The included patch for openssh 3.0.2p1 implements overlapping read >> requests for the sftp client. > > nice, Jean-Pierre is also working on this. > Cool ! This patch increases performance for the download side. The one I did send was for the upload, so we have now a fully optimized sftp client (: Cheers, - Jean-Pierre. From tori at ringstrom.mine.nu Sat Jan 5 01:09:09 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Fri, 4 Jan 2002 15:09:09 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Fri, 4 Jan 2002, Jean-Pierre wrote: > Le 4/01/02 14:09, ??Markus Friedl?? a ?crit?: > > On Fri, Jan 04, 2002 at 12:41:01AM +0100, Tobias Ringstrom wrote: > >> The included patch for openssh 3.0.2p1 implements overlapping read > >> requests for the sftp client. > > > > nice, Jean-Pierre is also working on this. > > The one I did send was for the upload, so we have now a > fully optimized sftp client (: Great. I'm new on this list, and I did not find it in the archives, although I must admit that I did not look very hard. Could you resend it to me off-list, or is it in CVS already? /Tobias From Nicolas.Williams at ubsw.com Sat Jan 5 01:32:29 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 4 Jan 2002 09:32:29 -0500 Subject: hang on exit bug under Linux In-Reply-To: <20020104091526.B1025@foo.birdnet.se>; from Peter Stuge on Fri, Jan 04, 2002 at 09:15:26AM +0100 References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> <20020104091526.B1025@foo.birdnet.se> Message-ID: <20020104093229.B20222@wdr.com> On Fri, Jan 04, 2002 at 09:15:26AM +0100, Peter Stuge wrote: > On Thu, Jan 03, 2002 at 05:28:19PM +0100, Markus Friedl wrote: > > for rlogin-like behaviour (i.e. a pty is allocated) it might > > be an option to discard data, like telnetd/rlogind do. > > I could fix up my patch to only apply when ssh is invoked as slogin and > change the configuration directive name to reflect this.. > > Should I bother? Yes. > Also, since the background mode isn't working the way I want it to and I > don't know enough to fix it, I'd very much appreciate pointers.. > Nicolas mentioned some Stevens books? What are they? Available online? Search for books with "W. Richard Stevens" as the author, and titles that start with "UNIX Network Programming ..." and "TCP/IP Illustrated ...". > (The deal is that I want to make a certain PID a child of a different PID > than it is right now.) You can't do that. You can put ssh into the background by forking off a child and exiting, but then the shell cannot bring that child back to the foreground. Which makes the background option not so useful. Perhaps you can just have ssh send itself a SIGTSTP, but then you have to rely on the user to ask the shell to actually background the process. > //Peter > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From CLAD at chevrontexaco.com Sat Jan 5 02:00:58 2002 From: CLAD at chevrontexaco.com (Ladner, Eric (CLAD)) Date: Fri, 4 Jan 2002 07:00:58 -0800 Subject: Strange problem from "identical" hosts Message-ID: <8F88657F29DFD11189ED0008C728C6B008A5A0F0@nor935-msx6.nor.chevron.com> Long post.. sorry. Ok.. I've got three systems, all running openssh-3.0.2p1. As a matter of fact, they were installed from the same built tree, so I know they are the same. Here's the deal. I've got three systems, call them source1, source2 and target. All are HP-UX 11.0 systems installed from the same tree. Source1 and source2 both have thier root rsa pub keys in target's auth keys file. If I ssh over from source1, everything works great. If I ssh over from source2, it asks me for root's password. Here's a debug list of the ssh from source1 and source2 with the differences indicated by a leading >: Any clues? Source1 (the one that works) # ssh-agent /bin/ksh # ssh-add /root/.ssh/id_rsa Enter passphrase for /root/.ssh/id_rsa: Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa) # ssh -v target OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/opt/ssh-3.0/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to target [10.0.0.253] port 22. debug1: temporarily_use_uid: 0/3 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/3 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_rsa type 1 > debug1: identity file /root/.ssh/identity type 0 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.0.2p1 debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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: 114/256 > debug1: bits set: 1558/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'target' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 > debug1: bits set: 1575/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: userauth_pubkey_agent: testing agent key /root/.ssh/id_rsa The big difference starts here. > debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 40028aa8 hint -1 > debug1: ssh-userauth2 successful: method publickey > debug1: channel 0: new [client-session] > debug1: send channel open 0 > debug1: Entering interactive session. > debug1: ssh_session2_setup: id 0 > debug1: Requesting authentication agent forwarding. > debug1: channel request 0: shell > debug1: channel 0: open confirm rwindow 0 rmax 16384 > Last login: Thu Jan 3 16:12:22 2002 from source1 .. Login continues here.. Source2 (the one that doesn't work) # ssh-agent /bin/ksh # ssh-add /root/.ssh/id_rsa Enter passphrase for /root/.ssh/id_rsa: Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa) # ssh -v target OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/opt/ssh-3.0/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to target [10.0.0.253] port 22. debug1: temporarily_use_uid: 0/3 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/3 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_rsa type 1 > debug1: identity file /root/.ssh/identity type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.0.2p1 debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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: 111/256 > debug1: bits set: 1623/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'target' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 > debug1: bits set: 1597/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: userauth_pubkey_agent: testing agent key /root/.ssh/id_rsa The big difference starts here. > debug1: authentications that can continue: publickey,password,keyboard-interactive > debug1: try privkey: /root/.ssh/id_dsa > debug1: try pubkey: /root/.ssh/id_rsa > debug1: authentications that can continue: publickey,password,keyboard-interactive > debug1: try privkey: /root/.ssh/identity > debug1: next auth method to try is keyboard-interactive > debug1: authentications that can continue: publickey,password,keyboard-interactive > debug1: next auth method to try is password > root at target's password: From mouring at etoh.eviladmin.org Sat Jan 5 02:36:23 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 4 Jan 2002 09:36:23 -0600 (CST) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: No it was not in the CVS tree yet. There was still discussions as to the implementation. I have a version that does not do more more then two overlapping writes. I'll have to take a look at your patch a little closer, but I worry about attempting to optimize the number of writes/reads done in a single sitting. This could feesable change per hardware, per network, etc. If we want to go this way I really suggest we flesh out that defination using -r. That way the user can optimize it for themselves. With -r 1 mimicing the current behavior. Then set a default (2 - 4) if -r is not used. Attached is my version of the upload patch. --- ../../ssh/sftp-client.c Wed Dec 19 18:00:49 2001 +++ ../sftp-client.c Tue Dec 25 14:00:00 2001 @@ -813,7 +813,7 @@ int pflag) { int local_fd; - u_int handle_len, id; + u_int handle_len, id, ackid; u_int64_t offset; char *handle; Buffer msg; @@ -861,6 +861,7 @@ return(-1); } + ackid = id + 1; /* Read from local and write to remote */ offset = 0; for (;;) { @@ -878,26 +879,30 @@ if (len == -1) fatal("Couldn't read from \"%s\": %s", local_path, strerror(errno)); - if (len == 0) + + if (len != 0) { + buffer_clear(&msg); + buffer_put_char(&msg, SSH2_FXP_WRITE); + buffer_put_int(&msg, ++id); + buffer_put_string(&msg, handle, handle_len); + buffer_put_int64(&msg, offset); + buffer_put_string(&msg, data, len); + send_msg(fd_out, &msg); + debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", + id, (unsigned long long)offset, len); + } else if (ackid > id) break; - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_WRITE); - buffer_put_int(&msg, ++id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_string(&msg, data, len); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", - id, (unsigned long long)offset, len); - - status = get_status(fd_in, id); - if (status != SSH2_FX_OK) { - error("Couldn't write to remote file \"%s\": %s", - remote_path, fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - close(local_fd); - goto done; + if (id > ackid || (len == 0 && id == ackid)) { + status = get_status(fd_in, ackid); + if (status != SSH2_FX_OK) { + error("Couldn't write to remote file \"%s\": %s", + remote_path, fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + close(local_fd); + goto done; + } + ackid++; } debug3("In write loop, got %d offset %llu", len, (unsigned long long)offset); From openssh-unix-dev at progressive-comp.com Sat Jan 5 02:51:16 2002 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Fri, 4 Jan 2002 10:51:16 -0500 Subject: Strange problem from "identical" hosts Message-ID: <200201041551.KAA27772@mailer.progressive-comp.com> On 2002-01-04, "Ladner, Eric (CLAD)" wrote: > Ok.. I've got three systems, all running openssh-3.0.2p1. As a matter > of fact, they were installed from the same built tree, so I know they > are the same. > Here's the deal. I've got three systems, call them source1, source2 > and target. All are HP-UX 11.0 systems installed from the same tree. > Source1 and source2 both have thier root rsa pub keys in target's auth > keys file. > If I ssh over from source1, everything works great. If I ssh over from > source2, it asks me for root's password. > Here's a debug list of the ssh from source1 and source2 with the > differences indicated by a leading >: Can you triple-check the authorized_keys entry for the second box? Perhaps it has line-wraps in it that bollocks it up? Can you run the server with at least 'LogLevel DEBUG' (and syslog.conf capturing *.debug) or run sshd -d (or sshd -d -d) ? I'd like to do essentially the same thing you did with the ssh -v outputs, from the server. -- Hank Leininger From bbense at networking.stanford.edu Sat Jan 5 03:25:47 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Fri, 4 Jan 2002 08:25:47 -0800 (PST) Subject: Killing the builtin entropy code In-Reply-To: Message-ID: On Sun, 30 Dec 2001, Booker C. Bense wrote: > On Mon, 24 Dec 2001, Damien Miller wrote: > > > On Fri, 21 Dec 2001, Damien Miller wrote: > > > > > Over the holidays, I intend to finally rid portable OpenSSH of the > > > builtin entropy collection code. Here's what I intend to do: > > > > Have done :) > > > > Hopefully someone else will step up to the plate and write or port > > a proper Yarrow PRNG. > > > > - I have made a start using the Yarrow library provided at > > http://opensource.zeroknowledge.com/yarrow/ > > This was the only unix Yarrow implementation I could find, > it seems pretty "beta" at best. It still has the problem > of figuring out good entrophy estimators. Once the code > compiles I'll hand it out, but I'm not sure it will actually > be any improvement. > - Well, I've poked around some more and come up with another alternative. The problem is that the zkyarrow implementation is just "yarrow", and not the gathering of entropy. It's fairly easy to adapt the openssh entrophy gatherers to this zkyarrow code, but the problem is that yarrow appears to be somewhat of a dead end. - The successor to Yarrow is Tiny. It's authors include one of the Yarrow designers. Tiny is implemented by the egads software[A]. The code is a much more complete implementation. There are a few problems however, 1. The tiny algorithm is new and not published as anything other than src code, however it's mostly Yarrow with a different entrophy gathering scheme. 2. The code requires an external deamon to gather entrophy. 3. The license is GPL, but the author seems flexible on this issue. - In application, the code looks much like egd. It would be trivial to write ssh-rand-helper using the provided api. It would be not much more work to avoid the Egads library code and just talk to the egads daemon directly. This would avoid license issues. Unfortunately, this would not be useful as the "default" rand helper, for much the same reasons that egd is not a suitable default. If we really wanted to we could rip the guts out of the egads deamon and insert it into ssh-rand-helper to use it as the default. If I understand correctly, this would require a license change for egads and a fair bit of work. I guess what I'm really fishing for here is requirements. - Booker C. Bense [A]- Available at http://www.securesw.com/egads/Index.html From Nicolas.Williams at ubsw.com Sat Jan 5 03:30:34 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 4 Jan 2002 11:30:34 -0500 Subject: hang on exit bug under Linux In-Reply-To: <20020104093229.B20222@wdr.com>; from Nicolas Williams on Fri, Jan 04, 2002 at 09:32:29AM -0500 References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> <20020104091526.B1025@foo.birdnet.se> <20020104093229.B20222@wdr.com> Message-ID: <20020104113034.C20222@wdr.com> On Fri, Jan 04, 2002 at 09:32:29AM -0500, Nicolas Williams wrote: > On Fri, Jan 04, 2002 at 09:15:26AM +0100, Peter Stuge wrote: > > (The deal is that I want to make a certain PID a child of a different PID > > than it is right now.) > > You can't do that. > > You can put ssh into the background by forking off a child and exiting, > but then the shell cannot bring that child back to the foreground. > Which makes the background option not so useful. Perhaps you can just > have ssh send itself a SIGTSTP, but then you have to rely on the user to > ask the shell to actually background the process. In fact, I just tested that approach and it works, mostly, though the shell I tested it with becomes confused about the status of the jobs after it gets SIGCONT. But it works. If ssh is going to do any stdio when it gets SIGCONT, then it will likely get SIGTTIN or SIGTTOU though. Personally, I don't think the self-background option is very practical. I would be happy with an option to close the channels and exit when ssh receives the session exit message. Here's a script to emulate what I'm saying: #!/bin/ksh date foo=$$ print $foo trap 'print continue' CONT ( sleep 5 ; kill -CONT $foo ) > /dev/null 2>&1 & print "Stopping $foo" kill -TSTP $foo sleep 10 print "hey there" date exit 0 > > //Peter > > > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From CLAD at chevrontexaco.com Sat Jan 5 05:49:48 2002 From: CLAD at chevrontexaco.com (Ladner, Eric (CLAD)) Date: Fri, 4 Jan 2002 12:49:48 -0600 Subject: Strange problem from "identical" hosts Message-ID: <8F88657F29DFD11189ED0008C728C6B008A5A101@nor935-msx6.nor.chevron.com> Thank you Hank! Suprisingly, if you stretch the window out, you find those line wrap problems with ease. Stupid cut/paste problems.. argh.. Thanks! Eric -----Original Message----- From: Hank Leininger [mailto:openssh-unix-dev at progressive-comp.com] Sent: Friday, January 04, 2002 9:51 AM To: openssh-unix-dev at mindrot.org Subject: Re: Strange problem from "identical" hosts On 2002-01-04, "Ladner, Eric (CLAD)" wrote: > Ok.. I've got three systems, all running openssh-3.0.2p1. As a matter > of fact, they were installed from the same built tree, so I know they > are the same. > Here's the deal. I've got three systems, call them source1, source2 > and target. All are HP-UX 11.0 systems installed from the same tree. > Source1 and source2 both have thier root rsa pub keys in target's auth > keys file. > If I ssh over from source1, everything works great. If I ssh over from > source2, it asks me for root's password. > Here's a debug list of the ssh from source1 and source2 with the > differences indicated by a leading >: Can you triple-check the authorized_keys entry for the second box? Perhaps it has line-wraps in it that bollocks it up? Can you run the server with at least 'LogLevel DEBUG' (and syslog.conf capturing *.debug) or run sshd -d (or sshd -d -d) ? I'd like to do essentially the same thing you did with the ssh -v outputs, from the server. -- Hank Leininger _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From Peter.J.Scott at jpl.nasa.gov Sat Jan 5 06:49:36 2002 From: Peter.J.Scott at jpl.nasa.gov (Peter Scott) Date: Fri, 04 Jan 2002 11:49:36 -0800 Subject: 3.0.2 AFS login problem, Solaris 2.5.1 Message-ID: <4.3.2.7.2.20020104112248.00aa6c20@mail.webquarry.com> I've been beating myself senseless trying to build OpenSsh 3.0.1 on Solaris 2.5.1 and get AFS login working. The symptoms of the problem are: sshd builds (used --with-afs and -with-kerberos4 - there is no PAM on this box), accepts connections from non-AFS users, but does not accept a connection from an AFS user; the user sees "permission denied" after entering the password. The server (in debug mode) at this point says: debug1: attempt 2 failures 2 kerberos-iv/udp unknown service, using default port 750 Kerberos v4 TGT for joeuser unverifiable: Principal unknown (kerberos); rcmd.grimble not registered, or srvtab is wrong? debug1: krb4_cleanup_proc called Failed password for joeuser from 123.45.67.89 port 34375 ssh2 Snooping the network reveals that client machine 'grimble' sends a packet that includes the kerberos realm and "rcmd.grimble' to 'kerberos', our auth server. Server sends response that includes username, part of realm (last component is missing), and text "code = 8: Exec format er" Snooping the network when the old (SSH1) server (which works) runs reveals *no connection* to 'kerberos' over port 750 during successful login... only some stuff on 7004. So I looked at the code, wondering how the ssh1.2.21 could work where this didn't... and found that 1.2.21 used a patch from dugsong that called ka_UserAuthenticateGeneral at this point... but 3.0.2 does not call any ka_ routines. I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and that if I could make an equivalent patch to 3.0.2 that would use it, I'd be able to talk to our kaserver. It's been pointed out that if we created a principal rcmd.grimble I might be able to use what I've got, but I don't want to do anything that requires an admin. Which is the same answer to the suggestions that we're running an out-of-date kaserver. I am not the cell admin. I want 3.0.2 to work on AFS the way 1.2.21 did. I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I couldn't even get it to link; usually I eventually figure out an order of all those wretched AFS libraries that works but not this time. Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? Is there a patch to make it do so? -- Peter Scott Peter.J.Scott at jpl.nasa.gov From bbense at networking.stanford.edu Sat Jan 5 08:27:57 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Fri, 4 Jan 2002 13:27:57 -0800 (PST) Subject: 3.0.2 AFS login problem, Solaris 2.5.1 In-Reply-To: <4.3.2.7.2.20020104112248.00aa6c20@mail.webquarry.com> Message-ID: On Fri, 4 Jan 2002, Peter Scott wrote: > I've been beating myself senseless trying to build OpenSsh 3.0.1 on Solaris > 2.5.1 and get AFS login working. > > The symptoms of the problem are: sshd builds (used --with-afs and > -with-kerberos4 - there is no PAM on this box), accepts connections from > non-AFS users, but does not accept a connection from an AFS user; the user > sees "permission denied" after entering the password. > > The server (in debug mode) at this point says: > debug1: attempt 2 failures 2 > kerberos-iv/udp unknown service, using default port 750 > Kerberos v4 TGT for joeuser unverifiable: Principal unknown > (kerberos); rcmd.grimble not registered, or srvtab is wrong? > debug1: krb4_cleanup_proc called > Failed password for joeuser from 123.45.67.89 port 34375 ssh2 > - You need a srvtab for your machine to accept kerberos 4 logins. Accepting logins without verifying them against a srvtab is not considered acceptable security practice by most people. > > > I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and > that if I could make an equivalent patch to 3.0.2 that would use it, I'd be > able to talk to our kaserver. It's been pointed out that if we created a > principal rcmd.grimble I might be able to use what I've got, but I don't > want to do anything that requires an admin. Which is the same answer to > the suggestions that we're running an out-of-date kaserver. I am not the > cell admin. I want 3.0.2 to work on AFS the way 1.2.21 did. - Then you should use 1.2.21. IMHO 3.0.2 is doing things the correct way and 1.2.21 did them the wrong way. > > I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I > couldn't even get it to link; usually I eventually figure out an order of > all those wretched AFS libraries that works but not this time. > > Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? - Because it's insecure? > Is there a patch to make it do so? - It's wildly insecure in my humble opinion, but there was a post on this list last month to allow kerberos 4 logins without access to a srvtab. You are leaving your machines wide open to anybody that can inject packets into your local network. It's pretty much the equivalent of using hosts.allow with old versions of rsh. (i.e. you're trusting the ip address in the packet as sufficient authentication. ) - Look for a message with the subject PATCH: Kerberos password authentication w/o KDC verification - It was posted to the list in early December 2001. You might want to read Dug Song's current opinion on how kerberos logins should work. http://www.monkey.org/~dugsong/kdcspoof.tar.gz - Booker C. Bense From Peter.J.Scott at jpl.nasa.gov Sat Jan 5 09:58:50 2002 From: Peter.J.Scott at jpl.nasa.gov (Peter Scott) Date: Fri, 04 Jan 2002 14:58:50 -0800 Subject: 3.0.2 AFS login problem, Solaris 2.5.1 In-Reply-To: References: <4.3.2.7.2.20020104112248.00aa6c20@mail.webquarry.com> Message-ID: <4.3.2.7.2.20020104142702.00b09850@mail2a.jpl.nasa.gov> At 01:27 PM 1/4/02 -0800, Booker C. Bense wrote: > > The server (in debug mode) at this point says: > > debug1: attempt 2 failures 2 > > kerberos-iv/udp unknown service, using default port 750 > > Kerberos v4 TGT for joeuser unverifiable: Principal unknown > > (kerberos); rcmd.grimble not registered, or srvtab is wrong? > > debug1: krb4_cleanup_proc called > > Failed password for joeuser from 123.45.67.89 port 34375 ssh2 > >- You need a srvtab for your machine to accept kerberos 4 logins. >Accepting logins without verifying them against a srvtab is not >considered acceptable security practice by most people. > > > I am suspecting that ka_UserAuthenticateGeneral is what talks over 7004 and > > that if I could make an equivalent patch to 3.0.2 that would use it, I'd be > > able to talk to our kaserver. [snip] > > I tried a naive patch to 3.0.2 to use ka_UserAuthenticateGeneral and I > > couldn't even get it to link; usually I eventually figure out an order of > > all those wretched AFS libraries that works but not this time. > > > > Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? > >- Because it's insecure? Thanks for this information. I've read the thread and URL you provided. If you don't mind what may be a stupid question - does this imply that the stock AFS login - or at least the Transarc one we are using - is insecure? Because all it has to go on is a username and password, and we already know that the kaservers don't have a srvtab for the client machine. If it isn't insecure, what makes it secure? I looked in OpenAFS source and if I'm looking at the right place, the login does call ka_UserAuthenticateGeneral... and without a srvtab for the client how can that be good enough? -- Peter Scott Peter.J.Scott at jpl.nasa.gov From jmknoble at pobox.com Sat Jan 5 10:45:05 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 4 Jan 2002 18:45:05 -0500 Subject: hang on exit bug under Linux In-Reply-To: <20020104093229.B20222@wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Jan 04, 2002 at 09:32:29AM -0500 References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> <20020104091526.B1025@foo.birdnet.se> <20020104093229.B20222@wdr.com> Message-ID: <20020104184505.H9973@zax.half.pint-stowp.cx> Circa 2002-Jan-04 09:32:29 -0500 dixit Nicolas Williams: : On Fri, Jan 04, 2002 at 09:15:26AM +0100, Peter Stuge wrote: : > On Thu, Jan 03, 2002 at 05:28:19PM +0100, Markus Friedl wrote: : > > for rlogin-like behaviour (i.e. a pty is allocated) it might : > > be an option to discard data, like telnetd/rlogind do. : > : > I could fix up my patch to only apply when ssh is invoked as slogin and : > change the configuration directive name to reflect this.. : > : > Should I bother? : : Yes. No. If you want to do that, you shouldn't care what the invocation name is, but rather whether ssh requests that a pty be allocated. I never use slogin, just 'ssh hostname'. And there's a command-line switch to explicitly request a pty as well. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020104/c48318ba/attachment.bin From hangang_2k at yahoo.com Sat Jan 5 15:03:56 2002 From: hangang_2k at yahoo.com (gang han) Date: Fri, 4 Jan 2002 20:03:56 -0800 (PST) Subject: why always "permission denied" in ssh attempts to a linux machine running openssh? Message-ID: <20020105040356.19508.qmail@web20007.mail.yahoo.com> My questions might be silly since I am a newbie in linux. Your helps are highly appreciated. I recent setup a computer (in workstation mode) with Redhat 7.0. The original installation includes ssh client, but not the sshd. I download the openssh source code (openssh-3.0.2p1.tar.gz) and compiled it following the instruction. The whole process was quite easy and smooth. Then I run the sshd from /usr/local/sbin. I also added "sshd: ALL" in the /etc/hosts.allow file. The problem is whenever I tried to connect this computer remotely using "ssh computer_ip_address -l user_name", the connection was failed. I was prompted for password type-in. After I typed the password, I always got "permission denied" or "access denied" message. Could anyone tell me what is wrong, and how to solve the problem? Also, what is the difference to add the sshd in this way from using the rpm? If I want to add sshd using rpm, shall I remove the current sshd installation? How to do that? Thanks in advance! By the way, I did not subscribe the mailing list. Please send your reply to me directly by replying my message. --Gang Han __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From markus at openbsd.org Sat Jan 5 21:36:23 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 5 Jan 2002 11:36:23 +0100 Subject: hang on exit bug under Linux In-Reply-To: <20020104184505.H9973@zax.half.pint-stowp.cx>; from jmknoble@pobox.com on Fri, Jan 04, 2002 at 06:45:05PM -0500 References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> <20020104091526.B1025@foo.birdnet.se> <20020104093229.B20222@wdr.com> <20020104184505.H9973@zax.half.pint-stowp.cx> Message-ID: <20020105113623.A19062@folly> i posted this before. there was lots of talk, but not much feed back. > Message-ID: <20011005173908.A8148 at faui02.informatik.uni-erlangen.de> > perhaps it's acceptable to discard data for sessions with ttys, > but i'm not sure yet. > > session.c:session_exit_message() > > if (c->ostate != CHAN_OUTPUT_CLOSED) > chan_write_failed(c); > + if (s->ttyfd != -1 && option.discard && c->istate == CHAN_INPUT_OPEN) > + chan_read_failed(c); > s->chanid = -1; > > should help. From tori at igor.prodako.se Sun Jan 6 03:28:52 2002 From: tori at igor.prodako.se (=?ISO-8859-1?Q?Tobias_Ringstr=F6m?=) Date: Sat, 5 Jan 2002 17:28:52 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Fri, 4 Jan 2002 mouring at etoh.eviladmin.org wrote: > No it was not in the CVS tree yet. There was still discussions as to the > implementation. I have a version that does not do more more then two > overlapping writes. I tried to vary the number of overlapping writes, but there is something (not so) funny going on that I must understand first. It seems to have something to do with pipes/lo in Linux. I'll be back... > I'll have to take a look at your patch a little closer, but I worry about > attempting to optimize the number of writes/reads done in a single > sitting. This could feesable change per hardware, per network, etc. If But more should be better unless we hit errors or EOF. That must be balanced of course. I really think that the gain from one to two should be really big, and that it should not increase much after that. I do not yet understand why this does not seem to be the case. > we want to go this way I really suggest we flesh out that defination using > -r. That way the user can optimize it for themselves. With -r 1 mimicing > the current behavior. Then set a default (2 - 4) if -r is not used. That is certainly doable. The patch I sent was just to get some more feedback. I'd like to try a couple of things more before I'm satisfied. And as I said above, I seem to have hit some be interaction with pipes and localdevs in Linux. Btw, you need to handle reordered responses in your patch to be draft standard compliant. Just check for an interval of id:s when reading the status message. /Tobias From tori at ringstrom.mine.nu Sun Jan 6 07:22:55 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sat, 5 Jan 2002 21:22:55 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: [Please ignore my previous post since it has a broken From address.] On Fri, 4 Jan 2002 mouring at etoh.eviladmin.org wrote: > No it was not in the CVS tree yet. There was still discussions as to the > implementation. I have a version that does not do more more then two > overlapping writes. I tried to vary the number of overlapping writes, but there is something (not so) funny going on that I must understand first. It seems to have something to do with pipes/lo in Linux. I'll be back... > I'll have to take a look at your patch a little closer, but I worry about > attempting to optimize the number of writes/reads done in a single > sitting. This could feesable change per hardware, per network, etc. If But more should be better unless we hit errors or EOF. That must be balanced of course. I really think that the gain from one to two should be really big, and that it should not increase much after that. I do not yet understand why this does not seem to be the case. > we want to go this way I really suggest we flesh out that defination using > -r. That way the user can optimize it for themselves. With -r 1 mimicing > the current behavior. Then set a default (2 - 4) if -r is not used. That is certainly doable. The patch I sent was just to get some more feedback. I'd like to try a couple of things more before I'm satisfied. And as I said above, I seem to have hit some be interaction with pipes and localdevs in Linux. Btw, you need to handle reordered responses in your patch to be draft standard compliant. Just check for an interval of id:s when reading the status message. /Tobias From dan at doxpara.com Sun Jan 6 08:22:53 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 5 Jan 2002 13:22:53 -0800 Subject: [PATCH] Improving sftp client performance References: Message-ID: <00b301c1962f$23385c10$1701000a@effugas> Tobias-- I'm a little wary of what's going on at the hard drive level. Clever file system tricks aside, it's *always* faster to read and write sequential blocks of data. Might there be any coalescing of requests on the server level? Also, I think it was mentioned that the overlapping techniques are only being used for blocks within one file. It's *very* common to need to copy vast numbers of small files from one location to another, and finding efficient means of doing so can sometimes be challenging. It's something to keep in mind. Thanks for your work! --Dan From dan at doxpara.com Sun Jan 6 08:22:53 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 5 Jan 2002 13:22:53 -0800 Subject: [PATCH] Improving sftp client performance References: Message-ID: <00b201c1962f$22dcce90$1701000a@effugas> Tobias-- I'm a little wary of what's going on at the hard drive level. Clever file system tricks aside, it's *always* faster to read and write sequential blocks of data. Might there be any coalescing of requests on the server level? Also, I think it was mentioned that the overlapping techniques are only being used for blocks within one file. It's *very* common to need to copy vast numbers of small files from one location to another, and finding efficient means of doing so can sometimes be challenging. It's something to keep in mind. Thanks for your work! --Dan From tori at ringstrom.mine.nu Sun Jan 6 08:26:50 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sat, 5 Jan 2002 22:26:50 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Sat, 5 Jan 2002, Tobias Ringstrom wrote: > On Fri, 4 Jan 2002 mouring at etoh.eviladmin.org wrote: > > > No it was not in the CVS tree yet. There was still discussions as to the > > implementation. I have a version that does not do more more then two > > overlapping writes. > > I tried to vary the number of overlapping writes, but there is something > (not so) funny going on that I must understand first. It seems to have > something to do with pipes/lo in Linux. I'll be back... Eureka! I found the real problem. I had a feeling somthing was not right when I needed such a big number of overlapping requests. The problem is the Nagle algorithm. Adding TCP_NODELAY to both ssh and sshd makes them fly. Adding a flag to ssh that turns off Nagle would be easy. I wonder what the best way is to to turn it off on the server side. One way is of course for the client to turn it off remotely. Another way would be to turn it off per subsystem using the config file. Yet another way would be for the subsystem to send a signal to its sshd. What do you think? > > we want to go this way I really suggest we flesh out that defination using > > -r. That way the user can optimize it for themselves. With -r 1 mimicing > > the current behavior. Then set a default (2 - 4) if -r is not used. With TCP_NODELAY, using two outstanding requests should be enough. /Tobias From tori at ringstrom.mine.nu Sun Jan 6 08:51:37 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sat, 5 Jan 2002 22:51:37 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: <00b301c1962f$23385c10$1701000a@effugas> Message-ID: On Sat, 5 Jan 2002, Dan Kaminsky wrote: > I'm a little wary of what's going on at the hard drive level. Clever > file system tricks aside, it's *always* faster to read and write sequential > blocks of data. Might there be any coalescing of requests on the server > level? The openssh sftp client will always upload file blocks in sequence. There is one case in my patch where we will issure read request packets out of sequence. It happens when we have two outstanding read requests of 8192 byte each, and the first returns with less than the requested amount of data. In this case we will read the missing data out of sequence. Note that this only happens for servers that cannot handle 8192 byte reads. I could fix that by reducing the size of the requested blocks, but I doubt we will need that since the blocks are so small already. Another case is if the remote server reorders the responses to our read requests. If that happens we will not write to the file sequentially. The openssh sftp server does not reorder responses, but if need arises, Or are you saying that the block size should be greater than 8192 bytes? > Also, I think it was mentioned that the overlapping techniques are only > being used for blocks within one file. It's *very* common to need to copy > vast numbers of small files from one location to another, and finding > efficient means of doing so can sometimes be challenging. It's something to > keep in mind. Correct, but I doubt the openssh sftp client is, or ever will be, the tool for that. /Tobias From listS+openssh-unix-dev at niss.com Sun Jan 6 09:09:17 2002 From: listS+openssh-unix-dev at niss.com (Scott Bolte) Date: Sat, 05 Jan 2002 16:09:17 -0600 Subject: new feature w/ patch Message-ID: <200201052209.g05M9HA23929@crag.niss.com> I've attached a patch to OpenSSH 3.0.2p1 that will allow the client side of local port forwarding to be bound to a single address. For my purposes, binding to 127.0.0.1 or (via GatewayPorts) all addresses would not work. I overloaded the "-b local_host" option so that it's address will be used when "-L port:remote_host:remote_port" is also specified. Today is the first day I played with OpenSSH 3.x or port forwarding. Therefore I am not sure if my use of -b with -L will break any existing use cases. If it does, please speak up. In case you are curious, here is the scenario I have... On FreeBSD there is the idea of a jail. A jail takes the old idea of chroot and extends it quite a bit. Aside from limiting the privileges of root in a jail, each jail can also have its own IP address. Therefore, one host can easily have two instances of (for example) Apache, each bound to port 80. (Yes, this can be done simply by multi-homing the host, but there are other reasons for a jail.) On one host on my LAN, I have two jails. Call them jail_1 (127.74.0.1) and jail_2 (127.74.0.2). I want to provide a remote friend access to those jails even though they are not routable addresses for him. With my patch, my friend can add two IP aliases on a host on his LAN. Let's call them mirror_1 (127.77.0.1) and mirror_2 (127.77.0.2). If "remote" is in root's ~/.ssh/config file pointing to my system, then the following two commands will provide two unique tunnels linking each mirror with its corresponding jail: root# ssh -b mirror_1 -N -f -L 80:jail_1:80 remote root# ssh -b mirror_2 -N -f -L 80:jail_2:80 remote Either the jails or the mirrors could use 10.* instead of 127.* if it is safe to allow general access on the LAN. Using the use case of Apache, my friend can then use http://mirror_1:80/ and http://mirror_2:80/ and reach my jails transparently. If we both then aliased mirror_1 and jail_1 to be virtual_1, we could even use the same host names. The commands below show my local test case. : : Set up two aliases, one representing a FreeBSD jail and the : other a remote mirror. : root# grep 127.7 /etc/hosts 127.74.0.1 localjail_1 127.77.0.1 localmirror_1 root# ifconfig lo0 inet localjail_1 netmask 0xffffffff alias root# ifconfig lo0 inet localmirror_1 netmask 0xffffffff alias : : Make sure (ssh remote) is a login into localhost. : user% tail -4 ~/.ssh/config Host remote Protocol 2 IdentityFile /home/scott/.ssh/id_dsa HostName 127.0.0.1 : : Start the tunnel so that it is locally bound to the host : address of localmirror_1. The 'remote' end happens to be local : for this example, but it easily could be half way around the : world. : user% ssh -b localmirror_1 -N -f -L 1111:localjail_1:2222 remote : : Run a test script that listens on a host:port and prints out : what it sees. Note the last line below was actually printed : after portsend was called. : user% portlisten.pl -a localjail_1 -p 2222 -w 600 & [Server ./portlisten.pl accepting clients on port 2222.] [Connect from 127.74.0.1:3521] read "in the mirror, out the jail" : : Now send a test message in one port of the mirror and see it : come out the other port in the jail. : user% ~/WIP-perl/portsend.pl -a localmirror_1 -p 1111 in the mirror, out the jail : : Verify that the client side of the tunnel is bound to a single : address. : root# netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 localjail_1.3521 localjail_1.2222 TIME_WAIT tcp4 0 0 localmirror_1.3520 localmirror_1.1111 TIME_WAIT tcp4 0 0 localjail_1.2222 *.* LISTEN tcp4 0 0 localmirror_1.1111 *.* LISTEN tcp4 0 0 localhost.ssh localmirror_1.3517 ESTABLISHED tcp4 0 0 localmirror_1.3517 localhost.ssh ESTABLISHED ... So folks, what do I need to do to have this feature added to the mainline of OpenSSH? Thanks, Scott diff -ru openssh-3.0.2p1/channels.c openssh-3.0.2p1-NewFeature/channels.c --- openssh-3.0.2p1/channels.c Thu Oct 11 20:35:05 2001 +++ openssh-3.0.2p1-NewFeature/channels.c Sat Jan 5 15:36:10 2002 @@ -2057,11 +2057,11 @@ * channel to host:port from remote side. */ int -channel_request_local_forwarding(u_short listen_port, const char *host_to_connect, - u_short port_to_connect, int gateway_ports) +channel_request_local_forwarding(const char *listen_host, u_short listen_port, + const char *host_to_connect, u_short port_to_connect, int gateway_ports) { return channel_request_forwarding( - NULL, listen_port, + listen_host, listen_port, host_to_connect, port_to_connect, gateway_ports, /*remote_fwd*/ 0); } @@ -2080,7 +2080,7 @@ int success, sock, on = 1, type; struct addrinfo hints, *ai, *aitop; char ntop[NI_MAXHOST], strport[NI_MAXSERV]; - const char *host; + const char *host, *listen_host = NULL; struct linger linger; success = 0; @@ -2089,6 +2089,7 @@ host = listen_address; type = SSH_CHANNEL_RPORT_LISTENER; } else { + listen_host = listen_address; host = host_to_connect; type = SSH_CHANNEL_PORT_LISTENER; } @@ -2108,7 +2109,7 @@ hints.ai_flags = gateway_ports ? AI_PASSIVE : 0; hints.ai_socktype = SOCK_STREAM; snprintf(strport, sizeof strport, "%d", listen_port); - if (getaddrinfo(NULL, strport, &hints, &aitop) != 0) + if (getaddrinfo(listen_host, strport, &hints, &aitop) != 0) packet_disconnect("getaddrinfo: fatal error"); for (ai = aitop; ai; ai = ai->ai_next) { @@ -2259,7 +2260,7 @@ port); #endif /* Initiate forwarding */ - channel_request_local_forwarding(port, hostname, host_port, gateway_ports); + channel_request_local_forwarding(NULL, port, hostname, host_port, gateway_ports); /* Free the argument string. */ xfree(hostname); diff -ru openssh-3.0.2p1/channels.h openssh-3.0.2p1-NewFeature/channels.h --- openssh-3.0.2p1/channels.h Sun Nov 11 18:04:55 2001 +++ openssh-3.0.2p1-NewFeature/channels.h Sat Jan 5 14:34:05 2002 @@ -189,7 +189,7 @@ int channel_connect_to(const char *, u_short); int channel_connect_by_listen_address(u_short); void channel_request_remote_forwarding(u_short, const char *, u_short); -int channel_request_local_forwarding(u_short, const char *, u_short, int); +int channel_request_local_forwarding(const char *, u_short, const char *, u_short, int); int channel_request_forwarding(const char *, u_short, const char *, u_short, int, int); diff -ru openssh-3.0.2p1/ssh.c openssh-3.0.2p1-NewFeature/ssh.c --- openssh-3.0.2p1/ssh.c Sun Nov 11 17:52:04 2001 +++ openssh-3.0.2p1-NewFeature/ssh.c Sat Jan 5 14:37:50 2002 @@ -830,14 +830,27 @@ { int success = 0; int i; + char *local_host; + + if (options.bind_address == NULL) { + if (options.gateway_ports == 0) { + local_host = "localhost"; + } else { + local_host = "{ANY}"; + } + } else { + local_host = options.bind_address; + } /* Initiate local TCP/IP port forwardings. */ for (i = 0; i < options.num_local_forwards; i++) { - debug("Connections to local port %d forwarded to remote address %.200s:%d", + debug("Connections to local port %.200s:%d forwarded to remote address %.200s:%d", + local_host, options.local_forwards[i].port, options.local_forwards[i].host, options.local_forwards[i].host_port); success += channel_request_local_forwarding( + options.bind_address, options.local_forwards[i].port, options.local_forwards[i].host, options.local_forwards[i].host_port, From dan at doxpara.com Sun Jan 6 09:20:32 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 5 Jan 2002 14:20:32 -0800 Subject: [PATCH] Improving sftp client performance References: Message-ID: <00c701c19637$30c02130$1701000a@effugas> > The openssh sftp client will always upload file blocks in sequence. Good stuff :-) > > Also, I think it was mentioned that the overlapping techniques are only > > being used for blocks within one file. It's *very* common to need to copy > > vast numbers of small files from one location to another, and finding > > efficient means of doing so can sometimes be challenging. It's something to > > keep in mind. > > Correct, but I doubt the openssh sftp client is, or ever will be, the tool > for that. Shockingly enough, heavily multithreaded FTP has become *the* preferred method for large scale minifile dumping around here. LeechFTP uses a variable number of threads, from five to fifteen to service a unified queue of files that scales to the thousands. It ends up being even faster than my normally preferred method, which is tar-over-ssh. Now, I bring this up because the one Windows SFTP client I've seen operates in *exactly* this manner, and is blisteringly fast. Clearly there's a use for extending your blocking code across multiple files, but I do admit it may not be easily done. Just some perspective. --Dan From mouring at etoh.eviladmin.org Sun Jan 6 11:52:43 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 5 Jan 2002 18:52:43 -0600 (CST) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: > Btw, you need to handle reordered responses in your patch to be draft > standard compliant. Just check for an interval of id:s when reading the > status message. > Mine will not allow for reordered responses. If ID 4 comes before ID 3 it will abort. I was think about this and with two it should not be a great deal, but the larger number of pending requests out the more important it is The only concern of mine (mainly with download) is the sender may decide to change it's package size in midstream. Also, you may want to check out pushing BLOCKSIZE (think that is right, not looking at the code) to 4092 which is the max size the RFC states. This may change your testing. - Ben From mouring at etoh.eviladmin.org Sun Jan 6 12:00:32 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 5 Jan 2002 19:00:32 -0600 (CST) Subject: [PATCH] Improving sftp client performance In-Reply-To: <00c701c19637$30c02130$1701000a@effugas> Message-ID: On Sat, 5 Jan 2002, Dan Kaminsky wrote: > > The openssh sftp client will always upload file blocks in sequence. > > Good stuff :-) > > > > Also, I think it was mentioned that the overlapping techniques are > only > > > being used for blocks within one file. It's *very* common to need to > copy > > > vast numbers of small files from one location to another, and finding > > > efficient means of doing so can sometimes be challenging. It's > something to > > > keep in mind. > > > > Correct, but I doubt the openssh sftp client is, or ever will be, the tool > > for that. > > Shockingly enough, heavily multithreaded FTP has become *the* preferred > method for large scale minifile dumping around here. LeechFTP uses a > variable number of threads, from five to fifteen to service a unified queue > of files that scales to the thousands. It ends up being even faster than my > normally preferred method, which is tar-over-ssh. > Doing multiple ftp streams is what you are refering to. That could be done, but it does not improve a single file transfer. I think I would perfer to get this working first and then look at if we want to improve the "mget *" or "mput *" case. Because that code would be at a higher level in some respects. - Ben From mouring at etoh.eviladmin.org Sun Jan 6 12:27:55 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 5 Jan 2002 19:27:55 -0600 (CST) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Sat, 5 Jan 2002, Tobias Ringstrom wrote: > On Sat, 5 Jan 2002, Tobias Ringstrom wrote: > > > On Fri, 4 Jan 2002 mouring at etoh.eviladmin.org wrote: > > > > > No it was not in the CVS tree yet. There was still discussions as to the > > > implementation. I have a version that does not do more more then two > > > overlapping writes. > > > > I tried to vary the number of overlapping writes, but there is something > > (not so) funny going on that I must understand first. It seems to have > > something to do with pipes/lo in Linux. I'll be back... > > Eureka! I found the real problem. I had a feeling somthing was not right > when I needed such a big number of overlapping requests. > > The problem is the Nagle algorithm. Adding TCP_NODELAY to both ssh and > sshd makes them fly. Adding a flag to ssh that turns off Nagle would be > easy. I wonder what the best way is to to turn it off on the server side. > One way is of course for the client to turn it off remotely. Another way > would be to turn it off per subsystem using the config file. Yet another > way would be for the subsystem to send a signal to its sshd. What do you > think? > This is a current topic else where on the two OpenSSH lists. I believe we don't want TCP_NODELAY for tty sessions, but maybe we can disable it on all non-tty sessions. That would handled the client side. As to the server side there is talk about using TCP_NODELAY everywhere. Thoughts Markus? Steve? Damien? - Ben From dan at doxpara.com Sun Jan 6 13:17:18 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 5 Jan 2002 18:17:18 -0800 Subject: [PATCH] Improving sftp client performance References: Message-ID: <00f701c19658$442f3f00$1701000a@effugas> > Doing multiple ftp streams is what you are refering to. That could be > done, but it does not improve a single file transfer. I think I would > perfer to get this working first and then look at if we want to improve > the "mget *" or "mput *" case. > > Because that code would be at a higher level in some respects. The direct equivalent to what happens in the FTP realm is for multiple ssh sessions to be established with multiple sftp-server's, each taking individual files as fast as possible. SFTP shouldn't require such inelegance. Instead of: 1) Choose file 2) Send a windowed series of blocks from that one file, until there are no blocks remaining 3) Choose next file we should be able to: 1) Choose file 2) Send a windowed series of blocks from that one file 3) If there are no further blocks available in this file, choose next file and begin sending blocks from that. Repeat ad infinitum until window size is exhausted There's a real elegance to this solution: For large files, we remain completely sequential, avoiding the useless and counterproductive interleaving that multi-thread FTP tends to create. But for small files, we have no downtime between each transfer. I definitely grant that this is of less import than simply getting individual file transfers to go at a reasonable speed. But it's not useless to be able to transfer many individual files quickly -- not in the least. --Dan From stevesk at pobox.com Sun Jan 6 18:23:23 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sat, 5 Jan 2002 23:23:23 -0800 (PST) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Sat, 5 Jan 2002, Tobias Ringstrom wrote: :The problem is the Nagle algorithm. Adding TCP_NODELAY to both ssh and :sshd makes them fly. Adding a flag to ssh that turns off Nagle would be :easy. I wonder what the best way is to to turn it off on the server side. is the problem that we are not doing >=MSS size sends? From tori at ringstrom.mine.nu Sun Jan 6 19:54:59 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 6 Jan 2002 09:54:59 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Sat, 5 Jan 2002, Kevin Steves wrote: > On Sat, 5 Jan 2002, Tobias Ringstrom wrote: > :The problem is the Nagle algorithm. Adding TCP_NODELAY to both ssh and > :sshd makes them fly. Adding a flag to ssh that turns off Nagle would be > :easy. I wonder what the best way is to to turn it off on the server side. > > is the problem that we are not doing >=MSS size sends? Yes. The read requests and write responses are very small, typically a few tens of bytes. Since we are sending packets over the TCP link, and latency is important, Nagle should not be used. /Tobias From tori at ringstrom.mine.nu Sun Jan 6 20:08:07 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 6 Jan 2002 10:08:07 +0100 (CET) Subject: [PATCH] Improving sftp client performance In-Reply-To: Message-ID: On Sat, 5 Jan 2002 mouring at etoh.eviladmin.org wrote: > On Sat, 5 Jan 2002, Tobias Ringstrom wrote: > > > The problem is the Nagle algorithm. [...] > > This is a current topic else where on the two OpenSSH lists. I believe > we don't want TCP_NODELAY for tty sessions, but maybe we can disable it > on all non-tty sessions. That would handled the client side. As to the > server side there is talk about using TCP_NODELAY everywhere. That would be the complete opposite of the current situation, right? Using Nagle for tty sessions would mean fewer packets on the network, but more latency. Increasing latency for typing sounds really bad, especially since typing is so slow that it will not be a noticable utilization of any sane network. /Tobias From markus at openbsd.org Sun Jan 6 20:49:37 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 6 Jan 2002 10:49:37 +0100 Subject: new feature w/ patch In-Reply-To: <200201052209.g05M9HA23929@crag.niss.com>; from listS+openssh-unix-dev@niss.com on Sat, Jan 05, 2002 at 04:09:17PM -0600 References: <200201052209.g05M9HA23929@crag.niss.com> Message-ID: <20020106104937.B32346@folly> On Sat, Jan 05, 2002 at 04:09:17PM -0600, Scott Bolte wrote: > I've attached a patch to OpenSSH 3.0.2p1 that will allow the client > side of local port forwarding to be bound to a single address. For > my purposes, binding to 127.0.0.1 or (via GatewayPorts) all addresses > would not work. I overloaded the "-b local_host" option so that > it's address will be used when "-L port:remote_host:remote_port" > is also specified. we are going to change -L, e.g. -L listenaddr:listenport:targethost:targetport -m From sturle.sunde at usit.uio.no Mon Jan 7 06:22:27 2002 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 06 Jan 2002 20:22:27 +0100 Subject: hang on exit bug under Linux In-Reply-To: <20020105113623.A19062@folly> References: <3C34836E.4090203@db.com> <20020103172818.A15928@faui02> <20020104091526.B1025@foo.birdnet.se> <20020104093229.B20222@wdr.com> <20020104184505.H9973@zax.half.pint-stowp.cx> <20020105113623.A19062@folly> Message-ID: Markus Friedl writes: > i posted this before. > there was lots of talk, but not much feed back. IMHO this solution is beautiful! Exactly what I want. -- Sturle ~~~~~~ From mperham at perham.net Mon Jan 7 07:17:57 2002 From: mperham at perham.net (Mike Perham) Date: Sun, 6 Jan 2002 15:17:57 -0500 (EST) Subject: sftp/scp performance testing Message-ID: Folks, I've noticed poor performance using sftp. If anyone has any advice on how to improve performance, I'd like to hear it. Test simply involved transferring a single 143MB MP3 file using defaults for all the program configs. The opensshd 3.0.2p1 server is used in all tests. Software: openssh suite 3.0.2p1 psftp (putty sftp client) latest dev snapshot pscp (putty scp client) latest dev snapshot winscp 2.0 beta cygwin 1.3.6 windows xp Localhost (client/server on same box) opensftp - 5.5MB/min putty sftp - 6MB/min open scp - 56MB/min winscp2 - 95MB/min putty scp - 280MB/min windows copy - 780MB/min (11 sec) 10mbit LAN (same binaries, both xp machines) putty sftp - 1.2MB/min opensftp - 3.9MB/min winscp2 - 9MB/min open scp - 50MB/min putty scp - 65MB/min windows network copy - 68MB/min I should also add that these machines are both P3 or better and both have half gig of ram. None of the secure tests peaked the CPU or gave any indictation of a net/IO bottleneck in the task manager. I imagine the two windows copy tests were peaking the IO/net bandwidth. Questions: why is sftp performance so much lower than scp performance across the board for this simple test? Does this point to a server-side issue? Thoughts? mike From tori at ringstrom.mine.nu Mon Jan 7 08:54:03 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 6 Jan 2002 22:54:03 +0100 (CET) Subject: sftp/scp performance testing In-Reply-To: Message-ID: On Sun, 6 Jan 2002, Mike Perham wrote: > Folks, I've noticed poor performance using sftp. If anyone has any > advice on how to improve performance, I'd like to hear it. Test simply > involved transferring a single 143MB MP3 file using defaults for all the > program configs. The opensshd 3.0.2p1 server is used in all tests. This is currently under discussion. It'd be great if you could apply the enclosed patch, give it a try, and report the results. Note that you need to install it properly, or your old ssh binary will still be used. This patch enables TCP_NODELAY for the client and the server, as well as using overlapping requests. /Tobias diff -ru openssh-3.0.2p1.orig/sftp-client.c openssh-3.0.2p1.sftp/sftp-client.c --- openssh-3.0.2p1.orig/sftp-client.c Wed Jul 18 17:45:45 2001 +++ openssh-3.0.2p1.sftp/sftp-client.c Sun Jan 6 22:52:10 2002 @@ -45,6 +45,15 @@ /* How much data to read/write at at time during copies */ /* XXX: what should this be? */ #define COPY_SIZE 8192 +/* Maximum number of outstanding requests */ +#define OVERLAPPING_REQUESTS 2 + +/* A read/write request */ +struct request { + u_int id; + u_int len; + u_int64_t offset; +}; /* Message ID */ static u_int msg_id = 1; @@ -215,6 +224,44 @@ return(a); } +static int +find_request(struct request *rq, int num, u_int id) +{ + int i; + + for (i = 0; i < num; ++i) { + if (rq[i].id == id) + break; + } + + if (i == num) + fatal("Request ID mismatch (%d)", id); + + return i; +} + +static void +remove_request(struct request *rq, int *num, int i) +{ + memmove(rq + i, rq + i + 1, (*num - i - 1) * sizeof(struct request)); + --*num; +} + +static void +send_request(int fd, const char *handle, u_int handle_len, int type, + const struct request *rq, Buffer *m) +{ + buffer_clear(m); + buffer_put_char(m, SSH2_FXP_READ); + buffer_put_int(m, rq->id); + buffer_put_string(m, handle, handle_len); + buffer_put_int64(m, rq->offset); + buffer_put_int(m, rq->len); + send_msg(fd, m); + debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", + rq->id, rq->offset, rq->len); +} + int do_init(int fd_in, int fd_out) { @@ -674,12 +721,15 @@ int pflag) { int local_fd; - u_int expected_id, handle_len, mode, type, id; + u_int handle_len, mode, type, id; u_int64_t offset; char *handle; Buffer msg; Attrib junk, *a; int status; + struct request req[OVERLAPPING_REQUESTS]; + int num_req = 0, max_req = 1, reply; + int write_error = 0, read_error = 0, write_errno; a = do_stat(fd_in, fd_out, remote_path, 0); if (a == NULL) @@ -726,87 +776,103 @@ /* Read from remote and write to local */ offset = 0; - for(;;) { - u_int len; + while (num_req > 0 || max_req > 0) { char *data; + u_int len; - id = expected_id = msg_id++; - - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_READ); - buffer_put_int(&msg, id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_int(&msg, COPY_SIZE); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", - id, (u_int64_t)offset, COPY_SIZE); + /* Send some more requests */ + while (num_req < max_req) { + req[num_req].id = msg_id++; + req[num_req].len = COPY_SIZE; + req[num_req].offset = offset; + offset += req[num_req].len; + num_req++; + send_request(fd_out, handle, handle_len, SSH2_FXP_READ, + &req[num_req - 1], &msg); + } buffer_clear(&msg); - get_msg(fd_in, &msg); type = buffer_get_char(&msg); id = buffer_get_int(&msg); debug3("Received reply T:%d I:%d", type, id); - if (id != expected_id) - fatal("ID mismatch (%d != %d)", id, expected_id); - if (type == SSH2_FXP_STATUS) { + reply = find_request(req, num_req, id); + + switch (type) { + case SSH2_FXP_STATUS: status = buffer_get_int(&msg); + if (status != SSH2_FX_EOF) + read_error = 1; + max_req = 0; + remove_request(req, &num_req, reply); + break; + case SSH2_FXP_DATA: + data = buffer_get_string(&msg, &len); + if (len > req[reply].len) + fatal("Received more data than asked for " + "%d > %d", len, req[reply].len); + + debug3("In read loop, got %d offset %llu", + len, req[reply].offset); + if ((lseek(local_fd, req[reply].offset, SEEK_SET) == -1 || + atomicio(write, local_fd, data, len) != len) && + !write_error) { + write_errno = errno; + write_error = 1; + max_req = 0; + } + xfree(data); - if (status == SSH2_FX_EOF) - break; + if (len == req[reply].len) + remove_request(req, &num_req, reply); else { - error("Couldn't read from remote " - "file \"%s\" : %s", remote_path, - fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - goto done; + /* Resend the request for the missing data */ + req[reply].id = msg_id++; + req[reply].len -= len; + req[reply].offset += len; + send_request(fd_out, handle, handle_len, + SSH2_FXP_READ, &req[reply], &msg); } - } else if (type != SSH2_FXP_DATA) { + if (max_req > 0 && max_req < OVERLAPPING_REQUESTS) + ++max_req; + break; + default: fatal("Expected SSH2_FXP_DATA(%d) packet, got %d", - SSH2_FXP_DATA, type); - } - - data = buffer_get_string(&msg, &len); - if (len > COPY_SIZE) - fatal("Received more data than asked for %d > %d", - len, COPY_SIZE); - - debug3("In read loop, got %d offset %llu", len, - (u_int64_t)offset); - if (atomicio(write, local_fd, data, len) != len) { - error("Couldn't write to \"%s\": %s", local_path, - strerror(errno)); - do_close(fd_in, fd_out, handle, handle_len); - status = -1; - xfree(data); - goto done; + SSH2_FXP_DATA, type); } - - offset += len; - xfree(data); } - status = do_close(fd_in, fd_out, handle, handle_len); - /* Override umask and utimes if asked */ + if (read_error) { + error("Couldn't read from remote " + "file \"%s\" : %s", remote_path, + fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + } else if (write_error) { + error("Couldn't write to \"%s\": %s", local_path, + strerror(write_errno)); + status = -1; + do_close(fd_in, fd_out, handle, handle_len); + } else { + status = do_close(fd_in, fd_out, handle, handle_len); + + /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD - if (pflag && fchmod(local_fd, mode) == -1) + if (pflag && fchmod(local_fd, mode) == -1) #else - if (pflag && chmod(local_path, mode) == -1) + if (pflag && chmod(local_path, mode) == -1) #endif /* HAVE_FCHMOD */ - error("Couldn't set mode on \"%s\": %s", local_path, - strerror(errno)); - if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { - struct timeval tv[2]; - tv[0].tv_sec = a->atime; - tv[1].tv_sec = a->mtime; - tv[0].tv_usec = tv[1].tv_usec = 0; - if (utimes(local_path, tv) == -1) - error("Can't set times on \"%s\": %s", local_path, - strerror(errno)); + error("Couldn't set mode on \"%s\": %s", local_path, + strerror(errno)); + if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { + struct timeval tv[2]; + tv[0].tv_sec = a->atime; + tv[1].tv_sec = a->mtime; + tv[0].tv_usec = tv[1].tv_usec = 0; + if (utimes(local_path, tv) == -1) + error("Can't set times on \"%s\": %s", + local_path, strerror(errno)); + } } - -done: close(local_fd); buffer_free(&msg); xfree(handle); @@ -825,6 +891,8 @@ struct stat sb; Attrib a; int status; + u_int32_t startid; + u_int32_t ackid; if ((local_fd = open(local_path, O_RDONLY, 0)) == -1) { error("Couldn't open local file \"%s\" for reading: %s", @@ -866,6 +934,8 @@ return(-1); } + startid = ackid = id + 1; + /* Read from local and write to remote */ offset = 0; for(;;) { @@ -883,29 +953,34 @@ if (len == -1) fatal("Couldn't read from \"%s\": %s", local_path, strerror(errno)); - if (len == 0) - break; - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_WRITE); - buffer_put_int(&msg, ++id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_string(&msg, data, len); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", - id, (u_int64_t)offset, len); + if (len != 0) { + buffer_clear(&msg); + buffer_put_char(&msg, SSH2_FXP_WRITE); + buffer_put_int(&msg, ++id); + buffer_put_string(&msg, handle, handle_len); + buffer_put_int64(&msg, offset); + buffer_put_string(&msg, data, len); + send_msg(fd_out, &msg); + debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", + id, (u_int64_t)offset, len); + } else if ( id < ackid ) + break; - status = get_status(fd_in, id); - if (status != SSH2_FX_OK) { - error("Couldn't write to remote file \"%s\": %s", - remote_path, fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - close(local_fd); - goto done; + if (id == startid || len == 0 || + id - ackid >= OVERLAPPING_REQUESTS - 1) { + status = get_status(fd_in, ackid); + if (status != SSH2_FX_OK) { + error("Couldn't write to remote file \"%s\": %s", + remote_path, fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + close(local_fd); + goto done; + } + debug3("In write loop, got %d offset %llu", len, + (u_int64_t)offset); + ++ackid; } - debug3("In write loop, got %d offset %llu", len, - (u_int64_t)offset); offset += len; } diff -ru openssh-3.0.2p1.orig/sshconnect.c openssh-3.0.2p1.sftp/sshconnect.c --- openssh-3.0.2p1.orig/sshconnect.c Wed Oct 10 07:07:45 2001 +++ openssh-3.0.2p1.sftp/sshconnect.c Sun Jan 6 22:20:56 2002 @@ -370,6 +370,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock, SOL_SOCKET, SO_LINGER, (void *)&linger, sizeof(linger)); + setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && diff -ru openssh-3.0.2p1.orig/sshd.c openssh-3.0.2p1.sftp/sshd.c --- openssh-3.0.2p1.orig/sshd.c Mon Nov 12 01:07:12 2001 +++ openssh-3.0.2p1.sftp/sshd.c Sun Jan 6 22:20:56 2002 @@ -1118,6 +1118,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock_in, SOL_SOCKET, SO_LINGER, (void *) &linger, sizeof(linger)); + setsockopt(sock_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && From mperham at perham.net Mon Jan 7 11:01:49 2002 From: mperham at perham.net (Mike Perham) Date: Sun, 6 Jan 2002 19:01:49 -0500 (EST) Subject: sftp/scp performance testing In-Reply-To: Message-ID: I applied the NODELAY patch, compiled and ran make install. It had no affect whatsoever to the localhost performance - still 5.5MB/min. I added a printf to sshd.c to verify that I was running a patched server. On connect from the sftp client, it printed the message out so I know it was the correct binary. I assume the patch should improve single file transfer performance or is it intended for multiple simultaneous file transfers? Is there a way to programmatically make sshd exit via a kill signal? I'd like to run gprof on it but I need to be able to shut it down without Ctrl-C (needs to call exit()). mike From tori at ringstrom.mine.nu Mon Jan 7 16:51:12 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Mon, 7 Jan 2002 06:51:12 +0100 (CET) Subject: sftp/scp performance testing In-Reply-To: Message-ID: On Sun, 6 Jan 2002, Mike Perham wrote: > I applied the NODELAY patch, compiled and ran make install. It had no > affect whatsoever to the localhost performance - still 5.5MB/min. I added > a printf to sshd.c to verify that I was running a patched server. On > connect from the sftp client, it printed the message out so I know it was > the correct binary. Weird. You need to run the patched sshd, ssh, and sftp programs. Running on localhost, your CPU utilization should be 100%. You can verify this using vmstat or top. > I assume the patch should improve single file transfer performance or is > it intended for multiple simultaneous file transfers? It should improve single file transfer performance. > Is there a way to programmatically make sshd exit via a kill signal? I'd > like to run gprof on it but I need to be able to shut it down without > Ctrl-C (needs to call exit()). I do not know. /Tobias From dan at doxpara.com Mon Jan 7 17:01:21 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 6 Jan 2002 22:01:21 -0800 Subject: sftp/scp performance testing References: Message-ID: <003e01c19740$bb51dcd0$1701000a@effugas> > Weird. You need to run the patched sshd, ssh, and sftp programs. > Running on localhost, your CPU utilization should be 100%. You can verify > this using vmstat or top. A small note -- My method for testing OpenSSH performance has been something along the lines of: cat /dev/zero | ssh user at host "cat > /dev/null" and then monitoring network traffic using another tool. Something like: cat /dev/zero | cpipe | ssh user at host "cat > /dev/null" would also work. This method is useful because the zeronum generator is faster than any randomizer, and it completely filters out disk I/O. Markus, a few words on OpenSSH profiling might be helpful? :-) --Dan From vinschen at redhat.com Mon Jan 7 21:37:14 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 7 Jan 2002 11:37:14 +0100 Subject: [PATCH]: Fix environment variable size restriction in Cygwin version In-Reply-To: <20011229111240.A22640@cygbert.vinschen.de> References: <20011218202526.H21898@cygbert.vinschen.de> <20011229111240.A22640@cygbert.vinschen.de> Message-ID: <20020107113714.F1242@cygbert.vinschen.de> Hi, just a question. Is that patch now going to be included? Thanks, Corinna > > Index: session.c > > =================================================================== > > RCS file: /var/cvs/openssh/session.c,v > > retrieving revision 1.162 > > diff -u -r1.162 session.c > > --- session.c 2001/12/21 03:58:36 1.162 > > +++ session.c 2001/12/29 02:59:16 > > @@ -885,62 +885,28 @@ > > fclose(f); > > } > > > > -#ifdef USE_PAM > > -/* > > - * Sets any environment variables which have been specified by PAM > > - */ > > -void do_pam_environment(char ***env, u_int *envsize) > > +void copy_environment(char **source, char ***env, u_int *envsize) > > { > > - char *equals, var_name[512], var_val[512]; > > - char **pam_env; > > + char *var_name, *var_val; > > int i; > > > > - if ((pam_env = fetch_pam_environment()) == NULL) > > + if (source == NULL) > > return; > > > > - for(i = 0; pam_env[i] != NULL; i++) { > > - if ((equals = strstr(pam_env[i], "=")) == NULL) > > + for(i = 0; source[i] != NULL; i++) { > > + var_name = xstrdup(source[i]); > > + if ((var_val = strstr(var_name, "=")) == NULL) { > > + xfree(var_name); > > continue; > > - > > - if (strlen(pam_env[i]) < (sizeof(var_name) - 1)) { > > - memset(var_name, '\0', sizeof(var_name)); > > - memset(var_val, '\0', sizeof(var_val)); > > - > > - strncpy(var_name, pam_env[i], equals - pam_env[i]); > > - strcpy(var_val, equals + 1); > > - > > - debug3("PAM environment: %s=%s", var_name, var_val); > > - > > - child_set_env(env, envsize, var_name, var_val); > > } > > - } > > -} > > -#endif /* USE_PAM */ > > - > > -#ifdef HAVE_CYGWIN > > -void copy_environment(char ***env, u_int *envsize) > > -{ > > - char *equals, var_name[512], var_val[512]; > > - int i; > > - > > - for(i = 0; environ[i] != NULL; i++) { > > - if ((equals = strstr(environ[i], "=")) == NULL) > > - continue; > > + *var_val++ = '\0'; > > > > - if (strlen(environ[i]) < (sizeof(var_name) - 1)) { > > - memset(var_name, '\0', sizeof(var_name)); > > - memset(var_val, '\0', sizeof(var_val)); > > - > > - strncpy(var_name, environ[i], equals - environ[i]); > > - strcpy(var_val, equals + 1); > > - > > - debug3("Copy environment: %s=%s", var_name, var_val); > > - > > - child_set_env(env, envsize, var_name, var_val); > > - } > > + debug3("Copy environment: %s=%s", var_name, var_val); > > + child_set_env(env, envsize, var_name, var_val); > > + > > + xfree(var_name); > > } > > } > > -#endif > > > > #if defined(HAVE_GETUSERATTR) > > /* > > @@ -1215,7 +1181,7 @@ > > * The Windows environment contains some setting which are > > * important for a running system. They must not be dropped. > > */ > > - copy_environment(&env, &envsize); > > + copy_environment(environ, &env, &envsize); > > #endif > > > > if (!options.use_login) { > > @@ -1299,7 +1265,7 @@ > > #endif > > #ifdef USE_PAM > > /* Pull in any environment variables that may have been set by PAM. */ > > - do_pam_environment(&env, &envsize); > > + copy_environment(fetch_pam_environment(), &env, &envsize); > > #endif /* USE_PAM */ > > > > if (auth_get_socket_name() != NULL) -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From dwlewis at dnai.com Tue Jan 8 03:03:03 2002 From: dwlewis at dnai.com (David W. Lewis) Date: Mon, 07 Jan 2002 18:03:03 +0200 Subject: Non-root hostname auth problem Message-ID: <4.2.2.20020107174400.0185b278(null)> All: I have a problem connecting Openssh 3.0.2p1 on Solaris 8 using hostname authentication for non-root users. When I connect to the sshd from a second machine as root it works fine using HostbasedAuthentication, but it always fails with non-root users. I suspect that I am having a permissions problem somewhere, but I'll be damned if I can figure out where. Any and all help appreciated. -David Relevant file snippets below: **************** Error message generated from the server-side command /usr/local/sbin/sshd -f /usr/local/etc/sshd_config -d -d -d debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user ais service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for ais debug1: Starting up PAM with username "ais" debug3: Trying to reverse map address 192.168.2.226. debug1: PAM setting rhost to "ais1" debug2: input_userauth_request: try method none Failed none for ais from 192.168.2.226 port 34813 ssh2 Connection closed by 192.168.2.226 debug1: Calling cleanup 0x22fcc(0x0) debug1: Calling cleanup 0x3c848(0x0) ********************* Error message generated from the client-side command (as the target user) ssh -F /usr/local/etc/ssh_config -p 1024 -v -v -v NFS debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: keyboard-interactive,hostbased debug3: start over, passed a different list keyboard-interactive,hostbased debug3: preferred hostbased,password debug3: authmethod_lookup hostbased debug3: remaining preferred: password debug3: authmethod_is_enabled hostbased debug1: next auth method to try is hostbased debug1: userauth_hostbased: no more client hostkeys debug2: we did not send a packet, disable method debug1: no more auth methods to try Permission denied (keyboard-interactive,hostbased). ****************** ****sshd_config on server**** Port 1024 # for testing without annoying the users #Port 22 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 HostKey /usr/local/etc/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh_host_rsa_key HostKey /usr/local/etc/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging # Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes no RSAAuthentication no PubkeyAuthentication no AuthorizedKeysFile %h/.ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts no # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no ****ssh_config on client**** PreferredAuthentications hostbased,password RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication no HostbasedAuthentication yes PasswordAuthentication yes From mandar at webchat.chatsystems.com Tue Jan 8 05:21:42 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Mon, 7 Jan 2002 12:21:42 -0600 (CST) Subject: sftp/scp performance testing In-Reply-To: <003e01c19740$bb51dcd0$1701000a@effugas> Message-ID: For curiosity's sake, how does sftp/scp performance compare when the underlying protocol is changed i.e rsa1 vs rsa2 vs dsa keys for encryption? - Mandar On Sun, 6 Jan 2002, Dan Kaminsky wrote: > Date: Sun, 6 Jan 2002 22:01:21 -0800 > From: Dan Kaminsky > To: Tobias Ringstrom , mike at perham.net > Cc: openssh-unix-dev at shitei.mindrot.org > Subject: Re: sftp/scp performance testing > > > Weird. You need to run the patched sshd, ssh, and sftp programs. > > Running on localhost, your CPU utilization should be 100%. You can verify > > this using vmstat or top. > > A small note -- > > My method for testing OpenSSH performance has been something along the > lines of: > > cat /dev/zero | ssh user at host "cat > /dev/null" > > and then monitoring network traffic using another tool. Something like: > > cat /dev/zero | cpipe | ssh user at host "cat > /dev/null" > > would also work. This method is useful because the zeronum generator is > faster than any randomizer, and it completely filters out disk I/O. > > Markus, a few words on OpenSSH profiling might be helpful? :-) > > --Dan > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bbense at networking.stanford.edu Tue Jan 8 06:39:31 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Mon, 7 Jan 2002 11:39:31 -0800 (PST) Subject: 3.0.2 AFS login problem, Solaris 2.5.1 In-Reply-To: <4.3.2.7.2.20020104142702.00b09850@mail2a.jpl.nasa.gov> Message-ID: On Fri, 4 Jan 2002, Peter Scott wrote: > > > > > > Why doesn't 3.0.2 call ka_UserAuthenticateGeneral? > > > >- Because it's insecure? > > Thanks for this information. I've read the thread and URL you > provided. If you don't mind what may be a stupid question - does this > imply that the stock AFS login - or at least the Transarc one we are using > - is insecure? Because all it has to go on is a username and password, and > we already know that the kaservers don't have a srvtab for the client > machine. If it isn't insecure, what makes it secure? I looked in OpenAFS > source and if I'm looking at the right place, the login does call > ka_UserAuthenticateGeneral... and without a srvtab for the client how can > that be good enough? - I would need to read the code to be sure of exactly what is going on. I'll poke around in OpenAFS and see if I can make some sense of what ka_UserAuthenticateGeneral actually does. - From what I can see it just gets a tgt and does nothing with it. IMHO, this is not "good enough". I don't have time at the moment to read the entire login code, but if ka_UserAuthenticateGeneral is all it's using, then there is a security risk in using this code. - Booker C. Bense From dan at doxpara.com Tue Jan 8 07:03:55 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 7 Jan 2002 12:03:55 -0800 Subject: sftp/scp performance testing References: Message-ID: <003a01c197b6$6f79f470$1701000a@effugas> > For curiosity's sake, how does sftp/scp performance compare when the > underlying protocol is changed i.e rsa1 vs rsa2 vs dsa keys for > encryption? RSA1, RSA2, and DSA only affect session initialization -- they're basically just the key exchange method used for the client and the server to sync up to some random 3DES/AES/RC4 session key, which (someone verify this for me) may or may not also be used for the SHA1/MD5 message authenticating layer as well in the case of SSH2. What should make a difference is whether the SSH1 or SSH2 protocols are used -- SSH1 implicitly authenticates packets, for what cannot be decrypted cannot be modified, while SSH2 uses a separate layer to guarantee that packets are not modified in transit. --Dan From chua at ayrnetworks.com Tue Jan 8 07:18:51 2002 From: chua at ayrnetworks.com (Bryan Chua) Date: Mon, 07 Jan 2002 12:18:51 -0800 Subject: keyboard-interactive Message-ID: <3C3A02AB.2010701@ayrnetworks.com> Is there a way for a PAM module to force a client (and the server) to use kbd-interactive? As far as I can tell, when in the INITIAL_LOGIN phase, all communication with the client returns a PAM_CONV_ERR. I am trying to write a PAM module that will prompt a user for a second username and a second password in order for the module to succeed so that proper authentication relies on the ability to authenticate against n machines, where n < 1. I looked at the pam_authsrv module, but that appears (I did not compile ad run) to use the supplied username, index against a mapfile, and then use the password supplied by the user to authenticate. So it may not be using kbd-interactive at all, it may just be password. Am I missing something? -- bryan From markus at openbsd.org Tue Jan 8 10:07:41 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 8 Jan 2002 00:07:41 +0100 Subject: Non-root hostname auth problem In-Reply-To: <4.2.2.20020107174400.0185b278(null)>; from dwlewis@dnai.com on Mon, Jan 07, 2002 at 06:03:03PM +0200 References: <4.2.2.20020107174400.0185b278(null)> Message-ID: <20020108000740.A4893@folly> are you sure ssh is setuid root? On Mon, Jan 07, 2002 at 06:03:03PM +0200, David W. Lewis wrote: > All: > > I have a problem connecting Openssh 3.0.2p1 on Solaris 8 using hostname > authentication for non-root users. When I connect to the sshd from a > second machine as root it works fine using HostbasedAuthentication, but it > always fails with non-root users. > > I suspect that I am having a permissions problem somewhere, but I'll be > damned if I can figure out where. > > Any and all help appreciated. > > -David > > Relevant file snippets below: > > **************** > Error message generated from the server-side command > > /usr/local/sbin/sshd -f /usr/local/etc/sshd_config -d -d -d > > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user ais service ssh-connection method none > debug1: attempt 0 failures 0 > debug2: input_userauth_request: setting up authctxt for ais > debug1: Starting up PAM with username "ais" > debug3: Trying to reverse map address 192.168.2.226. > debug1: PAM setting rhost to "ais1" > debug2: input_userauth_request: try method none > Failed none for ais from 192.168.2.226 port 34813 ssh2 > Connection closed by 192.168.2.226 > debug1: Calling cleanup 0x22fcc(0x0) > debug1: Calling cleanup 0x3c848(0x0) > > ********************* > Error message generated from the client-side command (as the target user) > > ssh -F /usr/local/etc/ssh_config -p 1024 -v -v -v NFS > > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: keyboard-interactive,hostbased > debug3: start over, passed a different list keyboard-interactive,hostbased > debug3: preferred hostbased,password > debug3: authmethod_lookup hostbased > debug3: remaining preferred: password > debug3: authmethod_is_enabled hostbased > debug1: next auth method to try is hostbased > debug1: userauth_hostbased: no more client hostkeys > debug2: we did not send a packet, disable method > debug1: no more auth methods to try > Permission denied (keyboard-interactive,hostbased). > ****************** > ****sshd_config on server**** > > Port 1024 # for testing without annoying the users > #Port 22 > Protocol 2 > #ListenAddress 0.0.0.0 > #ListenAddress :: > # HostKey for protocol version 1 > HostKey /usr/local/etc/ssh_host_key > # HostKeys for protocol version 2 > HostKey /usr/local/etc/ssh_host_rsa_key > HostKey /usr/local/etc/ssh_host_dsa_key > # Lifetime and size of ephemeral version 1 server key > KeyRegenerationInterval 3600 > ServerKeyBits 768 > # Logging > SyslogFacility AUTH > LogLevel INFO > #obsoletes QuietMode and FascistLogging > # Authentication: > LoginGraceTime 600 > PermitRootLogin yes > StrictModes no > RSAAuthentication no > PubkeyAuthentication no > AuthorizedKeysFile %h/.ssh/authorized_keys > # rhosts authentication should not be used > RhostsAuthentication no > # Don't read the user's ~/.rhosts and ~/.shosts files > IgnoreRhosts no > # For this to work you will also need host keys in /etc/ssh_known_hosts > RhostsRSAAuthentication no > # similar for protocol version 2 > HostbasedAuthentication yes > # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication > IgnoreUserKnownHosts no > # To disable tunneled clear text passwords, change to no here! > PasswordAuthentication yes > PermitEmptyPasswords no > > ****ssh_config on client**** > > PreferredAuthentications hostbased,password > RhostsAuthentication no > RhostsRSAAuthentication no > RSAAuthentication no > HostbasedAuthentication yes > PasswordAuthentication yes > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Tue Jan 8 10:10:18 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 8 Jan 2002 00:10:18 +0100 Subject: sftp/scp performance testing In-Reply-To: ; from mandar@webchat.chatsystems.com on Mon, Jan 07, 2002 at 12:21:42PM -0600 References: <003e01c19740$bb51dcd0$1701000a@effugas> Message-ID: <20020108001018.B4893@folly> On Mon, Jan 07, 2002 at 12:21:42PM -0600, mandar at webchat.chatsystems.com wrote: > For curiosity's sake, how does sftp/scp performance compare when the > underlying protocol is changed i.e rsa1 vs rsa2 vs dsa keys for > encryption? not related. From markus at openbsd.org Tue Jan 8 10:11:51 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 8 Jan 2002 00:11:51 +0100 Subject: sftp/scp performance testing In-Reply-To: <003a01c197b6$6f79f470$1701000a@effugas>; from dan@doxpara.com on Mon, Jan 07, 2002 at 12:03:55PM -0800 References: <003a01c197b6$6f79f470$1701000a@effugas> Message-ID: <20020108001151.C4893@folly> On Mon, Jan 07, 2002 at 12:03:55PM -0800, Dan Kaminsky wrote: > What should make a difference is whether the SSH1 or SSH2 protocols are > used -- SSH1 implicitly authenticates packets, that's not true. SSH1 does not really authenticate packets, it just uses CRC, while SSH2 uses a true MAC (e.g. hmac-md5 or hmac-sha1). > for what cannot be decrypted > cannot be modified, while SSH2 uses a separate layer to guarantee that > packets are not modified in transit. -m From markus at openbsd.org Tue Jan 8 10:12:49 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 8 Jan 2002 00:12:49 +0100 Subject: keyboard-interactive In-Reply-To: <3C3A02AB.2010701@ayrnetworks.com>; from chua@ayrnetworks.com on Mon, Jan 07, 2002 at 12:18:51PM -0800 References: <3C3A02AB.2010701@ayrnetworks.com> Message-ID: <20020108001249.D4893@folly> if you want to force a authentication method on the server you have to disable all other methods (or make them fail). On Mon, Jan 07, 2002 at 12:18:51PM -0800, Bryan Chua wrote: > Is there a way for a PAM module to force a client (and the server) to > use kbd-interactive? As far as I can tell, when in the INITIAL_LOGIN > phase, all communication with the client returns a PAM_CONV_ERR. I am > trying to write a PAM module that will prompt a user for a second > username and a second password in order for the module to succeed so > that proper authentication relies on the ability to authenticate against > n machines, where n < 1. > > I looked at the pam_authsrv module, but that appears (I did not compile > ad run) to use the supplied username, index against a mapfile, and then > use the password supplied by the user to authenticate. So it may not be > using kbd-interactive at all, it may just be password. > > Am I missing something? > > -- bryan > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From mandar at webchat.chatsystems.com Tue Jan 8 10:28:49 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Mon, 7 Jan 2002 17:28:49 -0600 (CST) Subject: sftp/scp performance testing In-Reply-To: <20020108001151.C4893@folly> Message-ID: I've heard some users say they get much better scp/sftp performance over SSH1, that's why I was curious..thanks - Mandar On Tue, 8 Jan 2002, Markus Friedl wrote: > Date: Tue, 8 Jan 2002 00:11:51 +0100 > From: Markus Friedl > To: Dan Kaminsky > Cc: mandar at webchat.chatsystems.com, openssh-unix-dev at shitei.mindrot.org > Subject: Re: sftp/scp performance testing > > On Mon, Jan 07, 2002 at 12:03:55PM -0800, Dan Kaminsky wrote: > > What should make a difference is whether the SSH1 or SSH2 protocols are > > used -- SSH1 implicitly authenticates packets, > > that's not true. SSH1 does not really authenticate packets, > it just uses CRC, while SSH2 uses a true MAC (e.g. hmac-md5 > or hmac-sha1). > > > for what cannot be decrypted > > cannot be modified, while SSH2 uses a separate layer to guarantee that > > packets are not modified in transit. > > -m > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From roth+openssh at feep.net Tue Jan 8 10:48:07 2002 From: roth+openssh at feep.net (Mark D. Roth) Date: Mon, 7 Jan 2002 17:48:07 -0600 Subject: keyboard-interactive In-Reply-To: <3C3A02AB.2010701@ayrnetworks.com>; from chua@ayrnetworks.com on Mon, Jan 07, 2002 at 12:18:51PM -0800 References: <3C3A02AB.2010701@ayrnetworks.com> Message-ID: <20020107174807.A12162@yorktown.isdn.uiuc.edu> On Mon Jan 07 12:18 2002 -0800, Bryan Chua wrote: > Is there a way for a PAM module to force a client (and the server) to > use kbd-interactive? As far as I can tell, when in the INITIAL_LOGIN The PAM module itself can't force a particular SSH auth method, but you can set this up in the sshd_config file by enabling ChallengeResponseAuthentication and disabling all the other auth methods. To get ChallengeResponseAuthentication to use PAM, you also need to enable PAMAuthenticationViaKbdInt. > I looked at the pam_authsrv module, but that appears (I did not compile > ad run) to use the supplied username, index against a mapfile, and then > use the password supplied by the user to authenticate. So it may not be > using kbd-interactive at all, it may just be password. I use pam_authsrv with kbd-interactive to authenticate via an SNK, and it works perfectly. I suggest you try the latest version of pam_authsrv: http://www-dev.cso.uiuc.edu/authsrv/ HTH. -- Mark D. Roth http://www.feep.net/~roth/ From djm at mindrot.org Tue Jan 8 15:29:36 2002 From: djm at mindrot.org (Damien Miller) Date: 08 Jan 2002 15:29:36 +1100 Subject: keyboard-interactive In-Reply-To: <20020107174807.A12162@yorktown.isdn.uiuc.edu> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> Message-ID: <1010464177.24458.6.camel@xenon> On Tue, 2002-01-08 at 10:48, Mark D. Roth wrote: > The PAM module itself can't force a particular SSH auth method, but > you can set this up in the sshd_config file by enabling > ChallengeResponseAuthentication and disabling all the other auth > methods. To get ChallengeResponseAuthentication to use PAM, you also > need to enable PAMAuthenticationViaKbdInt. I have been wanting to rewrite the PAM kbd-interactive support for a while now, but have hit a brick wall with the PAM api. The PAM API wants to ask all the questions and gather all the responses in a single conversation function. This doesn't work well with the SSH protocol, where userauth messages can arrive in any order. The current kbd-int PAM support assumes that it can get a response immediately and somewhat abuses the dispatch API to get at it. It probably isn't robust in the face of clients who send requests in a funny order. If any PAM experts can offer a solution to this, it would be greatly appreciated. What I would really like to see in PAM is the ability call to a function to collect the auth queries and another to send the responses at a time of my choosing. -d From ossh at gus-the-cat.org Tue Jan 8 15:45:07 2002 From: ossh at gus-the-cat.org (Gus) Date: Mon, 7 Jan 2002 20:45:07 -0800 Subject: Solaris 8 Kerberos PAM and OpenSSH Message-ID: <20020107204506.A15318@durden.besh.com> Hello, I am experiencing an error when using the Kerberos V PAM module provided with Solaris 8 with OpenSSH versions 2.9.9p2 and 3.0.2p1. The connection is established, the prompt appears, the motd of the remote system is sometimes displayed, and then the connection closes. This looks to be an error with the PAM module and not OpenSSH, but the problem only affects OpenSSH - all the other services are standard Sun. The same pam.conf lines are used for every service. The PAM debug error is as follows: Dec 27 15:12:10 hostname sshd[1239]: [ID 390226 auth.error] PAM-KRB5:Could not obtain principal name Like I said, I think this is a Sun issue, but I'd like to eliminate any other possibilities before trying to get any acknowledgement out of Sun. Thanks, -- Gus "Don't feel responsible--it's not you, it's me. My [ busy career / expensive drug habit / intense racquetball schedule / fascination with on-line pornography ] prevents me from committing to a serious relationship." From hgertges at provinzial-online.de Tue Jan 8 22:42:37 2002 From: hgertges at provinzial-online.de (hgertges at provinzial-online.de) Date: Tue, 8 Jan 2002 12:42:37 +0100 Subject: Compile SSH static on Solaris 2.7 (64Bit) Message-ID: I like to compile ssh-3.0.2 on Solaris 2.7 with 64 Bit support in static mode. But I get a fatal error. The compilation with shared libraries is working very fine. Does anyone has ideas to compile OpenSSH cleanly in static mode? gcc -static -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/include -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM =\"/usr/ssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT =\"/usr/ssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER =\"/usr/ssh/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -DHAVE_CONFIG_H -c uidswap.c uidswap.c: In function `temporarily_use_uid': uidswap.c:56: warning: int format, uid_t arg (arg 2) uidswap.c:56: warning: int format, gid_t arg (arg 3) uidswap.c:56: warning: int format, uid_t arg (arg 4) ...... gcc -static -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/include -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM =\"/usr/ssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT =\"/usr/ssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER =\"/usr/ssh/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -DHAVE_CONFIG_H -c sshconnect.c sshconnect.c: In function `ssh_login': sshconnect.c:868: warning: subscript has type `char' ..... gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lcrypto Undefined first referenced symbol in file gethostbyname openbsd-compat//libopenbsd-compat.a(fake-getaddrinfo.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) gethostbyaddr openbsd-compat//libopenbsd-compat.a(fake-getnameinfo.o) (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) ld: fatal: Symbol referencing errors. No output written to ssh collect2: ld returned 1 exit status From fcusack at fcusack.com Tue Jan 8 23:46:51 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 8 Jan 2002 04:46:51 -0800 Subject: Compile SSH static on Solaris 2.7 (64Bit) In-Reply-To: ; from hgertges@provinzial-online.de on Tue, Jan 08, 2002 at 12:42:37PM +0100 References: Message-ID: <20020108044651.A25364@google.com> On Tue, Jan 08, 2002 at 12:42:37PM +0100, hgertges at provinzial-online.de wrote: > I like to compile ssh-3.0.2 on Solaris 2.7 with 64 Bit support in static > mode. But I get a fatal error. The compilation with shared libraries is > working very fine. Does anyone has ideas to compile OpenSSH cleanly in > static mode? Not possible. , which is result number 7 for the Google search "static link solaris libnsl". /fc From fcusack at fcusack.com Wed Jan 9 00:19:13 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 8 Jan 2002 05:19:13 -0800 Subject: keyboard-interactive In-Reply-To: <1010464177.24458.6.camel@xenon>; from djm@shitei.mindrot.org on Tue, Jan 08, 2002 at 03:29:36PM +1100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> Message-ID: <20020108051913.A25407@google.com> On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote: > The PAM API wants to ask all the questions and gather all the responses > in a single conversation function. This doesn't work well with the SSH > protocol, where userauth messages can arrive in any order. > > The current kbd-int PAM support assumes that it can get a response > immediately and somewhat abuses the dispatch API to get at it. It > probably isn't robust in the face of clients who send requests in a > funny order. Do you have any example of a client that actually does this? > If any PAM experts can offer a solution to this, it would be greatly > appreciated. > > What I would really like to see in PAM is the ability call to a function > to collect the auth queries and another to send the responses at a time > of my choosing. Eek. I don't believe that's possible (or at best, more difficult than it's worth). But I may not quite understand exactly what you want to do. The conversation (ie, pam_conv()) needs to complete (fill in all responses) before returning. So in order to do things "asynchronously", you'd pretty much need to stash "control data" in appdata_ptr (or use global data), and call out to other sshd code in the conversation function. You'd be running a mini-sshd within the conversation function. It seems unlikely to me this is really doable, however my knowledge of the code isn't that great. This might be more doable if sshd were multithreaded, but PAM isn't really compatible with threaded apps, so sshd would have to both be fork()/exec() and multithreaded. This is almost certainly not worth it. /fc From roth+openssh at feep.net Wed Jan 9 01:27:16 2002 From: roth+openssh at feep.net (Mark D. Roth) Date: Tue, 8 Jan 2002 08:27:16 -0600 Subject: keyboard-interactive In-Reply-To: <1010464177.24458.6.camel@xenon>; from djm@shitei.mindrot.org on Tue, Jan 08, 2002 at 03:29:36PM +1100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> Message-ID: <20020108082716.A13110@yorktown.isdn.uiuc.edu> On Tue Jan 08 15:29 2002 +1100, Damien Miller wrote: > I have been wanting to rewrite the PAM kbd-interactive support for a > while now, but have hit a brick wall with the PAM api. > > The PAM API wants to ask all the questions and gather all the responses > in a single conversation function. This doesn't work well with the SSH > protocol, where userauth messages can arrive in any order. > > The current kbd-int PAM support assumes that it can get a response > immediately and somewhat abuses the dispatch API to get at it. It > probably isn't robust in the face of clients who send requests in a > funny order. > > If any PAM experts can offer a solution to this, it would be greatly > appreciated. I'm sure you're much more well versed in the SSH protocol than I am, but from a glance through draft-ietf-secsh-userauth-13.txt, I don't understand the problem. The last paragraph of section 2.1 says: An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. Based on this, it seems to me that there's no problem with assuming that you can get back responses immediately from the PAM conversation function. The only catch is that if you receive another SSH_MSG_USERAUTH_REQUEST message, you need to abort the PAM transaction and begin processing the new request. I see two possible ways to do this: 1. Call setjmp() before calling pam_authenticate(). If you get a SSH_MSG_USERAUTH_REQUEST message in the conversation function, simply call longjmp() to pop back out of the authentication request. 2. If you get a SSH_MSG_USERAUTH_REQUEST message in the conversation function, set some state to indicate that the PAM authentication should be aborted and return PAM_CONV_ERR. Method (2) is obviously cleaner, but doesn't guaruntee immediate return from pam_authenticate(). This is because the module which called the conversation function doesn't necessarily have to fail if the conversation function failed. And even if the module does fail, if it's control flag isn't "required", subsequent modules may still be called. However, this shouldn't have any bad effects other than a short delay. > What I would really like to see in PAM is the ability call to a function > to collect the auth queries and another to send the responses at a time > of my choosing. There's no way to do this with PAM, and IMHO that's a good thing. When you have multiple PAM modules in the stack, you can't necessarily tell whether a subsequent module will be called until you know whether the first one succeeds. In fact, you could even write a single PAM module which asks multiple questions, where the next question is determined by the response to the previous question. None of this would be possible if all the questions had to be batched up at once, which is one of the reasons why the PAM API is designed the way it is. I hope this information is useful. -- Mark D. Roth http://www.feep.net/~roth/ From Nicolas.Williams at ubsw.com Wed Jan 9 02:33:07 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 8 Jan 2002 10:33:07 -0500 Subject: keyboard-interactive In-Reply-To: <1010464177.24458.6.camel@xenon>; from djm@mindrot.org on Tue, Jan 08, 2002 at 03:29:36PM +1100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> Message-ID: <20020108103305.A27398@sm2p1386swk.wdr.com> On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote: > On Tue, 2002-01-08 at 10:48, Mark D. Roth wrote: > > The PAM module itself can't force a particular SSH auth method, but > > you can set this up in the sshd_config file by enabling > > ChallengeResponseAuthentication and disabling all the other auth > > methods. To get ChallengeResponseAuthentication to use PAM, you also > > need to enable PAMAuthenticationViaKbdInt. > > I have been wanting to rewrite the PAM kbd-interactive support for a > while now, but have hit a brick wall with the PAM api. > > The PAM API wants to ask all the questions and gather all the responses > in a single conversation function. This doesn't work well with the SSH > protocol, where userauth messages can arrive in any order. > > The current kbd-int PAM support assumes that it can get a response > immediately and somewhat abuses the dispatch API to get at it. It > probably isn't robust in the face of clients who send requests in a > funny order. > > If any PAM experts can offer a solution to this, it would be greatly > appreciated. > > What I would really like to see in PAM is the ability call to a function > to collect the auth queries and another to send the responses at a time > of my choosing. PAM doesn't allow this at all, though Linux-PAM, at least, allows the conversation function to return, I think, PAM_CONV_AGAIN/PAM_INCOMPLETE, which modules can take as a cue to return the same to libpam which then marks the place in the PAM stack where this happened and returns the same error to the application, which can then restart the PAM call in question and which libpam will restart where it had stopped, rather than from the beginning. Part of the problem is that a module might have more questions to ask given the answers to previous questions. Any system like PAM, with pluggable modules, will be potentially too dynamic to be used the way you want ("ask all your questions now, I'll answer them later"). > -d > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From KENDALL_PAMELA_A at Lilly.com Wed Jan 9 02:35:34 2002 From: KENDALL_PAMELA_A at Lilly.com (KENDALL_PAMELA_A at Lilly.com) Date: Tue, 08 Jan 2002 10:35:34 -0500 Subject: Problems with commercial SSH and Open SSH Message-ID: Hi, My UNIX SSH server environment is running OpenSSH. My UNIX SSH client environment is running the commercial SSH. I am getting the following errors when trying to authenticate with my public key: warning: Authentication failed. Disconnected; authentication cancelled by user (Authentication cancelled by use. FATAL: ssh2 client failed to authenticate. (or you have too old ssh2 installed,) Help~ Pam Kendall US Demand IT Operations Eli Lilly and Company Phone: 317.651.1928 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020108/5d8641c9/attachment.html From tori at ringstrom.mine.nu Wed Jan 9 05:46:02 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 8 Jan 2002 19:46:02 +0100 (CET) Subject: sftp/scp performance testing In-Reply-To: <003e01c19740$bb51dcd0$1701000a@effugas> Message-ID: On Sun, 6 Jan 2002, Dan Kaminsky wrote: > A small note -- > > My method for testing OpenSSH performance has been something along the > lines of: > > cat /dev/zero | ssh user at host "cat > /dev/null" > > and then monitoring network traffic using another tool. Something like: > > cat /dev/zero | cpipe | ssh user at host "cat > /dev/null" > > would also work. This method is useful because the zeronum generator is > faster than any randomizer, and it completely filters out disk I/O. And just how would you test sftp using /dev/zero? :-) You can always write the file to /dev/null, of course, as in get big-file /dev/null put big-file /dev/null One way to benchmark sftp is to put the line (get big-file /dev/null) in a file (tmp.bat), and then run time sftp -b tmp.bat host Subtract the time it takes to run sftp -b /dev/null host and your result should be somewhat accurate. /Tobias From kevin at tgivan.com Wed Jan 9 05:51:27 2002 From: kevin at tgivan.com (Kevin Sindhu) Date: Tue, 8 Jan 2002 10:51:27 -0800 Subject: Compile SSH static on Solaris 2.7 (64Bit) In-Reply-To: References: Message-ID: <20020108105126.A11007@tgivan.com> Moin hgertges! hgertges at provinzial-online.de schrieb am Dienstag, den 08. Januar 2002: > I like to compile ssh-3.0.2 on Solaris 2.7 with 64 Bit support in > static mode. But I get a fatal error. The compilation with shared > libraries is working very fine. Does anyone has ideas to compile > OpenSSH cleanly in static mode? As pointed out, this is not possible. Not that easily anyway...there are many pro's and cons to this. Also see http://gcc.gnu.org/ml/gcc-help/2001-10/msg00303.html > gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o > readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib > -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lcrypto > Undefined first referenced > symbol in file > gethostbyname > openbsd-compat//libopenbsd-compat.a(fake-getaddrinfo.o) (symbol belongs to > implicit dependency /usr/lib/libnsl.so.1) > gethostbyaddr > openbsd-compat//libopenbsd-compat.a(fake-getnameinfo.o) (symbol belongs to > implicit dependency /usr/lib/libnsl.so.1) > ld: fatal: Symbol referencing errors. No output written to ssh > collect2: ld returned 1 exit status Add -lnsl -lsocket here. It might break down the road though... -- Kevin Sindhu Systems Engineer TGI Technologies Inc. 107 E 3rd Avenue Tel: (604) 872-6676 Ext 321 Vancouver V5T 1C7 Fax: (604) 872-6601 British Columbia, Canada From Peter.J.Scott at jpl.nasa.gov Wed Jan 9 06:52:54 2002 From: Peter.J.Scott at jpl.nasa.gov (Peter Scott) Date: Tue, 08 Jan 2002 11:52:54 -0800 Subject: Some X11 programs don't work on connection from SSH Secure Shell Message-ID: <4.3.2.7.2.20020108110742.00a88ce0@mail.webquarry.com> Well this is weird... when I connect via SSH Secure Shell PC client 3.0.0, the server hangs and the client sees a disconnect as soon as the user activates certain X programs. But not all of them! For instance, xeyes and xlogo are fine... but emacs and xterm are not. This is 3.0.2p1 on Solaris 2.5.1. When the client runs xterm the output of sshd -d -d -d is: debug1: X11 connection requested. debug2: fd 13 is O_NONBLOCK debug2: fd 13 is O_NONBLOCK debug1: channel 2: new [X11 connection from 137.78.37.65 port 43165] debug1: channel 2: open confirm rwindow 30000 rmax 2048 And then it says no more. But these programs work fine if I connect via ssh from a Linux box or fsecure (SSH1). If I scratch my head any more I'll get splinters in my fingers. Any suggestions? -- Peter Scott Peter.J.Scott at jpl.nasa.gov From chua at ayrnetworks.com Wed Jan 9 07:07:52 2002 From: chua at ayrnetworks.com (Bryan Chua) Date: Tue, 08 Jan 2002 12:07:52 -0800 Subject: keyboard-interactive References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108103305.A27398@sm2p1386swk.wdr.com> Message-ID: <3C3B5198.3020301@ayrnetworks.com> Nicolas Williams wrote: > On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote: > >>On Tue, 2002-01-08 at 10:48, Mark D. Roth wrote: >> >>>The PAM module itself can't force a particular SSH auth method, but >>>you can set this up in the sshd_config file by enabling >>>ChallengeResponseAuthentication and disabling all the other auth >>>methods. To get ChallengeResponseAuthentication to use PAM, you also >>>need to enable PAMAuthenticationViaKbdInt. >>> >>I have been wanting to rewrite the PAM kbd-interactive support for a >>while now, but have hit a brick wall with the PAM api. >> >>The PAM API wants to ask all the questions and gather all the responses >>in a single conversation function. This doesn't work well with the SSH >>protocol, where userauth messages can arrive in any order. >> >>The current kbd-int PAM support assumes that it can get a response >>immediately and somewhat abuses the dispatch API to get at it. It >>probably isn't robust in the face of clients who send requests in a >>funny order. >> >>If any PAM experts can offer a solution to this, it would be greatly >>appreciated. >> >>What I would really like to see in PAM is the ability call to a function >>to collect the auth queries and another to send the responses at a time >>of my choosing. >> According to what I am interpreting from kbdinteract-02, the protocol sequence is defined to be specifically in section 3 - Protocol Exchanges, to be USERAUTH_REQUEST -> INFO_REQUEST -> INFO_RESPONSE. At least within kbdinteract, there do not appear to be any issues with respect to asynchronous kdbinteract responses, so it should be safe for the conversation function to post a single query to the client and await a single response. As long as the conversation function is sufficiently generic, it should be able to support any number of such query/response exchanges. Of course, it would be wise to set up the conversation timeout, otherwise the system would thus be exposed to a distributed DoS from several clients with open auth states in the middle of a blocking function.... Perhaps the question to be considering is not how to map the SSH messages into a PAM structure, but how to map a PAM structure into SSH messages. After all, the whole point of building a robust PAM converstaion function is to make the system easier to use tor module developers, no? I believe the exercise is to loop through the PAM msg array and build a SSH_MSG_USERAUTH_INFO_REQUEST packet, send it, and then block waiting for the response, after which the responses may be filled in to the reply array. Where I originally got stuck was in looking at the difference between INITIAL_LOGIN and *else*, where stdio or a pipe-equivalent is already established, so a packet must be constructed. Or am I completely misunderstanding? -- bryan From CLAD at chevrontexaco.com Wed Jan 9 07:35:41 2002 From: CLAD at chevrontexaco.com (Ladner, Eric (CLAD)) Date: Tue, 8 Jan 2002 14:35:41 -0600 Subject: new feature w/ patch Message-ID: <8F88657F29DFD11189ED0008C728C6B008A5A12F@nor935-msx6.nor.chevron.com> Won't colon separated numbers cause problems for people as they move towards IPv6? -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Sunday, January 06, 2002 3:50 AM To: Scott Bolte Cc: openssh-unix-dev at mindrot.org Subject: Re: new feature w/ patch On Sat, Jan 05, 2002 at 04:09:17PM -0600, Scott Bolte wrote: > I've attached a patch to OpenSSH 3.0.2p1 that will allow the client > side of local port forwarding to be bound to a single address. For > my purposes, binding to 127.0.0.1 or (via GatewayPorts) all addresses > would not work. I overloaded the "-b local_host" option so that > it's address will be used when "-L port:remote_host:remote_port" > is also specified. we are going to change -L, e.g. -L listenaddr:listenport:targethost:targetport -m _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From damien.miller at my-fortress.com Wed Jan 9 09:37:33 2002 From: damien.miller at my-fortress.com (Damien Miller) Date: 09 Jan 2002 09:37:33 +1100 Subject: keyboard-interactive Message-ID: <1010529453.29368.4.camel@xenon> On Wed, 2002-01-09 at 02:33, Nicolas Williams wrote: > Part of the problem is that a module might have more questions to ask > given the answers to previous questions. Any system like PAM, with > pluggable modules, will be potentially too dynamic to be used the way > you want ("ask all your questions now, I'll answer them later"). I can't see why this is the case. An API like: while (!pam_conversation_done(pamh) { pam_get_prompts(&prompts); /* do something with them */ pam_set_responses(&responses) } takes care of the potential flexability and doesn't dictate structure to the application developer. -d From Nicolas.Williams at ubsw.com Wed Jan 9 09:32:31 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 8 Jan 2002 17:32:31 -0500 Subject: keyboard-interactive In-Reply-To: <3C3B5198.3020301@ayrnetworks.com>; from chua@ayrnetworks.com on Tue, Jan 08, 2002 at 12:07:52PM -0800 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108103305.A27398@sm2p1386swk.wdr.com> <3C3B5198.3020301@ayrnetworks.com> Message-ID: <20020108173229.Y27171@sm2p1386swk.wdr.com> On Tue, Jan 08, 2002 at 12:07:52PM -0800, Bryan Chua wrote: > > On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote: > >>What I would really like to see in PAM is the ability call to a function > >>to collect the auth queries and another to send the responses at a time > >>of my choosing. > > According to what I am interpreting from kbdinteract-02, the protocol > sequence is defined to be specifically in section 3 - Protocol > Exchanges, to be USERAUTH_REQUEST -> INFO_REQUEST -> INFO_RESPONSE. At > least within kbdinteract, there do not appear to be any issues with > respect to asynchronous kdbinteract responses, so it should be safe for > the conversation function to post a single query to the client and await > a single response. As long as the conversation function is sufficiently > generic, it should be able to support any number of such query/response > exchanges. Of course, it would be wise to set up the conversation > timeout, otherwise the system would thus be exposed to a distributed DoS > from several clients with open auth states in the middle of a blocking > function.... Also, if a module posts multiple questions to the conversation function then sshd should (but doesn't have to) post those multiple questions in one info request. Looks like kbdinteract was written with PAM in mind by folks who have lots of experience with PAM (Frank Cusack, Martin Forssen) so that the INFO_REQUEST/INFO_RESPONSE messages are defined to look much like a straight encoding of PAM conversation messages/responses. > Perhaps the question to be considering is not how to map the SSH > messages into a PAM structure, but how to map a PAM structure into SSH > messages. After all, the whole point of building a robust PAM There can only be one userauth request going at any given time, yes? If so, then you map a single SSH connection to a single PAM handle and back, and, since OpenSSH is single-threaded, with one connection per-sshd-process, you can just have one PAM handle global to sshd (though a single global PAM handle is not not what *I* would use, but then, I'm not an OpenSSH developer). > converstaion function is to make the system easier to use tor module > developers, no? I believe the exercise is to loop through the PAM msg > array and build a SSH_MSG_USERAUTH_INFO_REQUEST packet, send it, and > then block waiting for the response, after which the responses may be > filled in to the reply array. Bingo. > Where I originally got stuck was in looking at the difference between > INITIAL_LOGIN and *else*, where stdio or a pipe-equivalent is already > established, so a packet must be constructed. Huh? I don't get this. > Or am I completely misunderstanding? No, you understood the intent of the kbdinteract draft just fine, methinks. Ask the authors, if anything. I know that Frank understands PAM quite well, so he certainly can speak to any issues you may have. > -- bryan Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From bob-openssh at technogeeks.com Wed Jan 9 12:41:57 2002 From: bob-openssh at technogeeks.com (bob-openssh at technogeeks.com) Date: Tue, 8 Jan 2002 17:41:57 -0800 (PST) Subject: Require Multiple keys per host Message-ID: As of version 3.0.2p1 and perhaps earlier localhost forwarded connections are checked in known_hosts. The difficulty is that if you have multiple forwards, only one of them will exist as a valid host key for localhost. All the others will be treated as a "Changed" key prompting reduced functionality including disallowing agent-forwarding. Depending on StrictHostKeyChecking being set, the connections might not be allowed at all. I suggest that the known host file have a host:port type scheme so a machine running multiple sshd's will respond correctly as well as multiple localforwards. I note that this problem probably did not present itself since KnownHostKey checkings did not seem to be active for localhost in older versions of openssh. Bob From raj at cup.hp.com Wed Jan 9 13:34:20 2002 From: raj at cup.hp.com (Rick Jones) Date: Tue, 08 Jan 2002 18:34:20 -0800 Subject: new feature w/ patch References: <8F88657F29DFD11189ED0008C728C6B008A5A12F@nor935-msx6.nor.chevron.com> Message-ID: <3C3BAC2C.E5DBF2A8@cup.hp.com> "Ladner, Eric (CLAD)" wrote: > Won't colon separated numbers cause problems for people as they move > towards IPv6? i do seem to recall that IPv6 address notation was going to use colons. while I cannot imagine someone enjoying typing-in an IPv6 address versus using a hostname, it could be best to select a different delimiter rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From stevesk at pobox.com Wed Jan 9 14:54:53 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 8 Jan 2002 19:54:53 -0800 (PST) Subject: new feature w/ patch In-Reply-To: <8F88657F29DFD11189ED0008C728C6B008A5A12F@nor935-msx6.nor.chevron.com> Message-ID: On Tue, 8 Jan 2002, Ladner, Eric (CLAD) wrote: :Won't colon separated numbers cause problems for people as they move :towards IPv6? the alternate form using / would be supported, as it is today. i'm not sure if an RFC2732-like syntax makes sense here. sshd ListenAddress attempts to use that. From maf at appgate.com Wed Jan 9 19:41:04 2002 From: maf at appgate.com (maf at appgate.com) Date: Wed, 9 Jan 2002 09:41:04 +0100 (CET) Subject: sftp/scp performance testing In-Reply-To: Message-ID: <20020109084308.4FEBB317A4@pelee.firedoor.se> On 8 Jan, Tobias Ringstrom wrote: \>> My method for testing OpenSSH performance has been something >> along the lines of: >> >> cat /dev/zero | ssh user at host "cat > /dev/null" >> >> and then monitoring network traffic using another tool. >> Something like: >> >> cat /dev/zero | cpipe | ssh user at host "cat > /dev/null" >> >> would also work. This method is useful because the zeronum >> generator is faster than any randomizer, and it completely filters >> out disk I/O. I once did something similar to test the performance of an ssh-based vpn (but I used ttcp). And got quite surprised when I got a throughput over 100Mbit/s when the vpn-nodes were connected with a 10Mbit/s network. The answer however was simple, they had compression enabled:-) From that point on I always use random-data to do performance testing. /MaF From norbert at linuxnetworks.de Wed Jan 9 22:34:50 2002 From: norbert at linuxnetworks.de (Norbert Sendetzky) Date: Wed, 9 Jan 2002 12:34:50 +0100 Subject: Passing a password from a program to ssh Message-ID: <200201091129.MAA20822@post.webmailer.de> Hi all Probably this question was asked before, but I didn't find anything in the FAQ or in the archives. I've written an programm that connects to a SSH server and communicate over the SSH protocol with a SSH subsystem. SSH now shows a prompt where the password should be typed in. If an error occurs (protocol error or so) the programm must reconnect to the server and reestablish the connection. If I fork the SSH program again, it will require the password to be typed into the console again. But as daemon there is no shell and it will fail. So, is there a possiblilty to pass the password e.g by using stdin or any other method which is secure? Norbert From markus at openbsd.org Wed Jan 9 23:57:55 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 9 Jan 2002 13:57:55 +0100 Subject: Require Multiple keys per host In-Reply-To: ; from bob-openssh@technogeeks.com on Tue, Jan 08, 2002 at 05:41:57PM -0800 References: Message-ID: <20020109135755.A21176@folly> On Tue, Jan 08, 2002 at 05:41:57PM -0800, bob-openssh at technogeeks.com wrote: > As of version 3.0.2p1 and perhaps earlier localhost forwarded connections > are checked in known_hosts. The difficulty is that if you have multiple > forwards, only one of them will exist as a valid host key for localhost. try to read the manpage, check that HostKeyAlias or UserKnownHosts work, and if you really need, use NoHostAuthenticationForLocalhost From nick at dccinc.com Thu Jan 10 02:00:27 2002 From: nick at dccinc.com (Nick Eggleston) Date: Wed, 9 Jan 2002 10:00:27 -0500 (EST) Subject: OpenSSH sshd: per-user restrictions and scp-only Message-ID: Greetings! Non-list subscriber, so please be sure to include me on replies. I want to be abut to set up sshd so that I can restrict the remote user's activities. In particular, I want... 1. no shell. I want them to be able to do scp and maybe port forwarding, but I DO NOT want them to be able to start up any shell or anything else! 2. i want to be able to restrict them to be able to do port forwarding ONLY to the the ip address and port number I specifiy. without these kinds of controls, ssh becomes kind of a risky proposition as opposed to, say, sslftp, whick only allows access to files. Hopefully, others have noticed these same problems and have some solutions. Thanks for your time!! From roth+openssh at feep.net Thu Jan 10 02:08:01 2002 From: roth+openssh at feep.net (Mark D. Roth) Date: Wed, 9 Jan 2002 09:08:01 -0600 Subject: keyboard-interactive In-Reply-To: <1010529453.29368.4.camel@xenon>; from damien.miller@my-fortress.com on Wed, Jan 09, 2002 at 09:37:33AM +1100 References: <1010529453.29368.4.camel@xenon> Message-ID: <20020109090801.A14811@yorktown.isdn.uiuc.edu> On Wed Jan 09 09:37 2002 +1100, Damien Miller wrote: > On Wed, 2002-01-09 at 02:33, Nicolas Williams wrote: > > Part of the problem is that a module might have more questions to ask > > given the answers to previous questions. Any system like PAM, with > > pluggable modules, will be potentially too dynamic to be used the way > > you want ("ask all your questions now, I'll answer them later"). > > I can't see why this is the case. An API like: > > while (!pam_conversation_done(pamh) { > pam_get_prompts(&prompts); > /* do something with them */ > pam_set_responses(&responses) > } > > takes care of the potential flexability and doesn't dictate structure to > the application developer. I may be missing something, but how is this functionally different from the way the conversation function works? The logic is essentially this: conversation_function(prompts) { /* do something with them */ return responses; } The while loop is taken care of for you by PAM itself by calling the conversation function multiple times. I don't see how this offers less functionality than the semantics you propose above...? -- Mark D. Roth http://www.feep.net/~roth/ From mouring at etoh.eviladmin.org Thu Jan 10 02:11:01 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 9 Jan 2002 09:11:01 -0600 (CST) Subject: Passing a password from a program to ssh In-Reply-To: <200201091129.MAA20822@post.webmailer.de> Message-ID: On Wed, 9 Jan 2002, Norbert Sendetzky wrote: > Hi all > > Probably this question was asked before, but I didn't find anything > in the FAQ or in the archives. > > I've written an programm that connects to a SSH server and > communicate over the SSH protocol with a SSH subsystem. SSH now shows > a prompt where the password should be typed in. If an error occurs > (protocol error or so) the programm must reconnect to the server and > reestablish the connection. If I fork the SSH program again, it will > require the password to be typed into the console again. But as > daemon there is no shell and it will fail. > > So, is there a possiblilty to pass the password e.g by using stdin or > any other method which is secure? > Why not use ssh-keygen and use that so you don't have to worry about entering passwords? - Ben From markus at openbsd.org Thu Jan 10 02:24:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 9 Jan 2002 16:24:33 +0100 Subject: Passing a password from a program to ssh In-Reply-To: <200201091129.MAA20822@post.webmailer.de> References: <200201091129.MAA20822@post.webmailer.de> Message-ID: <20020109152433.GD12465@faui02> don't use password authentication or write a ssh-askpass replacement and set SSH_ASKPASS From djast at cs.toronto.edu Thu Jan 10 03:58:19 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 9 Jan 2002 11:58:19 -0500 Subject: new feature w/ patch In-Reply-To: Your message of "Tue, 08 Jan 2002 22:54:53 EST." Message-ID: <02Jan9.115823edt.453139-19237@jane.cs.toronto.edu> On Tue, 08 Jan 2002 22:54:53 EST, Kevin Steves writes: > On Tue, 8 Jan 2002, Ladner, Eric (CLAD) wrote: > :Won't colon separated numbers cause problems for people as they move > :towards IPv6? > > the alternate form using / would be supported, as it is today. i'm not > sure if an RFC2732-like syntax makes sense here. sshd ListenAddress > attempts to use that. When I can manage to put together a bit of time, I'm hoping to (at Kevin's suggestion) supply a patch to move all the host/port-parsing code to one place, so that the same formats can be used for -L/-R/-D, ListenAddress, permitopen= in the key file, etc. I expect that all currently-accepted forms of specifying addresses/ports in any of those places will, in general, be accepted in all of them. In case anyone was wondering, when -L gets changed to accept the syntax "-L listenaddr:listenport:targethost:targetport", the "listenaddr" part will be optional, so the change should be backward compatible with the current -L syntax. The syntax for -R and -D should get similarly extended (although existing servers may not do the expected thing when a listenaddr is provided with -R). -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From dtwright at uiuc.edu Thu Jan 10 06:52:36 2002 From: dtwright at uiuc.edu (Dan Wright) Date: Wed, 9 Jan 2002 13:52:36 -0600 Subject: IRIX 6.5 RhostsRSA problems Message-ID: <20020109135236.C1321358@uiuc.edu> Hello, I'm new to the list, and I've been having a very weird problem with the IRIX version of portable openssh that I think may be a bug in this platform... I've looked through the FAQs and the man pages and can't find why this might not be working. The ssh binary is setuid-root, both ssh and sshd are told that Rhosts and RhostsRSA auth is OK in their config files, etc. I don't want to post my config files and verbose session transcripts right off, because I might be missing something obvious and don't want to clog your mailboxes :) Please let me know what parts of those files will be useful for diagnosing this and I'll send them along. If it is a bug, I'll be more then happy to assist in tracking it down and fixing it. Thanks, - Dan Wright (dtwright at uiuc.edu) (http://www.uiuc.edu/~dtwright) -] ------------------------------ [-] -------------------------------- [- ``Weave a circle round him thrice, / And close your eyes with holy dread, For he on honeydew hath fed, / and drunk the milk of Paradise.'' Samuel Taylor Coleridge, Kubla Khan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020109/e9335d97/attachment.bin From quentin.bracken at eds.com Thu Jan 10 06:12:36 2002 From: quentin.bracken at eds.com (Quentin Bracken) Date: Wed, 09 Jan 2002 13:12:36 -0600 Subject: 64-bit HP/UX 11.00 wtmp corruption identified Message-ID: <3C3C9624.ADC06860@eds.com> I spent some time with 3.0.2p1 to discover why OpenSSH on HP/UX 11.00 64-bit corrupts the /var/adm/wtmp file. The problem is with the utmp structure itself. When building with 32-bit compilation flags, the size of the utmp structure is 60 bytes. When building under 64-bit, the size is 72 bytes. The size difference is due to structure alignment and using basic types whose size changes depending on the integer size (like long). The OS and tools like "last" expect a wtmp entry to be 60 bytes in size. So, when OpenSSH is built with 64-bit options, it writes 72 byte entries into the wtmp causing "last" to seg fault. I do not know what a good work around could be. I temporarily modified the /usr/include/utmp.h structure to use int32_t as the type for ut_time instead of long and rebuilt loginrec.o and relinked sshd. OpenSSH performed correctly, updating wtmp like a champ. I thought that we could use utmpname and the pututline tools (which will convert the 72 byte structure to a 60 byte structure somehow), but their behavior is not actually compatible with wtmp. I also thought about defining a custom utmp structure when building on HP-UX 64-bit, but that really seems like a bad way of doing it. As far as I can tell, there are no patches from HP regarding this issue. So, that is why wtmp gets corrupted, but I wish I had a real work-around. -- Quentin Bracken Infrastructure Specialist EDS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020109/5e1d8b8b/attachment.html From stevesk at pobox.com Thu Jan 10 08:35:51 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 9 Jan 2002 13:35:51 -0800 (PST) Subject: new feature w/ patch In-Reply-To: <02Jan9.115823edt.453139-19237@jane.cs.toronto.edu> Message-ID: On Wed, 9 Jan 2002, Dan Astoorian wrote: :In case anyone was wondering, when -L gets changed to accept the syntax :"-L listenaddr:listenport:targethost:targetport", the "listenaddr" part :will be optional, so the change should be backward compatible with the :current -L syntax. The syntax for -R and -D should get similarly :extended (although existing servers may not do the expected thing when a :listenaddr is provided with -R). we might also consider deprecating the "port host:port" form in LocalForward and RemoteForward in favor of the same form as -L/R. From markus at openbsd.org Thu Jan 10 09:21:06 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 9 Jan 2002 23:21:06 +0100 Subject: keyboard-interactive In-Reply-To: <20020108051913.A25407@google.com>; from fcusack@fcusack.com on Tue, Jan 08, 2002 at 05:19:13AM -0800 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> Message-ID: <20020109232106.B28750@folly> On Tue, Jan 08, 2002 at 05:19:13AM -0800, Frank Cusack wrote: > On Tue, Jan 08, 2002 at 03:29:36PM +1100, Damien Miller wrote: > > The PAM API wants to ask all the questions and gather all the responses > > in a single conversation function. This doesn't work well with the SSH > > protocol, where userauth messages can arrive in any order. > > > > The current kbd-int PAM support assumes that it can get a response > > immediately and somewhat abuses the dispatch API to get at it. It > > probably isn't robust in the face of clients who send requests in a > > funny order. > > Do you have any example of a client that actually does this? I don't know. currently openssh works like this: there is a mainloop that dispatches the packets and calls different functions depending on the message type. so when sshd receives a REQUEST message the mainloop calls input_userauth_request() input_userauth_request() needs to parse the REQUEST message and (for kbd-interactive) contruct a INFO_REQUEST message by calling some PAM API and return the control to the mainloop. now the client can send _any_ packet, e.g. a KEXINIT for rekeying or a new REQUEST message for a different authentication method (e.g. pubkey). if the client sends the INFO_RESPONSE then input_userauth_info_response() needs to verify the reponse. From stevesk at pobox.com Thu Jan 10 09:35:30 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 9 Jan 2002 14:35:30 -0800 (PST) Subject: 64-bit HP/UX 11.00 wtmp corruption identified In-Reply-To: <3C3C9624.ADC06860@eds.com> Message-ID: On Wed, 9 Jan 2002, Quentin Bracken wrote: :I do not know what a good work around could be. I temporarily modified :the /usr/include/utmp.h structure to use int32_t as the type for ut_time :instead of long and rebuilt loginrec.o and relinked sshd. OpenSSH :performed correctly, updating wtmp like a champ. I thought that we :could use utmpname and the pututline tools (which will convert the 72 :byte structure to a 60 byte structure somehow), but their behavior is :not actually compatible with wtmp. I also thought about defining a :custom utmp structure when building on HP-UX 64-bit, but that really :seems like a bad way of doing it. ah, thanks for dealing with problems in TODO. we use getutx(3C) and getut(3C) for get* and put* (i think that is correct for hp-ux). would this be a defect in the 64-bit versions of those interfaces? i don't understand "not actually compatible with wtmp". From djm at mindrot.org Thu Jan 10 12:53:19 2002 From: djm at mindrot.org (Damien Miller) Date: 10 Jan 2002 12:53:19 +1100 Subject: keyboard-interactive In-Reply-To: <20020109090801.A14811@yorktown.isdn.uiuc.edu> References: <1010529453.29368.4.camel@xenon> <20020109090801.A14811@yorktown.isdn.uiuc.edu> Message-ID: <1010627600.2516.5.camel@xenon> On Thu, 2002-01-10 at 02:08, Mark D. Roth wrote: > > > takes care of the potential flexability and doesn't dictate structure to > > the application developer. > > I may be missing something, but how is this functionally different > from the way the conversation function works? The logic is > essentially this: > > conversation_function(prompts) > { > /* do something with them */ > return responses; > } This requires that the responses be given in the same function call that we receive the prompts. > The while loop is taken care of for you by PAM itself by calling the > conversation function multiple times. I don't see how this offers > less functionality than the semantics you propose above...? It doesn't allow you to decouple the prompting from the responses. -d From roth+openssh at feep.net Thu Jan 10 14:48:07 2002 From: roth+openssh at feep.net (Mark D. Roth) Date: Wed, 9 Jan 2002 21:48:07 -0600 Subject: keyboard-interactive In-Reply-To: <20020109232106.B28750@folly>; from markus@openbsd.org on Wed, Jan 09, 2002 at 11:21:06PM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> Message-ID: <20020109214807.A15545@yorktown.isdn.uiuc.edu> On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote: > currently openssh works like this: > > there is a mainloop that dispatches the packets and calls different > functions depending on the message type. > > so when sshd receives a REQUEST message the mainloop calls > input_userauth_request() > > input_userauth_request() needs to parse the REQUEST message and > (for kbd-interactive) contruct a INFO_REQUEST message by calling > some PAM API and return the control to the mainloop. > > now the client can send _any_ packet, e.g. a KEXINIT > for rekeying or a new REQUEST message for a different > authentication method (e.g. pubkey). > > if the client sends the INFO_RESPONSE then input_userauth_info_response() > needs to verify the reponse. OK, so how about this: * Call the main loop from the PAM conversation function with some state telling it where it was called from. * When the main loop gets the next message from the client, it can return control to the PAM conversation function. * If the client sent an INFO_RESPONSE message, the PAM conversation function returns the client's response, and the PAM transaction continues normally. * If the client sent some other type of message, the conversation function can return PAM_CONV_ERR to abort the PAM transaction. It should also set some state to indicate that the PAM transaction was aborted. * When pam_authenticate() returns, if the transaction was aborted, return control to the main loop to handle the request that the client sent. There are some obvious semantics to be worked out in terms of how the state is maintained, but the PAM code itself would be fairly straightforward. Or is there something I'm missing here? -- Mark D. Roth http://www.feep.net/~roth/ From dan at doxpara.com Thu Jan 10 17:16:11 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 9 Jan 2002 22:16:11 -0800 Subject: sftp/scp performance testing References: <20020109084308.4FEBB317A4@pelee.firedoor.se> Message-ID: <02aa01c1999e$4cc9a350$1701000a@effugas> > I once did something similar to test the performance of an ssh-based vpn > (but I used ttcp). And got quite surprised when I got a throughput over > 100Mbit/s when the vpn-nodes were connected with a 10Mbit/s network. The > answer however was simple, they had compression enabled:-) From that > point on I always use random-data to do performance testing. Yes, compression will break /dev/zero mightily :-) But /dev/urandom just isn't as fast, at least not on all platforms. Piping nonrandom data into SSH completely randomizes that data from the perspective of any routes in the middle, due to the equivalence of encrypted data and pure entropy. --Dan From fcusack at fcusack.com Thu Jan 10 19:10:26 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 10 Jan 2002 00:10:26 -0800 Subject: keyboard-interactive In-Reply-To: <20020109214807.A15545@yorktown.isdn.uiuc.edu>; from roth+openssh@feep.net on Wed, Jan 09, 2002 at 09:48:07PM -0600 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> Message-ID: <20020110001026.B30796@google.com> On Wed, Jan 09, 2002 at 09:48:07PM -0600, Mark D. Roth wrote: > On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote: > > so when sshd receives a REQUEST message the mainloop calls > > input_userauth_request() > > > > input_userauth_request() needs to parse the REQUEST message and > > (for kbd-interactive) contruct a INFO_REQUEST message by calling > > some PAM API and return the control to the mainloop. > > > > now the client can send _any_ packet, e.g. a KEXINIT > > for rekeying or a new REQUEST message for a different > > authentication method (e.g. pubkey). But KEXINIT (or any other non-auth message) /need not/ be handled "synchronously". Well, at best it's not clear that it /must be/ handled synchronously. Before I get to that, let me start with a problem in draft-ietf-secsh-userauth-13.txt, sec 2.1. As someone else mentioned, it says An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. However, this conflicts with the text of sec 2.2, which says The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. The conflict is that the server must acknowledge failed requests. Sec 2.1 says the server must ABANDON previous authentications if it receives another request. So we're off to a bad start. Sec. 2.2 goes on, Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. indicating - non-auth messages can be sent at any time; this is clear since if they could only be sent AFTER completion of the authentication, the text should read "after the client receives [SUCCESS]". - non-auth messages sent after (during) a request that results in failure may be ignored (implied) So a client could send a request for pk auth, during which he sends a KEXINIT message. That pk auth could fail, and then the client sends kbd-interactive which succeeds. The server may safely throw away the KEXINIT message. To me, that clearly means that non-auth messages need not be handled immediately. If they are to be handled immediately, there cannot be a distiction between auth requests that result in success and auth requests that result in failure. However, given the precedent set by the earlier conflicting text (re multiple auth requests and failure handling) and the lack of explicit statements as to how non-auth messages are to be handled, my conclusion, while valid based on the draft, may really just be an unintended consequence of an incompletely specified protocol. That is, it may be legal, but unintended behaviour. IMvHO, I would say the best course of action is to make no changes in the current implementation (other than perhaps handling an abortive (new) auth request), and instead spend energy getting the draft corrected/clarified. > OK, so how about this: > > * Call the main loop from the PAM conversation function with some > state telling it where it was called from. > > * When the main loop gets the next message from the client, it can > return control to the PAM conversation function. > > * If the client sent an INFO_RESPONSE message, the PAM conversation > function returns the client's response, and the PAM transaction > continues normally. > > * If the client sent some other type of message, the conversation > function can return PAM_CONV_ERR to abort the PAM transaction. It > should also set some state to indicate that the PAM transaction was > aborted. But that would unnecessarily fail the authentication, which might have gone on to success. I'd say this is fairly undesirable. I would say that instead of always returning control to "conv()", control should only be returned if the client message is an INFO_RESPONSE or a new userauth request. You'd have to tell conv() which one it is so it can continue or abort (fail) as needed. > * When pam_authenticate() returns, if the transaction was aborted, > return control to the main loop to handle the request that the > client sent. > > There are some obvious semantics to be worked out in terms of how the > state is maintained, but the PAM code itself would be fairly > straightforward. Or is there something I'm missing here? I think you're missing that both the non-auth and auth messages should continue as if they didn't overlap in sequence. Otherwise, your suggestion sounds reasonable (to me, anyway). If we assume that non-auth messages can be handled "asynchronously", then it's really easy. Just use appdata_ptr to store the non-auth messages, and if and after the authentication succeeds, then process them. Again, I'd do nothing until the draft is clarified. Especially given the expectation that current clients don't/won't actually show this behaviour. /fc From dan at doxpara.com Thu Jan 10 19:49:41 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 10 Jan 2002 00:49:41 -0800 Subject: sftp/scp performance testing References: <003a01c197b6$6f79f470$1701000a@effugas> <20020108001151.C4893@folly> Message-ID: <02f601c199b3$bea86ff0$1701000a@effugas> > > What should make a difference is whether the SSH1 or SSH2 protocols are > > used -- SSH1 implicitly authenticates packets, > > that's not true. SSH1 does not really authenticate packets, > it just uses CRC, while SSH2 uses a true MAC (e.g. hmac-md5 > or hmac-sha1). Markus-- Thus the difference between implicit and explicit authentication of packets. Implicit authentication basically says, look, the only other host that *could* generate a correctly decryptable packet is the one I exchanged encryption keys with, so I can implicitly assume any packet that decrypts into "something meaningful" comes from the host I authenticated earlier. Replay attacks don't defeat implicit authentication. Different sessions with the same host have different session keys, while the chaining of one packet to the next prevents intra-session replay. Of course, the problem is that anything can be decrypted with any key, it just won't necessarily mean anything. So CRCs were used in SSH1 as an attempt to ward off random corruption more than anything else. --Dan From markus at openbsd.org Thu Jan 10 19:48:57 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 10 Jan 2002 09:48:57 +0100 Subject: keyboard-interactive In-Reply-To: <20020110001026.B30796@google.com> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> Message-ID: <20020110084856.GA19126@faui02> On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote: > But KEXINIT (or any other non-auth message) /need not/ be handled > "synchronously". as i understand the transport draft, the KEXINIT is handled by a lower layer, and if the client send a KEXINIT message after the USERAUTH_REQUEST message, then the lower layer must finish the key exchange before continuing with the user authentication. > Well, at best it's not clear that it /must be/ handled > synchronously. Before I get to that, let me start with a problem in > draft-ietf-secsh-userauth-13.txt, sec 2.1. As someone else mentioned, > it says > > An authentication request MAY result in a further exchange of > messages. All such messages depend on the authentication method > used, and the client MAY at any time continue with a new > SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST > abandon the previous authentication attempt and continue with the new > one. > > However, this conflicts with the text of sec 2.2, which says > > The client MAY send several authentication requests without waiting > for responses from previous requests. The server MUST acknowledge > any failed requests with a SSH_MSG_USERAUTH_FAILURE message. > However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once > SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication > requests received after that SHOULD be silently ignored. > > The conflict is that the server must acknowledge failed requests. > Sec 2.1 says the server must ABANDON previous authentications if it > receives another request. So we're off to a bad start. > > Sec. 2.2 goes on, > > Any non-authentication messages sent by the client after the request > that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed > to the service being run on top of this protocol. i don't think this includes KEXINIT, because it's a lower layer. > IMvHO, I would say the best course of action is to make no changes in > the current implementation (other than perhaps handling an abortive (new) > auth request), and instead spend energy getting the draft corrected/clarified. yes, the only thing that needs to be handled is: (1) C->S: USERAUTH_REQUEST(kbdint) (2) S->C: INFO_REQUEST (3) C->S: USERAUTH_REQUEST(pubkey) (4) S->C: USERAUTH_SUCCESS/FAILURE the draft reads: > The server MUST acknowledge > any failed requests with a SSH_MSG_USERAUTH_FAILURE message. I guess this does _not_ mean that after message (3) the server has to send a USERAUTH_FAILURE for message (1), since this message has been handled by (2). However, on receiving (3) the state associated with "kbdint" must be abandonned. > Again, I'd do nothing until the draft is clarified. Especially given the > expectation that current clients don't/won't actually show this behaviour. -m From fcusack at fcusack.com Thu Jan 10 20:33:36 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 10 Jan 2002 01:33:36 -0800 Subject: keyboard-interactive In-Reply-To: <20020110084856.GA19126@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 09:48:57AM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> <20020110084856.GA19126@faui02> Message-ID: <20020110013336.E30796@google.com> On Thu, Jan 10, 2002 at 09:48:57AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote: > > But KEXINIT (or any other non-auth message) /need not/ be handled > > "synchronously". > > as i understand the transport draft, the KEXINIT > is handled by a lower layer, and if the client > send a KEXINIT message after the USERAUTH_REQUEST message, > then the lower layer must finish the key exchange > before continuing with the user authentication. hmm.. that does sound like what *should* happen, but then again the userauth draft need not mention explicit handling of non-auth messages if that's true. But the userauth draft goes out of it's way to mention how these should be handled. Why would the auth layer bother to mention anything about non-auth messages if it isn't to receive them? Anyway, you shouldn't limit this to the KEXINIT message, that was just an example. After actually looking that the code, it seems that auth2-pam.c correctly handles non-auth messages, except that a new SSH_MSG_USERAUTH_REQUEST doesn't correctly abort a previous auth request. I can work up a patch if needed. /fc From fcusack at fcusack.com Thu Jan 10 21:55:04 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 10 Jan 2002 02:55:04 -0800 Subject: keyboard-interactive In-Reply-To: <20020110084856.GA19126@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 09:48:57AM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> <20020110084856.GA19126@faui02> Message-ID: <20020110025504.U30796@google.com> On Thu, Jan 10, 2002 at 09:48:57AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote: > > But KEXINIT (or any other non-auth message) /need not/ be handled > > "synchronously". > > as i understand the transport draft, the KEXINIT > is handled by a lower layer, and if the client > send a KEXINIT message after the USERAUTH_REQUEST message, > then the lower layer must finish the key exchange > before continuing with the user authentication. This should be clarified to read any non-auth message received by the auth layer, then. Natch, if the auth layer doesn't receive the message, it's immaterial. KEXINIT may be been a bad example. /fc From fcusack at fcusack.com Thu Jan 10 22:24:42 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 10 Jan 2002 03:24:42 -0800 Subject: keyboard-interactive In-Reply-To: <20020108173229.Y27171@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Jan 08, 2002 at 05:32:31PM -0500 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108103305.A27398@sm2p1386swk.wdr.com> <3C3B5198.3020301@ayrnetworks.com> <20020108173229.Y27171@sm2p1386swk.wdr.com> Message-ID: <20020110032442.V30796@google.com> On Tue, Jan 08, 2002 at 05:32:31PM -0500, Nicolas Williams wrote: > On Tue, Jan 08, 2002 at 12:07:52PM -0800, Bryan Chua wrote: > > Of course, it would be wise to set up the conversation > > timeout, otherwise the system would thus be exposed to a distributed DoS > > from several clients with open auth states in the middle of a blocking > > function.... I don't see how this is a problem. /fc From markus at openbsd.org Thu Jan 10 23:13:00 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 10 Jan 2002 13:13:00 +0100 Subject: sftp/scp performance testing In-Reply-To: <02f601c199b3$bea86ff0$1701000a@effugas> References: <003a01c197b6$6f79f470$1701000a@effugas> <20020108001151.C4893@folly> <02f601c199b3$bea86ff0$1701000a@effugas> Message-ID: <20020110121300.GA18024@faui02> On Thu, Jan 10, 2002 at 12:49:41AM -0800, Dan Kaminsky wrote: > Thus the difference between implicit and explicit authentication of > packets. as I understand this: SSH 1 thinks that CBC encryption is ok for implicit packet authentication. but this is wrong, thus the need for the deattack.c hack. Modes like OCB would simultaneously provide both privacy and authenticity. From Nicolas.Williams at ubsw.com Fri Jan 11 00:23:41 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 10 Jan 2002 08:23:41 -0500 Subject: keyboard-interactive In-Reply-To: <20020109214807.A15545@yorktown.isdn.uiuc.edu>; from roth+openssh@feep.net on Wed, Jan 09, 2002 at 09:48:07PM -0600 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> Message-ID: <20020110082338.B27398@sm2p1386swk.wdr.com> On Wed, Jan 09, 2002 at 09:48:07PM -0600, Mark D. Roth wrote: > On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote: > OK, so how about this: > > * Call the main loop from the PAM conversation function with some > state telling it where it was called from. Bingo. Make the mainloop reentrant. > * When the main loop gets the next message from the client, it can > return control to the PAM conversation function. OR perhaps the mainloop can return to the conversation function only if it's an INFO_RESPONSE message. Else, if handling continues as you suggest then kbd-interactive messages can't be interleaved with any others; whether or not sshd should work that way depends on the protocol drafts. > * If the client sent an INFO_RESPONSE message, the PAM conversation > function returns the client's response, and the PAM transaction > continues normally. > > * If the client sent some other type of message, the conversation > function can return PAM_CONV_ERR to abort the PAM transaction. It > should also set some state to indicate that the PAM transaction was > aborted. > > * When pam_authenticate() returns, if the transaction was aborted, > return control to the main loop to handle the request that the > client sent. > > There are some obvious semantics to be worked out in terms of how the > state is maintained, but the PAM code itself would be fairly > straightforward. Or is there something I'm missing here? See above. > -- > Mark D. Roth > http://www.feep.net/~roth/ Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Fri Jan 11 00:50:03 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 10 Jan 2002 14:50:03 +0100 Subject: keyboard-interactive In-Reply-To: <20020110082338.B27398@sm2p1386swk.wdr.com> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110082338.B27398@sm2p1386swk.wdr.com> Message-ID: <20020110135003.GA24871@faui02> On Thu, Jan 10, 2002 at 08:23:41AM -0500, Nicolas Williams wrote: > On Wed, Jan 09, 2002 at 09:48:07PM -0600, Mark D. Roth wrote: > > On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote: > > OK, so how about this: > > > > * Call the main loop from the PAM conversation function with some > > state telling it where it was called from. > > Bingo. Make the mainloop reentrant. yes, this uglyness is currently used: dispatch_run() input_userauth_request() userauth_kbdint() auth2_pam() pam_authenticate() do_pam_conversation_kbd_int() dispatch_run() now we receive a USERAUTH_REQUEST(pubkey) and should call input_userauth_request()...... From Nicolas.Williams at ubsw.com Fri Jan 11 01:15:50 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 10 Jan 2002 09:15:50 -0500 Subject: keyboard-interactive In-Reply-To: <20020110135003.GA24871@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 02:50:03PM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110082338.B27398@sm2p1386swk.wdr.com> <20020110135003.GA24871@faui02> Message-ID: <20020110091548.C27398@sm2p1386swk.wdr.com> On Thu, Jan 10, 2002 at 02:50:03PM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 08:23:41AM -0500, Nicolas Williams wrote: > > Bingo. Make the mainloop reentrant. > > yes, this uglyness is currently used: > > dispatch_run() > input_userauth_request() > userauth_kbdint() > auth2_pam() > pam_authenticate() > do_pam_conversation_kbd_int() > dispatch_run() I don't think that's ugly... It would be easier if all PAM implementations supported PAM_CONV_AGAIN/PAM_INCOMPLETE/pam_*() restarts though. > now we receive a USERAUTH_REQUEST(pubkey) and should > call input_userauth_request()...... Well, if that implies that kbd-interact cannot proceed, then dispatch_run() can return to do_pam_conversation_kbd_int() and so on back to the top-level dispatch_run(). But if kbd-interact messages can be interleaved with others, then I fail to see any other way to make this work. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Fri Jan 11 01:20:10 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 10 Jan 2002 15:20:10 +0100 Subject: keyboard-interactive In-Reply-To: <20020110091548.C27398@sm2p1386swk.wdr.com> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110082338.B27398@sm2p1386swk.wdr.com> <20020110135003.GA24871@faui02> <20020110091548.C27398@sm2p1386swk.wdr.com> Message-ID: <20020110142009.GA27632@faui02> On Thu, Jan 10, 2002 at 09:15:50AM -0500, Nicolas Williams wrote: > On Thu, Jan 10, 2002 at 02:50:03PM +0100, Markus Friedl wrote: > > On Thu, Jan 10, 2002 at 08:23:41AM -0500, Nicolas Williams wrote: > > > Bingo. Make the mainloop reentrant. > > > > yes, this uglyness is currently used: > > > > dispatch_run() > > input_userauth_request() > > userauth_kbdint() > > auth2_pam() > > pam_authenticate() > > do_pam_conversation_kbd_int() > > dispatch_run() > > I don't think that's ugly... It would be easier if all PAM > implementations supported PAM_CONV_AGAIN/PAM_INCOMPLETE/pam_*() > restarts though. well, i think that's a major uglyness. in the future don't want to have it possible to call dispatch_run() at all. -m From Nicolas.Williams at ubsw.com Fri Jan 11 03:11:54 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 10 Jan 2002 11:11:54 -0500 Subject: keyboard-interactive In-Reply-To: <20020110142009.GA27632@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 03:20:10PM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110082338.B27398@sm2p1386swk.wdr.com> <20020110135003.GA24871@faui02> <20020110091548.C27398@sm2p1386swk.wdr.com> <20020110142009.GA27632@faui02> Message-ID: <20020110111152.D27398@sm2p1386swk.wdr.com> On Thu, Jan 10, 2002 at 03:20:10PM +0100, Markus Friedl wrote: > well, i think that's a major uglyness. in the future don't > want to have it possible to call dispatch_run() at all. > > -m Are you proposing some other way of working around this? You could use co-processes, one to run the PAM API, passing the questions and getting responses from the co-process that's running dispatch_run(). When I say "co-process" I mean the computer science concept, not necessarily a fork()ed process. Or you could choose to support Linux-PAM but not Sun PAM, I suppose. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From peb at mppmu.mpg.de Fri Jan 11 04:20:05 2002 From: peb at mppmu.mpg.de (Peter Breitenlohner) Date: Thu, 10 Jan 2002 18:20:05 +0100 (CET) Subject: An openssl shared library versioning problem (fwd) Message-ID: Hi, Below a message I had originally sent to openssl-bugs. The version mismatch mentioned below was OpenSSL 0x0090603f vs. OpenSSL 0x0090601f Meanwhile Richard Levitte has sent me the following: >>>>>>>>> Begin excerpt from levitte (first msg.) peb> If, on the other hand, the libraries from 0.9.6a and 0.9.6c are peb> binary compatible they certainly deserve the same soname, but peb> then ssh shouln't be able to notice the difference. They are binary compatible. I suggest you look in the openssh source to see how it detects the version, and yes, it's a bit oversensitive. >>>>>>>>> End excerpt from levitte >>>>>>>>> Begin excerpt from levitte (second msg.) peb> Now ssh may be a bit oversensitive, but certainly should protect peb> itself against incompatible library versions. Of course, and considering we keep OpenSSL binary compatible between patch levels, the test could be performed like this: if (((OPENSSL_VERSION_NUMBER ^ SSLeay()) & 0xffffff0f) == 0) /* success */ else /* failure */ (note: I haven't tested that, but it should mask the patch level. Also, the version number scheme was different before 0.9.5, so the above would only work starting with 0.9.5) >>>>>>>>> End excerpt from levitte NB: I think according to the OPENSSL_VERSION_NUMBER.3 manpage it should actually be & 0xffffff00fL for ssl version>=0.9.5 It would be really nice if this could be taken into account. regards Peter Breitenlohner ---------- Forwarded message ---------- Date: Thu, 10 Jan 2002 13:32:27 +0100 (CET) From: Peter Breitenlohner To: openssl-bugs at openssl.org Subject: An openssl shared library versioning problem Hi, I want to report an openssl shared library versioning problem (ix86-linux). Recently I have built and installed openssh-3.0.2p1 (using a shared library version of libcrypto), because the former version had some security holes. Before doing so I have upgraded from openssl-0.9.6a to 0.9.6c. After installing openssl, and thereby replacing libcrypto.so.0.9.6 from 0.9.6a by a library of the same name from 0.9.6c, but before building the new ssh, ssh complained about a build/use library version mismatch and failed. .......... rest deleted regards Peter Breitenlohner From quentin.bracken at eds.com Fri Jan 11 04:46:09 2002 From: quentin.bracken at eds.com (Quentin Bracken) Date: Thu, 10 Jan 2002 11:46:09 -0600 Subject: 64-bit HP/UX 11.00 wtmp corruption identified References: Message-ID: <3C3DD361.28B1BD7B@eds.com> Kevin, I tried re-implementing the wtmp writing routines to use utmpname(3), setutent(3), pututline(3), and so on. If my understanding is correct, the wtmp and utmp files function differently. When processing a logout with utmp, the routines will find the corresponding login record and update it with the logout information. However, when working with wtmp, you always want to append information. You do not actually want to update the login entry. Instead you want to add a whole new logout entry. That is why the wtmp grows so much faster than utmp. After re-implementing the code in loginrec.c to use the getut(3) routines to write to wtmp, I noticed the following behavior. After I log in, "last" shows an entry for my SSH login and lists it as "still logged in". The wtmp file grows by 60 bytes. When I logout, "last" no longer shows any record of my login. In other words, the entry that said "still logged in" did not show my logout time as you would expect. Rather, it simply no longer showed up. And, the wtmp file did not grow in size. This leads me to believe the getut(3) routines updated the login entry. That, and the man pages say they do. When working correctly, the wtmp file should grow by 60 bytes when I log in and again when I log out. Two entries are actually recorded. Using the pututline functions, the login entry is updated instead. I did read in some HP/UX 11 64-bit documents that use of the getut(3) functions has been deprecated in favor of the getutx(3) functions. However, no other system utilities that ship with HP/UX update the wtmpx file. It is normally blank. In fact, the utmp.h and utmpx.h include files do not define WTMPX_FILE where they do define UTMP_FILE, UTMPX_FULE, and WTMP_FILE. It is interesting that they indicate the getut(3) function should no longer be used when they (HP) still use them. Note that when using the pututline(3) routine, even if I pass it the 72 byte 64-bit utmp structure, it casts it to the 60 byte 32-bit structure and records it. This is good. It does not corrupt the wtmp file. Kevin Steves wrote: > On Wed, 9 Jan 2002, Quentin Bracken wrote: > :I do not know what a good work around could be. I temporarily modified > :the /usr/include/utmp.h structure to use int32_t as the type for ut_time > :instead of long and rebuilt loginrec.o and relinked sshd. OpenSSH > :performed correctly, updating wtmp like a champ. I thought that we > :could use utmpname and the pututline tools (which will convert the 72 > :byte structure to a 60 byte structure somehow), but their behavior is > :not actually compatible with wtmp. I also thought about defining a > :custom utmp structure when building on HP-UX 64-bit, but that really > :seems like a bad way of doing it. > > ah, thanks for dealing with problems in TODO. > > we use getutx(3C) and getut(3C) for get* and put* (i think that is correct > for hp-ux). would this be a defect in the 64-bit versions of those > interfaces? i don't understand "not actually compatible with wtmp". -- Quentin Bracken Infrastructure Specialist EDS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020110/24fc465b/attachment.html From dwd at bell-labs.com Fri Jan 11 06:40:29 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 10 Jan 2002 13:40:29 -0600 Subject: Potential SSH2 exploit Message-ID: <20020110134029.A17525@lucent.com> I just noticed (at least on OpenSSH 3.0p1) that even though I have both RSA and DSA keys available in sshd_config on a server, only a ssh-rsa line shows up in known_hosts on the client side, not a ssh-dss line (that priority may come from the fact that my RSA key is listed before my DSA key in sshd_config). If I comment out the RSA key in sshd_config and restart the server, then the next time the client connects it warns that a new key is being added and adds a ssh-dss line to known_hosts. Isn't that a potential opening for a man-in-the-middle exploit? Somebody could take over a DNS name, offer only a DSA key, and forward traffic to the real host. SSH users expect that once they've established the identity of a host they're safe from man-in-the-middle exploits so they may gloss over the warning of an additional key being added. Maybe the OpenSSH ssh client should retrieve and store both kinds of host keys if they're missing from known_hosts and the server has them available. I don't know if that would take a protocol change or not but I doubt it because ssh-keyscan has the ability to scan for both rsa and dsa keys at the same time (and be sure to scan for both if you do use it!). - Dave Dykstra From austin at coremetrics.com Fri Jan 11 07:00:34 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 10 Jan 2002 14:00:34 -0600 Subject: Potential SSH2 exploit In-Reply-To: <20020110134029.A17525@lucent.com> References: <20020110134029.A17525@lucent.com> Message-ID: <1010692834.11628.11.camel@UberGeek> I might have to agree with this thought. It does leave a pretty wide open hole it seems for now. I only use One key type in my network end-to-end, but if I were to use 2, it is possible. How could this be stopped. On Thu, 2002-01-10 at 13:40, Dave Dykstra wrote: > I just noticed (at least on OpenSSH 3.0p1) that even though I have both > RSA > and DSA keys available in sshd_config on a server, only a ssh-rsa line > shows up in known_hosts on the client side, not a ssh-dss line (that > priority may come from the fact that my RSA key is listed before my DSA > key > in sshd_config). If I comment out the RSA key in sshd_config and > restart > the server, then the next time the client connects it warns that a new > key > is being added and adds a ssh-dss line to known_hosts. > > Isn't that a potential opening for a man-in-the-middle exploit? > Somebody > could take over a DNS name, offer only a DSA key, and forward traffic to > the real host. SSH users expect that once they've established the > identity > of a host they're safe from man-in-the-middle exploits so they may gloss > over the warning of an additional key being added. Maybe the OpenSSH > ssh > client should retrieve and store both kinds of host keys if they're > missing > from known_hosts and the server has them available. I don't know if > that > would take a protocol change or not but I doubt it because ssh-keyscan > has > the ability to scan for both rsa and dsa keys at the same time (and be > sure > to scan for both if you do use it!). > > - Dave Dykstra > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020110/60a4245c/attachment.bin From dbt at meat.net Fri Jan 11 07:38:14 2002 From: dbt at meat.net (David Terrell) Date: Thu, 10 Jan 2002 12:38:14 -0800 Subject: Potential SSH2 exploit In-Reply-To: <1010692834.11628.11.camel@UberGeek>; from austin@coremetrics.com on Thu, Jan 10, 2002 at 02:00:34PM -0600 References: <20020110134029.A17525@lucent.com> <1010692834.11628.11.camel@UberGeek> Message-ID: <20020110123814.F8808@pianosa.catch22.org> There is a similar problem with ssh1/ssh2 compatability. There is no substitute for reading the prompt carefully, or generating an ssh-known-hosts file. On Thu, Jan 10, 2002 at 02:00:34PM -0600, Austin Gonyou wrote: > I might have to agree with this thought. It does leave a pretty wide > open hole it seems for now. I only use One key type in my network > end-to-end, but if I were to use 2, it is possible. How could this be > stopped. > > On Thu, 2002-01-10 at 13:40, Dave Dykstra wrote: > > I just noticed (at least on OpenSSH 3.0p1) that even though I have both > > RSA > > and DSA keys available in sshd_config on a server, only a ssh-rsa line > > shows up in known_hosts on the client side, not a ssh-dss line (that > > priority may come from the fact that my RSA key is listed before my DSA > > key > > in sshd_config). If I comment out the RSA key in sshd_config and > > restart > > the server, then the next time the client connects it warns that a new > > key > > is being added and adds a ssh-dss line to known_hosts. > > > > Isn't that a potential opening for a man-in-the-middle exploit? > > Somebody > > could take over a DNS name, offer only a DSA key, and forward traffic to > > the real host. SSH users expect that once they've established the > > identity > > of a host they're safe from man-in-the-middle exploits so they may gloss > > over the warning of an additional key being added. Maybe the OpenSSH > > ssh > > client should retrieve and store both kinds of host keys if they're > > missing > > from known_hosts and the server has them available. I don't know if > > that > > would take a protocol change or not but I doubt it because ssh-keyscan > > has > > the ability to scan for both rsa and dsa keys at the same time (and be > > sure > > to scan for both if you do use it!). > > > > - Dave Dykstra > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin at coremetrics.com > > "It is the part of a good shepherd to shear his flock, not to skin it." > Latin Proverb -- David Terrell | "Anyone who says that is woefully Prime Minister, Nebcorp | underinformed. IE, reads usenet." dbt at meat.net | - Sean O'Connor http://wwn.nebcorp.com/ From fcusack at fcusack.com Fri Jan 11 08:50:40 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 10 Jan 2002 13:50:40 -0800 Subject: keyboard-interactive In-Reply-To: <20020110142009.GA27632@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 03:20:10PM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110082338.B27398@sm2p1386swk.wdr.com> <20020110135003.GA24871@faui02> <20020110091548.C27398@sm2p1386swk.wdr.com> <20020110142009.GA27632@faui02> Message-ID: <20020110135040.H20828@google.com> On Thu, Jan 10, 2002 at 03:20:10PM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 09:15:50AM -0500, Nicolas Williams wrote: > > On Thu, Jan 10, 2002 at 02:50:03PM +0100, Markus Friedl wrote: > > > > > > yes, this uglyness is currently used: > > > > > > dispatch_run() > > > input_userauth_request() > > > userauth_kbdint() > > > auth2_pam() > > > pam_authenticate() > > > do_pam_conversation_kbd_int() > > > dispatch_run() > > > > I don't think that's ugly... It would be easier if all PAM > > implementations supported PAM_CONV_AGAIN/PAM_INCOMPLETE/pam_*() > > restarts though. > > well, i think that's a major uglyness. in the future don't > want to have it possible to call dispatch_run() at all. I also don't think it's ugly; it makes it pretty easy to fix the new-userauth-request problem and to handle any arbitrary packet. I was actually going to comment on how nice it was. /fc From ssklar at stanford.edu Fri Jan 11 09:15:22 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Thu, 10 Jan 2002 14:15:22 -0800 Subject: OpenSSH 3.0.Xp1, AIX -> Sun trusted host problem Message-ID: Hi, Folks ... Apologies in advance for the length of this message, but I wanted to be thorough, and provide as much info as I could. I'm trying to figure out a problem in trusted-host authentication using AIX hosts as clients, and a Sun host as the server; either I'm missing something real obvious, or there might be a bug somewhere in some piece of software involved here. -- All of the AIX hosts are at AIX 4.3.3-ML08 -- All of the AIX hosts are using OpenSSH 3.0.1p1, from the same compilation -- All of the AIX hosts have identical /etc/ssh/ssh_config files -- The Sun host is running OpenSSH 3.0.2p1 on Solaris 5.6 I'm attempting to get trusted host authentication for protocol 2 working, for a user account (existing on all four systems, with the same UID and primary GID, but with local home directories, not NFS mounted). The following is identical for all of the AIX hosts: $ ls -l `which ssh` ; ssh -V -rws--x--x 1 root system 1034732 Dec 02 10:09 /usr/local/bin/ssh OpenSSH_3.0.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f And on the Sun server: # /usr/local/sbin/sshd -V sshd: option requires an argument -- V sshd version OpenSSH_3.0.2p1 Usage: sshd [options] ... In order to protect the innocent, I'm replacing the hostnames and IP addresses in this mail with: aixhost1 aa.aa.aa.aa aixhost2 bb.bb.bb.bb aixhost3 cc.cc.cc.cc sunhost dd.dd.dd.dd -- From all AIX systems, trusted-host authentication works fine, with the three AIX hosts listed in the ~/.shosts file. -- On one AIX system, trusted-host authentication works IF the user account is a member of the "system" group. (in the details below, this system will be "aixhost1") -- On the other two AIX systems, trusted-host authentication fails, with no difference seen if the user is a member of the "system" group or not. Here is the contents of the /etc/ssh/ssh_config file, which is identical on all three AIX systems: Host * LogLevel ERROR IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_dsa IdentityFile ~/.ssh/id_rsa UserKnownHostsFile ~/.ssh/known_hosts GlobalKnownHostsFile /etc/ssh/ssh_known_hosts XAuthLocation /usr/bin/X11/xauth Protocol 2,1 Port 22 KeepAlive no CheckHostIP yes StrictHostKeyChecking ask EscapeChar ~ Cipher 3des Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 Compression no CompressionLevel 6 ConnectionAttempts 1 HostKeyAlgorithms ssh-rsa,ssh-dss UsePrivilegedPort yes PreferredAuthentications hostbased,publickey,keyboard-interactive,password NoHostAuthenticationForLocalhost no BatchMode no PasswordAuthentication yes NumberOfPasswordPrompts 3 RSAAuthentication yes PubkeyAuthentication yes UseRsh no FallBackToRsh no RhostsAuthentication yes RhostsRSAAuthentication yes HostbasedAuthentication yes ClearAllForwardings no ForwardAgent yes ForwardX11 yes GatewayPorts yes On the Sun server, here is the /etc/ssh/sshd_config file ... PidFile /etc/ssh/sshd.pid Port 22 Protocol 2,1 ListenAddress 0.0.0.0 HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no IgnoreRhosts no IgnoreUserKnownHosts no StrictModes yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no KeepAlive yes SyslogFacility DAEMON LogLevel DEBUG RhostsAuthentication no RhostsRSAAuthentication yes HostbasedAuthentication yes RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords no UseLogin no MaxStartups 10:20:40 ReverseMappingCheck no Subsystem sftp /usr/local/libexec/sftp-server The following log snippets are from the server-side. I've cut out what I thought to be irrelevant parts. ==================== Test #1 (succeeded) ==================== The user is "patrol", and is in the "system" group ... aixhost1:patrol 350 /opt/patrol>id uid=6737(patrol) gid=1012(patrol) groups=0(system) aixhost1:patrol 351 /opt/patrol>ssh -2 sunhost uptime 1:27pm up 13 day(s), 2:45, 4 users, load average: 0.02, 0.02, 0.02 ... and from the sshd server log ... Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: Connection from aa.aa.aa.aa port 732 Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: Client protocol version 2.0; client software version OpenSSH_3.0.1p1 Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: match: OpenSSH_3.0.1p1 pat ^OpenSSH Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: Enabling compatibility mode for protocol 2.0 Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_KEXINIT sent Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_KEXINIT received Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: kex: client->server blowfish-cbc hmac-md5 none Jan 10 13:31:14 sunhost.stanford.edu sshd[6832]: debug1: kex: server->client blowfish-cbc hmac-md5 none Jan 10 13:31:14 sunhost.stanford.edu sshd[6804]: debug1: Forked child 6832. Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: dh_gen_key: priv key bits set: 131/256 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: bits set: 1024/2049 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: bits set: 1030/2049 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: kex_derive_keys Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: newkeys: mode 1 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_NEWKEYS sent Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: waiting for SSH2_MSG_NEWKEYS Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: newkeys: mode 0 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: SSH2_MSG_NEWKEYS received Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: KEX done Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: userauth-request for user patrol service ssh-connection method none Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: attempt 0 failures 0 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: Failed none for patrol from aa.aa.aa.aa port 732 ssh2 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: userauth-request for user patrol service ssh-connection method hostbased Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: attempt 1 failures 1 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: userauth_hostbased: cuser patrol chost aixhost1.Stanford.EDU. pkalg ssh-dss slen 55 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: restore_uid Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: restore_uid Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: restore_uid Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: ssh_dss_verify: signature correct Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: Accepted hostbased for patrol from aa.aa.aa.aa port 732 ssh2 Jan 10 13:31:15 sunhost.stanford.edu sshd[6832]: debug1: Entering interactive session for SSH2. [ the above connection succeeded; the client used a privileged port, and the server "Accepted hostbased" ] ==================== Test #2 (failed) ==================== same system, same user, but removed from the "system" group ... Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: Connection from aa.aa.aa.aa port 36125 Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: debug1: Client protocol version 2.0; client software version OpenSSH_3.0.1p1 Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: debug1: match: OpenSSH_3.0.1p1 pat ^OpenSSH Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: Enabling compatibility mode for protocol 2.0 Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 Jan 10 13:36:35 sunhost.stanford.edu sshd[6843]: debug1: Rhosts Authentication disabled, originating port 36125 not trusted. [ note that a privileged port was NOT used, and thus the user was prompted for a password ] ==================== Test #3 (failed) ==================== another system, same user, and user is in the "system" group ... Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: Connection from bb.bb.bb.bb port 624 Jan 10 13:40:08 sunhost.stanford.edu sshd[6804]: debug1: Forked child 6848. Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: Client protocol version 2.0; client software version OpenSSH_3.0.1p1 Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: match: OpenSSH_3.0.1p1 pat ^OpenSSH Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: Enabling compatibility mode for protocol 2.0 Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_KEXINIT sent Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_KEXINIT received Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: kex: client->server blowfish-cbc hmac-md5 none Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: kex: server->client blowfish-cbc hmac-md5 none Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: dh_gen_key: priv key bits set: 130/256 Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: bits set: 1031/2049 Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Jan 10 13:40:08 sunhost.stanford.edu sshd[6848]: debug1: bits set: 1025/2049 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: kex_derive_keys Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: newkeys: mode 1 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_NEWKEYS sent Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: waiting for SSH2_MSG_NEWKEYS Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: newkeys: mode 0 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: SSH2_MSG_NEWKEYS received Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: KEX done Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: userauth-request for user patrol service ssh-connection method none Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: attempt 0 failures 0 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: Failed none for patrol from bb.bb.bb.bb port 624 ssh2 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: userauth-request for user patrol service ssh-connection method hostbased Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: attempt 1 failures 1 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: userauth_hostbased: cuser patrol chost aixhost2.Stanford.EDU. pkalg ssh-dss slen 55 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: Failed hostbased for patrol from bb.bb.bb.bb port 624 ssh2 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: userauth-request for user patrol service ssh-connection method hostbased Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: attempt 2 failures 2 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: userauth_hostbased: cuser patrol chost aixhost2.Stanford.EDU. pkalg ssh-rsa slen 143 Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: debug1: restore_uid Jan 10 13:40:09 sunhost.stanford.edu sshd[6848]: Failed hostbased for patrol from bb.bb.bb.bb port 624 ssh2 [ privileged port was used, but hostbased auth was still not accepted ] ==================== Test #4 (failed) ==================== same as test #3, but user is removed from "system" group ... Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: Connection from bb.bb.bb.bb port 893 Jan 10 13:57:26 sunhost.stanford.edu sshd[6804]: debug1: Forked child 6878. Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: Client protocol version 2.0; client software version OpenSSH_3.0.1p1 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: match: OpenSSH_3.0.1p1 pat ^OpenSSH Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: Enabling compatibility mode for protocol 2.0 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: list_hostkey_types: ssh-rsa,ssh-dss Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_KEXINIT sent Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_KEXINIT received Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: kex: client->server blowfish-cbc hmac-md5 none Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: kex: server->client blowfish-cbc hmac-md5 none Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: dh_gen_key: priv key bits set: 127/256 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: bits set: 1023/2049 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: bits set: 1052/2049 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: kex_derive_keys Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: newkeys: mode 1 Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_NEWKEYS sent Jan 10 13:57:26 sunhost.stanford.edu sshd[6878]: debug1: waiting for SSH2_MSG_NEWKEYS Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: newkeys: mode 0 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: SSH2_MSG_NEWKEYS received Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: KEX done Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: userauth-request for user patrol service ssh-connection method none Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: attempt 0 failures 0 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: Failed none for patrol from bb.bb.bb.bb port 893 ssh2 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: userauth-request for user patrol service ssh-connection method hostbased Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: attempt 1 failures 1 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: userauth_hostbased: cuser patrol chost aixhost2.Stanford.EDU. pkalg ssh-dss slen 55 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: Failed hostbased for patrol from bb.bb.bb.bb port 893 ssh2 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: userauth-request for user patrol service ssh-connection method hostbased Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: attempt 2 failures 2 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: userauth_hostbased: cuser patrol chost aixhost2.Stanford.EDU. pkalg ssh-rsa slen 143 Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: temporarily_use_uid: 6737/1012 (e=0) Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: debug1: restore_uid Jan 10 13:57:27 sunhost.stanford.edu sshd[6878]: Failed hostbased for patrol from bb.bb.bb.bb port 893 ssh2 [ client again used privileged port, but user was still denied ] =============================================================================== If I'm missing something obvious, I'd appreciate it if someone would point it out, and I'd gladly dope-slap myself. If there does indeed seem to be some issue there, it would be great if someone with more coding experience (which would be just about everyone) could point me in the proper direction. I should also note that this works fine when going from a sun host as a client and a sun host as the server. Thanks, --Sandy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From stevesk at pobox.com Fri Jan 11 09:17:26 2002 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 10 Jan 2002 14:17:26 -0800 (PST) Subject: 64-bit HP/UX 11.00 wtmp corruption identified In-Reply-To: <3C3DD361.28B1BD7B@eds.com> Message-ID: On Thu, 10 Jan 2002, Quentin Bracken wrote: :Kevin, I tried re-implementing the wtmp writing routines to use utmpname(3), :setutent(3), pututline(3), and so on. If my understanding is correct, the :wtmp and utmp files function differently. When processing a logout with :utmp, the routines will find the corresponding login record and update it :with the logout information. However, when working with wtmp, you always :want to append information. You do not actually want to update the login :entry. Instead you want to add a whole new logout entry. That is why the :wtmp grows so much faster than utmp. yes, i understand now. i was thinking pututline() could be used to append to wtmp. :After re-implementing the code in loginrec.c to use the getut(3) routines to :write to wtmp, I noticed the following behavior. After I log in, "last" :shows an entry for my SSH login and lists it as "still logged in". The wtmp :file grows by 60 bytes. When I logout, "last" no longer shows any record of :my login. In other words, the entry that said "still logged in" did not show :my logout time as you would expect. Rather, it simply no longer showed up. :And, the wtmp file did not grow in size. This leads me to believe the :getut(3) routines updated the login entry. That, and the man pages say they :do. that's my understanding as well. :When working correctly, the wtmp file should grow by 60 bytes when I log in :and again when I log out. Two entries are actually recorded. Using the :pututline functions, the login entry is updated instead. : :I did read in some HP/UX 11 64-bit documents that use of the getut(3) :functions has been deprecated in favor of the getutx(3) functions. However, :no other system utilities that ship with HP/UX update the wtmpx file. It is :normally blank. In fact, the utmp.h and utmpx.h include files do not define :WTMPX_FILE where they do define UTMP_FILE, UTMPX_FULE, and WTMP_FILE. It is :interesting that they indicate the getut(3) function should no longer be used :when they (HP) still use them. i believe that man pages that refer to wtmpx are wrong. there is no wtmpx file on HP-UX (up to 11.11 at least). note also that we do DISABLE_UTMP for HP-UX so loginrec will use pututxline(), which will write to utmpx then utmp. :Note that when using the pututline(3) routine, even if I pass it the 72 byte :64-bit utmp structure, it casts it to the 60 byte 32-bit structure and :records it. This is good. It does not corrupt the wtmp file. i'm not sure how best to address this, other than to have a private version of struct utmp, and that approach is really ugly. are you certain that utmp/utmpx are updated correctly (finger -R, who -R, etc. all showing good data)? i thought i had seen corruption there too when i tested this earlier last year. that may have been related to some socket issues though and fixed when we started using xopen_networking(7). also, while this should be fixed, i don't see much benefit to building openssh 64-bit on HP-UX particularly due to the lack of 64-bit libpam. From fcusack at fcusack.com Fri Jan 11 19:11:25 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 11 Jan 2002 00:11:25 -0800 Subject: [PATCH] PAM/abandon userauth (was: keyboard-interactive) In-Reply-To: <20020110084856.GA19126@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 09:48:57AM +0100 References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> <20020110084856.GA19126@faui02> Message-ID: <20020111001125.Y20903@google.com> On Thu, Jan 10, 2002 at 09:48:57AM +0100, Markus Friedl wrote: > yes, the only thing that needs to be handled is: > > (1) C->S: USERAUTH_REQUEST(kbdint) > (2) S->C: INFO_REQUEST > (3) C->S: USERAUTH_REQUEST(pubkey) > (4) S->C: USERAUTH_SUCCESS/FAILURE > > the draft reads: > > > The server MUST acknowledge > > any failed requests with a SSH_MSG_USERAUTH_FAILURE message. > > I guess this does _not_ mean that after message (3) the > server has to send a USERAUTH_FAILURE for message (1), > since this message has been handled by (2). > However, on receiving (3) the state associated with "kbdint" > must be abandonned. Attached is a patch to correctly abandon authentications in PAM. It is against 3.0.2p1. It basically completes the PAM auth (unsuccessfully) and then restarts the new authentication. In this patch, only PAM can abandon, but the method is trivially implementable by the other auth types. If desired, I can supply patches for the other auth methods also. I added a packet_rewind() function to packet.c, needed to support this. You may think it nasty at first glance, but really in the light of how PAM works, it's the best solution (IMHO). If PAM actually called the new auth method, there'd be some nasty bits to deal with -- eg, you can't know how many times the conversation function is going to be called. Also attached is a patch to the client to test that the server does the right thing. The patched client sends a kbdint auth request, then sends a password auth request. The client throws away the INFO_REQUEST and doesn't expect a failure message for the abandoned authentication. It works for me on a Linux 2.2.19/glibc-2.1 x86 machine. /fc -------------- next part -------------- diff -ur openssh.orig/auth.c openssh/auth.c --- openssh.orig/auth.c Thu Jan 10 14:40:45 2002 +++ openssh/auth.c Thu Jan 10 22:16:13 2002 @@ -202,7 +202,8 @@ if (authctxt->postponed) authmsg = "Postponed"; else - authmsg = authenticated ? "Accepted" : "Failed"; + authmsg = (authenticated == 1) ? "Accepted" : + (authenticated == 0) ? "Failed" : "Abandoned"; authlog("%s %s for %s%.100s from %.200s port %d%s", authmsg, diff -ur openssh.orig/auth2-pam.c openssh/auth2-pam.c --- openssh.orig/auth2-pam.c Thu Jan 10 14:40:45 2002 +++ openssh/auth2-pam.c Thu Jan 10 23:22:43 2002 @@ -17,12 +17,14 @@ const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); void input_userauth_info_response_pam(int type, int plen, void *ctxt); +static void pam_input_userauth_request(int, int, void *); +extern void input_userauth_request(int, int, void *); struct { - int finished, num_received, num_expected; + int finished, num_received, num_expected, abandon; int *prompts; struct pam_response *responses; -} context_pam2 = {0, 0, 0, NULL}; +} context_pam2 = {0, 0, 0, 0, NULL}; static struct pam_conv conv2 = { do_pam_conversation_kbd_int, @@ -32,20 +34,16 @@ int auth2_pam(Authctxt *authctxt) { - int retval = -1; - if (authctxt->user == NULL) fatal("auth2_pam: internal error: no user"); conv2.appdata_ptr = authctxt; do_pam_set_conv(&conv2); + context_pam2.abandon = 0; - dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, - &input_userauth_info_response_pam); - retval = (do_pam_authenticate(0) == PAM_SUCCESS); - dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, NULL); - - return retval; + /* 3-way return value: 1 = success, 0 = failure, -1 = quiet failure */ + return (do_pam_authenticate(0) == PAM_SUCCESS) ? 1 : + context_pam2.abandon; } static int @@ -62,6 +60,9 @@ context_pam2.responses = xmalloc(sizeof(struct pam_response) * num_msg); memset(context_pam2.responses, 0, sizeof(struct pam_response) * num_msg); + if (context_pam2.abandon == -1) + return PAM_CONV_ERR; + text = NULL; for (i = 0, context_pam2.num_expected = 0; i < num_msg; i++) { int style = PAM_MSG_MEMBER(msg, i, msg_style); @@ -113,12 +114,18 @@ * the client *should* be in lock-step with us, so the loop should * only be traversed once. */ + dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, + &input_userauth_info_response_pam); + dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &pam_input_userauth_request); while(context_pam2.finished == 0) { done = 1; +debug("doing pam dispatch"); dispatch_run(DISPATCH_BLOCK, &done, appdata_ptr); if(context_pam2.finished == 0) debug("extra packet during conversation"); } + dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &input_userauth_request); + dispatch_set(SSH2_MSG_USERAUTH_INFO_RESPONSE, NULL); if(context_pam2.num_received == context_pam2.num_expected) { *resp = context_pam2.responses; @@ -153,6 +160,20 @@ context_pam2.finished = 1; packet_done(); +} + + +/* PAM version of input_userauth_request(), needed so we abandon correctly. */ + +static void +pam_input_userauth_request(int type, int plen, void *ctxt) +{ +debug("got pam userauth"); + /* Tell PAM to abandon. */ + context_pam2.abandon = -1; + context_pam2.finished = 1; + /* Tell packet_read() to restart. */ + packet_rewind(type); } #endif diff -ur openssh.orig/auth2.c openssh/auth2.c --- openssh.orig/auth2.c Thu Jan 10 14:40:45 2002 +++ openssh/auth2.c Thu Jan 10 23:20:14 2002 @@ -70,7 +70,7 @@ /* protocol */ static void input_service_request(int, int, void *); -static void input_userauth_request(int, int, void *); +void input_userauth_request(int, int, void *); static void protocol_error(int, int, void *); /* helper */ @@ -172,7 +172,7 @@ xfree(service); } -static void +void input_userauth_request(int type, int plen, void *ctxt) { Authctxt *authctxt = ctxt; @@ -252,13 +252,13 @@ authctxt->user); /* Special handling for root */ - if (authenticated && authctxt->pw->pw_uid == 0 && + if ((authenticated > 0) && authctxt->pw->pw_uid == 0 && !auth_root_allowed(method)) authenticated = 0; #ifdef USE_PAM - if (authenticated && authctxt->user && !do_pam_account(authctxt->user, - NULL)) + if ((authenticated > 0) && authctxt->user && + !do_pam_account(authctxt->user, NULL)) authenticated = 0; #endif /* USE_PAM */ @@ -278,6 +278,7 @@ /* now we can break out */ authctxt->success = 1; } else { + /* This counts abaondoned authentications as failures. */ if (authctxt->failures++ > AUTH_FAIL_MAX) { #ifdef WITH_AIXAUTHENTICATE loginfailed(authctxt->user, @@ -286,13 +287,16 @@ #endif /* WITH_AIXAUTHENTICATE */ packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } - methods = authmethods_get(); - packet_start(SSH2_MSG_USERAUTH_FAILURE); - packet_put_cstring(methods); - packet_put_char(0); /* XXX partial success, unused */ - packet_send(); - packet_write_wait(); - xfree(methods); + /* Don't send a failure message if auth was abandoned. */ + if (authenticated == 0) { + methods = authmethods_get(); + packet_start(SSH2_MSG_USERAUTH_FAILURE); + packet_put_cstring(methods); + packet_put_char(0); /* XXX partial success, unused */ + packet_send(); + packet_write_wait(); + xfree(methods); + } } } diff -ur openssh.orig/packet.c openssh/packet.c --- openssh.orig/packet.c Thu Jan 10 14:40:45 2002 +++ openssh/packet.c Thu Jan 10 23:26:37 2002 @@ -603,6 +603,8 @@ DBG(debug("packet_send done")); } +static int rewind_type = -1; /* see packet_read() and packet_rewind() */ + /* * Waits until a packet has been received, and returns its type. Note that * no other data is processed until this returns, so this function should not @@ -617,6 +619,19 @@ char buf[8192]; DBG(debug("packet_read()")); + /* "rewind" if requested */ + if (rewind_type != -1) { + type = rewind_type; + rewind_type = -1; + *payload_len_ptr = buffer_len(&incoming_packet); +debug("rewind type %u, len %u", rewind_type, *payload_len_ptr); +#ifdef PACKET_DEBUG + fprintf(stderr, "re-read/plain[%d]:\r\n", type); + buffer_dump(&incoming_packet); +#endif + return type; + } + setp = (fd_set *)xmalloc(howmany(connection_in+1, NFDBITS) * sizeof(fd_mask)); @@ -959,6 +974,20 @@ packet_process_incoming(const char *buf, u_int len) { buffer_append(&input, buf, len); +} + +/* + * Places a packet back into the input stream. The next call to + * packet_read() will "re-read" this packet. The caller must not have + * processed the packet (ie, no calls to packet_get_string(), etc.). + * This is probably only useful during ssh2 authentication, to abandon an + * authentication request if a new one is started. + */ + +void +packet_rewind(int type) +{ + rewind_type = type; } /* Returns a character from the packet. */ diff -ur openssh.orig/packet.h openssh/packet.h --- openssh.orig/packet.h Thu Jan 10 14:40:45 2002 +++ openssh/packet.h Thu Jan 10 22:19:40 2002 @@ -44,6 +44,7 @@ void packet_read_expect(int *payload_len_ptr, int type); int packet_read_poll(int *packet_len_ptr); void packet_process_incoming(const char *buf, u_int len); +void packet_rewind(int type); u_int packet_get_char(void); u_int packet_get_int(void); -------------- next part -------------- diff -ur openssh.orig/sshconnect2.c openssh/sshconnect2.c --- openssh.orig/sshconnect2.c Thu Jan 10 14:40:45 2002 +++ openssh/sshconnect2.c Thu Jan 10 23:44:46 2002 @@ -455,13 +455,14 @@ packet_start(SSH2_MSG_USERAUTH_REQUEST); packet_put_cstring(authctxt->server_user); packet_put_cstring(authctxt->service); - packet_put_cstring(authctxt->method->name); + packet_put_cstring("password"); packet_put_char(0); packet_put_cstring(password); memset(password, 0, strlen(password)); xfree(password); packet_add_padding(64); packet_send(); +packet_write_wait(); return 1; } @@ -759,9 +760,13 @@ packet_put_cstring(options.kbd_interactive_devices ? options.kbd_interactive_devices : ""); packet_send(); +packet_write_wait(); dispatch_set(SSH2_MSG_USERAUTH_INFO_REQUEST, &input_userauth_info_req); +/* return 1; +*/ + return userauth_passwd(authctxt); } /* @@ -777,6 +782,8 @@ debug2("input_userauth_info_req"); +return; + if (authctxt == NULL) fatal("input_userauth_info_req: no authentication context"); From markus at openbsd.org Fri Jan 11 19:50:44 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 11 Jan 2002 09:50:44 +0100 Subject: Potential SSH2 exploit In-Reply-To: <20020110134029.A17525@lucent.com> References: <20020110134029.A17525@lucent.com> Message-ID: <20020111085044.GA24414@faui02> On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > I don't know if that > would take a protocol change or not but I doubt it because ssh-keyscan has > the ability to scan for both rsa and dsa keys at the same time (and be sure > to scan for both if you do use it!). ssh-keyscan makes 1 connection per key type. From carson at taltos.org Fri Jan 11 19:59:32 2002 From: carson at taltos.org (Carson Gaspar) Date: Fri, 11 Jan 2002 03:59:32 -0500 Subject: OpenSSH 3.0.Xp1, AIX -> Sun trusted host problem In-Reply-To: References: Message-ID: <19924609.1010721571@[192.168.0.1]> I am _not_ an AIX expert, but I suspect one of your problems is that the setuid bit on the ssh binary is not being honored unless the user invoking it is in the system group. Why this could be, I have no idea. Try the following: 1) log in as patrol; echo $$ to get your shell's pid 2) log in as root in another session 3) as root "truss -f -o $filename -p $pid" where $pid is patrol's shell's pid 4) as patrol try the ssh command 5) ^C the truss 6) repeat with the other system group membership 7) see what the !@#$%'s different For the other machine that doesn't work at all, I suspect an incorrect known_host key entry on the server. but I'd have to add debugging commands into the sshd source to find out. Bad system logging, no doughnut. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From markus at openbsd.org Fri Jan 11 20:00:50 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 11 Jan 2002 10:00:50 +0100 Subject: Potential SSH2 exploit In-Reply-To: <20020110134029.A17525@lucent.com> References: <20020110134029.A17525@lucent.com> Message-ID: <20020111090050.GB24414@faui02> On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > I just noticed (at least on OpenSSH 3.0p1) that even though I have both RSA > and DSA keys available in sshd_config on a server, only a ssh-rsa line > shows up in known_hosts on the client side, not a ssh-dss line (that > priority may come from the fact that my RSA key is listed before my DSA key > in sshd_config). no, it comes from HostKeyAlgorithms ssh-rsa,ssh-dss > If I comment out the RSA key in sshd_config and restart > the server, then the next time the client connects it warns that a new key > is being added and adds a ssh-dss line to known_hosts. yes, ssh should always ask. > Isn't that a potential opening for a man-in-the-middle exploit? man-in-the-middle is always possible if ssh sees a new hostkey. > Somebody > could take over a DNS name, offer only a DSA key, and forward traffic to > the real host. SSH users expect that once they've established the identity > of a host they're safe from man-in-the-middle exploits so they may gloss > over the warning of an additional key being added. i think keys should no longer be 'automatically added'. they should not be 'automatically added' for the IP address, if the key matches for the DNS name, but no key is known for the IP address (Niels?). > Maybe the OpenSSH ssh > client should retrieve and store both kinds of host keys not possible. > if they're missing > from known_hosts and the server has them available. they client could say: server offers an unknown rsa key, but we already have a known dsa key. > I don't know if that > would take a protocol change or not but I doubt it because ssh-keyscan has > the ability to scan for both rsa and dsa keys at the same time (and be sure > to scan for both if you do use it!). ssh-keyscan makes 2 connections if you request 2 different key types. From markus at openbsd.org Fri Jan 11 20:08:58 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 11 Jan 2002 10:08:58 +0100 Subject: Potential SSH2 exploit In-Reply-To: <20020110134029.A17525@lucent.com> References: <20020110134029.A17525@lucent.com> Message-ID: <20020111090857.GA25502@faui02> On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > I comment out the RSA key in sshd_config and restart > the server, then the next time the client connects it warns that a new key > is being added and adds a ssh-dss line to known_hosts. Are you sure that ssh just warns and automatically adds the key? I get this: % ssh bla -p1234 The authenticity of host 'bla (10.1.1.1)' can't be established. DSA key fingerprint is 5a:c9:15:95:a2:4f:0a:42:99:8c:63:92:06:36:b4:8d. Are you sure you want to continue connecting (yes/no)? ^C % So I don't see a new potential for a MITM attack, MITM is always possible if ssh says: The authenticity of host 'XXXX' can't be established. (however, ssh could try to list all known keys for this host) From peterw at usa.net Fri Jan 11 23:14:20 2002 From: peterw at usa.net (Peter W) Date: Fri, 11 Jan 2002 07:14:20 -0500 Subject: Potential SSH2 exploit In-Reply-To: <20020111090050.GB24414@faui02>; from markus@openbsd.org on Fri, Jan 11, 2002 at 10:00:50AM +0100 References: <20020110134029.A17525@lucent.com> <20020111090050.GB24414@faui02> Message-ID: <20020111071420.C19895@usa.net> On Fri, Jan 11, 2002 at 10:00:50AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > > Maybe the OpenSSH ssh > > client should retrieve and store both kinds of host keys > > not possible. Well, there *could* be logic like this, right? if ( key host presents is new ) { /* we don't know this host, or something has changed, e.g. maybe they've upgraded from SSH 1.5 to SSH 1.5/2, and now we're seing the SSH 2 key b/c we prefer protocol 2 -- see how many unknown keys the server offers */ foreach keytype we support { if ( we don't have such a key for this host ) { make a bogus/keyscan connection, show user the fingerprint, ask if the key should be cached } } } But I fear that's a bad idea. It would use more bandwidth, you'd be showing the user three diff fingerprints each time, even though in most cases they'd never, ever connect w/ anything other than their preferred SSH revision & the server's preferred key, and then there's the question of DSA keys & random number generators, right? That if the pseudo-random number generator stinks, performing a DSA operation can be dangerous, right? If that's true of simply scanning for the sshd's DSA key, then IMO it's obvious that trying to grab all the sshd's keys up front is a bad, bad idea. Clients should warn about unknown/changed keys (as OpenSSH does) and users should pay attention to those warnings. -Peter From markus at openbsd.org Fri Jan 11 23:24:40 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 11 Jan 2002 13:24:40 +0100 Subject: Potential SSH2 exploit In-Reply-To: <20020111071420.C19895@usa.net> References: <20020110134029.A17525@lucent.com> <20020111090050.GB24414@faui02> <20020111071420.C19895@usa.net> Message-ID: <20020111122440.GA8017@faui02> On Fri, Jan 11, 2002 at 07:14:20AM -0500, Peter W wrote: > On Fri, Jan 11, 2002 at 10:00:50AM +0100, Markus Friedl wrote: > > On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > > > > Maybe the OpenSSH ssh > > > client should retrieve and store both kinds of host keys > > > > not possible. > > Well, there *could* be logic like this, right? won't happen. > if ( key host presents is new ) { > /* we don't know this host, or something has changed, e.g. > maybe they've upgraded from SSH 1.5 to SSH 1.5/2, and now > we're seing the SSH 2 key b/c we prefer protocol 2 -- > see how many unknown keys the server offers */ > foreach keytype we support { > if ( we don't have such a key for this host ) { > make a bogus/keyscan connection, no, you don't want to do all the algorithm negotiation again. > show user the fingerprint, > ask if the key should be cached > } > } > } i'd rather have if (key is new) { print all known keys for this host ask if key should be accepted. } > But I fear that's a bad idea. It would use more bandwidth, you'd > be showing the user three diff fingerprints each time, even though > in most cases they'd never, ever connect w/ anything other than > their preferred SSH revision & the server's preferred key, and then > there's the question of DSA keys & random number generators, right? > Clients should warn about unknown/changed keys (as OpenSSH does) and > users should pay attention to those warnings. yes, since OpenSSH already warns, i don't see big issue here. From peterw at usa.net Fri Jan 11 23:44:43 2002 From: peterw at usa.net (Peter Watkins) Date: Fri, 11 Jan 2002 07:44:43 -0500 Subject: Potential SSH2 exploit In-Reply-To: <20020111122440.GA8017@faui02>; from markus@openbsd.org on Fri, Jan 11, 2002 at 01:24:40PM +0100 References: <20020110134029.A17525@lucent.com> <20020111090050.GB24414@faui02> <20020111071420.C19895@usa.net> <20020111122440.GA8017@faui02> Message-ID: <20020111074443.D19895@usa.net> On Fri, Jan 11, 2002 at 01:24:40PM +0100, Markus Friedl wrote: > On Fri, Jan 11, 2002 at 07:14:20AM -0500, Peter W wrote: > > On Fri, Jan 11, 2002 at 10:00:50AM +0100, Markus Friedl wrote: > > > On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > > > > > > Maybe the OpenSSH ssh > > > > client should retrieve and store both kinds of host keys > > > > > > not possible. > > > > Well, there *could* be logic like this, right? > > won't happen. > > Clients should warn about unknown/changed keys (as OpenSSH does) and > > users should pay attention to those warnings. > > yes, since OpenSSH already warns, i don't see big issue here. Nor do I. "won't happen" != "not possible", *but* "possible" != "good idea", either. Take care, and happy new year, -Peter From Nicolas.Williams at ubsw.com Sat Jan 12 02:54:01 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 11 Jan 2002 10:54:01 -0500 Subject: X11 forwarding, -f, error handling Message-ID: <20020111105359.E27398@sm2p1386swk.wdr.com> I'd like a feature whereby ssh puts itself in the background after the first successful X11 (or other port) forwarding. The reason for this is simple: error handling. If the application fails to open the X display and exits, then the client can still exit with the application's exit code. But if the application opens the X display successfully, then it can just display any errors by itself. I intend to write and contribute such a patch to implement such a feature in the next few days. Comments? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Sat Jan 12 04:03:22 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 11 Jan 2002 12:03:22 -0500 Subject: Potential SSH2 exploit In-Reply-To: <20020111122440.GA8017@faui02>; from markus@openbsd.org on Fri, Jan 11, 2002 at 01:24:40PM +0100 References: <20020110134029.A17525@lucent.com> <20020111090050.GB24414@faui02> <20020111071420.C19895@usa.net> <20020111122440.GA8017@faui02> Message-ID: <20020111120320.F27398@sm2p1386swk.wdr.com> On Fri, Jan 11, 2002 at 01:24:40PM +0100, Markus Friedl wrote: > i'd rather have > if (key is new) { > print all known keys for this host > ask if key should be accepted. > } Is it possible to reject the new host key and negotiate a key exchange for a known host key? [...] > yes, since OpenSSH already warns, i don't see big issue here. There is no issue. Except, perhaps, that if other types of host keys are known for the remote host, if there's a way to negotiate the useage of the known keys, that might be good, at least as an option. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ser at germane-software.com Sat Jan 12 05:39:27 2002 From: ser at germane-software.com (Sean Russell) Date: Fri, 11 Jan 2002 10:39:27 -0800 Subject: Interfacing with ssh-agent, API programming question Message-ID: <20020111183929.D55F61217@ender.germane-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I apologise in advance if this isn't the appropriate forum. If it isn't, please tell me which group to post my question to, and I'll go away. I'm trying to leverage on the ssh-agent, with the goal of easing the use of security by minimizing the number of times passwords need to be entered. Currently, I'm personally entering four different passwords, one for login, one for ssh-agent, one for GPG support in my mailer, and one for my crypt FS. Specifically, I'm trying to expand the CryptFS (FiST) authentication utility to use secret key information obtained from an existing ssh-agent parent process, should one exist. The CryptFS utility itself is very simple, but I'm having trouble figuring out how to get ssh-agent to cough up something reasonably secure. I can get it to give me the public key (which is of no use). I'd like it to sign something for me, or even give me the secret key. If there is a better way of doing this, I'd like to know. I just want something to use as an encryption key for the filesystem. For average use (ssh-agent being run, then running ssh-add from a sub-process) it appears that the key stored in the ssh-agent is an RSA1, which the ssh-agent won't use to generate signatures (generating "illegal key type" errors). Thanks, in advance, for any help or pointers! - --- SER - -- |.. "They that can give up essential liberty to obtain a little <|> temporary safety deserve neither liberty nor safety." /|\ -- Benjamin Franklin /| | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PzFfP0KxygnleI8RAnuKAKDAa3u6r/yBnvy/1KZtWv+l0Kq0vgCcDIJv /nTcstKPvjSBPMW10dZ1Co4= =f3up -----END PGP SIGNATURE----- From michael at bizsystems.com Sat Jan 12 05:53:33 2002 From: michael at bizsystems.com (Michael) Date: Fri, 11 Jan 2002 10:53:33 -0800 Subject: I'm stumped Message-ID: <200201111853.g0BIrOxa013611@ns2.is.bizsystems.com> I just installed 302p1 on a client's machine (I run it on all of mine) and something is definetly wrong, can't figure out what. ssh localhost ssh_exchange_identification: Connection closed by remote host stock config files except ssh allows X11 forwarding any suggestions? Michael at Insulin-Pumpers.org From andreas at conectiva.com.br Sat Jan 12 07:16:05 2002 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Fri, 11 Jan 2002 18:16:05 -0200 Subject: I'm stumped In-Reply-To: <200201111853.g0BIrOxa013611@ns2.is.bizsystems.com> References: <200201111853.g0BIrOxa013611@ns2.is.bizsystems.com> Message-ID: <20020111201605.GQ1424@conectiva.com.br> Em Fri, Jan 11, 2002 at 10:53:33AM -0800, Michael escreveu: > ssh localhost > ssh_exchange_identification: Connection closed by remote host /etc/hosts.{allow,deny} might be denying localhost for sshd From Nicolas.Williams at ubsw.com Sat Jan 12 08:01:14 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 11 Jan 2002 16:01:14 -0500 Subject: Channels API question (was Re: hang on exit bug under Linux) In-Reply-To: <20011214181059.A12650@foo.birdnet.se>; from stuge@cdy.org on Fri, Dec 14, 2001 at 06:10:59PM +0100 References: <200112130252.fBD2q99t017673@rollcage.bl.echidna.id.au> <20011213035924.C16141@foo.birdnet.se> <1008261058.2212.4.camel@johnh.apropos.com> <20011213163549.GA8500@wiggy.net> <20011214015841.H16141@foo.birdnet.se> <20011214181059.A12650@foo.birdnet.se> Message-ID: <20020111160113.G27398@sm2p1386swk.wdr.com> On Fri, Dec 14, 2001 at 06:10:59PM +0100, Peter Stuge wrote: > Ok. Here we go. It's not very complicated but it took me some time to get > familiar with all the code, which is very easy to read, kudos to all! > And after finishing it, I fell alseep. Ohwell. > > For this to work as desired the sshd must send the SSH_MSG_CHANNEL_CLOSE > message fast enough for the client to buffer it together with the > CHANNEL_REQ "exit-status", so that CHAN_CLOSE_RCVD is set in the channel > flags when client_process_buffered_input_packets() returns. If this isn't > acceptable/practical the only alternative I can see is to set a time limit. Ok, I'm coming back to this. 1. I think that you should really be patching client_input_channel_req() where it checks for "exit-status" so that appropriate action is taken. 2. I'm not sure how best to force quitting and I have failed to understand what Markus has said. Should the code set quit_pending=1? Or should channel_input_ieof() and what not to close the session's channel? And how is that best accomplished? How to force the other channels to close? > //Peter > > -- > irc: CareBear\ > irl: Peter Stuge Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Sat Jan 12 08:17:57 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 11 Jan 2002 22:17:57 +0100 Subject: Interfacing with ssh-agent, API programming question In-Reply-To: <20020111183929.D55F61217@ender.germane-software.com>; from ser@germane-software.com on Fri, Jan 11, 2002 at 10:39:27AM -0800 References: <20020111183929.D55F61217@ender.germane-software.com> Message-ID: <20020111221757.A4706@folly> On Fri, Jan 11, 2002 at 10:39:27AM -0800, Sean Russell wrote: > I'd like it to sign something for me, or even give me the > secret key. If there is a better way of doing this, I'd like to know. I > just want something to use as an encryption key for the filesystem. you can use the API from authfd.h however, ssh-agent does not give away the secret key. this is what the agent it for. it just does operations using the secret key. > For average use (ssh-agent being run, then running ssh-add from a > sub-process) it appears that the key stored in the ssh-agent is an RSA1, > which the ssh-agent won't use to generate signatures (generating "illegal > key type" errors). if you generate a key with ssh-keygen -t {rsa,dsa} -f xxx then you can use this key to sign data. however, the returned signature will be in an ssh specific format: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-11.txt Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). From dwd at bell-labs.com Sat Jan 12 09:51:56 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 11 Jan 2002 16:51:56 -0600 Subject: Potential SSH2 exploit In-Reply-To: <20020111090857.GA25502@faui02>; from markus@openbsd.org on Fri, Jan 11, 2002 at 10:08:58AM +0100 References: <20020110134029.A17525@lucent.com> <20020111090857.GA25502@faui02> Message-ID: <20020111165156.A21636@lucent.com> On Fri, Jan 11, 2002 at 10:00:50AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: ... > > Maybe the OpenSSH ssh > > client should retrieve and store both kinds of host keys > > not possible. Not without a protocol change at least. On Fri, Jan 11, 2002 at 10:08:58AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote: > > I comment out the RSA key in sshd_config and restart > > the server, then the next time the client connects it warns that a new key > > is being added and adds a ssh-dss line to known_hosts. > > Are you sure that ssh just warns and automatically adds the key? > > I get this: > > % ssh bla -p1234 > The authenticity of host 'bla (10.1.1.1)' can't be established. > DSA key fingerprint is 5a:c9:15:95:a2:4f:0a:42:99:8c:63:92:06:36:b4:8d. > Are you sure you want to continue connecting (yes/no)? ^C > % Right, I wasn't trying to imply that the warning didn't include a prompt. That's what it would do unless you have StrictHostKeyChecking=no in which case it skips the prompt. > So I don't see a new potential for a MITM attack, > MITM is always possible if ssh says: > The authenticity of host 'XXXX' can't be established. > > (however, ssh could try to list all known keys for this host) That would be of some help; make the warning stronger if there is a known key of another type. Hey, for that matter why not print out the big warning that somebody could be doing something nasty? It's really no different if somebody has exchanged one RSA key for another than if they've exchange one RSA key for a DSA key. Right? That would be a simple fix. - Dave From michael at bizsystems.com Sat Jan 12 10:46:33 2002 From: michael at bizsystems.com (Michael) Date: Fri, 11 Jan 2002 15:46:33 -0800 Subject: I'm stumped In-Reply-To: <20020111201605.GQ1424@conectiva.com.br> References: <200201111853.g0BIrOxa013611@ns2.is.bizsystems.com> Message-ID: <200201112346.g0BNkUxa015383@ns2.is.bizsystems.com> > Em Fri, Jan 11, 2002 at 10:53:33AM -0800, Michael escreveu: > > ssh localhost > > ssh_exchange_identification: Connection closed by remote host > > /etc/hosts.{allow,deny} might be denying localhost for sshd > Yep.... dumb mistake on my part, thanks for the feedback. You'd figure after doing so many installs that I'd remember that. sigh..... Michael Michael at Insulin-Pumpers.org From chuayl at 1-net.com.sg Sat Jan 12 12:15:06 2002 From: chuayl at 1-net.com.sg (chuayl at 1-net.com.sg) Date: Sat, 12 Jan 2002 09:15:06 +0800 Subject: automate SFTP Message-ID: <48256B3F.0006E09C.00@mail.1-net.com.sg> Is there anyway to automate a command line SFTP to transfer files to a SSH Server. Please advice. Thanks From mouring at etoh.eviladmin.org Sat Jan 12 12:36:23 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 11 Jan 2002 19:36:23 -0600 (CST) Subject: automate SFTP In-Reply-To: <48256B3F.0006E09C.00@mail.1-net.com.sg> Message-ID: Depends on the direction. sftp user at site:/path/to/file.tgz works very nicely. for put you should do like: echo "put file /path/to/lcation/filename.tgz" | sftp user at site You can use SSH keys as your form of authenitication. - Ben On Sat, 12 Jan 2002 chuayl at 1-net.com.sg wrote: > > > Is there anyway to automate a command line SFTP to transfer files to a SSH > Server. > > Please advice. Thanks > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dbt at meat.net Sat Jan 12 19:22:20 2002 From: dbt at meat.net (David Terrell) Date: Sat, 12 Jan 2002 00:22:20 -0800 Subject: Potential SSH2 exploit In-Reply-To: <20020111165156.A21636@lucent.com>; from dwd@bell-labs.com on Fri, Jan 11, 2002 at 04:51:56PM -0600 References: <20020110134029.A17525@lucent.com> <20020111090857.GA25502@faui02> <20020111165156.A21636@lucent.com> Message-ID: <20020112002220.A18140@pianosa.catch22.org> On Fri, Jan 11, 2002 at 04:51:56PM -0600, Dave Dykstra wrote: > That would be of some help; make the warning stronger if there is a known > key of another type. Hey, for that matter why not print out the big > warning that somebody could be doing something nasty? It's really no > different if somebody has exchanged one RSA key for another than if they've > exchange one RSA key for a DSA key. Right? That would be a simple fix. It is different. In once case, you have unverified credentials, in another case you have clearly wrong credentials. Some people have been lazy about generating ssh2 rsa keys you know :) -- David Terrell | "Anyone who says that is woefully Prime Minister, Nebcorp | underinformed. IE, reads usenet." dbt at meat.net | - Sean O'Connor http://wwn.nebcorp.com/ From markus at openbsd.org Sun Jan 13 01:05:00 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 12 Jan 2002 15:05:00 +0100 Subject: automate SFTP In-Reply-To: <48256B3F.0006E09C.00@mail.1-net.com.sg>; from chuayl@1-net.com.sg on Sat, Jan 12, 2002 at 09:15:06AM +0800 References: <48256B3F.0006E09C.00@mail.1-net.com.sg> Message-ID: <20020112150500.A7435@folly> sftp -b ? From cshobe at softhome.net Sun Jan 13 10:53:56 2002 From: cshobe at softhome.net (Casey Allen Shobe) Date: Sat, 12 Jan 2002 18:53:56 -0500 Subject: No shell prompt presented on SSH connection Message-ID: I just installed OpenSSH-3.0.2pl1 on a new machine, but am unable to use it. SCP works, ssh outbound works, and ssh inbound appears to work but I never get a prompt. The password authentication works... The output of ssh -vv from a client machine is exactly the same as the output when connecting to a machine where I do get a prompt, so it must be something outside of the ssh connection itself. Does anyone know where to look? Thanks, -- Casey Allen Shobe cshobe at softhome.net 'Why do people with closed minds always open their mouths?' From cshobe at softhome.net Sun Jan 13 17:27:04 2002 From: cshobe at softhome.net (Casey Allen Shobe) Date: Sun, 13 Jan 2002 01:27:04 -0500 Subject: No shell prompt presented on SSH connection In-Reply-To: References: Message-ID: On Saturday 12 January 2002 06:53 pm, Casey Allen Shobe wrote: > I just installed OpenSSH-3.0.2pl1 on a new machine, but am unable to use > it. SCP works, ssh outbound works, and ssh inbound appears to work but I > never get a prompt. The password authentication works... Nevermind, I fixed this myself. I was using devpts in the kernel, but hadn't specified in /etc/fstab that /dev/pts needed mounted. Sorry for the inconvenience! -- Casey Allen Shobe cshobe at softhome.net 'Why do people with closed minds always open their mouths?' From Greg.Scheidel at ed.gov Mon Jan 14 00:10:24 2002 From: Greg.Scheidel at ed.gov (Scheidel, Greg (Contractor)) Date: Sun, 13 Jan 2002 08:10:24 -0500 Subject: automate SFTP Message-ID: <2E3AC3356942D511B8A30008C7AAAC0804CCF103@wdcrobexc10.ed.gov> > Is there anyway to automate a command line > SFTP to transfer files to a SSH Server. You may want to check out using rsync over ssh. http://samba.anu.edu.au/rsync/index.html http://samba.anu.edu.au/ftp/rsync/rsync.html http://rsync.samba.org/rsync/fom-serve/cache/38.html Greg S. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020113/c44fb8c2/attachment.html From Greg.Scheidel at ed.gov Mon Jan 14 00:11:02 2002 From: Greg.Scheidel at ed.gov (Scheidel, Greg (Contractor)) Date: Sun, 13 Jan 2002 08:11:02 -0500 Subject: automate SFTP Message-ID: <2E3AC3356942D511B8A30008C7AAAC0804CCF104@wdcrobexc10.ed.gov> > Is there anyway to automate a command line > SFTP to transfer files to a SSH Server. You may want to check out using rsync over ssh. http://samba.anu.edu.au/rsync/index.html http://samba.anu.edu.au/ftp/rsync/rsync.html http://rsync.samba.org/rsync/fom-serve/cache/38.html Greg S. From mjt at tls.msk.ru Mon Jan 14 08:31:15 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 14 Jan 2002 00:31:15 +0300 Subject: No shell prompt presented on SSH connection References: Message-ID: <3C41FCA3.107EDE01@tls.msk.ru> Casey Allen Shobe wrote: > > On Saturday 12 January 2002 06:53 pm, Casey Allen Shobe wrote: > > I just installed OpenSSH-3.0.2pl1 on a new machine, but am unable to use > > it. SCP works, ssh outbound works, and ssh inbound appears to work but I > > never get a prompt. The password authentication works... > > Nevermind, I fixed this myself. I was using devpts in the kernel, but hadn't > specified in /etc/fstab that /dev/pts needed mounted. Hey, devfs provides devpts! You can still mount it over devfs, but that shouldn't be a requiriment. If I got devfs right -- I looked into it over a year ago, that time ssh worked without devpts just fine for me, and /dev/pts/* was here. Regards, Michael. From mjt at tls.msk.ru Mon Jan 14 08:51:39 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 14 Jan 2002 00:51:39 +0300 Subject: Public storage for public keys Message-ID: <3C42016B.C8C7414E@tls.msk.ru> This question should be asked before, but I fail to find the discussion. What options can be used for storing host/users pubkeys in a publically available places? I know openssh currently provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. But what about many machines? Think of e.g. pgp keyservers. Note that pgp keyservers isn't a good solution *always*. The best one IMHO will be to use a mechanism similar to name service switch (as found on solaris and now on linux/glibc, and on other systems as well). Sometimes, even this nsswitch mechanism can be used directly, by extending it for ssh needs (while nss api is known). There will be private module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, nis, ldap, db etc. Especially useful here is ldap, as it has more and more usages/deployments and was designed to store such kind of information. Even DNS can be used here (trusted, i.e. local, ofcourse)! Can something like this be done? (No, I don't ask to implement such a mechanism, but about possibilities of an "idea")? Regards, Michael. From fcusack at fcusack.com Mon Jan 14 09:38:31 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 13 Jan 2002 14:38:31 -0800 Subject: Public storage for public keys In-Reply-To: <3C42016B.C8C7414E@tls.msk.ru>; from mjt@tls.msk.ru on Mon, Jan 14, 2002 at 12:51:39AM +0300 References: <3C42016B.C8C7414E@tls.msk.ru> Message-ID: <20020113143831.B14544@google.com> On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote: > What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? > [...] > > Can something like this be done? (No, I don't ask to implement > such a mechanism, but about possibilities of an "idea")? There is a significant trust problem. You can't store pubkeys in places that are untrustworthy, like DNS, LDAP, unless you sign the keys. Which introduces a bunch of other problems. /fc From dbt at meat.net Mon Jan 14 16:56:39 2002 From: dbt at meat.net (David Terrell) Date: Sun, 13 Jan 2002 21:56:39 -0800 Subject: Public storage for public keys In-Reply-To: <3C42016B.C8C7414E@tls.msk.ru>; from mjt@tls.msk.ru on Mon, Jan 14, 2002 at 12:51:39AM +0300 References: <3C42016B.C8C7414E@tls.msk.ru> Message-ID: <20020113215639.A12607@pianosa.catch22.org> On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote: > This question should be asked before, but I fail to find > the discussion. > > What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? > > Think of e.g. pgp keyservers. Note that pgp keyservers isn't > a good solution *always*. The best one IMHO will be to use > a mechanism similar to name service switch (as found on solaris > and now on linux/glibc, and on other systems as well). Sometimes, > even this nsswitch mechanism can be used directly, by extending > it for ssh needs (while nss api is known). There will be private > module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, > nis, ldap, db etc. Especially useful here is ldap, as it has more > and more usages/deployments and was designed to store such kind > of information. Even DNS can be used here (trusted, i.e. local, > ofcourse)! There was a spec to use DNS KEY records written for the secsh wg at one point, but that draft was withdrawn and there is some serious opposition to using DNS KEY records for application keys within DNSEXT. That debate has not yet been resolved. You could use LDAP. SSH is kind of a maverick as far as using OS provided resources for this kind of thing, though. I'm not at all interested in reinventing, say, NIS+. Or even kerberos. -- David Terrell | "the only part about medicinal marijuana that Prime Minister, Nebcorp | bothers me is that, when I started chemo, all of dbt at meat.net | my children and grandchildren told me they could http://wwn.nebcorp.com/ | get some for me if I needed it." -mrw's grandfather From bugzilla-daemon at mindrot.org Mon Jan 14 18:41:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 18:41:38 +1100 (EST) Subject: [Bug 67] New: Test bug Message-ID: <20020114074138.8DF61E935@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=67 Summary: Test bug Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: djm at mindrot.org This is to test emailling of bugs to the list. ------- Additional Comments From djm at mindrot.org 2002-01-14 18:37 ------- Testing again ------- Additional Comments From djm at mindrot.org 2002-01-14 18:38 ------- again ------- Additional Comments From djm at mindrot.org 2002-01-14 18:41 ------- once more ------- 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 Jan 14 19:03:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:03:22 +1100 (EST) Subject: [Bug 50] Couldn't open random pool "yes": No such file or directory Message-ID: <20020114080322.8ABEDE93C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=50 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |minor Status|NEW |RESOLVED OS/Version|Solaris |All Platform|Sparc |All Resolution| |FIXED Version|3.0p1 |-current ------- Additional Comments From djm at mindrot.org 2002-01-14 19:03 ------- Fixed in -current. The --with-random and --with-prngd-socket now check that their argument is an absolute path. They will also warn (but not fail) if the path specified in the argument is not readable. ------- 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 Jan 14 19:12:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:12:16 +1100 (EST) Subject: [Bug 66] New: $HOME/authorized_keys not read by sshd Message-ID: <20020114081216.E6398E93D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=66 Summary: $HOME/authorized_keys not read by sshd Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: openssh_bugs at pongonova.net sshd does not appear to read authorized_keys2 during connection attempt from ssh client. This was verified on both a Solaris system running SSH-2.0-OpenSSH_2.9p2 and a Linux system running current version of sshd. Resolution of the problem was accomplished by creating a link from authorized_keys2 to authorized_keys. Current manpage does not mention authorized_keys2, and the ChangeLog seems to indicate authorized_keys2 has been deprecated, yet it appears to still be required for Protocol 2 connections. ------- Additional Comments From djm at mindrot.org 2002-01-14 19:12 ------- authorized_keys2 is required if you are running an old sshd (<2.9.9 IIRC). Newer sshd's do not require authorized_keys2, but still check it for backwards compatability - it is certainly not a requirement. ------- 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 Jan 14 19:14:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:14:54 +1100 (EST) Subject: [Bug 67] Test bug Message-ID: <20020114081454.3C16FE947@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=67 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2002-01-14 19:14 ------- Email seems to be working again - I broke it with a Bugzilla security upgrade. Apologies. ------- 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 Jan 14 19:21:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:21:58 +1100 (EST) Subject: [Bug 57] make: #error "No DATAMODEL_NATIVE specified" Message-ID: <20020114082158.9DE7AE93D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=57 ------- Additional Comments From djm at mindrot.org 2002-01-14 19:21 ------- This looks like a broken gcc installation ------- 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 Jan 14 19:28:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:28:57 +1100 (EST) Subject: [Bug 60] OpenSSH 3.0.2p1 configure script fails on NEXTSTEP Message-ID: <20020114082857.EB297E94C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=60 ------- Additional Comments From djm at mindrot.org 2002-01-14 19:28 ------- Why / where is this needed? Can you show an example of a failed build. This may be an autoconf bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Jan 14 19:41:34 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 14 Jan 2002 09:41:34 +0100 Subject: Public storage for public keys In-Reply-To: <3C42016B.C8C7414E@tls.msk.ru> References: <3C42016B.C8C7414E@tls.msk.ru> Message-ID: <20020114084134.GA29020@faui02> how can you trust ldap? or dns? On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote: > This question should be asked before, but I fail to find > the discussion. > > What options can be used for storing host/users pubkeys in > a publically available places? I know openssh currently > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > But what about many machines? > > Think of e.g. pgp keyservers. Note that pgp keyservers isn't > a good solution *always*. The best one IMHO will be to use > a mechanism similar to name service switch (as found on solaris > and now on linux/glibc, and on other systems as well). Sometimes, > even this nsswitch mechanism can be used directly, by extending > it for ssh needs (while nss api is known). There will be private > module for ~/.ssh/known_hosts, `files' module for /etc/ssh_known_hosts, > nis, ldap, db etc. Especially useful here is ldap, as it has more > and more usages/deployments and was designed to store such kind > of information. Even DNS can be used here (trusted, i.e. local, > ofcourse)! > > Can something like this be done? (No, I don't ask to implement > such a mechanism, but about possibilities of an "idea")? > > Regards, > Michael. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Mon Jan 14 19:57:04 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:57:04 +1100 (EST) Subject: [Bug 46] patches between portability revisions Message-ID: <20020114085704.EB4BBE956@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=46 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Version|3.0.2p1 |-current ------- Additional Comments From djm at mindrot.org 2002-01-14 19:57 ------- I'll look into doing it in our release scripts. You should consider using anonymous CVS to stay up to date. Details are at: http://www.openssh.com/portable.html ------- 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 Jan 14 19:59:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 19:59:36 +1100 (EST) Subject: [Bug 39] segmentation violations & bus errors Message-ID: <20020114085936.3E1BAE95C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=39 ------- Additional Comments From djm at mindrot.org 2002-01-14 19:59 ------- Please also try the latest patch release (0.9.6c) of OpenSSL ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jakob at crt.se Mon Jan 14 22:26:31 2002 From: jakob at crt.se (Jakob Schlyter) Date: Mon, 14 Jan 2002 12:26:31 +0100 (MET) Subject: Public storage for public keys In-Reply-To: <20020114084134.GA29020@faui02> Message-ID: On Mon, 14 Jan 2002, Markus Friedl wrote: > how can you trust ldap? LDAP over TLS could be usable. not very scalable though. > or dns? DNSsec. very scalable. jakob From bugzilla-daemon at mindrot.org Mon Jan 14 23:54:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 14 Jan 2002 23:54:25 +1100 (EST) Subject: [Bug 60] OpenSSH 3.0.2p1 configure script fails on NEXTSTEP Message-ID: <20020114125425.34D9DE95D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=60 ------- Additional Comments From abe at purdue.edu 2002-01-14 23:54 ------- Created an attachment (id=9) Example of the bug and supporting information ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mjt at tls.msk.ru Tue Jan 15 07:25:45 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 14 Jan 2002 23:25:45 +0300 Subject: Public storage for public keys References: <3C42016B.C8C7414E@tls.msk.ru> <20020113143831.B14544@google.com> Message-ID: <3C433EC9.4E92AD53@tls.msk.ru> Frank Cusack wrote: > > On Mon, Jan 14, 2002 at 12:51:39AM +0300, Michael Tokarev wrote: > > What options can be used for storing host/users pubkeys in > > a publically available places? I know openssh currently > > provide option except if /etc/ssh_known_hosts and ~/.ssh/known_hosts. > > But what about many machines? > > > [...] > > > > Can something like this be done? (No, I don't ask to implement > > such a mechanism, but about possibilities of an "idea")? > > There is a significant trust problem. You can't store pubkeys in > places that are untrustworthy, like DNS, LDAP, unless you sign the keys. > Which introduces a bunch of other problems. Can you trust LDAP when doing auth requests to it, using e.g. pam_ldap? Well, this is somewhat different, since pam_ldap usually runs as root and have access to more information than available to a regular user. As was already pointed out, with ldap, there are other ways of secure communication are available -- e.g. via TLS. The same is for DNS. There are another, rather common, situations exists also -- imagine a trusted local area network with a common database server in it (be it e.g. nis server), and another network -- an ssh connection target. There is another issue with current ssh behaviour as well -- right the opposite one. For example, in our network there are several servers where I have shell accounts (actually, I'm an administrator of the whole network!). I once connected from one of those servers to a target machine, ssh asked me if I want to connect to a host that can't be verified -- that's fine. Now I tries to connect to the same host from another our machine -- the same question. When from another -- again. Well, after several such question about *the same* target host, my attention is lost. Next time ssh will ask this question, I'll think "aha, I wasn't connected to this host from this machine yet, and "stupid" ssh can't figure out that other our machines already knows this host. Oh well, so hit "y" and don't worry about that anymore, it's enouth already!". Now think about man-in- the-middle at *this* point. Well yes, I know, there are other ways exists to distribute "global" (in a lan sense) /etc/ssh_known_hosts file. But I need to do this manually each time I'll connect to a new target host. But the question was in fact somewhat different. It wasn't about security and how secure various sources are, but about a *possibility* to use something like nss for pubkeys storage. Every installation or site will decide what is usable/acceptable/secure/whatether in their sense (after all, nfs-mounted homedir with ~/.ssh/ssh_known_hosts (no, I don't tell here about ~/.ssh/identify w/o password!) can't be "secure" either!). There ARE secure methods esists and used already for other means. Regards, Michael. From mjt at tls.msk.ru Tue Jan 15 07:33:00 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 14 Jan 2002 23:33:00 +0300 Subject: Public storage for public keys References: Message-ID: <3C43407C.3173BD4@tls.msk.ru> Jakob Schlyter wrote: > > On Mon, 14 Jan 2002, Markus Friedl wrote: > > > how can you trust ldap? > > LDAP over TLS could be usable. not very scalable though. There is no need to have scalable backend for this sort of things. Regards, Michael. From mjt at tls.msk.ru Tue Jan 15 07:42:07 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Mon, 14 Jan 2002 23:42:07 +0300 Subject: Public storage for public keys References: <3C42016B.C8C7414E@tls.msk.ru> <20020114084134.GA29020@faui02> Message-ID: <3C43429F.45AD3D48@tls.msk.ru> Markus Friedl wrote: > > how can you trust ldap? or dns? How you can trust public pgp keyservers? On another side, for storing *public* keys, there is no *real* need to be *so* suspicious. Saved pubkeys protects from man-in-the-middle attacks. If a key stored in some other place, that "middle-man" need to break a naming service (e.g. dns) of *target* host *and* your local naming service and/or pubkey storage (depending on how this is organized). Those two breakdowns should happen at the same time as your connection attempt to a target host. Well, it IS possible to research and implement such an attack, but an attacker should be really mad trying to hijaak your data. And in this case, your information should be VERY needed by an attacker -- in this case of so interesting information, extra security layers should be in place anyway, and *untrusted* dns/ldap/whatether should NOT be used for key storage either. A sort of -- I know, there are attackers exists who does their job for fun only for example. But imagine e.g. local dns server that handles local zones (and another one that talks with the world) -- I see no reason to NOT trust this local dns server (if configured properly). After all, if that dns server will be cracked, an intruder probably will be able to change /etc/ or ~/.ssh/ files as well. Regards, Michael. From datqtruong at yahoo.com Tue Jan 15 08:35:48 2002 From: datqtruong at yahoo.com (dat truong) Date: Mon, 14 Jan 2002 13:35:48 -0800 (PST) Subject: OpenSSH 3.0.2p1 and tcp wrappers on hp-ux 11i Message-ID: <20020114213548.15814.qmail@web14505.mail.yahoo.com> hi all, does anyone compile OpenSSH verion 3.0.2p1 on HP-UX 11i with TCP WRAPPERS option enabled? It keeps saying that libwrap.a missing. i do have libwrap.a installed under /usr/lib as well as /lib. I also have tcpd.h under /usr/include. any idea anyone? thanks in advance. --Dat Truong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From sxw at dcs.ed.ac.uk Tue Jan 15 08:38:40 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Mon, 14 Jan 2002 21:38:40 +0000 (GMT) Subject: Public storage for public keys In-Reply-To: <20020114084134.GA29020@faui02> Message-ID: On Mon, 14 Jan 2002, Markus Friedl wrote: > how can you trust ldap? or dns? In the LDAP case, you use a connection method that securely authenticates the server. The two obvious options here are Kerberos or TLS. Of course, if you're using Kerberos you can just use GSSAPI key exchange, and you don't need to distribute your public keys, but thats another can of worms. I've got code that pushes both ssh v1 and v2 keys into LDAP and uses this to maintain known hosts maps. I've been promising to package this up and distribute it for ages - its now nearing the top of my list. Cheers, Simon. From fcusack at fcusack.com Tue Jan 15 08:45:19 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 14 Jan 2002 13:45:19 -0800 Subject: Public storage for public keys In-Reply-To: <3C43429F.45AD3D48@tls.msk.ru>; from mjt@tls.msk.ru on Mon, Jan 14, 2002 at 11:42:07PM +0300 References: <3C42016B.C8C7414E@tls.msk.ru> <20020114084134.GA29020@faui02> <3C43429F.45AD3D48@tls.msk.ru> Message-ID: <20020114134518.C21767@google.com> On Mon, Jan 14, 2002 at 11:42:07PM +0300, Michael Tokarev wrote: > Markus Friedl wrote: > > > > how can you trust ldap? or dns? > > How you can trust public pgp keyservers? > > On another side, for storing *public* keys, there is no > *real* need to be *so* suspicious. Storing pgp keys is a completely different animal. pgp has it's own trust model and doesn't depend on the trustworthiness of the key distribution. ssh keys, on the other hand, do not have this quality. > Saved pubkeys protects from man-in-the-middle attacks. Yes, saved in a trusted location (ie, local file system). A key in DNS is not trustworthy, since DNS is easily compromised. /fc From pekkas at netcore.fi Tue Jan 15 08:45:33 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 14 Jan 2002 23:45:33 +0200 (EET) Subject: Public storage for public keys In-Reply-To: <3C433EC9.4E92AD53@tls.msk.ru> Message-ID: On Mon, 14 Jan 2002, Michael Tokarev wrote: > Well yes, I know, there are other ways exists to distribute "global" > (in a lan sense) /etc/ssh_known_hosts file. But I need to do this > manually each time I'll connect to a new target host. FWIW, we push a global known_hosts files to all the systems nightly. Works rather nicely. > But the question was in fact somewhat different. It wasn't about > security and how secure various sources are, but about a *possibility* > to use something like nss for pubkeys storage. Every installation > or site will decide what is usable/acceptable/secure/whatether in > their sense (after all, nfs-mounted homedir with ~/.ssh/ssh_known_hosts > (no, I don't tell here about ~/.ssh/identify w/o password!) can't be > "secure" either!). There ARE secure methods esists and used already > for other means. A "solution" for this is to keep personal known_hosts files small, and from time to time, "harvest" them all in one place, combine them with uniq(1) and update the global file. Perhaps not the best approach, but at least it's almost manageable. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus at openbsd.org Tue Jan 15 08:59:14 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 14 Jan 2002 22:59:14 +0100 Subject: Public storage for public keys In-Reply-To: <3C433EC9.4E92AD53@tls.msk.ru> References: <3C42016B.C8C7414E@tls.msk.ru> <20020113143831.B14544@google.com> <3C433EC9.4E92AD53@tls.msk.ru> Message-ID: <20020114215914.GC2054@faui02> On Mon, Jan 14, 2002 at 11:25:45PM +0300, Michael Tokarev wrote: > There are another, rather common, situations exists also -- imagine a > trusted local area network with a common database server in it (be > it e.g. nis server), and another network -- an ssh connection target. we used rdist over ssh to distribute /etc/ssh_known_hosts From markus at openbsd.org Tue Jan 15 08:59:49 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 14 Jan 2002 22:59:49 +0100 Subject: Public storage for public keys In-Reply-To: <3C43429F.45AD3D48@tls.msk.ru>; from mjt@tls.msk.ru on Mon, Jan 14, 2002 at 11:42:07PM +0300 References: <3C42016B.C8C7414E@tls.msk.ru> <20020114084134.GA29020@faui02> <3C43429F.45AD3D48@tls.msk.ru> Message-ID: <20020114225949.A2877@folly> On Mon, Jan 14, 2002 at 11:42:07PM +0300, Michael Tokarev wrote: > Markus Friedl wrote: > > > > how can you trust ldap? or dns? > > How you can trust public pgp keyservers? public keys != public keys. From fcusack at fcusack.com Tue Jan 15 09:09:10 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 14 Jan 2002 14:09:10 -0800 Subject: Public storage for public keys In-Reply-To: <20020114134518.C21767@google.com>; from fcusack@fcusack.com on Mon, Jan 14, 2002 at 01:45:19PM -0800 References: <3C42016B.C8C7414E@tls.msk.ru> <20020114084134.GA29020@faui02> <3C43429F.45AD3D48@tls.msk.ru> <20020114134518.C21767@google.com> Message-ID: <20020114140910.I21767@google.com> On Mon, Jan 14, 2002 at 01:45:19PM -0800, Frank Cusack wrote: > On Mon, Jan 14, 2002 at 11:42:07PM +0300, Michael Tokarev wrote: > > On another side, for storing *public* keys, there is no > > *real* need to be *so* suspicious. I see in my previous email I didn't actually respond to this statement. *Yes* there is a *real* need to be suspicious for *public* keys. If you blindly trust the public key, you expose yourself to MITM attacks. This is a significant problem in ssh. That is why PGP has its own trust model. That is why (eg) X.509 certs must be signed. /fc From ed at UDel.Edu Tue Jan 15 09:10:12 2002 From: ed at UDel.Edu (Ed Phillips) Date: Mon, 14 Jan 2002 17:10:12 -0500 (EST) Subject: Public storage for public keys In-Reply-To: Message-ID: On Mon, 14 Jan 2002, Simon Wilkinson wrote: > Date: Mon, 14 Jan 2002 21:38:40 +0000 (GMT) > From: Simon Wilkinson > To: openssh-unix-dev at mindrot.org > Subject: Re: Public storage for public keys > > On Mon, 14 Jan 2002, Markus Friedl wrote: > > > how can you trust ldap? or dns? > > In the LDAP case, you use a connection method that securely authenticates > the server. The two obvious options here are Kerberos or TLS. Of course, > if you're using Kerberos you can just use GSSAPI key exchange, and you > don't need to distribute your public keys, but thats another can of worms. > > I've got code that pushes both ssh v1 and v2 keys into LDAP and uses this > to maintain known hosts maps. I've been promising to package this up and > distribute it for ages - its now nearing the top of my list. That would be nice... ssh could query the LDAP directory to decide if sshd on the server side is who it claims to be, instead of looking in ~/.ssh/known_hosts. Very nice... especially for sites where there are many server keys that ssh must verify. What attribute do you use in your code for storing host public keys in the LDAP directory? What class(es) do you use for the "known_hosts" entries that hold these attribute values? Are these custom-defined attributes/classes or has someone already done this and put it in an RFC? I was thinking about the possibilty of putting public keys for users into an LDAP directory so that users would be able to use RSA authenticatation to login to a server... but insteaf of sshd using ~/.ssh/authorized_keys on the server side, it would fetch the user's public key from the directory. Have you tried implementing anything like this? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Tue Jan 15 09:15:22 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 14 Jan 2002 23:15:22 +0100 Subject: Public storage for public keys In-Reply-To: <20020114140910.I21767@google.com> References: <3C42016B.C8C7414E@tls.msk.ru> <20020114084134.GA29020@faui02> <3C43429F.45AD3D48@tls.msk.ru> <20020114134518.C21767@google.com> <20020114140910.I21767@google.com> Message-ID: <20020114221521.GA4105@faui02> On Mon, Jan 14, 2002 at 02:09:10PM -0800, Frank Cusack wrote: > On Mon, Jan 14, 2002 at 01:45:19PM -0800, Frank Cusack wrote: > > On Mon, Jan 14, 2002 at 11:42:07PM +0300, Michael Tokarev wrote: > > > On another side, for storing *public* keys, there is no > > > *real* need to be *so* suspicious. > > I see in my previous email I didn't actually respond to this statement. > *Yes* there is a *real* need to be suspicious for *public* keys. If > you blindly trust the public key, you expose yourself to MITM attacks. > > This is a significant problem in ssh. > > That is why PGP has its own trust model. That is why (eg) X.509 certs > must be signed. that is why users ignore X.509 certs and click ok? :) From ed at UDel.Edu Tue Jan 15 09:26:01 2002 From: ed at UDel.Edu (Ed Phillips) Date: Mon, 14 Jan 2002 17:26:01 -0500 (EST) Subject: Public storage for public keys In-Reply-To: <20020114134518.C21767@google.com> Message-ID: On Mon, 14 Jan 2002, Frank Cusack wrote: > Date: Mon, 14 Jan 2002 13:45:19 -0800 > From: Frank Cusack > To: Michael Tokarev > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Public storage for public keys > > On Mon, Jan 14, 2002 at 11:42:07PM +0300, Michael Tokarev wrote: > > Markus Friedl wrote: > > > > > > how can you trust ldap? or dns? > > > > How you can trust public pgp keyservers? > > > > On another side, for storing *public* keys, there is no > > *real* need to be *so* suspicious. > > Storing pgp keys is a completely different animal. pgp has it's > own trust model and doesn't depend on the trustworthiness of the > key distribution. ssh keys, on the other hand, do not have > this quality. > > > Saved pubkeys protects from man-in-the-middle attacks. > > Yes, saved in a trusted location (ie, local file system). > A key in DNS is not trustworthy, since DNS is easily > compromised. Just for giggles, let's say we're distributing public host keys via DNS, and JH (Joe Hacker) is trying to use this as an advantage to break into a system that is trusting the DNS-supplied public keys. In order to cause a compromise, JH would need to somehow convince a system running the ssh client (system A) that the sshd server it THOUGHT it was connecting to (system B) is the real thing when really it is not. In order to do this, JH would have to first, intercept DNS traffic from A DNS and return a spoofed public host key for system B (okay - that should be easy enough for JH). Then the hard part - JH would have to play man-in-the-middle between A and B enough to convince A that the spoofed host key for B is okay... but how can JH do this without knowing the REAL private host key for system B? What am I missing? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From tim at mcgarry.ch Tue Jan 15 09:27:25 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Mon, 14 Jan 2002 23:27:25 +0100 Subject: Should sshd be fixed to handle NIS+ keylogin Message-ID: <004b01c19d4a$a85889c0$c902a8c0@cablecom.ch> To get around the problem of having to change the root password every time a sys admin leaves the organization Solaris is hardened as follows. in /etc/default login. CONSOLE= Restricted permissions on su so only certain groups can run it. That way its really difficult to log in as root even if the root password is known. For OpenSSH PermitRootLogin is set to without-password and a key is added to the authorized_keys file for each sysadmin. BUT if in sshd_config UseLogin is set to yes then RSA keys cannot be used to get in as root. If UseLogin is set to no then sshd doesn't do the keylogin, therefore, no home directory (dh Secured NFS). and resticted access to the NIS+ maps. Should sshd be fixed to handle the keylogin. (Obviously this could only work with password auth) Tim McGarry From gem at rellim.com Tue Jan 15 09:47:08 2002 From: gem at rellim.com (Gary E. Miller) Date: Mon, 14 Jan 2002 14:47:08 -0800 (PST) Subject: Public storage for public keys In-Reply-To: Message-ID: Yo Ed! No need to intercept DNS traffic. All you have to do is get the victim DNS server to visit the hijackers DNS server. The hijacker puts a bogus glue record on his DNS server. Then gets the victim's DNS to do a legit DNS query to his DNS server. Maybe he does a telnet or ftp to the victim host and when the victim host does the reverse DNS check it goes to the hijackers DNS server. The hijackers DNS server then returns legit answer to the legit request and also returns the bogus glue record. A while back a guy did this and was sending out new NS records for ICANN. He was able to hijack the entire ICANN domain on all his victims this way. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Mon, 14 Jan 2002, Ed Phillips wrote: > Just for giggles, let's say we're distributing public host keys via DNS, > and JH (Joe Hacker) is trying to use this as an advantage to break into a > system that is trusting the DNS-supplied public keys. In order to cause a > compromise, JH would need to somehow convince a system running the ssh > client (system A) that the sshd server it THOUGHT it was connecting to > (system B) is the real thing when really it is not. In order to do this, > JH would have to first, intercept DNS traffic from A DNS and return a > spoofed public host key for system B (okay - that should be easy enough > for JH). Then the hard part - JH would have to play man-in-the-middle > between A and B enough to convince A that the spoofed host key for B is > okay... but how can JH do this without knowing the REAL private host key > for system B? What am I missing? From Darren.Moffat at Sun.COM Tue Jan 15 10:01:51 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 14 Jan 2002 15:01:51 -0800 Subject: Should sshd be fixed to handle NIS+ keylogin References: <004b01c19d4a$a85889c0$c902a8c0@cablecom.ch> Message-ID: <3C43635F.3020102@Sun.COM> > then sshd doesn't do the keylogin, therefore, no home directory (dh Secured > NFS). and resticted access to the NIS+ maps. > > Should sshd be fixed to handle the keylogin. (Obviously this could only work > with password auth) keylogin is handled by pam_unix on Solaris and since sshd always calls pam_setcred if it was built with PAM support this should just work. If you want AUTH_DH secured NFS then you can't use publickey authenticatio with sshd since you need to supply your secure rpc key (which is usually the same as your login password). -- Darren J Moffat From fcusack at fcusack.com Tue Jan 15 10:03:21 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 14 Jan 2002 15:03:21 -0800 Subject: Public storage for public keys In-Reply-To: ; from ed@udel.edu on Mon, Jan 14, 2002 at 05:26:01PM -0500 References: <20020114134518.C21767@google.com> Message-ID: <20020114150321.J21767@google.com> On Mon, Jan 14, 2002 at 05:26:01PM -0500, Ed Phillips wrote: > JH would have to first, intercept DNS traffic from A DNS and return a > spoofed public host key for system B (okay - that should be easy enough > for JH). Then the hard part - JH would have to play man-in-the-middle > between A and B enough to convince A that the spoofed host key for B is > okay... but how can JH do this without knowing the REAL private host key > for system B? What am I missing? The proposal is that the ssh client trusts the public key provided by DNS. An attacker would send his own IP address and public key in a spoofed (or poisoned) DNS reply. /fc From tim at mcgarry.ch Tue Jan 15 10:14:52 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 15 Jan 2002 00:14:52 +0100 Subject: Should sshd be fixed to handle NIS+ keylogin References: <004b01c19d4a$a85889c0$c902a8c0@cablecom.ch> <3C43635F.3020102@Sun.COM> Message-ID: <012c01c19d51$45d3ba20$c902a8c0@cablecom.ch> ----- Original Message ----- From: "Darren J Moffat" To: "Tim McGarry" Cc: Sent: Tuesday, January 15, 2002 12:01 AM Subject: Re: Should sshd be fixed to handle NIS+ keylogin > > then sshd doesn't do the keylogin, therefore, no home directory (dh Secured > > NFS). and resticted access to the NIS+ maps. > > > > Should sshd be fixed to handle the keylogin. (Obviously this could only work > > with password auth) > > > keylogin is handled by pam_unix on Solaris and since sshd always calls > pam_setcred if it was built with PAM support this should just work. It re-check why it doesn't work in my case (Solaris 2.6/OpenSSH 3.0.2p1 built --with-pam) -Anyone got any ideas what may be wrong? > > > If you want AUTH_DH secured NFS then you can't use publickey > authenticatio with sshd since you need to supply your secure rpc key > (which is usually the same as your login password). Obviously the clients can't use ~/.ssh/authorized_keys if ~ is on secure NFS (well not the first time/but once the keyserver has the key subsequent connections work) This is not a problem, since OpenSSH started allowing the authorized_keys file location to be defined, Its simple to use another location eg /etc/authorized_keys/%u. The keylogin is important for interactive sessions, because I really want my home-directory, RSA logins are often just batch jobs so getting the creds is (in my case) not so important. > > -- > Darren J Moffat > From jason at shalott.net Tue Jan 15 10:24:08 2002 From: jason at shalott.net (Jason Stone) Date: Mon, 14 Jan 2002 15:24:08 -0800 (PST) Subject: Public storage for public keys In-Reply-To: Message-ID: <20020114151234.G30233-100000@walter> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Yes, saved in a trusted location (ie, local file system). > > A key in DNS is not trustworthy, since DNS is easily > > compromised. > > Then the hard part - JH would have to play man-in-the-middle between A > and B enough to convince A that the spoofed host key for B is okay... > but how can JH do this without knowing the REAL private host key for > system B? What am I missing? No, JH doesn't have to know B's private key - that's the point. A doesn't know B's public key ('cause this whole discussion is about how to give it to him), so JH gets in the middle of A and B (check out dsniff, ettercap, etc - this is real easy nowadays), and when A asks for B's public key, JH hands his own public key to A. Now A encrypts all his packets with JH's key and sends them to JH. JH then requests B's public key, decrypts all of A's packets, re-encrypts them with B's public key, and passes them on to B. Neither A nor B realizes, because at a fundamental level, they don't _really_ know each other if they haven't already exchanged keys and cached them locally. Man-in-the-middle attacks are no longer strictly theoretical, nor reserved for hardcore hackers. Easy and powerful tools are widely available to let just anyone perform active attacks against a local net, even a switched one, and shoddy key exchange is completely unacceptable. You _could_ use DNSSEC to distribute the keys, and I'm interested in why this ended up being rejected? -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE8Q2icswXMWWtptckRAnDRAJ9RxSqC5tMlyC6/2PHAEZg9yL68SACcCF2K DJd8KB7+Q1PFQP+BZgynM48= =CKKQ -----END PGP SIGNATURE----- From sxw at dcs.ed.ac.uk Tue Jan 15 10:34:16 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Mon, 14 Jan 2002 23:34:16 +0000 Subject: Public storage for public keys In-Reply-To: References: Message-ID: <02011423341600.09330@loki.dcs.ed.ac.uk> On Monday 14 January 2002 22:10, Ed Phillips wrote: > That would be nice... ssh could query the LDAP directory to decide if sshd > on the server side is who it claims to be, instead of looking in > ~/.ssh/known_hosts. At present we just build a known_hosts file out of the LDAP map at regular intervals. It would be nice to have an interface for the ssh client to query this directly (perhaps via a helper program, similar to LPRng's filterfile function?) > Very nice... especially for sites where there are many server keys that ssh must verify. > > What attribute do you use in your code for storing host public keys in the > LDAP directory? I'm in the process of writing a draft that details what we're doing here. Basically we use the 'sshKey' attribute, with an OID out of our enterprise space. This attribute contains the public key in the format of the known hosts file. > What class(es) do you use for the "known_hosts" entries > that hold these attribute values? I've defined a supplemental class which we use with the RFC2306 ipHost class. It's possible that other definitions which don't require organizations to have a 2306 based directory structure would be possible (and better!) > Are these custom-defined > attributes/classes or has someone already done this and put it in an RFC? Currently custom defined, although documenting it all is very high up my list! I've been asked by a number of people to write all of this up as an Internet-Draft, which I'm doing currently. > I was thinking about the possibilty of putting public keys for users into > an LDAP directory so that users would be able to use RSA authenticatation > to login to a server... but insteaf of sshd using ~/.ssh/authorized_keys > on the server side, it would fetch the user's public key from the > directory. Have you tried implementing anything like this? No. We're using Kerberos for our secure authentication - using LDAP as a means of distributing keys was devised as a means of supporting our legacy systems. Cheers, Simon. From tim at mcgarry.ch Tue Jan 15 11:09:44 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 15 Jan 2002 01:09:44 +0100 Subject: ssh-agent too easy to hack Message-ID: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> 1/ Most correctly configured unix servers are fairly secure. Workstations on the other hand are extremely easy to compromise. Even if the eeprom (on a sparc) is password protected the fact that a hacker can get physical access to the machine means that it's very likely to be compromised, but thats just life. (I'm sure at least some readers on this list will at some time in there life have waited around until late in the office, armed with a Solaris boot CD!) I'd like to make it a little more difficult for the hacker to access a running ssh-agent. At present, if a hacker can be root they just need to find the socket and connect to it, this is too easy. Why can't the ssh-agent, put an extra secret in the environment? SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414 2/ I also think it should have a timeout too, perhaps dumping all keys if the agent is unused for more than 30 mins. This is all completely useless if the hacker, has been root once they could easily replace the whole OpenSSH package , with their own, but this can easily be detected, with cryptographic checksums on key system files, but even the most paranoid organisation might overlook regular checking of permissions on the files/directories found under SSH_AUTH_SOCK 3/ ssh and sshd, do a really good job of totally ignoring id_???/identity/authorized_keys etc if the permissions aren't absolutely as required, shouldn't the same stringent tests be applied to the directories/sockets used by the agent? (yes I realize that anyone whose sued to root, can easily su to be me) Tim McGarry From Darren.Moffat at Sun.COM Tue Jan 15 11:26:01 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 14 Jan 2002 16:26:01 -0800 Subject: ssh-agent too easy to hack References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> Message-ID: <3C437719.9050000@Sun.COM> On 01/14/02 16:09, Tim McGarry wrote: > Why can't the ssh-agent, put an extra secret in the environment? > > SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414 Total waste of time. Your environment variables are public information, Try: /usr/ucb/ps -ewwwww on Solaris if you don't believe me. Also Since you are talking abour protecting against someone who already has root on the machine there is nothing what so ever you can do to help the situation since they can always just attach a debugger to the running ssh-agent and get stuff that way, or if they are really perverse dig around in /dev/kmem. The only thing that is going to help against root is using a system that doesn't have root - ie one with finegrained privileges and mandatory access control (eg. Trusted Solaris). > 2/ I also think it should have a timeout too, perhaps dumping all keys if > the agent is unused for more than 30 mins. > directories/sockets used by the agent? (yes I realize that anyone whose sued > to root, can easily su to be me) If the socket was held in an NFS directory AUTH_DH or AUTH_GSS with kerberos would protect against some of that attack but see above. -- Darren J Moffat From tim at mcgarry.ch Tue Jan 15 11:52:26 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 15 Jan 2002 01:52:26 +0100 Subject: ssh-agent too easy to hack References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> <3C437719.9050000@Sun.COM> Message-ID: <003a01c19d5e$e6e46920$c902a8c0@cablecom.ch> > > SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414 > Total waste of time. Your environment variables are public information, > Try: /usr/ucb/ps -ewwwww on Solaris if you don't believe me. You're right, so perhaps I'll write a wrapper around ssh (for legitimate users) to find the agent and set the env, even when the SSH_BLAH variables aren't set. > > Also Since you are talking abour protecting against someone who already > has root on the machine there is nothing what so ever you can do to help > the situation since they can always just attach a debugger to the > running ssh-agent and get stuff that way, or if they are really perverse > dig around in /dev/kmem. If they've got root acces and they are determined enough then they are going to break the agent anyhow, I'd just like to secure it up a bit so that it's harder to do without leaving a trace. Changing permissions on volatile files is not easy to detect in a general way across all files on the system, thats why I beleive ssh-agent should make this check and should be as strict about permissions as ssh/sshd are. > If the socket was held in an NFS directory AUTH_DH or AUTH_GSS with > kerberos would protect against some of that attack but see above. I'm no GSS expert, but with AUTH_DH root can access the NFS mounts anyhow, once the credentials get into the keyserver and the mount is permitted. Tim McGarry > > > -- > Darren J Moffat > From bradshaw at staff.crosswalk.com Tue Jan 15 12:09:11 2002 From: bradshaw at staff.crosswalk.com (Mark Bradshaw) Date: Mon, 14 Jan 2002 20:09:11 -0500 Subject: [PATCH]: scp: Avoid paths beginning with "//" Message-ID: <911C684A29ACD311921800508B7293BA037D2A04@cnmail> Scp has some path issues when transferring to or from the root file system of a windows machine (cygwin). It creates a path that begins with //, which indicates a UNC path on Windows. I sent in patches for similar issues last year. The fix is a one line change to determine if the path is "/", and not double up on the slashes. I've attached diffs to latest cvs. -Mark -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scp.diff.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020114/e1157c1b/attachment.txt From peterw at usa.net Tue Jan 15 12:11:07 2002 From: peterw at usa.net (Peter Watkins) Date: Mon, 14 Jan 2002 20:11:07 -0500 Subject: ssh-agent too easy to hack In-Reply-To: <003a01c19d5e$e6e46920$c902a8c0@cablecom.ch>; from tim@mcgarry.ch on Tue, Jan 15, 2002 at 01:52:26AM +0100 References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> <3C437719.9050000@Sun.COM> <003a01c19d5e$e6e46920$c902a8c0@cablecom.ch> Message-ID: <20020114201107.C19749@usa.net> On Tue, Jan 15, 2002 at 01:52:26AM +0100, Tim McGarry wrote: > > > SSH_AUTH_SOCK=/tmp/ssh-saZ24308/agent.24308?SALT=RaNdoMsTuFF447183414 > > > Total waste of time. Your environment variables are public information, > > > Try: /usr/ucb/ps -ewwwww on Solaris if you don't believe me. > You're right, so perhaps I'll write a wrapper around ssh (for legitimate > users) to find the agent and set the env, even when the SSH_BLAH variables > aren't set. Let me guess, the wrapper will run SUID/SGID. It'll be another potential attack vector for malicious local users (because it will, by necessity, be world-executable). I'm very skeptical of your suggestions. It just seems that by "closing" this hole, you're really just shifting the attack vector to somewhere else, maybe making something worse in the process. -Peter -- One day you're gonna have to face the deep dark truthful mirror - E Costello From fcusack at fcusack.com Tue Jan 15 12:33:15 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 14 Jan 2002 17:33:15 -0800 Subject: Public storage for public keys In-Reply-To: <20020114151234.G30233-100000@walter>; from jason@shalott.net on Mon, Jan 14, 2002 at 03:24:08PM -0800 References: <20020114151234.G30233-100000@walter> Message-ID: <20020114173315.M21767@google.com> On Mon, Jan 14, 2002 at 03:24:08PM -0800, Jason Stone wrote: > You _could_ use DNSSEC to distribute the keys, and I'm interested in why > this ended up being rejected? I'm not that familiar with dnssec, is it possible for the ssh client to know that dns lookups are via dnssec and not "just dns"? If not, this sounds like a very bad idea. If there were a call getkeybyname() and that call only returned success if dnssec were used, that might be ok. dunno. /fc From bob at proulx.com Tue Jan 15 15:51:03 2002 From: bob at proulx.com (Bob Proulx) Date: Mon, 14 Jan 2002 21:51:03 -0700 Subject: Should sshd be fixed to handle NIS+ keylogin In-Reply-To: <004b01c19d4a$a85889c0$c902a8c0@cablecom.ch> References: <004b01c19d4a$a85889c0$c902a8c0@cablecom.ch> Message-ID: <200201150451.g0F4p3U23550@torment.proulx.com> > To get around the problem of having to change the root password every time a > sys admin leaves the organization Solaris is hardened as follows. Gratuitous editorial remark: Wouldn't it be better to avoid having a widely known root password and use sudo instead which does user based authentication? That is what we do and it works well. > Restricted permissions on su so only certain groups can run it. > > That way its really difficult to log in as root even if the root password is > known. This sounds like a reinvention of a the "wheel group". You might want to do a search in google of 'site:gnu.org "wheel group"' which will turn up an interesting news discussion about this topic. IMNHO it really just means you need to two passwords, root's plus someone in the wheel group as well. And if you were root before then it should be easy to have set up an account in the wheel group that you know the password. That way when you do leave the company you are all set to be disgruntled at a moments notice and break back in later. ;-) Bob From mugz at x-mafia.com Tue Jan 15 16:25:50 2002 From: mugz at x-mafia.com (mugz) Date: Mon, 14 Jan 2002 22:25:50 -0700 (MST) Subject: odd behavior of OpenSSH_3.0.2p1 Message-ID: The above version of OpenSSH seems to work fine most of the time, but when I connect to one server in particular I get a very odd looking login prompt: pts/0::mugz!xm[~] ssh -l mugz otp-md5 414 cr6003 ext S/Key Password: otp-md5 265 cr4395 ext S/Key Password: otp-md5 332 cr9989 ext S/Key Password: scripter at crimelords.org's password: I enter my password 3 times in a row at this prompt, and then i get a "normal" login prompt and can login, whats up with this? mugz From stevesk at pobox.com Tue Jan 15 16:43:00 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 14 Jan 2002 21:43:00 -0800 (PST) Subject: ssh-agent too easy to hack In-Reply-To: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> Message-ID: On Tue, 15 Jan 2002, Tim McGarry wrote: :2/ I also think it should have a timeout too, perhaps dumping all keys if :the agent is unused for more than 30 mins. agent key timeouts would be good (e.g., ssh-add -t 2h). someone just needs to propose something and write the code. From pekkas at netcore.fi Tue Jan 15 18:18:31 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 15 Jan 2002 09:18:31 +0200 (EET) Subject: odd behavior of OpenSSH_3.0.2p1 In-Reply-To: Message-ID: On Mon, 14 Jan 2002, mugz wrote: > The above version of OpenSSH seems to work fine most of the time, but when > I connect to one server in particular I get a very odd looking login > prompt: > > pts/0::mugz!xm[~] ssh -l mugz > otp-md5 414 cr6003 ext > S/Key Password: > otp-md5 265 cr4395 ext > S/Key Password: > otp-md5 332 cr9989 ext > S/Key Password: > scripter at crimelords.org's password: > > I enter my password 3 times in a row at this prompt, and then i get a > "normal" login prompt and can login, whats up with this? ssh -o preferredauthentications=password This is (at least) caused by the fact that FreeBSD people have broken all setups without skey in use. It happened a few months ago with their FTP daemon, now it's happening with sshd. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus at openbsd.org Tue Jan 15 20:01:36 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 15 Jan 2002 10:01:36 +0100 Subject: ssh-agent too easy to hack In-Reply-To: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> Message-ID: <20020115090135.GB11584@faui02> On Tue, Jan 15, 2002 at 01:09:44AM +0100, Tim McGarry wrote: > 3/ ssh and sshd, do a really good job of totally ignoring > id_???/identity/authorized_keys etc if the permissions aren't absolutely as > required, shouldn't the same stringent tests be applied to the > directories/sockets used by the agent? (yes I realize that anyone whose sued > to root, can easily su to be me) check how the agent creates the directory From markus at openbsd.org Tue Jan 15 20:01:52 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 15 Jan 2002 10:01:52 +0100 Subject: ssh-agent too easy to hack In-Reply-To: References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> Message-ID: <20020115090152.GC11584@faui02> On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > On Tue, 15 Jan 2002, Tim McGarry wrote: > :2/ I also think it should have a timeout too, perhaps dumping all keys if > :the agent is unused for more than 30 mins. > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone just > needs to propose something and write the code. i'll do. From jakob at crt.se Tue Jan 15 21:15:26 2002 From: jakob at crt.se (Jakob Schlyter) Date: Tue, 15 Jan 2002 11:15:26 +0100 (CET) Subject: Public storage for public keys In-Reply-To: <3C43407C.3173BD4@tls.msk.ru> Message-ID: On Mon, 14 Jan 2002, Michael Tokarev wrote: > > > how can you trust ldap? > > > > LDAP over TLS could be usable. not very scalable though. > > There is no need to have scalable backend for this sort of > things. multiple key distribution points is probably need for this to work, otherwise you are toast when your ldap-server is done. how do you set up trust for the tls session? how do I find which ldap server(s) to query for host foo.example.com? what query do I make and what attributes should I look for? I'm not saying there are no answers to these questions, just that someone has to document how this is supposed to work and present a working solutions for this (i.e. running code). jakob From ed at UDel.Edu Wed Jan 16 02:05:32 2002 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 15 Jan 2002 10:05:32 -0500 (EST) Subject: Public storage for public keys In-Reply-To: <20020114151234.G30233-100000@walter> Message-ID: On Mon, 14 Jan 2002, Jason Stone wrote: > Date: Mon, 14 Jan 2002 15:24:08 -0800 (PST) > From: Jason Stone > To: Ed Phillips > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Public storage for public keys > > > > > > Yes, saved in a trusted location (ie, local file system). > > > A key in DNS is not trustworthy, since DNS is easily > > > compromised. > > > > Then the hard part - JH would have to play man-in-the-middle between A > > and B enough to convince A that the spoofed host key for B is okay... > > but how can JH do this without knowing the REAL private host key for > > system B? What am I missing? > > No, JH doesn't have to know B's private key - that's the point. A doesn't > know B's public key ('cause this whole discussion is about how to give it > to him), so JH gets in the middle of A and B (check out dsniff, ettercap, > etc - this is real easy nowadays), and when A asks for B's public key, JH > hands his own public key to A. Now A encrypts all his packets with JH's > key and sends them to JH. JH then requests B's public key, decrypts all > of A's packets, re-encrypts them with B's public key, and passes them on > to B. Neither A nor B realizes, because at a fundamental level, they > don't _really_ know each other if they haven't already exchanged keys and > cached them locally. Okay... that makes sense to me now. So the main problem is that, without a secure way to verify that the B's public keys is authentic you're pretty wide open to this sort of thing. And the known_hosts file is the only way we have for A to verify the public key presented by B... so if we were using DNS (which is easily hijacked) to distribute known_hosts info, then that makes the problem even worse, right? On the other hand, if we were using LDAP (or whatever) + SSL + signed certificates as a means for the ssh client to verify a public key presented by B, then we could potentially still centralize the known_hosts information securely... assuming that we only trust signatures that JH can't create himself? Is there any provision in the SSH specification (I really should make time to read this some day) to use digital signatures with ssh public keys? > Man-in-the-middle attacks are no longer strictly theoretical, nor reserved > for hardcore hackers. Easy and powerful tools are widely available to let > just anyone perform active attacks against a local net, even a switched > one, and shoddy key exchange is completely unacceptable. > You _could_ use DNSSEC to distribute the keys, and I'm interested in why > this ended up being rejected? I haven't read up on it... so I'm not sure if people are complaining that it just "moves" the security hole instead of plugging it... Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From cshobe at softhome.net Wed Jan 16 03:14:36 2002 From: cshobe at softhome.net (Casey Allen Shobe) Date: Tue, 15 Jan 2002 11:14:36 -0500 Subject: No shell prompt presented on SSH connection In-Reply-To: <3C41FCA3.107EDE01@tls.msk.ru> References: <3C41FCA3.107EDE01@tls.msk.ru> Message-ID: On Sunday 13 January 2002 04:31 pm, Michael Tokarev wrote: > Hey, devfs provides devpts! You can still mount it over devfs, but that > shouldn't be a requiriment. If I got devfs right -- I looked into it over > a year ago, that time ssh worked without devpts just fine for me, and > /dev/pts/* was here. I'm not using devfs. -- Casey Allen Shobe cshobe at softhome.net 'Why do people with closed minds always open their mouths?' From markus at openbsd.org Wed Jan 16 05:08:55 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 15 Jan 2002 19:08:55 +0100 Subject: User-Dependent Identity File In-Reply-To: <20020115180050.5792.qmail@wizard.math.ualberta.ca> References: <20020115005558.24140.qmail@wizard.math.ualberta.ca> <20020115131643.A19863@folly> <20020115154615.3727.qmail@wizard.math.ualberta.ca> <20020115162944.GB8644@faui02> <20020115180050.5792.qmail@wizard.math.ualberta.ca> Message-ID: <20020115180854.GB22105@faui02> On Tue, Jan 15, 2002 at 06:00:50PM -0000, John Bowman wrote: > > Date: Tue, 15 Jan 2002 17:29:44 +0100 > > From: Markus Friedl > > Cc: openssh at openbsd.org > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > User-Agent: Mutt/1.3.25i > > > > On Tue, Jan 15, 2002 at 03:46:15PM -0000, John Bowman wrote: > > > Can you implement the same code for IdentityFile? On clusters, one wants to > > > make /ssh a local (non-NFS) file system and use a syntax like this in the > > > system wide ssh_config file: > > > > > > IdentityFile /ssh/%u/id_rsa > > > > That's unlikely. > > > Oh? It is a serious security hole on many systems running openssh, so I'm really? even if it's on unprotected NFS, id_rsa is still encrypted. > suprised it does not interest you. define interest. > (ssh has a %U facilty for exactly this > reason, as I reported to you in my message last May). well, so i missed this part. > If I have time, I will implement it myself and submit a patch to the list. -m From bowman at math.ualberta.ca Wed Jan 16 05:35:51 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 15 Jan 2002 18:35:51 -0000 Subject: User-Dependent Identity File In-Reply-To: <20020115180854.GB22105@faui02> (message from Markus Friedl on Tue, 15 Jan 2002 19:08:55 +0100) References: <20020115005558.24140.qmail@wizard.math.ualberta.ca> <20020115131643.A19863@folly> <20020115154615.3727.qmail@wizard.math.ualberta.ca> <20020115162944.GB8644@faui02> <20020115180050.5792.qmail@wizard.math.ualberta.ca> <20020115180854.GB22105@faui02> Message-ID: <20020115183551.6370.qmail@wizard.math.ualberta.ca> > Date: Tue, 15 Jan 2002 19:08:55 +0100 > From: Markus Friedl > Cc: openssh-unix-dev at shitei.mindrot.org, openssh at openbsd.org > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.3.25i > > On Tue, Jan 15, 2002 at 06:00:50PM -0000, John Bowman wrote: > > > Date: Tue, 15 Jan 2002 17:29:44 +0100 > > > From: Markus Friedl > > > Cc: openssh at openbsd.org > > > Content-Type: text/plain; charset=us-ascii > > > Content-Disposition: inline > > > User-Agent: Mutt/1.3.25i > > > > > > On Tue, Jan 15, 2002 at 03:46:15PM -0000, John Bowman wrote: > > > > Can you implement the same code for IdentityFile? On clusters, one wants to > > > > make /ssh a local (non-NFS) file system and use a syntax like this in the > > > > system wide ssh_config file: > > > > > > > > IdentityFile /ssh/%u/id_rsa > > > > > > That's unlikely. > > > > > Oh? It is a serious security hole on many systems running openssh, so I'm > > really? even if it's on unprotected NFS, id_rsa is still encrypted. I presume you mean using non-blank passphrases. Many people trust the integrity of their local file systems and use blank pass phrases, rather than using ssh-agent, etc. (a good example of where this is absolutely necessary is for tunnelling lpd through ssh, see http://www.math.ualberta.ca/imaging/snfs/lpd). But this means that id_rsa can't be stored on an NFS mounted partition. Can you explain what is the conceptual problem that prevents you from implementing the %u feature? It simply doesn't make sense to store private keys on a publicly mounted partition! -- John From jesus at omniti.com Wed Jan 16 07:21:43 2002 From: jesus at omniti.com (Theo Schlossnagle) Date: Tue, 15 Jan 2002 15:21:43 -0500 Subject: Public storage for public keys In-Reply-To: <20020114173315.M21767@google.com> Message-ID: <7E048B03-09F5-11D6-B4A0-00039358205C@omniti.com> On Monday, January 14, 2002, at 08:33 PM, Frank Cusack wrote: > On Mon, Jan 14, 2002 at 03:24:08PM -0800, Jason Stone wrote: >> You _could_ use DNSSEC to distribute the keys, and I'm interested in >> why >> this ended up being rejected? > > I'm not that familiar with dnssec, is it possible for the ssh client to > know that dns lookups are via dnssec and not "just dns"? If not, this > sounds like a very bad idea. > > If there were a call getkeybyname() and that call only returned success > if dnssec were used, that might be ok. dunno. I thought people might be interested in this. One of the guys in my lab did a project on OpenSSH and DNSSEC integration for exactly this purpose. It is sound. http://www.cs.jhu.edu/~claudiu/projects/dnssecssh.html -- Theo Schlossnagle 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From Nicolas.Williams at ubsw.com Wed Jan 16 07:37:38 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 15 Jan 2002 15:37:38 -0500 Subject: Channels API and ~& question Message-ID: <20020115153736.H27398@sm2p1386swk.wdr.com> When processing ~& with SSHv2 OpenSSH sends \004 (EOT) and does not bother sending SSH2_MSG_CHANNEL_EOF. Why is that? Why is there no direct way to get SSH2_MSG_CHANNEL_EOF or SSH2_MSG_CHANNEL_CLOSE sent? Or is there and I'm just missing it? Thanks, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From djm at mindrot.org Wed Jan 16 08:38:33 2002 From: djm at mindrot.org (Damien Miller) Date: 16 Jan 2002 08:38:33 +1100 Subject: ssh-agent too easy to hack In-Reply-To: <003a01c19d5e$e6e46920$c902a8c0@cablecom.ch> References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> <3C437719.9050000@Sun.COM> <003a01c19d5e$e6e46920$c902a8c0@cablecom.ch> Message-ID: <1011130713.25039.7.camel@mothra> On Tue, 2002-01-15 at 11:52, Tim McGarry wrote: > If they've got root acces and they are determined enough then they are going > to break the agent anyhow, I'd just like to secure it up a bit so that it's > harder to do without leaving a trace. Trolling through /dev/kmem or attaching to your ssh-agent with a debugger leaves no traces. That's what I'd do if I was a malicious root. What would be nice IMO is some way for ssh-agent to alert the user that a signature request is being made, and optionally allow them to refuse it. This would help if you agent forward to a host with a malicious root user. -d From bugzilla-daemon at mindrot.org Wed Jan 16 08:57:13 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 16 Jan 2002 08:57:13 +1100 (EST) Subject: [Bug 68] New: Manpage for ssh-add and scp missing after "make install" Message-ID: <20020115215713.CAF69E9B3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=68 Summary: Manpage for ssh-add and scp missing after "make install" Product: Portable OpenSSH Version: 3.0.2p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Todd.Bowden at atosorigin.com I have run into a situation where I configured, did the make and, make install on an HP-UX 11.0 box. Everything looks good until I try and do a man on ssh- add or scp. When I took a look at the byte count both those were zero. Here is an out put from the man1 directory. [/opt/ssh2/man/man1] # ll total 134 -rw-r--r-- 1 root sys 0 Jan 15 15:53 scp.1 -rw-r--r-- 1 root sys 5319 Jan 15 15:53 sftp.1 lrwxr-xr-x 1 root sys 5 Jan 15 15:53 slogin.1 -> ssh.1 -rw-r--r-- 1 root sys 0 Jan 15 15:53 ssh-add.1 -rw-r--r-- 1 root sys 4313 Jan 15 15:53 ssh-agent.1 -rw-r--r-- 1 root sys 8135 Jan 15 15:53 ssh-keygen.1 -rw-r--r-- 1 root sys 3684 Jan 15 15:53 ssh-keyscan.1 -rw-r--r-- 1 root sys 44867 Jan 15 15:53 ssh.1 I tried configuring twice but ran into the same problem. As I looked into the directory in which I untarred everything and did a listing here is what I found on ssh-add* and scp*: [/opt/ssh2/man/man1] # ll /opt/openssh/ssh-add* -rwxr-xr-x 1 root sys 1855912 Jan 15 15:51 /opt/openssh/ssh-add -rw-rw-r-- 1 500 500 3249 Dec 1 18:38 /opt/openssh/ssh-add.0 -rw-rw-r-- 1 500 500 4902 Sep 12 13:06 /opt/openssh/ssh-add.1 -rw-r--r-- 1 root sys 0 Jan 9 17:24 /opt/openssh/ssh- add.1.out -rw-rw-r-- 1 500 500 8008 Oct 3 13:43 /opt/openssh/ssh-add.c -rw-r--r-- 1 root sys 52247 Jan 10 09:40 /opt/openssh/ssh-add.o [/opt/ssh2/man/man1] # ll /opt/openssh/scp* -rwxr-xr-x 1 root sys 367000 Jan 15 15:51 /opt/openssh/scp -rw-rw-r-- 1 500 500 3144 Dec 1 18:38 /opt/openssh/scp.0 -rw-rw-r-- 1 500 500 3190 Sep 18 01:56 /opt/openssh/scp.1 -rw-r--r-- 1 root sys 0 Jan 9 17:22 /opt/openssh/scp.1.out -rw-rw-r-- 1 500 500 29339 Oct 21 20:53 /opt/openssh/scp.c -rw-r--r-- 1 root sys 70025 Jan 10 09:41 /opt/openssh/scp.o Any ideas? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at mcgarry.ch Wed Jan 16 10:43:04 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Wed, 16 Jan 2002 00:43:04 +0100 Subject: ssh-agent too easy to hack References: <001d01c19d58$ef8f18a0$c902a8c0@cablecom.ch> <20020115090152.GC11584@faui02> Message-ID: <005d01c19e1e$60ac5a00$c902a8c0@cablecom.ch> So what do you think is the best approach either give the key an absolute life of eg 2 hours from ssh-add time or dump all keys 2 hours after the last request to the agent? Tim McGarry ----- Original Message ----- From: "Markus Friedl" To: "Kevin Steves" Cc: "Tim McGarry" ; Sent: Tuesday, January 15, 2002 10:01 AM Subject: Re: ssh-agent too easy to hack > On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > > On Tue, 15 Jan 2002, Tim McGarry wrote: > > :2/ I also think it should have a timeout too, perhaps dumping all keys if > > :the agent is unused for more than 30 mins. > > > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone just > > needs to propose something and write the code. > > i'll do. > From mouring at etoh.eviladmin.org Wed Jan 16 13:03:59 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 15 Jan 2002 20:03:59 -0600 (CST) Subject: ssh-agent too easy to hack In-Reply-To: <005d01c19e1e$60ac5a00$c902a8c0@cablecom.ch> Message-ID: Umm.. The first of the two. You'd really piss people off while you are explaining to them why they have to enter their passphrase AGAIN after only two minutes. =) However I would still perfer a user definable period. Maybe with some reasonable upper limit (12 hours? ). - Ben On Wed, 16 Jan 2002, Tim McGarry wrote: > So what do you think is the best approach > > either > give the key an absolute life of eg 2 hours from ssh-add time > or > dump all keys 2 hours after the last request to the agent? > > Tim McGarry > > ----- Original Message ----- > From: "Markus Friedl" > To: "Kevin Steves" > Cc: "Tim McGarry" ; > Sent: Tuesday, January 15, 2002 10:01 AM > Subject: Re: ssh-agent too easy to hack > > > > On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > > > On Tue, 15 Jan 2002, Tim McGarry wrote: > > > :2/ I also think it should have a timeout too, perhaps dumping all keys > if > > > :the agent is unused for more than 30 mins. > > > > > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone just > > > needs to propose something and write the code. > > > > i'll do. > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Wed Jan 16 16:17:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 16 Jan 2002 16:17:01 +1100 (EST) Subject: [Bug 69] New: Generalize SSH_ASKPASS Message-ID: <20020116051701.E0A34E920@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 Summary: Generalize SSH_ASKPASS Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bbum at codefab.com Two generalizations to SSH_ASKPASS (explanation follows). (1) Do not require a DISPLAY environment variable for SSH_ASKPASS to work. It is not necessary on non-X windowing systems (such as OS X). (2) Allow SSH_ASKPASS type functionality to be available even when run with stdin (or whatever) connected to a valid TTY. --- Why? Under OS X, I no longer use public key authentication to allow for passwordless (or one time per ssh-agent) authentication into remote machines. This is done for a number of reasons; fewer trust relationships is always good and some uses of SSH under OS X simply do not give the opportunity to ask for a password unless done through an external program. Further more, I have developed a small app-- SSHPassKey (http://www.codefab.com/unsupported/SSHPassKey_v1.1-1-README.html) that uses the KeyChain functionality built into OS X to store the passwords for particular sites. In effect, SSHPassKey acts as a replacement for ssh-agent, following the security semantics the user has configured (in my case, my Keychain locks itself automatically anytime the machine sleeps or after two hours). SSHPassKey works wonderfully via SSH_ASKPASS but, of course, does not work at the command line (where there is and sometimes should be a valid TTY) and it requires the DISPLAY environment variable to be set to something, which can occasionally confuse X aware apps -- like xemacs -- into thinking they should use an X server when they shouldn't. 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 Wed Jan 16 16:19:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 16 Jan 2002 16:19:44 +1100 (EST) Subject: [Bug 70] New: Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020116051944.84E4EE9B9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 Summary: Allow 'authorize host' questions to be able to be answered via GUI app Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bbum at codefab.com Just like ssh can ask for a password via the SSH_ASKPASS hook, it would be extremely useful if ssh would have a hook to ask for authorization of a machine key via some external command hook. If there isn't a valid TTY, ssh will fail if the user has never logged into a particular machine as there is no way to ask the user if it a particular machine has acceptably identified itself. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jakob at crt.se Wed Jan 16 18:47:02 2002 From: jakob at crt.se (Jakob Schlyter) Date: Wed, 16 Jan 2002 08:47:02 +0100 (MET) Subject: Public storage for public keys In-Reply-To: <7E048B03-09F5-11D6-B4A0-00039358205C@omniti.com> Message-ID: On Tue, 15 Jan 2002, Theo Schlossnagle wrote: > I thought people might be interested in this. One of the guys in my lab > did a project on OpenSSH and DNSSEC integration for exactly this > purpose. It is sound. I'm working with Wes Griffin to generalize the key lookup mechanism so that different key source, such as dnssec, can interface easier. we have running code for dnssec lookup, but have currently not decided how to store the actual key (there are currently multiple proposals for this; KEY, APPKEY, CERT, ...). We'll keep the list informed of any progress. jakob From pkamath at india.hp.com Wed Jan 16 20:29:18 2002 From: pkamath at india.hp.com (Pradeep kamath) Date: Wed, 16 Jan 2002 14:59:18 +0530 Subject: scp host1 to host2 Message-ID: <3C4547EE.2FE22BB2@india.hp.com> Hello all, scp doesn't seem to do remote copy between 2 hosts ie. scp host1: host2: doesn't ask for the passphrase when trying to authenticate to host2. Now if I change my rsa key to have no passphrase for host2 , I am able to do the remote scp. Is this a known issue ? So scp doesnot work if you cannot authenticate without user interaction to host2? I am using OpenSSH3.0.2p1 Any pointers will be greatly appreciated. Thanks in advance. Regards, Pradeep. From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jan 16 22:00:00 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 16 Jan 2002 12:00:00 +0100 Subject: [Bug 68] New: Manpage for ssh-add and scp missing after "make install" In-Reply-To: <20020115215713.CAF69E9B3@shitei.mindrot.org> References: <20020115215713.CAF69E9B3@shitei.mindrot.org> Message-ID: <20020116110000.GA13045@serv01.aet.tu-cottbus.de> On Wed, Jan 16, 2002 at 08:57:13AM +1100, bugzilla-daemon at mindrot.org wrote: > I tried configuring twice but ran into the same problem. As I looked into the > directory in which I untarred everything and did a listing here is what I found > on ssh-add* and scp*: > > [/opt/ssh2/man/man1] # ll /opt/openssh/ssh-add* > -rwxr-xr-x 1 root sys 1855912 Jan 15 15:51 /opt/openssh/ssh-add > -rw-rw-r-- 1 500 500 3249 Dec 1 18:38 /opt/openssh/ssh-add.0 > -rw-rw-r-- 1 500 500 4902 Sep 12 13:06 /opt/openssh/ssh-add.1 > -rw-r--r-- 1 root sys 0 Jan 9 17:24 /opt/openssh/ssh- > add.1.out > -rw-rw-r-- 1 500 500 8008 Oct 3 13:43 /opt/openssh/ssh-add.c > -rw-r--r-- 1 root sys 52247 Jan 10 09:40 /opt/openssh/ssh-add.o > > [/opt/ssh2/man/man1] # ll /opt/openssh/scp* > -rwxr-xr-x 1 root sys 367000 Jan 15 15:51 /opt/openssh/scp > -rw-rw-r-- 1 500 500 3144 Dec 1 18:38 /opt/openssh/scp.0 > -rw-rw-r-- 1 500 500 3190 Sep 18 01:56 /opt/openssh/scp.1 > -rw-r--r-- 1 root sys 0 Jan 9 17:22 /opt/openssh/scp.1.out > -rw-rw-r-- 1 500 500 29339 Oct 21 20:53 /opt/openssh/scp.c > -rw-r--r-- 1 root sys 70025 Jan 10 09:41 /opt/openssh/scp.o > > Any ideas? Obviously the transformation from scp.1 to scp.1.out failed. This means, that either of the script fixpaths or mdoc2man.pl failed, both of which being executed using $(PERL). It did work fine for me on HP-UX 10.20 with perl5 self-installed. I don't know what version of perl is shipped with HP-UX 11 and what you have installed additionally on your system. The manual pages are built first when calling "make". Delete scp.1.out and/or ssh-add.1.out and call "make" to see the error messages. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From bugzilla-daemon at mindrot.org Thu Jan 17 00:24:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 00:24:50 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020116132450.C1C50E99F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 ------- Additional Comments From djm at mindrot.org 2002-01-17 00:24 ------- I like this idea - we could probably reuse most of the askpass code to obtain the answer (which should still IMO require the _typing_ of "yes"). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Jason.Lacoss-Arnold at AGEDWARDS.com Thu Jan 17 01:26:08 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Wed, 16 Jan 2002 08:26:08 -0600 Subject: OpenSSH: Solaris login and utmpx Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E481@hqempn06.agedwards.com> We're trying to build OpenSSH 3.0.2p1 for Solaris 8 (among others) and are running into a problem with UseLogin and utmpx. If we set "UseLogin no" then we can login okay. finger or who won't find us, even with a TTY allocated altough "who /etc/wtmpx" will find us. But the real problem is if we set "UseLogin true" which we must do for BSM support on some of our boxes. Then, when we try to login, we get the following: No utmpx entry. You must exec "login" from the lowest level "shell". I found that message in a patch submitted in March by Matt Eagleson. However, grepping on his "LOGIN_NEEDS_UTMPX" addition makes it look like the patch has been incorporated into the codebase. So, our configure did define LOGIN_NEEDS_UTMPX, so that's not the problem. I'm wondering about a post from William Knox that includes a patch submission with the subject: "PATCH: Fixing last/utmpx for Solaris". Is this patch what we need? Is there any chance that it will be incorporated into the official codebase soon? Has anyone answered any of the questions that he asked in his submission? Or is there something at issue here? Is there anything I can do to provide help debugging? We're building with the following options: --prefix=/opt/openssh --enable-largefile --with-pam --enable-tcp_wrappers --enable-lastlog --enable-utmpx -x-includes=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-ssl-dir=/opt/openssh --with-xauth=/usr/openwin/bin/xauth --with-default-path=/usr/bin:/usr/sbin:/usr/local/bin --with-pid-dir=/opt/openssh/etc We have problems with the current ssh client, previous clients, and F-Secure Win32 (version 5.1). (possibly) Relevant previous posts: http://marc.theaimsgroup.com/?l=openssh-unix-dev &m=98529677900660&w=2 http://marc.theaimsgroup.com/?l=openssh-unix-dev &m=100628485610076&w=2 Thanks for any help in advance, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** From bugzilla-daemon at mindrot.org Thu Jan 17 02:19:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 02:19:18 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020116151918.14BE7E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 ------- Additional Comments From markus at openbsd.org 2002-01-17 02:19 ------- Created an attachment (id=10) like this? ------- 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 Jan 17 02:22:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 02:22:51 +1100 (EST) Subject: [Bug 65] New: TCP Wrappers support does not log successful connections Message-ID: <20020116152251.9162FE9C1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=65 Summary: TCP Wrappers support does not log successful connections Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jap3003+opensshbugs at ksu.edu sshd does not log connections that succeed the hosts_access() function. Failed connections are logged in tcp wrappers [via refuse()], but special care must be taken to log connections that succeed. It's not a show-stopper, since other, more detailed logging mechanisms exist, but it'd be a nice thing to have, since it shows that the allowed connection passed the wrappers. That, and tcpd and the commercial [at least verision 1.2.whatever] do it. ------- Additional Comments From jap3003+opensshbugs at ksu.edu 2002-01-07 09:54 ------- Created an attachment (id=8) Patch to fix this bug (gdiff -u) ------- Additional Comments From markus at openbsd.org 2002-01-17 02:22 ------- shouln't the tcpwrapper do this? we should not call syslog at all ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From TGFurnish at herff-jones.com Thu Jan 17 02:20:32 2002 From: TGFurnish at herff-jones.com (Furnish, Trever G) Date: Wed, 16 Jan 2002 10:20:32 -0500 Subject: How can I politely disconnect? Was: Clean way to monitor status of 'sshd' remotely? Message-ID: <5D8D9455134FD211AE4900A0C9DED11E05EACF67@indy1ntm.herff-jones.com> I'm having the same issue "Eddy Geez" posted about in October, 2001 - I'm looking to figure out how to politely disconnect from openssh's sshd, such that it will either not log the connection at all or will at least not log it at fatal level. I monitor the sshd daemon on all my hosts with Netsaint's check_ssh plugin every five minutes, so there are a *lot* of these log messages piling up. It would be very nice to be able to configure sshd to ignore connections from a specific ip address/user combo, or to have it log these connections at info level instead, but barring those options I'd at least like to figure out how to modify Netsaint's check_ssh plugin to have it do a 'polite' disconnect, so sshd will just log it as a normal client connection. Where can I look to find what sshd will expect for a normal client disconnect? Pointers to a protocol spec would be appreciated, as would any other advice. -- Trever Furnish, tgfurnish at herff-jones.com, 317.329.3397 x3519 Unix Administrator, Herff-Jones, Inc. http://www.wondious.com From bugzilla-daemon at mindrot.org Thu Jan 17 03:14:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 03:14:18 +1100 (EST) Subject: [Bug 65] TCP Wrappers support does not log successful connections Message-ID: <20020116161418.959A3E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=65 ------- Additional Comments From jap3003+opensshbugs at ksu.edu 2002-01-17 03:14 ------- "should?" Maybe. "Does?" No. This is the way tcpd does it, too. The call to hosts_access() only determines whether or not a host should pass. refuse() [iirc, don't have the source handy] terminates sshd after calling syslog. There doesn't appear to be a corresponding accept() function. However, the fact that we have to call syslog ourselves is mitigated by the fact that there is a function available to crack the request structure, so we don't really have to go dinking with the tcp wrapper internals. It's the %s being sent into the syslog. Although it's not mentioned on the manpage, it's in the header we include. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Nicolas.Williams at ubsw.com Thu Jan 17 07:05:14 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 16 Jan 2002 15:05:14 -0500 Subject: PATCH: Option so -f waits until forwarded port/x11 is opened before backgrounding In-Reply-To: <20020111105359.E27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Fri, Jan 11, 2002 at 10:54:01AM -0500 References: <20020111105359.E27398@sm2p1386swk.wdr.com> Message-ID: <20020116150513.I27398@sm2p1386swk.wdr.com> You can now put "WaitForPortOpenBeforeFork=no" in ssh_config and "ssh -f ..." will wait until a forwarded port/x11/agent is opened before backgrounding the client. See below for the rationale for this feature. It improves error handling for users of OpenSSH when launching [X11] apps. As a bonus the backgrounded client closes stdio and the file descriptors of the channel associated with the ssh session so that in the background the client stays mum. This could be made a separate option. See the forkoff() function added to clientloop.c for details. Patch is attached. Comments? Should I file a bug report to request that this feature be added? Nico On Fri, Jan 11, 2002 at 10:54:01AM -0500, Nicolas Williams wrote: > I'd like a feature whereby ssh puts itself in the background after the > first successful X11 (or other port) forwarding. > > The reason for this is simple: error handling. > > If the application fails to open the X display and exits, then the > client can still exit with the application's exit code. But if the > application opens the X display successfully, then it can just display > any errors by itself. > > I intend to write and contribute such a patch to implement such a > feature in the next few days. > > Comments? > > Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- -------------- next part -------------- Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/ssh.c --- 3_0_2p1_w_gss_and_krb5_compat_try.2/ssh.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/ssh.c Wed, 16 Jan 2002 12:57:39 -0500 @@ -111,6 +111,7 @@ * background. */ int fork_after_authentication_flag = 0; +int wait_for_port_open_before_fork = 0; /* * General data structure for command line options and options configurable @@ -628,6 +629,8 @@ /* Fill configuration defaults. */ fill_default_options(&options); + wait_for_port_open_before_fork = options.wait_for_port_open_before_fork; + /* reinit */ log_init(av[0], options.log_level, SYSLOG_FACILITY_USER, 1); @@ -1164,7 +1167,7 @@ id = ssh_session2_open(); /* If requested, let ssh continue in the background. */ - if (fork_after_authentication_flag) + if (fork_after_authentication_flag && !options.wait_for_port_open_before_fork) if (daemon(1, 1) < 0) fatal("daemon() failed: %.200s", strerror(errno)); Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/readconf.h --- 3_0_2p1_w_gss_and_krb5_compat_try.2/readconf.h Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/readconf.h Tue, 15 Jan 2002 16:49:44 -0500 @@ -111,6 +111,7 @@ Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; int no_host_authentication_for_localhost; + int wait_for_port_open_before_fork; /* Like -f, but after first successful port/display open */ } Options; Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/readconf.c --- 3_0_2p1_w_gss_and_krb5_compat_try.2/readconf.c Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/readconf.c Tue, 15 Jan 2002 17:35:38 -0500 @@ -111,6 +111,7 @@ #ifdef AFS oAFSTokenPassing, #endif + oWaitForPortOpenBeforeFork, oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward, oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand, oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts, @@ -202,6 +203,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "waitforportopenbeforefork", oWaitForPortOpenBeforeFork }, { NULL, 0 } }; @@ -710,6 +712,10 @@ *intptr = value; break; + case oWaitForPortOpenBeforeFork: + intptr = &options->wait_for_port_open_before_fork; + goto parse_flag; + default: fatal("process_config_line: Unimplemented opcode %d", opcode); } @@ -839,6 +845,7 @@ options->bind_address = NULL; options->smartcard_device = NULL; options->no_host_authentication_for_localhost = - 1; + options->wait_for_port_open_before_fork = -1; } /* @@ -969,6 +976,8 @@ clear_forwardings(options); if (options->no_host_authentication_for_localhost == - 1) options->no_host_authentication_for_localhost = 0; + if (options->wait_for_port_open_before_fork == -1) + options->wait_for_port_open_before_fork = 0; /* 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 */ Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/clientloop.c --- 3_0_2p1_w_gss_and_krb5_compat_try.2/clientloop.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/clientloop.c Wed, 16 Jan 2002 14:50:24 -0500 @@ -95,6 +95,9 @@ */ extern char *host; +extern int fork_after_authentication_flag; +extern int wait_for_port_open_before_fork; + /* * Flag to indicate that we have received a window change signal which has * not yet been processed. This will cause a message indicating the new @@ -1007,6 +1010,79 @@ /*********/ +/* + * Detach the program (continue to serve connections, + * but put in background and no more new connections). + */ +static +void +forkoff(int stop_listening) +{ + pid_t pid; + int fd; + int bytes = 0; + Channel *c; + + /* Restore tty modes. */ + leave_raw_mode(); + + /* Stop listening for new connections. */ + if (stop_listening) + channel_stop_listening(); + + fprintf(stderr, "Forking off into the background - %s", + stop_listening ? "no longer listening" : "still listening"); + + /* Fork into background. */ + pid = fork(); + if (pid < 0) { + error("fork: %.100s", strerror(errno)); + return; + } + if (pid != 0) { /* This is the parent. */ + /* The parent just exits. */ + exit(0); + } + + c = channel_lookup(session_ident); + if (c == NULL) + error("couldn't lookup session channel"); + + /* The child continues serving connections. */ + /* fake EOF on stdin */ + if (compat20) { + buffer_append(&stdin_buffer, "\004", 1); + } else if (!stdin_eof) { + /* + * Sending SSH_CMSG_EOF alone does not always appear + * to be enough. So we try to send an EOF character + * first. + */ + packet_start(SSH_CMSG_STDIN_DATA); + packet_put_string("\004", 1); + packet_send(); + /* Close stdin. */ + stdin_eof = 1; + if (buffer_len(&stdin_buffer) == 0) { + packet_start(SSH_CMSG_EOF); + packet_send(); + } + } + chan_read_failed(c); + chan_write_failed(c); + channel_close_fds(c); + fd = open(_PATH_DEVNULL, O_RDWR, 0); + if (fd < 0) + return; + (void) dup2(fd, STDIN_FILENO); + (void) dup2(fd, STDOUT_FILENO); + (void) dup2(fd, STDERR_FILENO); + if (fd > 2) + (void) close(fd); + + return; +} + static void client_input_stdout_data(int type, int plen, void *ctxt) { @@ -1187,6 +1263,8 @@ packet_put_int(c->local_maxpacket); packet_send(); } + if (fork_after_authentication_flag && wait_for_port_open_before_fork) + forkoff(0); } else { debug("failure %s", ctype); packet_start(SSH2_MSG_CHANNEL_OPEN_FAILURE); Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/channels.h --- 3_0_2p1_w_gss_and_krb5_compat_try.2/channels.h Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/channels.h Wed, 16 Jan 2002 13:24:53 -0500 @@ -153,6 +153,7 @@ void channel_register_filter(int, channel_filter_fn *); void channel_cancel_cleanup(int); int channel_close_fd(int *); +void channel_close_fds(Channel *); /* protocol handler */ Index: 3_0_2p1_w_gss_and_krb5_compat_try.2/channels.c --- 3_0_2p1_w_gss_and_krb5_compat_try.2/channels.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_and_krb5_compat_try.2(w)/channels.c Wed, 16 Jan 2002 14:48:11 -0500 @@ -301,7 +301,7 @@ /* Close all channel fd/socket. */ -static void +void channel_close_fds(Channel *c) { debug3("channel_close_fds: channel %d: r %d w %d e %d", -------------- next part -------------- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Thu Jan 17 07:12:08 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 16 Jan 2002 15:12:08 -0500 Subject: Channels API and ~& question In-Reply-To: <20020115153736.H27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Jan 15, 2002 at 03:37:38PM -0500 References: <20020115153736.H27398@sm2p1386swk.wdr.com> Message-ID: <20020116151206.J27398@sm2p1386swk.wdr.com> I'll answer the question I was really after: To forcibly close the channel associated with a session call chan_read_failed(), chan_write_failed() and chan_close_fds() on said channel. Seems to work fine. See the feature patch I posted today. I think a don't-hang-on-exited-but-still-open-session feature could be coded that does the above upon receipt of the session-exit message for the last session. Please let me know if I'm horribly mis-understanding the channels API... Cheers, Nico On Tue, Jan 15, 2002 at 03:37:38PM -0500, Nicolas Williams wrote: > When processing ~& with SSHv2 OpenSSH sends \004 (EOT) and does not > bother sending SSH2_MSG_CHANNEL_EOF. > > Why is that? > > Why is there no direct way to get SSH2_MSG_CHANNEL_EOF or > SSH2_MSG_CHANNEL_CLOSE sent? Or is there and I'm just missing it? > > Thanks, > > Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at mcgarry.ch Thu Jan 17 09:40:45 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Wed, 16 Jan 2002 23:40:45 +0100 Subject: ssh-agent too easy to hack References: Message-ID: <001a01c19ede$d7b6e320$c902a8c0@cablecom.ch> Yep I prefer the first option too, it'll remind me to go to lunch at when my keys get dumped and also to leave the office in time to get the train :-) But, most people would expect keys to be dumped after a period of idleness. Tim ----- Original Message ----- From: To: "Tim McGarry" Cc: Sent: Wednesday, January 16, 2002 3:03 AM Subject: Re: ssh-agent too easy to hack > > Umm.. The first of the two. You'd really piss people off while you are > explaining to them why they have to enter their passphrase AGAIN after > only two minutes. =) However I would still perfer a user definable > period. Maybe with some reasonable upper limit (12 hours? ). > > - Ben > > On Wed, 16 Jan 2002, Tim McGarry wrote: > > > So what do you think is the best approach > > > > either > > give the key an absolute life of eg 2 hours from ssh-add time > > or > > dump all keys 2 hours after the last request to the agent? > > > > Tim McGarry > > > > ----- Original Message ----- > > From: "Markus Friedl" > > To: "Kevin Steves" > > Cc: "Tim McGarry" ; > > Sent: Tuesday, January 15, 2002 10:01 AM > > Subject: Re: ssh-agent too easy to hack > > > > > > > On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > > > > On Tue, 15 Jan 2002, Tim McGarry wrote: > > > > :2/ I also think it should have a timeout too, perhaps dumping all keys > > if > > > > :the agent is unused for more than 30 mins. > > > > > > > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone just > > > > needs to propose something and write the code. > > > > > > i'll do. > > > > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim at mcgarry.ch Thu Jan 17 09:40:45 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Wed, 16 Jan 2002 23:40:45 +0100 Subject: ssh-agent too easy to hack References: Message-ID: <001a01c19ede$d7b6e320$c902a8c0@cablecom.ch> Yep I prefer the first option too, it'll remind me to go to lunch at when my keys get dumped and also to leave the office in time to get the train :-) But, most people would expect keys to be dumped after a period of idleness. Tim ----- Original Message ----- From: To: "Tim McGarry" Cc: Sent: Wednesday, January 16, 2002 3:03 AM Subject: Re: ssh-agent too easy to hack > > Umm.. The first of the two. You'd really piss people off while you are > explaining to them why they have to enter their passphrase AGAIN after > only two minutes. =) However I would still perfer a user definable > period. Maybe with some reasonable upper limit (12 hours? ). > > - Ben > > On Wed, 16 Jan 2002, Tim McGarry wrote: > > > So what do you think is the best approach > > > > either > > give the key an absolute life of eg 2 hours from ssh-add time > > or > > dump all keys 2 hours after the last request to the agent? > > > > Tim McGarry > > > > ----- Original Message ----- > > From: "Markus Friedl" > > To: "Kevin Steves" > > Cc: "Tim McGarry" ; > > Sent: Tuesday, January 15, 2002 10:01 AM > > Subject: Re: ssh-agent too easy to hack > > > > > > > On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > > > > On Tue, 15 Jan 2002, Tim McGarry wrote: > > > > :2/ I also think it should have a timeout too, perhaps dumping all keys > > if > > > > :the agent is unused for more than 30 mins. > > > > > > > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone just > > > > needs to propose something and write the code. > > > > > > i'll do. > > > > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From acox at ia.primustel.com Thu Jan 17 11:23:20 2002 From: acox at ia.primustel.com (Aran Cox) Date: 16 Jan 2002 18:23:20 -0600 Subject: ssh-agent too easy to hack In-Reply-To: <001a01c19ede$d7b6e320$c902a8c0@cablecom.ch> References: <001a01c19ede$d7b6e320$c902a8c0@cablecom.ch> Message-ID: <1011227001.21733.20.camel@benway.cv.telegroup.com> Ideally you could choose both, dump the keys after a fixed period no matter what and/or after a period of disuse. At least, that's what I've always wanted. I'd dump them all after 4 hours no questions asked and maybe an hour or two after their last use. On Wed, 2002-01-16 at 16:40, Tim McGarry wrote: > Yep I prefer the first option too, it'll remind me to go to lunch at when my > keys get dumped and also to leave the office in time to get the train :-) > > But, most people would expect keys to be dumped after a period of idleness. > > Tim > > ----- Original Message ----- > From: > To: "Tim McGarry" > Cc: > Sent: Wednesday, January 16, 2002 3:03 AM > Subject: Re: ssh-agent too easy to hack > > > > > > Umm.. The first of the two. You'd really piss people off while you are > > explaining to them why they have to enter their passphrase AGAIN after > > only two minutes. =) However I would still perfer a user definable > > period. Maybe with some reasonable upper limit (12 hours? ). > > > > - Ben > > > > On Wed, 16 Jan 2002, Tim McGarry wrote: > > > > > So what do you think is the best approach > > > > > > either > > > give the key an absolute life of eg 2 hours from ssh-add time > > > or > > > dump all keys 2 hours after the last request to the agent? > > > > > > Tim McGarry > > > > > > ----- Original Message ----- > > > From: "Markus Friedl" > > > To: "Kevin Steves" > > > Cc: "Tim McGarry" ; > > > > Sent: Tuesday, January 15, 2002 10:01 AM > > > Subject: Re: ssh-agent too easy to hack > > > > > > > > > > On Mon, Jan 14, 2002 at 09:43:00PM -0800, Kevin Steves wrote: > > > > > On Tue, 15 Jan 2002, Tim McGarry wrote: > > > > > :2/ I also think it should have a timeout too, perhaps dumping all > keys > > > if > > > > > :the agent is unused for more than 30 mins. > > > > > > > > > > agent key timeouts would be good (e.g., ssh-add -t 2h). someone > just > > > > > needs to propose something and write the code. > > > > > > > > i'll do. > > > > > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020116/1d9c2c6b/attachment.bin From bugzilla-daemon at mindrot.org Thu Jan 17 13:28:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 13:28:28 +1100 (EST) Subject: [Bug 71] New: configure is looking for zlib but I don't have one and I can't turn zlib off. Message-ID: <20020117022828.AFAE2E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=71 Summary: configure is looking for zlib but I don't have one and I can't turn zlib off. Product: Portable OpenSSH Version: 3.0.2p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: george.r.goffe at seagate.com I'm trying to build this version of ssh on my solaris 2.8 system and can't get past the configure stage. Configure seems to be looking for zlib and fails even when I specify --without-zlib or --disable-zlib. I'm enclosing the build log as part of this bug report. Regards and THANKS for the cool software. George... cat bld.log1 #!/bin/sh -xv if [ $# = 0 ] then ncpus=1 else ncpus=$1 fi + [ 0 = 0 ] ncpus=1 sysver=`uname -s` + uname -s sysver=SunOS syslvl=`uname -r` + uname -r syslvl=5.8 osname=$sysver.$syslvl osname=SunOS.5.8 case $osname in SunOS.5.5) osname="$sysver.5.5" ;; SunOS.5.5.1) osname="$sysver.5.5.1" ;; SunOS.5.6) osname="$sysver.5.6" ;; SunOS.5.7) osname="$sysver.5.7" ;; SunOS.5.8) osname="$sysver.5.8" ;; SunOS.5.9) osname="$sysver.5.9" ;; *) printf "%s" 'Wrong system level encountered...' exit 86 esac osname=SunOS.5.8 PATH=/usr/lsd/$osname/bin:/usr/local/bin:/usr/bin PATH=/usr/lsd/SunOS.5.8/bin:/usr/local/bin:/usr/bin export PATH + export PATH which gcc + which gcc /usr/local/bin/gcc gcc --version + gcc --version 3.0.2 which as + which as /usr/lsd/SunOS.5.8/bin/as as --version + as --version GNU assembler 2.11.2 Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.8'. which ld + which ld /usr/lsd/SunOS.5.8/bin/ld ld --version + ld --version GNU ld 2.11.2 Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf32_sparc elf64_sparc make distclean + make distclean make: *** No rule to make target `distclean'. Stop. ./configure --prefix=/usr/lsd/$osname --verbose \ --enable-suid-ssh \ --with-cflags \ --with-cppflags \ --with-ldflags \ --with-zlib=/usr/lsd/$osname \ --with-libs=-lz \ --with-tcp-wrappers=/usr/lsd/$osname \ --with-pam \ --with-ssl-dir=/usr/lsd/$osname \ --with-rsh=/usr/bin \ --with-xauth=/usr/openwin/bin \ --with-mantype=man \ --with-md5-passwords \ --with-ipaddr-display \ --with-ipv4-default \ --with-4in6 \ --with-bsd-auth \ --with-pid-dir=/usr/lsd/$osname/etc + ./configure --prefix=/usr/lsd/SunOS.5.8 --verbose --enable-suid-ssh --with-cflags --with-cppflags --with-ldflags --with-zlib=/usr/lsd/SunOS.5.8 --with-libs=-lz --with-tcp-wrappers=/usr/lsd/SunOS.5.8 --with-pam --with-ssl-dir=/usr/lsd/SunOS.5.8 --with-rsh=/usr/bin --with-xauth=/usr/openwin/bin --with-mantype=man --with-md5-passwords --with-ipaddr-display --with-ipv4-default --with-4in6 --with-bsd-auth --with-pid-dir=/usr/lsd/SunOS.5.8/etc checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking whether byte ordering is bigendian... yes checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD compatible install... /usr/lsd/SunOS.5.8/bin/install -c checking for ar... /usr/lsd/SunOS.5.8/bin/ar checking for perl5... no checking for perl... /usr/lsd/SunOS.5.8/bin/perl checking for ent... no checking for filepriv... no checking for bash... /usr/lsd/SunOS.5.8/bin/bash checking for ksh... (cached) /usr/lsd/SunOS.5.8/bin/bash checking for sh... (cached) /usr/lsd/SunOS.5.8/bin/bash checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no checking for login... /usr/bin/login checking for gcc option to accept ANSI C... none needed checking for inline... inline checking for obsolete utmp and wtmp in solaris2.x... yes checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking for yp_match... no checking for yp_match in -lnsl... no checking for setsockopt... no checking for setsockopt in -lsocket... no checking for getspnam... no checking for getspnam in -lgen... no checking for deflate in -lz... no configure: error: *** zlib missing - please install first or check config.log *** #--with-random=FILE read entropy from FILE (default=/dev/urandom) #--with-prngd-port=PORT read entropy from PRNGD/EGD localhost:PORT #--with-prngd-socket=FILE read entropy from PRNGD/EGD socket FILE (default=/var/run/egd-pool) #--with-lastlog=FILE|DIR specify lastlog location common locations make clean + make clean make: *** No rule to make target `clean'. Stop. make depend + make depend make: *** No rule to make target `depend'. Stop. make -j $ncpus + make -j 1 make: *** No targets specified and no makefile found. Stop. make install + make install make: *** No rule to make target `install'. Stop. exit 0 + exit 0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pekkas at netcore.fi Thu Jan 17 18:19:45 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 17 Jan 2002 09:19:45 +0200 (EET) Subject: ssh-agent too easy to hack In-Reply-To: <1011227001.21733.20.camel@benway.cv.telegroup.com> Message-ID: On 16 Jan 2002, Aran Cox wrote: > Ideally you could choose both, dump the keys after a fixed period no > matter what and/or after a period of disuse. At least, that's what I've > always wanted. I'd dump them all after 4 hours no questions asked and > maybe an hour or two after their last use. What's the idea of such a short idle period? Me, for example, always xlock my workstation even if I go to talk to my colleagues nearby. If sufficient care is observed, the time periods should be usably long. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From bugzilla-daemon at mindrot.org Thu Jan 17 19:25:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 17 Jan 2002 19:25:27 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020117082527.02AD2E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 ------- Additional Comments From jmknoble at pobox.com 2002-01-17 19:25 ------- It wouldn't be too difficult to massage x11-ssh-askpass to provide a real sort of "yes-or-no" functionality, as long as we all agree on how to tell ssh-askpass to "be a yes-or-no dialog instead of a passphrase dialog". Then again, xmessage works for that sort of thing already; a shell wrapper around it would be even easier.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Ernst.Boetsch at lrz-muenchen.de Thu Jan 17 20:03:30 2002 From: Ernst.Boetsch at lrz-muenchen.de (Ernst Boetsch) Date: Thu, 17 Jan 2002 10:03:30 +0100 Subject: Please help: Compiling/configuring OpenSSH on SunOS 5.5.1 with AFS Message-ID: <20020117100329.U19999@wsc22.lrz-muenchen.de> Hello *, i have some problems to compile/configure OpenSSH on SunOS 5.5.1 with AFS. See the attachment for the compile environment. The programs compile fine and token passing is without problems. Unfortunately it is not possible to login without a valid token (`Permission denied.'). There is following message in the syslog: Kerberos v4 TGT for ... unverifiable: Principal unknown (kerberos); rcmd.wsc33 not registered, or srvtab is wrong? Failed password for ... from ... If i use an old ssh-1.2.27 with the patch from Dug Song (many thanks) and security fixes i have no problems: Kerberos V4 TGT for ... unverifiable: Principal unknown (kerberos); rcmd.wsc33 not registered, or srvtab is wrong? Password authentication for ... accepted. Any hint is appreciated very much since i am not familiar with AFS or Kerberos programming. Did i miss something? E.g. i could not find a `README.AFS'. Thanks in advance. Kind regards, Ernst Boetsch -- ******************************************************************* Ernst N. Boetsch | Leibniz Computer Center | of the Bavarian Academy Email: Ernst.Boetsch at lrz-muenchen.de | of Sciences Phone: +49 89 289-28831 (/-28784) | Barer Strasse 21 Fax: +49 89 2809460 | D-80333 Muenchen, Germany ######################################################################## Compile environment: * uname -a: SunOS wsc33 5.5.1 Generic_103640-35 sun4u sparc SUNW,Ultra-2 * zlib-1.1.3, krb4-1.1, openssl-0.9.6c * /opt/SUNWspro/bin/cc * `openssh-3.0.2p1' with the AFSPassTokenBeforeAuth patch of Serge Droz (it is very important for me, many thanks). * Configure information: OpenSSH has been configured with the following options: User binaries: /sw/sun4_55/Security/openssh-3.0.2p1 System binaries: /sw/sun4_55/Security/openssh-3.0.2p1 Configuration files: /usr/local/etc/openssh Askpass program: /sw/sun4_55/Security/openssh-3.0.2p1/ssh-askpass Manual pages: /sw/sun4_55/Security/openssh-3.0.2p1/man/manX PID file: /usr/local/etc/openssh sshd default user PATH: /usr/bin:/usr/ucb:/usr/local/bin:/client/bin Random number collection: Builtin (timeout 200) Manpage format: man PAM support: no KerberosIV support: yes Smartcard support: no AFS support: yes S/KEY support: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: no Host: sparc-sun-solaris2.5.1 Compiler: /opt/SUNWspro/bin/cc Compiler flags: -O Preprocessor flags: -I/client/include -I/client/include -I/usr/local/include -I/usr/afsws/include Linker flags: -R/client/lib -L/client/lib -s -z muldefs -L/client/lib -R/client/lib -L/usr/local/lib -R/usr/local/lib -L/usr/afsws/lib Libraries: -lkafs -lresolv -ldes -lkrb -lwrap -lz -lsocket -lnsl -lcrypto -ldes From peterw at usa.net Fri Jan 18 00:09:03 2002 From: peterw at usa.net (Peter Watkins) Date: Thu, 17 Jan 2002 08:09:03 -0500 Subject: ssh-agent discard timeout behavior (too easy to hack) In-Reply-To: ; from pekkas@netcore.fi on Thu, Jan 17, 2002 at 09:19:45AM +0200 References: <1011227001.21733.20.camel@benway.cv.telegroup.com> Message-ID: <20020117080903.B20924@usa.net> On Thu, Jan 17, 2002 at 09:19:45AM +0200, Pekka Savola wrote: > On 16 Jan 2002, Aran Cox wrote: > > Ideally you could choose both, dump the keys after a fixed period no > > matter what and/or after a period of disuse. At least, that's what I've > > always wanted. I'd dump them all after 4 hours no questions asked and > > maybe an hour or two after their last use. > > What's the idea of such a short idle period? > > Me, for example, always xlock my workstation even if I go to talk to my > colleagues nearby. If sufficient care is observed, the time periods > should be usably long. Same here. I can see why folks might want such a feature, but I personally would not need/want such behavior on some of my systems. I would personally prefer that *default* behavior be current behavior; let folks add command line arguments to request that certain keys be treated differently. Behavior question: let's say ssh-agent holds a key for sshd.example.com If ssh-agent were to dump that key, should it - forget about the key entirely (in which case, if the user were to connect to sshd.example.com, the user would likely be prompted for a regular password *after* ssh had already connected; if the user needed/wanted to use their key, they'd have to abort the ssh connection and re-add the key to ssh-agent before reconnecting) - remember that it *had* cached the key, and modify ssh/ssh-agent behavior such that the next time 'ssh' were used, it would prompt the user about each newly-dumped key with options like "forget" (forget all about this key; don't bother me again), "skip" (remember about this key, but I don't need to use it this time), and "re-add" (please prompt me for the passphrase now so this key is available for ssh authentication in this ssh connection attempt) - something else? Arguably, if default behavior were "hold on to keys forever" (unless a separate command were issued to flush some/all of them), then there wouldn't be much need for ssh/ssh-agent to be friendly about re-adding keys that had timed out. -Peter -- One day you're gonna have to face the deep dark truthful mirror - E Costello From bugzilla-daemon at mindrot.org Fri Jan 18 00:27:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 00:27:49 +1100 (EST) Subject: [Bug 65] TCP Wrappers support does not log successful connections Message-ID: <20020117132749.C7644E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=65 ------- Additional Comments From mstone at cs.loyola.edu 2002-01-18 00:27 ------- I'm confused. If I set LogLevel VERBOSE in sshd_config, I get something like this in the syslog: Jan 17 08:12:39 myhost sshd[432]: Connection from somehost port someport What else is desired? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From a.d.stribblehill at durham.ac.uk Fri Jan 18 01:56:58 2002 From: a.d.stribblehill at durham.ac.uk (Andrew Stribblehill) Date: Thu, 17 Jan 2002 14:56:58 +0000 Subject: ssh-agent too easy to hack In-Reply-To: References: <1011227001.21733.20.camel@benway.cv.telegroup.com> Message-ID: <20020117145658.GE24427@womble.dur.ac.uk> Quoting Pekka Savola : > Me, for example, always xlock my workstation even if I go to talk to my > colleagues nearby. If sufficient care is observed, the time periods > should be usably long. Of course, if you're using xscreensaver, the following script helps: #!/usr/bin/perl -w # # screenwatch. Watches xscreensaver and drops keys when screen blanks. # Adds the default key on unblank. # # Typical usage: Put this command in your .xsession # # BUGS: Only adds the default key, not all the keys that it had before. # [Matter-of-taste] Drops keys on both blank and lock. use strict; use POSIX 'setsid'; sub daemonise { chdir '/' or die "Can't chdir to /: $!"; open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!"; defined(my $pid = fork) or die "Can't fork: $!"; exit if $pid; setsid or die "Can't start a new session: $!"; open STDERR, '>&STDOUT' or die "Can't dup stdout: $!"; } daemonise(); my $blanked = 0; open (IN, "/usr/bin/X11/xscreensaver-command -watch |"); while () { if (m/^(BLANK|LOCK)/) { if (!$blanked) { system("/usr/bin/ssh-add -D"); $blanked = 1; } } elsif (m/^UNBLANK/) { system("ssh-add"); $blanked = 0; } } I can't remember who wrote that, but it doesn't look like my code. -- MALIN HEBRIDES BAILEY WEST OR SOUTHWEST 5 OR 6 BACKING SOUTH OR SOUTHEAST 7 OR GALE 8, PERHAPS SEVERE GALE 9 LATER. SQUALLY SHOWERS THEN RAIN. GOOD BECOMING MODERATE From mouring at etoh.eviladmin.org Fri Jan 18 02:05:59 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 17 Jan 2002 09:05:59 -0600 (CST) Subject: ssh-agent discard timeout behavior (too easy to hack) In-Reply-To: <20020117080903.B20924@usa.net> Message-ID: On Thu, 17 Jan 2002, Peter Watkins wrote: > On Thu, Jan 17, 2002 at 09:19:45AM +0200, Pekka Savola wrote: > > On 16 Jan 2002, Aran Cox wrote: > > > Ideally you could choose both, dump the keys after a fixed period no > > > matter what and/or after a period of disuse. At least, that's what I've > > > always wanted. I'd dump them all after 4 hours no questions asked and > > > maybe an hour or two after their last use. > > > > What's the idea of such a short idle period? > > > > Me, for example, always xlock my workstation even if I go to talk to my > > colleagues nearby. If sufficient care is observed, the time periods > > should be usably long. > > Same here. I can see why folks might want such a feature, but I personally > would not need/want such behavior on some of my systems. I would personally > prefer that *default* behavior be current behavior; let folks add command > line arguments to request that certain keys be treated differently. > > Behavior question: let's say ssh-agent holds a key for sshd.example.com > If ssh-agent were to dump that key, should it > - forget about the key entirely (in which case, if the user were to > connect to sshd.example.com, the user would likely be prompted for > a regular password *after* ssh had already connected; if the user > needed/wanted to use their key, they'd have to abort the ssh connection > and re-add the key to ssh-agent before reconnecting) Why would it? The authorization phase has pasted. They would be prompted at the next connection for a password. - Ben From acox at ia.primustel.com Fri Jan 18 02:44:25 2002 From: acox at ia.primustel.com (Aran Cox) Date: 17 Jan 2002 09:44:25 -0600 Subject: ssh-agent too easy to hack In-Reply-To: References: Message-ID: <1011282265.11721.4.camel@benway.cv.telegroup.com> I didn't mean to imply that is what the defaults should be for ssh-agent, just that that is probably what I would set them too if I had those features. Probably I'd quickly get annoyed at entering my passphrase several times a day and set the timeouts for something longer. On Thu, 2002-01-17 at 01:19, Pekka Savola wrote: > On 16 Jan 2002, Aran Cox wrote: > > Ideally you could choose both, dump the keys after a fixed period no > > matter what and/or after a period of disuse. At least, that's what I've > > always wanted. I'd dump them all after 4 hours no questions asked and > > maybe an hour or two after their last use. > > What's the idea of such a short idle period? > > Me, for example, always xlock my workstation even if I go to talk to my > colleagues nearby. If sufficient care is observed, the time periods > should be usably long. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020117/3c5df97b/attachment.bin From fcusack at fcusack.com Fri Jan 18 03:45:18 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 17 Jan 2002 08:45:18 -0800 Subject: User-Dependent Identity File In-Reply-To: <20020115183551.6370.qmail@wizard.math.ualberta.ca>; from bowman@math.ualberta.ca on Tue, Jan 15, 2002 at 06:35:51PM -0000 References: <20020115005558.24140.qmail@wizard.math.ualberta.ca> <20020115131643.A19863@folly> <20020115154615.3727.qmail@wizard.math.ualberta.ca> <20020115162944.GB8644@faui02> <20020115180050.5792.qmail@wizard.math.ualberta.ca> <20020115180854.GB22105@faui02> <20020115183551.6370.qmail@wizard.math.ualberta.ca> Message-ID: <20020117084517.A3039@google.com> On Tue, Jan 15, 2002 at 06:35:51PM -0000, John Bowman wrote: > > > > > make /ssh a local (non-NFS) file system and use a syntax like this in the > > > > > system wide ssh_config file: > > > > > > > > > > IdentityFile /ssh/%u/id_rsa > > > > > > > > That's unlikely. > > > > > > > Oh? It is a serious security hole on many systems running openssh, so I'm > > > > really? even if it's on unprotected NFS, id_rsa is still encrypted. > I presume you mean using non-blank passphrases. Many people trust the > integrity of their local file systems and use blank pass phrases, rather > than using ssh-agent, etc. (a good example of where this is absolutely > necessary is for tunnelling lpd through ssh, see > http://www.math.ualberta.ca/imaging/snfs/lpd). But this means that id_rsa > can't be stored on an NFS mounted partition. Why does the lpd tunnelling desribed there require a blank passphrase? Why does storing the key on a local file system require %u? /fc From bugzilla-daemon at mindrot.org Fri Jan 18 05:33:04 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 05:33:04 +1100 (EST) Subject: [Bug 72] New: sshd 3.0.2p1 assumes authorized_keys2 unless configured otherwise. Message-ID: <20020117183304.7DD61EA0A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=72 Summary: sshd 3.0.2p1 assumes authorized_keys2 unless configured otherwise. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: maupin at easystreet.com This bug report is similar to bug id 66. sshd 3.0.2p1 defaults to ~/.ssh/authorized_keys2 unless "AuthorizedKeysFile %h/.ssh/authorized_keys" is set in sshd_config. AuthorizedKeysFile is unset in the default sshd_config installed with OpenSSH. This behavior directly conflicts with statements in the change log that authorized_keys2 has been deprecated. I've observed this behavior under x86 Linux 6.2 and 7.1 and SPARC Solaris 7. OpenSSH was compiled from source in all cases. OpenSSH is a terrific product, keep up the great work! ------- 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 Jan 18 05:49:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 05:49:10 +1100 (EST) Subject: [Bug 72] sshd 3.0.2p1 assumes authorized_keys2 unless configured otherwise. Message-ID: <20020117184910.40B43EA0F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=72 ------- Additional Comments From markus at openbsd.org 2002-01-18 05:49 ------- can you prove this with a sshd output? e.g. from sshd -ddd ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at mcgarry.ch Fri Jan 18 09:17:19 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Thu, 17 Jan 2002 23:17:19 +0100 Subject: Dumping Keys under certain conditions (Re: ssh-agent too easy to hack) References: <1011227001.21733.20.camel@benway.cv.telegroup.com> <20020117145658.GE24427@womble.dur.ac.uk> Message-ID: <002201c19fa4$bad10d00$c902a8c0@cablecom.ch> I often tunnel through SSH to vnc, so dumping the keys on disconnect is more interesting than looking for a screensaver. I've decided whether to get SSHD (if given the environment reqd to contact ssh-agent) to tell the agent to dump the keys when the forwarded port is closed. The other alternative is to make the change in the vnc server. ----- Original Message ----- From: "Andrew Stribblehill" To: Sent: Thursday, January 17, 2002 3:56 PM Subject: Re: ssh-agent too easy to hack > Quoting Pekka Savola : > > Me, for example, always xlock my workstation even if I go to talk to my > > colleagues nearby. If sufficient care is observed, the time periods > > should be usably long. > > Of course, if you're using xscreensaver, the following script helps: > > #!/usr/bin/perl -w > # > # screenwatch. Watches xscreensaver and drops keys when screen blanks. > # Adds the default key on unblank. > # > # Typical usage: Put this command in your .xsession > # > # BUGS: Only adds the default key, not all the keys that it had before. > # [Matter-of-taste] Drops keys on both blank and lock. > > use strict; > use POSIX 'setsid'; > > sub daemonise { > chdir '/' or die "Can't chdir to /: $!"; > open STDIN, '/dev/null' or die "Can't read /dev/null: $!"; > open STDOUT, '>/dev/null' or die "Can't write to /dev/null: $!"; > defined(my $pid = fork) or die "Can't fork: $!"; > exit if $pid; > setsid or die "Can't start a new session: $!"; > open STDERR, '>&STDOUT' or die "Can't dup stdout: $!"; > } > > daemonise(); > my $blanked = 0; > open (IN, "/usr/bin/X11/xscreensaver-command -watch |"); > while () { > if (m/^(BLANK|LOCK)/) { > if (!$blanked) { > system("/usr/bin/ssh-add -D"); > $blanked = 1; > } > } elsif (m/^UNBLANK/) { > system("ssh-add"); > $blanked = 0; > } > } > > > I can't remember who wrote that, but it doesn't look like my code. > > -- > MALIN HEBRIDES BAILEY > WEST OR SOUTHWEST 5 OR 6 BACKING SOUTH OR SOUTHEAST 7 OR GALE 8, > PERHAPS SEVERE GALE 9 LATER. SQUALLY SHOWERS THEN RAIN. GOOD > BECOMING MODERATE > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Fri Jan 18 09:38:44 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 17 Jan 2002 17:38:44 -0500 Subject: Dumping Keys under certain conditions (Re: ssh-agent too easy to hack) In-Reply-To: <002201c19fa4$bad10d00$c902a8c0@cablecom.ch>; from tim@mcgarry.ch on Thu, Jan 17, 2002 at 11:17:19PM +0100 References: <1011227001.21733.20.camel@benway.cv.telegroup.com> <20020117145658.GE24427@womble.dur.ac.uk> <002201c19fa4$bad10d00$c902a8c0@cablecom.ch> Message-ID: <20020117173843.K27398@sm2p1386swk.wdr.com> On Thu, Jan 17, 2002 at 11:17:19PM +0100, Tim McGarry wrote: > I often tunnel through SSH to vnc, so dumping the keys on disconnect is more > interesting than looking for a screensaver. I've decided whether to get SSHD > (if given the environment reqd to contact ssh-agent) to tell the agent to > dump the keys when the forwarded port is closed. The other alternative is to > make the change in the vnc server. If you want your agent's keys to be one-time use then don't use ssh-agent at all. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at mcgarry.ch Fri Jan 18 10:20:15 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Fri, 18 Jan 2002 00:20:15 +0100 Subject: Dumping Keys under certain conditions (Re: ssh-agent too easy to hack) References: <1011227001.21733.20.camel@benway.cv.telegroup.com> <20020117145658.GE24427@womble.dur.ac.uk> <002201c19fa4$bad10d00$c902a8c0@cablecom.ch> <20020117173843.K27398@sm2p1386swk.wdr.com> Message-ID: <005201c19fad$85fd1980$c902a8c0@cablecom.ch> You're not familiar with VNC are you? (http://www.uk.research.att.com/vnc/) I suggest you check it out, it has a few advantages over tunneling X through SSH, I find it's really good for remote unix support via a Windoze based extranet client. If you lose the connection you X sessions still exist when you reconnect. I'd like the key to last for the lifetime of the connection (starting as many ssh sessions as I like). When I reconnect, reload the keys and then again start as many SSH sessions as I like. vncviewer on host A->tunnelled through SSH to host B, running Xvnc and ssh-agent, -> Multiple SSH connections to hosts C,D,E,F..Z The connection between A and B can be dropped as reqd. Cheers Tim ----- Original Message ----- From: "Nicolas Williams" To: "Tim McGarry" Cc: "Andrew Stribblehill" ; Sent: Thursday, January 17, 2002 11:38 PM Subject: Re: Dumping Keys under certain conditions (Re: ssh-agent too easy to hack) > On Thu, Jan 17, 2002 at 11:17:19PM +0100, Tim McGarry wrote: > > I often tunnel through SSH to vnc, so dumping the keys on disconnect is more > > interesting than looking for a screensaver. I've decided whether to get SSHD > > (if given the environment reqd to contact ssh-agent) to tell the agent to > > dump the keys when the forwarded port is closed. The other alternative is to > > make the change in the vnc server. > > If you want your agent's keys to be one-time use then don't use > ssh-agent at all. > > Nico > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > From bugzilla-daemon at mindrot.org Fri Jan 18 11:38:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 11:38:22 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020118003822.D4FAEEA2F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 ------- Additional Comments From djm at mindrot.org 2002-01-18 11:38 ------- The patch is nice and shorter too. The "yes"/"no" response won't be visible in the SSH_ASKPASS program, but I don't think this is a major problem. Perhaps we could arrange some standard way to tell the askpass to echo (cmdline arg?) CCing jmknoble at pobox.com as the author of x11-ssh-askpass ------- 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 Jan 18 11:46:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 11:46:06 +1100 (EST) Subject: [Bug 71] configure is looking for zlib but I don't have one and I can't turn zlib off. Message-ID: <20020118004606.9859DEA2F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=71 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-18 11:46 ------- Zlib is not optional - it is a mandatory part of OpenSSH. You should install it. If you have zlib installed, you may need to tell configure where to look for 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 Fri Jan 18 14:59:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 14:59:31 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020118035931.61334E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 ------- Additional Comments From djm at mindrot.org 2002-01-18 14:59 ------- oops - I failed to see that Jim was already reading this. I wouldn't want a click-for-accept-this-key dialog box. Forcing people to type "yes" has a hope of making them stop and think for a second or two about the validity of the key. ------- 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 Jan 18 21:15:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 18 Jan 2002 21:15:15 +1100 (EST) Subject: [Bug 73] New: sftp segfaults on an attempt to up/download a nonexistent file Message-ID: <20020118101515.4B2A6E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=73 Summary: sftp segfaults on an attempt to up/download a nonexistent file Product: Portable OpenSSH Version: -current Platform: ix86 URL: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34019 OS/Version: FreeBSD Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: roam at ringlet.net When the name of a non-existent file is given as the argument to a 'get' or 'put' command, sftp(1) fails to interpret correctly the result of the glob(3) invocation. glob(3) does not return an error (a non-zero exit), yet it does not return any meaningful file names, either, so process_get() and process_put()'s attempts to access the gl_pathv[] array fail miserably. A trivial patch is posted in the audit-trail of the FreeBSD problem report referenced by the URL above. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From atossava at cc.helsinki.fi Sat Jan 19 01:33:49 2002 From: atossava at cc.helsinki.fi (Atro Tossavainen) Date: Fri, 18 Jan 2002 16:33:49 +0200 (EET) Subject: KTH krb4 and OpenSSL conflict building OpenSSH 3.0.2p1 Message-ID: <200201181433.g0IEXnC12066@kruuna.Helsinki.FI> Hi, I configured OpenSSH 3.0.2p1 with ./configure --disable-suid-ssh --with-pam --with-kerberos4=/usr/athena \ --with-afs=/usr/afsws --with-ipaddr-display \ --with-ssl-dir=/afs/bi/v/@sys/libraries/openssl/latest My "latest" OpenSSL is 0.9.6a. KTH krb4 is 1.1. When linking the binaries, the KTH krb4 libdes conflicts with the OpenSSL libdes. It seems to be possible to get around this like this: where make emits gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/afs/bi/v/@sys/libraries/openssl/latest/lib -L/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv -ldes -lkrb -lpam -ldl -lutil -lz -lnsl -lcrypto -ldes substitute gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -L/afs/bi/v/@sys/libraries/openssl/latest/lib -L/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv -lkrb -lpam -ldl -lutil -lz -lnsl -lcrypto -L/afs/bi/v/@sys/libraries/openssl/latest/lib -ldes instead. I don't know if the resulting binaries work, but at least it gets around the conflict. Since OpenSSL is a requirement for OpenSSH, I would imagine the people who implemented krb4 support would have come across this already. Which obvious part am I missing? -- Atro Tossavainen (Mr.) / The Institute of Biotechnology at Systems Analyst, Techno-Amish & / the University of Helsinki, Finland, +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own. < URL : http : / / www . iki . fi / atro . tossavainen / > File attachments NOT welcome unless agreed to beforehand. From Nicolas.Williams at ubsw.com Sat Jan 19 01:39:31 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 18 Jan 2002 09:39:31 -0500 Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app In-Reply-To: <20020118035931.61334E8FF@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Fri, Jan 18, 2002 at 02:59:31PM +1100 References: <20020118035931.61334E8FF@shitei.mindrot.org> Message-ID: <20020118093929.L27398@sm2p1386swk.wdr.com> On Fri, Jan 18, 2002 at 02:59:31PM +1100, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=70 > > ------- Additional Comments From djm at mindrot.org 2002-01-18 14:59 ------- > oops - I failed to see that Jim was already reading this. > > I wouldn't want a click-for-accept-this-key dialog box. Forcing people to type > "yes" has a hope of making them stop and think for a second or two about the > validity of the key. Why? What difference does it make whether the question is asked on stdio or whether it's handled otherwise? What matters is that the question is asked and that the client does not proceed until it is answered. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Sat Jan 19 02:41:26 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 18 Jan 2002 16:41:26 +0100 Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app In-Reply-To: <20020118093929.L27398@sm2p1386swk.wdr.com> References: <20020118035931.61334E8FF@shitei.mindrot.org> <20020118093929.L27398@sm2p1386swk.wdr.com> Message-ID: <20020118154126.GA522@faui02> who did try the diff? > > http://bugzilla.mindrot.org/show_bug.cgi?id=70 From robert.shih at uk.nomura.com Sat Jan 19 02:53:58 2002 From: robert.shih at uk.nomura.com (Shih, Robert) Date: Fri, 18 Jan 2002 15:53:58 -0000 Subject: scp between two remote hosts Message-ID: Hi All, I am running openssh (OpenSSH_2.9p1, SSH protocols 1.5/2.0). The scenario is that I have got three machines (A, B and C). The sshd on host A is listensing on port 1234, and the sshd on host B is listensing on port 5678. How can I set up a scp from a third host C so as to copy a file from host A to host B? scp -P 1234 myname at A:/var/tmp/file1 -P 5678 myname at B:/var/tmp/file1 does not work and C always try to connect to sshd on A at port 22. Rgds. Bob Shih PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it and you should delete it and notify the sender immediately. Email is not a secure method of communication and Nomura International plc cannot accept responsibility for the accuracy or completeness of this message or any attachment(s). Please examine this email for virus infection, for which Nomura International plc accepts no responsibility. If verification of this email is sought then please request a hard copy. Unless otherwise stated any views or opinions presented are solely those of the author and do not represent those of Nomura International plc. This email is intended for informational purposes only and is not a solicitation or offer to buy or sell securities or related financial instruments. Nomura International plc is regulated by the Financial Services Authority and is a member of the London Stock Exchange. From peterw at usa.net Sat Jan 19 03:46:48 2002 From: peterw at usa.net (Peter Watkins) Date: Fri, 18 Jan 2002 11:46:48 -0500 Subject: scp between two remote hosts In-Reply-To: ; from robert.shih@uk.nomura.com on Fri, Jan 18, 2002 at 03:53:58PM -0000 References: Message-ID: <20020118114648.A11100@usa.net> On Fri, Jan 18, 2002 at 03:53:58PM -0000, Shih, Robert wrote: > I am running openssh (OpenSSH_2.9p1, SSH protocols 1.5/2.0). The scenario > is that I have got three machines (A, B and C). The sshd on host A is > listensing on port 1234, and the sshd on host B is listensing on port 5678. > How can I set up a scp from a third host C so as to copy a file from host A > to host B? You'll have to be creative, I think. > scp -P 1234 myname at A:/var/tmp/file1 -P 5678 myname at B:/var/tmp/file1 ssh -p 1234 myname at A "scp -P 5678 /var/tmp/file1 myname at B:/var/tmp/file1" You'd probably need to use keypair, shosts, etc. to authenticate A -> B. ssh -p 1234 myname at A "cat /var/tmp/file1" | ssh -p 5678 myname at B "cat > /var/tmp/file1" I think either of those tricks would work. The first is more efficient, as the data only crosses the network once, but authentication may be sticky; it doesn't work for me if A -> B needs interactive password authentication. The second is more likely to work easily, but the file had to go through A -> C and C -> B, which is a waste of bandwidth, and might not work, as you never said whether C could communicate directly with B. The second trick definitely works, though with my 2.5.2p2 systems, using password auth for both C -> A and C -> B connections, my terminal prompts me for both passwords on the same line. I enter one, press return, and then the other, ad pres return. The second password I type is echoed to my screen. Oops. Maybe someone could try that with the latest release and/or CVS? -Peter From macro at ds2.pg.gda.pl Sat Jan 19 03:55:28 2002 From: macro at ds2.pg.gda.pl (Maciej W. Rozycki) Date: Fri, 18 Jan 2002 17:55:28 +0100 (MET) Subject: [patch] openssh 3.0.2p1: Libwrap gets linked in unnecessarily Message-ID: Hello, There is a small but annoying problem with linking libwrap in openssh. The library is added to LIBS which makes it be linked in to all binaries. This is unnecessary and leads to bogus dependencies if libwrap is a shared library. Following is a trivial fix that reserves a separate autoconf substitution variable LIBWRAP, which is only used for sshd. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro at ds2.pg.gda.pl, PGP key available + openssh-3.0.1p1-libwrap.patch diff -up --recursive --new-file openssh-3.0.1p1.macro/Makefile.in openssh-3.0.1p1/Makefile.in --- openssh-3.0.1p1.macro/Makefile.in Sun Nov 11 23:34:23 2001 +++ openssh-3.0.1p1/Makefile.in Wed Dec 19 21:34:07 2001 @@ -30,6 +30,7 @@ LD=@LD@ CFLAGS=@CFLAGS@ CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@ LIBS=@LIBS@ +LIBWRAP=@LIBWRAP@ AR=@AR@ RANLIB=@RANLIB@ INSTALL=@INSTALL@ @@ -98,7 +99,7 @@ ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SS $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) - $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) + $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(LIBWRAP) scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o $(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) diff -up --recursive --new-file openssh-3.0.1p1.macro/configure.ac openssh-3.0.1p1/configure.ac --- openssh-3.0.1p1.macro/configure.ac Sat Nov 3 19:09:33 2001 +++ openssh-3.0.1p1/configure.ac Wed Dec 19 21:37:19 2001 @@ -546,7 +546,8 @@ AC_ARG_WITH(tcp-wrappers, CPPFLAGS="-I${withval} ${CPPFLAGS}" fi fi - LIBS="-lwrap $LIBS" + LIBWRAP="-lwrap" + LIBS="$LIBS $LIBWRAP" AC_MSG_CHECKING(for libwrap) AC_TRY_LINK( [ @@ -557,12 +558,14 @@ AC_ARG_WITH(tcp-wrappers, [ AC_MSG_RESULT(yes) AC_DEFINE(LIBWRAP) + AC_SUBST(LIBWRAP) TCPW_MSG="yes" ], [ AC_MSG_ERROR([*** libwrap missing]) ] ) + LIBS="$saved_LIBS" fi ] ) From bugzilla-daemon at mindrot.org Sat Jan 19 04:25:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 19 Jan 2002 04:25:37 +1100 (EST) Subject: [Bug 74] New: Use of sig_atomic_t breaks SunOS4 compile Message-ID: <20020118172537.5ECB0EA46@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=74 Summary: Use of sig_atomic_t breaks SunOS4 compile Product: Portable OpenSSH Version: -current Platform: Other OS/Version: SunOS Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dwd at bell-labs.com The use of sig_atomic_t in clientloop.c, serverloop.c, and sshd.c causes compilation to bomb on SunOS 4.1.4 where that type is not defined. Markus added it on November 22. Should the use of the type be removed or should there be a configure test to add the typedef if it is not found? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Todd.Miller at courtesan.com Sat Jan 19 04:22:57 2002 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 18 Jan 2002 10:22:57 -0700 Subject: [Bug 74] New: Use of sig_atomic_t breaks SunOS4 compile In-Reply-To: Your message of "Sat, 19 Jan 2002 04:25:37 +1100." <20020118172537.5ECB0EA46@shitei.mindrot.org> References: <20020118172537.5ECB0EA46@shitei.mindrot.org> Message-ID: <200201181722.g0IHMv1c029658@xerxes.courtesan.com> In message <20020118172537.5ECB0EA46 at shitei.mindrot.org> so spake (bugzilla-daemon): > The use of sig_atomic_t in clientloop.c, serverloop.c, and sshd.c causes > compilation to bomb on SunOS 4.1.4 where that type is not defined. > Markus added it on November 22. Should the use of the type be removed > or should there be a configure test to add the typedef if it is not found? A configure.in test should be added. Perhaps something like this AC_CHECK_TYPES([sig_atomic_t], , [AC_DEFINE(sig_atomic_t, int, [Define to `int' if does not define.])], [#include #include ]) - todd From rmallory at ensemblecom.com Sat Jan 19 07:02:06 2002 From: rmallory at ensemblecom.com (Rob Mallory) Date: Fri, 18 Jan 2002 12:02:06 -0800 Subject: contrib/solaris/opensshd.in patch Message-ID: <20020118120206.A51986@mystery.ensemblecom.com> This patch adds the seatbelts which _only_ kill parent sshd procs... -RMallory (eg: when you ssh into a machine and pkgadd the new openssh, it will not kill your current (or anyone else's sshd session) onanother_note: the buildpkg.sh could use some exec_prefix functionality... to deal with ./configure --prefix= --exec_prefix=/usr *** bak/opensshd.in Fri Oct 19 13:36:24 2001 --- opensshd.in Fri Jan 18 11:47:10 2002 *************** *** 8,16 **** KILL=/usr/bin/kill PS=/usr/bin/ps XARGS=/usr/bin/xargs prefix=%%openSSHDir%% --- 8,19 ---- KILL=/usr/bin/kill PS=/usr/bin/ps XARGS=/usr/bin/xargs + FGREP=/usr/bin/fgrep + EGREP=/usr/bin/egrep + ME=`/usr/bin/basename $0` prefix=%%openSSHDir%% *************** *** 22,29 **** killproc() { _procname=$1 ! _signal=$2 ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} } --- 25,42 ---- killproc() { _procname=$1 ! ! #The next line finds only the parent of $_procname if it exists ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` ! ! if [ -z "$PID" ] ; then ! echo "No parent sshd process found..." ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}'` ! test -z "$PID" && /usr/bin/echo "No sshd children found..." ! test -z "$PID" || /usr/bin/echo "Not killing these sshd children: \n$PID" ! else echo "Killing $PID" ; ${KILL} ${PID} ! fi } From mouring at etoh.eviladmin.org Sat Jan 19 07:04:41 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 18 Jan 2002 14:04:41 -0600 (CST) Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020118120206.A51986@mystery.ensemblecom.com> Message-ID: On Fri, 18 Jan 2002, Rob Mallory wrote: > This patch adds the seatbelts which _only_ kill parent sshd procs... -RMallory > (eg: when you ssh into a machine and pkgadd the new openssh, it will not > kill your current (or anyone else's sshd session) > > onanother_note: the buildpkg.sh could use some exec_prefix functionality... > to deal with ./configure --prefix= --exec_prefix=/usr > It should handle them. Can you give me a case wher eit does not? Since the buildpkg.sh is fake root based any --*prefix* options should work naturally. I would perfer the patch in -u format, but I'll look it over. - Ben From Zoran.Milojevic at SS8.com Sat Jan 19 08:04:27 2002 From: Zoran.Milojevic at SS8.com (Zoran Milojevic) Date: Fri, 18 Jan 2002 16:04:27 -0500 Subject: contrib/solaris/opensshd.in patch Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69A195A5@mail.ss8.ca> Here's a bit simpler change that accomplishes the same task: --- ./opensshd.in.old Fri Jan 18 15:47:21 2002 +++ ./opensshd.in Fri Jan 18 15:47:00 2002 @@ -23,7 +23,9 @@ killproc() { _procname=$1 _signal=$2 - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} + ${PS} -opid,ppid,fname -u root |\ + ${AWK} '/'"$_procname"'$/ {if ($2 == "1") {print $1}}' |\ + ${XARGS} ${KILL} -s $_signal } Zoran -- Zoran Milojevic SS8 Networks Inc. http://www.ss8.com "One Better" Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > -----Original Message----- > From: Rob Mallory [mailto:rmallory at ensemblecom.com] > Sent: January 18, 2002 15:02 > To: openssh-unix-dev at mindrot.org > Subject: contrib/solaris/opensshd.in patch > > > This patch adds the seatbelts which _only_ kill parent sshd > procs... -RMallory > (eg: when you ssh into a machine and pkgadd the new openssh, > it will not > kill your current (or anyone else's sshd session) > > onanother_note: the buildpkg.sh could use some exec_prefix > functionality... > to deal with ./configure --prefix= --exec_prefix=/usr > > *** bak/opensshd.in Fri Oct 19 13:36:24 2001 > --- opensshd.in Fri Jan 18 11:47:10 2002 > *************** > *** 8,16 **** > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > > prefix=%%openSSHDir%% > --- 8,19 ---- > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > + FGREP=/usr/bin/fgrep > + EGREP=/usr/bin/egrep > + ME=`/usr/bin/basename $0` > > prefix=%%openSSHDir%% > *************** > *** 22,29 **** > > killproc() { > _procname=$1 > ! _signal=$2 > ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | > ${XARGS} ${KILL} > } > > > --- 25,42 ---- > > killproc() { > _procname=$1 > ! > ! #The next line finds only the parent of $_procname if it exists > ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ > ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` > ! > ! if [ -z "$PID" ] ; then > ! echo "No parent sshd process found..." > ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ > {print $1}'` > ! test -z "$PID" && /usr/bin/echo "No sshd > children found..." > ! test -z "$PID" || /usr/bin/echo "Not killing > these sshd children: \n$PID" > ! else echo "Killing $PID" ; ${KILL} ${PID} > ! fi > } > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020118/d35d96f4/attachment.html From rmallory at ensemble.com Sat Jan 19 08:22:49 2002 From: rmallory at ensemble.com (Rob Mallory) Date: Fri, 18 Jan 2002 13:22:49 -0800 Subject: contrib/solaris/opensshd.in patch Message-ID: <2CED9BC6F755D5118B520002B302951D307390@copeland.ensemblecom.com> Did you try it? it seems to kill all sshd's here. specificaly, you (or at least I)_don't_ want to kill anything where $2=="1" from the ps -opid,ppid,fname line to be killed. also I don't want to kill parents of any procs called "opensshd" which is the name of the script. -Rob -----Original Message----- From: Zoran Milojevic [mailto:Zoran.Milojevic at SS8.com] Sent: Friday, January 18, 2002 1:04 PM To: openssh-unix-dev at shitei.mindrot.org Cc: 'Rob Mallory' Subject: RE: contrib/solaris/opensshd.in patch Here's a bit simpler change that accomplishes the same task: --- ./opensshd.in.old Fri Jan 18 15:47:21 2002 +++ ./opensshd.in Fri Jan 18 15:47:00 2002 @@ -23,7 +23,9 @@ killproc() { _procname=$1 _signal=$2 - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} + ${PS} -opid,ppid,fname -u root |\ + ${AWK} '/'"$_procname"'$/ {if ($2 == "1") {print $1}}' |\ + ${XARGS} ${KILL} -s $_signal } Zoran -- Zoran Milojevic SS8 Networks Inc. http://www.ss8.com "One Better" Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > -----Original Message----- > From: Rob Mallory [ mailto:rmallory at ensemblecom.com ] > Sent: January 18, 2002 15:02 > To: openssh-unix-dev at mindrot.org > Subject: contrib/solaris/opensshd.in patch > > > This patch adds the seatbelts which _only_ kill parent sshd > procs... -RMallory > (eg: when you ssh into a machine and pkgadd the new openssh, > it will not > kill your current (or anyone else's sshd session) > > onanother_note: the buildpkg.sh could use some exec_prefix > functionality... > to deal with ./configure --prefix= --exec_prefix=/usr > > *** bak/opensshd.in Fri Oct 19 13:36:24 2001 > --- opensshd.in Fri Jan 18 11:47:10 2002 > *************** > *** 8,16 **** > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > > prefix=%%openSSHDir%% > --- 8,19 ---- > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > + FGREP=/usr/bin/fgrep > + EGREP=/usr/bin/egrep > + ME=`/usr/bin/basename $0` > > prefix=%%openSSHDir%% > *************** > *** 22,29 **** > > killproc() { > _procname=$1 > ! _signal=$2 > ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | > ${XARGS} ${KILL} > } > > > --- 25,42 ---- > > killproc() { > _procname=$1 > ! > ! #The next line finds only the parent of $_procname if it exists > ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ > ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` > ! > ! if [ -z "$PID" ] ; then > ! echo "No parent sshd process found..." > ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ > {print $1}'` > ! test -z "$PID" && /usr/bin/echo "No sshd > children found..." > ! test -z "$PID" || /usr/bin/echo "Not killing > these sshd children: \n$PID" > ! else echo "Killing $PID" ; ${KILL} ${PID} > ! fi > } > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020118/8e62832e/attachment.html From celinn at mtu.edu Sat Jan 19 08:30:07 2002 From: celinn at mtu.edu (Christopher Linn) Date: Fri, 18 Jan 2002 16:30:07 -0500 Subject: contrib/solaris/opensshd.in patch In-Reply-To: <2CED9BC6F755D5118B520002B302951D307390@copeland.ensemblecom.com>; from rmallory@ensemble.com on Fri, Jan 18, 2002 at 01:22:49PM -0800 References: <2CED9BC6F755D5118B520002B302951D307390@copeland.ensemblecom.com> Message-ID: <20020118163007.B28145@mtu.edu> On Fri, Jan 18, 2002 at 01:22:49PM -0800, Rob Mallory wrote: [...] > also I don't want to kill parents of any procs called "opensshd" > which is the name of the script. fog this reason, it is a good idea to name the init.d script like "openssh" instead of "opensshd". > -Rob chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From rmallory at ensemble.com Sat Jan 19 08:37:24 2002 From: rmallory at ensemble.com (Rob Mallory) Date: Fri, 18 Jan 2002 13:37:24 -0800 Subject: contrib/solaris/opensshd.in patch Message-ID: <2CED9BC6F755D5118B520002B302951D307391@copeland.ensemblecom.com> Hmmm.. you are right. Dunno what I omitted when cut n pasted your (nice and unbloated) version. ...and yes, I do want to kill the one who $ppid=1, {was stuck in thinking ass-backwards like my example} yeppers..... anyways, I hope people agree this'd be nice to have in the tree..... it saved my butt a few times in the past... -----Original Message----- From: Rob Mallory [mailto:rmallory at ensemble.com] Sent: Friday, January 18, 2002 1:23 PM To: 'Zoran Milojevic'; openssh-unix-dev at shitei.mindrot.org Cc: 'Rob Mallory' Subject: RE: contrib/solaris/opensshd.in patch Did you try it? it seems to kill all sshd's here. specificaly, you (or at least I)_don't_ want to kill anything where $2=="1" from the ps -opid,ppid,fname line to be killed. also I don't want to kill parents of any procs called "opensshd" which is the name of the script. -Rob -----Original Message----- From: Zoran Milojevic [mailto:Zoran.Milojevic at SS8.com] Sent: Friday, January 18, 2002 1:04 PM To: openssh-unix-dev at shitei.mindrot.org Cc: 'Rob Mallory' Subject: RE: contrib/solaris/opensshd.in patch Here's a bit simpler change that accomplishes the same task: --- ./opensshd.in.old Fri Jan 18 15:47:21 2002 +++ ./opensshd.in Fri Jan 18 15:47:00 2002 @@ -23,7 +23,9 @@ killproc() { _procname=$1 _signal=$2 - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} + ${PS} -opid,ppid,fname -u root |\ + ${AWK} '/'"$_procname"'$/ {if ($2 == "1") {print $1}}' |\ + ${XARGS} ${KILL} -s $_signal } Zoran -- Zoran Milojevic SS8 Networks Inc. http://www.ss8.com "One Better" Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > -----Original Message----- > From: Rob Mallory [ mailto:rmallory at ensemblecom.com ] > Sent: January 18, 2002 15:02 > To: openssh-unix-dev at mindrot.org > Subject: contrib/solaris/opensshd.in patch > > > This patch adds the seatbelts which _only_ kill parent sshd > procs... -RMallory > (eg: when you ssh into a machine and pkgadd the new openssh, > it will not > kill your current (or anyone else's sshd session) > > onanother_note: the buildpkg.sh could use some exec_prefix > functionality... > to deal with ./configure --prefix= --exec_prefix=/usr > > *** bak/opensshd.in Fri Oct 19 13:36:24 2001 > --- opensshd.in Fri Jan 18 11:47:10 2002 > *************** > *** 8,16 **** > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > > prefix=%%openSSHDir%% > --- 8,19 ---- > KILL=/usr/bin/kill > PS=/usr/bin/ps > XARGS=/usr/bin/xargs > + FGREP=/usr/bin/fgrep > + EGREP=/usr/bin/egrep > + ME=`/usr/bin/basename $0` > > prefix=%%openSSHDir%% > *************** > *** 22,29 **** > > killproc() { > _procname=$1 > ! _signal=$2 > ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | > ${XARGS} ${KILL} > } > > > --- 25,42 ---- > > killproc() { > _procname=$1 > ! > ! #The next line finds only the parent of $_procname if it exists > ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ > ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` > ! > ! if [ -z "$PID" ] ; then > ! echo "No parent sshd process found..." > ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ > {print $1}'` > ! test -z "$PID" && /usr/bin/echo "No sshd > children found..." > ! test -z "$PID" || /usr/bin/echo "Not killing > these sshd children: \n$PID" > ! else echo "Killing $PID" ; ${KILL} ${PID} > ! fi > } > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020118/ef98ef53/attachment.html From mouring at etoh.eviladmin.org Sat Jan 19 08:50:47 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 18 Jan 2002 15:50:47 -0600 (CST) Subject: contrib/solaris/opensshd.in patch In-Reply-To: <2CED9BC6F755D5118B520002B302951D307391@copeland.ensemblecom.com> Message-ID: If we are in agreed. Then I'll be happy to commit this change. - Ben On Fri, 18 Jan 2002, Rob Mallory wrote: > Hmmm.. you are right. Dunno what I omitted when > cut n pasted your (nice and unbloated) version. > ...and yes, I do want to kill the one who $ppid=1, > {was stuck in thinking ass-backwards like my example} > yeppers..... > anyways, I hope people agree this'd be nice to have > in the tree..... it saved my butt a few times in the past... > > > -----Original Message----- > From: Rob Mallory [mailto:rmallory at ensemble.com] > Sent: Friday, January 18, 2002 1:23 PM > To: 'Zoran Milojevic'; openssh-unix-dev at shitei.mindrot.org > Cc: 'Rob Mallory' > Subject: RE: contrib/solaris/opensshd.in patch > > > Did you try it? it seems to kill all sshd's here. > specificaly, you (or at least I)_don't_ want to kill anything where $2=="1" > from the ps -opid,ppid,fname line to be killed. > > also I don't want to kill parents of any procs called "opensshd" > which is the name of the script. > -Rob > > -----Original Message----- > From: Zoran Milojevic [mailto:Zoran.Milojevic at SS8.com] > Sent: Friday, January 18, 2002 1:04 PM > To: openssh-unix-dev at shitei.mindrot.org > Cc: 'Rob Mallory' > Subject: RE: contrib/solaris/opensshd.in patch > > > > Here's a bit simpler change that accomplishes the same task: > > --- ./opensshd.in.old Fri Jan 18 15:47:21 2002 > +++ ./opensshd.in Fri Jan 18 15:47:00 2002 > @@ -23,7 +23,9 @@ > killproc() { > _procname=$1 > _signal=$2 > - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} > > + ${PS} -opid,ppid,fname -u root |\ > + ${AWK} '/'"$_procname"'$/ {if ($2 == "1") {print $1}}' |\ > + ${XARGS} ${KILL} -s $_signal > } > > Zoran > -- > Zoran Milojevic > SS8 Networks Inc. http://www.ss8.com > "One Better" > Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > > > > -----Original Message----- > > From: Rob Mallory [ mailto:rmallory at ensemblecom.com > ] > > Sent: January 18, 2002 15:02 > > To: openssh-unix-dev at mindrot.org > > Subject: contrib/solaris/opensshd.in patch > > > > > > This patch adds the seatbelts which _only_ kill parent sshd > > procs... -RMallory > > (eg: when you ssh into a machine and pkgadd the new openssh, > > it will not > > kill your current (or anyone else's sshd session) > > > > onanother_note: the buildpkg.sh could use some exec_prefix > > functionality... > > to deal with ./configure --prefix= --exec_prefix=/usr > > > > *** bak/opensshd.in Fri Oct 19 13:36:24 2001 > > --- opensshd.in Fri Jan 18 11:47:10 2002 > > *************** > > *** 8,16 **** > > KILL=/usr/bin/kill > > PS=/usr/bin/ps > > XARGS=/usr/bin/xargs > > > > prefix=%%openSSHDir%% > > --- 8,19 ---- > > KILL=/usr/bin/kill > > PS=/usr/bin/ps > > XARGS=/usr/bin/xargs > > + FGREP=/usr/bin/fgrep > > + EGREP=/usr/bin/egrep > > + ME=`/usr/bin/basename $0` > > > > prefix=%%openSSHDir%% > > *************** > > *** 22,29 **** > > > > killproc() { > > _procname=$1 > > ! _signal=$2 > > ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | > > ${XARGS} ${KILL} > > } > > > > > > --- 25,42 ---- > > > > killproc() { > > _procname=$1 > > ! > > ! #The next line finds only the parent of $_procname if it exists > > ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ > > ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` > > ! > > ! if [ -z "$PID" ] ; then > > ! echo "No parent sshd process found..." > > ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ > > {print $1}'` > > ! test -z "$PID" && /usr/bin/echo "No sshd > > children found..." > > ! test -z "$PID" || /usr/bin/echo "Not killing > > these sshd children: \n$PID" > > ! else echo "Killing $PID" ; ${KILL} ${PID} > > ! fi > > } > > > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > From prkumar at nortelnetworks.com Sat Jan 19 09:01:45 2002 From: prkumar at nortelnetworks.com (Prashant Kumar) Date: Fri, 18 Jan 2002 17:01:45 -0500 Subject: OpenSsh to Vxworks Message-ID: <001601c1a06b$b922e060$658920c0@engeast.baynetworks.com> Hello Group, I'm not registered in this mailing list, however it will be great if someone can help me with these questions: I have "OpenSsl" up and running on Vxworks. How difficult will it be to port OpenSsh "server" part on to Vxworks ?. Should I take the portable version or the regular version ?. Just compiling LIBSSH_OBJ, SSH_OBJ, SSHD_OBJ, LIBCOMPAT will serve my purpose or do I need any other OBJ's ? [I read from one of the mails in the archive that these are the OBJ's I have to build]. Any idea on the time required to port will be great . Thank you in advance. Regards, Prashant. From dwd at bell-labs.com Sat Jan 19 09:08:41 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 18 Jan 2002 16:08:41 -0600 Subject: Potential SSH2 exploit In-Reply-To: <20020112002220.A18140@pianosa.catch22.org>; from dbt@meat.net on Sat, Jan 12, 2002 at 12:22:20AM -0800 References: <20020110134029.A17525@lucent.com> <20020111090857.GA25502@faui02> <20020111165156.A21636@lucent.com> <20020112002220.A18140@pianosa.catch22.org> Message-ID: <20020118160841.A21184@lucent.com> I'm sorry for taking so long to respond. On Sat, Jan 12, 2002 at 12:22:20AM -0800, David Terrell wrote: > On Fri, Jan 11, 2002 at 04:51:56PM -0600, Dave Dykstra wrote: > > That would be of some help; make the warning stronger if there is a known > > key of another type. Hey, for that matter why not print out the big > > warning that somebody could be doing something nasty? It's really no > > different if somebody has exchanged one RSA key for another than if they've > > exchange one RSA key for a DSA key. Right? That would be a simple fix. > > It is different. > > In once case, you have unverified credentials, in another case you have > clearly wrong credentials. Well it's not the same thing as a brand new host with no credentials. Maybe a compromise message should be printed, but I don't think it should be the same message as a new host. > Some people have been lazy about generating ssh2 rsa keys you know :) What's that got to do with it? - Dave Dykstra From bugzilla-daemon at mindrot.org Sat Jan 19 09:38:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 19 Jan 2002 09:38:10 +1100 (EST) Subject: [Bug 73] sftp segfaults on an attempt to up/download a nonexistent file Message-ID: <20020118223810.B7483E928@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=73 ------- Additional Comments From djm at mindrot.org 2002-01-19 09:38 ------- Are you sure it is not your glob() implementation that is incorrect here? sftp relies on glob to return non-zero (i.e. GLOB_NOMATCH) when no files are matched. This works correctly on Linux, Solaris and OpenBSD. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Sat Jan 19 09:58:05 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 18 Jan 2002 14:58:05 -0800 Subject: contrib/solaris/opensshd.in patch In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Jan 18, 2002 at 03:50:47PM -0600 References: <2CED9BC6F755D5118B520002B302951D307391@copeland.ensemblecom.com> Message-ID: <20020118145804.Q6441@google.com> I thought the standard way to do this was to write the pid into /var/run and start time and kill that at stop time. I usually like to verify that the pid belongs to the process. something like PROG=sshd ... pid=`cat /var/run/$PROG.pid` if pgrep $PROG | /usr/xpg4/bin/grep -q $pid /dev/fd/0; then kill $pid && rm -f /var/run/$PROG.pid fi but later pkill's (Solaris 8 anyway) does all that for you pkill -P 1 sshd I assume you want this to run on earlier solari, so the first form is probably a bit better (except don't use pgrep). /fc On Fri, Jan 18, 2002 at 03:50:47PM -0600, mouring at etoh.eviladmin.org wrote: > > > If we are in agreed. Then I'll be happy to commit this change. > > - Ben > > On Fri, 18 Jan 2002, Rob Mallory wrote: > > > Hmmm.. you are right. Dunno what I omitted when > > cut n pasted your (nice and unbloated) version. > > ...and yes, I do want to kill the one who $ppid=1, > > {was stuck in thinking ass-backwards like my example} > > yeppers..... > > anyways, I hope people agree this'd be nice to have > > in the tree..... it saved my butt a few times in the past... > > > > > > -----Original Message----- > > From: Rob Mallory [mailto:rmallory at ensemble.com] > > Sent: Friday, January 18, 2002 1:23 PM > > To: 'Zoran Milojevic'; openssh-unix-dev at shitei.mindrot.org > > Cc: 'Rob Mallory' > > Subject: RE: contrib/solaris/opensshd.in patch > > > > > > Did you try it? it seems to kill all sshd's here. > > specificaly, you (or at least I)_don't_ want to kill anything where $2=="1" > > from the ps -opid,ppid,fname line to be killed. > > > > also I don't want to kill parents of any procs called "opensshd" > > which is the name of the script. > > -Rob > > > > -----Original Message----- > > From: Zoran Milojevic [mailto:Zoran.Milojevic at SS8.com] > > Sent: Friday, January 18, 2002 1:04 PM > > To: openssh-unix-dev at shitei.mindrot.org > > Cc: 'Rob Mallory' > > Subject: RE: contrib/solaris/opensshd.in patch > > > > > > > > Here's a bit simpler change that accomplishes the same task: > > > > --- ./opensshd.in.old Fri Jan 18 15:47:21 2002 > > +++ ./opensshd.in Fri Jan 18 15:47:00 2002 > > @@ -23,7 +23,9 @@ > > killproc() { > > _procname=$1 > > _signal=$2 > > - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} > > > > + ${PS} -opid,ppid,fname -u root |\ > > + ${AWK} '/'"$_procname"'$/ {if ($2 == "1") {print $1}}' |\ > > + ${XARGS} ${KILL} -s $_signal > > } > > > > Zoran > > -- > > Zoran Milojevic > > SS8 Networks Inc. http://www.ss8.com > > "One Better" > > Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > > > > > > > -----Original Message----- > > > From: Rob Mallory [ mailto:rmallory at ensemblecom.com > > ] > > > Sent: January 18, 2002 15:02 > > > To: openssh-unix-dev at mindrot.org > > > Subject: contrib/solaris/opensshd.in patch > > > > > > > > > This patch adds the seatbelts which _only_ kill parent sshd > > > procs... -RMallory > > > (eg: when you ssh into a machine and pkgadd the new openssh, > > > it will not > > > kill your current (or anyone else's sshd session) > > > > > > onanother_note: the buildpkg.sh could use some exec_prefix > > > functionality... > > > to deal with ./configure --prefix= --exec_prefix=/usr > > > > > > *** bak/opensshd.in Fri Oct 19 13:36:24 2001 > > > --- opensshd.in Fri Jan 18 11:47:10 2002 > > > *************** > > > *** 8,16 **** > > > KILL=/usr/bin/kill > > > PS=/usr/bin/ps > > > XARGS=/usr/bin/xargs > > > > > > prefix=%%openSSHDir%% > > > --- 8,19 ---- > > > KILL=/usr/bin/kill > > > PS=/usr/bin/ps > > > XARGS=/usr/bin/xargs > > > + FGREP=/usr/bin/fgrep > > > + EGREP=/usr/bin/egrep > > > + ME=`/usr/bin/basename $0` > > > > > > prefix=%%openSSHDir%% > > > *************** > > > *** 22,29 **** > > > > > > killproc() { > > > _procname=$1 > > > ! _signal=$2 > > > ! ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | > > > ${XARGS} ${KILL} > > > } > > > > > > > > > --- 25,42 ---- > > > > > > killproc() { > > > _procname=$1 > > > ! > > > ! #The next line finds only the parent of $_procname if it exists > > > ! PID=`${PS} -le -u root| ${FGREP} $_procname | ${EGREP} -v ${ME} \ > > > ! | ${AWK} '{print $5}' | ${EGREP} -v "^1$" | uniq ` > > > ! > > > ! if [ -z "$PID" ] ; then > > > ! echo "No parent sshd process found..." > > > ! PID=`${PS} -u root | ${AWK} '/'"$_procname"'$/ > > > {print $1}'` > > > ! test -z "$PID" && /usr/bin/echo "No sshd > > > children found..." > > > ! test -z "$PID" || /usr/bin/echo "Not killing > > > these sshd children: \n$PID" > > > ! else echo "Killing $PID" ; ${KILL} ${PID} > > > ! fi > > > } > > > > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From josb at cncdsl.com Sat Jan 19 10:45:13 2002 From: josb at cncdsl.com (Jos Backus) Date: Fri, 18 Jan 2002 15:45:13 -0800 Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020118145804.Q6441@google.com> References: <2CED9BC6F755D5118B520002B302951D307391@copeland.ensemblecom.com> <20020118145804.Q6441@google.com> Message-ID: <20020118234535.GB24468@lizzy.bugworks.com> [Slightly off-topic] On Fri, Jan 18, 2002 at 02:58:05PM -0800, Frank Cusack wrote: > PROG=sshd > ... > pid=`cat /var/run/$PROG.pid` > if pgrep $PROG | /usr/xpg4/bin/grep -q $pid /dev/fd/0; then > kill $pid && rm -f /var/run/$PROG.pid > fi > > but later pkill's (Solaris 8 anyway) does all that for you > > pkill -P 1 sshd > > I assume you want this to run on earlier solari, so the first form is > probably a bit better (except don't use pgrep). Using Dan Bernstein's daemontools I'm glad I can just do svc -d /service/sshd on Solaris (or FreeBD, or ...) and be done. Pidfiles are just so messy. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From kevin at tgivan.com Sat Jan 19 12:57:47 2002 From: kevin at tgivan.com (kevin at tgivan.com) Date: Fri, 18 Jan 2002 17:57:47 -0800 Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020118145804.Q6441@google.com> References: <2CED9BC6F755D5118B520002B302951D307391@copeland.ensemblecom.com> <20020118145804.Q6441@google.com> Message-ID: <20020118175747.A16806@tgivan.com> Moin Frank! Frank Cusack schrieb am Freitag, den 18. Januar 2002: > I assume you want this to run on earlier solari, so the first form > is probably a bit better (except don't use pgrep). pkill is not portable. Its available only on 2.7+ and I agree with not using pgrep. Something like: PID=`ps -a | awk '/[s]shd/{print $1}'` could be pretty portable on Solaris. -- Kevin Sindhu Systems Engineer TGI Technologies Inc. 107 E 3rd Avenue Tel: (604) 872-6676 Ext 321 Vancouver V5T 1C7 Fax: (604) 872-6601 British Columbia, Canada From tori at ringstrom.mine.nu Sat Jan 19 21:42:45 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sat, 19 Jan 2002 11:42:45 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally Message-ID: Dear OpenSSH maintainers, When analyzing the performance of sftp some weeks ago, I discovered that the cause of the horrible performance was the use of the Nagle algorithm on the ssh TCP connection, i.e. TCP_NODELAY was not used. I propose that the following patch is applied, enabling TCP_NODELAY for both ssh and sshd, unconditionally. Since the SSH channel is packet bases, if we want to reduce the amount of data on the wire, we should use a Nagle-type algorithm before making packets of the data. It is more efficient to make one SSH packet of two small data "chunks" than to make two packets of the data chunks, even if both fit within one TCP packet. I also have a patch which implements overlapping read and write requests for the sftp client. The patch was posted to the list at the time, but I see no reason to apply that patch until the TCP_NODELAY issue has been resolved. /Tobias diff -ru openssh-3.0.2p1.orig/packet.c openssh-3.0.2p1.nodelay/packet.c --- openssh-3.0.2p1.orig/packet.c Mon Nov 12 01:07:58 2001 +++ openssh-3.0.2p1.nodelay/packet.c Thu Jan 17 20:40:47 2002 @@ -1180,7 +1180,6 @@ int lowdelay = IPTOS_LOWDELAY; int throughput = IPTOS_THROUGHPUT; #endif - int on = 1; if (called) return; @@ -1198,7 +1197,7 @@ if (interactive) { /* * Set IP options for an interactive connection. Use - * IPTOS_LOWDELAY and TCP_NODELAY. + * IPTOS_LOWDELAY. */ #if defined(IP_TOS) && !defined(IP_TOS_IS_BROKEN) if (packet_connection_is_ipv4()) { @@ -1208,9 +1207,6 @@ strerror(errno)); } #endif - if (setsockopt(connection_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, - sizeof(on)) < 0) - error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); } else if (packet_connection_is_ipv4()) { /* * Set IP options for a non-interactive connection. Use diff -ru openssh-3.0.2p1.orig/sshconnect.c openssh-3.0.2p1.nodelay/sshconnect.c --- openssh-3.0.2p1.orig/sshconnect.c Wed Oct 10 07:07:45 2001 +++ openssh-3.0.2p1.nodelay/sshconnect.c Thu Jan 17 20:09:11 2002 @@ -370,6 +370,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock, SOL_SOCKET, SO_LINGER, (void *)&linger, sizeof(linger)); + setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && diff -ru openssh-3.0.2p1.orig/sshd.c openssh-3.0.2p1.nodelay/sshd.c --- openssh-3.0.2p1.orig/sshd.c Mon Nov 12 01:07:12 2001 +++ openssh-3.0.2p1.nodelay/sshd.c Thu Jan 17 20:42:24 2002 @@ -1118,6 +1118,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock_in, SOL_SOCKET, SO_LINGER, (void *) &linger, sizeof(linger)); + setsockopt(sock_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && From mouring at etoh.eviladmin.org Sun Jan 20 02:50:54 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 19 Jan 2002 09:50:54 -0600 (CST) Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020118175747.A16806@tgivan.com> Message-ID: On Fri, 18 Jan 2002 kevin at tgivan.com wrote: > Moin Frank! > Frank Cusack schrieb am Freitag, den 18. Januar 2002: > > > I assume you want this to run on earlier solari, so the first form > > is probably a bit better (except don't use pgrep). > > pkill is not portable. Its available only on 2.7+ and I agree with not > using pgrep. > > Something like: > > PID=`ps -a | awk '/[s]shd/{print $1}'` > > could be pretty portable on Solaris. > Same problem as the original code. It could kill all children sshd which would kill your remote session if you are upgrading OpenSSH. Somene stated sshd.pid should be used, and I agree mostly. However pid files get corrupted too easily. I'd like a fall back method if sshd.pid is not right. However no fallback method I know off hand would protect the sshd children from being killed. BTW.. Jos.. It is nice you like Dan Bernstein's tools. But I sure the hell ain't going to make them 'required' for a stupid little start/stop script. When I myself do not like most of his works nor his licensing. - Ben From stevesk at pobox.com Sun Jan 20 03:46:53 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sat, 19 Jan 2002 08:46:53 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Sat, 19 Jan 2002, Tobias Ringstrom wrote: :When analyzing the performance of sftp some weeks ago, I discovered that :the cause of the horrible performance was the use of the Nagle algorithm :on the ssh TCP connection, i.e. TCP_NODELAY was not used. : :I propose that the following patch is applied, enabling TCP_NODELAY for :both ssh and sshd, unconditionally. Since the SSH channel is packet :bases, if we want to reduce the amount of data on the wire, we should use :a Nagle-type algorithm before making packets of the data. It is more :efficient to make one SSH packet of two small data "chunks" than to make :two packets of the data chunks, even if both fit within one TCP packet. can you provide some tcpdump traces to show nagle delays during sftp? From markus at openbsd.org Sun Jan 20 03:48:53 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 19 Jan 2002 17:48:53 +0100 Subject: [Bug 71] configure is looking for zlib but I don't have one and I can't turn zlib off. In-Reply-To: <20020118004606.9859DEA2F@shitei.mindrot.org> References: <20020118004606.9859DEA2F@shitei.mindrot.org> Message-ID: <20020119164853.GA26879@faui02> hm, should we have a --without-zlib ? On Fri, Jan 18, 2002 at 11:46:06AM +1100, bugzilla-daemon at mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=71 > > djm at mindrot.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WORKSFORME > > > > ------- Additional Comments From djm at mindrot.org 2002-01-18 11:46 ------- > Zlib is not optional - it is a mandatory part of OpenSSH. You should install it. > If you have zlib installed, you may need to tell configure where to look for it. > > > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From stevesk at pobox.com Sun Jan 20 03:58:13 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sat, 19 Jan 2002 08:58:13 -0800 (PST) Subject: OpenSsh to Vxworks In-Reply-To: <001601c1a06b$b922e060$658920c0@engeast.baynetworks.com> Message-ID: On Fri, 18 Jan 2002, Prashant Kumar wrote: :I'm not registered in this mailing list, however it will be great if someone :can help me with these questions: : :I have "OpenSsl" up and running on Vxworks. How difficult will it be to :port OpenSsh "server" part on to Vxworks ?. Should I take the :portable version or the regular version ?. Just compiling LIBSSH_OBJ, : SSH_OBJ, SSHD_OBJ, LIBCOMPAT will serve my purpose :or do I need any other OBJ's ? [I read from one of the mails in the :archive that these are the OBJ's I have to build]. Any idea on the :time required to port will be great . HP has openssh (sshd) running on VxWorks on some of their networking equipment. I don't know of any public ports though. From kevin at tgivan.com Sun Jan 20 04:02:28 2002 From: kevin at tgivan.com (Kevin Sindhu) Date: Sat, 19 Jan 2002 09:02:28 -0800 Subject: contrib/solaris/opensshd.in patch In-Reply-To: References: <20020118175747.A16806@tgivan.com> Message-ID: <20020119090227.A20668@tgivan.com> Moin mouring! mouring at etoh.eviladmin.org schrieb am Samstag, den 19. Januar 2002: > > pkill is not portable. Its available only on 2.7+ and I agree with > > not using pgrep. > > Something like: > > PID=`ps -a | awk '/[s]shd/{print $1}'` > Same problem as the original code. It could kill all children sshd > which would kill your remote session if you are upgrading OpenSSH. True. However what about: a) Killing all(any) instances of sshd and restarting sshd Problems with this: - all children are still killed - restart does not ensure that the daemon started properly. If the config has some problem(s), the user is locked out. b) Interactive ps -ef which displays all running instances of sshd and asks for user input for the correct PPID of sshd. Problems with this: - Not foolproof. - Everyone/many(?) would not like a interactive menu of sshd - In case this for the solaris pkg, this section would need to go into the request script where the value will be used only in the postinstall. (There can be no user input in the pre/post{request} files). Either case, how about opting for (a) when (and only when), sshd.pid is not found or is corrupted? Something like a forcerestart option? Anyway, none of the above solutions are really foolproof in the first place. > Somene stated sshd.pid should be used, and I agree mostly. However > pid files get corrupted too easily. I'd like a fall back method if > sshd.pid is not right. However no fallback method I know off hand > would protect the sshd children from being killed. Yup, this happens all the time. A classic example is ipmon.pid on Solaris using IPFilter. > BTW.. Jos.. It is nice you like Dan Bernstein's tools. But I sure > the hell ain't going to make them 'required' for a stupid little > start/stop script. When I myself do not like most of his works nor > his licensing. Amen. Rgds, -Kevin From mouring at etoh.eviladmin.org Sun Jan 20 04:28:40 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 19 Jan 2002 11:28:40 -0600 (CST) Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020119090227.A20668@tgivan.com> Message-ID: On Sat, 19 Jan 2002, Kevin Sindhu wrote: > Moin mouring! > mouring at etoh.eviladmin.org schrieb am Samstag, den 19. Januar 2002: > > > > pkill is not portable. Its available only on 2.7+ and I agree with > > > not using pgrep. > > > > Something like: > > > > PID=`ps -a | awk '/[s]shd/{print $1}'` > > > Same problem as the original code. It could kill all children sshd > > which would kill your remote session if you are upgrading OpenSSH. > > True. However what about: > > a) Killing all(any) instances of sshd and restarting sshd > Problems with this: - all children are still killed > - restart does not ensure that the daemon > started properly. If the config has some > problem(s), the user is locked out. > > b) Interactive ps -ef which displays all running instances of sshd and > asks for user input for the correct PPID of sshd. > Problems with this: - Not foolproof. > - Everyone/many(?) would not like a > interactive menu of sshd > - In case this for the solaris pkg, this > section would need to go into the request > script where the value will be used only in > the postinstall. (There can be no user input > in the pre/post{request} files). > > > Either case, how about opting for (a) when (and only when), sshd.pid > is not found or is corrupted? Something like a forcerestart option? > Anyway, none of the above solutions are really foolproof in the first > place. > Too bad we don't have an acceptable way of changing the process name. Under OpenBSD this problem is easy. ps -ax | grep sshd | grep -v sshd: all children have their names changed. Granted this may kill other sshd deamons (if you have two sshd running for some reason), but the children would be safe. Too bad this does not happen. The more I think about it.. the more I just want to accept sshd.pid (with a check that is is really sshd) as gold. IF the pid does not exist or is not of the right name. Then return "Can not find SSH pid." error and shortcut out of the process leaving an intelligent (or so we hope =) admin to find and kill the pid him/herself. I more than likely will do this on Wed when I return to work if no one submits a patch before then. I already have a patch waiting to go in to support exec_prefilx vs prefix already (ran out of time for my own testing on friday). - Ben From ssklar at stanford.edu Sun Jan 20 06:06:31 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Sat, 19 Jan 2002 11:06:31 -0800 Subject: OpenSSH 3.0.Xp1, AIX -> Sun trusted host problem In-Reply-To: <19924609.1010721571@[192.168.0.1]> References: <19924609.1010721571@[192.168.0.1]> Message-ID: At 3:59 AM -0500 1/11/02, Carson Gaspar wrote: >I am _not_ an AIX expert, but I suspect one of your problems is that >the setuid bit on the ssh binary is not being honored unless the >user invoking it is in the system group. Why this could be, I have >no idea. Try the following: Hi there ... thanks for you suggestions; I haven't had time to try it out, but I will attempt to do so soon, and let you know what I find out. --Sandy > >1) log in as patrol; echo $$ to get your shell's pid >2) log in as root in another session >3) as root "truss -f -o $filename -p $pid" where $pid is patrol's shell's pid >4) as patrol try the ssh command >5) ^C the truss >6) repeat with the other system group membership >7) see what the !@#$%'s different > >For the other machine that doesn't work at all, I suspect an >incorrect known_host key entry on the server. but I'd have to add >debugging commands into the sshd source to find out. Bad system >logging, no doughnut. > >-- >Carson Gaspar - carson at taltos.org >Queen Trapped in a Butch Body > >_______________________________________________ >openssh-unix-dev at mindrot.org mailing list >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From tori at ringstrom.mine.nu Sun Jan 20 10:26:15 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 20 Jan 2002 00:26:15 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Sat, 19 Jan 2002, Kevin Steves wrote: > On Sat, 19 Jan 2002, Tobias Ringstrom wrote: > :When analyzing the performance of sftp some weeks ago, I discovered that > :the cause of the horrible performance was the use of the Nagle algorithm > :on the ssh TCP connection, i.e. TCP_NODELAY was not used. > : > :I propose that the following patch is applied, enabling TCP_NODELAY for > :both ssh and sshd, unconditionally. Since the SSH channel is packet > :bases, if we want to reduce the amount of data on the wire, we should use > :a Nagle-type algorithm before making packets of the data. It is more > :efficient to make one SSH packet of two small data "chunks" than to make > :two packets of the data chunks, even if both fit within one TCP packet. > > can you provide some tcpdump traces to show nagle delays during sftp? I suppose I could, but why exactly? Are you looking for proof that it is Nagle that is indeed the performance killer? It is easy to theoretically show how Nagle kills performance when you have a request-reply packet based protocol. For example, when writing data to the server, the server replies with a small response packet (tens of bytes). This response packet will not be transmitted immediately because of the Nagle algorithm is waiting for more data to form a full packet. Since the client is waiting for the response before sending another write packet, performance drops radically, especially over a fast link. Overlapping requests helps a bit, but if your link is very fast, you need many overlapping requests. It is also easy to show it by transmitting a file over a high-speed network with and without TCP_NODELAY. Without it, both the server and the client are mostly idle, and the network is not fully utilized. The empirical results may of course depend on the OS's Nagle implementation. I'm using Linux 2.4.17 on both ends. Please let me know if you still want a tcpdump! I cannot produce one right now because one of my computers is busy, and I need to sleep. /Tobias From fcusack at fcusack.com Sun Jan 20 12:49:48 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 19 Jan 2002 17:49:48 -0800 Subject: contrib/solaris/opensshd.in patch In-Reply-To: <20020119090227.A20668@tgivan.com>; from kevin@tgivan.com on Sat, Jan 19, 2002 at 09:02:28AM -0800 References: <20020118175747.A16806@tgivan.com> <20020119090227.A20668@tgivan.com> Message-ID: <20020119174948.A31381@google.com> On Sat, Jan 19, 2002 at 09:02:28AM -0800, Kevin Sindhu wrote: > Moin mouring! > mouring at etoh.eviladmin.org schrieb am Samstag, den 19. Januar 2002: > > > > pkill is not portable. Its available only on 2.7+ and I agree with > > > not using pgrep. > > > > Something like: > > > > PID=`ps -a | awk '/[s]shd/{print $1}'` > > > Same problem as the original code. It could kill all children sshd > > which would kill your remote session if you are upgrading OpenSSH. You just need to implement 'pkill -P 1 sshd'. How about installing a pkill substitute for systems < 2.7. /usr/local/bin/pkill: #! /bin/sh [ assume -P arg ] pids=`ps -eo ppid,pid,comm | grep '[ /]'$3'$' | awk '{ if ($1 == '$2') print $2 }' 2>/dev/null` if [ -z "$pids" ]; then exit 1 else kill $pids exit $? fi Then the init script is easy. Or, the above could be in the init script itself. /fc From david-bronder at uiowa.edu Mon Jan 21 05:15:26 2002 From: david-bronder at uiowa.edu (David Bronder) Date: Sun, 20 Jan 2002 12:15:26 -0600 (CST) Subject: [openssh-unix-dev] Re: contrib/solaris/opensshd.in patch In-Reply-To: <20020119174948.A31381@google.com> from "Frank Cusack" at Jan 19, 2002 05:49:48 PM Message-ID: <200201201815.g0KIFQS54026@fire.its.uiowa.edu> I'm not a Solaris user, so I don't care much about contrib/solaris, but wouldn't any script that assumes an sshd with a PPID of 1 is the parent sshd be fatal if you run a restart twice close enough together? First time would work. But all remaining children would now have a PPID of 1. Second restart would kill all remaining children from the original sshd. I agree with Ben. If you can't guarantee that you've got the right process, say so and defer the decision to the administrator. =Dave Frank Cusack wrote: > > You just need to implement 'pkill -P 1 sshd'. How about installing a pkill > substitute for systems < 2.7. -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From markus at openbsd.org Mon Jan 21 01:23:48 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 20 Jan 2002 15:23:48 +0100 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: ; from tori@ringstrom.mine.nu on Sun, Jan 20, 2002 at 12:26:15AM +0100 References: Message-ID: <20020120152348.A7223@folly> On Sun, Jan 20, 2002 at 12:26:15AM +0100, Tobias Ringstrom wrote: > It is easy to theoretically > show how Nagle kills performance when you have a request-reply packet > based protocol. not everybody thinks like you http://groups.google.com/groups?th=885385572a5a4219&seekm=990719183329.AA27312%40dojo.mi.org&frame=off but i guess, it would be better if ssh implements a nagle-like algorithms itself. -m From mouring at etoh.eviladmin.org Mon Jan 21 07:26:45 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 20 Jan 2002 14:26:45 -0600 (CST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020120152348.A7223@folly> Message-ID: On Sun, 20 Jan 2002, Markus Friedl wrote: > On Sun, Jan 20, 2002 at 12:26:15AM +0100, Tobias Ringstrom wrote: > > It is easy to theoretically > > show how Nagle kills performance when you have a request-reply packet > > based protocol. > > not everybody thinks like you > > http://groups.google.com/groups?th=885385572a5a4219&seekm=990719183329.AA27312%40dojo.mi.org&frame=off > > but i guess, it would be better if ssh implements a nagle-like > algorithms itself. > I think it would be better to see if we can avoid reinventing the wheel and offer a NoDelay No/Yes option on the client side. Unsure about the correct thing to do on the server side. - Ben From stevesk at pobox.com Mon Jan 21 07:59:52 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 20 Jan 2002 12:59:52 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Sun, 20 Jan 2002, Tobias Ringstrom wrote: :Please let me know if you still want a tcpdump! I cannot produce one :right now because one of my computers is busy, and I need to sleep. yes, i would like to see analysis before we change anything. also, among other things, see: http://citeseer.nj.nec.com/minshall99application.html From tori at ringstrom.mine.nu Mon Jan 21 08:02:46 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 20 Jan 2002 22:02:46 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Sun, 20 Jan 2002 mouring at etoh.eviladmin.org wrote: > I think it would be better to see if we can avoid reinventing the wheel > and offer a NoDelay No/Yes option on the client side. Unsure about the > correct thing to do on the server side. Is there no way to pass options from the client to the server? If not, a work-around for the sftp case could be to enable TCP_NODELAY when starting a subsystem. /Tobias From tori at ringstrom.mine.nu Mon Jan 21 10:12:57 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Mon, 21 Jan 2002 00:12:57 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Sun, 20 Jan 2002, Kevin Steves wrote: > On Sun, 20 Jan 2002, Tobias Ringstrom wrote: > :Please let me know if you still want a tcpdump! I cannot produce one > :right now because one of my computers is busy, and I need to sleep. > > yes, i would like to see analysis before we change anything. also, among > other things, see: http://citeseer.nj.nec.com/minshall99application.html Alright - I only hope you have the stamina to examine my data now that I've worked so hard to produce it... :-) The test is to transfer the file gcc-3.0.2.tar.gz from boris (PII-233, sftp server) to igor (Athlon-1000, sftp client), both running Linux 2.4.17. The file is cached at the server and writted to /dev/null on the client. The network is an otherwise idle 100 Mbit full duplex switched ethernet. Both machines are mostly idle. I tried very hard not to mix patches/tests by compiling all versions, and installing them in separate directories. I also inspected the installed config files, and run strace (c.f truss) to be sure that the right binaries was used. I've run four tests: 1. sftp No TCP_NODELAY and no overlapped requests (unpatched 3.0.2p1) 2. sftp.nodelay TCP_NODELAY but no overlapped requests 3. sftp.overlap No TCP_NODELAY but overlapped requests 4. TCP_NODELAY and overlapped requests For the overlapped tests, the overlap is 1, i.e. two active read requests at any time. The following information is collected: 1. ifstat (my own utility, running on the Athlon (sftp client) KiBi - kilobytes in per second KiBo - kilobytes out per second pi - packets in per second po - packets out per second 2. vmstat on both boris and igor (one second interval) 3. A one second snippet of tcpdump data from both sides (steady state) (full binary tcpdumps available if needed) In this test, the network is not the limiting factor, and it is a very low latency link. The sftp server boris is the bottle-neck. As can be seen, either overlapping requests _or_ TCP_NODELAY gives good performance in this test. When running on the local interface on the Athlon, TCP_NODELAY gives much better performance than one overlapping request. Increasing the number of overlapping requests to something large (10) achieves almost the same performance as with TCP_NODELAY. With TCP_NODELAY, overlapping requests does not make a noticable difference. I did most of my previous testing on the local interface which led me to believe that the nodelay patch needed to go in first, but from this test run, I conclude that the overlap patch works very well on its own, and can be applied at any time. I'm guessing that it will take some time to reach a conclusion regarding the Nagle issue... I've also attached the patches I used for anyone to play with (or apply to the CVS tree... :-) /Tobias -------------- next part -------------- diff -ru openssh-3.0.2p1.orig/sftp-client.c openssh-3.0.2p1.sftp/sftp-client.c --- openssh-3.0.2p1.orig/sftp-client.c Wed Jul 18 17:45:45 2001 +++ openssh-3.0.2p1.sftp/sftp-client.c Sun Jan 6 23:13:44 2002 @@ -45,6 +45,15 @@ /* How much data to read/write at at time during copies */ /* XXX: what should this be? */ #define COPY_SIZE 8192 +/* Maximum number of overlapping requests */ +#define OVERLAPPING_REQUESTS 1 + +/* A read/write request */ +struct request { + u_int id; + u_int len; + u_int64_t offset; +}; /* Message ID */ static u_int msg_id = 1; @@ -215,6 +224,44 @@ return(a); } +static int +find_request(struct request *rq, int num, u_int id) +{ + int i; + + for (i = 0; i < num; ++i) { + if (rq[i].id == id) + break; + } + + if (i == num) + fatal("Request ID mismatch (%d)", id); + + return i; +} + +static void +remove_request(struct request *rq, int *num, int i) +{ + memmove(rq + i, rq + i + 1, (*num - i - 1) * sizeof(struct request)); + --*num; +} + +static void +send_request(int fd, const char *handle, u_int handle_len, int type, + const struct request *rq, Buffer *m) +{ + buffer_clear(m); + buffer_put_char(m, SSH2_FXP_READ); + buffer_put_int(m, rq->id); + buffer_put_string(m, handle, handle_len); + buffer_put_int64(m, rq->offset); + buffer_put_int(m, rq->len); + send_msg(fd, m); + debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", + rq->id, rq->offset, rq->len); +} + int do_init(int fd_in, int fd_out) { @@ -674,12 +721,15 @@ int pflag) { int local_fd; - u_int expected_id, handle_len, mode, type, id; + u_int handle_len, mode, type, id; u_int64_t offset; char *handle; Buffer msg; Attrib junk, *a; int status; + struct request req[OVERLAPPING_REQUESTS + 1]; + int num_req = 0, max_req = 1, reply; + int write_error = 0, read_error = 0, write_errno; a = do_stat(fd_in, fd_out, remote_path, 0); if (a == NULL) @@ -726,87 +776,103 @@ /* Read from remote and write to local */ offset = 0; - for(;;) { - u_int len; + while (num_req > 0 || max_req > 0) { char *data; + u_int len; - id = expected_id = msg_id++; - - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_READ); - buffer_put_int(&msg, id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_int(&msg, COPY_SIZE); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", - id, (u_int64_t)offset, COPY_SIZE); + /* Send some more requests */ + while (num_req < max_req) { + req[num_req].id = msg_id++; + req[num_req].len = COPY_SIZE; + req[num_req].offset = offset; + offset += req[num_req].len; + num_req++; + send_request(fd_out, handle, handle_len, SSH2_FXP_READ, + &req[num_req - 1], &msg); + } buffer_clear(&msg); - get_msg(fd_in, &msg); type = buffer_get_char(&msg); id = buffer_get_int(&msg); debug3("Received reply T:%d I:%d", type, id); - if (id != expected_id) - fatal("ID mismatch (%d != %d)", id, expected_id); - if (type == SSH2_FXP_STATUS) { + reply = find_request(req, num_req, id); + + switch (type) { + case SSH2_FXP_STATUS: status = buffer_get_int(&msg); + if (status != SSH2_FX_EOF) + read_error = 1; + max_req = 0; + remove_request(req, &num_req, reply); + break; + case SSH2_FXP_DATA: + data = buffer_get_string(&msg, &len); + if (len > req[reply].len) + fatal("Received more data than asked for " + "%d > %d", len, req[reply].len); + + debug3("In read loop, got %d offset %llu", + len, req[reply].offset); + if ((lseek(local_fd, req[reply].offset, SEEK_SET) == -1 || + atomicio(write, local_fd, data, len) != len) && + !write_error) { + write_errno = errno; + write_error = 1; + max_req = 0; + } + xfree(data); - if (status == SSH2_FX_EOF) - break; + if (len == req[reply].len) + remove_request(req, &num_req, reply); else { - error("Couldn't read from remote " - "file \"%s\" : %s", remote_path, - fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - goto done; + /* Resend the request for the missing data */ + req[reply].id = msg_id++; + req[reply].len -= len; + req[reply].offset += len; + send_request(fd_out, handle, handle_len, + SSH2_FXP_READ, &req[reply], &msg); } - } else if (type != SSH2_FXP_DATA) { + if (max_req > 0 && max_req < OVERLAPPING_REQUESTS + 1) + ++max_req; + break; + default: fatal("Expected SSH2_FXP_DATA(%d) packet, got %d", - SSH2_FXP_DATA, type); - } - - data = buffer_get_string(&msg, &len); - if (len > COPY_SIZE) - fatal("Received more data than asked for %d > %d", - len, COPY_SIZE); - - debug3("In read loop, got %d offset %llu", len, - (u_int64_t)offset); - if (atomicio(write, local_fd, data, len) != len) { - error("Couldn't write to \"%s\": %s", local_path, - strerror(errno)); - do_close(fd_in, fd_out, handle, handle_len); - status = -1; - xfree(data); - goto done; + SSH2_FXP_DATA, type); } - - offset += len; - xfree(data); } - status = do_close(fd_in, fd_out, handle, handle_len); - /* Override umask and utimes if asked */ + if (read_error) { + error("Couldn't read from remote " + "file \"%s\" : %s", remote_path, + fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + } else if (write_error) { + error("Couldn't write to \"%s\": %s", local_path, + strerror(write_errno)); + status = -1; + do_close(fd_in, fd_out, handle, handle_len); + } else { + status = do_close(fd_in, fd_out, handle, handle_len); + + /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD - if (pflag && fchmod(local_fd, mode) == -1) + if (pflag && fchmod(local_fd, mode) == -1) #else - if (pflag && chmod(local_path, mode) == -1) + if (pflag && chmod(local_path, mode) == -1) #endif /* HAVE_FCHMOD */ - error("Couldn't set mode on \"%s\": %s", local_path, - strerror(errno)); - if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { - struct timeval tv[2]; - tv[0].tv_sec = a->atime; - tv[1].tv_sec = a->mtime; - tv[0].tv_usec = tv[1].tv_usec = 0; - if (utimes(local_path, tv) == -1) - error("Can't set times on \"%s\": %s", local_path, - strerror(errno)); + error("Couldn't set mode on \"%s\": %s", local_path, + strerror(errno)); + if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { + struct timeval tv[2]; + tv[0].tv_sec = a->atime; + tv[1].tv_sec = a->mtime; + tv[0].tv_usec = tv[1].tv_usec = 0; + if (utimes(local_path, tv) == -1) + error("Can't set times on \"%s\": %s", + local_path, strerror(errno)); + } } - -done: close(local_fd); buffer_free(&msg); xfree(handle); @@ -825,6 +891,8 @@ struct stat sb; Attrib a; int status; + u_int32_t startid; + u_int32_t ackid; if ((local_fd = open(local_path, O_RDONLY, 0)) == -1) { error("Couldn't open local file \"%s\" for reading: %s", @@ -866,6 +934,8 @@ return(-1); } + startid = ackid = id + 1; + /* Read from local and write to remote */ offset = 0; for(;;) { @@ -883,29 +953,34 @@ if (len == -1) fatal("Couldn't read from \"%s\": %s", local_path, strerror(errno)); - if (len == 0) - break; - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_WRITE); - buffer_put_int(&msg, ++id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_string(&msg, data, len); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", - id, (u_int64_t)offset, len); + if (len != 0) { + buffer_clear(&msg); + buffer_put_char(&msg, SSH2_FXP_WRITE); + buffer_put_int(&msg, ++id); + buffer_put_string(&msg, handle, handle_len); + buffer_put_int64(&msg, offset); + buffer_put_string(&msg, data, len); + send_msg(fd_out, &msg); + debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", + id, (u_int64_t)offset, len); + } else if ( id < ackid ) + break; - status = get_status(fd_in, id); - if (status != SSH2_FX_OK) { - error("Couldn't write to remote file \"%s\": %s", - remote_path, fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - close(local_fd); - goto done; + if (id == startid || len == 0 || + id - ackid >= OVERLAPPING_REQUESTS) { + status = get_status(fd_in, ackid); + if (status != SSH2_FX_OK) { + error("Couldn't write to remote file \"%s\": %s", + remote_path, fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + close(local_fd); + goto done; + } + debug3("In write loop, got %d offset %llu", len, + (u_int64_t)offset); + ++ackid; } - debug3("In write loop, got %d offset %llu", len, - (u_int64_t)offset); offset += len; } -------------- next part -------------- diff -ru openssh-3.0.2p1.orig/packet.c openssh-3.0.2p1.nodelay/packet.c --- openssh-3.0.2p1.orig/packet.c Mon Nov 12 01:07:58 2001 +++ openssh-3.0.2p1.nodelay/packet.c Thu Jan 17 20:40:47 2002 @@ -1180,7 +1180,6 @@ int lowdelay = IPTOS_LOWDELAY; int throughput = IPTOS_THROUGHPUT; #endif - int on = 1; if (called) return; @@ -1198,7 +1197,7 @@ if (interactive) { /* * Set IP options for an interactive connection. Use - * IPTOS_LOWDELAY and TCP_NODELAY. + * IPTOS_LOWDELAY. */ #if defined(IP_TOS) && !defined(IP_TOS_IS_BROKEN) if (packet_connection_is_ipv4()) { @@ -1208,9 +1207,6 @@ strerror(errno)); } #endif - if (setsockopt(connection_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, - sizeof(on)) < 0) - error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); } else if (packet_connection_is_ipv4()) { /* * Set IP options for a non-interactive connection. Use diff -ru openssh-3.0.2p1.orig/sshconnect.c openssh-3.0.2p1.nodelay/sshconnect.c --- openssh-3.0.2p1.orig/sshconnect.c Wed Oct 10 07:07:45 2001 +++ openssh-3.0.2p1.nodelay/sshconnect.c Thu Jan 17 20:09:11 2002 @@ -370,6 +370,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock, SOL_SOCKET, SO_LINGER, (void *)&linger, sizeof(linger)); + setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && diff -ru openssh-3.0.2p1.orig/sshd.c openssh-3.0.2p1.nodelay/sshd.c --- openssh-3.0.2p1.orig/sshd.c Mon Nov 12 01:07:12 2001 +++ openssh-3.0.2p1.nodelay/sshd.c Thu Jan 17 20:42:24 2002 @@ -1118,6 +1118,7 @@ linger.l_onoff = 1; linger.l_linger = 5; setsockopt(sock_in, SOL_SOCKET, SO_LINGER, (void *) &linger, sizeof(linger)); + setsockopt(sock_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on, sizeof(on)); /* Set keepalives if requested. */ if (options.keepalives && -------------- next part -------------- A non-text attachment was scrubbed... Name: sftp-bench.tar.gz Type: application/x-gzip Size: 11954 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020121/da23d17c/attachment.bin From tori at ringstrom.mine.nu Mon Jan 21 10:29:00 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Mon, 21 Jan 2002 00:29:00 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Message-ID: On Mon, 21 Jan 2002, Tobias Ringstrom wrote: > When running on the local interface on the Athlon, TCP_NODELAY gives much > better performance than one overlapping request. Increasing the number of > overlapping requests to something large (10) achieves almost the same > performance as with TCP_NODELAY. I forgot to mention that this may very well be a problem with the Linux Nagle implementation. It would be very interesting to hear how other OS:es behave. Anyone? Just apply the overlap patch from my last mail and try different values of OVERLAPPING_REQUESTS (say 0-10). /Tobias From fcusack at fcusack.com Mon Jan 21 13:45:55 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 20 Jan 2002 18:45:55 -0800 Subject: [openssh-unix-dev] Re: contrib/solaris/opensshd.in patch In-Reply-To: <200201201815.g0KIFQS54026@fire.its.uiowa.edu>; from david-bronder@uiowa.edu on Sun, Jan 20, 2002 at 12:15:26PM -0600 References: <20020119174948.A31381@google.com> <200201201815.g0KIFQS54026@fire.its.uiowa.edu> Message-ID: <20020120184554.A5447@google.com> On Sun, Jan 20, 2002 at 12:15:26PM -0600, David Bronder wrote: > I'm not a Solaris user, so I don't care much about contrib/solaris, > but wouldn't any script that assumes an sshd with a PPID of 1 is > the parent sshd be fatal if you run a restart twice close enough > together? First time would work. But all remaining children would > now have a PPID of 1. Second restart would kill all remaining > children from the original sshd. Yup, sounds right, damn. So just test that sshd.pid is an sshd and if so kill it. If not, punt. It should be correct in the great majority of cases. /fc From mouring at etoh.eviladmin.org Mon Jan 21 16:36:28 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 20 Jan 2002 23:36:28 -0600 (CST) Subject: [openssh-unix-dev] Re: contrib/solaris/opensshd.in patch In-Reply-To: <20020120184554.A5447@google.com> Message-ID: And if someone does not send a patch by Wed.. I'll write my own and commit it with the exec-prefix change. - Ben On Sun, 20 Jan 2002, Frank Cusack wrote: > On Sun, Jan 20, 2002 at 12:15:26PM -0600, David Bronder wrote: > > I'm not a Solaris user, so I don't care much about contrib/solaris, > > but wouldn't any script that assumes an sshd with a PPID of 1 is > > the parent sshd be fatal if you run a restart twice close enough > > together? First time would work. But all remaining children would > > now have a PPID of 1. Second restart would kill all remaining > > children from the original sshd. > > Yup, sounds right, damn. So just test that sshd.pid is an sshd and > if so kill it. If not, punt. It should be correct in the great > majority of cases. > /fc > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Mon Jan 21 16:41:37 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 21 Jan 2002 00:41:37 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: ; from tori@ringstrom.mine.nu on Sun, Jan 20, 2002 at 10:02:46PM +0100 References: Message-ID: <20020121004135.I27171@sm2p1386swk.wdr.com> On Sun, Jan 20, 2002 at 10:02:46PM +0100, Tobias Ringstrom wrote: > On Sun, 20 Jan 2002 mouring at etoh.eviladmin.org wrote: > > > I think it would be better to see if we can avoid reinventing the wheel > > and offer a NoDelay No/Yes option on the client side. Unsure about the > > correct thing to do on the server side. > > Is there no way to pass options from the client to the server? > > If not, a work-around for the sftp case could be to enable TCP_NODELAY > when starting a subsystem. At the very least. And X11 forwarding. What about that? Normally X11 TCP connections are run with TCP_NODELAY... Since the protocol allows a variety of kinds of traffic to be exchanged over a TCP connection, some which should be used with Nagle, and some which shouldn't, the protocol should really be capable of implementing Nagle on a per-channel basis and always run with TCP_NODELAY, but that's a lot easier said than done. > /Tobias Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Mon Jan 21 20:23:27 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 21 Jan 2002 10:23:27 +0100 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: References: Message-ID: <20020121092327.GE14658@faui02> On Sun, Jan 20, 2002 at 10:02:46PM +0100, Tobias Ringstrom wrote: > On Sun, 20 Jan 2002 mouring at etoh.eviladmin.org wrote: > > > I think it would be better to see if we can avoid reinventing the wheel > > and offer a NoDelay No/Yes option on the client side. Unsure about the > > correct thing to do on the server side. > > Is there no way to pass options from the client to the server? no, unless we define a "TCP_NODELAY at openssh.com" > If not, a work-around for the sftp case could be to enable TCP_NODELAY > when starting a subsystem. > > /Tobias > From markus at openbsd.org Mon Jan 21 20:24:28 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 21 Jan 2002 10:24:28 +0100 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020121004135.I27171@sm2p1386swk.wdr.com> References: <20020121004135.I27171@sm2p1386swk.wdr.com> Message-ID: <20020121092428.GF14658@faui02> On Mon, Jan 21, 2002 at 12:41:37AM -0500, Nicolas Williams wrote: > Since the protocol allows a variety of kinds of traffic to be exchanged > over a TCP connection, some which should be used with Nagle, and some > which shouldn't, the protocol should really be capable of implementing > Nagle on a per-channel basis and always run with TCP_NODELAY, but that's > a lot easier said than done. ietf-ssh is the place for this. From markus at openbsd.org Mon Jan 21 20:26:15 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 21 Jan 2002 10:26:15 +0100 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020121092428.GF14658@faui02> References: <20020121004135.I27171@sm2p1386swk.wdr.com> <20020121092428.GF14658@faui02> Message-ID: <20020121092615.GA16347@faui02> On Mon, Jan 21, 2002 at 10:24:28AM +0100, Markus Friedl wrote: > On Mon, Jan 21, 2002 at 12:41:37AM -0500, Nicolas Williams wrote: > > Since the protocol allows a variety of kinds of traffic to be exchanged > > over a TCP connection, some which should be used with Nagle, and some > > which shouldn't, the protocol should really be capable of implementing > > Nagle on a per-channel basis and always run with TCP_NODELAY, but that's > > a lot easier said than done. > > ietf-ssh is the place for this. ietf-ssh at netbsd.org From Mattias.Larsson at lm.se Tue Jan 22 02:47:44 2002 From: Mattias.Larsson at lm.se (Larsson Mattias) Date: Mon, 21 Jan 2002 16:47:44 +0100 Subject: nmap and OpenSSH 3.0.XpX Message-ID: <55BBFAB552D4D511BE390002A5ADBDBF2997B5@postdrux.lmv.lm.se> Hi all! I'm a bit curious about this I found out while running nmap scans on some of our machines. It seems that OpenSSH 3.0.1p1 and 3.0.2p1 doesn't like the nmap scan. I have put the logging to debug and run "nmap -p 1- " and it resulted in the below: error: accept: Software caused connection abort Our servers are Solaris 2.6 and Solaris 8 machines with OpenSSH kompiled on each and everyone of them and the result is that the connections is bloken for some users and some make it out of it alive. OpenSSH is compiled without any extra arguments or other stuff. -- Mattias Larsson Lantm?teriverket, Dataservice Tel 026-634617, Mobil 070-6778720 From raj at cup.hp.com Tue Jan 22 05:49:04 2002 From: raj at cup.hp.com (Rick Jones) Date: Mon, 21 Jan 2002 10:49:04 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: from Tobias Ringstrom at Jan "20," 2002 "00:26:15" am Message-ID: <200201211849.KAA23245@tardy.cup.hp.com> > I suppose I could, but why exactly? Are you looking for proof that it is > Nagle that is indeed the performance killer? It is easy to theoretically > show how Nagle kills performance when you have a request-reply packet > based protocol. For example, when writing data to the server, the server > replies with a small response packet (tens of bytes). This response > packet will not be transmitted immediately because of the Nagle algorithm > is waiting for more data to form a full packet. Since the client is > waiting for the response before sending another write packet, performance > drops radically, especially over a fast link. Overlapping requests helps > a bit, but if your link is very fast, you need many overlapping requests. The way the Nagle algorithm is supposed to work is like this: On every user send the code is supposed to go through this sequence of pseudo logic: 1) is the quantity of data in this send, plus any queued unsent data more than the MSS for the connection? if yes, send the data now (modulo other constraints such as receiver window and congestion window) if no, go to 2. 2) is the connection otherwise "idle"? that is, do we have no unacknowledged data outstanding to the remote? if yes, send the data now, if no, queue the data and wait. So, in a simple synchronous request/response application (such as might be simulated with a netperf TCP_RR test, the Nagle algoritm will _not_ kick-in. Whenver one side goes to write the request or response the connection will be "idle" Unless... the application writes its request or its response in multiple send/write calls. Now, where one _might_ see nalge with an app that does properly present all logically associated data to the trasnport in a one send is when that application wants to have multiple overlapping request/response pairs on the same connection, and either the requests, or the responses are smaller than the MSS of the connection. at that point it becomes a matter of timing as to whether or not any delay induced by the interaction of nagle and the remote's ack policy will come to pass. > It is also easy to show it by transmitting a file over a high-speed > network with and without TCP_NODELAY. Without it, both the server > and the client are mostly idle, and the network is not fully > utilized. Unidirctional bulk data transfer should _never_ run into an issue iwht nagle. the app is dumping data into the socket, and shoudl always be creating at least an MSS of data to send. for example, at least a "classic" ftp data connection should never need to set TCP_NODELAY. the ftp app will keep calling send with file data, and for any last little bi at the end, the close of the connectin will flush. rick jones From tori at ringstrom.mine.nu Tue Jan 22 09:03:49 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Mon, 21 Jan 2002 23:03:49 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <200201211849.KAA23245@tardy.cup.hp.com> Message-ID: On Mon, 21 Jan 2002, Rick Jones wrote: > The way the Nagle algorithm is supposed to work is like this: > On every user send the code is supposed to go through this sequence of > pseudo logic: > 1) is the quantity of data in this send, plus any queued unsent data > more than the MSS for the connection? if yes, send the data now > (modulo other constraints such as receiver window and congestion > window) if no, go to 2. > 2) is the connection otherwise "idle"? that is, do we have no > unacknowledged data outstanding to the remote? if yes, send the data > now, if no, queue the data and wait. You are right of course. Thanks for straightening this out! This is getting funnier all the time. The reason why the Nagle algorithm triggers is probably because of the SSH2_MSG_CHANNEL_WINDOW_ADJUST messages. Every fourth SSH2_FXP_READ message, a window adjust message is sent, and the two messages are sent with two write calls. Both messages are short, and one of the packets will be held back by the Nagle algorithm. The window adjust message seems to be sent before the read message, which delays the read until Nagle times out, which in turn explains the bad performance, at least part of it. Looking once more at the tcpdump, I can clearly see the Nagle algorithm at work. (48 byte is win_ad, 64 byte is sftp read request) 22:42:47.141152 boris.ssh > igor.32784: P 17776:17824(48) ack 1439097 win 63712 (DF) [tos 0x8] 22:42:47.171611 igor.32784 > boris.ssh: . ack 17824 win 10880 (DF) [tos 0x8] 22:42:47.171773 boris.ssh > igor.32784: P 17824:17888(64) ack 1439097 win 63712 (DF) [tos 0x8] Merging the two messages into one write would make sftp not trigger the Nagle algorithm, but it would not help the X11 forwarding case, which really needs TCP_NODELAY. Ahhh, progress... /Tobias From raj at cup.hp.com Tue Jan 22 09:53:13 2002 From: raj at cup.hp.com (Rick Jones) Date: Mon, 21 Jan 2002 14:53:13 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: from Tobias Ringstrom at Jan "21," 2002 "11:03:49" pm Message-ID: <200201212253.OAA26817@tardy.cup.hp.com> > You are right of course. Thanks for straightening this out! No problem, I have become something of a defender of the Nagle faith :) > This is getting funnier all the time. The reason why the Nagle > algorithm triggers is probably because of the > SSH2_MSG_CHANNEL_WINDOW_ADJUST messages. Every fourth SSH2_FXP_READ > message, a window adjust message is sent, and the two messages are > sent with two write calls. Both messages are short, and one of the > packets will be held back by the Nagle algorithm. The window adjust > message seems to be sent before the read message, which delays the > read until Nagle times out, which in turn explains the bad > performance, at least part of it. Now you know why TCP likes to piggy-back tings like ACK's and window updates. Not because of the nagle algorithm really, but because it saves a separate segment :) You description does sound like one where an app would run afoul of the interaction between Nagle and Delayed ACK. That is assuming that Read's have application-level ACKs and the window adjust does not. (Does it show that I'm new to ssh protocol? :) > Looking once more at the tcpdump, I can clearly see the Nagle algorithm > at work. (48 byte is win_ad, 64 byte is sftp read request) > > 22:42:47.141152 boris.ssh > igor.32784: P 17776:17824(48) ack 1439097 win 63712 (DF) [tos 0x8] > 22:42:47.171611 igor.32784 > boris.ssh: . ack 17824 win 10880 (DF) [tos 0x8] I'me guessing that igor is running with something like a 50 millisecond standalone ACK timer? > 22:42:47.171773 boris.ssh > igor.32784: P 17824:17888(64) ack 1439097 win 63712 (DF) [tos 0x8] > > Merging the two messages into one write would make sftp not trigger the > Nagle algorithm, but it would not help the X11 forwarding case, which > really needs TCP_NODELAY. Indeed X11 is one of those fun fringe things when it comes to Nagle. It has all these pseudo-time-sensitive small messages for pesky things like cursor position and such that have no replies coming-back the other way. In general, I would think that if ssh were acting as a pipe, it might as well set TCP_NODELAY - ostensibly the applications on either end of the pipe are (supposed to be) doing the "right" thing with TCP_NODELAY. In that sense ssh should simply pass the data along since it will have no prior knowledge (?) of the applications behaviour. The argument would be somewhat like the argument that says that an intervening router should not try to reassemable IP datagrams and leave that to the final recipient. (Not a perfect analogy, but it is what struck me at the moment. It would seem that sftp turns what used to be a nice unidrectional data flow into a request/response exchange. If there is no good way to get thatSSH window piggy-backed with the Read then indeed setting TCP_NODEALY is probably required if slighly unpleasant. Sounds like the designers of the ssh/ssl protocl didn't keep TCP behaviour in mind when they were doing their thing. rick jones From tim at multitalents.net Tue Jan 22 10:05:40 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 21 Jan 2002 15:05:40 -0800 (PST) Subject: [Bug 71] configure is looking for zlib but I don't have one and I can't turn zlib off. In-Reply-To: <20020119164853.GA26879@faui02> Message-ID: On Sat, 19 Jan 2002, Markus Friedl wrote: > hm, should we have a --without-zlib ? It's built into the AC_ARG_WITH() macro. > > On Fri, Jan 18, 2002 at 11:46:06AM +1100, bugzilla-daemon at mindrot.org wrote: > > http://bugzilla.mindrot.org/show_bug.cgi?id=71 > > > > djm at mindrot.org changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|NEW |RESOLVED > > Resolution| |WORKSFORME > > > > > > > > ------- Additional Comments From djm at mindrot.org 2002-01-18 11:46 ------- > > Zlib is not optional - it is a mandatory part of OpenSSH. You should install it. > > If you have zlib installed, you may need to tell configure where to look for it. > > > > > > > > > > > > ------- You are receiving this mail because: ------- > > You are the assignee for the bug, or are watching the assignee. > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From markus at openbsd.org Tue Jan 22 10:12:38 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 22 Jan 2002 00:12:38 +0100 Subject: [Bug 71] configure is looking for zlib but I don't have one and I can't turn zlib off. In-Reply-To: References: <20020119164853.GA26879@faui02> Message-ID: <20020121231237.GA13696@faui02> On Mon, Jan 21, 2002 at 03:05:40PM -0800, Tim Rice wrote: > On Sat, 19 Jan 2002, Markus Friedl wrote: > > > hm, should we have a --without-zlib ? > > It's built into the AC_ARG_WITH() macro. but it's not used in the source. From ppanon at sierrasys.com Tue Jan 22 10:20:55 2002 From: ppanon at sierrasys.com (root) Date: Mon, 21 Jan 2002 15:20:55 -0800 Subject: OpenSSH and OpenSSL snapshots Message-ID: <3C4CA257.7ABF9608@sierrasys.com> Hello, In order to experiment with OpenCA, I have built an RPM for redhat 7.2 of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built with the different target directories and libraries. Unfortunately these recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs that I have been able to find. None of them seem to compile successfully, even the snapshots at ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a branch of the CVS tree which I can checkout that will compile with recent OpenSSL builds? Paul-Andre Panon Sierra Systems Group Inc. From markus at openbsd.org Tue Jan 22 10:27:54 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 22 Jan 2002 00:27:54 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <3C4CA257.7ABF9608@sierrasys.com> References: <3C4CA257.7ABF9608@sierrasys.com> Message-ID: <20020121232753.GC13696@faui02> On Mon, Jan 21, 2002 at 03:20:55PM -0800, root wrote: > Hello, > > In order to experiment with OpenCA, I have built an RPM for redhat 7.2 > of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built > with the different target directories and libraries. Unfortunately these > recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs > that I have been able to find. None of them seem to compile > successfully, even the snapshots at > ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a > branch of the CVS tree which I can checkout that will compile with > recent OpenSSL builds? what did the OpenSSL people change? what did break? From Paul-AndrePanon at SierraSystems.com Tue Jan 22 11:07:36 2002 From: Paul-AndrePanon at SierraSystems.com (Panon, Paul-Andre) Date: Mon, 21 Jan 2002 16:07:36 -0800 Subject: OpenSSH and OpenSSL snapshots Message-ID: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> Here follows the error message I'm getting. I get it with the 3.0.2p1 source rpm, as well as when I replace the RPM's openssh tarball contents with those of the latest openssh snapshot. cipher.h is part of the openssh distribution and itself includes a bunch of openssl include files. I haven't yet tracked down which openssl include file is the problem, I thought I would first find out if anyone else is experiencing the same problem or whether it had been solved in a separate OpenSSH CVS branch. As for changes in 0.9.7 dev, there's quite a few, not the least of which is merging of the openssl engine into the core distribution. make[1]: Leaving directory `/usr/src/redhat/BUILD/openssh-3.0.2p1/openbsd-compat' i386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/openssh/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/openssh/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/libexec/openssh/ssh-rand-helper\" -DHAVE_CONFIG_H -c atomicio.ci386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/openssh/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/openssh/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/libexec/openssh/ssh-rand-helper\" -DHAVE_CONFIG_H -c authfd.c In file included from authfd.c:50: cipher.h:68: parse error before `des_key_schedule' cipher.h:68: warning: no semicolon at end of struct or union cipher.h:68: warning: no semicolon at end of struct or union cipher.h:69: warning: no semicolon at end of struct or union cipher.h:70: warning: type defaults to `int' in declaration of `des' cipher.h:70: warning: data definition has no type or storage class cipher.h:72: parse error before `des_key_schedule' cipher.h:72: warning: no semicolon at end of struct or union cipher.h:73: warning: type defaults to `int' in declaration of `key2' cipher.h:73: warning: data definition has no type or storage class cipher.h:74: parse error before `key3' cipher.h:74: warning: type defaults to `int' in declaration of `key3' cipher.h:74: warning: data definition has no type or storage class cipher.h:75: parse error before `iv1' cipher.h:75: warning: type defaults to `int' in declaration of `iv1' cipher.h:75: warning: data definition has no type or storage class cipher.h:76: parse error before `iv2' cipher.h:76: warning: type defaults to `int' in declaration of `iv2' cipher.h:76: warning: data definition has no type or storage class cipher.h:77: parse error before `iv3' cipher.h:77: warning: type defaults to `int' in declaration of `iv3' cipher.h:77: warning: data definition has no type or storage class cipher.h:78: warning: type defaults to `int' in declaration of `des3' cipher.h:78: warning: data definition has no type or storage class cipher.h:93: parse error before `}' cipher.h:93: warning: type defaults to `int' in declaration of `u' cipher.h:93: warning: data definition has no type or storage class cipher.h:95: parse error before `}' make: *** [authfd.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.77886 (%build) Bad exit status from /var/tmp/rpm-tmp.77886 (%build) -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Monday, January 21, 2002 3:28 PM To: root Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH and OpenSSL snapshots On Mon, Jan 21, 2002 at 03:20:55PM -0800, root wrote: > Hello, > > In order to experiment with OpenCA, I have built an RPM for redhat 7.2 > of a recent OpenSSL snapshot (the binary rpm on the OpenCA was built > with the different target directories and libraries. Unfortunately these > recent OpenSSL snapshots seems to break all OpenSSH tarballs and RPMs > that I have been able to find. None of them seem to compile > successfully, even the snapshots at > ftp://ftp.openssh.com/pub/OpenBSD/OpenSSH/portable/snapshot/. Is there a > branch of the CVS tree which I can checkout that will compile with > recent OpenSSL builds? what did the OpenSSL people change? what did break? From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Jan 22 11:24:49 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 22 Jan 2002 01:24:49 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> Message-ID: <20020122002449.GA9458@serv01.aet.tu-cottbus.de> On Mon, Jan 21, 2002 at 04:07:36PM -0800, Panon, Paul-Andre wrote: ... > In file included from authfd.c:50: > cipher.h:68: parse error before `des_key_schedule' > cipher.h:68: warning: no semicolon at end of struct or union > cipher.h:68: warning: no semicolon at end of struct or union > cipher.h:69: warning: no semicolon at end of struct or union > cipher.h:70: warning: type defaults to `int' in declaration of `des' > cipher.h:70: warning: data definition has no type or storage class ... From datqtruong at yahoo.com Tue Jan 22 15:15:27 2002 From: datqtruong at yahoo.com (dat truong) Date: Mon, 21 Jan 2002 20:15:27 -0800 (PST) Subject: ssh-keyscan: xmalloc out of memory error Message-ID: <20020122041527.17376.qmail@web14506.mail.yahoo.com> hi all, I got "xmalloc: out of memory" when i used ssh-keyscan to a remote host that is using SSH protocol 2 and only protocol 2 (no fallback to SSH protocol 1). Looks to me more like ssh-keyscan doesn't talk SSH protocol 2 to the server. Please help. Here is the exact error: # /usr/local/bin/ssh-keyscan -v miad_1 # miad_1 SSH-2.0-OpenSSH_3.0.2p1 xmalloc: out of memory (allocating 1349676920 bytes) debug1: Calling cleanup 0x4000b7b2(0x0) debug1: Calling cleanup 0x4000b7da(0x0) debug1: writing PRNG seed to file //.ssh/prng_seed # Thank you in advance. -Dat Truong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From markus at openbsd.org Tue Jan 22 19:36:57 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 22 Jan 2002 09:36:57 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020122002449.GA9458@serv01.aet.tu-cottbus.de> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> <20020122002449.GA9458@serv01.aet.tu-cottbus.de> Message-ID: <20020122083657.GA21612@faui02> On Tue, Jan 22, 2002 at 01:24:49AM +0100, Lutz Jaenicke wrote: > On Mon, Jan 21, 2002 at 04:07:36PM -0800, Panon, Paul-Andre wrote: > ... > > In file included from authfd.c:50: > > cipher.h:68: parse error before `des_key_schedule' > > cipher.h:68: warning: no semicolon at end of struct or union > > cipher.h:68: warning: no semicolon at end of struct or union > > cipher.h:69: warning: no semicolon at end of struct or union > > cipher.h:70: warning: type defaults to `int' in declaration of `des' > > cipher.h:70: warning: data definition has no type or storage class > ... > > >From OpenSSL's CHANGES file: > +) Change all functions with names starting with des_ to be starting > with DES_ instead. This because there are increasing clashes with > libdes and other des libraries that are currently used by other > projects. The old libdes interface is provided, as well as crypt(), > if openssl/des_old.h is included. Note that crypt() is no longer > declared in openssl/des.h. > > NOTE: This is a major break of an old API into a new one. Software > authors are encouraged to switch to the DES_ style functions. Some > time in the future, des_old.h and the libdes compatibility functions > will be completely removed. > [Richard Levitte] why do you break the old API? why is the old API not the default? why don't you call this openssl-1.x instead of you really have to break the API? From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Jan 22 19:55:03 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 22 Jan 2002 09:55:03 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020122083657.GA21612@faui02> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> <20020122002449.GA9458@serv01.aet.tu-cottbus.de> <20020122083657.GA21612@faui02> Message-ID: <20020122085503.GC15906@serv01.aet.tu-cottbus.de> On Tue, Jan 22, 2002 at 09:36:57AM +0100, Markus Friedl wrote: > On Tue, Jan 22, 2002 at 01:24:49AM +0100, Lutz Jaenicke wrote: > > >From OpenSSL's CHANGES file: > > +) Change all functions with names starting with des_ to be starting > > with DES_ instead. This because there are increasing clashes with > > libdes and other des libraries that are currently used by other > > projects. The old libdes interface is provided, as well as crypt(), > > if openssl/des_old.h is included. Note that crypt() is no longer > > declared in openssl/des.h. > > > > NOTE: This is a major break of an old API into a new one. Software > > authors are encouraged to switch to the DES_ style functions. Some > > time in the future, des_old.h and the libdes compatibility functions > > will be completely removed. > > [Richard Levitte] > > why do you break the old API? why is the old API not > the default? > > why don't you call this openssl-1.x instead of you really > have to break the API? It's one of the compromises we have to make. people complained about severe problems when linking against other libraries also offering DES functionality, so the namespace had to be cleaned up somehow. With respect to the numbering scheme: "1.0" should be the first version from which on we promise API _and_ binary compatibility. I know that version numbering of OpenSSL is quite somewhat confusing. 0.9.7 is a major step forward from 0.9.6 (and takes far too long to come out; it would probably be better to make more releases but in a shorter cycle; my experience - also with other projects - show that monster projects tend to make things crawl...). Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From openssh at openbsd.org Tue Jan 22 20:16:42 2002 From: openssh at openbsd.org (Markus Friedl) Date: Tue, 22 Jan 2002 10:16:42 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020122085503.GC15906@serv01.aet.tu-cottbus.de> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> <20020122002449.GA9458@serv01.aet.tu-cottbus.de> <20020122083657.GA21612@faui02> <20020122085503.GC15906@serv01.aet.tu-cottbus.de> Message-ID: <20020122091641.GA16010@faui02> On Tue, Jan 22, 2002 at 09:55:03AM +0100, Lutz Jaenicke wrote: > On Tue, Jan 22, 2002 at 09:36:57AM +0100, Markus Friedl wrote: > > On Tue, Jan 22, 2002 at 01:24:49AM +0100, Lutz Jaenicke wrote: > > > >From OpenSSL's CHANGES file: > > > +) Change all functions with names starting with des_ to be starting > > > with DES_ instead. This because there are increasing clashes with > > > libdes and other des libraries that are currently used by other > > > projects. The old libdes interface is provided, as well as crypt(), > > > if openssl/des_old.h is included. Note that crypt() is no longer > > > declared in openssl/des.h. > > > > > > NOTE: This is a major break of an old API into a new one. Software > > > authors are encouraged to switch to the DES_ style functions. Some > > > time in the future, des_old.h and the libdes compatibility functions > > > will be completely removed. > > > [Richard Levitte] > > > > why do you break the old API? why is the old API not > > the default? > > > > why don't you call this openssl-1.x instead of you really > > have to break the API? > > It's one of the compromises we have to make. people complained about > severe problems when linking against other libraries also offering > DES functionality, so the namespace had to be cleaned up somehow. But why break binary compatibility for 99% of the users if 1% have problems with linking? Why not provide an 'option' for for these 1%, that allows then to use the new API, e.g #define OPENSSL_NEW_DES_API #include > With respect to the numbering scheme: "1.0" should be the first version > from which on we promise API _and_ binary compatibility. So the reason for not calling this 1.0 is that nobody cares about binary compatibility _NOW_. The problem is that OpenSSL _is_ used, so binary _and_ API compatibility should not be discarded. > I know that version numbering of OpenSSL is quite somewhat confusing. > 0.9.7 is a major step forward from 0.9.6 (and takes far too long to > come out; it would probably be better to make more releases but in > a shorter cycle; my experience - also with other projects - show > that monster projects tend to make things crawl...). Yes, that's true. In the future we will have a time-based release scheme for OpenSSH (just like OpenBSD has a release every 6 months). -m From djm at mindrot.org Tue Jan 22 21:20:09 2002 From: djm at mindrot.org (Damien Miller) Date: 22 Jan 2002 21:20:09 +1100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020122091641.GA16010@faui02> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> <20020122002449.GA9458@serv01.aet.tu-cottbus.de> <20020122083657.GA21612@faui02> <20020122085503.GC15906@serv01.aet.tu-cottbus.de> <20020122091641.GA16010@faui02> Message-ID: <1011694809.24031.2.camel@mothra> On Tue, 2002-01-22 at 20:16, Markus Friedl wrote: > But why break binary compatibility for 99% of the > users if 1% have problems with linking? > > Why not provide an 'option' for for these 1%, > that allows then to use the new API, e.g > #define OPENSSL_NEW_DES_API > #include Or at least a way to enable the old API: #define OPENSSL_OLD_DES_API #include We don't have the luxury of only supporting the most recent OpenSSL release and we don't want to pollute our code with #ifdef's everywhere. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From jg at jguk.org Tue Jan 22 21:57:15 2002 From: jg at jguk.org (J. Grant) Date: Tue, 22 Jan 2002 19:57:15 +0900 Subject: Using OpenSSH through a SOCKS compatible firewall on your LAN References: Message-ID: <3C4D458B.5010404@jguk.org> Hello Ben, I have now written this draft guide "Using OpenSSH through a SOCKS compatible firewall on your LAN". I have attatched it to this email. All feedback is welcome, I expect still have a little to add before its ready for its first release. if you wish to give my email address to someone not on the email list please give them openssh at jguk.org JG mouring at etoh.eviladmin.org wrote: > Otherwise if you wish to do a full FAQ. html is fine. It still needs to > be send to openssh at openbsd.org and/or openssh-unix-dev at mindrot.org for > review and comments. > > - Ben > > -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-socks.html.gz Type: application/gzip Size: 2256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020122/cc59e285/attachment.bin From paluka at occultmail.com Tue Jan 22 21:09:56 2002 From: paluka at occultmail.com (John Doe) Date: Tue, 22 Jan 2002 02:09:56 -0800 (PST) Subject: Problems w/ sshd Message-ID: <20020122100956.B100736F9@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020122/164789c3/attachment.ksh From Nicolas.Williams at ubsw.com Wed Jan 23 02:21:17 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 10:21:17 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <200201212253.OAA26817@tardy.cup.hp.com>; from raj@cup.hp.com on Mon, Jan 21, 2002 at 02:53:13PM -0800 References: <200201212253.OAA26817@tardy.cup.hp.com> Message-ID: <20020122102116.J27171@sm2p1386swk.wdr.com> On Mon, Jan 21, 2002 at 02:53:13PM -0800, Rick Jones wrote: > > Merging the two messages into one write would make sftp not trigger the > > Nagle algorithm, but it would not help the X11 forwarding case, which > > really needs TCP_NODELAY. Fortunately fixing this behaviour in OpenSSH ought not require protocol changes. > Indeed X11 is one of those fun fringe things when it comes to > Nagle. It has all these pseudo-time-sensitive small messages for pesky > things like cursor position and such that have no replies coming-back > the other way. Yes, so something should probably be done about X11. Or is the current performance good enough? > In general, I would think that if ssh were acting as a pipe, it might > as well set TCP_NODELAY - ostensibly the applications on either end of > the pipe are (supposed to be) doing the "right" thing with > TCP_NODELAY. In that sense ssh should simply pass the data along since I agree in principle. A simple heuristic, like "if an SSHv2 connection has a no-pty session and at least one forwarded X11 channel open, then both the client and server ought to be smart enough to set TCP_NODELAY" would probably suffice for me. But Nagle should probably not be turned off for interactive sessions... In general with port forwarding you'd hope that the forwarder passes traffic along with the same characteristics as the original. If you're forwarding, say, CVS, and CVS uses TCP_NODELAY then the forwarder ought to use TCP_NODELAY as well, by the your suggested principle. But will a simple heuristic do? Or should there be a new SSHv2 global request type for requesting TCP_NODELAY? Should there be an SSHv2 channel-level Nagle algorythm? That would require a channgel request type to turn it on and off and an acknowledgement mechanism (gratouitous window adjusts?) and all such talk belongs, as Markus points out, at the IETF list. If heuristics will do, great. It sounds like it should be simple to fix sftp to avoid Nagle. Any other ideas that might fix X11 forwarding? Does anyone find it necessary? > it will have no prior knowledge (?) of the applications behaviour. The > argument would be somewhat like the argument that says that an > intervening router should not try to reassemable IP datagrams and > leave that to the final recipient. (Not a perfect analogy, but it is > what struck me at the moment. Sounds right. > It would seem that sftp turns what used to be a nice unidrectional > data flow into a request/response exchange. If there is no good way to > get thatSSH window piggy-backed with the Read then indeed setting > TCP_NODEALY is probably required if slighly unpleasant. Sounds like > the designers of the ssh/ssl protocl didn't keep TCP behaviour in mind > when they were doing their thing. You'd have to ask them... > rick jones Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From bradshaw at staff.crosswalk.com Wed Jan 23 03:10:43 2002 From: bradshaw at staff.crosswalk.com (Mark Bradshaw) Date: Tue, 22 Jan 2002 11:10:43 -0500 Subject: [PATCH]: scp: Avoid paths beginning with "//" Message-ID: <911C684A29ACD311921800508B7293BA037D2ABC@cnmail> Here's a new version of the patch I sent in earlier, diffed against cvs. Can someone please take a look at it. > -----Original Message----- > From: Mark Bradshaw > Sent: Monday, January 14, 2002 8:09 PM > To: openssh-unix-dev at mindrot.org > Subject: [PATCH]: scp: Avoid paths beginning with "//" > > > Scp has some path issues when transferring to or from the > root file system > of a windows machine (cygwin). It creates a path that begins > with //, which > indicates a UNC path on Windows. I sent in patches for > similar issues last > year. > > The fix is a one line change to determine if the path is "/", > and not double > up on the slashes. > > I've attached diffs to latest cvs. > > -Mark > > -------------- next part -------------- A non-text attachment was scrubbed... Name: scp.c.diff Type: application/octet-stream Size: 514 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020122/d552f7f5/attachment.obj From bbense at networking.stanford.edu Wed Jan 23 03:27:59 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Tue, 22 Jan 2002 08:27:59 -0800 (PST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020122091641.GA16010@faui02> Message-ID: On Tue, 22 Jan 2002, Markus Friedl wrote: > On Tue, Jan 22, 2002 at 09:55:03AM +0100, Lutz Jaenicke wrote: > > On Tue, Jan 22, 2002 at 09:36:57AM +0100, Markus Friedl wrote: > > > On Tue, Jan 22, 2002 at 01:24:49AM +0100, Lutz Jaenicke wrote: > > > > >From OpenSSL's CHANGES file: > > > > +) Change all functions with names starting with des_ to be starting > > > > with DES_ instead. > > > > > > why do you break the old API? why is the old API not > > > the default? > > > > > > why don't you call this openssl-1.x instead of you really > > > have to break the API? > > > > It's one of the compromises we have to make. people complained about > > severe problems when linking against other libraries also offering > > DES functionality, so the namespace had to be cleaned up somehow. > > But why break binary compatibility for 99% of the > users if 1% have problems with linking? - From my perspective this is a really good thing. It would be one thing if the OpenSSL folks had stayed with the original des implmentation, but the changed the API without changing the symbols. Basically, if you used openssl and any other api that used the "standard" des library it was extremely difficult to get things to compile. - This is why you can't put MIT k4 or k5 support easily in openssh. I think it's more than 1%, but even if it is 1% as one of that 1%, I am highly appreciative of this move. They should have done this in the first place, if the really had to twiddle with the des api. > > Why not provide an 'option' for for these 1%, > that allows then to use the new API, e.g > #define OPENSSL_NEW_DES_API > #include - Well, in fact the "old" library is a new library that never should have used the des_ symbol space to begin with. > > > With respect to the numbering scheme: "1.0" should be the first version > > from which on we promise API _and_ binary compatibility. > > So the reason for not calling this 1.0 is that nobody cares about > binary compatibility _NOW_. > > The problem is that OpenSSL _is_ used, so binary _and_ API > compatibility should not be discarded. - But, the problem is that from my perspective there is no API compatibly currently. IMHO, this is the best way out of a very bad situation. I'm sure the OpenSSL people will get a lot of flack, but this is the right thing to do. That fact that somebody was actually willing to do the right thing against their own interests has done much for my faith in open source. - The api hasn't changed that much, a simple query-replace with /des_/DES_/ should fix the src code tree once and for all. - Booker C. Bense From dan at doxpara.com Wed Jan 23 03:45:36 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 22 Jan 2002 08:45:36 -0800 Subject: OpenSSH and OpenSSL snapshots References: Message-ID: <04ba01c1a364$37f0a760$1701000a@effugas> - The api hasn't changed that much, a simple query-replace > with /des_/DES_/ should fix the src code tree once and for > all. Yes, but then new versions of OpenSSH won't compile on old (read: deployed) versions of OpenSSL. If it's hard to integrate OpenSSL with DES, that means there's probably not too many things that have that integration working. Instead, we're hoping for lots of new apps that suddenly became feasible to build. Let the new apps that have this moderately rare union -- rare enough that we made it to 2002 without it being a five alarm blaze -- include one #define. Incidentally, why DES_ vs. des_? I know this sounds a bit petty, but if there's going to be an API change, shouldn't it be one that can be spoken aloud without having to make up new words("big/capital/all-caps/etc. DES vs. the old little/tiny/babydes", the last of which has a completely different meaning). --Dan From dwd at bell-labs.com Wed Jan 23 04:32:00 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 22 Jan 2002 11:32:00 -0600 Subject: bugzilla down; patch for configure.ac --with-prngd-socket Message-ID: <20020122113200.A4954@lucent.com> Bugzilla is reporting an internal server error right now so I thought I'd post this here. The current portable OpenSSH developer CVS has some non-standard shell syntax in the --with-prngd-socket case, and the grep "-q" option is not supported in at least Solaris 2.5.1. Here's a patch. Alternatively, the first test could use case "$withval" in /*) ;; *) AC_MSG_ERROR(You must specify an absolute path to the entropy socket) ;; esac - Dave Dykstra --- configure.ac.O Tue Jan 22 11:20:41 2002 +++ configure.ac Tue Jan 22 11:22:39 2002 @@ -915,10 +915,12 @@ if test ! -z "$PRNGD_PORT" ; then AC_MSG_ERROR(You may not specify both a PRNGD/EGD port and socket) fi - if ! echo "$withval" | grep -q '^/' ; then + if echo "$withval" | grep '^/' >/dev/null; then + : + else AC_MSG_ERROR(You must specify an absolute path to the entropy socket) fi - if ! test -r "$withval" ; then + if test ! -r "$withval" ; then AC_MSG_WARN(Entropy socket is not readable) fi PRNGD_SOCKET="$withval" From mouring at etoh.eviladmin.org Wed Jan 23 05:09:13 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 22 Jan 2002 12:09:13 -0600 (CST) Subject: AIX reading /etc/environment out of step. Message-ID: I was discussing with Don about a private topic..and while skimming the code I noticed that during a 'ssh mouring at site ls' the /etc/environment is *ONLY* read if the remote machine is an AIX box. This is undocumented and I'm wondering if someone using AIX could explain WHY it exists in the session.c:do_child()? No other OS has this. I don't see why AIX should require it. Can someone JUSTIFY this to me the fact we are going against our own documentation for a single platform? - Ben From raj at cup.hp.com Wed Jan 23 05:17:29 2002 From: raj at cup.hp.com (Rick Jones) Date: Tue, 22 Jan 2002 10:17:29 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020122102116.J27171@sm2p1386swk.wdr.com> from Nicolas Williams at Jan "22," 2002 "10:21:17" am Message-ID: <200201221817.KAA14218@tardy.cup.hp.com> > > In general, I would think that if ssh were acting as a pipe, it > > might as well set TCP_NODELAY - ostensibly the applications on > > either end of the pipe are (supposed to be) doing the "right" > > thing with TCP_NODELAY. In that sense ssh should simply pass the > > data along since > > I agree in principle. A simple heuristic, like "if an SSHv2 > connection has a no-pty session and at least one forwarded X11 > channel open, then both the client and server ought to be smart > enough to set TCP_NODELAY" would probably suffice for me. But Nagle > should probably not be turned off for interactive sessions... > > In general with port forwarding you'd hope that the forwarder passes > traffic along with the same characteristics as the original. If > you're forwarding, say, CVS, and CVS uses TCP_NODELAY then the > forwarder ought to use TCP_NODELAY as well, by the your suggested > principle. I think that if ssh is operating as a pipe (is that the same as port forwarding), then if it sets TCP_NODELAY, so long as it does not do something silly like gratuitously sending logically associated data in separate sends, it will preserve the behaviour of the apps on either side - whether they set TCP_NODELAY or not. Data will arrive at the sockets the way it came-out of the TCPs on either end. > If heuristics will do, great. It sounds like it should be simple to fix > sftp to avoid Nagle. Any other ideas that might fix X11 forwarding? Does > anyone find it necessary? Since X11 sets TCP_NODELAY,one could either treat it as an example of a generic pipe (ie set TCP_NODELAY), or one could treat it as specific knowledge of the needs of the application - and in this case again set TCP_NODELAY. rick jones From Nicolas.Williams at ubsw.com Wed Jan 23 05:22:34 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 13:22:34 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <200201221817.KAA14218@tardy.cup.hp.com>; from raj@cup.hp.com on Tue, Jan 22, 2002 at 10:17:29AM -0800 References: <20020122102116.J27171@sm2p1386swk.wdr.com> <200201221817.KAA14218@tardy.cup.hp.com> Message-ID: <20020122132233.Q27171@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 10:17:29AM -0800, Rick Jones wrote: > I think that if ssh is operating as a pipe (is that the same as port > forwarding), then if it sets TCP_NODELAY, so long as it does not do > something silly like gratuitously sending logically associated data in > separate sends, it will preserve the behaviour of the apps on either > side - whether they set TCP_NODELAY or not. > Data will arrive at the sockets the way it came-out of the TCPs on > either end. Yes, agreed. Unfortunately these SSH pipes sometimes come associated with an interactive character based session, where Nagle is appropriate. > > If heuristics will do, great. It sounds like it should be simple to fix > > sftp to avoid Nagle. Any other ideas that might fix X11 forwarding? Does > > anyone find it necessary? > Since X11 sets TCP_NODELAY,one could either treat it as an example of > a generic pipe (ie set TCP_NODELAY), or one could treat it as specific > knowledge of the needs of the application - and in this case again set > TCP_NODELAY. A heuristic approach may be the best. Certainly it would be the easiest. > rick jones Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From raj at cup.hp.com Wed Jan 23 05:49:29 2002 From: raj at cup.hp.com (Rick Jones) Date: Tue, 22 Jan 2002 10:49:29 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020122132233.Q27171@sm2p1386swk.wdr.com> from Nicolas Williams at Jan "22," 2002 "01:22:34" pm Message-ID: <200201221849.KAA14786@tardy.cup.hp.com> [i'm going to start assuming that individual email addresses are on the mailing list(s) already and will start trimming them so people don't get double copies...] > Yes, agreed. Unfortunately these SSH pipes sometimes come associated > with an interactive character based session, where Nagle is > appropriate. Yep, for example, nagle was put in place for things like telnet sessions :) Where that breaks-down is when you have apps on either side that say send multi-byte escape sequences as individual single-byte sends to the transport. So, someone hits the down arrow and it takes "forever" to scroll through a screen. Then of course, those same users use an app that does a thousand separate putc()'s and they wonder why their network came to a screeching halt... oy. So, the users beat-up on the telnet providers who then are strong-armed into seting TCP_NODELAY. I suspect that any attempt by ssh to "fix" that behaviour by the end systems will only run into trouble, so I suspect that it needs to err (bletch) on the side of setting TCP_NODELAY (I cannot beleive I'm saying it, but I am). HOWEVER, ssh code must not gratuitously further break-up the data stream, and if there are cases where the ssh code can put two otherwise unrelated but small ssh messages and give them to the transport at one time, that would be goodness. rick jones From david-bronder at uiowa.edu Wed Jan 23 05:57:39 2002 From: david-bronder at uiowa.edu (David Bronder) Date: Tue, 22 Jan 2002 12:57:39 -0600 (CST) Subject: [openssh-unix-dev] AIX reading /etc/environment out of step. In-Reply-To: from "mouring@etoh.eviladmin.org" at Jan 22, 2002 12:09:13 PM Message-ID: <200201221857.g0MIve968582@fire.its.uiowa.edu> The /etc/environment file is an AIX-ism that is basically used to set system-wide environment variable defaults. In the case of interactive sessions via telnet or rlogin, I believe it is the telnetd or rlogind which reads that file, so sshd would have to do the same thing. Poor design choice, perhaps, and I could also be wrong about where /etc/environment really gets read (I haven't done any specific testing of it). But by reading it in do_child() you pick up any changes to the file without having to restart the parent sshd even if it originally gets read somewhere else. =Dave mouring at etoh.eviladmin.org wrote: > > I was discussing with Don about a private topic..and while skimming the > code I noticed that during a 'ssh mouring at site ls' the /etc/environment > is *ONLY* read if the remote machine is an AIX box. This is undocumented > and I'm wondering if someone using AIX could explain WHY it exists in the > session.c:do_child()? No other OS has this. I don't see why AIX should > require it. > > Can someone JUSTIFY this to me the fact we are going against our own > documentation for a single platform? -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From Nicolas.Williams at ubsw.com Wed Jan 23 05:59:52 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 13:59:52 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <200201221849.KAA14786@tardy.cup.hp.com>; from raj@cup.hp.com on Tue, Jan 22, 2002 at 10:49:29AM -0800 References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> Message-ID: <20020122135951.M27398@sm2p1386swk.wdr.com> So you're arguing against channel-level Nagle in SSHv2? Is it too complex? Nico On Tue, Jan 22, 2002 at 10:49:29AM -0800, Rick Jones wrote: > I suspect that any attempt by ssh to "fix" that behaviour by the end > systems will only run into trouble, so I suspect that it needs to err > (bletch) on the side of setting TCP_NODELAY (I cannot beleive I'm > saying it, but I am). HOWEVER, ssh code must not gratuitously further > break-up the data stream, and if there are cases where the ssh code > can put two otherwise unrelated but small ssh messages and give them > to the transport at one time, that would be goodness. > rick jones > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ssklar at stanford.edu Wed Jan 23 06:08:06 2002 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Tue, 22 Jan 2002 11:08:06 -0800 Subject: AIX reading /etc/environment out of step. In-Reply-To: References: Message-ID: At 12:09 PM -0600 1/22/02, wrote: >I was discussing with Don about a private topic..and while skimming the >code I noticed that during a 'ssh mouring at site ls' the /etc/environment >is *ONLY* read if the remote machine is an AIX box. This is undocumented >and I'm wondering if someone using AIX could explain WHY it exists in the >session.c:do_child()? No other OS has this. I don't see why AIX should >require it. > >Can someone JUSTIFY this to me the fact we are going against our own >documentation for a single platform? I can't justify it to you, or speak to the behavior on other platforms, but on AIX, /etc/environment is supposed to be read for *every* process's environment. Again, I don't know much about other platforms, if it is not read on AIX, then the process will have no concept of the standard variables whose values would be assumed, i.e., "TZ", "LANG", "LOCPATH", "NLSPATH", and perhaps most important, "ODMDIR". How other OSes deal with those items is something I don't know anything about. In short, I don't know if it is considered "correct" or not, based on the OpenSSH documentation, but I suspect that if it is changed, AIX will break and the word will end. From the "environment" manpage ... environment File Purpose Sets up the user environment. Description The /etc/environment file contains variables specifying the basic environment for all processes. When a new process begins, the exec subroutine makes an array of strings available that have the form Name=Value. This array of strings is called the environment. Each name defined by one of the strings is called an environment variable or shell variable. The exec subroutine allows the entire environment to be set at one time. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sandor W. Sklar - Unix Systems Administrator - Stanford University ITSS Non impediti ratione cogitationis. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rick_jones2 at hp.com Wed Jan 23 06:37:54 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 22 Jan 2002 11:37:54 -0800 Subject: [PATCH] Using TCP_NODELAY unconditionally References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> Message-ID: <3C4DBF92.B4AD9F70@hp.com> Nicolas Williams wrote: > > So you're arguing against channel-level Nagle in SSHv2? Is it too > complex? I guess what I am driving at is that unless there are gratuitous things being done by SSH to further break-up the data it is forwarding, setting TCP_NODELAY will "preserve" the on-the-wire appearance of the applications at either end. It does not matter if they set TCP_NODELAY or if they did not. If the app did not set TCP_NODELAY, its first small send will arrive at ssh's socket, and ssh will send that along (yes?). The ACK from the ssh host will be sent back to the app's TCP, and the rest of the small sends will be send and will arrive and ostensibly be recieved in one swell foop by ssh (it does use a reasonably large recv buffer yes?) and then will be passed-along by ssh on the other side. If the app _did_ set TCP_NODELAY, all the small sends will start arriving, and it will be a race between SSH and the remote. If ssh is faster than the remote, then the sends ssh makes out the other side will also be small, just like the app did originally. If SSH is not quite as fast, those little sends will accumulate in the socket buffer and ssh will then read larger chunks and presumeably send larger chunks out the other side. So, from that standpoint, any loss of interactive responsiveness in something like say X11 may be caused as much by ssh not being as fast as the endpoint(s) and chunking those mouse events as a result. From the standpoint of the network and a network purist, this is perhaps actualy a _good_ thing :) However, it is not good enough that I would ask that ssh try to make this explicitly happen. Now, when SSH _does_ get a big chunk of data from one side, if that has to become several ssh "messages" (I'm assuming that ssh in essense introduces message boundaries thanks to the encryption?) that those several ssh "messages" be presented to the transport in one send call (perhaps writev or sendmsg). To do otherwise I would _probably_ call a gratuitous breaking-up of the data it received to be passed-along. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From djast at cs.toronto.edu Wed Jan 23 06:45:08 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 22 Jan 2002 14:45:08 -0500 Subject: ssh-rand-helper Message-ID: <02Jan22.144510edt.453151-5649@jane.cs.toronto.edu> Now that ssh-rand-helper has been segregated into a separate program, I'd like to revisit an old question about its entropy gathering. - would it be desirable to make it possible for ssh-rand-helper to fall back to external commands if PRNGD cannot be reached, instead of choosing one or the other at compile time? - When using PRNGD, the program gets 48 bytes of entropy from PRNGD, stirs it into OpenSSL's RAND_add(), and outputs 48 bytes of pseudorandom bytes based on this entropy. Does this present any advantage over just dumping the 48 bytes of entropy received from PRNGD directly? The semantics I'm envisioning here: Define USE_PRNGD, USE_CMDS, or both. Case 1: USE_PRNGD && USE_CMDS: read_seedfile() fetch 96 bytes from PRNGD if successful output(bytes 1-48) RAND_add(bytes 49-96) /* for seedfile */ Otherwise stir_from_commands() stir_from_system() output(RAND_bytes(48)) write_seedfile() Case 2: !USE_PRNGD && USE_CMDS: read_seedfile() stir_from_commands() stir_from_system() output(RAND_bytes(48)) write_seedfile() Case 3: USE_PRNGD && !USE_CMDS: fetch 48 bytes from PRNGD if successful output(bytes) Note that the seedfile is always read and written if USE_CMDS is defined even if the entropy comes from PRNGD, so that there's a good seedfile available in case PRNGD goes away. Would a patch (or rewrite) to implement this be welcome? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From Nicolas.Williams at ubsw.com Wed Jan 23 06:55:46 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 14:55:46 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DBF92.B4AD9F70@hp.com>; from rick_jones2@hp.com on Tue, Jan 22, 2002 at 11:37:54AM -0800 References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> Message-ID: <20020122145544.N27398@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 11:37:54AM -0800, Rick Jones wrote: > Nicolas Williams wrote: > > > > So you're arguing against channel-level Nagle in SSHv2? Is it too > > complex? > > I guess what I am driving at is that unless there are gratuitous things > being done by SSH to further break-up the data it is forwarding, setting > TCP_NODELAY will "preserve" the on-the-wire appearance of the > applications at either end. It does not matter if they set TCP_NODELAY > or if they did not. But SSH is not all about forwarding other protocols. It's also about character-based interactive sessions. [...] > rick jones > -- Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From dwd at bell-labs.com Wed Jan 23 07:47:23 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 22 Jan 2002 14:47:23 -0600 Subject: ssh-rand-helper In-Reply-To: <02Jan22.144510edt.453151-5649@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Jan 22, 2002 at 02:45:08PM -0500 References: <02Jan22.144510edt.453151-5649@jane.cs.toronto.edu> Message-ID: <20020122144723.A8594@lucent.com> On Tue, Jan 22, 2002 at 02:45:08PM -0500, Dan Astoorian wrote: > Now that ssh-rand-helper has been segregated into a separate program, > I'd like to revisit an old question about its entropy gathering. A related topic has had some discussion on the secureshell at securityfocus.com recently in the thread "Question on prngd and slow OpenSSH". > - would it be desirable to make it possible for ssh-rand-helper to fall > back to external commands if PRNGD cannot be reached, instead of > choosing one or the other at compile time? Ben said we should use OpenSSL's interface into PRNGD (at least the socket mode) instead and let ssh-rand-helper do running of commands. I think that makes sense. I first learned about RAND_egd() from you so I know you are familiar with it, but I finally got a chance to try it recently and I think it's a good way to go. > - When using PRNGD, the program gets 48 bytes of entropy from PRNGD, > stirs it into OpenSSL's RAND_add(), and outputs 48 bytes of > pseudorandom bytes based on this entropy. Does this present any > advantage over just dumping the 48 bytes of entropy received from > PRNGD directly? I don't see any. I thought it was peculiar for ssh-rand-helper to link with OpenSSL at all, PRNGD doesn't. > The semantics I'm envisioning here: > > Define USE_PRNGD, USE_CMDS, or both. > > Case 1: USE_PRNGD && USE_CMDS: > read_seedfile() > fetch 96 bytes from PRNGD > if successful > output(bytes 1-48) > RAND_add(bytes 49-96) /* for seedfile */ > Otherwise > stir_from_commands() > stir_from_system() > output(RAND_bytes(48)) > > write_seedfile() > > Case 2: !USE_PRNGD && USE_CMDS: > read_seedfile() > stir_from_commands() > stir_from_system() > output(RAND_bytes(48)) > write_seedfile() > > Case 3: USE_PRNGD && !USE_CMDS: > fetch 48 bytes from PRNGD > if successful > output(bytes) > > Note that the seedfile is always read and written if USE_CMDS is defined > even if the entropy comes from PRNGD, so that there's a good seedfile > available in case PRNGD goes away. > > Would a patch (or rewrite) to implement this be welcome? I'm thinking I'll write a patch for PRNGD to have an option to be the ssh-rand-helper. I also want it to skip the long "stir_from_commands" if the seedfile is valid. - Dave Dykstra From rick_jones2 at hp.com Wed Jan 23 07:52:50 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 22 Jan 2002 12:52:50 -0800 Subject: [PATCH] Using TCP_NODELAY unconditionally References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> Message-ID: <3C4DD122.59AEA8DE@hp.com> Nicolas Williams wrote: > But SSH is not all about forwarding other protocols. It's also > about character-based interactive sessions. True. My discussion about setting TCP_NODELAY was for the case when sshis operating as a forwarder. If ssh is operating as an end application itself, then a different set of rules/heuristics may apply. The purist in me would say that if ssh is operating as an end-application (pseudo-source if you will) then its default behaviour should be to _not_ enable TCP_NODELAY. My reasoning is that if ssh is receiving data from something "well behaved" it will not matter, and if it is receiving data from something _not_ well behaved, it will make a huge difference in the network overhead. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From Nicolas.Williams at ubsw.com Wed Jan 23 08:10:19 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 16:10:19 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DD122.59AEA8DE@hp.com>; from rick_jones2@hp.com on Tue, Jan 22, 2002 at 12:52:50PM -0800 References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> Message-ID: <20020122161018.O27398@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 12:52:50PM -0800, Rick Jones wrote: > Nicolas Williams wrote: > > But SSH is not all about forwarding other protocols. It's also > > about character-based interactive sessions. > > True. My discussion about setting TCP_NODELAY was for the case when > sshis operating as a forwarder. If ssh is operating as an end > application itself, then a different set of rules/heuristics may apply. Fine, but what if you're mixing both, interactive sessions and port forwarding in the same SSHv2 connection? See? Problem. Also, heuristics can be a bit sucky, in that you have to count on both sides applying the same heuristics, which is why a global SSHv2 request for the client to ask the server to enable TCP_NODELAY would be good. I think at the very least there should be a global SSHv2 request as above and that if we'll rely on heuristics then it should be the client that applies them and requests the server to set or not set TCP_NODELAY. At most SSHv2 connections should always have TCP_NODELAY set and then Nagle should be a per-channel option. > The purist in me would say that if ssh is operating as an > end-application (pseudo-source if you will) then its default behaviour > should be to _not_ enable TCP_NODELAY. My reasoning is that if ssh is > receiving data from something "well behaved" it will not matter, and if > it is receiving data from something _not_ well behaved, it will make a > huge difference in the network overhead. Well, since you can mix general port forwarding with interactive sessions I would say that you can't be a purist on this issue without also arguing for per-channel Nagle at the SSHv2 level. :) :) > rick jones > -- Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From rick_jones2 at hp.com Wed Jan 23 08:20:02 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 22 Jan 2002 13:20:02 -0800 Subject: [PATCH] Using TCP_NODELAY unconditionally References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> <20020122161018.O27398@sm2p1386swk.wdr.com> Message-ID: <3C4DD782.6CAC8E48@hp.com> > Fine, but what if you're mixing both, interactive sessions and port > forwarding in the same SSHv2 connection? See? Problem. Um, do you mean port forwarding for interactive sessions on either end? That goes under the acting as a pipe heuristic. Of do you mean that a single instance of ssh might be doing both port-forwarding _and_ acting as an interactive data source at the same time?!? (and on the same TCP connection - again does it show that i'm new to all this ssh stuff?-) rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From bugzilla-daemon at mindrot.org Wed Jan 23 08:32:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 08:32:33 +1100 (EST) Subject: [Bug 74] Use of sig_atomic_t breaks SunOS4 compile Message-ID: <20020122213233.CE09FE9D9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=74 ------- Additional Comments From dwd at bell-labs.com 2002-01-23 08:32 ------- Created an attachment (id=11) Patch to add configure test for missing sig_atomic_t ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Nicolas.Williams at ubsw.com Wed Jan 23 08:34:32 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 16:34:32 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DD782.6CAC8E48@hp.com>; from rick_jones2@hp.com on Tue, Jan 22, 2002 at 01:20:02PM -0800 References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> <20020122161018.O27398@sm2p1386swk.wdr.com> <3C4DD782.6CAC8E48@hp.com> Message-ID: <20020122163430.P27398@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 01:20:02PM -0800, Rick Jones wrote: > > > Fine, but what if you're mixing both, interactive sessions and port > > forwarding in the same SSHv2 connection? See? Problem. > > Um, do you mean port forwarding for interactive sessions on either end? > That goes under the acting as a pipe heuristic. > > Of do you mean that a single instance of ssh might be doing both > port-forwarding _and_ acting as an interactive data source at the same > time?!? (and on the same TCP connection - again does it show that i'm > new to all this ssh stuff?-) The latter. Do you use SSH? It's like TELNET, but it can also do port forwarding over the same TCP connection as the main session, and it always encrypts TCP traffic, and it supports a variety of authentication mechanisms, but its main use is as a replacement for TELNET/RLOGIN. The main SSH abstraction that you should be interested in, wrt this discussion, is the channels abstraction, whereby SSHv2 multiplexes multiple streams onto one TCP session - some channels may be associated with, say, a login session, whereas others may be associated with X11 forwarding. > rick jones Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Wed Jan 23 08:42:52 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 16:42:52 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020120152348.A7223@folly>; from markus@openbsd.org on Sun, Jan 20, 2002 at 03:23:48PM +0100 References: <20020120152348.A7223@folly> Message-ID: <20020122164250.Q27398@sm2p1386swk.wdr.com> On Sun, Jan 20, 2002 at 03:23:48PM +0100, Markus Friedl wrote: > On Sun, Jan 20, 2002 at 12:26:15AM +0100, Tobias Ringstrom wrote: > > It is easy to theoretically > > show how Nagle kills performance when you have a request-reply packet > > based protocol. > > not everybody thinks like you > > http://groups.google.com/groups?th=885385572a5a4219&seekm=990719183329.AA27312%40dojo.mi.org&frame=off > > but i guess, it would be better if ssh implements a nagle-like > algorithms itself. Ok agreed. But, in the meantime, what is the rationale for turning Nagle off for interactive sessions and leaving it on for all others? I would expect the reverse... > -m Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From djast at cs.toronto.edu Wed Jan 23 08:43:57 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 22 Jan 2002 16:43:57 -0500 Subject: ssh-rand-helper In-Reply-To: Your message of "Tue, 22 Jan 2002 15:47:23 EST." <20020122144723.A8594@lucent.com> Message-ID: <02Jan22.164358edt.453152-5649@jane.cs.toronto.edu> On Tue, 22 Jan 2002 15:47:23 EST, Dave Dykstra writes: > > - would it be desirable to make it possible for ssh-rand-helper to fall > > back to external commands if PRNGD cannot be reached, instead of > > choosing one or the other at compile time? > > Ben said we should use OpenSSL's interface into PRNGD (at least the socket > mode) instead and let ssh-rand-helper do running of commands. I think that > makes sense. I first learned about RAND_egd() from you so I know you are > familiar with it, but I finally got a chance to try it recently and I think > it's a good way to go. Now that djm has finally managed to fumigate the entropy-gathering cruft from entropy.c, I fear he might be reluctant to let RAND_egd() calls back into it. Older releases of OpenSSL don't have RAND_egd(), which is presumably the reason why the code to connect to it exists in ssh-rand-helper.c. Furthermore, OpenSSL has no analog to PRNGD_PORT (PRNGD via TCP), so ssh-rand-helper has to support PRNGD in some form in any case. Personally, I think the ideal would be something like if OpenSSL-version >= 0.9.5 (i.e., RAND_egd() exists) include RAND_egd(PRNGD_SOCKET) calls in entropy.c omit PRNGD_SOCKET code in ssh-rand-helper.c else use existing PRNGD_SOCKET code in ssh-rand-helper.c at configure-time. > I don't see any. I thought it was peculiar for ssh-rand-helper to link > with OpenSSL at all, PRNGD doesn't. PRNGD has its own secure hash algorithm (SHA borrowed from mhash-0.8.5). Since OpenSSH already depends on OpenSSL, it makes much more sense to link against it rather than adding hashing code to ssh-rand-helper. I don't see any need for a hash algorithm if random bytes are being retrieved from PRNGD, but making use of command outputs etc. would still require one. > I'm thinking I'll write a patch for PRNGD to have an option to be the > ssh-rand-helper. I also want it to skip the long "stir_from_commands" > if the seedfile is valid. Notwithstanding your reasonable arguments for why the seedfile should be entirely sufficient, I'm reluctant, merely out of conservatism, to go that far. At the very least, I'd want to insist that the definition of "the seedfile is valid" includes "a new seedfile was successfully written," because I can't prove that using the same seedfile more than once in conjunction with the pittance of entropy provided by stir_from_system() would be safe from a cryptoanalytical standpoint. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From rick_jones2 at hp.com Wed Jan 23 08:53:53 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 22 Jan 2002 13:53:53 -0800 Subject: [PATCH] Using TCP_NODELAY unconditionally References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> <20020122161018.O27398@sm2p1386swk.wdr.com> <3C4DD782.6CAC8E48@hp.com> <20020122163430.P27398@sm2p1386swk.wdr.com> Message-ID: <3C4DDF71.4DC200D9@hp.com> > The latter. Then port forwarding trumps. > Do you use SSH? Yes. > It's like TELNET, but it can also do port forwarding > over the same TCP connection as the main session, But I've not used that feature. (At least not knowingly...) > and it always encrypts TCP traffic, and it supports a variety of > authentication mechanisms, but its main use is as a replacement for > TELNET/RLOGIN. Which has been my end-user experience thusfar (well, and scp). > The main SSH abstraction that you should be interested in, wrt this > discussion, is the channels abstraction, whereby SSHv2 multiplexes > multiple streams onto one TCP session - some channels may be > associated with, say, a login session, whereas others may be > associated with X11 forwarding. So, ssh is both the floor wax and the desert topping... Modulo all the vendors having been forced to kludge their telnets to disable nagle by default (grrrr) I would say that an interactive session should start with nalge still on (my quixotic hope of undoing the aforementioned telnet kludges) but when ssh is acting as a session-layer mux that the presence of a second session over the same TCP connection calls for setting TCP_NODELAY. Otherwise, two applicatoins that know nothing about one another, which would otherwise _not_ run afould of the interaction between nagle and delayed ack on their own would start to run afould of it. I still hold-onto the quixotic hope of keeping nagle on for single session connections. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From Nicolas.Williams at ubsw.com Wed Jan 23 09:22:39 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 22 Jan 2002 17:22:39 -0500 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DDF71.4DC200D9@hp.com>; from rick_jones2@hp.com on Tue, Jan 22, 2002 at 01:53:53PM -0800 References: <20020122132233.Q27171@sm2p1386swk.wdr.com> <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> <20020122161018.O27398@sm2p1386swk.wdr.com> <3C4DD782.6CAC8E48@hp.com> <20020122163430.P27398@sm2p1386swk.wdr.com> <3C4DDF71.4DC200D9@hp.com> Message-ID: <20020122172237.R27398@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 01:53:53PM -0800, Rick Jones wrote: > > > The latter. > > Then port forwarding trumps. Ok. OpenSSH team? :) > > The main SSH abstraction that you should be interested in, wrt this > > discussion, is the channels abstraction, whereby SSHv2 multiplexes > > multiple streams onto one TCP session - some channels may be > > associated with, say, a login session, whereas others may be > > associated with X11 forwarding. > > So, ssh is both the floor wax and the desert topping... Yes. It's the transport layer. As such you'd expect the underlying transport that SSH uses (TCP) should not implement Nagle and that Nagle should be implemented at the SSH layer, if at all. > Modulo all the vendors having been forced to kludge their telnets to > disable nagle by default (grrrr) I would say that an interactive session > should start with nalge still on (my quixotic hope of undoing the > aforementioned telnet kludges) but when ssh is acting as a session-layer > mux that the presence of a second session over the same TCP connection > calls for setting TCP_NODELAY. Otherwise, two applicatoins that know > nothing about one another, which would otherwise _not_ run afould of the > interaction between nagle and delayed ack on their own would start to > run afould of it. OpenSSH currently turns off Nagle only when an interactive session is running. You suggest that the reverse should be the case. OpenSSH Team: why is Nagle turned off only for interactive sessions? OpenSSH Team: what are your objections to reverse the current situation, with respect to Nagle, or even just turning it off altogether? Should Nagle-at-the-SSH-layer be advocated at the IETF SECSH working group? > I still hold-onto the quixotic hope of keeping nagle on for single > session connections. Your hope is quixotic alright. I think there's a better chance of the SSHv2 protocol being changed to implement Nagle on a per-channel basis at the SSHv2 layer than there is of making Nagle-at-the-TCP-layer work well with SSHv2, interoperably well that is. > rick jones Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From gert at greenie.muc.de Wed Jan 23 09:28:14 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 22 Jan 2002 23:28:14 +0100 Subject: AIX reading /etc/environment out of step. In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Jan 22, 2002 at 12:09:13PM -0600 References: Message-ID: <20020122232814.C15723@greenie.muc.de> Hi, On Tue, Jan 22, 2002 at 12:09:13PM -0600, mouring at etoh.eviladmin.org wrote: > I was discussing with Don about a private topic..and while skimming the > code I noticed that during a 'ssh mouring at site ls' the /etc/environment > is *ONLY* read if the remote machine is an AIX box. This is undocumented > and I'm wondering if someone using AIX could explain WHY it exists in the > session.c:do_child()? No other OS has this. I don't see why AIX should > require it. All other ways to log into AIX read this. So by doing it you're easing switchover from rlogin/whatever to ssh. 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 Zoran.Milojevic at SS8.com Wed Jan 23 09:38:36 2002 From: Zoran.Milojevic at SS8.com (Zoran Milojevic) Date: Tue, 22 Jan 2002 17:38:36 -0500 Subject: [openssh-unix-dev] Re: contrib/solaris/opensshd.in patch Message-ID: <8BAF8B40C4D2D411ADC300508BD63D69A195AF@mail.ss8.ca> Here's a try for the PID thing; I also included a startup check for a running sshd, just for the kicks. Z --- opensshd.in.old Fri Jan 18 15:47:21 2002 +++ opensshd.in.new Tue Jan 22 17:33:42 2002 @@ -3,11 +3,9 @@ # # Stripped PRNGd out of it for the time being. -AWK=/usr/bin/awk CAT=/usr/bin/cat KILL=/usr/bin/kill PS=/usr/bin/ps -XARGS=/usr/bin/xargs prefix=%%openSSHDir%% etcdir=%%configDir%% @@ -20,12 +18,6 @@ HOST_KEY_DSA=$etcdir/ssh_host_dsa_key HOST_KEY_RSA=$etcdir/ssh_host_rsa_key -killproc() { - _procname=$1 - _signal=$2 - ${PS} -u root | ${AWK} '/'"$_procname"'$/ {print $1}' | ${XARGS} ${KILL} -} - checkkeys() { if [ ! -f $HOST_KEY_RSA1 ]; then @@ -39,21 +31,38 @@ fi } -stop_service() { +find_pid() { if [ -r $PIDFILE -a ! -z ${PIDFILE} ]; then PID=`${CAT} ${PIDFILE}` fi if [ ${PID:=0} -gt 1 -a ! "X$PID" = "X " ]; then - ${KILL} ${PID} + PROC=`${PS} -ofname= -p $PID` + if [ "${PROC}" = "`basename $SSHD`" ]; then + return + fi + fi + PID=0 +} + + +stop_service() { + find_pid + if [ ${PID} -gt 1 ]; then + ${KILL} ${PID} else - echo "Unable to read PID file, killing using alternate method" - killproc sshd TERM + echo "Unable to locate the master sshd process." + echo "You may have to manually kill it later." fi } start_service() { - # XXX We really should check if the service is already going, but - # XXX we will opt out at this time. - Bal + find_pid + if [ ${PID} -gt 1 ]; then + # XXX do we kill running sshd, or abort here? + # ${KILL} ${PID} + echo "sshd already running - use 'restart' to restart." + return + fi # Check to see if we have keys that need to be made checkkeys -- Zoran Milojevic SS8 Networks Inc. http://www.ss8.com "One Better" Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 > -----Original Message----- > From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org] > Sent: January 21, 2002 00:36 > To: Frank Cusack > Cc: David Bronder; openssh-unix-dev at mindrot.org > Subject: Re: [openssh-unix-dev] Re: contrib/solaris/opensshd.in patch > > > > And if someone does not send a patch by Wed.. I'll > write my own and > commit it with the exec-prefix change. > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020122/f48e68ac/attachment.html From tori at ringstrom.mine.nu Wed Jan 23 09:41:16 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 22 Jan 2002 23:41:16 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020122164250.Q27398@sm2p1386swk.wdr.com> Message-ID: [I cannot keep up with the amazingly fast typers Nico and Rick, so there is some overlap...] On Tue, 22 Jan 2002, Nicolas Williams wrote: > On Sun, Jan 20, 2002 at 03:23:48PM +0100, Markus Friedl wrote: > > > but i guess, it would be better if ssh implements a nagle-like > > algorithms itself. I've thought about this some more, and it will be hard to implement. I think we would need an SSH ack packet for all data packets. If we added that, we would be able to implement our own nagle, but we would kill the delayed-ack feature of TCP, and gain nothing. Any ideas how to solve that? > But, in the meantime, what is the rationale for turning Nagle off for > interactive sessions and leaving it on for all others? > > I would expect the reverse... Me to, but remember that the primary purpose of nagle is to reduce the number of tinygrams on the network, not neccesarily to improve the "interactivity feeling". (pardon my bad english) Consider a case where the RTT is 1 s, and I type 10 characters within that time, and for simplicity, plain-text tcp: With Nagle ---------- packets: 2 header bytes: 2*52 = 104 bytes (tcp with timestamp, data direction) time: 1.5 seconds (from first character is sent to last is received, and assuming a symmetric link of infinite "bandwidth") user experience: very "choppy" Without Nagle: -------------- packets: 10 header bytes: 10*52 = 520 time: 1.5 seconds user experience: delayed but smooth Now, if we add a limited bandwith to the above, the nagle case would have better average latency, but it would be less smooth. I'd say that whether you want nagle on or off in this case is a matter of taste (unless you have to pay for your bytes...). To summarize: * Nagle should be turned off for X11 sessions. * Nagle could be either on or off for pure shell sessions. (taste) * Nagle can be off for sftp, since it is well behaved, and does not generate unneccesary tinygrams. Probably true for all (future) subsystems as well. The current problem we have with nagle and sftp can either be solved by letting nagle merge our two tinygrams, or by merging them in the ssh code. I'd prefer adding buffering to ssh to merge them in the application. Marcus? My suggestion is to turn off nagle unconditionally now, and to add an option later to turn it on, perhaps make it on by default for pure shell sessions. And it would be really really helpful if there was a way for the ssh client to tell the server to turn nagle off. /Tobias ( Nico, you really really need do do something about your pathetic sig... ;) From djm at mindrot.org Wed Jan 23 10:10:58 2002 From: djm at mindrot.org (Damien Miller) Date: 23 Jan 2002 10:10:58 +1100 Subject: ssh-rand-helper In-Reply-To: <02Jan22.164358edt.453152-5649@jane.cs.toronto.edu> References: <02Jan22.164358edt.453152-5649@jane.cs.toronto.edu> Message-ID: <1011741058.14453.18.camel@xenon> On Wed, 2002-01-23 at 08:43, Dan Astoorian wrote: > Now that djm has finally managed to fumigate the entropy-gathering cruft > from entropy.c, I fear he might be reluctant to let RAND_egd() calls > back into it. I'd rather see some way to configure OpenSSL do fetch entropy from EGD within the library itself. Currently it does this from /dev/urandom if it is detected at compile time, so it isn't too great a step. With the recent changes to portable OpenSSH, that would make mean that you would not need to configure anything if your OpenSSL installation is set up right. > Older releases of OpenSSL don't have RAND_egd(), which is presumably the > reason why the code to connect to it exists in ssh-rand-helper.c. RAND_egd doesn't support fetching from a localhost socket either, at least not in my version of OpenSSL. -d From rick_jones2 at hp.com Wed Jan 23 10:58:59 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 22 Jan 2002 15:58:59 -0800 Subject: [PATCH] Using TCP_NODELAY unconditionally References: Message-ID: <3C4DFCC3.31C67F3D@hp.com> > Me to, but remember that the primary purpose of nagle is to reduce the > number of tinygrams on the network, not neccesarily to improve the > "interactivity feeling". (pardon my bad english) The english is fine and the message expressed is spot-on. > Consider a case where the RTT is 1 s, and I type 10 characters within > that time, and for simplicity, plain-text tcp: Well, you need to include the ACK packets that may or may not be sent, but otherwise the analysis looks OK. > * Nagle should be turned off for X11 sessions. > > * Nagle could be either on or off for pure shell sessions. (taste) > > * Nagle can be off for sftp, since it is well behaved, and does not > generate unneccesary tinygrams. Probably true for all (future) > subsystems as well. The current problem we have with nagle and sftp > can either be solved by letting nagle merge our two tinygrams, or by > merging them in the ssh code. I'd prefer adding buffering to ssh to > merge them in the application. Marcus? "Conservative in what you send" would seem to suggest that assuming that future subsystems are well-behaved is not a given :) Also, what does an ASCII mode transfer sftp session look like? Is it still nice large sends, or is is a series of oneliners? rick jones as for the fast typing, blame my mother - she wanted to be sure that I could pass the US Civil Service Entrance Examination (from years ago) so that if all else failed I could become a clerk :) So, there I was, a small, young, teenage boy lugging this _heavy_ Smith_corona electric typewriter to a typing class where I was both the youngest student and only male - and too young to appreciate that fact :). And to add insult to injury, IIRC I needed to sit on phone books or something to be high enough to have proper typing position... -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From djast at cs.toronto.edu Wed Jan 23 10:59:56 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 22 Jan 2002 18:59:56 -0500 Subject: ssh-rand-helper In-Reply-To: Your message of "Tue, 22 Jan 2002 18:10:58 EST." <1011741058.14453.18.camel@xenon> Message-ID: <02Jan22.185957edt.453153-5649@jane.cs.toronto.edu> On Tue, 22 Jan 2002 18:10:58 EST, Damien Miller writes: > > I'd rather see some way to configure OpenSSL do fetch entropy from EGD > within the library itself. Currently it does this from /dev/urandom if > it is detected at compile time, so it isn't too great a step. OpenSSL 0.9.7 (according to their website) will do this, if the socket is where the library expects it to be; i.e., /var/run/egd-pool, /dev/egd-pool, /etc/egd-pool or /etc/entropy. However, I don't want the socket to live in any of those locations on my systems, because I don't run it with enough privileges to bind() in /var/run, /dev, or /etc. I might change my mind if and when an option is added to PRNGD to give away root privileges after initialization. Moreover, for the forseeable future we will still need to be able to use OpenSSL releases prior to 0.9.7 with OpenSSH, which means using either RAND_egd() or the existing code in ssh-rand-helper.c. In a nutshell: 1) It would be good if the library connected to PRNGD on its own; however, currently, it doesn't. 2) Since the library doesn't connect to PRNGD (yet), we need to bridge the gap somewhere. We do so already, in ssh-rand-helper. 3) If RAND_egd() is available, using it in entropy.c instead of forking ssh-rand-helper is an obvious and unobtrusive optimization--literally one line of code ("if (!RAND_status()) RAND_egd(PRNGD_SOCKET)"), with an #ifdef around it. I would not be suggesting this might be done in entropy.c if it were not so utterly trivial. If there's consensus that, as (according to Dave) Ben said, "we should use OpenSSL's interface into PRNGD", then entropy.c would be the only sensible place to do so--replacing the PRNGD_SOCKET code in ssh-rand-helper.c with RAND_egd() would preclude using SSL libraries that don't provide it. > RAND_egd doesn't support fetching from a localhost socket either, at > least not in my version of OpenSSL. (I believe I mentioned that, actually.) This is why the code in ssh-rand-helper which connects to the localhost socket should be kept; sites which use localhost sockets, or which have SSL libraries without RAND_egd(), would have to use ssh-rand-helper. I'm still interested in opinions about my original question, which was whether changing ssh-rand-helper to be able to support at build time both PRNGD and stir_from_commands() etc. simultaneously would be welcome. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From deraadt at cvs.openbsd.org Wed Jan 23 11:42:56 2002 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Tue, 22 Jan 2002 17:42:56 -0700 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: Your message of "Tue, 22 Jan 2002 08:27:59 PST." Message-ID: <200201230042.g0N0gu3I026655@cvs.openbsd.org> You have no idea how wrong you are. You want us ot #ifdef openssh? We will not. Instead, we will make it workwith one openssl version on. For now, we willl choose the old, and not move to the new for ... lemme see.. shall I say 4 years? > Return-Path: bbense at shred.stanford.edu > Delivery-Date: Tue Jan 22 09:35:46 2002 > Received: from openbsd.cs.colorado.edu (openbsd.cs.colorado.edu [128.138.192.83]) > by cvs.openbsd.org (8.12.1/8.12.1) with ESMTP id g0MGXA3J032556 > (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=FAIL) > for ; Tue, 22 Jan 2002 09:33:11 -0700 (MST) > Received: from shred.stanford.edu (shred.Stanford.EDU [171.64.13.91]) > by openbsd.cs.colorado.edu (8.12.2/8.12.2) with ESMTP id g0MGS5mZ000937 > for ; Tue, 22 Jan 2002 09:28:05 -0700 (MST) > Received: from localhost (bbense at localhost) > by shred.stanford.edu (8.11.6.Beta0/8.10.0.PreAlpha1) with ESMTP id g0MGRx909841; > Tue, 22 Jan 2002 08:27:59 -0800 (PST) > Date: Tue, 22 Jan 2002 08:27:59 -0800 (PST) > From: "Booker C. Bense" > To: Markus Friedl > cc: "'openssh-unix-dev at mindrot.org'" > Subject: Re: OpenSSH and OpenSSL snapshots > In-Reply-To: <20020122091641.GA16010 at faui02> > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Tue, 22 Jan 2002, Markus Friedl wrote: > > > On Tue, Jan 22, 2002 at 09:55:03AM +0100, Lutz Jaenicke wrote: > > > On Tue, Jan 22, 2002 at 09:36:57AM +0100, Markus Friedl wrote: > > > > On Tue, Jan 22, 2002 at 01:24:49AM +0100, Lutz Jaenicke wrote: > > > > > >From OpenSSL's CHANGES file: > > > > > +) Change all functions with names starting with des_ to be starting > > > > > with DES_ instead. > > > > > > > > why do you break the old API? why is the old API not > > > > the default? > > > > > > > > why don't you call this openssl-1.x instead of you really > > > > have to break the API? > > > > > > It's one of the compromises we have to make. people complained about > > > severe problems when linking against other libraries also offering > > > DES functionality, so the namespace had to be cleaned up somehow. > > > > But why break binary compatibility for 99% of the > > users if 1% have problems with linking? > > - From my perspective this is a really good thing. It would be one > thing if the OpenSSL folks had stayed with the original des > implmentation, but the changed the API without changing the symbols. > Basically, if you used openssl and any other api that used the > "standard" des library it was extremely difficult to get things > to compile. > > - This is why you can't put MIT k4 or k5 support easily in openssh. > I think it's more than 1%, but even if it is 1% as one of that 1%, > I am highly appreciative of this move. They should have done this > in the first place, if the really had to twiddle with the des api. > > > > > Why not provide an 'option' for for these 1%, > > that allows then to use the new API, e.g > > #define OPENSSL_NEW_DES_API > > #include > > - Well, in fact the "old" library is a new library that > never should have used the des_ symbol space to begin with. > > > > > > With respect to the numbering scheme: "1.0" should be the first version > > > from which on we promise API _and_ binary compatibility. > > > > So the reason for not calling this 1.0 is that nobody cares about > > binary compatibility _NOW_. > > > > The problem is that OpenSSL _is_ used, so binary _and_ API > > compatibility should not be discarded. > > - But, the problem is that from my perspective there is no > API compatibly currently. IMHO, this is the best way out of > a very bad situation. I'm sure the OpenSSL people will get > a lot of flack, but this is the right thing to do. That fact > that somebody was actually willing to do the right thing > against their own interests has done much for my faith in > open source. > > - The api hasn't changed that much, a simple query-replace > with /des_/DES_/ should fix the src code tree once and for > all. > > - Booker C. Bense > From djm at mindrot.org Wed Jan 23 12:15:22 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Jan 2002 12:15:22 +1100 (EST) Subject: ssh-rand-helper In-Reply-To: <02Jan22.185957edt.453153-5649@jane.cs.toronto.edu> Message-ID: On Wed, 2002-01-23 at 10:59, Dan Astoorian wrote: > On Tue, 22 Jan 2002 18:10:58 EST, Damien Miller writes: > > > > I'd rather see some way to configure OpenSSL do fetch entropy from EGD > > within the library itself. Currently it does this from /dev/urandom if > > it is detected at compile time, so it isn't too great a step. > > OpenSSL 0.9.7 (according to their website) will do this, if the socket > is where the library expects it to be; i.e., /var/run/egd-pool, > /dev/egd-pool, /etc/egd-pool or /etc/entropy. > > However, I don't want the socket to live in any of those locations on my > systems, because I don't run it with enough privileges to bind() in > /var/run, /dev, or /etc. I might change my mind if and when an option > is added to PRNGD to give away root privileges after initialization. Perhaps you could prevail on the OpenSSL developers to allow run-time socket selection through an environment variable or similar? > 3) If RAND_egd() is available, using it in entropy.c instead of forking > ssh-rand-helper is an obvious and unobtrusive optimization--literally > one line of code ("if (!RAND_status()) RAND_egd(PRNGD_SOCKET)"), with > an #ifdef around it. I would not be suggesting this might be done in > entropy.c if it were not so utterly trivial. I'd prefer to keep entropy.c as minimal as possible - I certainly don't want it depending on compile-time configured paths or ports. One of the aims of splitting out ssh-rand-helper was to remove these from the core code. In any case, a fork+exec+socket+connect+read+write+exit is hardly an overhead to worry about. > > RAND_egd doesn't support fetching from a localhost socket either, at > > least not in my version of OpenSSL. > > (I believe I mentioned that, actually.) (sorry - I just skimmed your message in the brief time between breakfast and work) > I'm still interested in opinions about my original question, which was > whether changing ssh-rand-helper to be able to support at build time > both PRNGD and stir_from_commands() etc. simultaneously would be > welcome. I am considering that, and if you look at the recent revisions to ssh-rand-helper.c you'll see that the code has been restructured to make this a more simple change. But I _really_ don't like the command hashing business and would much rather see it go in favor of an properly maintained (by someone else!) Yarrow implementation. -d From bbense at networking.stanford.edu Wed Jan 23 12:22:25 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Tue, 22 Jan 2002 17:22:25 -0800 (PST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <200201230042.g0N0gu3I026655@cvs.openbsd.org> Message-ID: On Tue, 22 Jan 2002, Theo de Raadt wrote: > You have no idea how wrong you are. - In what way am I wrong? > You want us ot #ifdef openssh? - I don't see why you would need to do that other than a simple 3 line include for the backward compatible include files. The function signatures aren't changing just their names. > We will not. Instead, we will make it workwith one openssl version on. > For now, we willl choose the old, and not move to the new for ... lemme see.. > shall I say 4 years? > > -That's entirely your choice. If you want to stick with openssl.0.9.6c for the next 4 years, then go for it. This however is entirely the attitude that causes open source to fail, you are only considering what's best for your particular app and not thinking about the larger community. - OpenSSL is doing something that is far from their best interest, but is in the interest of the larger community. I highly applaud them for being courageous enough to take this action. - Booker C. Bense From djm at mindrot.org Wed Jan 23 12:44:43 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Jan 2002 12:44:43 +1100 (EST) Subject: ssh-rand-helper In-Reply-To: <02Jan22.203220edt.453154-5649@jane.cs.toronto.edu> Message-ID: On Tue, 22 Jan 2002, Dan Astoorian wrote: > > I am considering that, and if you look at the recent revisions to > > ssh-rand-helper.c you'll see that the code has been restructured to make > > this a more simple change. > > I only saw two mentions of ssh-rand-helper.c in the portable ChangeLog > (your introduction of it on 12/22/2001 and Kevin's __progname change > three days later), so I don't know what you mean by "recent revisions," > sorry. I just saw that, as of yesterday's snapshot, about 7/8ths of > ssh-rand-helper.c is within the USE_PRNGD #ifdef-#else-#endif. There may be some time skew between the late Australian evenings that I commited the changes and the early Canadian mornings that the snapshots are built. If you use anonCVS, then you should see all the changes. > > But I _really_ don't like the command hashing > > business and would much rather see it go in favor of an properly > > maintained (by someone else!) Yarrow implementation. > > Unfortunately, I don't currently have that kind of time and > cryptographic expertise to throw at the problem, or I'd offer to do > that. > > I'm not familiar with Yarrow, and don't understand how any algorithm > could generate entropy without some genuine source of randomness to > start from. Isn't Yarrow just another PRNG, which still needs to be > seeded with entropy from somewhere? You are quite correct - Yarrow is just a system to maintain a cryptographic random number source. Some people have used it to build things like the command hashing part of ssh-rand-helper. The main attraction is that it is purpose built and maintained by someone else. -d From dan at doxpara.com Wed Jan 23 12:58:11 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 22 Jan 2002 17:58:11 -0800 Subject: ssh-rand-helper References: Message-ID: <05cb01c1a3b1$69c45d20$1701000a@effugas> > You are quite correct - Yarrow is just a system to maintain a > cryptographic random number source. Some people have used it to build > things like the command hashing part of ssh-rand-helper. The main > attraction is that it is purpose built and maintained by someone else. "The generation of random numbers is far too important to be left to chance." --Dan From dan at doxpara.com Wed Jan 23 12:58:11 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 22 Jan 2002 17:58:11 -0800 Subject: ssh-rand-helper References: Message-ID: <05cc01c1a3b1$6b14aae0$1701000a@effugas> > You are quite correct - Yarrow is just a system to maintain a > cryptographic random number source. Some people have used it to build > things like the command hashing part of ssh-rand-helper. The main > attraction is that it is purpose built and maintained by someone else. "The generation of random numbers is far too important to be left to chance." --Dan From bbense at networking.stanford.edu Wed Jan 23 13:12:15 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Tue, 22 Jan 2002 18:12:15 -0800 (PST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <1011733268.21550.28.camel@mothra> Message-ID: On 23 Jan 2002, Damien Miller wrote: > On Wed, 2002-01-23 at 03:27, Booker C. Bense wrote: > > > - The api hasn't changed that much, a simple query-replace > > with /des_/DES_/ should fix the src code tree once and for > > all. > > That won't work - we have to support currently deployed OpenSSL's as > well as the newest versions. > - It will with this include file. #ifdef OPENSSL_OLD_VERSION #define DES_set_key des_set_key #define DES_key_sched des_key_sched #define DES_ncbc_encrypt des_ncbc_encrypt #define DES_ede3_cbc_encrypt des_ede3_cbc_encrypt #define DES_cblock des_cblock #endif - I think people are making this into a bigger problem than it is. Yes it requires that openssl apps do a bit more work, but it isn't that much and it makes some things possible that just weren't before this change. - Booker C. Bense From bugzilla-daemon at mindrot.org Wed Jan 23 15:10:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 15:10:16 +1100 (EST) Subject: [Bug 75] New: Error compiling in ssh-agent.c Message-ID: <20020123041016.24694EA0C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 Summary: Error compiling in ssh-agent.c Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: adrian at afsthumper.com I am compiling with all the defaults, using the latest versions of ZLIB and OpenSSL. I am also using GNU Make, GCC, and all the other standards. Nothing out of the ordinary. After compiling quite a bit of code, it fails with the following error: gcc -g -02 -Wall -Wpointer-arith -Wno- uninitialized -I. -I. -I/usr/local/ssl/inlclude -DETCDIR=\"/usr/local/etc\" - D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" - D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" - D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" - D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c ssh-agent.c ssh-agent.c:1018: macro 'atexit' used with just one arg make: *** [ssh-agent.o] Error 1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Wed Jan 23 15:52:03 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 22 Jan 2002 22:52:03 -0600 (CST) Subject: AIX reading /etc/environment out of step. In-Reply-To: <20020122232814.C15723@greenie.muc.de> Message-ID: On Tue, 22 Jan 2002, Gert Doering wrote: > Hi, > > On Tue, Jan 22, 2002 at 12:09:13PM -0600, mouring at etoh.eviladmin.org wrote: > > I was discussing with Don about a private topic..and while skimming the > > code I noticed that during a 'ssh mouring at site ls' the /etc/environment > > is *ONLY* read if the remote machine is an AIX box. This is undocumented > > and I'm wondering if someone using AIX could explain WHY it exists in the > > session.c:do_child()? No other OS has this. I don't see why AIX should > > require it. > > All other ways to log into AIX read this. So by doing it you're easing > switchover from rlogin/whatever to ssh. > Still don't like the idea. You sure it is required in this location and should not be somewhere else? Like for interactive sessions only? Remember this is include for all subsystems. - Ben From jg at jguk.org Wed Jan 23 16:35:38 2002 From: jg at jguk.org (J. Grant) Date: Wed, 23 Jan 2002 14:35:38 +0900 Subject: Using OpenSSH through a SOCKS compatible firewall on your LAN References: <3C4D458B.5010404@jguk.org> Message-ID: <3C4E4BAA.5060305@jguk.org> Hello, Incase I have missed some replies I thought I should mention I am not on these lists, please email me directly if you have any comment to make. JG From bugzilla-daemon at mindrot.org Wed Jan 23 17:16:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 17:16:09 +1100 (EST) Subject: [Bug 75] Error compiling in ssh-agent.c Message-ID: <20020123061609.97D98E906@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From djm at mindrot.org 2002-01-23 17:16 ------- AFAIK atexit() should only take one arg. It looks like configure might not be finding your libc atexit() and is using the compat macro in defines.h. What does configure report when it looks for atexit()? Ben, the compat macro looks wrong too. It is currently defined as: # define atexit(a, NULL) on_exit(a, NULL) shouldn't it be: # define atexit(a) on_exit(a, NULL) ?? ------- 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 Jan 23 17:25:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 17:25:06 +1100 (EST) Subject: [Bug 73] sftp segfaults on an attempt to up/download a nonexistent file Message-ID: <20020123062506.A38E8EA1F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=73 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-23 17:25 ------- Resolution: FreeBSD's glob function doesn't support GLOB_NOMATCH (which AFAIK is a POSIX requirement). FreeBSD will patch their shipped version of sftp for the upcoming release and will implement GLOB_NOMATCH in future. The URL attached to this bug includes the patch they intend to apply (it also contains a GLOB_NOMATCH 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 Wed Jan 23 17:26:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 17:26:55 +1100 (EST) Subject: [Bug 72] sshd 3.0.2p1 assumes authorized_keys2 unless configured otherwise. Message-ID: <20020123062655.6E031EA22@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=72 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-23 17:26 ------- I can attest that 3.0.2p2 does check authorized_keys first. In the absence of any further information, I am closing. ------- 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 Jan 23 17:28:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 17:28:45 +1100 (EST) Subject: [Bug 70] Allow 'authorize host' questions to be able to be answered via GUI app Message-ID: <20020123062845.7DB84EA27@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=70 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2002-01-23 17:28 ------- Markus committed support for this a couple of days back and I merged it into portable last night. Open a seperate bugs if there are any issues with 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 Jan 23 17:37:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 23 Jan 2002 17:37:28 +1100 (EST) Subject: [Bug 52] ssh hangs on exit Message-ID: <20020123063728.CAB65EA29@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=52 ------- Additional Comments From djm at mindrot.org 2002-01-23 17:37 ------- This is a known issue and has been discussed extensively on the mailings list. There is difference of opinion as to whether this is a bug or whether it is correct behaviour. A good description of the issue comes from a text file in Redhat's source RPM: ------------------------------------ About the hang-on-exit bug: this is the TODO item which shows up when you run "ssh server 'sleep 20 & exit'". Feel free to add the text directly to TODO (I didn't, but only because it's a lot of detail that might not belong). * The shell starts up, and starts its own session. As a side-effect, it gets its own process group. * The child forks off sleep, and because it's in the background, puts it into its own process group. The sleep command inherits a copy of the shell's descriptor for the tty as its stdout. * The shell exits, but doesn't SIGHUP all of its child PIDs like it probably should. * The sshd server attempts to read from the master side of the pty, and while there are still process with the pty open, no EOF is produced. * The sleep command exits, closes its descriptor, sshd detects the EOF, and the connection gets closed. Attempts at fixing this in sshd, and why they don't work: * SIGHUP the sshd's process group. - The shell is in its own process group. * Track process group IDs of all children before we reap them (via an extra field in Session structures which holds the pgid for each child pid), and SIGHUP the pgid when we reap. - Background commands are in yet another process group. * Close the connection when the child dies. - Background commands may need to write data to the connection. Also prematurely truncates output from some commands (scp server, the famous "dd if=/dev/zero bs=1000 count=100" case). Known-good workarounds: * bash: shopt huponexit on * tcsh: none * zsh: setopt HUP (usually the default setting) (taken from email from Jason Stone to openssh-unix-dev, 5 May 2001) * pdksh: ? This appears to affect rsh as well: it behaves the same with 'sleep 20 & exit'. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Wed Jan 23 17:34:41 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 00:34:41 -0600 (CST) Subject: [Bug 75] Error compiling in ssh-agent.c (fwd) Message-ID: Ermmm.. bugzilla does not like return emails.=) ---------- Forwarded message ---------- Date: Wed, 23 Jan 2002 00:25:05 -0600 (CST) From: mouring at etoh.eviladmin.org To: bugzilla-daemon at mindrot.org Subject: Re: [Bug 75] Error compiling in ssh-agent.c > ------- Additional Comments From djm at mindrot.org 2002-01-23 17:16 ------- > AFAIK atexit() should only take one arg. It looks like configure might not be > finding your libc atexit() and is using the compat macro in defines.h. What does > configure report when it looks for atexit()? > > Ben, the compat macro looks wrong too. It is currently defined as: > > # define atexit(a, NULL) on_exit(a, NULL) > > shouldn't it be: > > # define atexit(a) on_exit(a, NULL) > Ermm.. Why did I change that: -# define atexit(a) on_exit(a, NULL) +# define atexit(a, NULL) on_exit(a, NULL) Hmm..only Hints I see is I was doing SonyOS merging at that time. I'll revert out.. and if breaks SonyOS then we will handle it as a special case for them. - Ben From tori at ringstrom.mine.nu Wed Jan 23 18:31:45 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Wed, 23 Jan 2002 08:31:45 +0100 (CET) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DFCC3.31C67F3D@hp.com> Message-ID: On Tue, 22 Jan 2002, Rick Jones wrote: > > * Nagle should be turned off for X11 sessions. > > > > * Nagle could be either on or off for pure shell sessions. (taste) > > > > * Nagle can be off for sftp, since it is well behaved, and does not > > generate unneccesary tinygrams. Probably true for all (future) > > subsystems as well. The current problem we have with nagle and sftp > > can either be solved by letting nagle merge our two tinygrams, or by > > merging them in the ssh code. I'd prefer adding buffering to ssh to > > merge them in the application. Marcus? > > "Conservative in what you send" would seem to suggest that assuming that > future subsystems are well-behaved is not a given :) If a future subsystems would misbehave, you would be able to see that by the fact that it generates a lot of tinygrams. The most generic solution would of course be to have the possibility to add a nodelay flag to the subsystem line in the sshd config file. > Also, what does an ASCII mode transfer sftp session look like? Is it > still nice large sends, or is is a series of oneliners? There is no ASCII mode as in normal FTP, and directory listings are handled with opendir and readdir messages. The openssh server currently sends readdir data for 100 files at a time which should avoid tinygrams. /Tobias From j.petersen at msh.de Wed Jan 23 20:22:27 2002 From: j.petersen at msh.de (=?ISO-8859-1?Q?=22Petersen=2C_J=F6rg=22?=) Date: Wed, 23 Jan 2002 10:22:27 +0100 Subject: AIX reading /etc/environment out of step. Message-ID: /etc/environment on AIX is the place to put environment variables for all processes... (independent of shell!) The current code does what an AIX-admin would expect. J?rg Petersen -----Original Message----- .... > All other ways to log into AIX read this. So by doing it you're easing > switchover from rlogin/whatever to ssh. > Still don't like the idea. You sure it is required in this location and should not be somewhere else? Like for interactive sessions only? Remember this is include for all subsystems. ... From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jan 23 21:16:57 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 23 Jan 2002 11:16:57 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <1011694809.24031.2.camel@mothra> References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> <20020122002449.GA9458@serv01.aet.tu-cottbus.de> <20020122083657.GA21612@faui02> <20020122085503.GC15906@serv01.aet.tu-cottbus.de> <20020122091641.GA16010@faui02> <1011694809.24031.2.camel@mothra> Message-ID: <20020123101657.GA20829@serv01.aet.tu-cottbus.de> On Tue, Jan 22, 2002 at 09:20:09PM +1100, Damien Miller wrote: > On Tue, 2002-01-22 at 20:16, Markus Friedl wrote: > > > But why break binary compatibility for 99% of the > > users if 1% have problems with linking? > > > > Why not provide an 'option' for for these 1%, > > that allows then to use the new API, e.g > > #define OPENSSL_NEW_DES_API > > #include > > Or at least a way to enable the old API: > > #define OPENSSL_OLD_DES_API > #include > > We don't have the luxury of only supporting the most recent OpenSSL > release and we don't want to pollute our code with #ifdef's everywhere. Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: The old interface is now working again by default, as long as OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should be changed to the DES_* interface in the long run, as the old interface will go away at some point in the future. (Please note, that 0.9.7 providing the new interface is not even out...) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From mike.bristow at thus.net Wed Jan 23 22:12:27 2002 From: mike.bristow at thus.net (Mike Bristow) Date: Wed, 23 Jan 2002 11:12:27 +0000 Subject: [PATCH] Add multiple AuthorizedKeyFiles options Message-ID: <20020123111227.A93704@lindt.urgle.com> Hi, We'd like to run sshd with a configuration morally equivilent to: # stuff ... AuthorizedKeysFile /var/db/keys-distributed-by-security-team/%u AuthorizedKeysFile %h/.ssh/authorized_keys # be backwards compatable for a bit longer yet AuthorizedKeysFile %h/.ssh/authorized_keys2 # more stuff ... The following patch (against the cvs source) turns the authorizedkeysfile statement in sshd.conf into one which populates a list of such files. I've also turned "authorizedkeysfile2" into an alias for "authorizedkeysfile" (but perhaps it out to be deprecated instead). Does this look OK to folk? If so, I'll make the approprate changes to the manual pages and re-submit (via bugzilla, the mailing list, or whatever is the Right Thing To Do). -- Mike Bristow, embonpointful, but not managerial, damnit. -------------- next part -------------- Index: auth-rsa.c =================================================================== RCS file: /cvs/openssh/auth-rsa.c,v retrieving revision 1.41 diff -u -r1.41 auth-rsa.c --- auth-rsa.c 22 Jan 2002 12:16:33 -0000 1.41 +++ auth-rsa.c 23 Jan 2002 11:11:28 -0000 @@ -58,6 +58,8 @@ * our challenge; returns zero if the client gives a wrong answer. */ +static int auth_rsa_file(struct passwd *pw, BIGNUM *client_n, char *file); + int auth_rsa_challenge_dialog(RSA *pk) { @@ -122,11 +124,33 @@ * 0 if the client could not be authenticated, and 1 if authentication was * successful. This may exit if there is a serious protocol violation. */ +int +auth_rsa(struct passwd *pw, BIGNUM *client_n) { + char *file; + int authorized = 0; + int authfileno = 0; + + /* no user given */ + if (pw == NULL) + return 0; + + /* Iterate over all authorized keys files. */ + while ( (file = authorized_keys_file(pw, authfileno++)) != NULL) { + debug("trying public RSA key file %s", file); + authorized = auth_rsa_file(pw, client_n, file); + xfree(file); + if (authorized == 1) { + return 1; + } + } + return 0; +} +/* Do the hard work in authenticating the client */ int -auth_rsa(struct passwd *pw, BIGNUM *client_n) +auth_rsa_file(struct passwd *pw, BIGNUM *client_n, char *file) { - char line[8192], *file; + char line[8192]; int authenticated; u_int bits; FILE *f; @@ -142,15 +166,10 @@ /* Temporarily use the user's uid. */ temporarily_use_uid(pw); - /* The authorized keys. */ - file = authorized_keys_file(pw); - debug("trying public RSA key file %s", file); - /* Fail quietly if file does not exist */ if (stat(file, &st) < 0) { /* Restore the privileged uid. */ restore_uid(); - xfree(file); return 0; } /* Open the file containing the authorized keys. */ @@ -160,12 +179,10 @@ restore_uid(); packet_send_debug("Could not open %.900s for reading.", file); packet_send_debug("If your home is on an NFS volume, it may need to be world-readable."); - xfree(file); return 0; } if (options.strict_modes && secure_filename(f, file, pw, line, sizeof(line)) != 0) { - xfree(file); fclose(f); log("Authentication refused: %s", line); packet_send_debug("Authentication refused: %s", line); @@ -271,7 +288,6 @@ restore_uid(); /* Close the file. */ - xfree(file); fclose(f); key_free(key); Index: auth.c =================================================================== RCS file: /cvs/openssh/auth.c,v retrieving revision 1.41 diff -u -r1.41 auth.c --- auth.c 21 Dec 2001 03:45:47 -0000 1.41 +++ auth.c 23 Jan 2002 11:11:28 -0000 @@ -296,15 +296,11 @@ } char * -authorized_keys_file(struct passwd *pw) +authorized_keys_file(struct passwd *pw, int n) { - return expand_filename(options.authorized_keys_file, pw); -} - -char * -authorized_keys_file2(struct passwd *pw) -{ - return expand_filename(options.authorized_keys_file2, pw); + if (n >= options.num_authorized_keys_files) + return NULL; + return expand_filename(options.authorized_keys_files[n], pw); } /* return ok if key exists in sysfile or userfile */ Index: auth.h =================================================================== RCS file: /cvs/openssh/auth.h,v retrieving revision 1.27 diff -u -r1.27 auth.h --- auth.h 22 Jan 2002 12:11:02 -0000 1.27 +++ auth.h 23 Jan 2002 11:11:28 -0000 @@ -139,8 +139,7 @@ struct passwd * auth_get_user(void); char *expand_filename(const char *, struct passwd *); -char *authorized_keys_file(struct passwd *); -char *authorized_keys_file2(struct passwd *); +char *authorized_keys_file(struct passwd *, int n); int secure_filename(FILE *, const char *, struct passwd *, char *, size_t); Index: auth2.c =================================================================== RCS file: /cvs/openssh/auth2.c,v retrieving revision 1.87 diff -u -r1.87 auth2.c --- auth2.c 22 Jan 2002 12:26:40 -0000 1.87 +++ auth2.c 23 Jan 2002 11:11:28 -0000 @@ -720,17 +720,15 @@ { int success; char *file; + int authfileno = 0; - file = authorized_keys_file(pw); - success = user_key_allowed2(pw, key, file); - xfree(file); - if (success) - return success; - - /* try suffix "2" for backward compat, too */ - file = authorized_keys_file2(pw); - success = user_key_allowed2(pw, key, file); - xfree(file); + /* Iterate over all authorized_keys_files */ + while ( (file = authorized_keys_file(pw, authfileno++) ) != NULL) { + success = user_key_allowed2(pw, key, file); + xfree(file); + if (success) + return success; + } return success; } Index: servconf.c =================================================================== RCS file: /cvs/openssh/servconf.c,v retrieving revision 1.74 diff -u -r1.74 servconf.c --- servconf.c 22 Jan 2002 12:35:12 -0000 1.74 +++ servconf.c 23 Jan 2002 11:11:29 -0000 @@ -107,8 +107,7 @@ options->reverse_mapping_check = -1; options->client_alive_interval = -1; options->client_alive_count_max = -1; - options->authorized_keys_file = NULL; - options->authorized_keys_file2 = NULL; + options->num_authorized_keys_files = 0; } void @@ -223,15 +222,11 @@ options->client_alive_interval = 0; if (options->client_alive_count_max == -1) options->client_alive_count_max = 3; - if (options->authorized_keys_file2 == NULL) { - /* authorized_keys_file2 falls back to authorized_keys_file */ - if (options->authorized_keys_file != NULL) - options->authorized_keys_file2 = options->authorized_keys_file; - else - options->authorized_keys_file2 = _PATH_SSH_USER_PERMITTED_KEYS2; + if (options->num_authorized_keys_files == 0) { + /* fill default authorized keys files */ + options->authorized_keys_files[options->num_authorized_keys_files++] = _PATH_SSH_USER_PERMITTED_KEYS; + options->authorized_keys_files[options->num_authorized_keys_files++] = _PATH_SSH_USER_PERMITTED_KEYS2; } - if (options->authorized_keys_file == NULL) - options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; } /* Keyword tokens. */ @@ -263,7 +258,7 @@ sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, sBanner, sReverseMappingCheck, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, - sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, + sClientAliveCountMax, sAuthorizedKeysFile, sDeprecated } ServerOpCodes; @@ -336,7 +331,7 @@ { "clientaliveinterval", sClientAliveInterval }, { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, - { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "authorizedkeysfile2", sAuthorizedKeysFile }, { NULL, sBadOption } }; @@ -834,10 +829,13 @@ * AuthorizedKeysFile /etc/ssh_keys/%u */ case sAuthorizedKeysFile: - case sAuthorizedKeysFile2: - charptr = (opcode == sAuthorizedKeysFile ) ? - &options->authorized_keys_file : - &options->authorized_keys_file2; + intptr = &options->num_authorized_keys_files; + if (*intptr >= MAX_AUTHKEYFILES) + fatal("%s line %d: too many authorized keys " + "files specified (max %d).", + filename, linenum, MAX_AUTHKEYFILES); + + charptr = &options->authorized_keys_files[*intptr]; goto parse_filename; case sClientAliveInterval: Index: servconf.h =================================================================== RCS file: /cvs/openssh/servconf.h,v retrieving revision 1.42 diff -u -r1.42 servconf.h --- servconf.h 21 Dec 2001 03:45:49 -0000 1.42 +++ servconf.h 23 Jan 2002 11:11:29 -0000 @@ -24,6 +24,7 @@ #define MAX_DENY_GROUPS 256 /* Max # groups on deny list. */ #define MAX_SUBSYSTEMS 256 /* Max # subsystems. */ #define MAX_HOSTKEYS 256 /* Max # hostkeys. */ +#define MAX_AUTHKEYFILES 256 /* Max # authorized_keys statements */ /* permit_root_login */ #define PERMIT_NOT_SET -1 @@ -126,8 +127,12 @@ * disconnect the session */ - char *authorized_keys_file; /* File containing public keys */ - char *authorized_keys_file2; + + char *authorized_keys_files[MAX_AUTHKEYFILES]; /* + * Files containing + * public keys + */ + int num_authorized_keys_files; int pam_authentication_via_kbd_int; } ServerOptions; From andreip at cs.tuiasi.ro Wed Jan 23 22:23:11 2002 From: andreip at cs.tuiasi.ro (Andrei POSTOLACHE) Date: Wed, 23 Jan 2002 13:23:11 +0200 (EET) Subject: Hi Message-ID: RedHat 7.1 #rpm -q zlib zlib-1.1.3-22 #rpm -ql zlib /usr/lib/libz.so.1 /usr/lib/libz.so.1.1.3 /usr/share/doc/zlib-1.1.3 /usr/share/doc/zlib-1.1.3/README #cd openssh-3.0.2p1 #./configure ...... checking for deflate in -lz... no configure: error: *** zlib missing - please install first or check config.log *** .... -- Dowsed in mud, soaked in bleach Andrei Postolache -- From tori at ringstrom.mine.nu Wed Jan 23 22:56:14 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Wed, 23 Jan 2002 12:56:14 +0100 (CET) Subject: Hi In-Reply-To: Message-ID: On Wed, 23 Jan 2002, Andrei POSTOLACHE wrote: > RedHat 7.1 > #rpm -q zlib > zlib-1.1.3-22 > #rpm -ql zlib > /usr/lib/libz.so.1 > /usr/lib/libz.so.1.1.3 > /usr/share/doc/zlib-1.1.3 > /usr/share/doc/zlib-1.1.3/README > > #cd openssh-3.0.2p1 > #./configure > ...... > checking for deflate in -lz... no > configure: error: *** zlib missing - please install first or check > config.log *** > .... Install the zlib-devel rpm. /Tobias From Nicolas.Williams at ubsw.com Thu Jan 24 01:26:30 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 09:26:30 -0500 Subject: Might a patch be accepted? (was Re: [PATCH] Using TCP_NODELAY unconditionally) In-Reply-To: ; from tori@ringstrom.mine.nu on Wed, Jan 23, 2002 at 08:31:45AM +0100 References: <3C4DFCC3.31C67F3D@hp.com> Message-ID: <20020123092628.S27398@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 08:31:45AM +0100, Tobias Ringstrom wrote: > On Tue, 22 Jan 2002, Rick Jones wrote: > > "Conservative in what you send" would seem to suggest that assuming that > > future subsystems are well-behaved is not a given :) > > If a future subsystems would misbehave, you would be able to see that by > the fact that it generates a lot of tinygrams. The most generic solution > would of course be to have the possibility to add a nodelay flag to the > subsystem line in the sshd config file. I may have to have such a feature, in which case I could maintain a local patch, but I would prefer if such a patch were accepted. OpenSSH Team: what sort of patch w.r.t. TCP_NODELAY handling would you be willing to accept? I might like to see client and server config file options for specifying whether X11 or other port forwarding should imply TCP_NODELAY and similar options per-subsystem as Tobias suggests as well as, possbily, a global option to override all the others. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Thu Jan 24 01:31:45 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 09:31:45 -0500 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: ; from bbense@networking.stanford.edu on Tue, Jan 22, 2002 at 06:12:15PM -0800 References: <1011733268.21550.28.camel@mothra> Message-ID: <20020123093143.T27398@sm2p1386swk.wdr.com> On Tue, Jan 22, 2002 at 06:12:15PM -0800, Booker C. Bense wrote: > On 23 Jan 2002, Damien Miller wrote: > > > On Wed, 2002-01-23 at 03:27, Booker C. Bense wrote: > > > > > - The api hasn't changed that much, a simple query-replace > > > with /des_/DES_/ should fix the src code tree once and for > > > all. > > > > That won't work - we have to support currently deployed OpenSSL's as > > well as the newest versions. > > > > - It will with this include file. > > #ifdef OPENSSL_OLD_VERSION > > #define DES_set_key des_set_key > #define DES_key_sched des_key_sched > #define DES_ncbc_encrypt des_ncbc_encrypt > #define DES_ede3_cbc_encrypt des_ede3_cbc_encrypt > #define DES_cblock des_cblock > > #endif So if the OpenSSH Team refuses to cater to this OpenSSL change or to upgrade to the new version till, say, 1.0, one could ./configure --with-cppflags="-DDES_set_key=des_set_key ..." ... or ./configure --with-cppflags="-Ddes_set_key=DES_set_key ..." ..., depending on what version of OpenSSL the OpenSSH team decides to support and what version you use. Kinda sucky, but livable. > - I think people are making this into a bigger > problem than it is. Yes it requires that openssl > apps do a bit more work, but it isn't that much > and it makes some things possible that just weren't > before this change. Yes. But not catering to this change in OpenSSL wouldn't be that bad if the above ./configure --with-cppflags=... trick works... > - Booker C. Bense Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From kouril at ics.muni.cz Thu Jan 24 01:35:40 2002 From: kouril at ics.muni.cz (Daniel Kouril) Date: Wed, 23 Jan 2002 15:35:40 +0100 Subject: Fix AFS and Kerberos interaction Message-ID: <20020123153540.A31514@odorn.ics.muni.cz> Hello, I going to use ssh with Kerberos V5 support along with support for AFS. I don't want to use Kerberos V4 or AFS token passing. The only thing I need from AFS is creating an AFS token (using appropriate function from krb5 API) after user's authentication. It seems to me that such scenario is not much supported by the current code. Rather it is assumed only Kerberos 4 will be used with AFS. Please, could you have a look at the enclosed patch? The main purpose of it is to enclose those parts dealing with AFS or KRB4 ticket passing between #ifdef AFS && KRB4 (instead of only AFS as in the current code). The patch is created against OpenSSH 3.0.2p1, tested with Heimdal implementation of Kerberos V5. Would it be possible to add the patch to the standard distribution? with best regards -- Daniel Kouril -------------- next part -------------- --- Makefile.in 2002/01/23 10:09:09 1.1 +++ Makefile.in 2002/01/23 10:10:50 @@ -50,7 +50,7 @@ SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-krb5.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out MANPAGES_IN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 --- auth-krb4.c 2002/01/23 10:50:54 1.1 +++ auth-krb4.c 2002/01/23 10:55:40 @@ -34,11 +34,12 @@ #include "uidswap.h" #include "auth.h" +#ifdef KRB4 + #ifdef AFS #include "radix.h" #endif -#ifdef KRB4 extern ServerOptions options; static int @@ -279,9 +280,7 @@ packet_write_wait(); return (1); } -#endif /* KRB4 */ -#ifdef AFS int auth_krb4_tgt(Authctxt *authctxt, const char *string) { @@ -370,4 +369,4 @@ return (1); } -#endif /* AFS */ +#endif /* KRB4 */ --- auth.h 2002/01/23 12:01:53 1.1 +++ auth.h 2002/01/23 12:14:19 @@ -102,14 +102,15 @@ int auth_krb4(Authctxt *, KTEXT, char **); int auth_krb4_password(Authctxt *, const char *); void krb4_cleanup_proc(void *); +#endif /* KRB4 */ #ifdef AFS #include +#ifdef KRB4 int auth_krb4_tgt(Authctxt *, const char *); int auth_afs_token(Authctxt *, const char *); -#endif /* AFS */ - #endif /* KRB4 */ +#endif /* AFS */ #ifdef KRB5 int auth_krb5(Authctxt *authctxt, krb5_data *auth, char **client); --- auth1.c 2002/01/23 12:15:49 1.1 +++ auth1.c 2002/01/23 12:17:26 @@ -162,11 +162,11 @@ case SSH_CMSG_HAVE_KERBEROS_TGT: packet_send_debug("Kerberos TGT passing disabled before authentication."); break; -#ifdef AFS +#if defined(AFS) && defined(KRB4) case SSH_CMSG_HAVE_AFS_TOKEN: packet_send_debug("AFS token passing disabled before authentication."); break; -#endif /* AFS */ +#endif /* AFS && KRB4 */ #endif /* AFS || KRB5 */ case SSH_CMSG_AUTH_RHOSTS: --- radix.c 2002/01/23 10:13:32 1.1 +++ radix.c 2002/01/23 10:27:36 @@ -27,7 +27,7 @@ RCSID("$OpenBSD: radix.c,v 1.16 2001/06/23 15:12:19 itojun Exp $"); -#ifdef AFS +#if defined(AFS) && defined(KRB4) #include #include @@ -211,4 +211,4 @@ return 1; } -#endif /* AFS */ +#endif /* AFS && KRB4 */ --- readconf.c 2002/01/23 12:18:23 1.1 +++ readconf.c 2002/01/23 12:23:17 @@ -102,7 +102,7 @@ #if defined(AFS) || defined(KRB5) oKerberosTgtPassing, #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) oAFSTokenPassing, #endif oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward, @@ -147,7 +147,7 @@ #if defined(AFS) || defined(KRB5) { "kerberostgtpassing", oKerberosTgtPassing }, #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) { "afstokenpassing", oAFSTokenPassing }, #endif { "fallbacktorsh", oFallBackToRsh }, @@ -368,7 +368,7 @@ intptr = &options->kerberos_tgt_passing; goto parse_flag; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) case oAFSTokenPassing: intptr = &options->afs_token_passing; goto parse_flag; @@ -757,7 +757,7 @@ #if defined(AFS) || defined(KRB5) options->kerberos_tgt_passing = -1; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) options->afs_token_passing = -1; #endif options->password_authentication = -1; @@ -839,7 +839,7 @@ if (options->kerberos_tgt_passing == -1) options->kerberos_tgt_passing = 1; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) if (options->afs_token_passing == -1) options->afs_token_passing = 1; #endif --- readconf.h 2002/01/23 12:18:23 1.1 +++ readconf.h 2002/01/23 12:23:17 @@ -47,7 +47,7 @@ #if defined(AFS) || defined(KRB5) int kerberos_tgt_passing; /* Try Kerberos TGT passing. */ #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) int afs_token_passing; /* Try AFS token passing. */ #endif int password_authentication; /* Try password --- servconf.c 2002/01/23 10:56:44 1.1 +++ servconf.c 2002/01/23 11:06:44 @@ -12,9 +12,13 @@ #include "includes.h" RCSID("$OpenBSD: servconf.c,v 1.91 2001/11/12 18:17:07 markus Exp $"); -#if defined(KRB4) || defined(KRB5) +#if defined(KRB4) #include #endif +#ifdef KRB5 +#include +#define KEYFILE "/etc/krb5.keytab" +#endif #ifdef AFS #include #endif @@ -82,7 +86,7 @@ #if defined(AFS) || defined(KRB5) options->kerberos_tgt_passing = -1; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) options->afs_token_passing = -1; #endif options->password_authentication = -1; @@ -190,7 +194,7 @@ if (options->kerberos_tgt_passing == -1) options->kerberos_tgt_passing = 0; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) if (options->afs_token_passing == -1) options->afs_token_passing = k_hasafs(); #endif @@ -246,7 +250,7 @@ #if defined(AFS) || defined(KRB5) sKerberosTgtPassing, #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) sAFSTokenPassing, #endif sChallengeResponseAuthentication, @@ -297,7 +301,7 @@ #if defined(AFS) || defined(KRB5) { "kerberostgtpassing", sKerberosTgtPassing }, #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) { "afstokenpassing", sAFSTokenPassing }, #endif { "passwordauthentication", sPasswordAuthentication }, @@ -632,7 +636,7 @@ intptr = &options->kerberos_tgt_passing; goto parse_flag; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) case sAFSTokenPassing: intptr = &options->afs_token_passing; goto parse_flag; --- servconf.h 2002/01/23 10:56:44 1.1 +++ servconf.h 2002/01/23 11:07:37 @@ -87,7 +87,7 @@ int kerberos_tgt_passing; /* If true, permit Kerberos TGT * passing. */ #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) int afs_token_passing; /* If true, permit AFS token passing. */ #endif int password_authentication; /* If true, permit password --- session.c 2002/01/23 11:08:20 1.1 +++ session.c 2002/01/23 12:12:42 @@ -343,19 +343,19 @@ verbose("Kerberos v5 TGT refused for %.100s", s->authctxt->user); #endif /* KRB5 */ } else { -#ifdef AFS +#if defined(AFS) && defined(KRB4) if (auth_krb4_tgt(s->authctxt, kdata)) success = 1; else verbose("Kerberos v4 TGT refused for %.100s", s->authctxt->user); -#endif /* AFS */ +#endif /* AFS && KRB4 */ } xfree(kdata); } break; #endif /* AFS || KRB5 */ -#ifdef AFS +#if defined(AFS) && defined(KRB4) case SSH_CMSG_HAVE_AFS_TOKEN: if (!options.afs_token_passing || !k_hasafs()) { verbose("AFS token passing disabled."); @@ -372,7 +372,7 @@ xfree(token); } break; -#endif /* AFS */ +#endif /* AFS && KRB4 */ case SSH_CMSG_EXEC_SHELL: case SSH_CMSG_EXEC_CMD: @@ -1370,6 +1370,10 @@ krb_afslog(cell, 0); krb_afslog(0, 0); +#ifdef KRB5 + krb5_afslog(s->authctxt->krb5_ctx, s->authctxt->krb5_fwd_ccache, + NULL, NULL); +#endif } #endif /* AFS */ --- ssh.c 2002/01/23 12:28:10 1.1 +++ ssh.c 2002/01/23 12:30:58 @@ -159,9 +159,9 @@ _PATH_SSH_USER_CONFFILE); fprintf(stderr, " -A Enable authentication agent forwarding.\n"); fprintf(stderr, " -a Disable authentication agent forwarding (default).\n"); -#ifdef AFS +#if defined(AFS) || defined(KRB5) fprintf(stderr, " -k Disable Kerberos ticket and AFS token forwarding.\n"); -#endif /* AFS */ +#endif /* AFS || KRB5 */ fprintf(stderr, " -X Enable X11 connection forwarding.\n"); fprintf(stderr, " -x Disable X11 connection forwarding (default).\n"); fprintf(stderr, " -i file Identity for public key authentication " @@ -351,10 +351,14 @@ case 'A': options.forward_agent = 1; break; -#ifdef AFS +#if defined(AFS) && defined(KRB4) case 'k': options.kerberos_tgt_passing = 0; options.afs_token_passing = 0; + break; +#elif defined(KRB5) + case 'k': + options.kerberos_tgt_passing = 0; break; #endif case 'i': --- sshconnect1.c 2002/01/23 10:28:25 1.1 +++ sshconnect1.c 2002/01/23 12:05:15 @@ -26,8 +26,10 @@ #endif #ifdef AFS #include +#ifdef KRB4 #include "radix.h" #endif +#endif #include "ssh.h" #include "ssh1.h" @@ -685,7 +687,7 @@ } #endif /* KRB5 */ -#ifdef AFS +#if defined(AFS) && defined(KRB4) static void send_krb4_tgt(void) { @@ -806,7 +808,7 @@ } } -#endif /* AFS */ +#endif /* AFS && KRB4 */ /* * Tries to authenticate with any string-based challenge/response system. @@ -1255,7 +1257,7 @@ krb5_free_context(context); #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) /* Try Kerberos v4 TGT passing if the server supports it. */ if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && options.kerberos_tgt_passing) { @@ -1270,7 +1272,7 @@ log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); send_afs_tokens(); } -#endif /* AFS */ +#endif /* AFS && KRB4 */ return; /* need statement after label */ } --- sshd.c 2002/01/23 10:41:05 1.1 +++ sshd.c 2002/01/23 12:12:42 @@ -1289,7 +1289,7 @@ if (options.kerberos_tgt_passing) auth_mask |= 1 << SSH_PASS_KERBEROS_TGT; #endif -#ifdef AFS +#if defined(AFS) && defined(KRB4) if (options.afs_token_passing) auth_mask |= 1 << SSH_PASS_AFS_TOKEN; #endif From thanus at ccf.auth.gr Thu Jan 24 01:46:43 2002 From: thanus at ccf.auth.gr (Thanos Siaperas) Date: Wed, 23 Jan 2002 16:46:43 +0200 Subject: X.509 support in ssh (revisited) Message-ID: <3C4ECCD3.9090300@ccf.auth.gr> Hi there, Forgive me for repeating a question asked about a year ago: > Hi, > > Just wondered if anyone had got the following to work or if there are any > plans to add this functionality. > > * X.509 certificate support for authentication. As used in the likes of > stunnel, mod_ssl etc for client auth. > > * Directory based (LDAP) key lookup. Either for X.509 public certs or > standard ssh public key. > > Many thanks, > > Andrew Back > Messaging & Directory Services Architect > Iomart > We are considering upgrading our ssh infrastructure, from the previous one (f-secure) to OpenSSH or ssh.com's SSH. ssh.com' SSH supports certificate authentication in their commercial version. If, though, there is at least any work in progress for implementing this to opensshd, we may tend towards it. Thanks for your attention, Thanos Siaperas Network Operation Center Aristotle University of Thessaloniki Thessaloniki, Greece From bbense at networking.stanford.edu Thu Jan 24 01:55:26 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 23 Jan 2002 06:55:26 -0800 (PST) Subject: AIX reading /etc/environment out of step. In-Reply-To: Message-ID: On Tue, 22 Jan 2002 mouring at etoh.eviladmin.org wrote: > > > On Tue, 22 Jan 2002, Gert Doering wrote: > > > Hi, > > > > On Tue, Jan 22, 2002 at 12:09:13PM -0600, mouring at etoh.eviladmin.org wrote: > > > I was discussing with Don about a private topic..and while skimming the > > > code I noticed that during a 'ssh mouring at site ls' the /etc/environment > > > is *ONLY* read if the remote machine is an AIX box. This is undocumented > > > and I'm wondering if someone using AIX could explain WHY it exists in the > > > session.c:do_child()? No other OS has this. I don't see why AIX should > > > require it. > > > > All other ways to log into AIX read this. So by doing it you're easing > > switchover from rlogin/whatever to ssh. > > > Still don't like the idea. You sure it is required in this location and > should not be somewhere else? Like for interactive sessions only? > Remember this is include for all subsystems. > - It's the AIX way. There are variables set in there that are required for interaction with the system libraries. You either have to read it or duplicate it. - Booker C. Bense From bbense at networking.stanford.edu Thu Jan 24 02:03:20 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 23 Jan 2002 07:03:20 -0800 (PST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020123101657.GA20829@serv01.aet.tu-cottbus.de> Message-ID: On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > On Tue, Jan 22, 2002 at 09:20:09PM +1100, Damien Miller wrote: > > On Tue, 2002-01-22 at 20:16, Markus Friedl wrote: > > > > > But why break binary compatibility for 99% of the > > > users if 1% have problems with linking? > > > > > > Why not provide an 'option' for for these 1%, > > > that allows then to use the new API, e.g > > > #define OPENSSL_NEW_DES_API > > > #include > > > > Or at least a way to enable the old API: > > > > #define OPENSSL_OLD_DES_API > > #include > > > > We don't have the luxury of only supporting the most recent OpenSSL > > release and we don't want to pollute our code with #ifdef's everywhere. - They don't have to, but I can't convince them of that. > > Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: > The old interface is now working again by default, as long as > OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should > be changed to the DES_* interface in the long run, as the old > interface will go away at some point in the future. > > (Please note, that 0.9.7 providing the new interface is not even out...) > - Just to confirm, the routines will be DES_foo , but you are playing cpp macro games to provide the old interface? - Booker C. Bense From bugzilla-daemon at mindrot.org Thu Jan 24 02:40:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 24 Jan 2002 02:40:33 +1100 (EST) Subject: [Bug 76] New: scp won't transfer files to or from the root under Cygwin Message-ID: <20020123154033.7F5A6E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=76 Summary: scp won't transfer files to or from the root under Cygwin Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Cygwin on NT/2k Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bradshaw at staff.crosswalk.com Scp has some path issues when transferring to or from the root file system of a windows machine (cygwin). It creates a path that begins with //, which indicates a UNC path on Windows. I sent in patches for similar issues last year. The fix is a one line change to determine if the path is "/", and not double up on the slashes. You can see a diff patch from current cvs at: http://www.networksimplicity.com/openssh/scp.c.diff ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Thu Jan 24 02:35:42 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 09:35:42 -0600 (CST) Subject: AIX reading /etc/environment out of step. In-Reply-To: Message-ID: > > > All other ways to log into AIX read this. So by doing it you're easing > > > switchover from rlogin/whatever to ssh. > > > > > Still don't like the idea. You sure it is required in this location and > > should not be somewhere else? Like for interactive sessions only? > > Remember this is include for all subsystems. > > > > - It's the AIX way. There are variables set in there that are required > for interaction with the system libraries. You either have to read it > or duplicate it. > However you do get why I don't like it. It is undocumented and is targeted to a single platform. It is normally those things that cause people to be bitten in the ass. - Ben From carson at taltos.org Thu Jan 24 02:50:01 2002 From: carson at taltos.org (Carson Gaspar) Date: Wed, 23 Jan 2002 10:50:01 -0500 Subject: AIX reading /etc/environment out of step. In-Reply-To: References: Message-ID: <6380835.1011783001@[172.25.113.221]> Solaris has something vaguely similar - /etc/default/login. Does PAM take care of this for us, or does OpenSSH just ignore it? -- Carson From donald at demag.rwth-aachen.de Thu Jan 24 02:51:07 2002 From: donald at demag.rwth-aachen.de (Donald van de Weyer) Date: Wed, 23 Jan 2002 15:51:07 GMT Subject: X.509 support in ssh (revisited) In-Reply-To: <3C4ECCD3.9090300@ccf.auth.gr> References: <3C4ECCD3.9090300@ccf.auth.gr> Message-ID: <20020123155107.21250.qmail@itchy.demag.rwth-aachen.de> Hi, I found this a while ago, but didn't have time to look into it. If you do so maybe you could share your experience ... In case the mentioned FTP site is down, drop me a mail and I'll send you the tarball I grabbed. Donald ---- I found reference to this on the IPSEC mailing list. I think you might find it useful. Look at ftp://hplose.hpl.hp.com/pub/nd Alex (Yo, Emacs, this is -*- text -*-) OpenSSH X.509 Extensions Neil Dunbar (nd at hplb.hpl.hp.com) January 25th, 2000 1. Introduction One of the problems with SSH in the larger scale is that key management becomes quite tricky, as people forget all the accounts that they have authority to use, and (in an organisation), they leave without telling the infrastructure staff which keys they had generated. Add to this that SSH leaves the generation and transport of private and public keys up to the end user, and the problem can get quite gruesome. To this end, I adapted some of the code which I wrote for the FreeS/WAN project to serve as an interface between SSH and a PKI. Note that to use these extensions, you will need OpenSSL 0.9.4+ and NOT SSLeay. The code requires use of the X509v3 extensions, and won't compile without it. Note: the actual SSH protocol is untouched. Only the key handling and verification functions have been extended. 2. Configuration To configure the extensions, add the text '--with-x509' to the ./configure line which you would normally use to configure the OpenSSH code. If you want to be able to look up certificates via LDAP, you need to add '--with-ldap=PATH' to the configure arguments. At the moment, the code will understand both OpenLDAP and Netscape LDAP SDK 3.0 (although it doesn't use SSL, for the moment). Thus, assuming that you have the Netscape SDK in /usr/local/ns-ldap, the configure line might look like the following - ./configure --prefix=/usr --with-dante --with-x509 \ --with-ldap=/usr/local/ns-ldap (If you've got OpenLDAP, installed in a sane location like /usr/lib or /usr/local/lib, then you can generally omit the pathname for LDAP). After that, compilation and installation should follow by the normal OpenSSH commands. 3. Usage The OpenSSH code has been modified such that, in addition to reading keys from public key files and SSH private key files, it can read public keys from X.509 certificate files in PEM format, and private keys either from OpenSSL RSA files, or better still, from PKCS-8 files (which are defined by reasonably well adhered to standards). Thus, to generate a key, you can use the sequence of commands as follows - openssl req -new -newkey rsa:1024 -nodes -keyout mykey.pem \ -out myreq.pem [ Followed by requests for the name on the certificate, country, etc...] openssl pkcs8 -topk8 -in myreq.pem -out mykey.pk8 (*) [ Followed by request for the encryption passphrase... ] rm -f mykey.pem [ A secure wipe would be preferable to rm -f ...] (*) if you were generating a host key or unencrypted client key, you can add the options '-nocrypt' to this stage. Be sure that you really want an unencrypted key file. And that's it. Now, once you have your certificate, either signed by your friendly neighbourhood CA, or self-signed, you should concatenate the public key certificate to your private key. cat mycert.pem >> mykey.pk8 This assumes that your certificate is in PEM format. If it's in DER format, convert it first via - openssl x509 -inform DER -in mycert.der -outform PEM \ -out mycert.pem OK. Why do we have to do this step? Answer: because SSH stores its private/public keypairs as the encrypted private key concatenated to the unencrypted public key, and loads the public key from the private key file prior to asking for a passphrase. In a PKCS-8 (or RSA private key) file, all of the information is encrypted, so that the public key cannot be loaded from the keyfile without a passphrase. Thus, as a workaround, we concatenate the (unencrypted) certificate to the end of the (encrypted) private key, and everything works well. etc.... ---- URL: http://www-unix.gridforum.org/mail_archive/security-wg/msg00050.html From markus at openbsd.org Thu Jan 24 02:58:06 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 16:58:06 +0100 Subject: AIX reading /etc/environment out of step. In-Reply-To: <6380835.1011783001@[172.25.113.221]> References: <6380835.1011783001@[172.25.113.221]> Message-ID: <20020123155805.GB5255@faui02> On Wed, Jan 23, 2002 at 10:50:01AM -0500, Carson Gaspar wrote: > Solaris has something vaguely similar - /etc/default/login. Does PAM take > care of this for us, or does OpenSSH just ignore it? /etc/default/login is not only a list of environment variables. From david-bronder at uiowa.edu Thu Jan 24 03:00:49 2002 From: david-bronder at uiowa.edu (David Bronder) Date: Wed, 23 Jan 2002 10:00:49 -0600 (CST) Subject: [openssh-unix-dev] Re: AIX reading /etc/environment out of step. In-Reply-To: from "mouring@etoh.eviladmin.org" at Jan 23, 2002 09:35:42 AM Message-ID: <200201231600.g0NG0nn64264@fire.its.uiowa.edu> mouring at etoh.eviladmin.org wrote: > > [...snipping stuff re: /etc/environment for AIX...] > > > > - It's the AIX way. There are variables set in there that are required > > for interaction with the system libraries. You either have to read it > > or duplicate it. > > > > However you do get why I don't like it. It is undocumented and is > targeted to a single platform. > > It is normally those things that cause people to be bitten in the ass. > So document it. Other AIX-isms aren't really documented either. Things like authenticate(), loginsuccess() and loginfailed() calls. Should you get rid of those too, and just stop supporting AIX? =Dave (using an extreme to illustrate a point) -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From mouring at etoh.eviladmin.org Thu Jan 24 03:14:42 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 10:14:42 -0600 (CST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123155107.21250.qmail@itchy.demag.rwth-aachen.de> Message-ID: As far as I'm aware of there is no such thing as --with-x509 for OpenSSH unless that article was suppose to come with a patch to OpenSSH. - Ben On Wed, 23 Jan 2002, Donald van de Weyer wrote: > Hi, > > I found this a while ago, but didn't have time to look into it. If you do so > maybe you could share your experience ... > > In case the mentioned FTP site is down, drop me a mail and I'll send you the > tarball I grabbed. > > Donald > > ---- > I found reference to this on the IPSEC mailing list. I think > you might find it useful. Look at > ftp://hplose.hpl.hp.com/pub/nd > > Alex > > (Yo, Emacs, this is -*- text -*-) > OpenSSH X.509 Extensions > > Neil Dunbar (nd at hplb.hpl.hp.com) > January 25th, 2000 > > 1. Introduction > > One of the problems with SSH in the larger scale is that key > management becomes quite tricky, as people forget all the accounts > that they have authority to use, and (in an organisation), they leave > without telling the infrastructure staff which keys they had > generated. Add to this that SSH leaves the generation and transport of > private and public keys up to the end user, and the problem can get > quite gruesome. > > To this end, I adapted some of the code which I wrote for the > FreeS/WAN project to serve as an interface between SSH and a PKI. Note > that to use these extensions, you will need OpenSSL 0.9.4+ and NOT > SSLeay. The code requires use of the X509v3 extensions, and won't > compile without it. Note: the actual SSH protocol is untouched. Only > the key handling and verification functions have been extended. > > 2. Configuration > > To configure the extensions, add the text '--with-x509' to the > ./configure line which you would normally use to configure the OpenSSH > code. > > If you want to be able to look up certificates via LDAP, you need to > add '--with-ldap=PATH' to the configure arguments. At the moment, the > code will understand both OpenLDAP and Netscape LDAP SDK 3.0 (although > it doesn't use SSL, for the moment). Thus, assuming that you have the > Netscape SDK in /usr/local/ns-ldap, the configure line might look like > the following - > > ./configure --prefix=/usr --with-dante --with-x509 \ > --with-ldap=/usr/local/ns-ldap > > (If you've got OpenLDAP, installed in a sane location like /usr/lib or > /usr/local/lib, then you can generally omit the pathname for LDAP). > > After that, compilation and installation should follow by the normal > OpenSSH commands. > > 3. Usage > > The OpenSSH code has been modified such that, in addition to reading > keys from public key files and SSH private key files, it can read > public keys from X.509 certificate files in PEM format, and private > keys either from OpenSSL RSA files, or better still, from PKCS-8 files > (which are defined by reasonably well adhered to standards). > > Thus, to generate a key, you can use the sequence of commands as > follows - > > openssl req -new -newkey rsa:1024 -nodes -keyout mykey.pem \ > -out myreq.pem > [ Followed by requests for the name on the certificate, > country, etc...] > openssl pkcs8 -topk8 -in myreq.pem -out mykey.pk8 (*) > [ Followed by request for the encryption passphrase... ] > rm -f mykey.pem > [ A secure wipe would be preferable to rm -f ...] > > (*) if you were generating a host key or unencrypted client key, you > can add the options '-nocrypt' to this stage. Be sure that you really > want an unencrypted key file. > > And that's it. Now, once you have your certificate, either signed by > your friendly neighbourhood CA, or self-signed, you should concatenate > the public key certificate to your private key. > > cat mycert.pem >> mykey.pk8 > > This assumes that your certificate is in PEM format. If it's in DER > format, convert it first via - > > openssl x509 -inform DER -in mycert.der -outform PEM \ > -out mycert.pem > > OK. Why do we have to do this step? Answer: because SSH stores its > private/public keypairs as the encrypted private key concatenated to > the unencrypted public key, and loads the public key from the private > key file prior to asking for a passphrase. In a PKCS-8 (or RSA private > key) file, all of the information is encrypted, so that the public key > cannot be loaded from the keyfile without a passphrase. Thus, as a > workaround, we concatenate the (unencrypted) certificate to the end of > the (encrypted) private key, and everything works well. > > etc.... > > ---- > URL: http://www-unix.gridforum.org/mail_archive/security-wg/msg00050.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com > For additional commands, e-mail: secureshell-help at securityfocus.com > > From sperber at informatik.uni-tuebingen.de Thu Jan 24 03:24:04 2002 From: sperber at informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: Wed, 23 Jan 2002 17:24:04 +0100 Subject: OpenSSH w/ kth-krb4 on AIX Message-ID: Hi, I'm suffering from a memory corruption problem when compiling OpenSSH 3.0.2p1 with kth-krb4 1.1 on AIX 4.3.2 and 4.3.3. The symptom is that the file name gets zeroed out during ssh key generation, for example during "make install": Generating public/private rsa1 key pair. open failed: No such file or directory. ^ filename normally goes here When I remove krb4 from the install, things work. (For the record, this is against zlib 1.1.1 and OpenSSL 0.9.6c.) Has anyone by any chance seen this problem? I've done a little bit of gdb on this, but so far have been unsuccessful at extracting any useful info. Direct email replies would be much appreciated. -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From donald at demag.rwth-aachen.de Thu Jan 24 03:30:56 2002 From: donald at demag.rwth-aachen.de (Donald van de Weyer) Date: Wed, 23 Jan 2002 16:30:56 GMT Subject: X.509 support in ssh (revisited) In-Reply-To: References: Message-ID: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> mouring at etoh.eviladmin.org writes: > As far as I'm aware of there is no such thing as --with-x509 for OpenSSH > unless that article was suppose to come with a patch to OpenSSH. I would suppose that is what is in that 400K tarball. I didn't look however ... From Nicolas.Williams at ubsw.com Thu Jan 24 03:30:09 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 11:30:09 -0500 Subject: AIX reading /etc/environment out of step. In-Reply-To: <20020123155805.GB5255@faui02>; from markus@openbsd.org on Wed, Jan 23, 2002 at 04:58:06PM +0100 References: <6380835.1011783001@[172.25.113.221]> <20020123155805.GB5255@faui02> Message-ID: <20020123113008.U27398@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 04:58:06PM +0100, Markus Friedl wrote: > On Wed, Jan 23, 2002 at 10:50:01AM -0500, Carson Gaspar wrote: > > Solaris has something vaguely similar - /etc/default/login. Does PAM take > > care of this for us, or does OpenSSH just ignore it? > > /etc/default/login is not only a list of environment variables. And some PAM module ought to implement support for it so that things like OpenSSH don't have to. But, alas, there is no PAM module that implements /etc/default/login. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Thu Jan 24 03:31:38 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 10:31:38 -0600 (CST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> Message-ID: On Wed, 23 Jan 2002, Donald van de Weyer wrote: > mouring at etoh.eviladmin.org writes: > > > As far as I'm aware of there is no such thing as --with-x509 for OpenSSH > > unless that article was suppose to come with a patch to OpenSSH. > > I would suppose that is what is in that 400K tarball. I didn't look however > ... > Wow..I hope that is the whole OpenSSH source in that tarball. Because that is larger than OpenSSH 3.0.2p1 portable code compressed! Does X.509 really make sense with SSH? I mean you are still not going to get Verisigned licenses and even that you are putting your trust in a 3rd party certificate which has no real bearing on the trust of the machine in question. - Ben From markus at openbsd.org Thu Jan 24 03:42:46 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 17:42:46 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> Message-ID: <20020123164246.GD5255@faui02> On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > Does X.509 really make sense with SSH? I mean you are still not going to > get Verisigned licenses and even that you are putting your trust in a 3rd > party certificate which has no real bearing on the trust of the machine in > question. well it could make hostkey management simpler, but i see no difference between people clicking on "continue, i don't care about this hostkey" and "continue, i don't care about the certificate for this hostkey" -m From gert at greenie.muc.de Thu Jan 24 03:43:35 2002 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 23 Jan 2002 17:43:35 +0100 Subject: AIX reading /etc/environment out of step. In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 09:35:42AM -0600 References: Message-ID: <20020123174335.A7823@greenie.muc.de> Hi, On Wed, Jan 23, 2002 at 09:35:42AM -0600, mouring at etoh.eviladmin.org wrote: > > - It's the AIX way. There are variables set in there that are required > > for interaction with the system libraries. You either have to read it > > or duplicate it. > > However you do get why I don't like it. It is undocumented and is > targeted to a single platform. So let's document it? :-) As for "single platform" - well, other platforms don't do it that way, so if we start doing it, it might also lead to nasty surprises. 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 gator at cacr.caltech.edu Thu Jan 24 03:45:49 2002 From: gator at cacr.caltech.edu (Anne Carasik) Date: Wed, 23 Jan 2002 08:45:49 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <3C4ECCD3.9090300@ccf.auth.gr>; from thanus@ccf.auth.gr on Wed, Jan 23, 2002 at 04:46:43PM +0200 References: <3C4ECCD3.9090300@ccf.auth.gr> Message-ID: <20020123084549.A15319@swamp.cacr.caltech.edu> On Wed, Jan 23, 2002 at 04:46:43PM +0200, Thanos Siaperas wrote: [deletia] > * X.509 certificate support for authentication. As used in the likes of > stunnel, mod_ssl etc for client auth. > > * Directory based (LDAP) key lookup. Either for X.509 public certs or > standard ssh public key. [deletia] > We are considering upgrading our ssh infrastructure, from the previous > one (f-secure) > to OpenSSH or ssh.com's SSH. > ssh.com' SSH supports certificate authentication in their commercial > version. Ok, right. With the many certificate vendors out there, I'd find out who exactly they do support. Last time I checked, X.509 support was only for SSH own CA (Certifier). Last I heard (and it's been a while), OpenSSH is supposed to have some spki support, but I'm not sure when it's going to be implemented. -Anne -- .-"".__."``". Anne Carasik, sysadmin, gator at cacr.caltech.edu .-.--. _...' (/) (/) ``' Don't insult the alligator till after you (O/ O) \-' ` -="""=. ', cross the river. -unknown ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020123/590b5452/attachment.bin From mouring at etoh.eviladmin.org Thu Jan 24 03:48:02 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 10:48:02 -0600 (CST) Subject: AIX reading /etc/environment out of step. In-Reply-To: <20020123174335.A7823@greenie.muc.de> Message-ID: On Wed, 23 Jan 2002, Gert Doering wrote: > Hi, > > On Wed, Jan 23, 2002 at 09:35:42AM -0600, mouring at etoh.eviladmin.org wrote: > > > - It's the AIX way. There are variables set in there that are required > > > for interaction with the system libraries. You either have to read it > > > or duplicate it. > > > > However you do get why I don't like it. It is undocumented and is > > targeted to a single platform. > > So let's document it? :-) > > As for "single platform" - well, other platforms don't do it that way, > so if we start doing it, it might also lead to nasty surprises. > Issue with documentation.. 1) Who will maintain all the diferences in the manpages? 2) Why would someone running Linux/Redhat care about an AIX 'feature'? Same goes for people in AIX..Why do they care about PAM since they don't use it. One would almost have to have a manpage per OS. Which would be impratical to maintain. My main intent is for some known who understand AIX well enough to ensure the code is in the right place. It stuck out like a bike with a bent front wheel while skimming that part of the code whiling discussing about 'clean untampered environments' (mainly because the manpage makes a point to define what is read on establishing a ssh shell). On the same note.. I assume AIX has it's own krb4. Otherwise the nice krb4 variables set in do_child() will be overwritten a few lines down. - Ben From markus at openbsd.org Thu Jan 24 03:53:59 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 17:53:59 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123084549.A15319@swamp.cacr.caltech.edu> References: <3C4ECCD3.9090300@ccf.auth.gr> <20020123084549.A15319@swamp.cacr.caltech.edu> Message-ID: <20020123165359.GI5255@faui02> On Wed, Jan 23, 2002 at 08:45:49AM -0800, Anne Carasik wrote: > Last I heard (and it's been a while), OpenSSH is supposed to have some > spki support, but I'm not sure when it's going to be implemented. who said this? is there anyone working on patches? i think lsh has some spki thingy. From Nicolas.Williams at ubsw.com Thu Jan 24 04:04:36 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 12:04:36 -0500 Subject: X.509 support in ssh (revisited) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 10:31:38AM -0600 References: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> Message-ID: <20020123120434.W27398@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > > On Wed, 23 Jan 2002, Donald van de Weyer wrote: > > > mouring at etoh.eviladmin.org writes: > > > > > As far as I'm aware of there is no such thing as --with-x509 for OpenSSH > > > unless that article was suppose to come with a patch to OpenSSH. > > > > I would suppose that is what is in that 400K tarball. I didn't look however > > ... > > > Wow..I hope that is the whole OpenSSH source in that tarball. Because > that is larger than OpenSSH 3.0.2p1 portable code compressed! The tarball's not there to be found... > Does X.509 really make sense with SSH? I mean you are still not going to > get Verisigned licenses and even that you are putting your trust in a 3rd > party certificate which has no real bearing on the trust of the machine in > question. X.509, like GSS-API w/ Kerberos or GSI, solve the problem of known host key distribution. Also, I have a patch to OpenSSH 3.0.2p1 that allows the use of names in authorized_keys entries, krb4, krb5 and GSI names, and with X.509 support, if OpenSSH had it, certificate names. This functionality is more general than the traditional .klogin and .k5login authorization checks and it solves the problem of having to update authorized_keys whenever you re-key. So I can have auth_keys entries like: ssh-named:krb5 myusername at MYREALM ssh-named:krb5 myusername/admin at MYREALM And: ssh-name-pat:krb5 */superroot at MYREALM > - Ben Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From peterw at usa.net Thu Jan 24 04:09:26 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 12:09:26 -0500 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123164246.GD5255@faui02>; from markus@openbsd.org on Wed, Jan 23, 2002 at 05:42:46PM +0100 References: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> <20020123164246.GD5255@faui02> Message-ID: <20020123120926.C22786@usa.net> On Wed, Jan 23, 2002 at 05:42:46PM +0100, Markus Friedl wrote: > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > Does X.509 really make sense with SSH? I mean you are still not going to > > get Verisigned licenses and even that you are putting your trust in a 3rd > > party certificate which has no real bearing on the trust of the machine in > > question. A 3rd party CA can at least give the user confidence that the server is owned by the folks who own the domain name, and that is a *LOT* better than the current behavior. Some sort of CA/cert setup definitely makes sense, IMO. > well it could make hostkey management simpler, but i see > no difference between people clicking on > "continue, i don't care about this hostkey" > and > "continue, i don't care about the certificate for this hostkey" Many of us get OpenSSH from the companies and organizations that build our operating environments (Sun, Red Hat, Debian, etc.). These entities could distribute OpenSSH clients that behave like https Web browsers -- include a set of known/trusted CA keys, and make ssh_config such that users must do something extra to accept an unsigned key, an expired cert, or a cert from an untrusted CA -- much like Web browsers do. Orgaizations could set up their own CA's and CRLs, and would only need to distribute the CA cert with the client setups -- an easy, one-time setup. Much more manageable than distributing N host keys to M known hosts files, and updating those M files. -Peter -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From Darren.Moffat at Sun.COM Thu Jan 24 04:15:01 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Wed, 23 Jan 2002 09:15:01 -0800 Subject: AIX reading /etc/environment out of step. References: <6380835.1011783001@[172.25.113.221]> <20020123155805.GB5255@faui02> Message-ID: <3C4EEF95.6090100@Sun.COM> On 01/23/02 07:58, Markus Friedl wrote: > On Wed, Jan 23, 2002 at 10:50:01AM -0500, Carson Gaspar wrote: > >>Solaris has something vaguely similar - /etc/default/login. Does PAM take >>care of this for us, or does OpenSSH just ignore it? >> > > /etc/default/login is not only a list of environment variables. I'd drop the only from that statement to make it 100% correct. /etc/default/login is a set of key value pairs joined by an equals sign, tradition dictates that the keys have been written in uppercase this makes them look like environment variables. /etc/default/login is intended to be read by login(1). sshd has some overlap with some of its own options in sshd_config, reading both will lead to confusion about which takes precedence and the sometimes very subtle difference in meaning of the options and the actions that result. It would be simpler to have sshd read sshd_config as nice as it might appear to have it pickup stuff from /etc/default/login it leads to confusion. To further complicate matters I believe there are other systems that have an /etc/default/login file but the key/value pairs in it are different to those found in Solaris. -- Darren J Moffat From edgy at us.ibm.com Thu Jan 24 04:22:44 2002 From: edgy at us.ibm.com (Edward Geraghty) Date: Wed, 23 Jan 2002 12:22:44 -0500 Subject: AIX reading /etc/environment out of step. Message-ID: Actually AIX allready has limited PAM support in AIX v5.1. This is part of the Linux/AIX integration work. Version 5.2 will have fully supported PAM libraries. My guess is they are building supported modules for DCE/AFS etc. before it is officially released/supported. AIX is moving the way of Linux so after many years these differences should dissapear. They might keep stuff around for backwards compatibility :( EdGy @mindrot.org on 01/23/2002 11:48:02 Sent by: openssh-unix-dev-admin at mindrot.org To: Gert Doering cc: "Booker C. Bense" , Subject: Re: AIX reading /etc/environment out of step. On Wed, 23 Jan 2002, Gert Doering wrote: > Hi, > > On Wed, Jan 23, 2002 at 09:35:42AM -0600, mouring at etoh.eviladmin.org wrote: > > > - It's the AIX way. There are variables set in there that are required > > > for interaction with the system libraries. You either have to read it > > > or duplicate it. > > > > However you do get why I don't like it. It is undocumented and is > > targeted to a single platform. > > So let's document it? :-) > > As for "single platform" - well, other platforms don't do it that way, > so if we start doing it, it might also lead to nasty surprises. > Issue with documentation.. 1) Who will maintain all the diferences in the manpages? 2) Why would someone running Linux/Redhat care about an AIX 'feature'? Same goes for people in AIX..Why do they care about PAM since they don't use it. One would almost have to have a manpage per OS. Which would be impratical to maintain. My main intent is for some known who understand AIX well enough to ensure the code is in the right place. It stuck out like a bike with a bent front wheel while skimming that part of the code whiling discussing about 'clean untampered environments' (mainly because the manpage makes a point to define what is read on establishing a ssh shell). On the same note.. I assume AIX has it's own krb4. Otherwise the nice krb4 variables set in do_child() will be overwritten a few lines down. - Ben _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From ed at UDel.Edu Thu Jan 24 04:57:24 2002 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 23 Jan 2002 12:57:24 -0500 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123164246.GD5255@faui02> Message-ID: On Wed, 23 Jan 2002, Markus Friedl wrote: > Date: Wed, 23 Jan 2002 17:42:46 +0100 > From: Markus Friedl > To: mouring at etoh.eviladmin.org > Cc: Donald van de Weyer , > Thanos Siaperas , openssh-unix-dev at mindrot.org, > secureshell at securityfocus.com > Subject: Re: X.509 support in ssh (revisited) > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > Does X.509 really make sense with SSH? I mean you are still not going to > > get Verisigned licenses and even that you are putting your trust in a 3rd > > party certificate which has no real bearing on the trust of the machine in > > question. > > well it could make hostkey management simpler, but i see > no difference between people clicking on > "continue, i don't care about this hostkey" Okay... maybe someone has upgrade OpenSSH on the system and generated a new hostkey. How can you tell? > and > "continue, i don't care about the certificate for this hostkey" The kicker is that if you manage the systems, you shouldn't see this message because the client will know which CA(s) your client should trust in on certs for sshd servers you want to connect to. If you see this message when certs are in play, then something is likely wrong. I would think that the benefit here is that if your client is configured to trust only certain signers, then Joe Hacker can't play man-in-the-middle during the "should I accept this hostkey" question, because Joe Hacker shouldn't have the private key for the CA you trust. Isn't that an improvement? I could envision that when generating a hostkey, you take extra steps to sign it with your CA key, then you install OpenSSH with an extra file containing a list of trusted signers. Maybe I'm extrapolating too much on the features implemented in the original "--with-x509" feature that was posted? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Thu Jan 24 05:03:35 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 12:03:35 -0600 (CST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123120926.C22786@usa.net> Message-ID: On Wed, 23 Jan 2002, Peter Watkins wrote: > On Wed, Jan 23, 2002 at 05:42:46PM +0100, Markus Friedl wrote: > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > Does X.509 really make sense with SSH? I mean you are still not going to > > > get Verisigned licenses and even that you are putting your trust in a 3rd > > > party certificate which has no real bearing on the trust of the machine in > > > question. > > A 3rd party CA can at least give the user confidence that the server is > owned by the folks who own the domain name, and that is a *LOT* better than > the current behavior. Some sort of CA/cert setup definitely makes sense, IMO. > > > well it could make hostkey management simpler, but i see > > no difference between people clicking on > > "continue, i don't care about this hostkey" > > and > > "continue, i don't care about the certificate for this hostkey" > > Many of us get OpenSSH from the companies and organizations that build our > operating environments (Sun, Red Hat, Debian, etc.). These entities could > distribute OpenSSH clients that behave like https Web browsers -- include > a set of known/trusted CA keys, and make ssh_config such that users must > do something extra to accept an unsigned key, an expired cert, or a cert > from an untrusted CA -- much like Web browsers do. Orgaizations could set up > their own CA's and CRLs, and would only need to distribute the CA cert with > the client setups -- an easy, one-time setup. Much more manageable than > distributing N host keys to M known hosts files, and updating those M files. > What an utter joke. CAs give you warm fuzzy feelings. Not much more. Just because some CAs 'claims' to have signed a key does not mean much (Refer to the forged signatures of Microsoft due to a stupid Versign employee that happened last year). This has been heavily discussed in alot of security groups. It was a very hot topic when Microsoft did not include a lot of the smaller CAs vendors that appeared and people started complaining about being prompted for such verifications when they dished out money for a 'trusted CA'. As I said.. from a trust view.. it is a total and utter joke. - Ben From Nicolas.Williams at ubsw.com Thu Jan 24 05:09:00 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 13:09:00 -0500 Subject: AIX reading /etc/environment out of step. In-Reply-To: <3C4EEF95.6090100@Sun.COM>; from Darren.Moffat@Sun.COM on Wed, Jan 23, 2002 at 09:15:01AM -0800 References: <6380835.1011783001@[172.25.113.221]> <20020123155805.GB5255@faui02> <3C4EEF95.6090100@Sun.COM> Message-ID: <20020123130858.X27398@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 09:15:01AM -0800, Darren J Moffat wrote: > > > On 01/23/02 07:58, Markus Friedl wrote: > > > On Wed, Jan 23, 2002 at 10:50:01AM -0500, Carson Gaspar wrote: > > > >>Solaris has something vaguely similar - /etc/default/login. Does PAM take > >>care of this for us, or does OpenSSH just ignore it? > >> > > > > /etc/default/login is not only a list of environment variables. > > > I'd drop the only from that statement to make it 100% correct. That would be wrong. Though the contents of /etc/default/login looks like environment variable settings, the semantics of the variables listed in there are not so simple. [...] > -- > Darren J Moffat Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Thu Jan 24 05:07:28 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 12:07:28 -0600 (CST) Subject: X.509 support in ssh (revisited) In-Reply-To: Message-ID: On Wed, 23 Jan 2002, Ed Phillips wrote: > On Wed, 23 Jan 2002, Markus Friedl wrote: > > > Date: Wed, 23 Jan 2002 17:42:46 +0100 > > From: Markus Friedl > > To: mouring at etoh.eviladmin.org > > Cc: Donald van de Weyer , > > Thanos Siaperas , openssh-unix-dev at mindrot.org, > > secureshell at securityfocus.com > > Subject: Re: X.509 support in ssh (revisited) > > > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > Does X.509 really make sense with SSH? I mean you are still not going to > > > get Verisigned licenses and even that you are putting your trust in a 3rd > > > party certificate which has no real bearing on the trust of the machine in > > > question. > > > > well it could make hostkey management simpler, but i see > > no difference between people clicking on > > "continue, i don't care about this hostkey" > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > new hostkey. How can you tell? > > > and > > "continue, i don't care about the certificate for this hostkey" > > The kicker is that if you manage the systems, you shouldn't see this > message because the client will know which CA(s) your client should trust > in on certs for sshd servers you want to connect to. If you see this > message when certs are in play, then something is likely wrong. > > I would think that the benefit here is that if your client is configured > to trust only certain signers, then Joe Hacker can't play > man-in-the-middle during the "should I accept this hostkey" question, > because Joe Hacker shouldn't have the private key for the CA you trust. > > Isn't that an improvement? > Until your CA's employees do something brain dead like hand out a copy of your key to someone who 'claims' to be an employee of your company. Refer to Micorosft and Versign issue last year which caused MS to resign a ton of packages and revoke a very heavily used key. Think warm fuzzy thoughts that your CA is trustworthy. =) - Ben From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jan 24 05:20:44 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 23 Jan 2002 19:20:44 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: References: <20020123101657.GA20829@serv01.aet.tu-cottbus.de> Message-ID: <20020123182044.GB698@serv01.aet.tu-cottbus.de> On Wed, Jan 23, 2002 at 07:03:20AM -0800, Booker C. Bense wrote: > On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > > Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: > > The old interface is now working again by default, as long as > > OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should > > be changed to the DES_* interface in the long run, as the old > > interface will go away at some point in the future. > > > > (Please note, that 0.9.7 providing the new interface is not even out...) > > > > - Just to confirm, the routines will be DES_foo , but you are playing > cpp macro games to provide the old interface? No cpp macro games but real functions just calling the new functions. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From gator at cacr.caltech.edu Thu Jan 24 05:21:39 2002 From: gator at cacr.caltech.edu (Anne Carasik) Date: Wed, 23 Jan 2002 10:21:39 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123165359.GI5255@faui02>; from markus@openbsd.org on Wed, Jan 23, 2002 at 05:53:59PM +0100 References: <3C4ECCD3.9090300@ccf.auth.gr> <20020123084549.A15319@swamp.cacr.caltech.edu> <20020123165359.GI5255@faui02> Message-ID: <20020123102139.C15319@swamp.cacr.caltech.edu> Hi Markus, I don't remember who said this, as this was a while back. All I remember is the PKI thingy, and everyone was trying to do something with it. From a sysadmin standpoint, I'd like to be able to manage user keys with PKI. You can probably do that with PAM, right? -Anne On Wed, Jan 23, 2002 at 05:53:59PM +0100, Markus Friedl wrote: > On Wed, Jan 23, 2002 at 08:45:49AM -0800, Anne Carasik wrote: > > Last I heard (and it's been a while), OpenSSH is supposed to have some > > spki support, but I'm not sure when it's going to be implemented. > > who said this? is there anyone working on patches? > i think lsh has some spki thingy. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com > For additional commands, e-mail: secureshell-help at securityfocus.com > -- .-"".__."``". Anne Carasik, sysadmin, gator at cacr.caltech.edu .-.--. _...' (/) (/) ``' Don't insult the alligator till after you (O/ O) \-' ` -="""=. ', cross the river. -unknown ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020123/914986f7/attachment.bin From peterw at usa.net Thu Jan 24 05:21:25 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 13:21:25 -0500 Subject: X.509 support in ssh (revisited) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 12:03:35PM -0600 References: <20020123120926.C22786@usa.net> Message-ID: <20020123132125.D22786@usa.net> On Wed, Jan 23, 2002 at 12:03:35PM -0600, mouring at etoh.eviladmin.org wrote: > On Wed, 23 Jan 2002, Peter Watkins wrote: > > A 3rd party CA can at least give the user confidence that the server is > > owned by the folks who own the domain name, and that is a *LOT* better than > > the current behavior. Some sort of CA/cert setup definitely makes sense, IMO. > > Orgaizations could set up > > their own CA's and CRLs, and would only need to distribute the CA cert with > > the client setups -- an easy, one-time setup. Much more manageable than > > distributing N host keys to M known hosts files, and updating those M files. > What an utter joke. CAs give you warm fuzzy feelings. Not much more. Without CAs, Internet commerce (business-to-consumer) simply could not happen. That's not a joke, it's reality. Do certs solve all problems? No. Are they perfect? No. Are they better than the current status quo? Many of us believe they would be. While you might not choose to use a cert, and might (arguably very reasonably) *never* want the official OpenSSH package, even "portable", to include any "trusted" CA certs, I think adding cert support would be appreciated by many of the rest of us. No joke. > As I said.. from a trust view.. it is a total and utter joke. I'd argue the current system of key "management" is an utter joke. Comparing OpenSSH to https is like comparing /etc/hosts to DNS. From a trust view, DNS is a joke, right? Now raise your hand if you want to go back to the days of distributing and managing local host lookup tables. -Peter -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From kevin at tgivan.com Thu Jan 24 05:25:05 2002 From: kevin at tgivan.com (kevin at tgivan.com) Date: Wed, 23 Jan 2002 10:25:05 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> Message-ID: <20020123182504.GA21528@tgivan.com> Moin mouring! mouring at etoh.eviladmin.org schrieb am Mittwoch, den 23. Januar 2002: > Does X.509 really make sense with SSH? I mean you are still not > going to get Verisigned licenses and even that you are putting your > trust in a 3rd party certificate which has no real bearing on the > trust of the machine in question. I think X.509 is very good thing when managing a large environment where you have thousands of hosts running SSH and one main key management system. Getting a signed cert from Verisign might be a good thing for some, yet if you a large domain with thousands of hosts (company/clients) and you manage your own CA, you can have a relatively reliable key-management system tied with X.509 bases authentication. My 0.2 cents Rgds, -- Kevin Sindhu Systems Engineer TGI Technologies Inc. 107 E 3rd Avenue Tel: (604) 872-6676 Ext 321 Vancouver V5T 1C7 Fax: (604) 872-6601 British Columbia, Canada From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jan 24 05:31:41 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 23 Jan 2002 19:31:41 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: Message-ID: <20020123183141.GD698@serv01.aet.tu-cottbus.de> On Wed, Jan 23, 2002 at 12:07:28PM -0600, mouring at etoh.eviladmin.org wrote: > > I would think that the benefit here is that if your client is configured > > to trust only certain signers, then Joe Hacker can't play > > man-in-the-middle during the "should I accept this hostkey" question, > > because Joe Hacker shouldn't have the private key for the CA you trust. > > > > Isn't that an improvement? > > > > Until your CA's employees do something brain dead like hand out a copy of > your key to someone who 'claims' to be an employee of your company. > > Refer to Micorosft and Versign issue last year which caused MS to resign a > ton of packages and revoke a very heavily used key. > > Think warm fuzzy thoughts that your CA is trustworthy. =) Hmm. Of course it finally comes down to the CA. And I don't think it makes sense to add the large commercial CAs (actually, is there anybody left beyond Verisign anyway?) by default. But it would my life easier just being my own CA, signing for the hosts I have. By now I distribute my public keys with rdist (via SSH of course :-), but this doesn't work with lots of our Linux-machines which are not available all day long (switched off, booted into Windows) and is only nice with the 24x7 machines. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From ed at UDel.Edu Thu Jan 24 05:32:01 2002 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 23 Jan 2002 13:32:01 -0500 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: Message-ID: On Wed, 23 Jan 2002 mouring at etoh.eviladmin.org wrote: > Date: Wed, 23 Jan 2002 12:07:28 -0600 (CST) > From: mouring at etoh.eviladmin.org > To: Ed Phillips > Cc: openssh-unix-dev at mindrot.org, secureshell at securityfocus.com > Subject: Re: X.509 support in ssh (revisited) > > > > On Wed, 23 Jan 2002, Ed Phillips wrote: > > > On Wed, 23 Jan 2002, Markus Friedl wrote: > > > > > Date: Wed, 23 Jan 2002 17:42:46 +0100 > > > From: Markus Friedl > > > To: mouring at etoh.eviladmin.org > > > Cc: Donald van de Weyer , > > > Thanos Siaperas , openssh-unix-dev at mindrot.org, > > > secureshell at securityfocus.com > > > Subject: Re: X.509 support in ssh (revisited) > > > > > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > > Does X.509 really make sense with SSH? I mean you are still not going to > > > > get Verisigned licenses and even that you are putting your trust in a 3rd > > > > party certificate which has no real bearing on the trust of the machine in > > > > question. > > > > > > well it could make hostkey management simpler, but i see > > > no difference between people clicking on > > > "continue, i don't care about this hostkey" > > > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > > new hostkey. How can you tell? > > > > > and > > > "continue, i don't care about the certificate for this hostkey" > > > > The kicker is that if you manage the systems, you shouldn't see this > > message because the client will know which CA(s) your client should trust > > in on certs for sshd servers you want to connect to. If you see this > > message when certs are in play, then something is likely wrong. > > > > I would think that the benefit here is that if your client is configured > > to trust only certain signers, then Joe Hacker can't play > > man-in-the-middle during the "should I accept this hostkey" question, > > because Joe Hacker shouldn't have the private key for the CA you trust. > > > > Isn't that an improvement? > > > > Until your CA's employees do something brain dead like hand out a copy of > your key to someone who 'claims' to be an employee of your company. I wasn't the one talking about a CA "service" like Thawte or Verisign - I was talking about a home-brew CA used just to sign OpenSSH hostkeys and verify them so that it can all be automated. I only need to protect the home-brew-CA private key. That is workable in my environment, and the reward seems worth the effort. Anyone else think it would be worth it? > Refer to Micorosft and Versign issue last year which caused MS to resign a > ton of packages and revoke a very heavily used key. If you trust them, then you're in for a world of hurt in these situations. > Think warm fuzzy thoughts that your CA is trustworthy. =) Yes... it's nice isn't it? ;-P Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Thu Jan 24 05:38:53 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 19:38:53 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123164246.GD5255@faui02> Message-ID: <20020123183853.GA21895@faui02> On Wed, Jan 23, 2002 at 12:57:24PM -0500, Ed Phillips wrote: > On Wed, 23 Jan 2002, Markus Friedl wrote: > > > Date: Wed, 23 Jan 2002 17:42:46 +0100 > > From: Markus Friedl > > To: mouring at etoh.eviladmin.org > > Cc: Donald van de Weyer , > > Thanos Siaperas , openssh-unix-dev at mindrot.org, > > secureshell at securityfocus.com > > Subject: Re: X.509 support in ssh (revisited) > > > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > Does X.509 really make sense with SSH? I mean you are still not going to > > > get Verisigned licenses and even that you are putting your trust in a 3rd > > > party certificate which has no real bearing on the trust of the machine in > > > question. > > > > well it could make hostkey management simpler, but i see > > no difference between people clicking on > > "continue, i don't care about this hostkey" > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > new hostkey. How can you tell? > > > and > > "continue, i don't care about the certificate for this hostkey" > > The kicker is that if you manage the systems, you shouldn't see this > message because the client will know which CA(s) your client should trust i know, but this is not how i see how people use https, for example. -m From markus at openbsd.org Thu Jan 24 05:39:54 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 19:39:54 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123164246.GD5255@faui02> Message-ID: <20020123183954.GB21895@faui02> On Wed, Jan 23, 2002 at 12:57:24PM -0500, Ed Phillips wrote: > Okay... maybe someone has upgrade OpenSSH on the system and generated a > new hostkey. How can you tell? well, there is no need to generate a new hostkey after an upgrade of ssh. not even after an upgrade of the system. -m From Nicolas.Williams at ubsw.com Thu Jan 24 05:37:54 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 13:37:54 -0500 Subject: X.509 support in ssh (revisited) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 12:03:35PM -0600 References: <20020123120926.C22786@usa.net> Message-ID: <20020123133752.Y27398@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 12:03:35PM -0600, mouring at etoh.eviladmin.org wrote: > What an utter joke. CAs give you warm fuzzy feelings. Not much more. > Just because some CAs 'claims' to have signed a key does not mean much > (Refer to the forged signatures of Microsoft due to a stupid Versign > employee that happened last year). It is not a joke when you control the CA and use this in an intranet. In such a situation it's no more a joke than is Kerberos. Key distribution is always the problem to solve in cryptography. > This has been heavily discussed in alot of security groups. It was a very > hot topic when Microsoft did not include a lot of the smaller CAs vendors > that appeared and people started complaining about being prompted for such > verifications when they dished out money for a 'trusted CA'. > > As I said.. from a trust view.. it is a total and utter joke. You have to know who you trust. Do you trust the piece of paper called a driver's license or passport or whatever that someone might present to you during a transaction to prove that they are who they say they are? Do you trust the issuer of that piece of paper? Ultimately you make an estimate of the trustworthiness of such things - this is why the local dept. or motor vehicles requires several id documents from different origins to accept your identity. In an intranet, I trust the CA. > - Ben Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Thu Jan 24 05:40:26 2002 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 23 Jan 2002 13:40:26 -0500 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123183853.GA21895@faui02> Message-ID: On Wed, 23 Jan 2002, Markus Friedl wrote: > Date: Wed, 23 Jan 2002 19:38:53 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: mouring at etoh.eviladmin.org, > Donald van de Weyer , > Thanos Siaperas , openssh-unix-dev at mindrot.org, > secureshell at securityfocus.com > Subject: Re: X.509 support in ssh (revisited) > > On Wed, Jan 23, 2002 at 12:57:24PM -0500, Ed Phillips wrote: > > On Wed, 23 Jan 2002, Markus Friedl wrote: > > > > > Date: Wed, 23 Jan 2002 17:42:46 +0100 > > > From: Markus Friedl > > > To: mouring at etoh.eviladmin.org > > > Cc: Donald van de Weyer , > > > Thanos Siaperas , openssh-unix-dev at mindrot.org, > > > secureshell at securityfocus.com > > > Subject: Re: X.509 support in ssh (revisited) > > > > > > On Wed, Jan 23, 2002 at 10:31:38AM -0600, mouring at etoh.eviladmin.org wrote: > > > > Does X.509 really make sense with SSH? I mean you are still not going to > > > > get Verisigned licenses and even that you are putting your trust in a 3rd > > > > party certificate which has no real bearing on the trust of the machine in > > > > question. > > > > > > well it could make hostkey management simpler, but i see > > > no difference between people clicking on > > > "continue, i don't care about this hostkey" > > > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > > new hostkey. How can you tell? > > > > > and > > > "continue, i don't care about the certificate for this hostkey" > > > > The kicker is that if you manage the systems, you shouldn't see this > > message because the client will know which CA(s) your client should trust > > i know, but this is not how i see how people use https, for example. Hehehe... I agree. In our environment, we'd make the client refuse to connect under these circumstances. ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From steph at ssh.com Thu Jan 24 05:51:18 2002 From: steph at ssh.com (Stephanie Thomas) Date: Wed, 23 Jan 2002 10:51:18 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123084549.A15319@swamp.cacr.caltech.edu> Message-ID: Actually, Thanos, the certificate support in SSH Secure Shell is not just for SSH Certifier - we've done interop testing with several CA vendors. And most CAs are supported through the importing of DER encoded binary X.509 (.CER) or Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B) certificates (see RSA guide below for example of this). SSH Secure Shell has even been certified (please excuse the pun ;) to work with RSA Keon: http://www.rsasecurity.com/support/guides/keonca_pdfs/SSH_Secure_Shell_KCA.p df You can perform certificate testing using SSH Certifier at this site: http://www.ssh.com/tech/pki/ And you can find information about supported hardware tokens here: http://www.ssh.com/products/ssh/interoperability.cfm If you have specific questions about SSH Secure Shell and PKI and are evaluating, please submit your questions using our Support Request Form here: http://www.ssh.com/support/ssh/pre-sales_support.cfm Cheers, Steph **************************** Stephanie Thomas SSH Secure Shell SSH Communications Security Technical Support Specialist GIAC Certified Unix Security Administrator **************************** -----Original Message----- From: Anne Carasik [mailto:gator at cacr.caltech.edu] Sent: Wednesday, January 23, 2002 8:46 AM To: Thanos Siaperas Cc: openssh-unix-dev at mindrot.org; secureshell at securityfocus.com Subject: Re: X.509 support in ssh (revisited) On Wed, Jan 23, 2002 at 04:46:43PM +0200, Thanos Siaperas wrote: [deletia] > * X.509 certificate support for authentication. As used in the likes of > stunnel, mod_ssl etc for client auth. > > * Directory based (LDAP) key lookup. Either for X.509 public certs or > standard ssh public key. [deletia] > We are considering upgrading our ssh infrastructure, from the previous > one (f-secure) > to OpenSSH or ssh.com's SSH. > ssh.com' SSH supports certificate authentication in their commercial > version. Ok, right. With the many certificate vendors out there, I'd find out who exactly they do support. Last time I checked, X.509 support was only for SSH own CA (Certifier). Last I heard (and it's been a while), OpenSSH is supposed to have some spki support, but I'm not sure when it's going to be implemented. -Anne -- .-"".__."``". Anne Carasik, sysadmin, gator at cacr.caltech.edu .-.--. _...' (/) (/) ``' Don't insult the alligator till after you (O/ O) \-' ` -="""=. ', cross the river. -unknown ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ --------------------------------------------------------------------- To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com For additional commands, e-mail: secureshell-help at securityfocus.com From Nicolas.Williams at ubsw.com Thu Jan 24 05:39:51 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 23 Jan 2002 13:39:51 -0500 Subject: AIX reading /etc/environment out of step. In-Reply-To: <3C4F022E.B15D9B64@Sun.COM>; from Darren.Moffat@Sun.COM on Wed, Jan 23, 2002 at 10:34:22AM -0800 References: <6380835.1011783001@[172.25.113.221]> <20020123155805.GB5255@faui02> <3C4EEF95.6090100@Sun.COM> <20020123130858.X27398@sm2p1386swk.wdr.com> <3C4F022E.B15D9B64@Sun.COM> Message-ID: <20020123133950.B27171@sm2p1386swk.wdr.com> On Wed, Jan 23, 2002 at 10:34:22AM -0800, Darren J Moffat wrote: > Nicolas Williams wrote: > > > > > /etc/default/login is not only a list of environment variables. > > > > > > > > > I'd drop the only from that statement to make it 100% correct. > > > > That would be wrong. Though the contents of /etc/default/login looks > > like environment variable settings, the semantics of the variables > > listed in there are not so simple. > > Isn't that what I just said and further clarified in the rest of my message ? > > dropping the only makes the sentance: > > /etc/default/login is not a list of environment variables. Oy! I mis-parsed. My apologies. > -- > Darren J Moffat > > Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From sxw at dcs.ed.ac.uk Thu Jan 24 05:44:45 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Wed, 23 Jan 2002 18:44:45 +0000 (GMT) Subject: X.509 support in ssh (revisited) In-Reply-To: Message-ID: On Wed, 23 Jan 2002 mouring at etoh.eviladmin.org wrote: > Until your CA's employees do something brain dead like hand out a copy of > your key to someone who 'claims' to be an employee of your company. > > Refer to Micorosft and Versign issue last year which caused MS to resign a > ton of packages and revoke a very heavily used key. > > Think warm fuzzy thoughts that your CA is trustworthy. =) If you run your own CA, these thoughts can be a little less fuzzy. I think many of the posters are missing the point. For large institutions which have ssh deployed on every host, managing a central known hosts file is a real pain. Failures or delays in managing that file which result in "key changed" warnings lead to users just skipping those warnings, and an obvious degradation in security. For the intranet model there are three solutions to this 1) Use ssh with GSSAPI to remove the need for host keys 2) Use a secure service such as LDAP to distribute host keys 3) Use a key signing infrastructure to sign your host keys Using X.509 signatures doesn't mean giving control to a central Verisign-a-like CA - you can just use your local CA. For organisations which have already deployed some form of trust infrastructure, having ssh fit into that existing system is a big win. Cheers, Simon. From gator at cacr.caltech.edu Thu Jan 24 05:49:19 2002 From: gator at cacr.caltech.edu (Anne Carasik) Date: Wed, 23 Jan 2002 10:49:19 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: ; from ed@UDel.Edu on Wed, Jan 23, 2002 at 01:32:01PM -0500 References: Message-ID: <20020123104919.A15783@swamp.cacr.caltech.edu> On Wed, Jan 23, 2002 at 01:32:01PM -0500, Ed Phillips wrote: > I wasn't the one talking about a CA "service" like Thawte or Verisign - I > was talking about a home-brew CA used just to sign OpenSSH hostkeys and > verify them so that it can all be automated. I only need to protect the > home-brew-CA private key. That is workable in my environment, and the > reward seems worth the effort. Anyone else think it would be worth it? I think so. Having all your hostkeys signed by a central authority (like an OpenSSL generated key) should be fine. There's no reason you have to pay a Certificate Authority to do it. You could do something like GnuPG and sign all the keys by a single key (treating it like a CA), if OpenSSH can have a hook to use GnuPG keys. > > Refer to Micorosft and Versign issue last year which caused MS to resign a > > ton of packages and revoke a very heavily used key. > If you trust them, then you're in for a world of hurt in these situations. No kidding. I'd prefer to run my own CA and sign the keys that way. As a university employee, we look for solutions that are very cost-effective (especially if they don't cost anything :). That's what OpenSSL is for. You can make your own certs. :) > > Think warm fuzzy thoughts that your CA is trustworthy. =) > Yes... it's nice isn't it? ;-P *shiver* -Anne -- .-"".__."``". Anne Carasik, sysadmin, gator at cacr.caltech.edu .-.--. _...' (/) (/) ``' Don't insult the alligator till after you (O/ O) \-' ` -="""=. ', cross the river. -unknown ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020123/5c8c50aa/attachment.bin From peterw at usa.net Thu Jan 24 05:49:37 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 13:49:37 -0500 Subject: X.509 support in ssh via PAM? In-Reply-To: <20020123102139.C15319@swamp.cacr.caltech.edu>; from gator@cacr.caltech.edu on Wed, Jan 23, 2002 at 10:21:39AM -0800 References: <3C4ECCD3.9090300@ccf.auth.gr> <20020123084549.A15319@swamp.cacr.caltech.edu> <20020123165359.GI5255@faui02> <20020123102139.C15319@swamp.cacr.caltech.edu> Message-ID: <20020123134937.F22786@usa.net> On Wed, Jan 23, 2002 at 10:21:39AM -0800, Anne Carasik wrote: > I don't remember who said this, as this was a while back. All I remember > is the PKI thingy, and everyone was trying to do something with it. > > From a sysadmin standpoint, I'd like to be able to manage user keys with > PKI. > > You can probably do that with PAM, right? Maybe halfway, if that, right? Most of us, I'd wager, are more concerned about managing/certifying host keys, so a client knows[0] the sshd is legit, that there's no MITM attack going on. And all the PAM hooks right now are in the sshd code, so PAM wouldn't come into play here. Is PAM usable, or appropriate, for use on the *client* side, for verifying the key presented by the sshd? PAM could be useful for the other way around. If the sshd were told to treat "sshpeer.example.com" as a trusted host, then sshd would need a way of verifying the key presented by the client. Clearly PAM might work there, if such a PAM module were to exist. But since OpenSSH already uses OpenSSL, wouldn't it make more sense just to leverage the OpenSSL code instead? -Peter [0] not Ben's client, but those of us who might enable PKI :-) -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From ed at UDel.Edu Thu Jan 24 05:52:54 2002 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 23 Jan 2002 13:52:54 -0500 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123183954.GB21895@faui02> Message-ID: On Wed, 23 Jan 2002, Markus Friedl wrote: > Date: Wed, 23 Jan 2002 19:39:54 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: mouring at etoh.eviladmin.org, > Donald van de Weyer , > Thanos Siaperas , openssh-unix-dev at mindrot.org, > secureshell at securityfocus.com > Subject: Re: X.509 support in ssh (revisited) > > On Wed, Jan 23, 2002 at 12:57:24PM -0500, Ed Phillips wrote: > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > > new hostkey. How can you tell? > > well, there is no need to generate a new hostkey after an upgrade > of ssh. not even after an upgrade of the system. I know... but likely, the system disk died, or the OS was installed from scratch because the machine was hacked, replaced, is new, etc. Plus, it's good to change your keys from time to time to keep the hackers guessing (esp. in a firewall-free site like ours). In our environment, we need to be able to generate a new host key on a "whim"... but we'd also like to have some level of confidence that we were the ones who generated it, in a way that is more "automated" than the hand-verify of the fingerprint (how to you protect the fingerprints anyway?). That's why I suggested to somehow leverage LDAP+SSL in the ssh client to verify hostkeys instead of relying on ~/.ssh/known_hosts in 30000+ user's insecure-NFS-mounted home directories (which got shot down in flames). Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Thu Jan 24 05:56:08 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 19:56:08 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123183954.GB21895@faui02> References: <20020123164246.GD5255@faui02> <20020123183954.GB21895@faui02> Message-ID: <20020123185608.GA22106@faui02> On Wed, Jan 23, 2002 at 07:39:54PM +0100, Markus Friedl wrote: > [bla bla bla] ok, enough talk, we all know about this. let's switch from talk-mode to patch-mode, there is already enough traffic on this list. From donald at demag.rwth-aachen.de Thu Jan 24 06:07:31 2002 From: donald at demag.rwth-aachen.de (Donald van de Weyer) Date: Wed, 23 Jan 2002 19:07:31 GMT Subject: X.509 support in ssh (revisited) In-Reply-To: References: Message-ID: <20020123190731.389.qmail@itchy.demag.rwth-aachen.de> Hi, everyone who's interested can grab the tarball at: http://users.demag.rwth-aachen.de/donald/download/openssh-1.2.2-x509.txt http://users.demag.rwth-aachen.de/donald/download/openssh-1.2.2-x509.tar.gz http://users.demag.rwth-aachen.de/donald/download/openssh-1.2.2-x509.tar.gz. sig And please remember that I didn't even try compiling them. I just grabbed those files to take a look at them when I have some spare time ... I think X.509 in OpenSSH would be very useful. We would be able to manage our UNIX-environment in a more comfortable way. Donald From peterw at usa.net Thu Jan 24 06:10:41 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 14:10:41 -0500 Subject: CAs, server key permanence, SSL weaknesses (X.509 support in ssh) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 12:07:28PM -0600 References: Message-ID: <20020123141041.G22786@usa.net> On Wed, Jan 23, 2002 at 12:07:28PM -0600, mouring at etoh.eviladmin.org wrote: > On Wed, 23 Jan 2002, Ed Phillips wrote: > > I would think that the benefit here is that if your client is configured > > to trust only certain signers, then Joe Hacker can't play > > man-in-the-middle during the "should I accept this hostkey" question, > > because Joe Hacker shouldn't have the private key for the CA you trust. > > > > Isn't that an improvement? > Until your CA's employees do something brain dead like hand out a copy of > your key to someone who 'claims' to be an employee of your company. > Think warm fuzzy thoughts that your CA is trustworthy. =) :-) To be fair, and not come across as a complete apologist for CAs, I think it may be worthwhile to point out that part of the reason CAs are needed for https and Web commerce is not simply the difficulty of distributing Amazon's server keypair. Protocol design and server key permanence are important factors in the importance of CA certs for SSL/TLS. Except for the weak "export" ciphers, the RSA ciphers for SSL/TLS lack what's known as Perfect Forward Secrecy. Anyone who posesses a copy of the server keys can decrypt any traffic to any server using those server keys. Let's say merchant.example.com sets up shop on January 1st. Does a lot of SSL. Some black hat records all the traffic, but can't read any of it because it uses the fairly strong 128-bit RSA SSL/TLS ciphers. But the black hat's significant other does some dumpster diving, turns up the server key from merchant.example.com, and presents it as a Kwanzaa gift. Voila, the black hat can now decrypt all that captured traffic. It doesn't have to be that way, but that's how the spec was written. My personal belief, based on my lurking in the TLS IETF working group's mailing list, is that certain big software companies have exerted pressure on the IETF not to require better ciphers, fearing the ciphers would hurt server performance (and Web admins generally agree that https is a bear compared to http, of course). So, generally speaking, when a company like merchant.example.com renews its annual SSL/TLS cert, it generates a new server keypair.[0] IMO, this ought to happen more often, but... The point is that in https (and SSL/TLS in general), it is *expected* that server certs will be periodically replaced. So a static cache like OpenSSH uses would not be appropriate. A static cache would prevent merchant.example.com from replacing their cert, giving the data-sniffing black hats even more to gain if/when they got the server keypair. CAs are critcial to allowing merchants to replace their keys, to reduce the risks involved in keypair compromise. Of course that brings us to the other side of PKI, the downside of OpenSSH's static hostkey cache. With https, a merchant can fairly effectively[1] disavow a keypair & replace it if it believes the key was compromised, to protect future traffic[2], by revoking the cert -- the revoked cert would then be disavowed with the CA's Certificate Revocation List. How is the admin of an sshd server supposed to handle a situation where his sshd servre keypair has been compromised? -Peter [0] At least commercial products like iPlanet Web Server generate new kesy whenever they generate new Certificate Signing Requests; I believe with something like Apache + mod_ssl + 'openssl' it's easy to reuse a key, bad as that is to do. [1] This is up to the client, of course, just as an ssh client could "ignore and add" a host key if it were poorly designed/configured. [2] Revoking a compromised cert of course does nothing to protect past traffic that may have been captured, and is now decipherable by the attacker. -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From peterw at usa.net Thu Jan 24 06:15:45 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 14:15:45 -0500 Subject: 3rd party vs internal CAs (X.509 support in ssh) In-Reply-To: ; from ed@UDel.Edu on Wed, Jan 23, 2002 at 01:32:01PM -0500 References: Message-ID: <20020123141545.H22786@usa.net> On Wed, Jan 23, 2002 at 01:32:01PM -0500, Ed Phillips wrote: > I wasn't the one talking about a CA "service" like Thawte or Verisign - I > was talking about a home-brew CA used just to sign OpenSSH hostkeys and > verify them so that it can all be automated. I only need to protect the > home-brew-CA private key. That is workable in my environment, and the > reward seems worth the effort. Anyone else think it would be worth it? That's what I was thinking, too. Besides not wanting to pay $100 USD per year per host, I'd have zero interest in giving a third party the hostnames of all the boxes I ran sshd on. And even less interest in letting them know when boxes had been compromised (i.e., when I needed to replace a cert). For internal, or private-use-only, hosts, in-house CAs are the way to go. -Peter -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From mouring at etoh.eviladmin.org Thu Jan 24 06:11:28 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 13:11:28 -0600 (CST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123132125.D22786@usa.net> Message-ID: On Wed, 23 Jan 2002, Peter Watkins wrote: > On Wed, Jan 23, 2002 at 12:03:35PM -0600, mouring at etoh.eviladmin.org wrote: > > On Wed, 23 Jan 2002, Peter Watkins wrote: > > > > A 3rd party CA can at least give the user confidence that the server is > > > owned by the folks who own the domain name, and that is a *LOT* better than > > > the current behavior. Some sort of CA/cert setup definitely makes sense, IMO. > > > > Orgaizations could set up > > > their own CA's and CRLs, and would only need to distribute the CA cert with > > > the client setups -- an easy, one-time setup. Much more manageable than > > > distributing N host keys to M known hosts files, and updating those M files. > > > What an utter joke. CAs give you warm fuzzy feelings. Not much more. > > Without CAs, Internet commerce (business-to-consumer) simply could not > happen. That's not a joke, it's reality. Do certs solve all problems? No. > Are they perfect? No. Are they better than the current status quo? Many > of us believe they would be. While you might not choose to use a cert, > and might (arguably very reasonably) *never* want the official OpenSSH > package, even "portable", to include any "trusted" CA certs, I think adding > cert support would be appreciated by many of the rest of us. No joke. > Pssss.. Give ya a hint.. 'eCommerical' was happening before SSL and CA certifications. It was called "Find what you want on online catalogy and call their voice number." So don't feel that line. If CAs did not exist another method (better or worse would not be known) would appear. CAs appeared because https (and SSL in a lot of respects) lends itself to that style. > > As I said.. from a trust view.. it is a total and utter joke. > > I'd argue the current system of key "management" is an utter joke. Comparing > OpenSSH to https is like comparing /etc/hosts to DNS. From a trust view, DNS > is a joke, right? Now raise your hand if you want to go back to the days of > distributing and managing local host lookup tables. > Great.. Routers can not be trusted.. Lets just live in our own little isolated LANs.. Wait! You can't trust your lan.. someone in your house could be listening in!!! Phhhff.. LAME retort. CAs only work if you have an trust established. Yet another trust to worry about and yet another trust that can be broken. I have no problems with providing companies with the abilities to sign their own keys. It is an internal trust (which still can be broken if the guy making the keys gets fired and takes a copy of the master key chain with in). But like any other major trust system (e-commiercal) it requires user buy in. BTW.. No I never do what to see a "OpenSSH will blindly accept CA certified public keys from the following CAs." Why? Simple.. *WHAT* right does Theo, Markus, Damien, or even myself have to tell the end user "Who should be trusted"? Theo may feel "Foo Signers" is trustworty, I may fell they are a POS operation out to make money and are careless with their key generation. Who is right? I don't presume to dictate trust... Which is my whole point here. And what Microsoft, Netscape, Opera, etc do as part of their core business. They dictate who they feel is trustworthy and then shove that trust in everyone's face. Which IMNSHO is wrong. X.509 I have no problems with. Just think for majority of the people it would be overkill and added compexity. It is 'Trusted CA' I have an issue with. - Ben From bbense at networking.stanford.edu Thu Jan 24 06:21:49 2002 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 23 Jan 2002 11:21:49 -0800 (PST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020123182044.GB698@serv01.aet.tu-cottbus.de> Message-ID: On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > On Wed, Jan 23, 2002 at 07:03:20AM -0800, Booker C. Bense wrote: > > On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > > > Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: > > > The old interface is now working again by default, as long as > > > OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should > > > be changed to the DES_* interface in the long run, as the old > > > interface will go away at some point in the future. > > > > > > (Please note, that 0.9.7 providing the new interface is not even out...) > > > > > > > - Just to confirm, the routines will be DES_foo , but you are playing > > cpp macro games to provide the old interface? > > No cpp macro games but real functions just calling the new functions. > - I was afraid you'd say that... It defeats the whole point of changing the names in the first place[1]. Oh well, I'll just have to figure a way to install openssl without them. At least you tried to do the right thing. - BTW, the cpp macro trick works. I've used it in the kerberos code to allow openssl compatiblity. Looks like I'll have to keep those patches around. - Booker C. Bense [1] Unless you put them in separate library. From peterw at usa.net Thu Jan 24 06:31:22 2002 From: peterw at usa.net (Peter Watkins) Date: Wed, 23 Jan 2002 14:31:22 -0500 Subject: consensus: support for internal CAs is good (X.509 support in ssh) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 01:11:28PM -0600 References: <20020123132125.D22786@usa.net> Message-ID: <20020123143122.I22786@usa.net> On Wed, Jan 23, 2002 at 01:11:28PM -0600, mouring at etoh.eviladmin.org wrote: > I have no problems > with providing companies with the abilities to sign their own keys. It > is an internal trust (which still can be broken if the guy making the keys > gets fired and takes a copy of the master key chain with in). But like > any other major trust system (e-commiercal) it requires user buy in. I think everyone is in agreement on this. (Whew!) > BTW.. No I never do what to see a "OpenSSH will blindly accept CA > certified public keys from the following CAs." And I haven't heard anyone suggest that it should do so. Anyone who wanted to give money to Thawte instead of running their own CA setup could certainly add the root Thawte cert. Their call. > I don't presume to dictate trust... Which is my whole point here. > X.509 I have no problems with. Just think for majority of the people it > would be overkill and added compexity. It is 'Trusted CA' I have an issue > with. Perfect. Really, perfect. -Peter -- We must all learn to live together as brothers, or we will all perish as fools. - Dr Martin Luther King, Jr From budden at nps.navy.mil Thu Jan 24 06:24:01 2002 From: budden at nps.navy.mil (Rex Buddenberg) Date: Wed, 23 Jan 2002 11:24:01 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123104919.A15783@swamp.cacr.caltech.edu> References: <20020123104919.A15783@swamp.cacr.caltech.edu> Message-ID: >I only need to protect the > > home-brew-CA private key. That is workable in my environment, and the >> reward seems worth the effort. Anyone else think it would be worth it? > >I think so. Having all your hostkeys signed by a central authority (like >an OpenSSL generated key) should be fine. There's no reason you have to >pay a Certificate Authority to do it. If this is the limit of scope to your application, by all means keep it simple. > >You could do something like GnuPG and sign all the keys by a single key >(treating it like a CA), if OpenSSH can have a hook to use GnuPG keys. > As a >university employee, we look for solutions that are very cost-effective >(especially if they don't cost anything :). Scope limitation: you can do this for secure comms but only for the accounts you manage -- your students, faculty and staff. It won't work for your supply department trying to buy copier toner from an outside vendor because that vendor won't be on the same key tree. -- b From gator at cacr.caltech.edu Thu Jan 24 06:56:40 2002 From: gator at cacr.caltech.edu (Anne Carasik) Date: Wed, 23 Jan 2002 11:56:40 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: ; from budden@nps.navy.mil on Wed, Jan 23, 2002 at 11:24:01AM -0800 References: <20020123104919.A15783@swamp.cacr.caltech.edu> Message-ID: <20020123115640.A16430@swamp.cacr.caltech.edu> On Wed, Jan 23, 2002 at 11:24:01AM -0800, Rex Buddenberg wrote: > >I think so. Having all your hostkeys signed by a central authority (like > >an OpenSSL generated key) should be fine. There's no reason you have to > >pay a Certificate Authority to do it. > If this is the limit of scope to your application, by all means keep it simple. From what I've seen, most implementations can't handle cross-certification anyway. > Scope limitation: you can do this for secure comms but only for the > accounts you manage -- your students, faculty and staff. It won't > work for your supply department trying to buy copier toner from an > outside vendor because that vendor won't be on the same key tree. Hope you find what you're looking for (sounds like cross-certification to me). -Anne -- .-"".__."``". Anne Carasik, sysadmin, gator at cacr.caltech.edu .-.--. _...' (/) (/) ``' Don't insult the alligator till after you (O/ O) \-' ` -="""=. ', cross the river. -unknown ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020123/7eb879c1/attachment.bin From mouring at etoh.eviladmin.org Thu Jan 24 07:16:37 2002 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 23 Jan 2002 14:16:37 -0600 (CST) Subject: X.509 support in ssh via PAM? In-Reply-To: <20020123134937.F22786@usa.net> Message-ID: On Wed, 23 Jan 2002, Peter Watkins wrote: > On Wed, Jan 23, 2002 at 10:21:39AM -0800, Anne Carasik wrote: > > > I don't remember who said this, as this was a while back. All I remember > > is the PKI thingy, and everyone was trying to do something with it. > > > > From a sysadmin standpoint, I'd like to be able to manage user keys with > > PKI. > > > > You can probably do that with PAM, right? > > Maybe halfway, if that, right? Most of us, I'd wager, are more concerned > about managing/certifying host keys, so a client knows[0] the sshd is > legit, that there's no MITM attack going on. And all the PAM hooks right > now are in the sshd code, so PAM wouldn't come into play here. Is PAM > usable, or appropriate, for use on the *client* side, for verifying the > key presented by the sshd? > I think PAM support of PKI would be a shoe horning at best. > PAM could be useful for the other way around. If the sshd were told to > treat "sshpeer.example.com" as a trusted host, then sshd would need a way > of verifying the key presented by the client. Clearly PAM might work there, > if such a PAM module were to exist. > > But since OpenSSH already uses OpenSSL, wouldn't it make more sense just to > leverage the OpenSSL code instead? > I think OpenSSL's x.509 support would be better since it lends itself to be more portable when everything is said and done. > -Peter > > [0] not Ben's client, but those of us who might enable PKI :-) > For those who want to trust me.. I'd be happy to issue 'EvilAdmin' certified keys. And manage them for only $30 a month for the rest of your life. It would help offset my need to buy Sparc servers that I acquired in the last year. - Ben From markus at openbsd.org Thu Jan 24 07:23:55 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 21:23:55 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123183954.GB21895@faui02> Message-ID: <20020123202355.GA28499@faui02> On Wed, Jan 23, 2002 at 01:52:54PM -0500, Ed Phillips wrote: > somehow leverage LDAP+SSL in the ssh client to verify hostkeys instead of you don't need LDAP for this, just a TrustedCAs /etc/ssh/ca in sshd_config > relying on ~/.ssh/known_hosts in 30000+ user's insecure-NFS-mounted home > directories (which got shot down in flames). you don't want this in $HOME, use /etc/ssh_known_hosts instead. From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jan 24 08:20:32 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 23 Jan 2002 22:20:32 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: References: <20020123182044.GB698@serv01.aet.tu-cottbus.de> Message-ID: <20020123212032.GA4337@serv01.aet.tu-cottbus.de> On Wed, Jan 23, 2002 at 11:21:49AM -0800, Booker C. Bense wrote: > On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > > > On Wed, Jan 23, 2002 at 07:03:20AM -0800, Booker C. Bense wrote: > > > On Wed, 23 Jan 2002, Lutz Jaenicke wrote: > > > > Ok, the behaviour of the OpenSSL-0.9.7 has been adjusted: > > > > The old interface is now working again by default, as long as > > > > OPENSSL_NO_OLD_DES_SUPPORT is not defined. Applications should > > > > be changed to the DES_* interface in the long run, as the old > > > > interface will go away at some point in the future. > > > > > > > > (Please note, that 0.9.7 providing the new interface is not even out...) > > > > > > > > > > - Just to confirm, the routines will be DES_foo , but you are playing > > > cpp macro games to provide the old interface? > > > > No cpp macro games but real functions just calling the new functions. > > > > - I was afraid you'd say that... It defeats the whole point of > changing the names in the first place[1]. Oh well, I'll just have to > figure a way to install openssl without them. At least you tried to do > the right thing. > > - BTW, the cpp macro trick works. I've used it in the kerberos code to > allow openssl compatiblity. Looks like I'll have to keep those > patches around. > > - Booker C. Bense > > [1] Unless you put them in separate library. Hmm, hmm. I actually didn't look into this issue personally (Richard Levitte handled it) and I only pointed out the state-as-is. Your point makes complete sense: as long as the des_* functions are in the library, the linker might take them. So actually it should be macros replacing the des_* calls with DES_* calls... But I am tired now, maybe not seeing the forest because there are so many trees around :-), so I will crosspost this issue to openssl-dev... Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From bugzilla-daemon at mindrot.org Thu Jan 24 09:47:14 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 24 Jan 2002 09:47:14 +1100 (EST) Subject: [Bug 72] sshd 3.0.2p1 assumes authorized_keys2 unless configured otherwise. Message-ID: <20020123224714.AB5EFEA28@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=72 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED ------- Additional Comments From djm at mindrot.org 2002-01-24 09:47 ------- Reporter contacted me by email - the issue was a permissions problem on the authorized_key files ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Thu Jan 24 09:58:05 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 09:58:05 +1100 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123165359.GI5255@faui02> Message-ID: On Wed, 23 Jan 2002, Markus Friedl wrote: > On Wed, Jan 23, 2002 at 08:45:49AM -0800, Anne Carasik wrote: > > Last I heard (and it's been a while), OpenSSH is supposed to have some > > spki support, but I'm not sure when it's going to be implemented. > > who said this? is there anyone working on patches? > i think lsh has some spki thingy. spki looks nice, but I haven't seen a helper library with a BSD compatible license. -d From djm at mindrot.org Thu Jan 24 09:59:11 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 09:59:11 +1100 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123120434.W27398@sm2p1386swk.wdr.com> Message-ID: On Wed, 23 Jan 2002, Nicolas Williams wrote: > > Wow..I hope that is the whole OpenSSH source in that tarball. Because > > that is larger than OpenSSH 3.0.2p1 portable code compressed! > > The tarball's not there to be found... Neil's patches were against an early 1.x version of OpenSSH and also included LDAP support. They wouldn't help much for recent versions. -d From markus at openbsd.org Thu Jan 24 09:56:56 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 23 Jan 2002 23:56:56 +0100 Subject: X.509 support in ssh (revisited) In-Reply-To: References: <20020123165359.GI5255@faui02> Message-ID: <20020123225655.GA1931@faui02> On Thu, Jan 24, 2002 at 09:58:05AM +1100, Damien Miller wrote: > spki looks nice, but I haven't seen a helper library with a BSD compatible > license. unlike keynote :) ? From djm at mindrot.org Thu Jan 24 10:04:55 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 10:04:55 +1100 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: Message-ID: On Wed, 23 Jan 2002, mouring at etoh.eviladmin.org wrote: > Until your CA's employees do something brain dead like hand out a copy of > your key to someone who 'claims' to be an employee of your company. > > Refer to Micorosft and Versign issue last year which caused MS to resign a > ton of packages and revoke a very heavily used key. > > Think warm fuzzy thoughts that your CA is trustworthy. =) If your CA is you, then this is less of a worry. -d From dan at doxpara.com Thu Jan 24 10:11:53 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 23 Jan 2002 15:11:53 -0800 Subject: X.509 support in ssh (revisited) References: <20020123164246.GD5255@faui02> <20020123183853.GA21895@faui02> Message-ID: <008101c1a463$58a91c80$5001000a@effugas> >i know, but this is not how i see how people use https, for example. I must admit, despite my visceral reaction toSSL's honestly embarassing lack of forward secrecy(sniff all you want, we'll keep the decryption key handy for your convenience), it'd actually be nice if we could integrate OpenSSH keys directly with Verisign/Thawte/whoever. As far as they'd know, we'd just be another "web server". Of course, we'd actually do it right, signing the short term encryption key with the long term identity key, but that'd be internal to our implementation. This actually would be a win -- especially since it would work out of the box on any server that already had an SSL key set up correctly. --Dan From dan at doxpara.com Thu Jan 24 10:13:40 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 23 Jan 2002 15:13:40 -0800 Subject: X.509 support in ssh (revisited) References: <20020123183141.GD698@serv01.aet.tu-cottbus.de> Message-ID: <009101c1a463$9879c800$5001000a@effugas> > Hmm. Of course it finally comes down to the CA. And I don't think it makes > sense to add the large commercial CAs (actually, is there anybody left > beyond Verisign anyway?) by default. > But it would my life easier just being my own CA, signing for the hosts > I have. By now I distribute my public keys with rdist (via SSH of course :-), > but this doesn't work with lots of our Linux-machines which are not available > all day long (switched off, booted into Windows) and is only nice with > the 24x7 machines. Throw an rsync into the rc.local of the linux partitions, then. If you can't push 'em out, suck 'em in. Mind sending me a quick doc describing your rdist conf? --Dan From dan at doxpara.com Thu Jan 24 10:26:10 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 23 Jan 2002 15:26:10 -0800 Subject: X.509 support in ssh (revisited) References: <20020123164246.GD5255@faui02> <20020123183954.GB21895@faui02> Message-ID: <00c801c1a465$574e83a0$5001000a@effugas> > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > > new hostkey. How can you tell? > > well, there is no need to generate a new hostkey after an upgrade > of ssh. not even after an upgrade of the system. We really need a ./configure --with-upgrade to set all paths correctly such that this occurs more then one out of a hundred times. In theory, theory is no different than practice. In practice, it is. --Dan From djm at mindrot.org Thu Jan 24 12:49:05 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 12:49:05 +1100 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <00c801c1a465$574e83a0$5001000a@effugas> Message-ID: On Wed, 23 Jan 2002, Dan Kaminsky wrote: > > > Okay... maybe someone has upgrade OpenSSH on the system and generated a > > > new hostkey. How can you tell? > > > > well, there is no need to generate a new hostkey after an upgrade > > of ssh. not even after an upgrade of the system. > > We really need a ./configure --with-upgrade to set all paths correctly such > that this occurs more then one out of a hundred times. OpenSSH's "make install" will never overwrite existing key files, I can't see what more we can do than that. -d From dan at doxpara.com Thu Jan 24 14:39:16 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 23 Jan 2002 19:39:16 -0800 Subject: X.509 support in ssh (revisited) References: Message-ID: <019701c1a488$b2d2ee00$5001000a@effugas> > > We really need a ./configure --with-upgrade to set all paths correctly such > > that this occurs more then one out of a hundred times. > > OpenSSH's "make install" will never overwrite existing key files, I > can't see what more we can do than that. We can make it work under real world conditions. Specific flags are often required for recompilation to be effective(--with-md5-passwords being most common). Very commonly, the daemon itself will have been configured to live in /usr/sbin or /usr/local/sbin, but keying material will live in /etc or /etc/ssh. Lets not even talk about the problem of people being afraid to kill the very same service they're reconfiguring a system through, and thus end up leaving the old daemon residing in memory indefinitely. Plus there's other reasons for upgrade breakage that I don't even know. Clients have trouble figuring out local port forward syntax; servers are confounded by upgrading without at the very least wiping out their old keys. It's just the way it is, and why nobody's surprised when keys change. I'm not complaining about this just to complain -- I'm going to eventually do something about this. I'm thinking about embedding the configure options in the sshd itself and using the process table to discover which sshd to clone(probably allowing --with-upgrade=/usr/sbin as an override). --Dan From bugzilla-daemon at mindrot.org Thu Jan 24 15:21:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 24 Jan 2002 15:21:17 +1100 (EST) Subject: [Bug 75] Error compiling in ssh-agent.c Message-ID: <20020124042117.36B03E92C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From adrian at afsthumper.com 2002-01-24 15:21 ------- The configure report has both HAVE_XATEXIT and HAVE_ATEXIT commented out. It looks like so: /* If you have no atexit() but xatexit(), and want to use xatexit() */ /* #undef HAVE_XATEXIT */ and also /* Define if you have the 'atexit' function. */ /* #undef HAVE_ATEXIT */ Is there a library I'm missing? I'm not familiar with the atexit function and I'm not sure what I need to install to satisfy it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Jan 24 14:38:07 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 23 Jan 2002 19:38:07 -0800 (PST) Subject: X.509 support in ssh (revisited) In-Reply-To: <00c801c1a465$574e83a0$5001000a@effugas> Message-ID: On Wed, 23 Jan 2002, Dan Kaminsky wrote: :We really need a ./configure --with-upgrade to set all paths correctly such :that this occurs more then one out of a hundred times. what exactly would this do? From bugzilla-daemon at mindrot.org Thu Jan 24 15:39:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 24 Jan 2002 15:39:37 +1100 (EST) Subject: [Bug 75] Error compiling in ssh-agent.c Message-ID: <20020124043937.041EAEA22@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From djm at mindrot.org 2002-01-24 15:39 ------- What linux distribution are you using? What version of libc? Can you grep through /usr/include/stdlib.h for an atexit() definition? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Thu Jan 24 15:51:06 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 23 Jan 2002 20:51:06 -0800 Subject: X.509 support in ssh (revisited) References: Message-ID: <01a301c1a492$bbf7bc40$5001000a@effugas> > what exactly would this do? Build an SSHD that matched the presently loaded configuration or die trying. Not really worth talking about until it exists, though. --Dan From djm at mindrot.org Thu Jan 24 16:16:02 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 16:16:02 +1100 (EST) Subject: X.509 support in ssh (revisited) In-Reply-To: <01a301c1a492$bbf7bc40$5001000a@effugas> Message-ID: On Wed, 23 Jan 2002, Dan Kaminsky wrote: > > what exactly would this do? > > Build an SSHD that matched the presently loaded configuration or die trying. > Not really worth talking about until it exists, though. With installation of system software such as OpenSSH being increasinly managed by automated tools (rpm, Solaris packages, .debs, etc), and the building of said software being increasingly done by the packagers, I can't help but believe that the effort to implement this would be better spent elsewhere. -d From secureshell at ifokr.org Thu Jan 24 16:18:11 2002 From: secureshell at ifokr.org (Brian Hatch) Date: Wed, 23 Jan 2002 21:18:11 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <019701c1a488$b2d2ee00$5001000a@effugas> References: <019701c1a488$b2d2ee00$5001000a@effugas> Message-ID: <20020124051811.GF3302@ifokr.org> > Lets not even talk about the problem of people being afraid to > kill the very same service they're reconfiguring a system through, and thus > end up leaving the old daemon residing in memory indefinitely. Every time I upgrade sshd I test the new version out simply by running one on a separate port until I verify it works. You can run it in debug mode, even with a new version of the config file if it'll differ from the existing one: /path/to/new/sshd -p 222 [-d] [-f new_config_file] So a few 'ssh hostname -p 222' tests from various machines should let you know if it works. When it does, kill off the sshd process with PPID 1 and start your new sshd daemon in it's place. No reason to leave the old version running for ages. > Plus there's > other reasons for upgrade breakage that I don't even know. None if you test things before installing. > Clients have trouble figuring out local port forward syntax; What does that have to do with upgrades? > servers are > confounded by upgrading without at the very least wiping out their old keys. I've never had that problem, not even once. I've used the same keys through upgrades from OpenSSH 1.2.3 and on. > It's just the way it is, and why nobody's surprised when keys change. If I see my keys change then sshmitm is to blame. > I'm not complaining about this just to complain -- I'm going to eventually > do something about this. I'm thinking about embedding the configure options > in the sshd itself and using the process table to discover which sshd to > clone(probably allowing --with-upgrade=/usr/sbin as an override). Why not save a copy of the ./configure options you used when you compiled? Incidentally, here's how I do an ssh compile (for a fictitious Linux machine, in this case, root vs non root user issues glossed over for conciseness) $ cd openssh-X.Y.Z $ mkdir /opt/pkgs/openssh-X.Y.Z $ script /opt/pkgs/openssh-X.Y.Z/COMPILE.TXT $ ./configure --prefix=/opt/pkgs/openssh-X.Y.Z \ --with-tcp-wrappers --with-pam \ --with-md5-passwords \ .... $ make; make install $ exit Viola. New sshd doesn't overwite the old one, and you have a copy of the configure options automatically saved in /opt/pkgs/.../COMPILE.TXT which you can look at next time if needed. So, what other arguments do you have that there's a problem with OpenSSH and not your administrative process? -- Brian Hatch "Look, somebody's got to have Systems and some damn perspective around Security Engineer here. Boom, sooner or later. http://www.ifokr.org/bri/ *BOOM*!" Every message PGP signed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020123/f31e3e5b/attachment.bin From levitte at stacken.kth.se Thu Jan 24 17:19:56 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Thu, 24 Jan 2002 07:19:56 +0100 (MET) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020123212032.GA4337@serv01.aet.tu-cottbus.de> References: <20020123182044.GB698@serv01.aet.tu-cottbus.de> <20020123212032.GA4337@serv01.aet.tu-cottbus.de> Message-ID: <20020124.071956.59269850.levitte@stacken.kth.se> From: Lutz Jaenicke Lutz.Jaenicke> On Wed, Jan 23, 2002 at 11:21:49AM -0800, Booker C. Bense wrote: Lutz.Jaenicke> > - I was afraid you'd say that... It defeats the whole Lutz.Jaenicke> > point of changing the names in the first place[1]. Oh Lutz.Jaenicke> > well, I'll just have to figure a way to install Lutz.Jaenicke> > openssl without them. At least you tried to do the Lutz.Jaenicke> > right thing. Lutz.Jaenicke> > Lutz.Jaenicke> > - BTW, the cpp macro trick works. I've used it in the Lutz.Jaenicke> > kerberos code to allow openssl compatiblity. Looks Lutz.Jaenicke> > like I'll have to keep those patches around. Lutz.Jaenicke> > Lutz.Jaenicke> > - Booker C. Bense Lutz.Jaenicke> > Lutz.Jaenicke> > [1] Unless you put them in separate library. My first attepmt was to do the whole thing with cpp macros. However, after giving it some thought, that could cause a number of problems; one is that macros have zero type safety. You can give those macros exactly whatever without the compiler reacting, since a lot of casts would be made in their expansion. The other problem is applications that link either with libdes or with openssl's libcrypto. The latter will very suddenly fail. But, this isn't the end of the story. On some architectures, there are binary incompatibilities between openssl's libcrypto and libdes. -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From djm at mindrot.org Thu Jan 24 17:32:06 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 17:32:06 +1100 (EST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020124.071956.59269850.levitte@stacken.kth.se> Message-ID: On Thu, 24 Jan 2002, Richard Levitte - VMS Whacker wrote: > My first attepmt was to do the whole thing with cpp macros. However, > after giving it some thought, that could cause a number of problems; > one is that macros have zero type safety. You can give those macros > exactly whatever without the compiler reacting, since a lot of casts > would be made in their expansion. If there is a one-to-one mapping of arguments between the new and old functions, and the macros merely rearrange the order (and change the names) then type safety shouldn't be a problem. > The other problem is applications > that link either with libdes or with openssl's libcrypto. The latter > will very suddenly fail. How? These apps would need to be recompiled anyway - that way they would pick up the macros. > But, this isn't the end of the story. On some architectures, there > are binary incompatibilities between openssl's libcrypto and libdes. Aren't these what you are trying to avoid in the first place? The libdes shipped with MIT krbIV is an ongoing source of frustration for the portable OpenSSH developers. -d From levitte at stacken.kth.se Thu Jan 24 18:22:28 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Thu, 24 Jan 2002 08:22:28 +0100 (MET) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: References: <20020124.071956.59269850.levitte@stacken.kth.se> Message-ID: <20020124.082228.28499166.levitte@stacken.kth.se> From: Damien Miller djm> On Thu, 24 Jan 2002, Richard Levitte - VMS Whacker wrote: djm> djm> > My first attepmt was to do the whole thing with cpp macros. However, djm> > after giving it some thought, that could cause a number of problems; djm> > one is that macros have zero type safety. You can give those macros djm> > exactly whatever without the compiler reacting, since a lot of casts djm> > would be made in their expansion. djm> djm> If there is a one-to-one mapping of arguments between the new and old djm> functions, and the macros merely rearrange the order (and change the djm> names) then type safety shouldn't be a problem. Take a look, there are type casts in the wrappers, so it's not merely a rearrangement of the order. djm> > The other problem is applications djm> > that link either with libdes or with openssl's libcrypto. The latter djm> > will very suddenly fail. djm> djm> How? These apps would need to be recompiled anyway - that way they would djm> pick up the macros. If we retain the old symbols in the library, which is currently expected, they don't need to recompile. Re*linking* would be sufficient to satisfy the linkers idea of what the program needs. djm> > But, this isn't the end of the story. On some architectures, there djm> > are binary incompatibilities between openssl's libcrypto and libdes. djm> djm> Aren't these what you are trying to avoid in the first place? djm> The libdes shipped with MIT krbIV is an ongoing source of frustration for djm> the portable OpenSSH developers. Yes, you're right, that's what we try to avoid. However, we've already had complaints about not providing the old symbols by default, so guess how people will react if they are missing in the library as well. This mess is our own fault in a way. We changed the des API from the libdes form, and thereby created a number of source-level incompatibilities, which leads to clashes when people need to interchange libdes and libcrypto in a fairly elegant way. -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From jaltman at columbia.edu Thu Jan 24 18:32:24 2002 From: jaltman at columbia.edu (Jeffrey Altman) Date: Thu, 24 Jan 2002 2:32:24 EST Subject: OpenSSH and OpenSSL snapshots In-Reply-To: Your message of Thu, 24 Jan 2002 08:22:28 +0100 (MET) Message-ID: > djm> > The other problem is applications > djm> > that link either with libdes or with openssl's libcrypto. The latter > djm> > will very suddenly fail. > djm> > djm> How? These apps would need to be recompiled anyway - that way they would > djm> pick up the macros. > > If we retain the old symbols in the library, which is currently > expected, they don't need to recompile. Re*linking* would be > sufficient to satisfy the linkers idea of what the program needs. > > djm> > But, this isn't the end of the story. On some architectures, there > djm> > are binary incompatibilities between openssl's libcrypto and libdes. > djm> > djm> Aren't these what you are trying to avoid in the first place? > djm> The libdes shipped with MIT krbIV is an ongoing source of frustration for > djm> the portable OpenSSH developers. > > Yes, you're right, that's what we try to avoid. However, we've > already had complaints about not providing the old symbols by default, > so guess how people will react if they are missing in the library as > well. > > This mess is our own fault in a way. We changed the des API from the > libdes form, and thereby created a number of source-level > incompatibilities, which leads to clashes when people need to > interchange libdes and libcrypto in a fairly elegant way. Richard: We knew there were going to be complaints no matter what was decided. However, I thought the consensus was that OpenSSL pre-1.0 is not api compatible between releases. Therefore, it didn't matter that the function names would change and the libraries would not be compatible. The longer this change gets put off the more difficult it will be to fix because there will be an ever increasing number of applications relying on it. The only way that this can be handled is to use macros to map from the old api to the new functions. I do not see any other way that will allow the libdes.a to be mixed with libcrypto.a. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support at columbia.edu OpenSSL. Interfaces with OpenSSH From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jan 24 19:08:05 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 24 Jan 2002 09:08:05 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: References: Message-ID: <20020124080805.GA13193@serv01.aet.tu-cottbus.de> On Thu, Jan 24, 2002 at 02:32:24AM -0500, Jeffrey Altman wrote: > > djm> > The other problem is applications > > djm> > that link either with libdes or with openssl's libcrypto. The latter > > djm> > will very suddenly fail. > > djm> > > djm> How? These apps would need to be recompiled anyway - that way they would > > djm> pick up the macros. > > > > If we retain the old symbols in the library, which is currently > > expected, they don't need to recompile. Re*linking* would be > > sufficient to satisfy the linkers idea of what the program needs. Hmm. OpenSSL 0.9.7 is not binary/API compatible with the 0.9.6x series. Applications must be recompiled anyway. > > djm> > But, this isn't the end of the story. On some architectures, there > > djm> > are binary incompatibilities between openssl's libcrypto and libdes. > > djm> > > djm> Aren't these what you are trying to avoid in the first place? > > djm> The libdes shipped with MIT krbIV is an ongoing source of frustration for > > djm> the portable OpenSSH developers. > > > > Yes, you're right, that's what we try to avoid. However, we've > > already had complaints about not providing the old symbols by default, > > so guess how people will react if they are missing in the library as > > well. It should not matter, as they need to recompile anyway, so macros to redefine the functions would be picked up. If the des_old functionality cannot be achieved using macros, we can still leave the wrapper functions but rename them: #define des_ecb3_encrypt(input,output,ks1,ks2,ks3) \ DES_old_ecb3_encrypt(input,output,ks1,ks2,ks3) and then call the wrapper functions des_old_*(). In this way the argument handling can be done in real functions, but in the library they are found as "des_old_*", so we will never see a problem of the linker finding the wrong functions. Looks ugly? But it would help to solve the conflict. > We knew there were going to be complaints no matter what was decided. > However, I thought the consensus was that OpenSSL pre-1.0 is not > api compatible between releases. Therefore, it didn't matter that > the function names would change and the libraries would not be > compatible. The longer this change gets put off the more difficult > it will be to fix because there will be an ever increasing number > of applications relying on it. I agree on that this problem must be solved. In former times with export restrictions the amount of cryptographic code and options (kerberos etc) was much smaller. Now that much more code of this type is available the amount of possible conflicts should be minimized. OpenSSL already cleared its namespace by moving include files into openssl/*.h allowing inclusion of similar header files with the same name, now the contents must also be worked out :-) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From ben at algroup.co.uk Thu Jan 24 19:34:41 2002 From: ben at algroup.co.uk (Ben Laurie) Date: Thu, 24 Jan 2002 08:34:41 +0000 Subject: OpenSSH and OpenSSL snapshots References: <20020123182044.GB698@serv01.aet.tu-cottbus.de> <20020123212032.GA4337@serv01.aet.tu-cottbus.de> <20020124.071956.59269850.levitte@stacken.kth.se> Message-ID: <3C4FC721.D7DB8F5F@algroup.co.uk> Richard Levitte - VMS Whacker wrote: > > From: Lutz Jaenicke > > Lutz.Jaenicke> On Wed, Jan 23, 2002 at 11:21:49AM -0800, Booker C. Bense wrote: > Lutz.Jaenicke> > - I was afraid you'd say that... It defeats the whole > Lutz.Jaenicke> > point of changing the names in the first place[1]. Oh > Lutz.Jaenicke> > well, I'll just have to figure a way to install > Lutz.Jaenicke> > openssl without them. At least you tried to do the > Lutz.Jaenicke> > right thing. > Lutz.Jaenicke> > > Lutz.Jaenicke> > - BTW, the cpp macro trick works. I've used it in the > Lutz.Jaenicke> > kerberos code to allow openssl compatiblity. Looks > Lutz.Jaenicke> > like I'll have to keep those patches around. > Lutz.Jaenicke> > > Lutz.Jaenicke> > - Booker C. Bense > Lutz.Jaenicke> > > Lutz.Jaenicke> > [1] Unless you put them in separate library. > > My first attepmt was to do the whole thing with cpp macros. However, > after giving it some thought, that could cause a number of problems; > one is that macros have zero type safety. You can give those macros > exactly whatever without the compiler reacting, since a lot of casts > would be made in their expansion. Umm ... but we know how to do typesafe macros, remember? > The other problem is applications > that link either with libdes or with openssl's libcrypto. The latter > will very suddenly fail. Not sure what to do about this one, though! > But, this isn't the end of the story. On some architectures, there > are binary incompatibilities between openssl's libcrypto and libdes. Arg! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From levitte at stacken.kth.se Thu Jan 24 20:06:52 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Thu, 24 Jan 2002 10:06:52 +0100 (MET) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: References: Message-ID: <20020124.100652.68141672.levitte@stacken.kth.se> From: Jeffrey Altman jaltman> The only way that this can be handled is to use macros to map from jaltman> the old api to the new functions. I do not see any other way that jaltman> will allow the libdes.a to be mixed with libcrypto.a. I'm thinking you're right. At the same time, I want to retain C type security as well as possible. How about this: I could rename all the old functions to _old_des_* and then have cpp macros that map des_* to _old_des_*. That would probably resolve all the issues. -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From levitte at stacken.kth.se Thu Jan 24 20:13:56 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Thu, 24 Jan 2002 10:13:56 +0100 (MET) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <3C4FC721.D7DB8F5F@algroup.co.uk> References: <20020123212032.GA4337@serv01.aet.tu-cottbus.de> <20020124.071956.59269850.levitte@stacken.kth.se> <3C4FC721.D7DB8F5F@algroup.co.uk> Message-ID: <20020124.101356.32239086.levitte@stacken.kth.se> From: Ben Laurie ben> > But, this isn't the end of the story. On some architectures, there ben> > are binary incompatibilities between openssl's libcrypto and libdes. ben> ben> Arg! Hardly a surprise, I've talked about that before (last summer or autumn, IIRC). The incompatibility comes from different uses of DES_INT on 64-bit architectures. -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From levitte at stacken.kth.se Thu Jan 24 20:19:49 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Thu, 24 Jan 2002 10:19:49 +0100 (MET) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020124.100652.68141672.levitte@stacken.kth.se> References: <20020124.100652.68141672.levitte@stacken.kth.se> Message-ID: <20020124.101949.127150754.levitte@stacken.kth.se> From: Richard Levitte - VMS Whacker levitte> I'm thinking you're right. At the same time, I want to retain C type levitte> security as well as possible. How about this: I could rename all the levitte> old functions to _old_des_* and then have cpp macros that map des_* to levitte> _old_des_*. That would probably resolve all the issues. Just saw that others came up with the same thought... -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From djm at mindrot.org Thu Jan 24 21:50:26 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Jan 2002 21:50:26 +1100 (EST) Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <20020124.082228.28499166.levitte@stacken.kth.se> Message-ID: On Thu, 24 Jan 2002, Richard Levitte - VMS Whacker wrote: > If we retain the old symbols in the library, which is currently > expected, they don't need to recompile. Re*linking* would be > sufficient to satisfy the linkers idea of what the program needs. I don't think anyone will be too upset with another binary incompatible OpenSSL release :) -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From bugzilla-daemon at mindrot.org Thu Jan 24 23:18:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 24 Jan 2002 23:18:32 +1100 (EST) Subject: [Bug 75] Error compiling in ssh-agent.c Message-ID: <20020124121832.82E84E923@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From adrian at afsthumper.com 2002-01-24 23:18 ------- I am using Peanut Linux 8.4 (http://www.peanutlinux.org), which is just a stripped down version of linux that uses BSD-style init scripts. I am running kernel 2.2.19 with pretty standard features, nothing strange or experimental compiled in. I am using GLibc 2.2.4, libc6 ELF. The atexit definition(s) I have in stdlib.h are as follows: (I wasn't sure which one was more pertinent) /* Register a function to be called when 'exit' is called. */ extern int atexit __P ((void (*__func) (void))); /* Call all functions registered with 'atexit' and 'on_exit', in the reverse of the order in which they were registered perform stdio cleanup, and terminate program execution with STATUS. */ extern void exit __P ((int __status)) __attribute__ ((__noreturn__)); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jaltman at columbia.edu Fri Jan 25 00:22:34 2002 From: jaltman at columbia.edu (Jeffrey Altman) Date: Thu, 24 Jan 2002 8:22:34 EST Subject: OpenSSH and OpenSSL snapshots In-Reply-To: Your message of Thu, 24 Jan 2002 10:06:52 +0100 (MET) Message-ID: > From: Jeffrey Altman > > jaltman> The only way that this can be handled is to use macros to map from > jaltman> the old api to the new functions. I do not see any other way that > jaltman> will allow the libdes.a to be mixed with libcrypto.a. > > I'm thinking you're right. At the same time, I want to retain C type > security as well as possible. How about this: I could rename all the > old functions to _old_des_* and then have cpp macros that map des_* to > _old_des_*. That would probably resolve all the issues. Look at what we do in in kssl.c for mapping the kerberos functions from krb5_ to kssl_krb5_ in the windows world. That is exactly what you want to do in this case. Rename the real functions in the library. Then in the des.h header if USE_OLD_DES is defined you #define des_foo old_des_foo and expose the prototypes for the old_des_foo function. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support at columbia.edu OpenSSL. Interfaces with OpenSSH From manoj at ranchnetworks.com Fri Jan 25 01:51:28 2002 From: manoj at ranchnetworks.com (Manoj Jaitly) Date: Thu, 24 Jan 2002 09:51:28 -0500 Subject: Please unsubscribe me from this list In-Reply-To: Message-ID: From Nicolas.Williams at ubsw.com Fri Jan 25 03:54:52 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 24 Jan 2002 11:54:52 -0500 Subject: PATCH: krb4/krb5/... names/patterns in auth_keys entries Message-ID: <20020124115451.Z27398@sm2p1386swk.wdr.com> This patch (to OpenSSH 3.0.2p1) adds support for using krb4, krb5 and other principal names in authorized_keys entries. It's a sort of replacement for .klogin and .k5login, but it's much more general than .k*login as it applies to any authentication mechanism where a name is associated with the ssh client and it supports name patterns and all the normal authorized_keys entry options we're used to. Now you can have entries like these in your authorized_keys files: ssh-ext-named:krb5 someuser at SOMEREALM deny-access ssh-ext-named:krb5 joe/superroot at SOMEREALM ssh-ext-name-pat:krb5 */superroot at SOMERALM command=/local/bin/inventory ssh-name-pat:krb5 inventory/*.mydomain at MYREALM ... Double quotes can be used when key names contain whitespace and '\' can be used inside double-quotes to quote quote (use '\\' for '\')... This feature applies to SSHv1 krb4 and krb5 auth. It also applies to SSHv2, with Simon Wilkinson's gsskeyex patch, to GSS-API authentication, either with the Kerberos V GSS mechanism or the GSI GSS mechanism. Features added: - ssh-named key entry type for authorized_keys files - ssh-name-pat key entry type for authorized_keys files - deny-access option for authorized_keys files - SSH_AUTH_NAME env var added by sshd for clients with named keys - SSH_AUTH_NAME_TYPE env var added by sshd for clients with named keys I really hope that this feature or a variation thereof will find its way into OpenSSH. In conjunction with Kerberos (IV or V) it can be extremely useful: - key management is simplified: key management is done at the KDC and there is no need to edit authorized_keys files all over to change or revoke keys! - authorized_keys is much more featureful than .klogin and .k5login are, regardless of Kerberos implementation source (KTH, Heimdal, MIT, SEAM, all implement pretty much the same all-or-nothing .klogin/.k5login functionality). - patterns can be very useful. For example: command=/local/bin/inventory ssh-name-pat:krb5 inventory/*.mydomain at MYREALM which allows me to setup new inventory master hosts without having to change ~root/.authorized_keys on all thousands of servers. Below you should find two versions of this patch, one against OpenSSH 3.0.2p1, the other against 3.0.2p1 + Simon Willkinson's GSS-API patches. Files modified: - key.h - added KEY_NAME key type - added KEY_NAME_PAT key type - added name, name_len and name_type fields to the Key struct - added prototype for key_match() - key.c - added initialization/finalization of new Key fields to key_new()/key_free() - added named/pattern key type support to a variety of functions, including key_read() and key_write(), among others - added key_match() implementation - auth-options.h - added void auth_set_key_env(Key *) prototype - auth-options.c - added auth_set_key_env() implementation - modified auth_parse_options() to return (-1) when new deny-access option is encountered - auth-rsa.c - modified auth_parse_options() return value check according to the change made to auth_parse_options() - auth2.c - user_key_allowed() is not static now - modified user_key_allowed2() to: - try key_match() if key_equal() fails - check the result of auth_parse_options() for negative, 0, or positive values. - modified userauth_pubkey() to check for a positive return from user_key_allowed() - sshd.8 - added documentation for new key types and the new auth_keys option - auth-krb4.c - modified auth_krb4() to build a Key struct and call user_key_allowed() - auth-krb5.c - modified auth_krb5() to build a Key struct and call user_key_allowed() - gss-serv.c - modified ssh_gssapi_krb5_userok() to build a Key struct and call user_key_allowed() Comments? Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- -------------- next part -------------- Index: 3_0_2p1.1/sshd.8 --- 3_0_2p1.1/sshd.8 Thu, 10 Jan 2002 14:11:10 -0500 +++ 3_0_2p1_w_named_keys.1(w)/sshd.8 Thu, 24 Jan 2002 10:52:24 -0500 @@ -932,7 +932,8 @@ is the default file that lists the public keys that are permitted for RSA authentication in protocol version 1 and for public key authentication (PubkeyAuthentication) -in protocol version 2. +in protocol version 2. It can also list key names or key patterns +for external authentication systems, such as krb4, krb5, gsi, etc... .Cm AuthorizedKeysFile may be used to specify an alternative file. .Pp @@ -955,7 +956,19 @@ For protocol version 2 the keytype is .Dq ssh-dss or -.Dq ssh-rsa . +.Dq ssh-rsa +or +.Dq ssh-named: +or +.Dq ssh-name-pat: . +.Pp +Named keys and key name patterns follow the latter two, in double +quotes if they contain whitespace. Named key types may include: +.Dq krb4 , +.Dq krb5 +and/or +.Dq gsi , +depending on what features are compiled in to OpenSSH. .Pp Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). @@ -1017,6 +1030,10 @@ This option is automatically disabled if .Cm UseLogin is enabled. +.It Cm deny-access +This option ends authorized_keys2 processing if the key matches. This +option is only really useful with named key and named key pattern +entries. .It Cm no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. Index: 3_0_2p1.1/key.h --- 3_0_2p1.1/key.h Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/key.h Thu, 24 Jan 2002 10:52:24 -0500 @@ -34,7 +34,9 @@ KEY_RSA1, KEY_RSA, KEY_DSA, - KEY_UNSPEC + KEY_UNSPEC, + KEY_NAME, + KEY_NAME_PAT }; enum fp_type { SSH_FP_SHA1, @@ -53,12 +55,15 @@ int flags; RSA *rsa; DSA *dsa; + u_char *name; + char *name_type; }; Key *key_new(int); Key *key_new_private(int); void key_free(Key *); int key_equal(Key *, Key *); +int key_match(Key *a, Key *b); char *key_fingerprint(Key *, enum fp_type, enum fp_rep); char *key_type(Key *); int key_write(Key *, FILE *); Index: 3_0_2p1.1/key.c --- 3_0_2p1.1/key.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/key.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -57,6 +57,8 @@ k->flags = 0; k->dsa = NULL; k->rsa = NULL; + k->name = NULL; + k->name_type = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -73,6 +75,8 @@ dsa->pub_key = BN_new(); k->dsa = dsa; break; + case KEY_NAME: + case KEY_NAME_PAT: case KEY_UNSPEC: break; default: @@ -120,6 +124,13 @@ DSA_free(k->dsa); k->dsa = NULL; break; + case KEY_NAME: + case KEY_NAME_PAT: + if (k->name != NULL) + xfree(k->name); + if (k->name_type != NULL) + xfree(k->name_type); + break; case KEY_UNSPEC: break; default: @@ -131,8 +142,9 @@ int key_equal(Key *a, Key *b) { - if (a == NULL || b == NULL || a->type != b->type) + if (a == NULL || b == NULL || a->type != b->type) { return 0; + } switch (a->type) { case KEY_RSA1: case KEY_RSA: @@ -147,12 +159,65 @@ BN_cmp(a->dsa->g, b->dsa->g) == 0 && BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; break; + case KEY_NAME: + if ((a->name_type == NULL && b->name_type == NULL) || + (a->name_type == b->name_type)) + return (strcmp(a->name, b->name) == 0); + if (a->name_type == NULL || b->name_type == NULL) + return 0; + if (strcmp(a->name_type, b->name_type) == 0) + return (strcmp(a->name, b->name) == 0); + break; + case KEY_NAME_PAT: + return 0; + break; default: fatal("key_equal: bad key type %d", a->type); break; } return 0; } +int +key_match(Key *a, Key *b) +{ + debug3("key_match: trying to match %x and %x", a, b); + if (a == NULL || b == NULL) + return 0; + + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); + /* One key must be a name pattern, the other must be a name */ + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) + return 0; + + /* Both keys must have name types, or both must not */ + /* or one key must have '*' as its name type */ + if ((a->name_type == NULL && b->name_type != NULL) || + (b->name_type == NULL && a->name_type != NULL)) { + + debug3("key_match: foo"); + if (a->name_type != NULL && *(a->name_type) != '*') + return 0; + if (b->name_type != NULL && *(b->name_type) != '*') + return 0; + } + + /* Name type "*" matches any name type */ + /* Otherwise name types must match */ + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && + (*(a->name_type) != '*' || *(b->name_type) != '*')) { + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); + return 0; + } + + debug3("key_match: trying to match %s WITH %s", a->name, b->name); + if (a->type == KEY_NAME_PAT) + return match_pattern(b->name, a->name); + else + return match_pattern(a->name, b->name); +} + static u_char* key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) @@ -161,7 +226,7 @@ EVP_MD_CTX ctx; u_char *blob = NULL; u_char *retval = NULL; - int len = 0; + u_int len = 0; int nlen, elen; *dgst_raw_length = 0; @@ -364,11 +429,12 @@ { Key *k; int success = -1; - char *cp, *space; + char *cp, *space, *name_type; int len, n, type; u_int bits; - u_char *blob; + u_char *blob = NULL; + name_type = NULL; cp = *cpp; switch(ret->type) { @@ -391,6 +457,8 @@ case KEY_UNSPEC: case KEY_RSA: case KEY_DSA: + case KEY_NAME: + case KEY_NAME_PAT: space = strchr(cp, ' '); if (space == NULL) { debug3("key_read: no space"); @@ -398,6 +466,19 @@ } *space = '\0'; type = key_type_from_name(cp); + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { + char * colon = NULL; + + colon = strchr(cp, ':'); + + debug3("key_read: reading named%s key", + (type == KEY_NAME) ? "" : " pattern"); + + if (colon != NULL && *(++colon) != '\0') { + name_type = xstrdup(colon); + } else + name_type == NULL; + } *space = ' '; if (type == KEY_UNSPEC) { debug3("key_read: no key found"); @@ -410,31 +491,83 @@ } if (ret->type == KEY_UNSPEC) { ret->type = type; + } else if (ret->type == KEY_NAME && type == KEY_NAME_PAT) { + ret->type = type; } else if (ret->type != type) { /* is a key, but different type */ debug3("key_read: type mismatch"); return -1; } - len = 2*strlen(cp); - blob = xmalloc(len); - n = uudecode(cp, blob, len); - if (n < 0) { - error("key_read: uudecode %s failed", cp); - return -1; + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + char *p, *p1, ch; + + if (cp == NULL || *cp == '\0') + return -1; + + debug3("key_read: reading named key %s", cp); + k = key_new(ret->type); + /* Skip whitespace */ + for ( ; (*cp != '\0') && isspace(*cp) && (*cp != '\n') ; cp++ ) + ; + if (*cp == '"') { + k->name = (unsigned char *) xstrdup(cp+1); + p = k->name; + for ( p1 = cp+1 ; *p1 != '\0' ; p1++ ) { + if (*p1 == '\\') + p1++; + else if (*p1 == '"') + break; + *p++ = *p1; + } + *p = '\0'; + debug3("key_read: quoted key: %s", k->name); + } else { + /* Ignore trailing whitespace */ + for ( p = cp ; *p != '\0' && !isspace(*p) ; p++ ) + ; + ch = *p; + *p = '\0'; + k->name = (unsigned char *) xstrdup(cp); + *p = ch; + debug3("key_read: key: %s", k->name); + } + k->name_type = name_type; + } else { + len = 2*strlen(cp); + blob = xmalloc(len); + n = uudecode(cp, blob, len); + if (n < 0) { + error("key_read: uudecode %s failed", cp); + return -1; + } + k = key_from_blob(blob, n); } - k = key_from_blob(blob, n); if (k == NULL) { error("key_read: key_from_blob %s failed", cp); return -1; } - xfree(blob); + if (blob != NULL) + xfree(blob); if (k->type != type) { - error("key_read: type mismatch: encoding error"); - key_free(k); - return -1; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + error("key_read: type mismatch: encoding error"); + key_free(k); + return -1; + } } /*XXXX*/ - if (ret->type == KEY_RSA) { + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + /* + if (ret->name != NULL) + xfree(ret->name); + */ + ret->name = k->name; + ret->name_type = k->name_type; + k->name = NULL; + k->name_type = NULL; + success = 1; + } else if (ret->type == KEY_RSA) { if (ret->rsa != NULL) RSA_free(ret->rsa); ret->rsa = k->rsa; @@ -488,7 +621,7 @@ } } else if ((key->type == KEY_DSA && key->dsa != NULL) || (key->type == KEY_RSA && key->rsa != NULL)) { - int len, n; + u_int len, n; u_char *blob, *uu; key_to_blob(key, &blob, &len); uu = xmalloc(2*len); @@ -499,6 +632,12 @@ } xfree(blob); xfree(uu); + } else if (key->type == KEY_NAME && key->name != NULL) { + fprintf(f, "%s ", key_ssh_name(key)); + if (key->name_type != NULL) + fprintf(f, ":%s", key->name_type); + else + fprintf(f, " \"%s\"", key->name); } return success; } @@ -515,6 +654,12 @@ case KEY_DSA: return "DSA"; break; + case KEY_NAME: + return "Named"; + break; + case KEY_NAME_PAT: + return "Name_Pattern"; + break; } return "unknown"; } @@ -528,6 +673,12 @@ case KEY_DSA: return "ssh-dss"; break; + case KEY_NAME: + return "ssh-named"; + break; + case KEY_NAME_PAT: + return "ssh-name-pat"; + break; } return "ssh-unknown"; } @@ -605,6 +756,14 @@ BN_copy(n->rsa->n, k->rsa->n); BN_copy(n->rsa->e, k->rsa->e); break; + case KEY_NAME: + case KEY_NAME_PAT: + n = key_new(k->type); + n->name = xstrdup(k->name); + if (k->name_type) { + n->name_type = xstrdup(k->name_type); + } + break; default: fatal("key_from_private: unknown type %d", k->type); break; @@ -625,6 +784,26 @@ return KEY_RSA; } else if (strcmp(name, "ssh-dss") == 0){ return KEY_DSA; + } else if (strcmp(name, "ssh-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-named:", strlen("ssh-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-name-pat:", + strlen("ssh-name-pat:")) == 0){ + return KEY_NAME_PAT; + /* Backwards compatibility for previous named key entry forms at UBSW */ + } else if (strcmp(name, "ssh-ext-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-ext-named:", + strlen("ssh-ext-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-ext-name-pat:", + strlen("ssh-ext-name-pat:")) == 0){ + return KEY_NAME_PAT; } debug2("key_type_from_name: unknown key type '%s'", name); return KEY_UNSPEC; Index: 3_0_2p1.1/auth2.c --- 3_0_2p1.1/auth2.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth2.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -76,7 +76,7 @@ /* helper */ static Authmethod *authmethod_lookup(const char *); static char *authmethods_get(void); -static int user_key_allowed(struct passwd *, Key *); +int user_key_allowed(struct passwd *, Key *); static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); /* auth */ @@ -476,7 +476,7 @@ buffer_dump(&b); #endif /* test for correct signature */ - if (user_key_allowed(authctxt->pw, key) && + if (user_key_allowed(authctxt->pw, key) > 0 && key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) authenticated = 1; buffer_clear(&b); @@ -493,7 +493,7 @@ * if a user is not allowed to login. is this an * issue? -markus */ - if (user_key_allowed(authctxt->pw, key)) { + if (user_key_allowed(authctxt->pw, key) > 0) { packet_start(SSH2_MSG_USERAUTH_PK_OK); packet_put_string(pkalg, alen); packet_put_string(pkblob, blen); @@ -719,24 +719,31 @@ continue; } } - if (key_equal(found, key) && - auth_parse_options(pw, options, file, linenum) == 1) { - found_key = 1; - debug("matching key found: file %s, line %lu", - file, linenum); - break; + if (key_equal(found, key) || key_match(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key != 0) + break; + auth_clear_options(); } } restore_uid(); fclose(f); key_free(found); - if (!found_key) + if (found_key == 0) debug2("key not found"); + else if (found_key > 0) { + debug("matching key found: file %s, line %lu", + file, linenum); + auth_set_key_env(key); + } else + debug("matching deny key found: file %s, line %lu", + file, linenum); + return found_key; } /* check whether given key is in .ssh/authorized_keys* */ -static int +int user_key_allowed(struct passwd *pw, Key *key) { int success; @@ -745,7 +752,7 @@ file = authorized_keys_file(pw); success = user_key_allowed2(pw, key, file); xfree(file); - if (success) + if (success != 0) return success; /* try suffix "2" for backward compat, too */ Index: 3_0_2p1.1/auth-rsa.c --- 3_0_2p1.1/auth-rsa.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-rsa.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -232,7 +232,7 @@ * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (auth_parse_options(pw, options, file, linenum) < 1) continue; /* Perform the challenge-response dialog for this key. */ Index: 3_0_2p1.1/auth-options.h --- 3_0_2p1.1/auth-options.h Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-options.h Thu, 24 Jan 2002 10:52:24 -0500 @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -31,6 +33,8 @@ extern struct envstring *custom_environment; int auth_parse_options(struct passwd *, char *, char *, u_long); +void auth_set_key_env(Key *k); void auth_clear_options(void); + #endif Index: 3_0_2p1.1/auth-options.c --- 3_0_2p1.1/auth-options.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-options.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -56,8 +56,43 @@ channel_clear_permitted_opens(); } +void auth_set_key_env(Key *k) +{ + struct envstring *new_env; + char *s; + int len; + + if (k->type != KEY_NAME) + return; + + len = strlen("SSH_AUTH_NAME="); + len += strlen(k->name) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_NAME=%s", k->name); + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + if (k->name_type == NULL) + return; + + len = strlen("SSH_AUTH_NAME_TYPE="); + len += strlen(k->name_type) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_NAME_TYPE=%s", k->name_type); + + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + return; +} + /* - * return 1 if access is granted, 0 if not. + * return 1 if access is granted, 0 if not, -1 if access explicitly denied * side effect: sets key option flags */ int @@ -73,6 +108,12 @@ return 1; while (*opts && *opts != ' ' && *opts != '\t') { + cp = "deny-access"; + if (strncasecmp(opts, cp, strlen(cp)) == 0) { + log("Authentication successful, but authorization denied"); + packet_send_debug("Permission denied"); + return -1; + } cp = "no-port-forwarding"; if (strncasecmp(opts, cp, strlen(cp)) == 0) { packet_send_debug("Port forwarding disabled."); Index: 3_0_2p1.1/auth-krb4.c --- 3_0_2p1.1/auth-krb4.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-krb4.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -40,6 +40,7 @@ #ifdef KRB4 extern ServerOptions options; +int user_key_allowed(struct passwd *, Key *); static int krb4_init(void *context) @@ -220,6 +221,7 @@ socklen_t slen; u_int cksum; int r, s; + Key k; s = packet_get_connection_in(); @@ -249,12 +251,27 @@ *adat.pinst ? "." : "", adat.pinst, adat.prealm); /* Check ~/.klogin authorization now. */ - if (kuserok(&adat, authctxt->user) != KSUCCESS) { - log("Kerberos v4 .klogin authorization failed for %s to " - "account %s", *client, authctxt->user); + k.type = KEY_NAME; + k.name = *client; + k.name_type = "krb4"; + + r = user_key_allowed(authctxt->pw, &k); + + if (r < 0) { + log("Kerberos v4 %s authorization failed for %s to " + "account %s", "authorized_keys", *client, authctxt->user); xfree(*client); return (0); } + + if (r == 0 && kuserok(&adat, authctxt->user) != KSUCCESS) { + log("Kerberos v4 %s authorization failed for %s to " + "account %s", (r == 0) ? ".klogin" : "authorized_keys", + *client, authctxt->user); + xfree(*client); + return (0); + } + /* Increment the checksum, and return it encrypted with the session key. */ cksum = adat.checksum + 1; Index: 3_0_2p1.1/auth-krb5.c --- 3_0_2p1.1/auth-krb5.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-krb5.c Thu, 24 Jan 2002 10:52:24 -0500 @@ -19,6 +19,7 @@ #include extern ServerOptions options; +int user_key_allowed(struct passwd *, Key *); static int krb5_init(void *context) @@ -52,6 +53,8 @@ krb5_principal server; krb5_data reply; krb5_ticket *ticket; + Key k; + char *client_name; int fd, ret; ret = 0; @@ -95,14 +98,30 @@ if (problem) goto err; + if (!krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, + &client_name)) + goto err; + /* Check .k5login authorization now. */ - if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, - authctxt->pw->pw_name)) + k.type = KEY_NAME; + k.name = client_name; + k.name_type = "krb5"; + + ret = user_key_allowed(authctxt->pw, &k); + if (ret < 0) { + ret = 0; goto err; + } + if (ret == 0 && !krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, + authctxt->pw->pw_name)) { + log("SSHv1 Kerberos v5 %s authorization failed for %s to " + "account %s", (ret == 0) ? ".k5login" : "authorized_keys", + *client, authctxt->user); + goto err; + } if (client) - krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, - client); + *client = client_name; packet_start(SSH_SMSG_AUTH_KERBEROS_RESPONSE); packet_put_string((char *) reply.data, reply.length); -------------- next part -------------- Index: 3_0_2p1_w_gss.1/sshd.8 --- 3_0_2p1_w_gss.1/sshd.8 Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/sshd.8 Fri, 18 Jan 2002 14:15:53 -0500 @@ -951,7 +951,8 @@ is the default file that lists the public keys that are permitted for RSA authentication in protocol version 1 and for public key authentication (PubkeyAuthentication) -in protocol version 2. +in protocol version 2. It can also list key names or key patterns +for external authentication systems, such as krb4, krb5, gsi, etc... .Cm AuthorizedKeysFile may be used to specify an alternative file. .Pp @@ -974,7 +975,19 @@ For protocol version 2 the keytype is .Dq ssh-dss or -.Dq ssh-rsa . +.Dq ssh-rsa +or +.Dq ssh-named: +or +.Dq ssh-name-pat: . +.Pp +Named keys and key name patterns follow the latter two, in double +quotes if they contain whitespace. Named key types may include: +.Dq krb4 , +.Dq krb5 +and/or +.Dq gsi , +depending on what features are compiled in to OpenSSH. .Pp Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). @@ -1036,6 +1049,10 @@ This option is automatically disabled if .Cm UseLogin is enabled. +.It Cm deny-access +This option ends authorized_keys2 processing if the key matches. This +option is only really useful with named key and named key pattern +entries. .It Cm no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. Index: 3_0_2p1_w_gss.1/key.h --- 3_0_2p1_w_gss.1/key.h Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/key.h Fri, 18 Jan 2002 12:24:41 -0500 @@ -35,7 +35,9 @@ KEY_RSA, KEY_DSA, KEY_NULL, - KEY_UNSPEC + KEY_UNSPEC, + KEY_NAME, + KEY_NAME_PAT }; enum fp_type { SSH_FP_SHA1, @@ -54,12 +56,15 @@ int flags; RSA *rsa; DSA *dsa; + u_char *name; + char *name_type; }; Key *key_new(int); Key *key_new_private(int); void key_free(Key *); int key_equal(Key *, Key *); +int key_match(Key *a, Key *b); char *key_fingerprint(Key *, enum fp_type, enum fp_rep); char *key_type(Key *); int key_write(Key *, FILE *); Index: 3_0_2p1_w_gss.1/key.c --- 3_0_2p1_w_gss.1/key.c Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/key.c Fri, 18 Jan 2002 17:21:17 -0500 @@ -57,6 +57,8 @@ k->flags = 0; k->dsa = NULL; k->rsa = NULL; + k->name = NULL; + k->name_type = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -73,6 +75,8 @@ dsa->pub_key = BN_new(); k->dsa = dsa; break; + case KEY_NAME: + case KEY_NAME_PAT: case KEY_UNSPEC: break; default: @@ -120,6 +124,13 @@ DSA_free(k->dsa); k->dsa = NULL; break; + case KEY_NAME: + case KEY_NAME_PAT: + if (k->name != NULL) + xfree(k->name); + if (k->name_type != NULL) + xfree(k->name_type); + break; case KEY_UNSPEC: break; default: @@ -131,8 +142,9 @@ int key_equal(Key *a, Key *b) { - if (a == NULL || b == NULL || a->type != b->type) + if (a == NULL || b == NULL || a->type != b->type) { return 0; + } switch (a->type) { case KEY_RSA1: case KEY_RSA: @@ -147,12 +159,65 @@ BN_cmp(a->dsa->g, b->dsa->g) == 0 && BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; break; + case KEY_NAME: + if ((a->name_type == NULL && b->name_type == NULL) || + (a->name_type == b->name_type)) + return (strcmp(a->name, b->name) == 0); + if (a->name_type == NULL || b->name_type == NULL) + return 0; + if (strcmp(a->name_type, b->name_type) == 0) + return (strcmp(a->name, b->name) == 0); + break; + case KEY_NAME_PAT: + return 0; + break; default: fatal("key_equal: bad key type %d", a->type); break; } return 0; } +int +key_match(Key *a, Key *b) +{ + debug3("key_match: trying to match %x and %x", a, b); + if (a == NULL || b == NULL) + return 0; + + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); + /* One key must be a name pattern, the other must be a name */ + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) + return 0; + + /* Both keys must have name types, or both must not */ + /* or one key must have '*' as its name type */ + if ((a->name_type == NULL && b->name_type != NULL) || + (b->name_type == NULL && a->name_type != NULL)) { + + debug3("key_match: foo"); + if (a->name_type != NULL && *(a->name_type) != '*') + return 0; + if (b->name_type != NULL && *(b->name_type) != '*') + return 0; + } + + /* Name type "*" matches any name type */ + /* Otherwise name types must match */ + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && + (*(a->name_type) != '*' || *(b->name_type) != '*')) { + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); + return 0; + } + + debug3("key_match: trying to match %s WITH %s", a->name, b->name); + if (a->type == KEY_NAME_PAT) + return match_pattern(b->name, a->name); + else + return match_pattern(a->name, b->name); +} + static u_char* key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) @@ -161,7 +226,7 @@ EVP_MD_CTX ctx; u_char *blob = NULL; u_char *retval = NULL; - int len = 0; + u_int len = 0; int nlen, elen; *dgst_raw_length = 0; @@ -364,11 +429,12 @@ { Key *k; int success = -1; - char *cp, *space; + char *cp, *space, *name_type; int len, n, type; u_int bits; - u_char *blob; + u_char *blob = NULL; + name_type = NULL; cp = *cpp; switch(ret->type) { @@ -391,6 +457,8 @@ case KEY_UNSPEC: case KEY_RSA: case KEY_DSA: + case KEY_NAME: + case KEY_NAME_PAT: space = strchr(cp, ' '); if (space == NULL) { debug3("key_read: no space"); @@ -398,6 +466,19 @@ } *space = '\0'; type = key_type_from_name(cp); + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { + char * colon = NULL; + + colon = strchr(cp, ':'); + + debug3("key_read: reading named%s key", + (type == KEY_NAME) ? "" : " pattern"); + + if (colon != NULL && *(++colon) != '\0') { + name_type = xstrdup(colon); + } else + name_type == NULL; + } *space = ' '; if (type == KEY_UNSPEC) { debug3("key_read: no key found"); @@ -410,31 +491,83 @@ } if (ret->type == KEY_UNSPEC) { ret->type = type; + } else if (ret->type == KEY_NAME && type == KEY_NAME_PAT) { + ret->type = type; } else if (ret->type != type) { /* is a key, but different type */ debug3("key_read: type mismatch"); return -1; } - len = 2*strlen(cp); - blob = xmalloc(len); - n = uudecode(cp, blob, len); - if (n < 0) { - error("key_read: uudecode %s failed", cp); - return -1; + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + char *p, *p1, ch; + + if (cp == NULL || *cp == '\0') + return -1; + + debug3("key_read: reading named key %s", cp); + k = key_new(ret->type); + /* Skip whitespace */ + for ( ; (*cp != '\0') && isspace(*cp) && (*cp != '\n') ; cp++ ) + ; + if (*cp == '"') { + k->name = (unsigned char *) xstrdup(cp+1); + p = k->name; + for ( p1 = cp+1 ; *p1 != '\0' ; p1++ ) { + if (*p1 == '\\') + p1++; + else if (*p1 == '"') + break; + *p++ = *p1; + } + *p = '\0'; + debug3("key_read: quoted key: %s", k->name); + } else { + /* Ignore trailing whitespace */ + for ( p = cp ; *p != '\0' && !isspace(*p) ; p++ ) + ; + ch = *p; + *p = '\0'; + k->name = (unsigned char *) xstrdup(cp); + *p = ch; + debug3("key_read: key: %s", k->name); + } + k->name_type = name_type; + } else { + len = 2*strlen(cp); + blob = xmalloc(len); + n = uudecode(cp, blob, len); + if (n < 0) { + error("key_read: uudecode %s failed", cp); + return -1; + } + k = key_from_blob(blob, n); } - k = key_from_blob(blob, n); if (k == NULL) { error("key_read: key_from_blob %s failed", cp); return -1; } - xfree(blob); + if (blob != NULL) + xfree(blob); if (k->type != type) { - error("key_read: type mismatch: encoding error"); - key_free(k); - return -1; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + error("key_read: type mismatch: encoding error"); + key_free(k); + return -1; + } } /*XXXX*/ - if (ret->type == KEY_RSA) { + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + /* + if (ret->name != NULL) + xfree(ret->name); + */ + ret->name = k->name; + ret->name_type = k->name_type; + k->name = NULL; + k->name_type = NULL; + success = 1; + } else if (ret->type == KEY_RSA) { if (ret->rsa != NULL) RSA_free(ret->rsa); ret->rsa = k->rsa; @@ -488,7 +621,7 @@ } } else if ((key->type == KEY_DSA && key->dsa != NULL) || (key->type == KEY_RSA && key->rsa != NULL)) { - int len, n; + u_int len, n; u_char *blob, *uu; key_to_blob(key, &blob, &len); uu = xmalloc(2*len); @@ -499,6 +632,12 @@ } xfree(blob); xfree(uu); + } else if (key->type == KEY_NAME && key->name != NULL) { + fprintf(f, "%s ", key_ssh_name(key)); + if (key->name_type != NULL) + fprintf(f, ":%s", key->name_type); + else + fprintf(f, " \"%s\"", key->name); } return success; } @@ -515,6 +654,12 @@ case KEY_DSA: return "DSA"; break; + case KEY_NAME: + return "Named"; + break; + case KEY_NAME_PAT: + return "Name_Pattern"; + break; } return "unknown"; } @@ -528,6 +673,12 @@ case KEY_DSA: return "ssh-dss"; break; + case KEY_NAME: + return "ssh-named"; + break; + case KEY_NAME_PAT: + return "ssh-name-pat"; + break; } return "ssh-unknown"; } @@ -605,6 +756,14 @@ BN_copy(n->rsa->n, k->rsa->n); BN_copy(n->rsa->e, k->rsa->e); break; + case KEY_NAME: + case KEY_NAME_PAT: + n = key_new(k->type); + n->name = xstrdup(k->name); + if (k->name_type) { + n->name_type = xstrdup(k->name_type); + } + break; default: fatal("key_from_private: unknown type %d", k->type); break; @@ -625,6 +784,26 @@ return KEY_RSA; } else if (strcmp(name, "ssh-dss") == 0){ return KEY_DSA; + } else if (strcmp(name, "ssh-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-named:", strlen("ssh-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-name-pat:", + strlen("ssh-name-pat:")) == 0){ + return KEY_NAME_PAT; + /* Backwards compatibility for previous named key entry forms at UBSW */ + } else if (strcmp(name, "ssh-ext-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-ext-named:", + strlen("ssh-ext-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-ext-name-pat:", + strlen("ssh-ext-name-pat:")) == 0){ + return KEY_NAME_PAT; } else if (strcmp(name, "null") == 0){ return KEY_NULL; } Index: 3_0_2p1_w_gss.1/auth2.c --- 3_0_2p1_w_gss.1/auth2.c Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth2.c Fri, 18 Jan 2002 12:24:41 -0500 @@ -80,7 +80,7 @@ /* helper */ static Authmethod *authmethod_lookup(const char *); static char *authmethods_get(void); -static int user_key_allowed(struct passwd *, Key *); +int user_key_allowed(struct passwd *, Key *); static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); /* auth */ @@ -499,7 +499,7 @@ buffer_dump(&b); #endif /* test for correct signature */ - if (user_key_allowed(authctxt->pw, key) && + if (user_key_allowed(authctxt->pw, key) > 0 && key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) authenticated = 1; buffer_clear(&b); @@ -516,7 +516,7 @@ * if a user is not allowed to login. is this an * issue? -markus */ - if (user_key_allowed(authctxt->pw, key)) { + if (user_key_allowed(authctxt->pw, key) > 0) { packet_start(SSH2_MSG_USERAUTH_PK_OK); packet_put_string(pkalg, alen); packet_put_string(pkblob, blen); @@ -742,24 +742,31 @@ continue; } } - if (key_equal(found, key) && - auth_parse_options(pw, options, file, linenum) == 1) { - found_key = 1; - debug("matching key found: file %s, line %lu", - file, linenum); - break; + if (key_equal(found, key) || key_match(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key != 0) + break; + auth_clear_options(); } } restore_uid(); fclose(f); key_free(found); - if (!found_key) + if (found_key == 0) debug2("key not found"); + else if (found_key > 0) { + debug("matching key found: file %s, line %lu", + file, linenum); + auth_set_key_env(key); + } else + debug("matching deny key found: file %s, line %lu", + file, linenum); + return found_key; } /* check whether given key is in .ssh/authorized_keys* */ -static int +int user_key_allowed(struct passwd *pw, Key *key) { int success; @@ -768,7 +775,7 @@ file = authorized_keys_file(pw); success = user_key_allowed2(pw, key, file); xfree(file); - if (success) + if (success != 0) return success; /* try suffix "2" for backward compat, too */ Index: 3_0_2p1_w_gss.1/auth-rsa.c --- 3_0_2p1_w_gss.1/auth-rsa.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-rsa.c Fri, 18 Jan 2002 12:24:41 -0500 @@ -232,7 +232,7 @@ * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (auth_parse_options(pw, options, file, linenum) < 1) continue; /* Perform the challenge-response dialog for this key. */ Index: 3_0_2p1_w_gss.1/auth-options.h --- 3_0_2p1_w_gss.1/auth-options.h Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-options.h Fri, 18 Jan 2002 12:24:41 -0500 @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -31,6 +33,8 @@ extern struct envstring *custom_environment; int auth_parse_options(struct passwd *, char *, char *, u_long); +void auth_set_key_env(Key *k); void auth_clear_options(void); + #endif Index: 3_0_2p1_w_gss.1/auth-options.c --- 3_0_2p1_w_gss.1/auth-options.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-options.c Fri, 18 Jan 2002 12:24:41 -0500 @@ -56,8 +56,43 @@ channel_clear_permitted_opens(); } +void auth_set_key_env(Key *k) +{ + struct envstring *new_env; + char *s; + int len; + + if (k->type != KEY_NAME) + return; + + len = strlen("SSH_AUTH_NAME="); + len += strlen(k->name) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_NAME=%s", k->name); + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + if (k->name_type == NULL) + return; + + len = strlen("SSH_AUTH_NAME_TYPE="); + len += strlen(k->name_type) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_NAME_TYPE=%s", k->name_type); + + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + return; +} + /* - * return 1 if access is granted, 0 if not. + * return 1 if access is granted, 0 if not, -1 if access explicitly denied * side effect: sets key option flags */ int @@ -73,6 +108,12 @@ return 1; while (*opts && *opts != ' ' && *opts != '\t') { + cp = "deny-access"; + if (strncasecmp(opts, cp, strlen(cp)) == 0) { + log("Authentication successful, but authorization denied"); + packet_send_debug("Permission denied"); + return -1; + } cp = "no-port-forwarding"; if (strncasecmp(opts, cp, strlen(cp)) == 0) { packet_send_debug("Port forwarding disabled."); Index: 3_0_2p1_w_gss.1/auth-krb4.c --- 3_0_2p1_w_gss.1/auth-krb4.c Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-krb4.c Fri, 18 Jan 2002 14:44:13 -0500 @@ -40,6 +40,7 @@ #ifdef KRB4 extern ServerOptions options; +int user_key_allowed(struct passwd *, Key *); static int krb4_init(void *context) @@ -220,6 +221,7 @@ socklen_t slen; u_int cksum; int r, s; + Key k; s = packet_get_connection_in(); @@ -249,12 +251,27 @@ *adat.pinst ? "." : "", adat.pinst, adat.prealm); /* Check ~/.klogin authorization now. */ - if (kuserok(&adat, authctxt->user) != KSUCCESS) { - log("Kerberos v4 .klogin authorization failed for %s to " - "account %s", *client, authctxt->user); + k.type = KEY_NAME; + k.name = *client; + k.name_type = "krb4"; + + r = user_key_allowed(authctxt->pw, &k); + + if (r < 0) { + log("Kerberos v4 %s authorization failed for %s to " + "account %s", "authorized_keys", *client, authctxt->user); xfree(*client); return (0); } + + if (r == 0 && kuserok(&adat, authctxt->user) != KSUCCESS) { + log("Kerberos v4 %s authorization failed for %s to " + "account %s", (r == 0) ? ".klogin" : "authorized_keys", + *client, authctxt->user); + xfree(*client); + return (0); + } + /* Increment the checksum, and return it encrypted with the session key. */ cksum = adat.checksum + 1; Index: 3_0_2p1_w_gss.1/auth-krb5.c --- 3_0_2p1_w_gss.1/auth-krb5.c Thu, 10 Jan 2002 14:22:14 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-krb5.c Fri, 18 Jan 2002 14:44:54 -0500 @@ -22,6 +22,7 @@ #endif /* !HEIMDAL */ extern ServerOptions options; +int user_key_allowed(struct passwd *, Key *); static int krb5_init(void *context) @@ -55,6 +56,8 @@ krb5_principal server; krb5_data reply; krb5_ticket *ticket; + Key k; + char *client_name; int fd, ret; ret = 0; @@ -110,14 +113,30 @@ if (problem) goto err; + if (!krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, + &client_name)) + goto err; + /* Check .k5login authorization now. */ - if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, - authctxt->pw->pw_name)) + k.type = KEY_NAME; + k.name = client_name; + k.name_type = "krb5"; + + ret = user_key_allowed(authctxt->pw, &k); + if (ret < 0) { + ret = 0; goto err; + } + if (ret == 0 && !krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, + authctxt->pw->pw_name)) { + log("SSHv1 Kerberos v5 %s authorization failed for %s to " + "account %s", (ret == 0) ? ".k5login" : "authorized_keys", + *client, authctxt->user); + goto err; + } if (client) - krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, - client); + *client = client_name; packet_start(SSH_SMSG_AUTH_KERBEROS_RESPONSE); packet_put_string((char *) reply.data, reply.length); Index: 3_0_2p1_w_gss.1/gss-serv.c --- 3_0_2p1_w_gss.1/gss-serv.c Thu, 10 Jan 2002 15:57:24 -0500 +++ 3_0_2p1_w_gss_w_named_keys.14(w)/gss-serv.c Fri, 18 Jan 2002 12:24:41 -0500 @@ -48,6 +48,7 @@ extern ServerOptions options; extern u_char *session_id2; extern int session_id2_len; +int user_key_allowed(struct passwd *, Key *); typedef struct ssh_gssapi_cred_cache { @@ -98,24 +99,39 @@ ssh_gssapi_krb5_userok(char *name) { krb5_principal princ; int retval; + char *by; + Key k; if (ssh_gssapi_krb5_init() == 0) return 0; - + + k.type = KEY_NAME; + k.name = gssapi_client_name.value; + k.name_type = "krb5"; + if ((retval=krb5_parse_name(krb_context, gssapi_client_name.value, &princ))) { log("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context,retval)); return 0; } - if (krb5_kuserok(krb_context, princ, name)) { + + /* Try authorized_keys first */ + by = "authorized_keys"; + retval = user_key_allowed(getpwnam(name), &k); + if (retval < 0) { + debug("ssh_gssapi_krb5_userok: access denied in %s", by); + krb5_free_principal(krb_context, princ); + return 0; + } + if (retval == 0 && krb5_kuserok(krb_context, princ, name)) { + by = "krb5_kuserok"; retval = 1; - log("Authorized to %s, krb5 principal %s (krb5_kuserok)",name, - (char *)gssapi_client_name.value); } - else - retval = 0; + notice("Authorized to %s, krb5 principal %s (%s)", name, + (char *)gssapi_client_name.value, by); + krb5_free_principal(krb_context, princ); return retval; } -------------- next part -------------- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Douglas.Chimento at FMR.COM Fri Jan 25 04:03:06 2002 From: Douglas.Chimento at FMR.COM (Chimento, Douglas) Date: Thu, 24 Jan 2002 12:03:06 -0500 Subject: Configure script Message-ID: Hello, Why does the configure scipt include -I/usr/local/include for CPPFLAGS and -L/usr/local/lib -R/usr/local/lib for LDFLAGS in the Makefile? Is this nesscesary? I take them out for security concerns Thanks Doug From Nicolas.Williams at ubsw.com Fri Jan 25 05:04:23 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 24 Jan 2002 13:04:23 -0500 Subject: Configure script In-Reply-To: ; from Douglas.Chimento@FMR.COM on Thu, Jan 24, 2002 at 12:03:06PM -0500 References: Message-ID: <20020124130421.A27398@sm2p1386swk.wdr.com> I think it's silly. I take that out locally. If there's multiple versions of, say, OpenSSL or, say, MIT or Heimdal krb5, or what have you, then not being in full control over the include and linker paths can lead to unexpected results. Nico On Thu, Jan 24, 2002 at 12:03:06PM -0500, Chimento, Douglas wrote: > Hello, > > Why does the configure scipt include -I/usr/local/include for > CPPFLAGS > and -L/usr/local/lib -R/usr/local/lib for LDFLAGS in the Makefile? > Is this nesscesary? I take them out for security concerns > > Thanks > Doug > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From celinn at mtu.edu Fri Jan 25 05:43:19 2002 From: celinn at mtu.edu (Christopher Linn) Date: Thu, 24 Jan 2002 13:43:19 -0500 Subject: Configure script In-Reply-To: ; from Douglas.Chimento@FMR.COM on Thu, Jan 24, 2002 at 12:03:06PM -0500 References: Message-ID: <20020124134319.A26401@mtu.edu> On Thu, Jan 24, 2002 at 12:03:06PM -0500, Chimento, Douglas wrote: > Hello, > > Why does the configure scipt include -I/usr/local/include for > CPPFLAGS and -L/usr/local/lib -R/usr/local/lib for LDFLAGS in > the Makefile? Is this nesscesary? I take them out for security > concerns bingo. i take this out manually as well, since even if i have nothing in /usr/local that has to do with OpenSSH, it is generated this way by configure. i have simply suspected that It Is A Configure Thing(tm), and wished that there was a --no-usrlocalrefs flag or some such thing.. is it possible to have a --no-usrlocalrefs flag? hmm....... chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From Nicolas.Williams at ubsw.com Fri Jan 25 05:58:40 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 24 Jan 2002 13:58:40 -0500 Subject: Configure script In-Reply-To: <20020124134319.A26401@mtu.edu>; from celinn@mtu.edu on Thu, Jan 24, 2002 at 01:43:19PM -0500 References: <20020124134319.A26401@mtu.edu> Message-ID: <20020124135838.B27398@sm2p1386swk.wdr.com> On Thu, Jan 24, 2002 at 01:43:19PM -0500, Christopher Linn wrote: > On Thu, Jan 24, 2002 at 12:03:06PM -0500, Chimento, Douglas wrote: > > Hello, > > > > Why does the configure scipt include -I/usr/local/include for > > CPPFLAGS and -L/usr/local/lib -R/usr/local/lib for LDFLAGS in > > the Makefile? Is this nesscesary? I take them out for security > > concerns > > bingo. > > i take this out manually as well, since even if i have nothing in > /usr/local that has to do with OpenSSH, it is generated this way by > configure. i have simply suspected that It Is A Configure Thing(tm), > and wished that there was a --no-usrlocalrefs flag or some such thing.. > > is it possible to have a --no-usrlocalrefs flag? hmm....... Just edit configure.ac, autoreconf, and you're set. It just shouldn't be there, really. File a bug report in bugzilla. > chris Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Douglas.Chimento at FMR.COM Fri Jan 25 07:44:34 2002 From: Douglas.Chimento at FMR.COM (Chimento, Douglas) Date: Thu, 24 Jan 2002 15:44:34 -0500 Subject: Configure script Message-ID: Thank you for you help, I will file a bug report -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com] Sent: Thursday, January 24, 2002 1:59 PM To: Christopher Linn Cc: openssh-unix-dev at mindrot.org Subject: Re: Configure script On Thu, Jan 24, 2002 at 01:43:19PM -0500, Christopher Linn wrote: > On Thu, Jan 24, 2002 at 12:03:06PM -0500, Chimento, Douglas wrote: > > Hello, > > > > Why does the configure scipt include -I/usr/local/include for > > CPPFLAGS and -L/usr/local/lib -R/usr/local/lib for LDFLAGS in > > the Makefile? Is this nesscesary? I take them out for security > > concerns > > bingo. > > i take this out manually as well, since even if i have nothing in > /usr/local that has to do with OpenSSH, it is generated this way by > configure. i have simply suspected that It Is A Configure Thing(tm), > and wished that there was a --no-usrlocalrefs flag or some such thing.. > > is it possible to have a --no-usrlocalrefs flag? hmm....... Just edit configure.ac, autoreconf, and you're set. It just shouldn't be there, really. File a bug report in bugzilla. > chris Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Fri Jan 25 08:19:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 25 Jan 2002 08:19:50 +1100 (EST) Subject: [Bug 77] New: Configure Script contains /usr/local/lib /usr/local/include FLAGS Message-ID: <20020124211950.B8458E8EA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=77 Summary: Configure Script contains /usr/local/lib /usr/local/include FLAGS Product: Portable OpenSSH Version: 3.0.2p1 Platform: All OS/Version: Solaris Status: NEW Severity: trivial Priority: P5 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: douglas.chimento at fmr.com configure.ac contains the LDFLAGS and CPPFLAGS enviroment which explicity set to -R/usr/local/lib -L/usr/local/lib and -L/usr/local/include. The user has no option to disable these flag settings. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Higdon.David at cnf.com Fri Jan 25 08:18:34 2002 From: Higdon.David at cnf.com (Higdon, David M - CNF) Date: Thu, 24 Jan 2002 13:18:34 -0800 Subject: v3.0.2 Message-ID: <7B73D5F649D0D311B1E30008C7A4D92A0E3BAA3C@cnfqs029.cnf.prod.cnf.com> I have upgraded my openssh version from 2.2.0.p1 to 3.0.2p1. 3.0.2 was compile on a sunblade 100 running Solaris 8. Is it possible for my to use my existing DSA key? Thanks, David Higdon UNIX System Administrator (503) 450-4800 (Office) (503) 701-5558 (Cell Phone) higdon.david at cnf.com From Higdon.David at cnf.com Fri Jan 25 08:30:48 2002 From: Higdon.David at cnf.com (Higdon, David M - CNF) Date: Thu, 24 Jan 2002 13:30:48 -0800 Subject: v3.0.2 Message-ID: <7B73D5F649D0D311B1E30008C7A4D92A0E3BAA3E@cnfqs029.cnf.prod.cnf.com> Stupid me! I created a new DSA key with the same passphrase thinking that would work! I kept a copy of my old key and it worked no problem! David Higdon UNIX System Administrator (503) 450-4800 (Office) (503) 701-5558 (Cell Phone) higdon.david at cnf.com > -----Original Message----- > From: Higdon, David M - CNF > Sent: Thursday, January 24, 2002 1:19 PM > To: 'openssh-unix-dev at mindrot.org' > Subject: v3.0.2 > > I have upgraded my openssh version from 2.2.0.p1 to 3.0.2p1. 3.0.2 was > compile on a > sunblade 100 running Solaris 8. Is it possible for my to use my existing > DSA key? > > Thanks, > > > > David Higdon > UNIX System Administrator > (503) 450-4800 (Office) > (503) 701-5558 (Cell Phone) > higdon.david at cnf.com > From bugzilla-daemon at mindrot.org Fri Jan 25 10:03:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 25 Jan 2002 10:03:09 +1100 (EST) Subject: [Bug 69] Generalize SSH_ASKPASS Message-ID: <20020124230309.086DEE952@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=69 ------- Additional Comments From djm at mindrot.org 2002-01-25 10:03 ------- Created an attachment (id=12) Adds SSH_ALWAYS_ASKPASS env var and removes check for $DISPLAY ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From siegert at sfu.ca Fri Jan 25 11:15:31 2002 From: siegert at sfu.ca (Martin Siegert) Date: Thu, 24 Jan 2002 16:15:31 -0800 Subject: bug in readconf.c Message-ID: <20020124161531.A27325@stikine.ucs.sfu.ca> Hi, there is a tiny bug in readconf.c: options->use_privileged_port is always set to 0 regardless of whether -P is specified or not. This has the effect that RhostsAuthentication is disabled even if "RhostsAuthentication yes" is specified. The (trivial) patch is appended below. Martin ======================================================================== Martin Siegert Academic Computing Services phone: (604) 291-4691 Simon Fraser University fax: (604) 291-4242 Burnaby, British Columbia email: siegert at sfu.ca Canada V5A 1S6 ======================================================================== --- openssh-3.0.2p1/readconf.c.orig Wed Jan 23 19:44:13 2002 +++ openssh-3.0.2p1/readconf.c Wed Jan 23 19:44:45 2002 @@ -822,7 +822,7 @@ if (options->gateway_ports == -1) options->gateway_ports = 0; if (options->use_privileged_port == -1) - options->use_privileged_port = 0; + options->use_privileged_port = 1; if (options->rhosts_authentication == -1) options->rhosts_authentication = 1; if (options->rsa_authentication == -1) From bugzilla-daemon at mindrot.org Fri Jan 25 11:32:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 25 Jan 2002 11:32:26 +1100 (EST) Subject: [Bug 52] ssh hangs on exit Message-ID: <20020125003226.779C6EAE5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=52 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal OS/Version|Solaris |All Priority|P2 |P3 Platform|UltraSparc |All Version|2.9.9p2 |-current ------- Additional Comments From djm at mindrot.org 2002-01-25 11:32 ------- As has been stated several times on the list - further effort should be aimed at finding out why this "bug" does not manifest on OpenBSD. What aspect of fd semantics differs? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djast at cs.toronto.edu Fri Jan 25 11:27:19 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Thu, 24 Jan 2002 19:27:19 -0500 Subject: bug in readconf.c In-Reply-To: Your message of "Thu, 24 Jan 2002 19:15:31 EST." <20020124161531.A27325@stikine.ucs.sfu.ca> Message-ID: <02Jan24.192722edt.453139-5649@jane.cs.toronto.edu> On Thu, 24 Jan 2002 19:15:31 EST, Martin Siegert writes: > Hi, > > there is a tiny bug in readconf.c: options->use_privileged_port is always > set to 0 regardless of whether -P is specified or not. This has the effect > that RhostsAuthentication is disabled even if "RhostsAuthentication yes" > is specified. I don't believe that's a bug. The documented default for UsePrivilegedPort is 'no', which is what readconf.c does. This default has changed from previous releases. Try using "-o UsePrivilegedPort=yes" to turn it on. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From siegert at sfu.ca Fri Jan 25 12:31:59 2002 From: siegert at sfu.ca (Martin Siegert) Date: Thu, 24 Jan 2002 17:31:59 -0800 Subject: bug in readconf.c In-Reply-To: <02Jan24.192722edt.453139-5649@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Thu, Jan 24, 2002 at 07:27:19PM -0500 References: <20020124161531.A27325@stikine.ucs.sfu.ca> <02Jan24.192722edt.453139-5649@jane.cs.toronto.edu> Message-ID: <20020124173159.A27345@stikine.ucs.sfu.ca> On Thu, Jan 24, 2002 at 07:27:19PM -0500, Dan Astoorian wrote: > On Thu, 24 Jan 2002 19:15:31 EST, Martin Siegert writes: > > > > there is a tiny bug in readconf.c: options->use_privileged_port is always > > set to 0 regardless of whether -P is specified or not. This has the effect > > that RhostsAuthentication is disabled even if "RhostsAuthentication yes" > > is specified. > > I don't believe that's a bug. > > The documented default for UsePrivilegedPort is 'no', which is what > readconf.c does. This default has changed from previous releases. > > Try using "-o UsePrivilegedPort=yes" to turn it on. Yes, you are right this works. Ignore my message. (I got confused by the -P option: if there is only an option to switch UsePrivilegedPort off, then the default must be on - wrong as you pointed out). Sorry for bugging you. Martin ======================================================================== Martin Siegert Academic Computing Services phone: (604) 291-4691 Simon Fraser University fax: (604) 291-4242 Burnaby, British Columbia email: siegert at sfu.ca Canada V5A 1S6 ======================================================================== From bugzilla-daemon at mindrot.org Fri Jan 25 13:27:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 25 Jan 2002 13:27:57 +1100 (EST) Subject: [Bug 78] New: Support use of named (krb4, krb5, gsi, x.509) keys in auth_keys entries Message-ID: <20020125022757.549ABE917@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=78 Summary: Support use of named (krb4, krb5, gsi, x.509) keys in auth_keys entries Product: Portable OpenSSH Version: 3.0.2p1 Platform: All URL: http://marc.theaimsgroup.com/?l=openssh-unix- dev&m=101189381805982&w=2 OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams at ubsw.com CC: openssh-unix-dev at mindrot.org This patch adds support for entries in authorized_keys which reference Kerberos principal names, GSI/X.509 certificate names when doing Kerberos or GSS authentication. Also included is support for authorized_keys entries which are patterns matching such names. Also included is support for a new authorized_keys entry option, "deny-access." With this patch sshd also sets environment variables to indicate the client's authenticated name, if a named authorized_keys entry matches. These simple features simplify key management and authorized_keys file management in environments where Kerberos or GSI are in use with OpenSSH (see Simon Wilkinson's patch to OpenSSH that implements the gsskeyex draft). These features represent a much more general authorization system for Kerberos than .klogin or .k5login, and apply to other authentication mechanisms as well (again, GSI/X.509, and, in the future, when direct X.509 support is added to OpenSSH, x.509). These features, or a variation thereof, in OpenSSH, would be greatly appreciated. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. From markus at openbsd.org Fri Jan 25 20:32:13 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Jan 2002 10:32:13 +0100 Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020122172237.R27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Jan 22, 2002 at 05:22:39PM -0500 References: <200201221849.KAA14786@tardy.cup.hp.com> <20020122135951.M27398@sm2p1386swk.wdr.com> <3C4DBF92.B4AD9F70@hp.com> <20020122145544.N27398@sm2p1386swk.wdr.com> <3C4DD122.59AEA8DE@hp.com> <20020122161018.O27398@sm2p1386swk.wdr.com> <3C4DD782.6CAC8E48@hp.com> <20020122163430.P27398@sm2p1386swk.wdr.com> <3C4DDF71.4DC200D9@hp.com> <20020122172237.R27398@sm2p1386swk.wdr.com> Message-ID: <20020125103213.C28091@folly> On Tue, Jan 22, 2002 at 05:22:39PM -0500, Nicolas Williams wrote: > On Tue, Jan 22, 2002 at 01:53:53PM -0800, Rick Jones wrote: > > > > > The latter. > > > > Then port forwarding trumps. > > Ok. OpenSSH team? :) ? > OpenSSH Team: why is Nagle turned off only for interactive sessions? history, inherited from ssh-1.2.12 > OpenSSH Team: what are your objections to reverse the current situation, > with respect to Nagle, or even just turning it off altogether? if you research why ssh-1.2.12 does it this way. > Should Nagle-at-the-SSH-layer be advocated at the IETF SECSH working > group? ask them. From markus at openbsd.org Fri Jan 25 20:08:29 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Jan 2002 10:08:29 +0100 Subject: ssh-keyscan: xmalloc out of memory error In-Reply-To: <20020122041527.17376.qmail@web14506.mail.yahoo.com>; from datqtruong@yahoo.com on Mon, Jan 21, 2002 at 08:15:27PM -0800 References: <20020122041527.17376.qmail@web14506.mail.yahoo.com> Message-ID: <20020125100829.A28091@folly> fix in current: Index: ssh-keyscan.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh-keyscan.c,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- ssh-keyscan.c 22 Nov 2001 05:27:29 -0000 1.32 +++ ssh-keyscan.c 10 Dec 2001 20:34:31 -0000 1.33 @@ -7,7 +7,7 @@ */ #include "includes.h" -RCSID("$OpenBSD: ssh-keyscan.c,v 1.32 2001/11/22 05:27:29 stevesk Exp $"); +RCSID("$OpenBSD: ssh-keyscan.c,v 1.33 2001/12/10 20:34:31 markus Exp $"); #include #include @@ -469,8 +469,9 @@ congreet(int s) { char buf[256], *cp; + char remote_version[sizeof buf]; size_t bufsiz; - int n = 0; + int remote_major, remote_minor, n = 0; con *c = &fdcon[s]; bufsiz = sizeof(buf); @@ -492,20 +493,21 @@ return; } *cp = '\0'; + if (sscanf(buf, "SSH-%d.%d-%[^\n]\n", + &remote_major, &remote_minor, remote_version) == 3) + compat_datafellows(remote_version); + else + datafellows = 0; if (c->c_keytype != KT_RSA1) { - int remote_major, remote_minor; - char remote_version[sizeof buf]; - - if (sscanf(buf, "SSH-%d.%d-%[^\n]\n", - &remote_major, &remote_minor, remote_version) == 3) - compat_datafellows(remote_version); - else - datafellows = 0; if (!ssh2_capable(remote_major, remote_minor)) { debug("%s doesn't support ssh2", c->c_name); confree(s); return; } + } else if (remote_major != 1) { + debug("%s doesn't support ssh1", c->c_name); + confree(s); + return; } fprintf(stderr, "# %s %s\n", c->c_name, chop(buf)); n = snprintf(buf, sizeof buf, "SSH-%d.%d-OpenSSH-keyscan\r\n", From dan at doxpara.com Fri Jan 25 21:23:09 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 25 Jan 2002 02:23:09 -0800 Subject: Improving Upgrade Success Rate for OpenSSH References: <019701c1a488$b2d2ee00$5001000a@effugas> <20020124051811.GF3302@ifokr.org> Message-ID: <026c01c1a58a$49757970$5001000a@effugas> Brian-- Hmmm? My administrative process? *maniacal grin* === Dan at EFFUGAS ~ $ ssh -o ProxyCommand="ssh root@%h /root/openssh/sshd -i" effugas at 10.0.1.11 root at 10.0.1.11's password: effugas at 10.0.1.11's password: FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ === But that's besides the point. What I can do for myself is one thing, but it doesn't do a whit of good when I'm connecting to other people's servers. The more they screw up, the more I have to assume there hasn't been a MITM. And I have to make that assumption pretty regularly; sure, we've been using SSH since before it was cool, but they haven't. It's more than unproductive for me to just whine about other people not knowing some shibboleth to render SSH functional with previous keys intact; it's poor administrative process. Patching SSH is a very roundabout way of me administering other people's machines. The easier it is for others to upgrade successfully, the more likely they will, and the safer I'll be. Beyond key fade, older versions of SSH are to no small degree the thunderclouds rumbling in our collective future, and doing even small things to alleviate that makes me sleep easier. I'm really thinking now about a small check during ./configure that would compare the keys to be loaded by the compiled SSHD against whichever keys were being hosted on 127.0.0.1:22. Configure wouldn't necessarily fail, but it might end with: WARNING: This build of the SSH server will serve a different set of server identity keys than the server presently deployed on this host. This will cause clients to be unable to recognize this host, and force them to take a "leap of faith" that they are still legitimately connecting to your server rather than a "man in the middle". The more used to these leaps your users are, the less security there will be in your identity keys at all. To continue using the present keys, you may want to try adding --sysconfdir="/path" to your invocation of configure, replacing "path" with the location of the keys presently being served(most likely, /etc or /etc/ssh). ...only possibly a bit less verbose. This has the huge advantage of not requiring prior knowledge of --with-upgrade to prevent a key fade. As for MD5 passwords...well, that codebase needs to be taken out of preprocessor hell, if I remember correctly. If password type was contained within sshd_config, and all possible auth_passwd methods were just compiled in, the system password type would persist from build to build in the config and wouldn't otherwise pollute the rebuilding process. Is there any reasonable, cross platform way of determining the master SSHD's PID from a child subshell? --Dan From markus at openbsd.org Fri Jan 25 20:22:53 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Jan 2002 10:22:53 +0100 Subject: [Bug 75] Error compiling in ssh-agent.c (fwd) In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Jan 23, 2002 at 12:34:41AM -0600 References: Message-ID: <20020125102253.B28091@folly> On Wed, Jan 23, 2002 at 12:34:41AM -0600, mouring at etoh.eviladmin.org wrote: > -# define atexit(a) on_exit(a, NULL) > +# define atexit(a, NULL) on_exit(a, NULL) i'd rather use the fatal_cleanup API in ssh-agent, too. From markus at openbsd.org Sat Jan 26 00:48:18 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Jan 2002 14:48:18 +0100 Subject: ssh 2 for SCO open server In-Reply-To: References: Message-ID: <20020125134818.GB10403@faui02> On Fri, Jan 25, 2002 at 08:25:36AM -0500, Heidi Pugliese wrote: > We have a server running SCO Openserver 5.0.6 and SSH1. Our vendor tells > me there isn't an ssh2 version available for SCO and I have been unable to > find one myself. Does anyone have advice on if there is a port and where > I might find it? openssh should run on SCO: http://www.openssh.com/portable.html -m From tr_jsa at hotmail.com Sat Jan 26 01:40:31 2002 From: tr_jsa at hotmail.com (Joel K) Date: Fri, 25 Jan 2002 09:40:31 -0500 Subject: Generating custom public/private keys Message-ID: This may not be the run of the mill, but does anyone have any idea how to create keys that will work with the text I want in them. The reason I'd like to do this is that if a computer on the network has to be replaced due to a fault on it, I'd like to be able to just put the new key on the box without having to regenerate using ssh-keygen the keys for the entire network it is on. Basically I'd like to make the keys set, instead of random. Thanks, Tony _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From mstone at cs.loyola.edu Sat Jan 26 01:41:09 2002 From: mstone at cs.loyola.edu (Michael Stone) Date: Fri, 25 Jan 2002 09:41:09 -0500 Subject: X.509 support in ssh (revisited) In-Reply-To: <00c801c1a465$574e83a0$5001000a@effugas>; from dan@doxpara.com on Wed, Jan 23, 2002 at 03:26:10PM -0800 References: <20020123164246.GD5255@faui02> <20020123183954.GB21895@faui02> <00c801c1a465$574e83a0$5001000a@effugas> Message-ID: <20020125094109.Q19778@justice.loyola.edu> On Wed, Jan 23, 2002 at 03:26:10PM -0800, Dan Kaminsky wrote: > We really need a ./configure --with-upgrade to set all paths correctly such > that this occurs more then one out of a hundred times. If you look at the config.log from the last version, it'll show you the flags used to configure... -- Mike Stone From Jason.Lacoss-Arnold at AGEDWARDS.com Sat Jan 26 02:36:44 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Fri, 25 Jan 2002 09:36:44 -0600 Subject: Improving Upgrade Success Rate for OpenSSH Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4BF@hqempn06.agedwards.com> While this may have some benefit, if you worried about busineses at all, you may get more benefit by working on the Solaris packaging scripts and HP depot scripts that I think I saw on a TODO list in the code. My rational is this: most businesses of any size at all don't compile ssh on every server that they deploy it to (and in fact rarely have compilers on a lot of them). Instead, we build and package it on one server, then deploy it to a few hundred others. One thing that we've been careful to do in building our package is to put the keys in a location that won't be deleted when the package is removed (i.e. for an upgrade) and also check during package install to see if the keys have been left in one of the places where we tend to leave old keys (due to poor standards during previous roll-outs). Anyway, it's a thought. -----Original Message----- From: Dan Kaminsky To: Brian Hatch Cc: Damien Miller; secureshell at securityfocus.com; openssh-unix-dev at mindrot.org Sent: 1/25/02 4:23 AM Subject: Improving Upgrade Success Rate for OpenSSH Brian-- Hmmm? My administrative process? *maniacal grin* === Dan at EFFUGAS ~ $ ssh -o ProxyCommand="ssh root@%h /root/openssh/sshd -i" effugas at 10.0.1.11 root at 10.0.1.11's password: effugas at 10.0.1.11's password: FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $ === But that's besides the point. What I can do for myself is one thing, but it doesn't do a whit of good when I'm connecting to other people's servers. The more they screw up, the more I have to assume there hasn't been a MITM. And I have to make that assumption pretty regularly; sure, we've been using SSH since before it was cool, but they haven't. It's more than unproductive for me to just whine about other people not knowing some shibboleth to render SSH functional with previous keys intact; it's poor administrative process. Patching SSH is a very roundabout way of me administering other people's machines. The easier it is for others to upgrade successfully, the more likely they will, and the safer I'll be. Beyond key fade, older versions of SSH are to no small degree the thunderclouds rumbling in our collective future, and doing even small things to alleviate that makes me sleep easier. I'm really thinking now about a small check during ./configure that would compare the keys to be loaded by the compiled SSHD against whichever keys were being hosted on 127.0.0.1:22. Configure wouldn't necessarily fail, but it might end with: WARNING: This build of the SSH server will serve a different set of server identity keys than the server presently deployed on this host. This will cause clients to be unable to recognize this host, and force them to take a "leap of faith" that they are still legitimately connecting to your server rather than a "man in the middle". The more used to these leaps your users are, the less security there will be in your identity keys at all. To continue using the present keys, you may want to try adding --sysconfdir="/path" to your invocation of configure, replacing "path" with the location of the keys presently being served(most likely, /etc or /etc/ssh). ...only possibly a bit less verbose. This has the huge advantage of not requiring prior knowledge of --with-upgrade to prevent a key fade. As for MD5 passwords...well, that codebase needs to be taken out of preprocessor hell, if I remember correctly. If password type was contained within sshd_config, and all possible auth_passwd methods were just compiled in, the system password type would persist from build to build in the config and wouldn't otherwise pollute the rebuilding process. Is there any reasonable, cross platform way of determining the master SSHD's PID from a child subshell? --Dan _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020125/00d761f2/attachment.html From openssh-unix-dev at thewrittenword.com Sat Jan 26 02:53:39 2002 From: openssh-unix-dev at thewrittenword.com (Albert Chin) Date: Fri, 25 Jan 2002 09:53:39 -0600 Subject: Solaris PAM: Cannot delete credentials In-Reply-To: <200111221152.MAA23052@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Thu, Nov 22, 2001 at 12:52:31PM +0100 References: <200111221152.MAA23052@marc.physik3.gwdg.de> Message-ID: <20020125095339.B77961@oolong.il.thewrittenword.com> On Thu, Nov 22, 2001 at 12:52:31PM +0100, Hans Werner Strube wrote: > > As has been reported several times, openssh with PAM in Solaris gives > > a debug message on logout: Cannot delete credentials. > > Here is a patch for auth-pam.c (possibly Solaris-specific). > > The line numbers hold at least for 2.9.9p2 through 3.0.1p1. > > Note that seteuid() is not sufficient, one must use setuid(). > > It would be more efficient to save the uid of the session and pass it, > > in order to avoid pam_get_item() and getpwnam(), but this would me a > > major change. > > Here is the "major change", involving auth-pam.c, auth-pam.h, session.c. > The change of the first argument of do_pam_session() is possible, because > this argument has not been used in the original version. > Please treat with caution, since I have no actual overview over the > global interdependence and calling sequence of the functions in sshd. > But it worked for a login connection as well as a tty-less connection in > Solaris 7, without yielding the debug message "Cannot delete credentials." Has anyone tried this? We tried it against 3.0.2p1 on Solaris 8 with 111659-05 installed and get: ... Warning: Your password has expired, please change it now Enter login password: [blah] Could not unset your secret key(s). Maybe the keyserver is down? -- albert chin (china at thewrittenword.com) From secureshell at ifokr.org Sat Jan 26 04:03:25 2002 From: secureshell at ifokr.org (Brian Hatch) Date: Fri, 25 Jan 2002 09:03:25 -0800 Subject: Generating custom public/private keys In-Reply-To: References: Message-ID: <20020125170325.GO3302@ifokr.org> > This may not be the run of the mill, but does anyone have any idea how to > create keys that will work with the text I want in them. The reason I'd > like to do this is that if a computer on the network has to be replaced due > to a fault on it, I'd like to be able to just put the new key on the box > without having to regenerate using ssh-keygen the keys for the entire > network it is on. Basically I'd like to make the keys set, instead of > random. If a single machine dies, you need to bring in new hardware or reinstall as appropriate. Then copy the old version of the server keys (/etc/ssh_host_key* or /etc/ssh/ssh_host_key*) from your backups. No need to change anything on the network, the host key won't have changed from the appearance of the clients, etc. If the machine died because it was rooted, then I'd definately *NOT* use old keys, you should generate new ones. -- Brian Hatch Quantum Mechanics: Systems and The dreams stuff Security Engineer is made of. http://www.ifokr.org/bri/ Every message PGP signed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020125/1a5c48d8/attachment.bin From Nicolas.Williams at ubsw.com Sat Jan 26 04:07:56 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 25 Jan 2002 12:07:56 -0500 Subject: suggested fix for the sigchld race In-Reply-To: <20011031174201.A5564@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 31, 2001 at 05:42:01PM +0100 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> Message-ID: <20020125120754.C27398@sm2p1386swk.wdr.com> On Wed, Oct 31, 2001 at 05:42:01PM +0100, Markus Friedl wrote: > comments? Works. The SIGCHLD/select() race is still present in 3.0.2p1. This patch should be applied. The patch applies cleanly but for the bit that patches the signal handler - the change from signal(...) to mysignal() confuses patch. > alternatives: sigsetjmp(ugly) and pselect(not portable, available) > drawback: additional filedescriptors. sigsetjmp() is not ugly (this is the sort of problem it's meant to be there for). But it's not as elegant as the pipe trick and probably much less portable. I prefer the the pipe trick. I've never used pselect(). So I second the use of the pipe trick to prevent the SIGCHLD/select() race condition. I'll file a bug report. Thanks! Cheers, Nico > Index: serverloop.c > =================================================================== > RCS file: /home/markus/cvs/ssh/serverloop.c,v > retrieving revision 1.82 > diff -u -r1.82 serverloop.c > --- serverloop.c 10 Oct 2001 22:18:47 -0000 1.82 > +++ serverloop.c 11 Oct 2001 18:06:33 -0000 > @@ -92,6 +92,45 @@ > /* prototypes */ > static void server_init_dispatch(void); > > +/* > + * we write to this pipe if a SIGCHLD is caught in order to avoid > + * the race between select() and child_terminated > + */ > +static int notify_pipe[2]; > +static void > +notify_setup(void) > +{ > + if (pipe(notify_pipe) < 0) { > + error("pipe(notify_pipe) failed %s", strerror(errno)); > + notify_pipe[0] = -1; /* read end */ > + notify_pipe[1] = -1; /* write end */ > + } else { > + set_nonblock(notify_pipe[0]); > + set_nonblock(notify_pipe[1]); > + } > +} > +static void > +notify_parent(void) > +{ > + if (notify_pipe[1] != -1) > + write(notify_pipe[1], "", 1); > +} > +static void > +notify_prepare(fd_set *readset) > +{ > + if (notify_pipe[0] != -1) > + FD_SET(notify_pipe[0], readset); > +} > +static void > +notify_done(fd_set *readset) > +{ > + char c; > + > + if (notify_pipe[0] != -1 && FD_ISSET(notify_pipe[0], readset)) > + while (read(notify_pipe[0], &c, 1) != -1) > + debug2("notify_done: reading"); > +} > + > static void > sigchld_handler(int sig) > { > @@ -99,6 +138,7 @@ > debug("Received SIGCHLD."); > child_terminated = 1; > signal(SIGCHLD, sigchld_handler); > + notify_parent(); > errno = save_errno; > } > > @@ -242,6 +282,7 @@ > if (fdin != -1 && buffer_len(&stdin_buffer) > 0) > FD_SET(fdin, *writesetp); > } > + notify_prepare(*readsetp); > > /* > * If we have buffered packet data going to the client, mark that > @@ -278,6 +319,8 @@ > error("select: %.100s", strerror(errno)); > } else if (ret == 0 && client_alive_scheduled) > client_alive_check(); > + > + notify_done(*readsetp); > } > > /* > @@ -467,6 +510,8 @@ > connection_in = packet_get_connection_in(); > connection_out = packet_get_connection_out(); > > + notify_setup(); > + > previous_stdout_buffer_bytes = 0; > > /* Set approximate I/O buffer size. */ > @@ -572,6 +617,7 @@ > max_fd = MAX(max_fd, fdin); > max_fd = MAX(max_fd, fdout); > max_fd = MAX(max_fd, fderr); > + max_fd = MAX(max_fd, notify_pipe[0]); > > /* Sleep in select() until we can do something. */ > wait_until_can_do_something(&readset, &writeset, &max_fd, > @@ -696,7 +742,11 @@ > connection_in = packet_get_connection_in(); > connection_out = packet_get_connection_out(); > > + notify_setup(); > + > max_fd = MAX(connection_in, connection_out); > + max_fd = MAX(max_fd, notify_pipe[0]); > + > xxx_authctxt = authctxt; > > server_init_dispatch(); -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Sat Jan 26 04:13:14 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Jan 2002 18:13:14 +0100 Subject: suggested fix for the sigchld race In-Reply-To: <20020125120754.C27398@sm2p1386swk.wdr.com> References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> <20020125120754.C27398@sm2p1386swk.wdr.com> Message-ID: <20020125171314.GA19665@faui02> On Fri, Jan 25, 2002 at 12:07:56PM -0500, Nicolas Williams wrote: > On Wed, Oct 31, 2001 at 05:42:01PM +0100, Markus Friedl wrote: > > comments? > > Works. The SIGCHLD/select() race is still present in 3.0.2p1. This > patch should be applied. wow! finally feedback on this. please check current snapshots, it's already beed added. > sigsetjmp() is not ugly (this is the sort of problem it's meant to be > there for). But it's not as elegant as the pipe trick and probably much > less portable. I prefer the the pipe trick. sigsetjmp() is ugly as hell. think about correctly releasing resources. > So I second the use of the pipe trick to prevent the SIGCHLD/select() > race condition. > > I'll file a bug report. what bug report? From bugzilla-daemon at mindrot.org Sat Jan 26 04:30:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 04:30:24 +1100 (EST) Subject: [Bug 79] New: A race with select() in SIGCHLD handling causes hangs occasionally Message-ID: <20020125173024.59C6DEB6C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=79 Summary: A race with select() in SIGCHLD handling causes hangs occasionally Product: Portable OpenSSH Version: 3.0.2p1 Platform: All URL: http://marc.theaimsgroup.com/?l=openssh-unix- dev&m=100454673601558&w=2 OS/Version: All Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams at ubsw.com CC: openssh-unix-dev at mindrot.org There's a race condition in OpenSSH (all versions - haven't checked -current) such that if SIGCHLD arrives after the check for child_terminated, but before entering select() (with no timeout) AND if the session's pty/pipes have received EOF before SIGCHLD is handled, then sshd will block in select() forever, while the client hangs waiting for the session-exit message that will never arrive (because sshd will never send it, because it's blocking in select()). Markus Friedl posted a fix for it (see URL associated with this bug report). It works. It should be applied. Thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. From Nicolas.Williams at ubsw.com Sat Jan 26 04:29:37 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 25 Jan 2002 12:29:37 -0500 Subject: suggested fix for the sigchld race In-Reply-To: <20020125171314.GA19665@faui02>; from markus@openbsd.org on Fri, Jan 25, 2002 at 06:13:14PM +0100 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> <20020125120754.C27398@sm2p1386swk.wdr.com> <20020125171314.GA19665@faui02> Message-ID: <20020125122935.D27398@sm2p1386swk.wdr.com> On Fri, Jan 25, 2002 at 06:13:14PM +0100, Markus Friedl wrote: > On Fri, Jan 25, 2002 at 12:07:56PM -0500, Nicolas Williams wrote: > > On Wed, Oct 31, 2001 at 05:42:01PM +0100, Markus Friedl wrote: > > > comments? > > > > Works. The SIGCHLD/select() race is still present in 3.0.2p1. This > > patch should be applied. > > wow! finally feedback on this. please check current snapshots, > it's already beed added. Sorry for the delay. I'd like to play with releases of and patches to OpenSSH and other opensource stuff as they come out. But I can't always. > > sigsetjmp() is not ugly (this is the sort of problem it's meant to be > > there for). But it's not as elegant as the pipe trick and probably much > > less portable. I prefer the the pipe trick. > > sigsetjmp() is ugly as hell. think about correctly releasing resources. Whatever - I'm not advocating it :) > > So I second the use of the pipe trick to prevent the SIGCHLD/select() > > race condition. > > > > I'll file a bug report. > > what bug report? Bug 79 on http://bugzilla.mindrot.org/ :) Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From bugzilla-daemon at mindrot.org Sat Jan 26 04:49:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 04:49:18 +1100 (EST) Subject: [Bug 79] A race with select() in SIGCHLD handling causes hangs occasionally Message-ID: <20020125174918.E797BEB7B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=79 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-01-26 04:49 ------- fixed in current: Markus Friedl commited this patch ages ago (last year) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. From bugzilla-daemon at mindrot.org Sat Jan 26 04:59:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 04:59:46 +1100 (EST) Subject: [Bug 80] New: Host key conflict with two servers on one IP Message-ID: <20020125175946.C43DFEB7E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 Summary: Host key conflict with two servers on one IP Product: Portable OpenSSH Version: 3.0p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: pc-mindrot at crowcastle.net I'm having a problem running two separate instances of sshd on different ports. The two instances of sshd have their own host keys. Unfortunately, the ssh clients seem to associate the host keys based only on the host, not the host and port. [Why would any sane person do what I've described? Well, the truth is that I'm connecting to a different machine through a firewall using port forwarding.] As a work-around, I copied the host keys in /etc/sshd from one machine to the other and restarted sshd, so now both hosts have the same key. Now I'm hoping that doesn't cause any problems. ------- 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 Jan 26 05:06:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 05:06:47 +1100 (EST) Subject: [Bug 81] New: ssh cannot use ssh-askspass & passphrases as documented Message-ID: <20020125180647.CC2DBEB84@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=81 Summary: ssh cannot use ssh-askspass & passphrases as documented Product: Portable OpenSSH Version: 3.0.2p1 Platform: Sparc OS/Version: SunOS Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dean.r.smart at mail.sprint.com When using scp|ssh in nohup|cron|batch in a non interactive mode, sshconnect1.c and sshconnect2.c do not have the ability to call read_passphrase in such a manner to cause ssh-askpass to be utilized as documented in the man pages. The calls are as follows for the released code: # grep 'read_passphrase(' sshconnect[12].c-original sshconnect1.c-original: passphrase = read_passphrase(buf, 0); sshconnect1.c-original: response = read_passphrase(prompt, 0); sshconnect1.c-original: password = read_passphrase(prompt, 0); sshconnect2.c-original: password = read_passphrase(prompt, 0); sshconnect2.c-original: passphrase = read_passphrase(prompt, 0); sshconnect2.c-original: response = read_passphrase(prompt, echo ? RP_ECHO : 0); (white space adjusted above) Note that the second arguments are all set to zero. To make ssh work as documented one call in each of the two sshconnect[12].c source files must be altered to have the enabling second argument as below: # grep 'read_passphrase(' sshconnect[12].c sshconnect1.c: passphrase = read_passphrase(buf, RP_ALLOW_STDIN); sshconnect1.c: response = read_passphrase(prompt, 0); sshconnect1.c: password = read_passphrase(prompt, 0); sshconnect2.c: password = read_passphrase(prompt, 0); sshconnect2.c: passphrase = read_passphrase(prompt, RP_ALLOW_STDIN); sshconnect2.c: response = read_passphrase(prompt, echo ? RP_ECHO : 0); With this one single change to each of the sshconnect[12].c source files, ssh will work as documented. Note the RP_ALLOW_STDIN constant. This has been tested with protocols 1 and 2. Note how the call is structured with ssh-add.c # grep 'read_passphrase(' ssh-add.c pass = read_passphrase(msg, RP_ALLOW_STDIN); (I am using a self-decrypting binary* for ssh-askpass which authenticates the calling self-decrypting binary* which calls scp and ssh. This authentification is done via a number of environmental variables. After scp completes, these authentificating environmetal variables are immediately unset. So this is quite secure and ssh-askpass will not yield the passphrase to any non autheticated invoking process. The use of ssh-agent and ssh-add are quite unsuitable for my requirements, and would otherwise not be secure. These measures may seem excessive but are neccesary to overcome the security risks involved in more basic cron'd ssh-askpass implementations. I do-not/can-not assume a trust relationship with root on the any systems where my applications are run.) * - these two self-decrypting binaries can be the same binary - FreeEss is being used to create the self decrypting binaries ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From datqtruong at yahoo.com Sat Jan 26 05:05:22 2002 From: datqtruong at yahoo.com (dat truong) Date: Fri, 25 Jan 2002 10:05:22 -0800 (PST) Subject: ssh-keyscan: xmalloc out of memory error In-Reply-To: <20020125100829.A28091@folly> Message-ID: <20020125180522.13177.qmail@web14507.mail.yahoo.com> Thanks Markus. -Dat --- Markus Friedl wrote: > fix in current: > > > Index: ssh-keyscan.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh-keyscan.c,v > retrieving revision 1.32 > retrieving revision 1.33 > diff -u -r1.32 -r1.33 > --- ssh-keyscan.c 22 Nov 2001 05:27:29 -0000 1.32 > +++ ssh-keyscan.c 10 Dec 2001 20:34:31 -0000 1.33 > @@ -7,7 +7,7 @@ > */ > > #include "includes.h" > -RCSID("$OpenBSD: ssh-keyscan.c,v 1.32 2001/11/22 > 05:27:29 stevesk Exp $"); > +RCSID("$OpenBSD: ssh-keyscan.c,v 1.33 2001/12/10 > 20:34:31 markus Exp $"); > > #include > #include > @@ -469,8 +469,9 @@ > congreet(int s) > { > char buf[256], *cp; > + char remote_version[sizeof buf]; > size_t bufsiz; > - int n = 0; > + int remote_major, remote_minor, n = 0; > con *c = &fdcon[s]; > > bufsiz = sizeof(buf); > @@ -492,20 +493,21 @@ > return; > } > *cp = '\0'; > + if (sscanf(buf, "SSH-%d.%d-%[^\n]\n", > + &remote_major, &remote_minor, remote_version) > == 3) > + compat_datafellows(remote_version); > + else > + datafellows = 0; > if (c->c_keytype != KT_RSA1) { > - int remote_major, remote_minor; > - char remote_version[sizeof buf]; > - > - if (sscanf(buf, "SSH-%d.%d-%[^\n]\n", > - &remote_major, &remote_minor, remote_version) > == 3) > - compat_datafellows(remote_version); > - else > - datafellows = 0; > if (!ssh2_capable(remote_major, remote_minor)) { > debug("%s doesn't support ssh2", c->c_name); > confree(s); > return; > } > + } else if (remote_major != 1) { > + debug("%s doesn't support ssh1", c->c_name); > + confree(s); > + return; > } > fprintf(stderr, "# %s %s\n", c->c_name, > chop(buf)); > n = snprintf(buf, sizeof buf, > "SSH-%d.%d-OpenSSH-keyscan\r\n", > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > secureshell-unsubscribe at securityfocus.com > For additional commands, e-mail: > secureshell-help at securityfocus.com > __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From dan at doxpara.com Sat Jan 26 07:15:24 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 25 Jan 2002 12:15:24 -0800 Subject: X.509 support in ssh (revisited) References: <20020123164246.GD5255@faui02> <20020123183954.GB21895@faui02> <00c801c1a465$574e83a0$5001000a@effugas> <20020125094109.Q19778@justice.loyola.edu> Message-ID: <02e001c1a5dd$05c53410$5001000a@effugas> > > We really need a ./configure --with-upgrade to set all paths correctly such > > that this occurs more then one out of a hundred times. > > If you look at the config.log from the last version, it'll show you the > flags used to configure... If I had the config.log from previous builds -- which I may or may not have even built myself -- this could be useful. I'm wondering about embedding this information in sshd itself as a #define ... maybe have the ability to do something like: ./configure `/usr/sbin/sshd --configure` to clone the original configuration options. Mind you, much of what's in ./configure now should be defined at runtime in sshd_config -- but I'm being pragmatic here. We're not eliminating all compile time variations, but maybe we can make them persist from compile to compile without requiring an auxillary log or gooja search. Thoughts? --Dan From bugzilla-daemon at mindrot.org Sat Jan 26 09:04:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 09:04:54 +1100 (EST) Subject: [Bug 82] New: scp: Command not found errors Message-ID: <20020125220454.7828EE95B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=82 Summary: scp: Command not found errors Product: Portable OpenSSH Version: -current Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: steve_dum at mentor.com First, the FAQ discussion item 3.7 is out of date and needs updated. the 'scp: Command not found' errors seem to typically get generated because the default search path doesn't include /usr/local/bin which is where scp is located. It is fixed by adding /usr/local/bin to one's login setup scripts. Next, the configure --with-default-path suggestion is a bum steer. The option --with-default-path no longer effects the makefiles, header files or source code. It did in Version 1.x but certianly its gone from 3.x and later 2.x's. This option should be removed from configure, since it's no longer used. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From cmadams at hiwaay.net Sat Jan 26 09:06:30 2002 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Jan 2002 16:06:30 -0600 Subject: [Bug 82] New: scp: Command not found errors In-Reply-To: <20020125220454.7828EE95B@shitei.mindrot.org> References: <20020125220454.7828EE95B@shitei.mindrot.org> Message-ID: <20020125220630.GD29979@HiWAAY.net> Once upon a time, bugzilla-daemon at mindrot.org said: > Next, the configure --with-default-path suggestion is a bum steer. The > option --with-default-path no longer effects the makefiles, header files or > source code. It did in Version 1.x but certianly its gone from 3.x and later > 2.x's. This option should be removed from configure, since it's no longer used. It should _not_ be removed because it does work and it is used. I'm not sure why someone thinks it doesn't work; configure does set USER_PATH in config.h, which is used in defines.h to override _PATH_STDPATH, which is used in session.c do_child() to initialize the PATH. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From stevev at darkwing.uoregon.edu Sat Jan 26 09:07:50 2002 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Fri, 25 Jan 2002 14:07:50 -0800 Subject: [Bug 82] New: scp: Command not found errors In-Reply-To: <20020125220454.7828EE95B@shitei.mindrot.org> References: <20020125220454.7828EE95B@shitei.mindrot.org> Message-ID: <15441.55094.251472.310443@darkwing.uoregon.edu> bugzilla-daemon at mindrot.org writes: > Next, the configure --with-default-path suggestion is a bum steer. The > option --with-default-path no longer effects the makefiles, header files or > source code. It did in Version 1.x but certianly its gone from 3.x and later > 2.x's. This option should be removed from configure, since it's no longer used. Funny, "configure --with-default-path=..." still works for me in Portable OpenSSH 3.0.2p1. I get /* Specify default $PATH */ #define USER_PATH "/usr/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin" in config.h in my Solaris and Digital UNIX builds when I use it. What platform are you trying to configure for? From bugzilla-daemon at mindrot.org Sat Jan 26 09:59:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 09:59:42 +1100 (EST) Subject: [Bug 80] Host key conflict with two servers on one IP Message-ID: <20020125225942.6582EE96F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-26 09:59 ------- You can use the HostKeyAlias option in ~/.ssh/config or /etc/ssh_config to "rename" hosts to avoid these collisions. ------- 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 Jan 26 10:07:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 10:07:10 +1100 (EST) Subject: [Bug 81] ssh cannot use ssh-askspass & passphrases as documented Message-ID: <20020125230710.999CBEB2D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=81 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-26 10:07 ------- The suggested change is incorrect. ssh may have stdin redirected from something else - you do not want to read the passphease from there (e.g. the output of a pipe). BTW the passphrase reading does work as advertised, it states: > If ssh needs a passphrase, it will read the passphrase from the > current terminal if it was run from a terminal. If ssh does not > have a terminal associated with it but DISPLAY and SSH_ASKPASS > are set, it will execute the program specified by SSH_ASKPASS > ... just because you have redirected stdin does not mean you have lost your controlling terminal. You need to call setsid to do that. You may be interested in the patch on Bug #69 though ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From carson at taltos.org Sat Jan 26 10:06:22 2002 From: carson at taltos.org (Carson Gaspar) Date: Fri, 25 Jan 2002 18:06:22 -0500 Subject: Configure script In-Reply-To: <20020124134319.A26401@mtu.edu> References: <20020124134319.A26401@mtu.edu> Message-ID: <369432140.1011981982@[192.168.0.1]> See the list archives for the previous discussion of this issue. The short form: - Currently, it's hardcoded in configure.ac It used to be first (blech) and now it's last (slightly less nasty) - The OpenSSH maintainers don't want to just remove it, since idiots will then be unable to compile OpenSSH - I proposed a patch that implements a much better search algorithm for external libraries, and it was never merged in. If I recall correctly, I proposed that: If --with-foo=/bar was specified, look in /bar. If it's not there, fail. If it is there, prepend -I/bar/include to CPPFLAGS and -L/bar/lib (and -R/bar/lib if appropriate) to LDFLAGS, and -lfoo to LIBS. If --with-foo was specified (or is on by default), try with the current CPPFLAGS and LDFLAGS. If it works, add -lfoo to LIBS. If it doesn't work, look in /usr/local. If it works, append -I/usr/local/include to CPPFLAGS, and -L/usr/local/lib (and -R/usr/local/lib if appropriate) to LDFLAGS and -lfoo to LIBS. If you haven't found it yet, fail. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From bugzilla-daemon at mindrot.org Sat Jan 26 10:14:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 10:14:41 +1100 (EST) Subject: [Bug 82] scp: Command not found errors Message-ID: <20020125231441.D3300EB3E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=82 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From djm at mindrot.org 2002-01-26 10:14 ------- The --with-default-path option most certainly does work. You probably have some environment or shell initialisation which is clobbering your $PATH env var. I don't see how the FAQ is out of date. ------- 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 Jan 26 10:29:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 10:29:20 +1100 (EST) Subject: [Bug 80] Host key conflict with two servers on one IP Message-ID: <20020125232920.A490EEB5C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 carson at taltos.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Priority|P2 |P3 Resolution|WORKSFORME | ------- Additional Comments From carson at taltos.org 2002-01-26 10:29 ------- Services are provided on an IP:PORT pair basis. Assuming anything else is silly. The existance of a workaround for the bug does not imply the non- existance of the bug itself. OpenSSH should behave correctly in the default case, not require users to muck about with their configs. If you wish to consider it a low priority bug, fine (I'm dropping it to P3). But a bug it is. ------- 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 Jan 26 10:54:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 10:54:42 +1100 (EST) Subject: [Bug 80] Host key conflict with two servers on one IP Message-ID: <20020125235442.ACDA0EB5C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 dan at doxpara.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From dan at doxpara.com 2002-01-26 10:54 ------- HostKeyAlias isn't just *a* solution, it's the right solution. SSH connects to hosts, not to ports -- the port is just some address that may or may not lead to a specific desired host, possibly the machine listening on that port, possibly somewhere else. We identify by destination, not by route. Theory aside, what we want is for a given firewall to be able to remap a port on the external interface to an SSHD on the backend, with the client authenticating (and independently encrypting) against this forwarded link. Instead of: alice$ ssh -p 2022 user at firewall either conflicting with the firewall's actual ssh key *or* somehow associating the key with the firewall itself(or, in the localhost variant involving 127.0.0.1, just not authenticating at all), HostKeyAlias lets us inform the client of its expected cryptographically validated destination: Bob. alice$ ssh -o HostKeyAlias="Bob" -p 2022 user at firewall I do have a better syntax for this that might someday actually work, but there is no bug beyond that. It's as incorrect to see Bob's key associated with the firewall as it would be to see it associated with, say, MAE-West. Firewall's just the route -- Bob's who we're looking for. That being said -- you're generally correct about services mapping to IP:PORT. SSH escapes this general purpose simplification, because its services don't always remain on the same IP:PORT. SSL makes a similar judgement, authenticating DNS names but not IPs or Ports. You are you, no matter your phone number. It's much the same for cryptographically verified identity. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Sat Jan 26 11:27:01 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 25 Jan 2002 16:27:01 -0800 (PST) Subject: Configure script In-Reply-To: <369432140.1011981982@[192.168.0.1]> Message-ID: On Fri, 25 Jan 2002, Carson Gaspar wrote: > See the list archives for the previous discussion of this issue. The short > form: > > - Currently, it's hardcoded in configure.ac It used to be first (blech) and > now it's last (slightly less nasty) > - The OpenSSH maintainers don't want to just remove it, since idiots will > then be unable to compile OpenSSH It really comes down to how many e-mails would we get by removing -L/usr/local/lib vs. the few we get now by having it in. If anyone can put forth a convincing argument that removing it would NOT significantly increase the support burden, we'll revisit the idea. > - I proposed a patch that implements a much better search algorithm for > external libraries, and it was never merged in. If I recall correctly, I It wasn't merged in because it didn't work. > proposed that: > > If --with-foo=/bar was specified, look in /bar. If it's not there, fail. If > it is there, prepend -I/bar/include to CPPFLAGS and -L/bar/lib (and > -R/bar/lib if appropriate) to LDFLAGS, and -lfoo to LIBS. > If --with-foo was specified (or is on by default), try with the current > CPPFLAGS and LDFLAGS. If it works, add -lfoo to LIBS. If it doesn't work, > look in /usr/local. If it works, append -I/usr/local/include to CPPFLAGS, > and -L/usr/local/lib (and -R/usr/local/lib if appropriate) to LDFLAGS and > -lfoo to LIBS. If you haven't found it yet, fail. > > I like the idea. I just have not seen a working implementation of this. Your patch may have worked on your systems but didn't work here. After about 6 hours I gave up. Would anyone be interested in support for a config.local file where you could set CFLAGS, CPPFLAGS, LDFLAGS, etc. that would override the defaults in configure? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sat Jan 26 13:47:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 13:47:46 +1100 (EST) Subject: [Bug 82] scp: Command not found errors Message-ID: <20020126024746.DDD5EE974@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=82 steve_dum at mentor.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From steve_dum at mentor.com 2002-01-26 13:47 ------- Yes, in 3.0.2p1 it causes USER_PATH to be defined in config.h. However, it's not used in any of the code. The old behavior, e.g. 1.2.3, when USER_PATH was defined, it caused _PATH_STDPATH to be defined (in config.h). This in turn was used by sshd.c in a call to child_set_env(...) to set it in the environment. That code isn't there any longer. More important, it looks like sshd forks off a user's shell to execute the scp command, so now we are stuck with the system default settings for PATH, and as you point out, what the user's local initialization code does. So even if --with-default-path did work, it would be overridden, making the advice of the FAQ not very helpful. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From cmadams at hiwaay.net Sat Jan 26 13:58:51 2002 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Jan 2002 20:58:51 -0600 Subject: [Bug 82] scp: Command not found errors In-Reply-To: <20020126024746.DDD5EE974@shitei.mindrot.org> References: <20020126024746.DDD5EE974@shitei.mindrot.org> Message-ID: <20020126025851.GJ5539@HiWAAY.net> Once upon a time, bugzilla-daemon at mindrot.org said: > Yes, in 3.0.2p1 it causes USER_PATH to be defined in config.h. However, > it's not used in any of the code. Wrong again. Look at defines.h, lines 315-320 in OpenSSH 3.0.2p1: #ifdef USER_PATH # ifdef _PATH_STDPATH # undef _PATH_STDPATH # endif # define _PATH_STDPATH USER_PATH #endif Then look at session.c, line 1235: child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); --with-default-path _is_ used. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bugzilla-daemon at mindrot.org Sat Jan 26 14:24:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 14:24:23 +1100 (EST) Subject: [Bug 82] scp: Command not found errors Message-ID: <20020126032423.B524CE93F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=82 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2002-01-26 14:24 ------- Please read the code. From defines.h: #ifdef USER_PATH # ifdef _PATH_STDPATH # undef _PATH_STDPATH # endif # define _PATH_STDPATH USER_PATH #endif From bugzilla-daemon at mindrot.org Sat Jan 26 14:25:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 14:25:58 +1100 (EST) Subject: [Bug 80] Host key conflict with two servers on one IP Message-ID: <20020126032558.7B2A3E93F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 ------- Additional Comments From djm at mindrot.org 2002-01-26 14:25 ------- A fursther comment: ssh works on port 22, that is what has been reserved by the IANA. Anything else is a special case. ------- 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 Jan 26 16:51:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 16:51:22 +1100 (EST) Subject: [Bug 82] scp: Command not found errors Message-ID: <20020126055122.750A2EBA0@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=82 ------- Additional Comments From steve_dum at mentor.com 2002-01-26 16:51 ------- Apologies, your right. The FAQ should be updated to indicate that another reason this error occurs is if ones shell initialiation excludes the directory that scp is in from the PATH variable. ------- 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 Jan 26 16:54:02 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 26 Jan 2002 16:54:02 +1100 (EST) Subject: [Bug 80] Host key conflict with two servers on one IP Message-ID: <20020126055402.D4B76EBA5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=80 ------- Additional Comments From dan at doxpara.com 2002-01-26 16:53 ------- The IANA number is nice, but I wouldn't call "anything else a special case". If it wasn't for the nature of the crypto identity, he'd have a good argument that we weren't elegantly supporting multiple servers living on the same host. It's a bit strange coming up with an example, but suppose web browsers didn't attach the alternate port to relative links. Sure, you could download the HTML page, but any linked images would either have to be absolutely specified or would be attempted to be sucked from the server on port 80, the "IANA" port. It'd be presumptively incorrect behavior, even if the original page was retrieved via HTTP. Multiple servers on the same host have different content, and that's OK. Keep in mind -- port shifting is pretty much the only way to virtual host HTTP over SSL. SSH is a much different story, though. "Multiple servers living on the same host" represent one of two things: A) An alternate SSHD running locally, possibly for testing purposes. The keys should match, and as does the desired destination. B) An alternate SSHD running remotely, probably port forwarded. The keys ought not match, because someone's trying to go elsewhere. Content is not identity. Who you are is different than what you say. Anyway, IANA is a suggestion and a reservation; it excludes other services from using SSH's port, but shouldn't be construed to restrict SSH to 22. Flexibility is a good thing. --Dan ------- 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 Jan 27 00:59:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 27 Jan 2002 00:59:11 +1100 (EST) Subject: [Bug 75] Error compiling in ssh-agent.c Message-ID: <20020126135911.364EBE944@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=75 ------- Additional Comments From adrian at afsthumper.com 2002-01-27 00:59 ------- After doing some research, and noticing that I get similar errors when compiling other software (like the GMP library), it looks like my problem may be GLibc and/or GCC related. When I try to compile GMP, I get undefined reference to 'atexit()'. It looks like a patch for this issue for GCC- 2.95.3 is available. Here are the links I used to come to this conclusion http://www.winehq.com/hypermail/wine- users/2001/06/0049.html http://sources.redhat.com/ml/libc-alpha/2001- 03/msg00048.html http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01187.html So, in short, it looks like the bug may not be with the SSH source, but with the tools I'm using. I will let you know if patching GCC resolves this problem so we can get this bug closed out. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tori at ringstrom.mine.nu Sun Jan 27 06:47:45 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sat, 26 Jan 2002 20:47:45 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option Message-ID: Hello again! Since there was some resistance against adding TCP_NODELAY uncontionally, I've made another patch. The new patch contains the following: * Added a NoDelay yes/no (default no) config option to ssh and sshd * Added -oNoDelay=yes to the ssh command line for sftp. * Changed the sshd subsystem config option syntax from Subsystem name path to Subsystem name options path where options is similar to the option field in fstab. The only options right now are "defaults" and "nodelay". I also added a backwards compatible hack: If the parser finds a slash (/) as the first character of the options field, it emits a warning and assumes defaults. * Changed the sshd_config template to use nodelay by default for the sftp subsystem. I have not updated the documentation yet, but I can do that if you find the patch acceptable. So, what do you all think? The patch is for openssh-3.0.2p1. /Tobias -------------- next part -------------- diff -ru openssh-3.0.2p1.orig/readconf.c openssh-3.0.2p1.cfgnodelay/readconf.c --- openssh-3.0.2p1.orig/readconf.c Wed Oct 3 19:39:39 2001 +++ openssh-3.0.2p1.cfgnodelay/readconf.c Sat Jan 26 19:42:34 2002 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oNoDelay } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +188,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "nodelay", oNoDelay }, { NULL, 0 } }; @@ -678,6 +680,10 @@ *intptr = value; break; + case oNoDelay: + intptr = &options->nodelay; + goto parse_flag; + default: fatal("process_config_line: Unimplemented opcode %d", opcode); } @@ -799,6 +805,7 @@ options->bind_address = NULL; options->smartcard_device = NULL; options->no_host_authentication_for_localhost = - 1; + options->nodelay = -1; } /* @@ -919,6 +926,8 @@ clear_forwardings(options); if (options->no_host_authentication_for_localhost == - 1) options->no_host_authentication_for_localhost = 0; + if (options->nodelay == -1) + options->nodelay = 0; /* 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 -ru openssh-3.0.2p1.orig/readconf.h openssh-3.0.2p1.cfgnodelay/readconf.h --- openssh-3.0.2p1.orig/readconf.h Wed Oct 3 19:39:39 2001 +++ openssh-3.0.2p1.cfgnodelay/readconf.h Sat Jan 26 17:34:31 2002 @@ -102,6 +102,7 @@ Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; int no_host_authentication_for_localhost; + int nodelay; } Options; diff -ru openssh-3.0.2p1.orig/servconf.c openssh-3.0.2p1.cfgnodelay/servconf.c --- openssh-3.0.2p1.orig/servconf.c Tue Nov 13 14:03:15 2001 +++ openssh-3.0.2p1.cfgnodelay/servconf.c Sat Jan 26 20:09:29 2002 @@ -109,6 +109,7 @@ options->client_alive_count_max = -1; options->authorized_keys_file = NULL; options->authorized_keys_file2 = NULL; + options->nodelay = -1; } void @@ -229,6 +230,8 @@ } if (options->authorized_keys_file == NULL) options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; + if (options->nodelay == -1) + options->nodelay = 0; } /* Keyword tokens. */ @@ -261,6 +264,7 @@ sBanner, sReverseMappingCheck, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, + sNoDelay, sDeprecated } ServerOpCodes; @@ -334,6 +338,7 @@ { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "nodelay", sNoDelay }, { NULL, 0 } }; @@ -801,15 +806,30 @@ fatal("%s line %d: Missing subsystem name.", filename, linenum); for (i = 0; i < options->num_subsystems; i++) - if(strcmp(arg, options->subsystem_name[i]) == 0) + if(strcmp(arg, options->subsystem[i].name) == 0) fatal("%s line %d: Subsystem '%s' already defined.", filename, linenum, arg); - options->subsystem_name[options->num_subsystems] = xstrdup(arg); + options->subsystem[options->num_subsystems].name = xstrdup(arg); arg = strdelim(&cp); if (!arg || *arg == '\0') - fatal("%s line %d: Missing subsystem command.", + fatal("%s line %d: Missing subsystem options and command.", filename, linenum); - options->subsystem_command[options->num_subsystems] = xstrdup(arg); + if (arg[0] == '/') { + log("%s line %d: Subsystem option starts with '/'. " + "Assuming old syntax.", filename, linenum); + } else { + if (strcmp(arg, "nodelay") == 0) + options->subsystem[options->num_subsystems].nodelay = 1; + else if (strcmp(arg, "defaults") != 0) { + fatal("%s line %d: Unknown subsystem option.", + filename, linenum); + } + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing subsystem command.", + filename, linenum); + } + options->subsystem[options->num_subsystems].command = xstrdup(arg); options->num_subsystems++; break; @@ -859,6 +879,10 @@ intptr = &options->client_alive_count_max; goto parse_int; + case sNoDelay: + intptr = &options->nodelay; + goto parse_flag; + case sDeprecated: log("%s line %d: Deprecated option %s", filename, linenum, arg); diff -ru openssh-3.0.2p1.orig/servconf.h openssh-3.0.2p1.cfgnodelay/servconf.h --- openssh-3.0.2p1.orig/servconf.h Wed Sep 12 18:40:06 2001 +++ openssh-3.0.2p1.cfgnodelay/servconf.h Sat Jan 26 17:47:25 2002 @@ -34,6 +34,12 @@ typedef struct { + char *name; + int nodelay; + char *command; +} Subsystem; + +typedef struct { u_int num_ports; u_int ports_from_cmdline; u_short ports[MAX_PORTS]; /* Port number to listen on. */ @@ -108,8 +114,7 @@ char *deny_groups[MAX_DENY_GROUPS]; u_int num_subsystems; - char *subsystem_name[MAX_SUBSYSTEMS]; - char *subsystem_command[MAX_SUBSYSTEMS]; + Subsystem subsystem[MAX_SUBSYSTEMS]; int max_startups_begin; int max_startups_rate; @@ -129,6 +134,7 @@ char *authorized_keys_file; /* File containing public keys */ char *authorized_keys_file2; int pam_authentication_via_kbd_int; + int nodelay; } ServerOptions; diff -ru openssh-3.0.2p1.orig/session.c openssh-3.0.2p1.cfgnodelay/session.c --- openssh-3.0.2p1.orig/session.c Sun Dec 2 00:37:08 2001 +++ openssh-3.0.2p1.cfgnodelay/session.c Sat Jan 26 19:33:57 2002 @@ -1695,13 +1695,19 @@ log("subsystem request for %s", subsys); for (i = 0; i < options.num_subsystems; i++) { - if (strcmp(subsys, options.subsystem_name[i]) == 0) { - cmd = options.subsystem_command[i]; + if (strcmp(subsys, options.subsystem[i].name) == 0) { + cmd = options.subsystem[i].command; if (stat(cmd, &st) < 0) { error("subsystem: cannot stat %s: %s", cmd, strerror(errno)); break; } + if (options.subsystem[i].nodelay) { + int sock = packet_get_connection_out(), on = 1; + if (setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, + (void *)&on, sizeof(on)) < 0) + error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); + } debug("subsystem: exec() %s", cmd); s->is_subsystem = 1; do_exec(s, cmd); diff -ru openssh-3.0.2p1.orig/sftp.c openssh-3.0.2p1.cfgnodelay/sftp.c --- openssh-3.0.2p1.orig/sftp.c Thu Sep 20 02:57:56 2001 +++ openssh-3.0.2p1.cfgnodelay/sftp.c Sat Jan 26 19:47:36 2002 @@ -119,6 +119,7 @@ addargs(&args, "-oForwardX11 no"); addargs(&args, "-oForwardAgent no"); addargs(&args, "-oClearAllForwardings yes"); + addargs(&args, "-oNoDelay yes"); ll = SYSLOG_LEVEL_INFO; infile = stdin; /* Read from STDIN unless changed by -b */ diff -ru openssh-3.0.2p1.orig/ssh_config openssh-3.0.2p1.cfgnodelay/ssh_config --- openssh-3.0.2p1.orig/ssh_config Wed Apr 4 03:58:48 2001 +++ openssh-3.0.2p1.cfgnodelay/ssh_config Sat Jan 26 19:47:14 2002 @@ -33,3 +33,4 @@ # Protocol 2,1 # Cipher blowfish # EscapeChar ~ +# NoDelay yes diff -ru openssh-3.0.2p1.orig/sshconnect.c openssh-3.0.2p1.cfgnodelay/sshconnect.c --- openssh-3.0.2p1.orig/sshconnect.c Wed Oct 10 07:07:45 2001 +++ openssh-3.0.2p1.cfgnodelay/sshconnect.c Sat Jan 26 17:38:50 2002 @@ -377,6 +377,12 @@ sizeof(on)) < 0) error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno)); + /* Set nodelay if requested. */ + if (options.nodelay && + setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (void *)&on, + sizeof(on)) < 0) + error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); + /* Set the connection. */ packet_set_connection(sock, sock); diff -ru openssh-3.0.2p1.orig/sshd.c openssh-3.0.2p1.cfgnodelay/sshd.c --- openssh-3.0.2p1.orig/sshd.c Mon Nov 12 01:07:12 2001 +++ openssh-3.0.2p1.cfgnodelay/sshd.c Sat Jan 26 17:38:36 2002 @@ -1125,6 +1125,12 @@ sizeof(on)) < 0) error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno)); + /* Set nodelay if requested. */ + if (options.nodelay && + setsockopt(sock_in, IPPROTO_TCP, TCP_NODELAY, (void *)&on, + sizeof(on)) < 0) + error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); + /* * Register our connection. This turns encryption off because we do * not have a key. diff -ru openssh-3.0.2p1.orig/sshd_config openssh-3.0.2p1.cfgnodelay/sshd_config --- openssh-3.0.2p1.orig/sshd_config Fri Sep 21 01:15:44 2001 +++ openssh-3.0.2p1.cfgnodelay/sshd_config Sat Jan 26 19:46:49 2002 @@ -9,6 +9,7 @@ #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: +#NoDelay yes # HostKey for protocol version 1 HostKey /etc/ssh_host_key @@ -77,4 +78,4 @@ #Banner /etc/issue.net #ReverseMappingCheck yes -Subsystem sftp /usr/libexec/sftp-server +Subsystem sftp nodelay /usr/libexec/sftp-server From carson at taltos.org Sun Jan 27 08:05:34 2002 From: carson at taltos.org (Carson Gaspar) Date: Sat, 26 Jan 2002 16:05:34 -0500 Subject: [Bug 80] Host key conflict with two servers on one IP In-Reply-To: <20020125235442.ACDA0EB5C@shitei.mindrot.org> References: <20020125235442.ACDA0EB5C@shitei.mindrot.org> Message-ID: <448584453.1012061134@[192.168.0.1]> > ------- Additional Comments From dan at doxpara.com 2002-01-26 10:54 ------- > We identify by destination, not by route. OK, I have an idea, but I don't know, protocol-wise, if it's possible. Does the server send it's name before the client has to verify the key, or after? If before, ssh should look up the host key by the server's in-band name (similar to the HostAuth behaviour). This would actually map the key to the identity at layer 7, and avoid the layering violation of using layer 3/4 data, or requiring the user to manually map things. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From carson at taltos.org Sun Jan 27 08:09:35 2002 From: carson at taltos.org (Carson Gaspar) Date: Sat, 26 Jan 2002 16:09:35 -0500 Subject: Configure script In-Reply-To: References: Message-ID: <448824812.1012061374@[192.168.0.1]> --On Friday, January 25, 2002 4:27 PM -0800 Tim Rice wrote: > I like the idea. > I just have not seen a working implementation of this. > Your patch may have worked on your systems but didn't work here. > After about 6 hours I gave up. I'd forgotten about that (my bad). If the idea is sound, I'll re-work my changes using the latest autoconf stuff. It would be great to finally have configure not making path assumptions. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From jclonguet at free.fr Sun Jan 27 09:45:39 2002 From: jclonguet at free.fr (Jean-Charles Longuet) Date: Sat, 26 Jan 2002 23:45:39 +0100 Subject: [PATCH] Connect timeout Message-ID: <3C533193.33910695@free.fr> The attached patch adds a new 'ConnectTimeout' option (man page updated in patch) to avoid wasting time when the target host is down. I needed that because I was using rsync/rdist over ssh for massive files update and the default connect() took too long for my purpose. The patch was tested on Linux only, but I used a similar one for ssh 1.2.XX on Linux, Solaris and HP-UX without problems. The patch can also be found on: http://charts.free.fr/openssh-3.0.2p1-timeout.patch PS: I did not suscribe to the list, so please cc: me regarding this patch -------------- next part -------------- --- includes.h.OK Thu Sep 20 04:07:51 2001 +++ includes.h Sat Jan 26 21:44:35 2002 @@ -44,6 +44,8 @@ #include #include #include +#include +#include #ifdef HAVE_LIMITS_H # include --- readconf.c.OK Wed Oct 3 19:39:39 2001 +++ readconf.c Sat Jan 26 21:44:35 2002 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oConnectTimeout } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +188,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "connecttimeout", oConnectTimeout }, { NULL, 0 } }; @@ -294,6 +296,11 @@ /* don't panic, but count bad options */ return -1; /* NOTREACHED */ + + case oConnectTimeout: + intptr = &options->connection_timeout; + goto parse_int; + case oForwardAgent: intptr = &options->forward_agent; parse_flag: @@ -775,6 +782,7 @@ options->compression_level = -1; options->port = -1; options->connection_attempts = -1; + options->connection_timeout = -1; options->number_of_password_prompts = -1; options->cipher = -1; options->ciphers = NULL; --- readconf.h.OK Wed Oct 3 19:39:39 2001 +++ readconf.h Sat Jan 26 21:44:35 2002 @@ -68,6 +68,8 @@ int port; /* Port to connect. */ int connection_attempts; /* Max attempts (seconds) before * giving up */ + int connection_timeout; /* Max time (seconds) before + * aborting connection attempt */ int number_of_password_prompts; /* Max number of password * prompts. */ int cipher; /* Cipher to use. */ --- ssh.1.OK Mon Nov 12 01:05:49 2001 +++ ssh.1 Sat Jan 26 21:44:35 2002 @@ -804,6 +804,12 @@ The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1. +.It Cm ConnectTimeout +Specifies the timeout (in seconds) used when connecting to the ssh +server, instead of using default system values. This value is used +only when the target is down or really unreachable, not when it +refuses the connection. This may be usefull for tools using ssh +for communication, as it avoid long waits. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application --- ssh.c.OK Mon Nov 12 00:52:04 2001 +++ ssh.c Sat Jan 26 21:44:35 2002 @@ -674,7 +674,7 @@ /* Open a connection to the remote host. */ cerr = ssh_connect(host, &hostaddr, options.port, IPv4or6, - options.connection_attempts, + options.connection_attempts, options.connection_timeout, original_effective_uid != 0 || !options.use_privileged_port, pw, options.proxy_command); --- sshconnect.c.OK Wed Oct 10 07:07:45 2001 +++ sshconnect.c Sat Jan 26 21:44:35 2002 @@ -35,6 +35,8 @@ char *client_version_string = NULL; char *server_version_string = NULL; +static jmp_buf jmpenv; + extern Options options; extern char *__progname; @@ -221,6 +223,43 @@ return sock; } +/* for alarm() */ +static void +timeout_sigh(int dummy) +{ + errno = ETIMEDOUT; + longjmp(jmpenv, !0); +} + +int +timeout_connect(int sockfd, const struct sockaddr *serv_addr, + socklen_t addrlen, int timeout) +{ + void (*sigh)(int); + int rc; + + if (timeout <= 0) + return(connect(sockfd, serv_addr, addrlen)); + + if (setjmp(jmpenv) == 0) + { + debug("ssh: setting connect() timeout to %d s.", + timeout); + sigh = signal(SIGALRM, timeout_sigh); + if (sigh == SIG_ERR) + sigh = SIG_IGN; /* For further restore */ + (void) alarm((unsigned int) timeout); + rc = connect(sockfd, serv_addr, addrlen); + /* restore previous behaviour */ + (void) alarm((unsigned int) 0); + (void) signal(SIGALRM, sigh); + return rc; + } else { + errno = ETIMEDOUT; + return -1; + } +} + /* * Opens a TCP/IP connection to the remote server on the given host. * The address of the remote host will be returned in hostaddr. @@ -240,7 +279,7 @@ */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, + u_short port, int family, int connection_attempts, int connection_timeout, int anonymous, struct passwd *pw, const char *proxy_command) { int gaierr; @@ -322,7 +361,8 @@ * the remote uid as root. */ temporarily_use_uid(pw); - if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) { + if (timeout_connect(sock, ai->ai_addr, ai->ai_addrlen, + connection_timeout) >= 0) { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); restore_uid(); --- sshconnect.h.OK Wed Oct 10 07:07:45 2001 +++ sshconnect.h Sat Jan 26 21:44:35 2002 @@ -28,7 +28,7 @@ int ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int, struct passwd *, const char *); + int, int, struct passwd *, const char *); void ssh_login(Key **, int, const char *, struct sockaddr *, struct passwd *); From josb at cncdsl.com Sun Jan 27 10:05:07 2002 From: josb at cncdsl.com (Jos Backus) Date: Sat, 26 Jan 2002 15:05:07 -0800 Subject: Interest in ssh-agent connection retry patch? Message-ID: <20020126230529.GC40862@lizzy.bugworks.com> I wrote a patch to make the number of times and and the delay between retries that ssh attempts to talk to ssh-agent configurable. This patch is indispensible when running multiple ssh sessions in parallel from a script (e.g. to run commands on a large number of hosts); without the patch, many ssh sessions simply fail because they cannot contact the agent, rendering the mechanism unusable. If there is sufficient interest to incorporate this patch into a future OpenSSH version I'll post it here. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From dan at doxpara.com Sun Jan 27 10:11:54 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 26 Jan 2002 15:11:54 -0800 Subject: [PATCH] Connect timeout References: <3C533193.33910695@free.fr> Message-ID: <009201c1a6be$d8a825e0$1701000a@effugas> > The attached patch adds a new 'ConnectTimeout' option (man page updated > in patch) to avoid wasting time when the target host is down. I needed that > because I was using rsync/rdist over ssh for massive files update and the > default connect() took too long for my purpose. All-- This is really, really useful. If the code is correct, I'd *really* like to see this in future builds. --dan From jmknoble at pobox.com Sun Jan 27 10:09:10 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Sat, 26 Jan 2002 18:09:10 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from tori@ringstrom.mine.nu on Sat, Jan 26, 2002 at 08:47:45PM +0100 References: Message-ID: <20020126180910.A9223@shell.ntrnet.net> Circa 2002-Jan-26 20:47:45 +0100 dixit Tobias Ringstrom: : * Changed the sshd subsystem config option syntax from : Subsystem name path : to : Subsystem name options path : where options is similar to the option field in fstab. The only options : right now are "defaults" and "nodelay". I also added a backwards : compatible hack: If the parser finds a slash (/) as the first character : of the options field, it emits a warning and assumes defaults. Why not: Subsystem name path [options] ? That way you don't need the cruft to detect forward-slashes, and you can omit the warnings as well, since the options are ... well, optional. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ From djm at mindrot.org Sun Jan 27 10:33:00 2002 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Jan 2002 10:33:00 +1100 (EST) Subject: [PATCH] Connect timeout In-Reply-To: <3C533193.33910695@free.fr> Message-ID: On Sat, 26 Jan 2002, Jean-Charles Longuet wrote: > The attached patch adds a new 'ConnectTimeout' option (man page > updated in patch) to avoid wasting time when the target host is > down. I needed that because I was using rsync/rdist over ssh for > massive files update and the default connect() took too long for my > purpose. I'd prefer to see a patch which sets the connect socket to nonblocking and does a timed select() on it. -d From dan at doxpara.com Sun Jan 27 11:32:57 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 26 Jan 2002 16:32:57 -0800 Subject: Interest in ssh-agent connection retry patch? References: <20020126230529.GC40862@lizzy.bugworks.com> Message-ID: <00a001c1a6ca$2adfd000$1701000a@effugas> > I wrote a patch to make the number of times and and the delay between retries > that ssh attempts to talk to ssh-agent configurable. This patch is > indispensible when running multiple ssh sessions in parallel from a script > (e.g. to run commands on a large number of hosts); without the patch, many ssh > sessions simply fail because they cannot contact the agent, rendering the > mechanism unusable. Why is SSH failing to communicate with the agent? --Dan From josb at cncdsl.com Sun Jan 27 13:56:03 2002 From: josb at cncdsl.com (Jos Backus) Date: Sat, 26 Jan 2002 18:56:03 -0800 Subject: Interest in ssh-agent connection retry patch? In-Reply-To: <00a001c1a6ca$2adfd000$1701000a@effugas> References: <20020126230529.GC40862@lizzy.bugworks.com> <00a001c1a6ca$2adfd000$1701000a@effugas> Message-ID: <20020127025625.GD40862@lizzy.bugworks.com> On Sat, Jan 26, 2002 at 04:32:57PM -0800, Dan Kaminsky wrote: > Why is SSH failing to communicate with the agent? Because ssh-agent can only serve so many connections in a given time period. We start between 50-100 ssh sessions within a short time period, and they all race to connect to the agent socket. Some of these ssh processes fail so they have to back off and retry. We could also have put the retry mechanism in the tool but in our case it seemed to make more sense to put this functionality in ssh. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From josb at cncdsl.com Sun Jan 27 14:22:09 2002 From: josb at cncdsl.com (Jos Backus) Date: Sat, 26 Jan 2002 19:22:09 -0800 Subject: Interest in ssh-agent connection retry patch? In-Reply-To: <20020127025625.GD40862@lizzy.bugworks.com> References: <20020126230529.GC40862@lizzy.bugworks.com> <00a001c1a6ca$2adfd000$1701000a@effugas> <20020127025625.GD40862@lizzy.bugworks.com> Message-ID: <20020127032231.GF40862@lizzy.bugworks.com> On Sat, Jan 26, 2002 at 06:56:03PM -0800, Jos Backus wrote: > On Sat, Jan 26, 2002 at 04:32:57PM -0800, Dan Kaminsky wrote: > > Why is SSH failing to communicate with the agent? > > Because ssh-agent can only serve so many connections in a given time period. > We start between 50-100 ssh sessions within a short time period, and they all > race to connect to the agent socket. Some of these ssh processes fail so they > have to back off and retry. We could also have put the retry mechanism in the > tool but in our case it seemed to make more sense to put this functionality in > ssh. To elaborate on this some more: by putting this functionality inside ssh this type of ssh session failure is hidden from the tool in virtually all cases, reducing the complexity of the tool and making the tool's output easier to analyze by a human operator. Before adding this feature we were seeing lots of ``Permission denied'' errors, some of them caused by that particular ssh session's inability to communicate with the agent, others by (say) genuine misconfiguration of the remote host involved. It wasn't always easy to discern between the various failure modes and this would cause our operators to have to do more work. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From dan at doxpara.com Sun Jan 27 14:34:46 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 26 Jan 2002 19:34:46 -0800 Subject: Interest in ssh-agent connection retry patch? References: <20020126230529.GC40862@lizzy.bugworks.com> <00a001c1a6ca$2adfd000$1701000a@effugas> <20020127025625.GD40862@lizzy.bugworks.com> Message-ID: <00d801c1a6e3$913cea40$1701000a@effugas> > On Sat, Jan 26, 2002 at 04:32:57PM -0800, Dan Kaminsky wrote: > > Why is SSH failing to communicate with the agent? > > Because ssh-agent can only serve so many connections in a given time period. > We start between 50-100 ssh sessions within a short time period, and they all > race to connect to the agent socket. Some of these ssh processes fail so they > have to back off and retry. We could also have put the retry mechanism in the > tool but in our case it seemed to make more sense to put this functionality in > ssh. Hmmm. This a problem with file-oriented sockets, isn't it -- each connection blocks, because everyone's sharing the same socket. In return, however, we do get per-user authentication, which we *wouldn't* have with a loopback mechanism. I don't know enough about socket level work to know if non-blocking/select() style loops could be applied to serve greater numbers of SSH clients -- distaste for sockets drove me to libnet/libpcap :-) But although your connection-retry solution is better than flat out failing, in the long term it'd be very good for the agent to be able to support more clients. --Dan From josb at cncdsl.com Sun Jan 27 14:55:42 2002 From: josb at cncdsl.com (Jos Backus) Date: Sat, 26 Jan 2002 19:54:42 -0801 Subject: Interest in ssh-agent connection retry patch? In-Reply-To: <00d801c1a6e3$913cea40$1701000a@effugas> References: <20020126230529.GC40862@lizzy.bugworks.com> <00a001c1a6ca$2adfd000$1701000a@effugas> <20020127025625.GD40862@lizzy.bugworks.com> <00d801c1a6e3$913cea40$1701000a@effugas> Message-ID: <20020127035504.GG40862@lizzy.bugworks.com> On Sat, Jan 26, 2002 at 07:34:46PM -0800, Dan Kaminsky wrote: > Hmmm. This a problem with file-oriented sockets, isn't it -- each > connection blocks, because everyone's sharing the same socket. The first ssh processes will block, waiting in the ssh-agent's listen() queue, subsequent ssh processes get ECONNREFUSED. First I tried increasing the listen() queue in ssh-agent, but that didn't really help much, and it's not very portable (I have heard that there are UNIX versions which ignore any value greater than 5). > In return, however, we do get per-user authentication, which we *wouldn't* > have with a loopback mechanism. > > I don't know enough about socket level work to know if non-blocking/select() > style loops could be applied to serve greater numbers of SSH clients -- > distaste for sockets drove me to libnet/libpcap :-) But although your > connection-retry solution is better than flat out failing, in the long term > it'd be very good for the agent to be able to support more clients. Yup. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From tori at ringstrom.mine.nu Sun Jan 27 19:00:30 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Sun, 27 Jan 2002 09:00:30 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020126180910.A9223@shell.ntrnet.net> Message-ID: On Sat, 26 Jan 2002, Jim Knoble wrote: > Why not: > > Subsystem name path [options] > > ? That way you don't need the cruft to detect forward-slashes, and you > can omit the warnings as well, since the options are ... well, optional. I'm influenced by the inetd config format, and want to preserve the possibility of adding arguments to the path (executable). While we cannot handle that right now, it may be a nice feature in the future(!). /Tobias From Jarno.Huuskonen at uku.fi Sun Jan 27 19:56:24 2002 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Sun, 27 Jan 2002 10:56:24 +0200 Subject: Strange read_passphrase behaviour ? Message-ID: <20020127085624.GA79100@messi.uku.fi> Hi, I'm sorry if this has already come up on the list, I did a quick search of the archive and didn't notice it. I noticed IMHO strange behavior in read_passphrase: If readpassphrase returns NULL and sets errno to ENOTTY, then read_passphrase returns an empty passphrase to the caller instead of error, now what happens with password authentication is that if readpassphrase fails every time then ssh sends 3 empty passwords to the server. Is this the expected behaviour ? -Jarno -- Jarno Huuskonen From markus at openbsd.org Mon Jan 28 01:20:21 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 27 Jan 2002 15:20:21 +0100 Subject: [PATCH] Connect timeout In-Reply-To: <3C533193.33910695@free.fr>; from jclonguet@free.fr on Sat, Jan 26, 2002 at 11:45:39PM +0100 References: <3C533193.33910695@free.fr> Message-ID: <20020127152021.D30885@folly> On Sat, Jan 26, 2002 at 11:45:39PM +0100, Jean-Charles Longuet wrote: > The attached patch adds a new 'ConnectTimeout' option (man page updated > in patch) to avoid wasting time when the target host is down. I needed that > because I was using rsync/rdist over ssh for massive files update and the > default connect() took too long for my purpose. please no setjmp. you can use async connects and select, like the rest of openssh. -m From markus at openbsd.org Mon Jan 28 01:23:11 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 27 Jan 2002 15:23:11 +0100 Subject: Strange read_passphrase behaviour ? In-Reply-To: <20020127085624.GA79100@messi.uku.fi>; from Jarno.Huuskonen@uku.fi on Sun, Jan 27, 2002 at 10:56:24AM +0200 References: <20020127085624.GA79100@messi.uku.fi> Message-ID: <20020127152311.E30885@folly> why do you get ENOTTY? should ssh auto-set Batchmode=yes for ENOTTY? On Sun, Jan 27, 2002 at 10:56:24AM +0200, Jarno Huuskonen wrote: > Hi, > > I'm sorry if this has already come up on the list, I did a quick search > of the archive and didn't notice it. > > I noticed IMHO strange behavior in read_passphrase: > > If readpassphrase returns NULL and sets errno to ENOTTY, then > read_passphrase returns an empty passphrase to the caller instead of > error, now what happens with password authentication is that > if readpassphrase fails every time then ssh sends 3 empty passwords to > the server. > > Is this the expected behaviour ? > > -Jarno > > -- > Jarno Huuskonen > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Mon Jan 28 01:25:32 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 27 Jan 2002 15:25:32 +0100 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from tori@ringstrom.mine.nu on Sat, Jan 26, 2002 at 08:47:45PM +0100 References: Message-ID: <20020127152532.F30885@folly> On Sat, Jan 26, 2002 at 08:47:45PM +0100, Tobias Ringstrom wrote: > Hello again! > > Since there was some resistance against adding TCP_NODELAY uncontionally, > I've made another patch. The new patch contains the following: > > * Added a NoDelay yes/no (default no) config option to ssh and sshd default yes :) > * Added -oNoDelay=yes to the ssh command line for sftp. > > * Changed the sshd subsystem config option syntax from > Subsystem name path > to > Subsystem name options path i don't like this. i'd rather add a per-channel option to the protocol for requesting nodelay. From Jarno.Huuskonen at uku.fi Mon Jan 28 04:23:31 2002 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Sun, 27 Jan 2002 19:23:31 +0200 Subject: Strange read_passphrase behaviour ? In-Reply-To: <20020127152311.E30885@folly> References: <20020127085624.GA79100@messi.uku.fi> <20020127152311.E30885@folly> Message-ID: <20020127172331.GA90182@messi.uku.fi> On Sun, Jan 27, Markus Friedl wrote: > why do you get ENOTTY? I think it was the util-linux bug where login didn't set controlling tty. It was on some test install box that had the buggy util-linux and it didn't have eth0 configured. If I logged in as root and manually brought eth0 up then ssh some.host.com would fail to read the password and just send empty password three times to some.host.com (open(/dev/tty) returned -1). (Funny thing was that after logout/login (when eth0 was up) ssh was able to read the password from tty). The tty problem is/was something with util-linux, but I think that ssh should handle ENOTTY more "gracefully". > should ssh auto-set Batchmode=yes for ENOTTY? This might work. I'll try to test it (I still have the buggy util-linux around). BTW I failed to mention that I tested this with openssh-3.0.2p1. -Jarno -- Jarno Huuskonen From bowman at math.ualberta.ca Mon Jan 28 06:45:15 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 27 Jan 2002 19:45:15 -0000 Subject: [PATCH] Fix for hang-on-exit bug in OpenSSH-3.0.2p1 Message-ID: <20020127194515.8388.qmail@wizard.math.ualberta.ca> Here is a simpler patch (based on Markus Friedl's suggestion posted to this list) to OpenSSH-3.0.2p1 to fix the hang-on-exit bug (Protocol 2 only). To date, no data loss has been reported with this patch: it does not break ssh or scp. This patch should make OpenSSH work on all operating systems exactly as it does under FreeBSD. This patch and others are maintained on the http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-3.0.2p1/clientloop.c openssh-3.0.2p1J2/clientloop.c --- openssh-3.0.2p1/clientloop.c Sun Nov 11 17:06:33 2001 +++ openssh-3.0.2p1J2/clientloop.c Sat Jan 19 15:55:44 2002 @@ -445,9 +445,12 @@ len = read(connection_in, buf, sizeof(buf)); if (len == 0) { /* Received EOF. The remote host has closed the connection. */ +/* This message duplicates the one already in client_loop(). */ +#if 0 snprintf(buf, sizeof buf, "Connection to %.300s closed by remote host.\r\n", host); buffer_append(&stderr_buffer, buf, strlen(buf)); +#endif quit_pending = 1; return; } diff -ur openssh-3.0.2p1/session.c openssh-3.0.2p1J2/session.c --- openssh-3.0.2p1/session.c Sat Dec 1 16:37:08 2001 +++ openssh-3.0.2p1J2/session.c Sat Jan 19 15:56:32 2002 @@ -1929,6 +1929,8 @@ */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) + chan_read_failed(c); s->chanid = -1; } From bowman at math.ualberta.ca Mon Jan 28 06:46:55 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 27 Jan 2002 19:46:55 -0000 Subject: [PATCH] Add user-dependent IdentityFile to OpenSSH-3.0.2p1 Message-ID: <20020127194655.8404.qmail@wizard.math.ualberta.ca> Here is a patch to allow private key files to be placed system wide (for all users) in a secure (non-NFS) mounted location on systems where home directories are NFS mounted. This is especially important for users who use blank passphrases rather than ssh-agent (a good example of where this is necessary is for tunnelling lpd through ssh on systems that run lpd as user lp). IdentityFile now accepts the same %u, %h, %% options that AuthorizedKeysFile accepts (see man sshd). For example, one can specify a user-dependent IdentityFile in ssh_config: IdentityFile /ssh/%u/id_rsa This patch and others are maintained on the http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-3.0.2p1/auth.c openssh-3.0.2p1I/auth.c --- openssh-3.0.2p1/auth.c Sun Nov 11 17:06:07 2001 +++ openssh-3.0.2p1I/auth.c Sun Jan 27 12:05:14 2002 @@ -44,7 +44,6 @@ #include "auth.h" #include "auth-options.h" #include "canohost.h" -#include "buffer.h" #include "bufaux.h" #include "uidswap.h" #include "tildexpand.h" @@ -239,62 +238,6 @@ return 0; } - -/* - * Given a template and a passwd structure, build a filename - * by substituting % tokenised options. Currently, %% becomes '%', - * %h becomes the home directory and %u the username. - * - * This returns a buffer allocated by xmalloc. - */ -char * -expand_filename(const char *filename, struct passwd *pw) -{ - Buffer buffer; - char *file; - const char *cp; - - /* - * Build the filename string in the buffer by making the appropriate - * substitutions to the given file name. - */ - buffer_init(&buffer); - for (cp = filename; *cp; cp++) { - if (cp[0] == '%' && cp[1] == '%') { - buffer_append(&buffer, "%", 1); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'h') { - buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'u') { - buffer_append(&buffer, pw->pw_name, - strlen(pw->pw_name)); - cp++; - continue; - } - buffer_append(&buffer, cp, 1); - } - buffer_append(&buffer, "\0", 1); - - /* - * Ensure that filename starts anchored. If not, be backward - * compatible and prepend the '%h/' - */ - file = xmalloc(MAXPATHLEN); - cp = buffer_ptr(&buffer); - if (*cp != '/') - snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); - else - strlcpy(file, cp, MAXPATHLEN); - - buffer_free(&buffer); - return file; -} - char * authorized_keys_file(struct passwd *pw) { diff -ur openssh-3.0.2p1/auth.h openssh-3.0.2p1I/auth.h --- openssh-3.0.2p1/auth.h Tue Jul 3 22:46:57 2001 +++ openssh-3.0.2p1I/auth.h Sun Jan 27 12:05:14 2002 @@ -138,7 +138,6 @@ struct passwd * auth_get_user(void); -char *expand_filename(const char *, struct passwd *); char *authorized_keys_file(struct passwd *); char *authorized_keys_file2(struct passwd *); diff -ur openssh-3.0.2p1/ssh.c openssh-3.0.2p1I/ssh.c --- openssh-3.0.2p1/ssh.c Sun Nov 11 16:52:04 2001 +++ openssh-3.0.2p1I/ssh.c Sun Jan 27 12:05:14 2002 @@ -1212,9 +1212,13 @@ key_free(public); } #endif /* SMARTCARD */ + struct passwd *pw; + pw=getpwuid(original_real_uid); + if (!pw) fatal("Unknown user id: %d", original_real_uid); for (; i < options.num_identity_files; i++) { filename = tilde_expand_filename(options.identity_files[i], original_real_uid); + filename = expand_filename(filename,pw); public = key_load_public(filename, NULL); debug("identity file %s type %d", filename, public ? public->type : -1); diff -ur openssh-3.0.2p1/tildexpand.c openssh-3.0.2p1I/tildexpand.c --- openssh-3.0.2p1/tildexpand.c Wed Aug 15 17:19:22 2001 +++ openssh-3.0.2p1I/tildexpand.c Sun Jan 27 12:05:14 2002 @@ -16,6 +16,7 @@ #include "xmalloc.h" #include "log.h" #include "tildexpand.h" +#include "buffer.h" /* * Expands tildes in the file name. Returns data allocated by xmalloc. @@ -47,7 +48,7 @@ if (userlen == 0) pw = getpwuid(my_uid); /* Own home directory. */ else { - /* Tilde refers to someone elses home directory. */ + /* Tilde refers to someone else's home directory. */ if (userlen > sizeof(user) - 1) fatal("User name after tilde too long."); memcpy(user, filename, userlen); @@ -70,3 +71,58 @@ snprintf(expanded, len, "%s%s%s", pw->pw_dir, strcmp(pw->pw_dir, "/") ? "/" : "", cp + 1); return expanded; } + +/* + * Given a template and a passwd structure, build a filename + * by substituting % tokenised options. Currently, %% becomes '%', + * %h becomes the home directory and %u the username. + * + * This returns a buffer allocated by xmalloc. + */ +char * +expand_filename(const char *filename, struct passwd *pw) +{ + Buffer buffer; + char *file; + const char *cp; + + /* + * Build the filename string in the buffer by making the appropriate + * substitutions to the given file name. + */ + buffer_init(&buffer); + for (cp = filename; *cp; cp++) { + if (cp[0] == '%' && cp[1] == '%') { + buffer_append(&buffer, "%", 1); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'h') { + buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'u') { + buffer_append(&buffer, pw->pw_name, + strlen(pw->pw_name)); + cp++; + continue; + } + buffer_append(&buffer, cp, 1); + } + buffer_append(&buffer, "\0", 1); + + /* + * Ensure that filename starts anchored. If not, be backward + * compatible and prepend the '%h/' + */ + file = xmalloc(MAXPATHLEN); + cp = buffer_ptr(&buffer); + if (*cp != '/') + snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); + else + strlcpy(file, cp, MAXPATHLEN); + + buffer_free(&buffer); + return file; +} diff -ur openssh-3.0.2p1/tildexpand.h openssh-3.0.2p1I/tildexpand.h --- openssh-3.0.2p1/tildexpand.h Tue Jul 3 22:46:58 2001 +++ openssh-3.0.2p1I/tildexpand.h Sun Jan 27 12:05:14 2002 @@ -13,3 +13,4 @@ */ char *tilde_expand_filename(const char *, uid_t); +char *expand_filename(const char *, struct passwd *); From bowman at math.ualberta.ca Mon Jan 28 06:48:09 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 27 Jan 2002 19:48:09 -0000 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 Message-ID: <20020127194809.8437.qmail@wizard.math.ualberta.ca> Here is a patch to add the missing scp -1 and -2 options to eliminate confusion for users familiar with the commercial version of SSH. This patch and others are maintained on the secure nfs (SNFS) web page: http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-3.0.2p1/scp.c openssh-3.0.2p1J2/scp.c --- openssh-3.0.2p1/scp.c Sun Oct 21 18:53:59 2001 +++ openssh-3.0.2p1J2/scp.c Sat Jan 19 15:26:34 2002 @@ -82,6 +82,7 @@ #include "pathnames.h" #include "log.h" #include "misc.h" +#include "compat.h" #ifdef HAVE___PROGNAME extern char *__progname; @@ -242,9 +243,15 @@ addargs(&args, "-oClearAllForwardings yes"); fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:F:")) != -1) switch (ch) { /* User-visible flags. */ + case '1': + addargs(&args, "-oProtocol=1"); + break; + case '2': + addargs(&args, "-oProtocol=2"); + break; case '4': case '6': case 'C': @@ -966,7 +973,7 @@ usage() { (void) fprintf(stderr, - "usage: scp [-pqrvBC46] [-F config] [-S ssh] [-P port] [-c cipher] [-i identity]\n" + "usage: scp [-pqrvBC1246] [-F config] [-S ssh] [-P port] [-c cipher] [-i identity]\n" " [-o option] f1 f2\n" " or: scp [options] f1 ... fn directory\n"); exit(1); From dan at doxpara.com Mon Jan 28 07:08:09 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 27 Jan 2002 12:08:09 -0800 Subject: [PATCH] Add user-dependent IdentityFile to OpenSSH-3.0.2p1 References: <20020127194655.8404.qmail@wizard.math.ualberta.ca> Message-ID: <012d01c1a76e$575df0e0$1701000a@effugas> > IdentityFile now accepts the same %u, %h, %% options that > AuthorizedKeysFile accepts (see man sshd). For example, one can specify a > user-dependent IdentityFile in ssh_config: > > IdentityFile /ssh/%u/id_rsa I like this, but if we're going to be supporting % variables, I'd like to see them supported generically a la Samba. ProxyCommand supports %h and %p, for example, and it starts getting unweildy to mark which substittues what. Perhaps throw a unified parser into readconf.c/ssh.c? That being said, it's really, really useful to have access to % variables. --Dan From mouring at etoh.eviladmin.org Mon Jan 28 06:39:38 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Sun, 27 Jan 2002 13:39:38 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020127194809.8437.qmail@wizard.math.ualberta.ca> from John Bowman at "Jan 27, 2002 07:48:09 pm" Message-ID: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> > Here is a patch to add the missing scp -1 and -2 options to eliminate > confusion for users familiar with the commercial version of SSH. > > This patch and others are maintained on the secure nfs (SNFS) web page: > http://www.math.ualberta.ca/imaging/snfs/ > > -- John Bowman > University of Alberta > > diff -ur openssh-3.0.2p1/scp.c openssh-3.0.2p1J2/scp.c > --- openssh-3.0.2p1/scp.c Sun Oct 21 18:53:59 2001 > +++ openssh-3.0.2p1J2/scp.c Sat Jan 19 15:26:34 2002 > @@ -82,6 +82,7 @@ > #include "pathnames.h" > #include "log.h" > #include "misc.h" > +#include "compat.h" > Why are we adding compat.h? > #ifdef HAVE___PROGNAME > extern char *__progname; > @@ -242,9 +243,15 @@ > addargs(&args, "-oClearAllForwardings yes"); > > fflag = tflag = 0; > - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1) > + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:F:")) != -1) > switch (ch) { > /* User-visible flags. */ > + case '1': > + addargs(&args, "-oProtocol=1"); > + break; > + case '2': > + addargs(&args, "-oProtocol=2"); > + break; The above could be cleaned up to be: case '1': case '2': addargs(&args, "-Protocol=%c", ch) break; Still doubtful it will be accepted since -o provides such abilities. And is even stated in the scp documentation as an exmaple of the -o usage. - Ben From mouring at etoh.eviladmin.org Mon Jan 28 06:44:50 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Sun, 27 Jan 2002 13:44:50 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> from mouring at "Jan 27, 2002 01:39:38 pm" Message-ID: <200201271944.g0RJiopt024091@etoh.eviladmin.org> > > Here is a patch to add the missing scp -1 and -2 options to eliminate > > confusion for users familiar with the commercial version of SSH. > > > > This patch and others are maintained on the secure nfs (SNFS) web page: > > http://www.math.ualberta.ca/imaging/snfs/ > > > > -- John Bowman > > University of Alberta > > > > diff -ur openssh-3.0.2p1/scp.c openssh-3.0.2p1J2/scp.c > > --- openssh-3.0.2p1/scp.c Sun Oct 21 18:53:59 2001 > > +++ openssh-3.0.2p1J2/scp.c Sat Jan 19 15:26:34 2002 > > @@ -82,6 +82,7 @@ > > #include "pathnames.h" > > #include "log.h" > > #include "misc.h" > > +#include "compat.h" > > > Why are we adding compat.h? > > > > #ifdef HAVE___PROGNAME > > extern char *__progname; > > @@ -242,9 +243,15 @@ > > addargs(&args, "-oClearAllForwardings yes"); > > > > fflag = tflag = 0; > > - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1) > > + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:F:")) != -1) > > switch (ch) { > > /* User-visible flags. */ > > > + case '1': > > + addargs(&args, "-oProtocol=1"); > > + break; > > + case '2': > > + addargs(&args, "-oProtocol=2"); > > + break; > The above could be cleaned up to be: > > case '1': > case '2': > addargs(&args, "-Protocol=%c", ch) ^^ Missed my 'o' =) but the concept is valid. > break; > > Still doubtful it will be accepted since -o provides such abilities. And > is even stated in the scp documentation as an exmaple of the -o usage. > > - Ben > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dan at doxpara.com Mon Jan 28 07:49:04 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 27 Jan 2002 12:49:04 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> Message-ID: <013801c1a774$0ea00ea0$1701000a@effugas> > case '1': > case '2': > addargs(&args, "-Protocol=%c", ch) > break; > > Still doubtful it will be accepted since -o provides such abilities. And > is even stated in the scp documentation as an exmaple of the -o usage. SCP is conceptually a special case execution of SSH that copies files using the RCP syntax. Ideally, it should support the subset of options in SSH still relevant to file copying. By my count, they are: === -l user Log in using this user name. -F config Config file (default: ~/.ssh/config). -i file Identity for public key authentication (default: ~/.ssh/identity) -v Verbose; display verbose debugging messages. Multiple -v increases verbosity. -V Display version number only. -P Don't allocate a privileged port. -q Quiet; don't display any warning messages. -f Fork into background after authentication. -c cipher Select encryption algorithm -m macs Specify MAC algorithms for protocol version 2. -p port Connect to this port. Server must be on the same port. -C Enable compression. -1 Force protocol version 1. -2 Force protocol version 2. -4 Use IPv4 only. -6 Use IPv6 only. -o 'option' Process the option as if it was read from a configuration file. -b addr Local IP address. === Status on these: -l: unsupported -F config: supported -i file: supported -v: supported -V: supported -P: unsupported; overloaded for -p conflict, may reference historical port shifting command -q: supported -f: unsupported (but kinda cool -- copy in background?) -c: supported -m: unsupported -p: overloaded onto -P due to "preserve times" conflict from historical context -C: supported -1: unsupported -2: unsupported -4: supported -6: supported -o option: supported -b addr: unsupported For all command line options, we've already determined that these were all *such* important parameters to ssh that they deserve to be triggerable using quick mnemonics and documented in the short list of SSH options. So the decision has already been made to go above and beyond -o syntax; the question now is whether that decision should continue onto SCP. I think, given the fact that we support the majority of relevant options from SSH at present, we should try to be consistent and support all arguments that have a relevant context and don't conflict with existing command line options. That would mean adding support for: -l -m -1 -2 -b addr and if someone is a bit masochistic, -f It's just a matter of consistency -- though, to be honest, since protocol declaration impacts security pretty directly, both in terms of communication privacy and authentication methods, it's really hard to claim -1/-2 aren't completely appropriate for SCP regardless of "Well, it works in SSH". --Dan From bowman at math.ualberta.ca Mon Jan 28 06:49:41 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 27 Jan 2002 19:49:41 -0000 Subject: [PATCH] Add an exit delay to Openssh-3.0.2p1 for use in tunneling Message-ID: <20020127194941.8453.qmail@wizard.math.ualberta.ca> Here is a patch to implement an exit delay in OpenSSH-3.0.2p1, proposed by John Hardin. This is his description of the feature: New option for OpenSSH: Delay before exit. Command line option: -S delay Config file option: sleep {delay} Purpose: Wait the specified number of seconds after last traffic before dropping the connection and exiting. If ports are forwarded, this causes the ssh client to allow another forwarded connection to begin after the current one closes. This permits multiple sequential port-forwarded connections without using a long-running remote sleep command. For example, for fetchmail polling of several accounts on a remote POP server over an SSH tunnel, you might say: ssh -n -L 11000:popserver:110 -S 30 host exit or ssh -N -L 11000:popserver:110 -S 30 host The ssh client would exit after thirty seconds of inactivity, rather than exiting immediately when the first forwarded connection closes. This would allow multiple sequential POP sessions to be carried over the same tunnel without specifying a long-running remote sleep command. Why not just use a long-running remote sleep command? In the above example, you may wish the ssh session to terminate promptly if no new mail is spooled: maybe this is running over a demand-dialled ISP connection. The -S option also removes the need to run a sleep command on the remote host in the first place. A delay value of zero means wait forever. This patch and others are maintained on the secure nfs (SNFS) web page: http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-3.0.2p1/clientloop.c openssh-3.0.2p1S/clientloop.c --- openssh-3.0.2p1/clientloop.c Sun Nov 11 17:06:33 2001 +++ openssh-3.0.2p1S/clientloop.c Sat Jan 19 14:50:11 2002 @@ -84,6 +84,7 @@ /* import options */ extern Options options; +extern int no_tty_flag; /* Flag indicating that stdin should be redirected from /dev/null. */ extern int stdin_null_flag; @@ -122,7 +123,8 @@ static int connection_in; /* Connection to server (input). */ static int connection_out; /* Connection to server (output). */ static int need_rekeying; /* Set to non-zero if rekeying is requested. */ -static int session_closed = 0; /* In SSH2: login session closed. */ +enum SessionStatus {SessionOpen, SessionClose, SessionWait}; +static int session_status = SessionOpen; /* In SSH2: login session closed. */ static void client_init_dispatch(void); int session_ident = -1; @@ -320,6 +322,10 @@ client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int *nallocp, int rekeying) { + struct timeval timer; + struct timeval *timerp; + int rc; + /* Add any selections by the channel mechanism. */ channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, rekeying); @@ -343,7 +349,7 @@ FD_SET(fileno(stderr), *writesetp); } else { /* channel_prepare_select could have closed the last channel */ - if (session_closed && !channel_still_open() && + if (session_status == SessionClose && !channel_still_open() && !packet_have_data_to_write()) { /* clear mask since we did not call select() */ memset(*readsetp, 0, *nallocp); @@ -367,7 +373,16 @@ * SSH_MSG_IGNORE packet when the timeout expires. */ - if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) { + if(session_status == SessionWait && options.sleep > 0) { + timer.tv_sec=options.sleep > 0 ? options.sleep : 0; + timer.tv_usec=0; + timerp=&timer; + } else { + timerp=NULL; + } + + rc=select((*maxfdp)+1, *readsetp, *writesetp, NULL, timerp); + if (rc < 0) { char buf[100]; /* @@ -384,7 +399,8 @@ snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; - } + } else if (rc == 0 && session_status == SessionWait) + session_status=SessionClose; } static void @@ -760,7 +776,7 @@ error("client_channel_closed: id %d != session_ident %d", id, session_ident); channel_cancel_cleanup(id); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -785,6 +801,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -848,7 +865,8 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat20 && (session_status == SessionClose) + && !channel_still_open()) break; rekeying = (xxx_kex != NULL && !xxx_kex->done); diff -ur openssh-3.0.2p1/readconf.c openssh-3.0.2p1S/readconf.c --- openssh-3.0.2p1/readconf.c Wed Oct 3 11:39:39 2001 +++ openssh-3.0.2p1S/readconf.c Sat Jan 19 14:49:50 2002 @@ -115,7 +115,7 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, oSleep } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +187,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "sleep", oSleep }, { NULL, 0 } }; @@ -528,6 +529,10 @@ intptr = &options->connection_attempts; goto parse_int; + case oSleep: + intptr = &options->sleep; + goto parse_int; + case oCipher: intptr = &options->cipher; arg = strdelim(&s); @@ -799,6 +804,7 @@ options->bind_address = NULL; options->smartcard_device = NULL; options->no_host_authentication_for_localhost = - 1; + options->sleep = -1; } /* diff -ur openssh-3.0.2p1/readconf.h openssh-3.0.2p1S/readconf.h --- openssh-3.0.2p1/readconf.h Wed Oct 3 11:39:39 2001 +++ openssh-3.0.2p1S/readconf.h Sat Jan 19 14:49:50 2002 @@ -102,6 +102,7 @@ Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; int no_host_authentication_for_localhost; + int sleep; /* Exit delay in seconds */ } Options; diff -ur openssh-3.0.2p1/ssh.c openssh-3.0.2p1S/ssh.c --- openssh-3.0.2p1/ssh.c Sun Nov 11 16:52:04 2001 +++ openssh-3.0.2p1S/ssh.c Sat Jan 19 14:49:51 2002 @@ -187,6 +187,7 @@ fprintf(stderr, " These cause %s to listen for connections on a port, and\n", __progname); fprintf(stderr, " forward them to the other side by connecting to host:port.\n"); fprintf(stderr, " -D port Enable dynamic application-level port forwarding.\n"); + fprintf(stderr, " -S delay Set exit delay (in seconds; 0 means wait forever).\n"); fprintf(stderr, " -C Enable compression.\n"); fprintf(stderr, " -N Do not execute a shell or command.\n"); fprintf(stderr, " -g Allow remote hosts to connect to forwarded ports.\n"); @@ -312,7 +313,7 @@ again: while ((opt = getopt(ac, av, - "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) { + "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:S:TVX")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -487,7 +488,13 @@ add_remote_forward(&options, fwd_port, buf, fwd_host_port); break; - + case 'S': + options.sleep = atoi(optarg); + if (options.sleep < 0) { + fprintf(stderr, "Bad delay value '%s'\n", optarg); + exit(1); + } + break; case 'D': fwd_port = a2port(optarg); if (fwd_port == 0) { From stevesk at pobox.com Mon Jan 28 10:23:15 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 27 Jan 2002 15:23:15 -0800 (PST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <013801c1a774$0ea00ea0$1701000a@effugas> Message-ID: On Sun, 27 Jan 2002, Dan Kaminsky wrote: :It's just a matter of consistency -- though, to be honest, since protocol :declaration impacts security pretty directly, both in terms of communication :privacy and authentication methods, i have no idea what this means. :it's really hard to claim -1/-2 aren't :completely appropriate for SCP regardless of "Well, it works in SSH". the general approach is that programs that use ssh for transport don't inherit all the ssh command line options, -o is used instead. From stevesk at pobox.com Mon Jan 28 10:28:08 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 27 Jan 2002 15:28:08 -0800 (PST) Subject: [PATCH] Connect timeout In-Reply-To: <3C533193.33910695@free.fr> Message-ID: On Sat, 26 Jan 2002, Jean-Charles Longuet wrote: : The patch was tested on Linux only, but I used a similar one for ssh 1.2.XX :on Linux, Solaris and HP-UX without problems. + case oConnectTimeout: + intptr = &options->connection_timeout; + goto parse_int; + look at servconf.c for parse_time. From stevesk at pobox.com Mon Jan 28 10:47:03 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 27 Jan 2002 15:47:03 -0800 (PST) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: Message-ID: On Sat, 26 Jan 2002, Tobias Ringstrom wrote: :So, what do you all think? The patch is for openssh-3.0.2p1. what is the overall methodology you have for openssh and nagle? i'd rather not have a tunable for every possible TCP endpoint and usage variation. my somewhat high-level thoughts are currently: non-ssh connection endpoints (those not going over the SSH transport) should not use nagle: connect_to(), channel_post_port_lister() for the ssh transport connection, we use nagle by default only if it is a session channel with a pty and shell or exec channel other channel types would cause connection to be nodelay on both sides (as determined and set by ssh and sshd) nodelay yes/no would be available to change default for pty,shell,exec only behavior. From stevesk at pobox.com Mon Jan 28 11:08:30 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 27 Jan 2002 16:08:30 -0800 (PST) Subject: Interest in ssh-agent connection retry patch? In-Reply-To: <20020127035504.GG40862@lizzy.bugworks.com> Message-ID: On Sat, 26 Jan 2002, Jos Backus wrote: :The first ssh processes will block, waiting in the ssh-agent's listen() queue, :subsequent ssh processes get ECONNREFUSED. First I tried increasing the :listen() queue in ssh-agent, but that didn't really help much, and it's not :very portable (I have heard that there are UNIX versions which ignore any :value greater than 5). what OS are you using? From josb at cncdsl.com Mon Jan 28 13:20:40 2002 From: josb at cncdsl.com (Jos Backus) Date: Sun, 27 Jan 2002 18:19:40 -0801 Subject: Interest in ssh-agent connection retry patch? In-Reply-To: References: <20020127035504.GG40862@lizzy.bugworks.com> Message-ID: <20020128022002.GA30180@lizzy.bugworks.com> On Sun, Jan 27, 2002 at 04:08:30PM -0800, Kevin Steves wrote: > On Sat, 26 Jan 2002, Jos Backus wrote: > :The first ssh processes will block, waiting in the ssh-agent's listen() > queue, :subsequent ssh processes get ECONNREFUSED. First I tried increasing > the :listen() queue in ssh-agent, but that didn't really help much, and it's > not :very portable (I have heard that there are UNIX versions which ignore > any :value greater than 5). > > what OS are you using? This is on Solaris [78], both i386 and sparc. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From dan at doxpara.com Mon Jan 28 15:05:48 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 27 Jan 2002 20:05:48 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: Message-ID: <018001c1a7b1$11b37c70$1701000a@effugas> > :It's just a matter of consistency -- though, to be honest, since protocol > :declaration impacts security pretty directly, both in terms of communication > :privacy and authentication methods, > > i have no idea what this means. SCP stands for _SECURE_ copy, as opposed to the insecure "remote" copy. So options that have direct impact on security are actually the most critical for SCP to implement. > :it's really hard to claim -1/-2 aren't > :completely appropriate for SCP regardless of "Well, it works in SSH". > > the general approach is that programs that use ssh for transport don't > inherit all the ssh command line options, -o is used instead. Programs that use SSH for transport aren't generally a part of the SSH distribution; SCP is -- note the direct support for selecting cryptographic ciphers or the presence of compression. This is rather different than, say, rsync over ssh. Surely, in a secure copying tool, the cryptographic protocol used to exchange data is of greater, not lesser importance than whether the datastream is compressed! That being said, the main difference pragmatically between SCP and rsync is that rsync uses an encapsulation option -- -e -- to capture whatever options are desired inside a fully described executable command, like so: rsync -e "ssh -2 -C -c blowfish" foo user at bar:/foo By contrast, SCP's option for selecting the encapsulator doesn't support arbitrary options at all; it just provides a path to a binary. This is considerably less flexible, but does enforce the meaningfulness of options like -C and -c. The equivalent to the above, using the patched syntax, is: scp -2 -C -c blowfish foo user at bar:/foo Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com From bowman at math.ualberta.ca Mon Jan 28 15:52:39 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 28 Jan 2002 04:52:39 -0000 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> (message from mouring on Sun, 27 Jan 2002 13:39:38 -0600 (CST)) References: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> Message-ID: <20020128045239.26419.qmail@wizard.math.ualberta.ca> > The above could be cleaned up to be: Agreed. All that we need is the following. With so few changes required to fix such a trivial oversight in scp, there can no rational argument against implementing a fix. You will note that this issue keeps reappearing on this list; it isn't going to go away on its own. :-) -- John Bowman University of Alberta diff -ur openssh-3.0.2p1/scp.c openssh-3.0.2p1C/scp.c --- openssh-3.0.2p1/scp.c Sun Oct 21 18:53:59 2001 +++ openssh-3.0.2p1C/scp.c Sun Jan 27 18:12:23 2002 @@ -242,9 +242,13 @@ addargs(&args, "-oClearAllForwardings yes"); fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:F:")) != -1) switch (ch) { /* User-visible flags. */ + case '1': + case '2': + addargs(&args, "-oProtocol=%c",ch); + break; case '4': case '6': case 'C': @@ -966,7 +970,7 @@ usage() { (void) fprintf(stderr, - "usage: scp [-pqrvBC46] [-F config] [-S ssh] [-P port] [-c cipher] [-i identity]\n" + "usage: scp [-pqrvBC1246] [-F config] [-S ssh] [-P port] [-c cipher] [-i identity]\n" " [-o option] f1 f2\n" " or: scp [options] f1 ... fn directory\n"); exit(1); From mouring at etoh.eviladmin.org Mon Jan 28 15:45:10 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Sun, 27 Jan 2002 22:45:10 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128045239.26419.qmail@wizard.math.ualberta.ca> from John Bowman at "Jan 28, 2002 04:52:39 am" Message-ID: <200201280445.g0S4jAWd000204@etoh.eviladmin.org> > > The above could be cleaned up to be: > > Agreed. All that we need is the following. With so few changes required to > fix such a trivial oversight in scp, there can no rational argument against > implementing a fix. You will note that this issue keeps reappearing on this > list; it isn't going to go away on its own. :-) > It is? You are the first to bring up -1/-2 for over at least two months if memory serves.. Maybe even longer. I'll admit the last 4 days I've not been following the last as closely due to replacing dead webservers and attempting to do data recovery. - Ben From ramesh at spower.com.sg Mon Jan 28 17:50:56 2002 From: ramesh at spower.com.sg (Ramesh Dharma) Date: Mon, 28 Jan 2002 14:50:56 +0800 Subject: sftp failed on channel 0 Message-ID: Hi , I just recently installed OpenSSH_3.0.2p1 on a HP-UX box. The ssh works fine but the sftp is not. There is a firewall in between both the machine. Only SSH port is allowed from the source host to the destination machine. ssh works fine across the firewall. Below is the log. Thanks in advance . ~~~~~~~~~~~~~~~~~~~~~~~~~~~` sftp spdns1 Connecting to spdns1... smorrx at spdns1's password: Request for subsystem 'sftp' failed on channel 0 Connection closed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` Cheers, Ramesh From pekkas at netcore.fi Mon Jan 28 18:18:10 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 28 Jan 2002 09:18:10 +0200 (EET) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201280445.g0S4jAWd000204@etoh.eviladmin.org> Message-ID: On Sun, 27 Jan 2002, mouring wrote: > > > The above could be cleaned up to be: > > > > Agreed. All that we need is the following. With so few changes required to > > fix such a trivial oversight in scp, there can no rational argument against > > implementing a fix. You will note that this issue keeps reappearing on this > > list; it isn't going to go away on its own. :-) > > > > It is? You are the first to bring up -1/-2 for over at least two > months if memory serves.. Maybe even longer. I recall that scp had -1/-2 support a long, long time ago (2.0, 2.1 era), but it was removed and people were told to use -o (by Theo de Raadt IIRC). However, I couldn't find confirmation for this in ChangeLog, so I may be misremembering this for some other -1/-2 issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Mon Jan 28 18:10:11 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Mon, 28 Jan 2002 01:10:11 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: from Pekka Savola at "Jan 28, 2002 09:18:10 am" Message-ID: <200201280710.g0S7AB32021616@etoh.eviladmin.org> > On Sun, 27 Jan 2002, mouring wrote: > > > > The above could be cleaned up to be: > > > > > > Agreed. All that we need is the following. With so few changes required to > > > fix such a trivial oversight in scp, there can no rational argument against > > > implementing a fix. You will note that this issue keeps reappearing on this > > > list; it isn't going to go away on its own. :-) > > > > > > > It is? You are the first to bring up -1/-2 for over at least two > > months if memory serves.. Maybe even longer. > > I recall that scp had -1/-2 support a long, long time ago (2.0, 2.1 era), > but it was removed and people were told to use -o (by Theo de Raadt IIRC). > However, I couldn't find confirmation for this in ChangeLog, so I may be > misremembering this for some other -1/-2 issue. > Unless it was added then removed. It was not there on the day the code was checked into the CVS tree on sept 26, 1999. Oct 11, 2000 is when -o came into being. Don't know where you got he idea -1/02 was supported by scp. Unless you are thinking when ssh gained -1 and -2 which was Feb 6th, 2001 and Apr 14th, 2000--respectively (geesh, almost a year apart!).. People complained about lack of -1/-2 in scp.c (thus the -o and 'addargs()' code was created), but OpenSSH has never had a -1/-2 for scp - Ben From bowman at math.ualberta.ca Mon Jan 28 10:16:48 2002 From: bowman at math.ualberta.ca (John Bowman) Date: 27 Jan 2002 23:16:48 -0000 Subject: IdentityFile patch Message-ID: <20020127231648.9600.qmail@wizard.math.ualberta.ca> By the way, I noticed in the previous IdentityFile patch I forgot to expand tilde. I fixed this by making the change in ssh.c instead of readconf.c, which is probably where it belongs, as far as the existing code is concerned: diff -ur openssh-3.0.2p1/auth.c openssh-3.0.2p1I/auth.c --- openssh-3.0.2p1/auth.c Sun Nov 11 17:06:07 2001 +++ openssh-3.0.2p1I/auth.c Sun Jan 27 12:05:14 2002 @@ -44,7 +44,6 @@ #include "auth.h" #include "auth-options.h" #include "canohost.h" -#include "buffer.h" #include "bufaux.h" #include "uidswap.h" #include "tildexpand.h" @@ -239,62 +238,6 @@ return 0; } - -/* - * Given a template and a passwd structure, build a filename - * by substituting % tokenised options. Currently, %% becomes '%', - * %h becomes the home directory and %u the username. - * - * This returns a buffer allocated by xmalloc. - */ -char * -expand_filename(const char *filename, struct passwd *pw) -{ - Buffer buffer; - char *file; - const char *cp; - - /* - * Build the filename string in the buffer by making the appropriate - * substitutions to the given file name. - */ - buffer_init(&buffer); - for (cp = filename; *cp; cp++) { - if (cp[0] == '%' && cp[1] == '%') { - buffer_append(&buffer, "%", 1); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'h') { - buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); - cp++; - continue; - } - if (cp[0] == '%' && cp[1] == 'u') { - buffer_append(&buffer, pw->pw_name, - strlen(pw->pw_name)); - cp++; - continue; - } - buffer_append(&buffer, cp, 1); - } - buffer_append(&buffer, "\0", 1); - - /* - * Ensure that filename starts anchored. If not, be backward - * compatible and prepend the '%h/' - */ - file = xmalloc(MAXPATHLEN); - cp = buffer_ptr(&buffer); - if (*cp != '/') - snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); - else - strlcpy(file, cp, MAXPATHLEN); - - buffer_free(&buffer); - return file; -} - char * authorized_keys_file(struct passwd *pw) { diff -ur openssh-3.0.2p1/auth.h openssh-3.0.2p1I/auth.h --- openssh-3.0.2p1/auth.h Tue Jul 3 22:46:57 2001 +++ openssh-3.0.2p1I/auth.h Sun Jan 27 12:05:14 2002 @@ -138,7 +138,6 @@ struct passwd * auth_get_user(void); -char *expand_filename(const char *, struct passwd *); char *authorized_keys_file(struct passwd *); char *authorized_keys_file2(struct passwd *); diff -ur openssh-3.0.2p1/ssh.c openssh-3.0.2p1I/ssh.c --- openssh-3.0.2p1/ssh.c Sun Nov 11 16:52:04 2001 +++ openssh-3.0.2p1I/ssh.c Sun Jan 27 12:05:14 2002 @@ -1212,9 +1212,13 @@ key_free(public); } #endif /* SMARTCARD */ + struct passwd *pw; + pw=getpwuid(original_real_uid); + if (!pw) fatal("Unknown user id: %d", original_real_uid); for (; i < options.num_identity_files; i++) { filename = tilde_expand_filename(options.identity_files[i], original_real_uid); + filename = expand_filename(filename,pw); public = key_load_public(filename, NULL); debug("identity file %s type %d", filename, public ? public->type : -1); diff -ur openssh-3.0.2p1/tildexpand.c openssh-3.0.2p1I/tildexpand.c --- openssh-3.0.2p1/tildexpand.c Wed Aug 15 17:19:22 2001 +++ openssh-3.0.2p1I/tildexpand.c Sun Jan 27 12:05:14 2002 @@ -16,6 +16,7 @@ #include "xmalloc.h" #include "log.h" #include "tildexpand.h" +#include "buffer.h" /* * Expands tildes in the file name. Returns data allocated by xmalloc. @@ -47,7 +48,7 @@ if (userlen == 0) pw = getpwuid(my_uid); /* Own home directory. */ else { - /* Tilde refers to someone elses home directory. */ + /* Tilde refers to someone else's home directory. */ if (userlen > sizeof(user) - 1) fatal("User name after tilde too long."); memcpy(user, filename, userlen); @@ -70,3 +71,58 @@ snprintf(expanded, len, "%s%s%s", pw->pw_dir, strcmp(pw->pw_dir, "/") ? "/" : "", cp + 1); return expanded; } + +/* + * Given a template and a passwd structure, build a filename + * by substituting % tokenised options. Currently, %% becomes '%', + * %h becomes the home directory and %u the username. + * + * This returns a buffer allocated by xmalloc. + */ +char * +expand_filename(const char *filename, struct passwd *pw) +{ + Buffer buffer; + char *file; + const char *cp; + + /* + * Build the filename string in the buffer by making the appropriate + * substitutions to the given file name. + */ + buffer_init(&buffer); + for (cp = filename; *cp; cp++) { + if (cp[0] == '%' && cp[1] == '%') { + buffer_append(&buffer, "%", 1); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'h') { + buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); + cp++; + continue; + } + if (cp[0] == '%' && cp[1] == 'u') { + buffer_append(&buffer, pw->pw_name, + strlen(pw->pw_name)); + cp++; + continue; + } + buffer_append(&buffer, cp, 1); + } + buffer_append(&buffer, "\0", 1); + + /* + * Ensure that filename starts anchored. If not, be backward + * compatible and prepend the '%h/' + */ + file = xmalloc(MAXPATHLEN); + cp = buffer_ptr(&buffer); + if (*cp != '/') + snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); + else + strlcpy(file, cp, MAXPATHLEN); + + buffer_free(&buffer); + return file; +} diff -ur openssh-3.0.2p1/tildexpand.h openssh-3.0.2p1I/tildexpand.h --- openssh-3.0.2p1/tildexpand.h Tue Jul 3 22:46:58 2001 +++ openssh-3.0.2p1I/tildexpand.h Sun Jan 27 12:05:14 2002 @@ -13,3 +13,4 @@ */ char *tilde_expand_filename(const char *, uid_t); +char *expand_filename(const char *, struct passwd *); From markus at openbsd.org Mon Jan 28 19:44:44 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 09:44:44 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: References: <200201280445.g0S4jAWd000204@etoh.eviladmin.org> Message-ID: <20020128084444.GA10384@faui02> On Mon, Jan 28, 2002 at 09:18:10AM +0200, Pekka Savola wrote: > I recall that scp had -1/-2 support a long, long time ago (2.0, 2.1 era), > but it was removed and people were told to use -o (by Theo de Raadt IIRC). > However, I couldn't find confirmation for this in ChangeLog, so I may be > misremembering this for some other -1/-2 issue. usually we don't remove command line options. From markus at openbsd.org Mon Jan 28 19:50:02 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 09:50:02 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <018001c1a7b1$11b37c70$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> Message-ID: <20020128085002.GB10384@faui02> On Sun, Jan 27, 2002 at 08:05:48PM -0800, Dan Kaminsky wrote: > > :It's just a matter of consistency -- though, to be honest, since protocol > > :declaration impacts security pretty directly, both in terms of > communication > > :privacy and authentication methods, > > > > i have no idea what this means. > > SCP stands for _SECURE_ copy, as opposed to the insecure "remote" copy. So > options that have direct impact on security are actually the most critical > for SCP to implement. > > > :it's really hard to claim -1/-2 aren't > > :completely appropriate for SCP regardless of "Well, it works in SSH". > > > > the general approach is that programs that use ssh for transport don't > > inherit all the ssh command line options, -o is used instead. > > Programs that use SSH for transport aren't generally a part of the SSH > distribution; SCP is -- note the direct support for selecting cryptographic > ciphers or the presence of compression. This is rather different than, say, > rsync over ssh. > > Surely, in a secure copying tool, the cryptographic protocol used to > exchange data is of greater, not lesser importance than whether the > datastream is compressed! > > That being said, the main difference pragmatically between SCP and rsync is > that rsync uses an encapsulation option -- -e -- to capture whatever options > are desired inside a fully described executable command, like so: > > rsync -e "ssh -2 -C -c blowfish" foo user at bar:/foo > > By contrast, SCP's option for selecting the encapsulator doesn't support > arbitrary options at all; it just provides a path to a binary. This is > considerably less flexible, but does enforce the meaningfulness of options > like -C and -c. The equivalent to the above, using the patched syntax, is: > > scp -2 -C -c blowfish foo user at bar:/foo no, the equivalent is scp -e "ssh -2 -C -c blowfish" foo user at bar:/foo -m From markus at openbsd.org Mon Jan 28 19:56:53 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 09:56:53 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <013801c1a774$0ea00ea0$1701000a@effugas> References: <200201271939.g0RJdd9X020906@etoh.eviladmin.org> <013801c1a774$0ea00ea0$1701000a@effugas> Message-ID: <20020128085653.GC10384@faui02> i don't like the idea of 'linking' scp to ssh. having non-rcp options in scp is a very bad idea, scp should be independant of the 'transport' that gets used and not depend on any ssh option or a specific ssh implementation. rsync does not depend on ssh options, so scp should either. most of the duplicated ssh options are inherited from scp, so it's hard to change. i'd prefer to remove -c, -i, -B, -4, -6 from scp, but it's too late. From wichert at wiggy.net Mon Jan 28 20:55:39 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 10:55:39 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201280710.g0S7AB32021616@etoh.eviladmin.org> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> Message-ID: <20020128095539.GN31953@wiggy.net> Previously mouring wrote: > Unless it was added then removed. It was not there on the day the code was > checked into the CVS tree on sept 26, 1999. Oct 11, 2000 is when -o came > into being. Debian has used a patch to add -1/-2 to scp for a while now to make things more consistent so it's definitely not a new (or rare) request. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From markus at openbsd.org Mon Jan 28 21:05:34 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 11:05:34 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128095539.GN31953@wiggy.net> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> Message-ID: <20020128100534.GD10384@faui02> On Mon, Jan 28, 2002 at 10:55:39AM +0100, Wichert Akkerman wrote: > Previously mouring wrote: > > Unless it was added then removed. It was not there on the day the code was > > checked into the CVS tree on sept 26, 1999. Oct 11, 2000 is when -o came > > into being. > > Debian has used a patch to add -1/-2 to scp for a while now to make > things more consistent so it's definitely not a new (or rare) request. why do you need -1 and -2? -1 and -2 are only in ssh for debugging (ok, they escaped into the release). From wichert at wiggy.net Mon Jan 28 21:55:03 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 11:55:03 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128100534.GD10384@faui02> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> Message-ID: <20020128105503.GC19577@wiggy.net> Previously Markus Friedl wrote: > why do you need -1 and -2? Users want it, and it's very useful in situations where you need to specifiy the version due to existing keys, old servers, etc. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From markus at openbsd.org Mon Jan 28 22:26:48 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 12:26:48 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128105503.GC19577@wiggy.net> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> Message-ID: <20020128112648.GA17992@faui02> On Mon, Jan 28, 2002 at 11:55:03AM +0100, Wichert Akkerman wrote: > Previously Markus Friedl wrote: > > why do you need -1 and -2? > > Users want it, and it's very useful in situations where you need > to specifiy the version due to existing keys, old servers, etc. hm, should there be an extra option for 0.0001% of all use cases. From wichert at wiggy.net Mon Jan 28 22:48:39 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 12:48:39 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128112648.GA17992@faui02> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> <20020128112648.GA17992@faui02> Message-ID: <20020128114839.GD19577@wiggy.net> Previously Markus Friedl wrote: > hm, should there be an extra option for 0.0001% of all > use cases. Of course not, we don't want to have as many options as ls or tar. In this case I think there are a few good reasons: * there is a lot of ssh1 deployed out there and making it easy for people to work with that so then can migrate is a good thing * there is a precedent in that ssh itself has the -1 and -2 options as well so it's not completely unreasonably to add the same options to scp as well Of course you can argue `scp shouldn't get new options that aren't really needed since there is -o already', but then again you might just as well argue that -1 and -2 should be removed from ssh either. As long as that doesn't happen I don't see Debian dropping the -1 and -2 from scp either. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From dan at doxpara.com Mon Jan 28 23:11:43 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 04:11:43 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> Message-ID: <021701c1a7f4$f3125bd0$1701000a@effugas> > no, the equivalent is > scp -e "ssh -2 -C -c blowfish" foo user at bar:/foo Not supported in scp right now, though I was thinking it'd be a decent idea for a while. Now, I'm not so sure. Mind you -- I *hate* using SCP -- but I finally figured out why it's not entirely useless: We can depend on it to exist on every system with a correctly installed SSH daemon. This is non-trivial -- not only can we not depend on rsync being around, but we can't even depend on tar, cat, and ls: a) Existing at all (win32, for example) b) Behaving entirely predictably (as we've seen from "why doesn't this graphical scp client do ls correctly?") SCP is our backwards and forwards compatible method of knowing we can get files from host a to host b using only what ships with OpenSSH. It shares ssh options because it *is* ssh, minus whatever options have zero bearings on file transfer (like escape characters, or local port forwarding). Perfect? Hell no, that's why we're (slowly) migrating the world to SFTP. _I_ don't use scp. But I respect those who do, and I do understand what needs others have. The reason for needing -1 and -2 is at the intersection between user interface and security -- essentially, if you pick the wrong SSH protocol, your keys don't work, you don't connect, and you can't do anything. That's really painful when you're upgrading from SSH 1.2.27 to OpenSSH 3.0.2p2. The solution is to be able to quickly look at the configuration options for the tool and see an easily accessible option to twiddle. The heirarchy of these options is basically: 1) Start a secure link 2) Specify how secure you want that link 3) Start a file copy, with basic options 4) Specify detailed traits of that copy Generally, the more critical an option, the more you want to make it easily available to a user. The -o set of options is nice to have, and certainly can contain useful things -- but "without this, a good portion of connection attempts will fail outright because you're using the wrong set of keys" style configurations are much more critical and need to be "pushed to the front", if you will. In this typology, -1/-2 are level one critical, and clearly deserve to be fronted. -m and -l are mentioned by me for consistency in the UI -- they're direct options in ssh that refer to security constraints at the same level as -c and -C; they should be supported as they are in the genuine lient. -f is a toy that I can ignore. Yeah, I did do UI design before I got into security :-) --Dan From markus at openbsd.org Mon Jan 28 23:20:56 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 13:20:56 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <021701c1a7f4$f3125bd0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> Message-ID: <20020128122056.GB17992@faui02> On Mon, Jan 28, 2002 at 04:11:43AM -0800, Dan Kaminsky wrote: > Yeah, I did do UI design before I got into security :-) this is why i think -C -c -i should not be in scp. it's an accident to have them in scp. see what happened with -P/-p ? it's nightmare, you cannot have both rcp's and ssh's options in scp. and since scp is basically just rcp calling ssh, scp should have rcp's options plus _one_ simple way of passing options to ssh. so use -F and -o. you cannot have consistency between these 3 programs, so for consistency scp should have _no_ options from ssh, because if it _has_ then people want every option. From wichert at wiggy.net Mon Jan 28 23:34:16 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 13:34:16 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128122056.GB17992@faui02> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> Message-ID: <20020128123416.GA21592@wiggy.net> Previously Markus Friedl wrote: > way of passing options to ssh. so use -F and -o. If you insist on having a simply way to pass options to ssh I would suggest something like the -Wl option for gcc to pass commandline options directly instead of forcing people to use the -o option (which is way too much typing). This will give you commands like: scp -s,-1 -s,-C file remote: where -s simply means `pass this option on to ssh'. You can also get rid of -F and -o then and do them using -s to reduce the non-rcp options to just one. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From sperber at informatik.uni-tuebingen.de Mon Jan 28 23:34:45 2002 From: sperber at informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: Mon, 28 Jan 2002 13:34:45 +0100 Subject: OpenSSH w/ kth-krb4 on AIX In-Reply-To: (sperber@informatik.uni-tuebingen.de's message of "Wed, 23 Jan 2002 17:24:04 +0100") References: Message-ID: >>>>> "Moiself" == Michael Sperber writes: Moiself> Hi, Moiself> I'm suffering from a memory corruption problem when compiling OpenSSH Moiself> 3.0.2p1 with kth-krb4 1.1 on AIX 4.3.2 and 4.3.3. The symptom is that Moiself> the file name gets zeroed out during ssh key generation, for example Moiself> during "make install": Moiself> Generating public/private rsa1 key pair. Moiself> open failed: No such file or directory. Moiself> ^ filename normally goes here Moiself> When I remove krb4 from the install, things work. (For the record, Moiself> this is against zlib 1.1.1 and OpenSSL 0.9.6c.) Has anyone by any Moiself> chance seen this problem? I've done a little bit of gdb on this, but Moiself> so far have been unsuccessful at extracting any useful info. Here's the source of the problem: krb4 and openssl both define RC4_INT, and they define it differently. OpenSSH happens to call some routines from one, and some from the other. Poing! I don't know what to do about this in general. Suggestions? -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From dan at doxpara.com Mon Jan 28 23:46:47 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 04:46:47 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> Message-ID: <023901c1a7f9$d994afa0$1701000a@effugas> > this is why i think -C -c -i should not be in scp. > it's an accident to have them in scp. > see what happened with -P/-p ? it's nightmare, > you cannot have both rcp's and ssh's options > in scp. and since scp is basically just rcp calling > ssh, scp should have rcp's options plus _one_ simple > way of passing options to ssh. so use -F and -o. > > you cannot have consistency between these 3 programs, > so for consistency scp should have _no_ options from > ssh, because if it _has_ then people want every option. rcp's command line has long since been fixed; scp's command line is a bit in flux, and ssh's command line is still growing. That -p/-P is the only serious conflict we've got going is pretty incredible, all things considered. I see where you're coming from. Keeping ssh from stepping on scp's toes, under my method, means we have to keep -r, -B, -S, -d, and -f(oops) out of SSH's "file transfer relevant" set of options. That's a loss to our namespace. It's a cost, yes, but the cause is pretty critical(transfering files is often *more* important than getting a remote shell), and it pales in comparison to requiring somebody to know the mental acrobatics of translating: ssh -1 user at host to scp -o Protocol=1 user at host:/foo . or scp -e "ssh -1" user at host:/foo . or scp -F some_file_with_Protocol_1 user at host:/foo . or whatever. These are awkward -- users and distributions moved the -1 up to primary configuration real estate for a reason. I guess my question to you, Markus, is this: When is an option important enough to add to the command line of ssh, but *not* for the exact same reasons important enough to add to scp? --Dan From dan at doxpara.com Mon Jan 28 23:59:19 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 04:59:19 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <20020128123416.GA21592@wiggy.net> Message-ID: <024301c1a7fb$99c8d430$1701000a@effugas> > scp -s,-1 -s,-C file remote: > > where -s simply means `pass this option on to ssh'. You can also > get rid of -F and -o then and do them using -s to reduce the > non-rcp options to just one. Well, lets look at what happens: scp -r -s,-c blowfish -s,-C -s,-2 - user at host:/foo . vs. scp -rC2 -c blowfish user at host:/foo . or even scp -e "ssh -C2 -c blowfish" user at host:/foo . I actually kinda *like* the second syntax; I just think it's a bit redundant. SCP should imply use of SSH; that's the only way to keep the implication that a server that doesn't support SCP is either a) buggy or b) security-restricted. It's not "scp over ssh", it's not "rcp over ssh" -- it's "scp, an integrated component of OpenSSH we expect to find the other half of on the server, in the same way we expect to find the sftp-server subsystem". The fact that the comma syntax is very nonstandard means we're demanding a hard translation, which I'm trying to avoid. --Dan From markus at openbsd.org Mon Jan 28 23:57:27 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 13:57:27 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <023901c1a7f9$d994afa0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> Message-ID: <20020128125727.GA26963@faui02> On Mon, Jan 28, 2002 at 04:46:47AM -0800, Dan Kaminsky wrote: > I guess my question to you, Markus, is this: When is an option important > enough to add to the command line of ssh, but *not* for the exact same > reasons important enough to add to scp? always. From dan at doxpara.com Tue Jan 29 00:33:26 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 05:33:26 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> Message-ID: <025501c1a800$5d62d8b0$1701000a@effugas> > On Mon, Jan 28, 2002 at 04:46:47AM -0800, Dan Kaminsky wrote: > > I guess my question to you, Markus, is this: When is an option important > > enough to add to the command line of ssh, but *not* for the exact same > > reasons important enough to add to scp? > > always. *laughs* Me, Mr. "Encapsulate it all and let God sort it out", arguing for integration? Quelle horror! Look. bin/ssh integrates shells, commands, and TCP port forwards into a multiplexed cryptographically secure session. bin/scp integrates file transfer into a multiplexed cryptographically secure session. We *could* encapsulate file transfer any number of ways -- we could TCP forward HTTP, we could use my various cat/tar/ls hacks, we could do any number of things. Implementation-wise, we actually do encapsulate scp inside of ssh. But as far as the user knows, scp is the integrated alternative to various other methods. They chose the self-contained entity, distributed as part of SSH, that provides rcp-style semantics to access files on remote hosts. There are times where I want to deal with the various aspects of packaging one system inside of another -- but the SSH way is to integrate to a point and then encapsulate the rest. We can depend on the ability to transfer files, much as we can depend on the ability to forward ports or access our remote shells with fully correct terminal support. It's a different approach. It's not the same as rsync, it's not the same as tar. But forcing scp into the encapsulation paradigm is conceptually incorrect -- you're leaking implementation details into what is psychologically just another entity ssh supports. Sure, a different command line is needed, and we need to specify files to move instead of commands to remotely execute -- but in the end, "ssh supports file transfer, because file transfer is important". Heh. I don't like SCP; I find it limiting. But I see where its users are coming from, and really, all it costs us to support command parity is the non-usage of -rBSDf for file-transfer relevant options in ssh. This is a small piece of latitude for what is clearly a very important knob for users to be able to easily tweak! Regarding ports -- I built a patch a while back to allow this syntax. Any objection to it? ssh user at host:port scp user at host:port:/path . this mirrors standard URL syntax pretty closely. --Dan From levitte at stacken.kth.se Tue Jan 29 00:37:24 2002 From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker) Date: Mon, 28 Jan 2002 14:37:24 +0100 (MET) Subject: OpenSSH w/ kth-krb4 on AIX In-Reply-To: References: Message-ID: <20020128.143724.03867069.levitte@stacken.kth.se> From: sperber at informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) sperber> >>>>> "Moiself" == Michael Sperber writes: sperber> sperber> Moiself> Hi, sperber> sperber> Moiself> I'm suffering from a memory corruption problem when sperber> Moiself> compiling OpenSSH 3.0.2p1 with kth-krb4 1.1 on AIX sperber> Moiself> 4.3.2 and 4.3.3. The symptom is that the file name [...] sperber> Here's the source of the problem: krb4 and openssl both define sperber> RC4_INT, and they define it differently. OpenSSH happens to call some sperber> routines from one, and some from the other. Poing! I don't know what sperber> to do about this in general. Suggestions? It's been suggested a few days ago that recent versions of kth-krb4 can be configured to use OpenSSL to get the crypto routines. Doing so is very likely to resolve the problem. I wonder, where exactly does lib/des/rc4* come from? SSLeay? I just checked, and when looking at the Configure from OpenSSL (latest CVS update) and from SSLeay 0.8.1b (which is basically the absolutely earliest SSLeay we have in the OpenSSL repository), the aix targets have exactly the same configuration options (BN_LLONG and RC4_CHAR). Back in SSLeay times, one could find the following in rc4.org (and the distributed rc4.h, which was rebuilt from rc4.org by the configuration script): #define RC4_INT unsigned int And as long as rc4.h got rewritten properly for the different architectures, all was fine. However (and this is very unfortunate, even if it was a nice thought), SSLeay was designed in such a way that crypto algorithm implementations could be picked out and form independent libraries, of which libdes is probably the most well-known (for the picky: it was actually the other way around, libdes and the like were basically grafted into SSLeay). However, since those lack the SSLeay/OpenSSL configuration script, you would end up having differences on some platforms between lib{crypto} and the same routines in libcrypto. And this only becomes visible when the two are suddenly combined, something I don't think has happened before OpenSSH started using both OpenSSL's libcrypto and kth-krb4 (which in this case was NOT built against OpenSSL's libcrypto). All this is quite unfortunate, and we (the OpenSSL team) have battled with the old des routines (which we unfortunately messed up for a bit of time) and have finally come up with a method to avoid all clashes that we can think of. Do we need to do that for all other crypto implementations that were present in SSLeay, or should kth-krb4 move to require the presence of OpenSSL? I personally would prefer the latter (less work for us, that's why :-)), but I'm up for listening. -- Richard Levitte \ Spannv?gen 38, II \ LeViMS at stacken.kth.se Redakteur at Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis -- poei at bofh.se Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See for more info. From markus at openbsd.org Tue Jan 29 01:07:34 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 15:07:34 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <025501c1a800$5d62d8b0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> Message-ID: <20020128140734.GA6774@faui02> On Mon, Jan 28, 2002 at 05:33:26AM -0800, Dan Kaminsky wrote: > > On Mon, Jan 28, 2002 at 04:46:47AM -0800, Dan Kaminsky wrote: > > > I guess my question to you, Markus, is this: When is an option > important > > > enough to add to the command line of ssh, but *not* for the exact same > > > reasons important enough to add to scp? > > > > always. > > *laughs* Me, Mr. "Encapsulate it all and let God sort it out", arguing for > integration? Quelle horror! ??? scp has _zero_ to do with ssh. > Look. bin/ssh integrates shells, commands, and TCP port forwards into a > multiplexed cryptographically secure session. > > bin/scp integrates file transfer into a multiplexed cryptographically secure > session. scp just happen to call 'ssh'. it can use every 8bit clean channel. scp just does rcp over some transport protocol. > We *could* encapsulate file transfer any number of ways -- we could TCP > forward HTTP, we could use my various cat/tar/ls hacks, we could do any > number of things. Implementation-wise, we actually do encapsulate scp > inside of ssh. > > But as far as the user knows, scp is the integrated alternative to various > other methods. They chose the self-contained entity, distributed as part of > SSH, that provides rcp-style semantics to access files on remote hosts. > There are times where I want to deal with the various aspects of packaging > one system inside of another -- but the SSH way is to integrate to a point > and then encapsulate the rest. We can depend on the ability to transfer > files, much as we can depend on the ability to forward ports or access our > remote shells with fully correct terminal support. > > It's a different approach. It's not the same as rsync, it's not the same as > tar. But forcing scp into the encapsulation paradigm is conceptually > incorrect -- you're leaking implementation details into what is > psychologically just another entity ssh supports. but _you_ are linking scp to ssh, so you are leaking implementation details. > Sure, a different command > line is needed, and we need to specify files to move instead of commands to > remotely execute -- but in the end, "ssh supports file transfer, because > file transfer is important". > > Heh. I don't like SCP; I find it limiting. But I see where its users are > coming from, and really, all it costs us to support command parity is the > non-usage of -rBSDf for file-transfer relevant options in ssh. This is a > small piece of latitude for what is clearly a very important knob for users > to be able to easily tweak! > > Regarding ports -- I built a patch a while back to allow this syntax. Any > objection to it? > > ssh user at host:port > scp user at host:port:/path . > > this mirrors standard URL syntax pretty closely. it does not support ipv6 addresses. From andreas at nexus.se Tue Jan 29 01:02:10 2002 From: andreas at nexus.se (Andreas Persson) Date: Mon, 28 Jan 2002 15:02:10 +0100 (CET) Subject: installation problems Message-ID: <20020128144836.D36362-100000@us.unilog.se> Hi, there seems to be alot of people having problem installing openSSH (and so do I)! Search on the Internet for this "Could not find working OpenSSL library" and you will see that people have problems with many different versions and there's also a lot of suggestions how to fix that wont work. I suggest that you put an explanation and the solution on your FAQ! Thanks! /Andreas Andreas Persson Tel: +46 18 171808 Nexus Security Fax: +46 18 696516 Drottningg. 4, Box 857 Mobile: +46 705 270137 S-751 08 Uppsala, Sweden E-post: Andreas.Persson at nexus.se From dan at doxpara.com Tue Jan 29 02:12:01 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 07:12:01 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> <20020128140734.GA6774@faui02> Message-ID: <02a001c1a80e$232d62b0$1701000a@effugas> > ??? scp has _zero_ to do with ssh. (if you'd rather not read all the UI theory, just skip to the section that says IMPORTANT.) Markus, I really would like a -e mode for scp; if nothing else it would unify my rsync and scp syntax which are now painfully different. But that -e is a nice toy doesn't obscure the truth about what scp means for ssh. SCP is *the* standard method of transfering files over SSH. It is the only method that has always shipped with SSH. It is the only method I'm really supposed to be able to expect to work. It's the one method I have the right to get angry about failing all the ding dong day. Think about this -- an SSH server is either locked down or incorrectly configured if it doesn't support scp. That's *not* the case if it doesn't support rsync, or tar, or whatever. This is a major difference that you're not giving enough credence to! > scp just happen to call 'ssh'. it can use every 8bit clean channel. > > scp just does rcp over some transport protocol. Let me put it this way. ssh is more than just rsh over some 8bit clean channel scp is more than just rcp over some 8bit clean channel It's beyond what it carries, Markus. It's user expectations. ssh(secure shell) transmits a shell securely, scp(secure copy) retrieves a file securely. When I configure ssh, I say what shell I want and how secure I want it. When I configure scp, I say what file I want and how secure I want it. I don't care if scp has all of ssh's functions duplicated internally(as actually happens on most win32 implementation of scp) or if it borrows them from an ssh binary. All I care about is that I get a file just like I got a shell. (From a security standpoint, it's troublesome that being able to get a file means I have the client to receive a shell, but we'll overlook that for now.) > but _you_ are linking scp to ssh, so you are leaking implementation details. I'm saying, from the user's point of view, scp is ssh for file transfer. If I type: ssh user at host to get into somewhere, I can type: scp user at host:file . to copy a file from the default login directory to my own folder. If I type: ssh -c blowfish -2 -X -e! user at host I've configured the cryptography of the session -- blowfish and SSH2 on the holy 8 bit link -- as well as traits of the session itself: I want X11 forwarding enabled and I want a different escape character. And that's OK -- SSH handles both with aplomb. Similarly, if I type: scp -c blowfish -2 -r user at host:path . Again, I've configured the cryptography of the session -- blowfish *and* ssh2 on the 8 bit link* -- but I've also specified a trait of the session: Execute a recursive copy. Now, yes, we could do: scp -e "ssh -c blowfish -2" -r user at host:path . [IMPORTANT] But, heh, we didn't have to separate out our cryptography options from our session options with ssh, why should we have to with scp? And why should we now explicitly need to specify our chosen tunneler, when before we had no need? And thus, we find the real problem. For all you say that scp has nothing to do with ssh, there's a pretty serious presumption in all four of these: scp -F ssh_config -r user at host:path . scp -o Protocol=2 -o Cipher=blowfish -r user at host:path . scp -s,-2 -s,-c blowfish -r user at host:path . scp -2 -c blowfish -r user at host:path . All four of these presume they can give the "8 bit channel" marching orders as to what type of crypto to use. The first thinks -F ssh_config will be respected just like ssh would; the second thinks -o options will be understood as anything more than random characters, and the third and fourth presume command line syntax matches. They're all tied, and you just can't get away from that. Hiding behind a segregated syntax doesn't lessen your assumptions one bit. Don't get me wrong, Markus. I like the idea of a -e mode; it makes rsync very easy to move over bizarre ssh tunnels (like rsync over reverse tunneled http). But everything but -e makes huge assumptions about the 8 bit tunnel, as well it should -- this is _s_cp, not _r_cp. I _expect_ security to be an equal if not greater concern than whether or not the files get there. I _expect_ I can give security orders just as I can give file copying orders. Now, if I want to override the default security encapsulator with a -e, and give it my own options, that's my business, but if not I expect it'll still be secure, because it's "secure copy". Those are my expectations. What do you expect? > it does not support ipv6 addresses. And it has problems if I'm trying to copy a numbered file from the user's default home directory. Hmmm. Any idea how URLs are adapting to IPV6? --Dan From markus at openbsd.org Tue Jan 29 02:14:38 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 16:14:38 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <02a001c1a80e$232d62b0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> <20020128140734.GA6774@faui02> <02a001c1a80e$232d62b0$1701000a@effugas> Message-ID: <20020128151438.GA17264@faui02> On Mon, Jan 28, 2002 at 07:12:01AM -0800, Dan Kaminsky wrote: > SCP is *the* standard method of transfering files over SSH. it there _was_ a standard method, just look at the scp1/scp2/sftp mess From djast at cs.toronto.edu Tue Jan 29 02:16:59 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 28 Jan 2002 10:16:59 -0500 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: Your message of "Mon, 28 Jan 2002 07:20:56 EST." <20020128122056.GB17992@faui02> Message-ID: <02Jan28.101709edt.453144-1882@jane.cs.toronto.edu> On Mon, 28 Jan 2002 07:20:56 EST, Markus Friedl writes: > you cannot have both rcp's and ssh's options > in scp. and since scp is basically just rcp calling > ssh, scp should have rcp's options plus _one_ simple > way of passing options to ssh. so use -F and -o. > > you cannot have consistency between these 3 programs, > so for consistency scp should have _no_ options from > ssh, because if it _has_ then people want every option. It should not be difficult for someone to write a wrapper script or program (perhaps included in contrib/, and maintained independently of OpenSSH) which maps the relevant SSH-specific options to the appropriate -o options for OpenSSH's SCP; e.g., to translate sshcp -2 -b 10.0.0.1 -u myuser [args] to scp -oProtocol=2 -oBindAddress=10.0.0.1 -oUser=myser [args] This would introduce an explicit layer of indirection, allowing the core interface to be kept clean, and providing the convenience options for those who want them. Would this make everybody (anybody?) happy? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From markus at openbsd.org Tue Jan 29 02:19:19 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 16:19:19 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <02a001c1a80e$232d62b0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> <20020128140734.GA6774@faui02> <02a001c1a80e$232d62b0$1701000a@effugas> Message-ID: <20020128151919.GB17264@faui02> On Mon, Jan 28, 2002 at 07:12:01AM -0800, Dan Kaminsky wrote: > It's beyond what it carries, Markus. It's user expectations. yes, and this is the problem. -c, -C, -i got added, while -p could not, -f could not, -t could not, -P could not, so there is already a _big_ difference, and now with this inconsistency people started expecting that scp accepts all options from ssh. but that's not possible. adding more options to scp will make even more people expect that scp and ssh behave the same. but they cannot behave the same, it's too late. From markus at openbsd.org Tue Jan 29 02:22:56 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 16:22:56 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <02a001c1a80e$232d62b0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> <20020128140734.GA6774@faui02> <02a001c1a80e$232d62b0$1701000a@effugas> Message-ID: <20020128152256.GC17264@faui02> On Mon, Jan 28, 2002 at 07:12:01AM -0800, Dan Kaminsky wrote: > Those are my expectations. What do you expect? i expect that -o works. > > it does not support ipv6 addresses. > > And it has problems if I'm trying to copy a numbered file from the user's > default home directory. Hmmm. Any idea how URLs are adapting to IPV6? [addr]:port From stevesk at pobox.com Tue Jan 29 02:34:58 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 28 Jan 2002 07:34:58 -0800 (PST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <018001c1a7b1$11b37c70$1701000a@effugas> Message-ID: On Sun, 27 Jan 2002, Dan Kaminsky wrote: :> :It's just a matter of consistency -- though, to be honest, since protocol :> :declaration impacts security pretty directly, both in terms of :communication :> :privacy and authentication methods, :> :> i have no idea what this means. : :SCP stands for _SECURE_ copy, as opposed to the insecure "remote" copy. So scp is just the rcp protocol over ssh. :options that have direct impact on security are actually the most critical :for SCP to implement. they are "implemented" with -o. From mouring at etoh.eviladmin.org Tue Jan 29 02:47:38 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Mon, 28 Jan 2002 09:47:38 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128105503.GC19577@wiggy.net> from Wichert Akkerman at "Jan 28, 2002 11:55:03 am" Message-ID: <200201281547.g0SFldDw012253@etoh.eviladmin.org> > Previously Markus Friedl wrote: > > why do you need -1 and -2? > > Users want it, and it's very useful in situations where you need > to specifiy the version due to existing keys, old servers, etc. > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your business, but you only add to the confusion (if there is any at all). #2 - In TWO years of helping people with ssh compiling, configuring, and using. I've seen SIX people (80% of them are on this list!) whine about lack of -1/-2. The others where happy to use -oProtocol=[12] to do their job. NOW please.. tell me.. *WHERE* are these MASSES of people crying out for the -1/-2 option for scp? SIX people out of almost a thousand plus people I've interacted with. Waste of time.. - Ben From Nicolas.Williams at ubsw.com Tue Jan 29 03:33:57 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 11:33:57 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020127152532.F30885@folly>; from markus@openbsd.org on Sun, Jan 27, 2002 at 03:25:32PM +0100 References: <20020127152532.F30885@folly> Message-ID: <20020128113356.E27398@sm2p1386swk.wdr.com> On Sun, Jan 27, 2002 at 03:25:32PM +0100, Markus Friedl wrote: > On Sat, Jan 26, 2002 at 08:47:45PM +0100, Tobias Ringstrom wrote: > > * Changed the sshd subsystem config option syntax from > > Subsystem name path > > to > > Subsystem name options path > > i don't like this. > > i'd rather add a per-channel option to > the protocol for requesting nodelay. TCP_NODELAY is a socket option and so applies to all of an SSH connection, not to a specific channel. Or do you think that the protocol should have a per-channel Nagle-like option at the SSHv2 transport layer? That wouldn't hurt, and it would probably be very good. Back to the IETF list? Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From wichert at wiggy.net Tue Jan 29 03:36:23 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 17:36:23 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201281547.g0SFldDw012253@etoh.eviladmin.org> References: <20020128105503.GC19577@wiggy.net> <200201281547.g0SFldDw012253@etoh.eviladmin.org> Message-ID: <20020128163623.GI23607@wiggy.net> Previously mouring wrote: > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your > business, but you only add to the confusion (if there is any at all). I see it as reducing confusion and adding a bit of consistency, but you're free to disagree with me on that. > NOW please.. tell me.. *WHERE* are these MASSES of people crying out for > the -1/-2 option for scp? SIX people out of almost a thousand plus > people I've interacted with. Only a minority of people who have such issues actually bother to send them to this list. Most will either go to to vendor/distributor or won't bother. If you're so interested in what people are saying that doesn't make it to this feel free to browse http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ssh&archived=yes Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From Nicolas.Williams at ubsw.com Tue Jan 29 03:36:42 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 11:36:42 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from stevesk@pobox.com on Sun, Jan 27, 2002 at 03:47:03PM -0800 References: Message-ID: <20020128113641.F27398@sm2p1386swk.wdr.com> On Sun, Jan 27, 2002 at 03:47:03PM -0800, Kevin Steves wrote: > On Sat, 26 Jan 2002, Tobias Ringstrom wrote: > for the ssh transport connection, we use nagle by default only if it is a > session channel with a pty and shell or exec channel > > other channel types would cause connection to be nodelay on both sides (as > determined and set by ssh and sshd) Forwarded SSH agents should not require TCP_NODELAY. Forwarded TCP ports in general, and forwarded X11 displays specifically, should. Turning off Nagle when a non-agent forwarded port is opened would be a simple patch. > nodelay yes/no would be available to change default for pty,shell,exec > only behavior. Yeah. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Jason.Lacoss-Arnold at AGEDWARDS.com Tue Jan 29 03:46:59 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Mon, 28 Jan 2002 10:46:59 -0600 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4CA@hqempn06.agedwards.com> Personally, I wish it was in the current release as it'd greatly aid our migration efforts (from a poorly done 2.5.1 implementation) and is a lot easier to communigate to clueless users. We've finally managed to piggyback a real ssh deployment onto a high profile project, and some of the user education is really sucking. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: mouring [mailto:mouring at etoh.eviladmin.org] Sent: Monday, January 28, 2002 9:48 To: Wichert Akkerman Cc: openssh-unix-dev at mindrot.org Subject: Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 > Previously Markus Friedl wrote: > > why do you need -1 and -2? > > Users want it, and it's very useful in situations where you need > to specifiy the version due to existing keys, old servers, etc. > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your business, but you only add to the confusion (if there is any at all). #2 - In TWO years of helping people with ssh compiling, configuring, and using. I've seen SIX people (80% of them are on this list!) whine about lack of -1/-2. The others where happy to use -oProtocol=[12] to do their job. NOW please.. tell me.. *WHERE* are these MASSES of people crying out for the -1/-2 option for scp? SIX people out of almost a thousand plus people I've interacted with. Waste of time.. - Ben _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020128/ba348af0/attachment.html From markus at openbsd.org Tue Jan 29 03:50:23 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 17:50:23 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 Message-ID: <20020128165023.GB19536@faui02> will adding -1 and -2 make people post useful patches for real bugs to this list? From markus at openbsd.org Tue Jan 29 03:49:17 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 17:49:17 +0100 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020128113356.E27398@sm2p1386swk.wdr.com> References: <20020127152532.F30885@folly> <20020128113356.E27398@sm2p1386swk.wdr.com> Message-ID: <20020128164917.GA19536@faui02> On Mon, Jan 28, 2002 at 11:33:57AM -0500, Nicolas Williams wrote: > TCP_NODELAY is a socket option i know. > and so applies to all of an SSH > connection, not to a specific channel. wrong, you have to consider each channel endpoint, e.g. for tcp forwarding. > Or do you think that the protocol should have a per-channel Nagle-like > option at the SSHv2 transport layer? no. From markus at openbsd.org Tue Jan 29 04:19:41 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 18:19:41 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E4CA@hqempn06.agedwards.com> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4CA@hqempn06.agedwards.com> Message-ID: <20020128171941.GB25227@faui02> On Mon, Jan 28, 2002 at 10:46:59AM -0600, Lacoss-Arnold, Jason wrote: > Personally, I wish it was in the current release as it'd greatly aid our > migration efforts (from a poorly done 2.5.1 implementation) what's wrong with 2.5.1 ? > and is a lot > easier to communigate to clueless users. > > We've finally managed to piggyback a real ssh deployment onto a high profile > project, and some of the user education is really sucking. > > Thanks, > --Jason Lacoss-Arnold, Systems Technical Specialist > Technical Services - Unix Arch. > 314-955-8501 > > > -----Original Message----- > From: mouring [mailto:mouring at etoh.eviladmin.org] > Sent: Monday, January 28, 2002 9:48 > To: Wichert Akkerman > Cc: openssh-unix-dev at mindrot.org > Subject: Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 > > > > Previously Markus Friedl wrote: > > > why do you need -1 and -2? > > > > Users want it, and it's very useful in situations where you need > > to specifiy the version due to existing keys, old servers, etc. > > > > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your > business, but you only add to the confusion (if there is any at all). > > #2 - In TWO years of helping people with ssh compiling, configuring, and > using. I've seen SIX people (80% of them are on this list!) whine about > lack of -1/-2. The others where happy to use -oProtocol=[12] to do their > job. > > NOW please.. tell me.. *WHERE* are these MASSES of people crying out for > the -1/-2 option for scp? SIX people out of almost a thousand plus > people I've interacted with. > > Waste of time.. > > - Ben > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > *************************************************************************************** > WARNING: All e-mail sent to and from this address will be received or > otherwise recorded by the A.G. Edwards corporate e-mail system and is > subject to archival, monitoring or review by, and/or disclosure to, > someone other than the recipient. > *************************************************************************************** From mouring at etoh.eviladmin.org Tue Jan 29 03:45:32 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Mon, 28 Jan 2002 10:45:32 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128163623.GI23607@wiggy.net> from Wichert Akkerman at "Jan 28, 2002 05:36:23 pm" Message-ID: <200201281645.g0SGjWhk026516@etoh.eviladmin.org> > Previously mouring wrote: > > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your > > business, but you only add to the confusion (if there is any at all). > > I see it as reducing confusion and adding a bit of consistency, > but you're free to disagree with me on that. > > > NOW please.. tell me.. *WHERE* are these MASSES of people crying out for > > the -1/-2 option for scp? SIX people out of almost a thousand plus > > people I've interacted with. > > Only a minority of people who have such issues actually bother to send > them to this list. Most will either go to to vendor/distributor > or won't bother. > This list is the minority of the people I talk to. On an average day I tend to deal with about 5 - 10 people between efnet irc, and other IM style systems. I consider this list to be technical enough to not count them. > If you're so interested in what people are saying that doesn't make > it to this feel free to browse > http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ssh&archived=yes > Funny how Debian is in the minority for -1/-2. I checked around with a few other vendors (including Redhat) and none of them felt it was a requirement. BTW I have looked at a lot of those reports in the past. Majority of the issues is because you people have taken it on yourself to set policy (add -1/-2, no v1 in default support, add :: to ListenAddress, etc). The other group of them are extremely old (over a year plus) and most of them (from skimming) were fixed and I doubt we saw a single bug request from debian group. Oh, lets not forget the silly ones like "sftp-server should be in /usr/lib" persons' reasoning? "Because it is only useful to sshd"... BAH! WHY the *HELL* would one put EXCUTABLES in /usr/lib? WHEN did sftp-server, ssh-askpass-gnome, etc become librariees?! But I'm glad to see people with common sense to say no to -c none option. Do you start to see my point? HAVE you read them? There are some pretty stupid/uninformed requests. BTW.. I don't see -1/-2 request. BTW2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=51955&repeatmerged=yes was fixed. You can take it off your wishlist. - Ben From Nicolas.Williams at ubsw.com Tue Jan 29 04:23:21 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 12:23:21 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020128164917.GA19536@faui02>; from markus@openbsd.org on Mon, Jan 28, 2002 at 05:49:17PM +0100 References: <20020127152532.F30885@folly> <20020128113356.E27398@sm2p1386swk.wdr.com> <20020128164917.GA19536@faui02> Message-ID: <20020128122319.G27398@sm2p1386swk.wdr.com> On Mon, Jan 28, 2002 at 05:49:17PM +0100, Markus Friedl wrote: > On Mon, Jan 28, 2002 at 11:33:57AM -0500, Nicolas Williams wrote: > > TCP_NODELAY is a socket option > > i know. I figured as much! :) :) > > and so applies to all of an SSH > > connection, not to a specific channel. > > wrong, you have to consider each channel endpoint, e.g. > for tcp forwarding. Yes, but a single global SSHv2 request will do. I don't see why it has to be a channel request. Or are you thinking that, if you have a connection with 3 channels, one of which needs TCP_NODELAY, and then that channel is closed, both parties should immediately unset TCP_NODELAY? But if the client has control over whether the server has TCP_NODELAY on, then the client can keep track of when to turn Nagle on and off using as finely or coarsely tuned heuristic as it wants (or as it's told by the user). > > Or do you think that the protocol should have a per-channel Nagle-like > > option at the SSHv2 transport layer? > > no. Ok. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Tue Jan 29 03:47:52 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Mon, 28 Jan 2002 10:47:52 -0600 (CST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128165023.GB19536@faui02> from Markus Friedl at "Jan 28, 2002 05:50:23 pm" Message-ID: <200201281647.g0SGlqsn019954@etoh.eviladmin.org> > will adding -1 and -2 make people post useful patches for real > bugs to this list? I think your asking too much. =) - Ben Hating elm to death. From markus at openbsd.org Tue Jan 29 04:32:10 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Jan 2002 18:32:10 +0100 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020128122319.G27398@sm2p1386swk.wdr.com> References: <20020127152532.F30885@folly> <20020128113356.E27398@sm2p1386swk.wdr.com> <20020128164917.GA19536@faui02> <20020128122319.G27398@sm2p1386swk.wdr.com> Message-ID: <20020128173210.GE25227@faui02> On Mon, Jan 28, 2002 at 12:23:21PM -0500, Nicolas Williams wrote: > Or are you thinking that, if you have a connection with 3 channels, one > of which needs TCP_NODELAY, and then that channel is closed, both > parties should immediately unset TCP_NODELAY? no, i'm talking about the sockets that are created on the peer. e.g. for -L style forwarding: should the connect()ed socket on the server be TCP_NODELAY'ed or not? -m From Jason.Lacoss-Arnold at AGEDWARDS.com Tue Jan 29 04:32:26 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Mon, 28 Jan 2002 11:32:26 -0600 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4CD@hqempn06.agedwards.com> Nothing wrong with the code as much out our crappy implementation. We've got horrendous ssh_config and sshd_configs that don't integrate well with each others or the OS's we support. X11 forwarding is fundamentally broken, paths are poor, uselogin is inconsistant, etc. It's pretty much a recipe for everyone avoiding ssh like the plague, esp since while info security and my group (unix architecture) were wise enough to mandate that ssh must go on all servers, they forgot to mandate that telnet, ftp, and r* had to come off. Plus the dunderheads in info security like obfuscation so much that they mandated that we use a non-standard port which they were unfortunately not clueful enough to avoid high ports, so it'd be trivial to for a normal user to put a trojaned daemon on a box that's not running ssh. *sigh* Doing things right is a never-ending battle. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Monday, January 28, 2002 11:20 To: Lacoss-Arnold, Jason Cc: 'mouring'; Wichert Akkerman; openssh-unix-dev at mindrot.org Subject: Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 On Mon, Jan 28, 2002 at 10:46:59AM -0600, Lacoss-Arnold, Jason wrote: > Personally, I wish it was in the current release as it'd greatly aid our > migration efforts (from a poorly done 2.5.1 implementation) what's wrong with 2.5.1 ? > and is a lot > easier to communigate to clueless users. > > We've finally managed to piggyback a real ssh deployment onto a high profile > project, and some of the user education is really sucking. > > Thanks, > --Jason Lacoss-Arnold, Systems Technical Specialist > Technical Services - Unix Arch. > 314-955-8501 > > > -----Original Message----- > From: mouring [mailto:mouring at etoh.eviladmin.org] > Sent: Monday, January 28, 2002 9:48 > To: Wichert Akkerman > Cc: openssh-unix-dev at mindrot.org > Subject: Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 > > > > Previously Markus Friedl wrote: > > > why do you need -1 and -2? > > > > Users want it, and it's very useful in situations where you need > > to specifiy the version due to existing keys, old servers, etc. > > > > #1 - OpenSSH/OpenBSD is not Debian. What you do to the source is your > business, but you only add to the confusion (if there is any at all). > > #2 - In TWO years of helping people with ssh compiling, configuring, and > using. I've seen SIX people (80% of them are on this list!) whine about > lack of -1/-2. The others where happy to use -oProtocol=[12] to do their > job. > > NOW please.. tell me.. *WHERE* are these MASSES of people crying out for > the -1/-2 option for scp? SIX people out of almost a thousand plus > people I've interacted with. > > Waste of time.. > > - Ben > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > **************************************************************************** *********** > WARNING: All e-mail sent to and from this address will be received or > otherwise recorded by the A.G. Edwards corporate e-mail system and is > subject to archival, monitoring or review by, and/or disclosure to, > someone other than the recipient. > **************************************************************************** *********** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020128/04f9a1b7/attachment.html From Nicolas.Williams at ubsw.com Tue Jan 29 04:58:08 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 12:58:08 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020128173210.GE25227@faui02>; from markus@openbsd.org on Mon, Jan 28, 2002 at 06:32:10PM +0100 References: <20020127152532.F30885@folly> <20020128113356.E27398@sm2p1386swk.wdr.com> <20020128164917.GA19536@faui02> <20020128122319.G27398@sm2p1386swk.wdr.com> <20020128173210.GE25227@faui02> Message-ID: <20020128125806.H27398@sm2p1386swk.wdr.com> On Mon, Jan 28, 2002 at 06:32:10PM +0100, Markus Friedl wrote: > On Mon, Jan 28, 2002 at 12:23:21PM -0500, Nicolas Williams wrote: > > Or are you thinking that, if you have a connection with 3 channels, one > > of which needs TCP_NODELAY, and then that channel is closed, both > > parties should immediately unset TCP_NODELAY? > > no, i'm talking about the sockets that are created on the > peer. e.g. for -L style forwarding: should the connect()ed > socket on the server be TCP_NODELAY'ed or not? Oh I see. That makes sense. > -m Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From stevesk at pobox.com Tue Jan 29 05:06:27 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 28 Jan 2002 10:06:27 -0800 (PST) Subject: sftp failed on channel 0 In-Reply-To: Message-ID: On Mon, 28 Jan 2002, Ramesh Dharma wrote: :I just recently installed OpenSSH_3.0.2p1 on a HP-UX box. :The ssh works fine but the sftp is not. :There is a firewall in between both the machine. :Only SSH port is allowed from the source host to the destination machine. :ssh works fine across the firewall. :Below is the log. :Thanks in advance . : :~~~~~~~~~~~~~~~~~~~~~~~~~~~` : sftp spdns1 :Connecting to spdns1... :smorrx at spdns1's password: :Request for subsystem 'sftp' failed on channel 0 :Connection closed :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~` there is no subsystem sftp configured on the server. [stevesk at anchor ssh]$ ssh -s jenny foo Request for subsystem 'foo' failed on channel 0 From Nicolas.Williams at ubsw.com Tue Jan 29 05:18:44 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 13:18:44 -0500 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128165023.GB19536@faui02>; from markus@openbsd.org on Mon, Jan 28, 2002 at 05:50:23PM +0100 References: <20020128165023.GB19536@faui02> Message-ID: <20020128131842.I27398@sm2p1386swk.wdr.com> Will useful patches posted to this list receive any consideration for inclusion in future releases of OpenSSH? The most important contributed patch, right now, from my point of view, is Simon Wilkinson's GSS-API userauth/external key exchange patch. Will that be included? Nico On Mon, Jan 28, 2002 at 05:50:23PM +0100, Markus Friedl wrote: > will adding -1 and -2 make people post useful patches for real > bugs to this list? -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From wichert at wiggy.net Tue Jan 29 05:28:00 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 28 Jan 2002 19:28:00 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <200201281645.g0SGjWhk026516@etoh.eviladmin.org> References: <20020128163623.GI23607@wiggy.net> <200201281645.g0SGjWhk026516@etoh.eviladmin.org> Message-ID: <20020128182800.GO23607@wiggy.net> (this is getting seriously offtopic, if anyone wants to continue this discussion please do so in private mail) Previously mouring wrote: > Funny how Debian is in the minority for -1/-2. That never stopped Debian from doing something. Being a minority or not is one of the worst possibly reasons for doing something. > BTW I have looked at a lot of those reports in the past. Majority of > the issues is because you people have taken it on yourself to set policy > (add -1/-2, no v1 in default support, add :: to ListenAddress, etc). :: isn't added to ListenAddress at the moment I think, there are some ipv4/ipv6 issues that break if you do that. > The other group of them are extremely old (over a year plus) and most of them > (from skimming) were fixed and I doubt we saw a single bug request from > debian group. Keep in mind that the Debian ssh package was pretty much unmaintained for a long time and people are working on it now. Matthew has already been active on this list for a while now, he just never mentioned he is maintaining the Debian package now iirc. > Oh, lets not forget the silly ones like "sftp-server should be in /usr/lib" > persons' reasoning? "Because it is only useful to sshd"... BAH! WHY > the *HELL* would one put EXCUTABLES in /usr/lib? WHEN did sftp-server, > ssh-askpass-gnome, etc become librariees?! That is a completely different argument. We happen to like to have a standard for things in the Linux world, and the relevant standard in this case is FHS. You don't have to agree with it, but having a standard is a good thing. > Do you start to see my point? HAVE you read them? There are some pretty > stupid/uninformed requests. I did look through them before handing out the URL. And yes, a lot of them are silly and should be closed, but as I said earlier unfortunately the Debian ssh package wasn't maintained for a while and a lot of cruft piled up in that list. > BTW.. I don't see -1/-2 request. So it was never filed as a bugreport, doesn't change much. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From Nicolas.Williams at ubsw.com Tue Jan 29 05:39:00 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 13:39:00 -0500 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128131842.I27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Mon, Jan 28, 2002 at 01:18:44PM -0500 References: <20020128165023.GB19536@faui02> <20020128131842.I27398@sm2p1386swk.wdr.com> Message-ID: <20020128133858.J27398@sm2p1386swk.wdr.com> I realize, by the way, that you asked about bug fixes, not feature patches. But all the bugs in OpenSSH that I've cared about that I know of so far are fixed :) which is why I feel I have the luxury of asking about feature patches. On Mon, Jan 28, 2002 at 01:18:44PM -0500, Nicolas Williams wrote: > Will useful patches posted to this list receive any consideration for > inclusion in future releases of OpenSSH? > > The most important contributed patch, right now, from my point of view, > is Simon Wilkinson's GSS-API userauth/external key exchange patch. > > Will that be included? > > Nico > > > On Mon, Jan 28, 2002 at 05:50:23PM +0100, Markus Friedl wrote: > > will adding -1 and -2 make people post useful patches for real > > bugs to this list? -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From stevesk at pobox.com Tue Jan 29 07:07:52 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 28 Jan 2002 12:07:52 -0800 (PST) Subject: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <3C4DBF92.B4AD9F70@hp.com> Message-ID: On Tue, 22 Jan 2002, Rick Jones wrote: :I guess what I am driving at is that unless there are gratuitous things :being done by SSH to further break-up the data it is forwarding, setting :TCP_NODELAY will "preserve" the on-the-wire appearance of the :applications at either end. It does not matter if they set TCP_NODELAY :or if they did not. : :If the app did not set TCP_NODELAY, its first small send will arrive at :ssh's socket, and ssh will send that along (yes?). The ACK from the ssh :host will be sent back to the app's TCP, and the rest of the small sends :will be send and will arrive and ostensibly be recieved in one swell :foop by ssh (it does use a reasonably large recv buffer yes?) and then :will be passed-along by ssh on the other side. we don't currently set SO_RCVBUF/SO_SNDBUF anywhere. more to look at. :If the app _did_ set TCP_NODELAY, all the small sends will start :arriving, and it will be a race between SSH and the remote. If ssh is :faster than the remote, then the sends ssh makes out the other side will :also be small, just like the app did originally. If SSH is not quite as :fast, those little sends will accumulate in the socket buffer and ssh :will then read larger chunks and presumeably send larger chunks out the :other side. thanks. we need to do some testing. this sets the TCP forwarding sockets (source and sink) to TCP_NODELAY. Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.163 diff -u -r1.163 channels.c --- channels.c 27 Jan 2002 14:57:46 -0000 1.163 +++ channels.c 28 Jan 2002 19:57:32 -0000 @@ -1132,6 +1132,7 @@ error("accept: %.100s", strerror(errno)); return; } + set_nodelay(newsock); nc = channel_new(rtype, nextstate, newsock, newsock, -1, c->local_window_max, c->local_maxpacket, @@ -2325,6 +2326,7 @@ return -1; } /* success */ + set_nodelay(sock); return sock; } From tori at ringstrom.mine.nu Tue Jan 29 07:12:53 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Mon, 28 Jan 2002 21:12:53 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: Message-ID: On Sun, 27 Jan 2002, Kevin Steves wrote: > On Sat, 26 Jan 2002, Tobias Ringstrom wrote: > :So, what do you all think? The patch is for openssh-3.0.2p1. > > what is the overall methodology you have for openssh and nagle? Dream: I'd like to use Nagle for regular ssh pty/shell/exec connections with no forwarding, and I'd like to be able to have a per channel nodelay (nonagle) flag. If one or more channels requests nodelay, then TCP_NODELAY shall be set for the ssh tcp connection. It would be great if the protocol could accomodate such a flag, but I have no idea. Currently we do the opposite: We use TCP_NODELAY for regular pty/shell/exec connections. The disable-nagle-unditionally patch was rejected. Some people express wishes for other solutions, but I cannot see anything happening, at least not in public. I cannot see how using (or not using) nagle for the forwarded connections would be important, since they are probably LAN connections (where Nagle does not help much). My overlapping reads/writes for sftp seems to be ignored at the moment. I'm not happy. /Tobias From dan at doxpara.com Tue Jan 29 08:06:13 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 28 Jan 2002 13:06:13 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 References: Message-ID: <03c801c1a83f$9e34c8f0$1701000a@effugas> > they are "implemented" with -o. First of all, -o presumes an SSH backend. Markus's argument that SCP has nothing to do with SSH thus doesn't work, the _S_ stands as much for SSH's as it does Secure. It ships with it, it uses it by default, it authenticates using the same means normally. Second of all, you *hide* unimportant or rarely needed things with -o. There's, what, fifty four options supported in readconf.c? We don't need to support all of 'em, but those that have critical impacts certainly have priority. === Ben, the first patch I ever wrote for OpenSSH added -1/-2. It was trivial enough that I just did it myself, and this was before I even understood the codebase. === Markus: >> SCP is *the* standard method of transfering files over SSH. > >it there _was_ a standard method, just look at the >scp1/scp2/sftp mess I didn't say it was a good standard. Remember, _I_ hate SCP, and don't think SFTP is even close to mature yet. (Mindterm's SFTP bridge, incidentally, is so breathtakingly elegant that it's challenging my SOCKS solution.) > -c, -C, -i got added, while -p could not, -f could not, -t could not, > -P could not, so there is already a _big_ difference, and now with this > inconsistency people started expecting that scp accepts all options > from ssh. but that's not possible. adding more options to scp will make > even more people expect that scp and ssh behave the same. but they > cannot behave the same, it's too late. Oh, fooey. You're making way too big a deal of this than it is. Go *look* at the command line options we support in bin/ssh and don't in bin/scp. Yeah, we conflict on ports, and that sucks, but we need a better port syntax anyway. -t doesn't mean anything, there's no tty involved. -f is a toy that's matched simply by typing scp -q user at host:/file . & So we're left with being unable to use -r, -B, -S, and -d in ssh for any option that scp might possibly want to use. BFD. You want consistent -o availability throughout all s* client apps. I say, heh, great idea. But whenever we go ahead and say, look, something is so important that we're going to add it to the command line of ssh, I say that change should propagate through the rest of the s* apps. If nothing else, it'll prevent the quick command line namespace from getting too crowded. We BOTH want consistency, Markus. If it was important enough to add to ssh -- and for 1/2, oh yes it was -- it's important enough for the rest of the s* clients. Anyway, I'm done with this thread. I've said what I needed to say, and to be blunt, I've been enough of a gasbag :-) No more from Dan until patches are submitted. That's a promise. --Dan From Nicolas.Williams at ubsw.com Tue Jan 29 09:16:39 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 28 Jan 2002 17:16:39 -0500 Subject: PATCH: krb4/krb5/... names/patterns in auth_keys entries In-Reply-To: <20020124115451.Z27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Jan 24, 2002 at 11:54:52AM -0500 References: <20020124115451.Z27398@sm2p1386swk.wdr.com> Message-ID: <20020128171638.K27398@sm2p1386swk.wdr.com> NOTE: There appears to be some confusion, that this patch depends on Simon Wilkinson's MIT compat and GSS patches. It does not. I included two versions: one for plain OpenSSH 3.0.2p1 and one for 3.0.2p1 w/ Simon's patches. Either patch allows the use of Kerberos principal names in authorized_keys entries. OpenSSH 3.0.2p1 comes with Kerberos IV and Kerberos V support for SSHv1, and my patch allows you to authorized kerberos-authenticated SSHv1 connections via authorized_keys entries. If you have Simon's patches installed then you can also use authorized_keys to authorize GSS-API/kerberos-authenticated SSHv2 connections. Comments? Nico On Thu, Jan 24, 2002 at 11:54:52AM -0500, Nicolas Williams wrote: > This patch (to OpenSSH 3.0.2p1) adds support for using krb4, krb5 and > other principal names in authorized_keys entries. > > It's a sort of replacement for .klogin and .k5login, but it's much more > general than .k*login as it applies to any authentication mechanism > where a name is associated with the ssh client and it supports name > patterns and all the normal authorized_keys entry options we're used to. > > Now you can have entries like these in your authorized_keys files: > > ssh-ext-named:krb5 someuser at SOMEREALM > deny-access ssh-ext-named:krb5 joe/superroot at SOMEREALM > ssh-ext-name-pat:krb5 */superroot at SOMERALM > command=/local/bin/inventory ssh-name-pat:krb5 inventory/*.mydomain at MYREALM > ... > > Double quotes can be used when key names contain whitespace and '\' can > be used inside double-quotes to quote quote (use '\\' for '\')... > > This feature applies to SSHv1 krb4 and krb5 auth. It also applies to > SSHv2, with Simon Wilkinson's gsskeyex patch, to GSS-API authentication, > either with the Kerberos V GSS mechanism or the GSI GSS mechanism. > > Features added: > > - ssh-named key entry type for authorized_keys files > - ssh-name-pat key entry type for authorized_keys files > > - deny-access option for authorized_keys files > > - SSH_AUTH_NAME env var added by sshd for clients with named keys > - SSH_AUTH_NAME_TYPE env var added by sshd for clients with named keys > > I really hope that this feature or a variation thereof will find its way > into OpenSSH. In conjunction with Kerberos (IV or V) it can be extremely > useful: > > - key management is simplified: key management is done at the KDC and > there is no need to edit authorized_keys files all over to change or > revoke keys! > > - authorized_keys is much more featureful than .klogin and .k5login > are, regardless of Kerberos implementation source (KTH, Heimdal, MIT, > SEAM, all implement pretty much the same all-or-nothing > .klogin/.k5login functionality). > > - patterns can be very useful. For example: > > command=/local/bin/inventory ssh-name-pat:krb5 inventory/*.mydomain at MYREALM > > which allows me to setup new inventory master hosts without having to > change ~root/.authorized_keys on all thousands of servers. > > Below you should find two versions of this patch, one against OpenSSH > 3.0.2p1, the other against 3.0.2p1 + Simon Willkinson's GSS-API patches. > > Files modified: > > - key.h > - added KEY_NAME key type > - added KEY_NAME_PAT key type > - added name, name_len and name_type fields to the Key struct > - added prototype for key_match() > > - key.c > - added initialization/finalization of new Key fields to key_new()/key_free() > - added named/pattern key type support to a variety of functions, > including key_read() and key_write(), among others > - added key_match() implementation > > - auth-options.h > - added void auth_set_key_env(Key *) prototype > > - auth-options.c > - added auth_set_key_env() implementation > - modified auth_parse_options() to return (-1) when new deny-access > option is encountered > > - auth-rsa.c > - modified auth_parse_options() return value check according to the > change made to auth_parse_options() > > - auth2.c > - user_key_allowed() is not static now > - modified user_key_allowed2() to: > - try key_match() if key_equal() fails > - check the result of auth_parse_options() for negative, 0, or > positive values. > - modified userauth_pubkey() to check for a positive return from > user_key_allowed() > > - sshd.8 > - added documentation for new key types and the new auth_keys option > > - auth-krb4.c > - modified auth_krb4() to build a Key struct and call user_key_allowed() > > - auth-krb5.c > - modified auth_krb5() to build a Key struct and call user_key_allowed() > > - gss-serv.c > - modified ssh_gssapi_krb5_userok() to build a Key struct and > call user_key_allowed() > > > Comments? > > > Nico > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- Content-Description: patch against OpenSSH 3.0.2p1 > Index: 3_0_2p1.1/sshd.8 > --- 3_0_2p1.1/sshd.8 Thu, 10 Jan 2002 14:11:10 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/sshd.8 Thu, 24 Jan 2002 10:52:24 -0500 > @@ -932,7 +932,8 @@ > is the default file that lists the public keys that are > permitted for RSA authentication in protocol version 1 > and for public key authentication (PubkeyAuthentication) > -in protocol version 2. > +in protocol version 2. It can also list key names or key patterns > +for external authentication systems, such as krb4, krb5, gsi, etc... > .Cm AuthorizedKeysFile > may be used to specify an alternative file. > .Pp > @@ -955,7 +956,19 @@ > For protocol version 2 the keytype is > .Dq ssh-dss > or > -.Dq ssh-rsa . > +.Dq ssh-rsa > +or > +.Dq ssh-named: > +or > +.Dq ssh-name-pat: . > +.Pp > +Named keys and key name patterns follow the latter two, in double > +quotes if they contain whitespace. Named key types may include: > +.Dq krb4 , > +.Dq krb5 > +and/or > +.Dq gsi , > +depending on what features are compiled in to OpenSSH. > .Pp > Note that lines in this file are usually several hundred bytes long > (because of the size of the RSA key modulus). > @@ -1017,6 +1030,10 @@ > This option is automatically disabled if > .Cm UseLogin > is enabled. > +.It Cm deny-access > +This option ends authorized_keys2 processing if the key matches. This > +option is only really useful with named key and named key pattern > +entries. > .It Cm no-port-forwarding > Forbids TCP/IP forwarding when this key is used for authentication. > Any port forward requests by the client will return an error. > Index: 3_0_2p1.1/key.h > --- 3_0_2p1.1/key.h Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/key.h Thu, 24 Jan 2002 10:52:24 -0500 > @@ -34,7 +34,9 @@ > KEY_RSA1, > KEY_RSA, > KEY_DSA, > - KEY_UNSPEC > + KEY_UNSPEC, > + KEY_NAME, > + KEY_NAME_PAT > }; > enum fp_type { > SSH_FP_SHA1, > @@ -53,12 +55,15 @@ > int flags; > RSA *rsa; > DSA *dsa; > + u_char *name; > + char *name_type; > }; > > Key *key_new(int); > Key *key_new_private(int); > void key_free(Key *); > int key_equal(Key *, Key *); > +int key_match(Key *a, Key *b); > char *key_fingerprint(Key *, enum fp_type, enum fp_rep); > char *key_type(Key *); > int key_write(Key *, FILE *); > Index: 3_0_2p1.1/key.c > --- 3_0_2p1.1/key.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/key.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -57,6 +57,8 @@ > k->flags = 0; > k->dsa = NULL; > k->rsa = NULL; > + k->name = NULL; > + k->name_type = NULL; > switch (k->type) { > case KEY_RSA1: > case KEY_RSA: > @@ -73,6 +75,8 @@ > dsa->pub_key = BN_new(); > k->dsa = dsa; > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > case KEY_UNSPEC: > break; > default: > @@ -120,6 +124,13 @@ > DSA_free(k->dsa); > k->dsa = NULL; > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > + if (k->name != NULL) > + xfree(k->name); > + if (k->name_type != NULL) > + xfree(k->name_type); > + break; > case KEY_UNSPEC: > break; > default: > @@ -131,8 +142,9 @@ > int > key_equal(Key *a, Key *b) > { > - if (a == NULL || b == NULL || a->type != b->type) > + if (a == NULL || b == NULL || a->type != b->type) { > return 0; > + } > switch (a->type) { > case KEY_RSA1: > case KEY_RSA: > @@ -147,12 +159,65 @@ > BN_cmp(a->dsa->g, b->dsa->g) == 0 && > BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; > break; > + case KEY_NAME: > + if ((a->name_type == NULL && b->name_type == NULL) || > + (a->name_type == b->name_type)) > + return (strcmp(a->name, b->name) == 0); > + if (a->name_type == NULL || b->name_type == NULL) > + return 0; > + if (strcmp(a->name_type, b->name_type) == 0) > + return (strcmp(a->name, b->name) == 0); > + break; > + case KEY_NAME_PAT: > + return 0; > + break; > default: > fatal("key_equal: bad key type %d", a->type); > break; > } > return 0; > } > +int > +key_match(Key *a, Key *b) > +{ > + debug3("key_match: trying to match %x and %x", a, b); > + if (a == NULL || b == NULL) > + return 0; > + > + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); > + /* One key must be a name pattern, the other must be a name */ > + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && > + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) > + return 0; > + > + /* Both keys must have name types, or both must not */ > + /* or one key must have '*' as its name type */ > + if ((a->name_type == NULL && b->name_type != NULL) || > + (b->name_type == NULL && a->name_type != NULL)) { > + > + debug3("key_match: foo"); > + if (a->name_type != NULL && *(a->name_type) != '*') > + return 0; > + if (b->name_type != NULL && *(b->name_type) != '*') > + return 0; > + } > + > + /* Name type "*" matches any name type */ > + /* Otherwise name types must match */ > + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && > + (*(a->name_type) != '*' || *(b->name_type) != '*')) { > + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); > + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); > + return 0; > + } > + > + debug3("key_match: trying to match %s WITH %s", a->name, b->name); > + if (a->type == KEY_NAME_PAT) > + return match_pattern(b->name, a->name); > + else > + return match_pattern(a->name, b->name); > +} > + > > static u_char* > key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) > @@ -161,7 +226,7 @@ > EVP_MD_CTX ctx; > u_char *blob = NULL; > u_char *retval = NULL; > - int len = 0; > + u_int len = 0; > int nlen, elen; > > *dgst_raw_length = 0; > @@ -364,11 +429,12 @@ > { > Key *k; > int success = -1; > - char *cp, *space; > + char *cp, *space, *name_type; > int len, n, type; > u_int bits; > - u_char *blob; > + u_char *blob = NULL; > > + name_type = NULL; > cp = *cpp; > > switch(ret->type) { > @@ -391,6 +457,8 @@ > case KEY_UNSPEC: > case KEY_RSA: > case KEY_DSA: > + case KEY_NAME: > + case KEY_NAME_PAT: > space = strchr(cp, ' '); > if (space == NULL) { > debug3("key_read: no space"); > @@ -398,6 +466,19 @@ > } > *space = '\0'; > type = key_type_from_name(cp); > + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { > + char * colon = NULL; > + > + colon = strchr(cp, ':'); > + > + debug3("key_read: reading named%s key", > + (type == KEY_NAME) ? "" : " pattern"); > + > + if (colon != NULL && *(++colon) != '\0') { > + name_type = xstrdup(colon); > + } else > + name_type == NULL; > + } > *space = ' '; > if (type == KEY_UNSPEC) { > debug3("key_read: no key found"); > @@ -410,31 +491,83 @@ > } > if (ret->type == KEY_UNSPEC) { > ret->type = type; > + } else if (ret->type == KEY_NAME && type == KEY_NAME_PAT) { > + ret->type = type; > } else if (ret->type != type) { > /* is a key, but different type */ > debug3("key_read: type mismatch"); > return -1; > } > - len = 2*strlen(cp); > - blob = xmalloc(len); > - n = uudecode(cp, blob, len); > - if (n < 0) { > - error("key_read: uudecode %s failed", cp); > - return -1; > + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { > + char *p, *p1, ch; > + > + if (cp == NULL || *cp == '\0') > + return -1; > + > + debug3("key_read: reading named key %s", cp); > + k = key_new(ret->type); > + /* Skip whitespace */ > + for ( ; (*cp != '\0') && isspace(*cp) && (*cp != '\n') ; cp++ ) > + ; > + if (*cp == '"') { > + k->name = (unsigned char *) xstrdup(cp+1); > + p = k->name; > + for ( p1 = cp+1 ; *p1 != '\0' ; p1++ ) { > + if (*p1 == '\\') > + p1++; > + else if (*p1 == '"') > + break; > + *p++ = *p1; > + } > + *p = '\0'; > + debug3("key_read: quoted key: %s", k->name); > + } else { > + /* Ignore trailing whitespace */ > + for ( p = cp ; *p != '\0' && !isspace(*p) ; p++ ) > + ; > + ch = *p; > + *p = '\0'; > + k->name = (unsigned char *) xstrdup(cp); > + *p = ch; > + debug3("key_read: key: %s", k->name); > + } > + k->name_type = name_type; > + } else { > + len = 2*strlen(cp); > + blob = xmalloc(len); > + n = uudecode(cp, blob, len); > + if (n < 0) { > + error("key_read: uudecode %s failed", cp); > + return -1; > + } > + k = key_from_blob(blob, n); > } > - k = key_from_blob(blob, n); > if (k == NULL) { > error("key_read: key_from_blob %s failed", cp); > return -1; > } > - xfree(blob); > + if (blob != NULL) > + xfree(blob); > if (k->type != type) { > - error("key_read: type mismatch: encoding error"); > - key_free(k); > - return -1; > + if (! ((ret->type == KEY_NAME) && > + type == KEY_NAME_PAT)) { > + error("key_read: type mismatch: encoding error"); > + key_free(k); > + return -1; > + } > } > /*XXXX*/ > - if (ret->type == KEY_RSA) { > + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { > + /* > + if (ret->name != NULL) > + xfree(ret->name); > + */ > + ret->name = k->name; > + ret->name_type = k->name_type; > + k->name = NULL; > + k->name_type = NULL; > + success = 1; > + } else if (ret->type == KEY_RSA) { > if (ret->rsa != NULL) > RSA_free(ret->rsa); > ret->rsa = k->rsa; > @@ -488,7 +621,7 @@ > } > } else if ((key->type == KEY_DSA && key->dsa != NULL) || > (key->type == KEY_RSA && key->rsa != NULL)) { > - int len, n; > + u_int len, n; > u_char *blob, *uu; > key_to_blob(key, &blob, &len); > uu = xmalloc(2*len); > @@ -499,6 +632,12 @@ > } > xfree(blob); > xfree(uu); > + } else if (key->type == KEY_NAME && key->name != NULL) { > + fprintf(f, "%s ", key_ssh_name(key)); > + if (key->name_type != NULL) > + fprintf(f, ":%s", key->name_type); > + else > + fprintf(f, " \"%s\"", key->name); > } > return success; > } > @@ -515,6 +654,12 @@ > case KEY_DSA: > return "DSA"; > break; > + case KEY_NAME: > + return "Named"; > + break; > + case KEY_NAME_PAT: > + return "Name_Pattern"; > + break; > } > return "unknown"; > } > @@ -528,6 +673,12 @@ > case KEY_DSA: > return "ssh-dss"; > break; > + case KEY_NAME: > + return "ssh-named"; > + break; > + case KEY_NAME_PAT: > + return "ssh-name-pat"; > + break; > } > return "ssh-unknown"; > } > @@ -605,6 +756,14 @@ > BN_copy(n->rsa->n, k->rsa->n); > BN_copy(n->rsa->e, k->rsa->e); > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > + n = key_new(k->type); > + n->name = xstrdup(k->name); > + if (k->name_type) { > + n->name_type = xstrdup(k->name_type); > + } > + break; > default: > fatal("key_from_private: unknown type %d", k->type); > break; > @@ -625,6 +784,26 @@ > return KEY_RSA; > } else if (strcmp(name, "ssh-dss") == 0){ > return KEY_DSA; > + } else if (strcmp(name, "ssh-named") == 0){ > + return KEY_NAME; > + } else if (strncmp(name, "ssh-named:", strlen("ssh-named:")) == 0){ > + return KEY_NAME; > + } else if (strcmp(name, "ssh-name-pat") == 0){ > + return KEY_NAME_PAT; > + } else if (strncmp(name, "ssh-name-pat:", > + strlen("ssh-name-pat:")) == 0){ > + return KEY_NAME_PAT; > + /* Backwards compatibility for previous named key entry forms at UBSW */ > + } else if (strcmp(name, "ssh-ext-named") == 0){ > + return KEY_NAME; > + } else if (strncmp(name, "ssh-ext-named:", > + strlen("ssh-ext-named:")) == 0){ > + return KEY_NAME; > + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ > + return KEY_NAME_PAT; > + } else if (strncmp(name, "ssh-ext-name-pat:", > + strlen("ssh-ext-name-pat:")) == 0){ > + return KEY_NAME_PAT; > } > debug2("key_type_from_name: unknown key type '%s'", name); > return KEY_UNSPEC; > Index: 3_0_2p1.1/auth2.c > --- 3_0_2p1.1/auth2.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth2.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -76,7 +76,7 @@ > /* helper */ > static Authmethod *authmethod_lookup(const char *); > static char *authmethods_get(void); > -static int user_key_allowed(struct passwd *, Key *); > +int user_key_allowed(struct passwd *, Key *); > static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); > > /* auth */ > @@ -476,7 +476,7 @@ > buffer_dump(&b); > #endif > /* test for correct signature */ > - if (user_key_allowed(authctxt->pw, key) && > + if (user_key_allowed(authctxt->pw, key) > 0 && > key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) > authenticated = 1; > buffer_clear(&b); > @@ -493,7 +493,7 @@ > * if a user is not allowed to login. is this an > * issue? -markus > */ > - if (user_key_allowed(authctxt->pw, key)) { > + if (user_key_allowed(authctxt->pw, key) > 0) { > packet_start(SSH2_MSG_USERAUTH_PK_OK); > packet_put_string(pkalg, alen); > packet_put_string(pkblob, blen); > @@ -719,24 +719,31 @@ > continue; > } > } > - if (key_equal(found, key) && > - auth_parse_options(pw, options, file, linenum) == 1) { > - found_key = 1; > - debug("matching key found: file %s, line %lu", > - file, linenum); > - break; > + if (key_equal(found, key) || key_match(found, key)) { > + found_key = auth_parse_options(pw, options, file, linenum); > + if (found_key != 0) > + break; > + auth_clear_options(); > } > } > restore_uid(); > fclose(f); > key_free(found); > - if (!found_key) > + if (found_key == 0) > debug2("key not found"); > + else if (found_key > 0) { > + debug("matching key found: file %s, line %lu", > + file, linenum); > + auth_set_key_env(key); > + } else > + debug("matching deny key found: file %s, line %lu", > + file, linenum); > + > return found_key; > } > > /* check whether given key is in .ssh/authorized_keys* */ > -static int > +int > user_key_allowed(struct passwd *pw, Key *key) > { > int success; > @@ -745,7 +752,7 @@ > file = authorized_keys_file(pw); > success = user_key_allowed2(pw, key, file); > xfree(file); > - if (success) > + if (success != 0) > return success; > > /* try suffix "2" for backward compat, too */ > Index: 3_0_2p1.1/auth-rsa.c > --- 3_0_2p1.1/auth-rsa.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth-rsa.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -232,7 +232,7 @@ > * If our options do not allow this key to be used, > * do not send challenge. > */ > - if (!auth_parse_options(pw, options, file, linenum)) > + if (auth_parse_options(pw, options, file, linenum) < 1) > continue; > > /* Perform the challenge-response dialog for this key. */ > Index: 3_0_2p1.1/auth-options.h > --- 3_0_2p1.1/auth-options.h Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth-options.h Thu, 24 Jan 2002 10:52:24 -0500 > @@ -16,6 +16,8 @@ > #ifndef AUTH_OPTIONS_H > #define AUTH_OPTIONS_H > > +#include "key.h" > + > /* Linked list of custom environment strings */ > struct envstring { > struct envstring *next; > @@ -31,6 +33,8 @@ > extern struct envstring *custom_environment; > > int auth_parse_options(struct passwd *, char *, char *, u_long); > +void auth_set_key_env(Key *k); > void auth_clear_options(void); > + > > #endif > Index: 3_0_2p1.1/auth-options.c > --- 3_0_2p1.1/auth-options.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth-options.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -56,8 +56,43 @@ > channel_clear_permitted_opens(); > } > > +void auth_set_key_env(Key *k) > +{ > + struct envstring *new_env; > + char *s; > + int len; > + > + if (k->type != KEY_NAME) > + return; > + > + len = strlen("SSH_AUTH_NAME="); > + len += strlen(k->name) + 1; > + s = xmalloc(len); > + snprintf(s, len, "SSH_AUTH_NAME=%s", k->name); > + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); > + new_env = xmalloc(sizeof(struct envstring)); > + new_env->s = s; > + new_env->next = custom_environment; > + custom_environment = new_env; > + > + if (k->name_type == NULL) > + return; > + > + len = strlen("SSH_AUTH_NAME_TYPE="); > + len += strlen(k->name_type) + 1; > + s = xmalloc(len); > + snprintf(s, len, "SSH_AUTH_NAME_TYPE=%s", k->name_type); > + > + new_env = xmalloc(sizeof(struct envstring)); > + new_env->s = s; > + new_env->next = custom_environment; > + custom_environment = new_env; > + > + return; > +} > + > /* > - * return 1 if access is granted, 0 if not. > + * return 1 if access is granted, 0 if not, -1 if access explicitly denied > * side effect: sets key option flags > */ > int > @@ -73,6 +108,12 @@ > return 1; > > while (*opts && *opts != ' ' && *opts != '\t') { > + cp = "deny-access"; > + if (strncasecmp(opts, cp, strlen(cp)) == 0) { > + log("Authentication successful, but authorization denied"); > + packet_send_debug("Permission denied"); > + return -1; > + } > cp = "no-port-forwarding"; > if (strncasecmp(opts, cp, strlen(cp)) == 0) { > packet_send_debug("Port forwarding disabled."); > Index: 3_0_2p1.1/auth-krb4.c > --- 3_0_2p1.1/auth-krb4.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth-krb4.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -40,6 +40,7 @@ > > #ifdef KRB4 > extern ServerOptions options; > +int user_key_allowed(struct passwd *, Key *); > > static int > krb4_init(void *context) > @@ -220,6 +221,7 @@ > socklen_t slen; > u_int cksum; > int r, s; > + Key k; > > s = packet_get_connection_in(); > > @@ -249,12 +251,27 @@ > *adat.pinst ? "." : "", adat.pinst, adat.prealm); > > /* Check ~/.klogin authorization now. */ > - if (kuserok(&adat, authctxt->user) != KSUCCESS) { > - log("Kerberos v4 .klogin authorization failed for %s to " > - "account %s", *client, authctxt->user); > + k.type = KEY_NAME; > + k.name = *client; > + k.name_type = "krb4"; > + > + r = user_key_allowed(authctxt->pw, &k); > + > + if (r < 0) { > + log("Kerberos v4 %s authorization failed for %s to " > + "account %s", "authorized_keys", *client, authctxt->user); > xfree(*client); > return (0); > } > + > + if (r == 0 && kuserok(&adat, authctxt->user) != KSUCCESS) { > + log("Kerberos v4 %s authorization failed for %s to " > + "account %s", (r == 0) ? ".klogin" : "authorized_keys", > + *client, authctxt->user); > + xfree(*client); > + return (0); > + } > + > /* Increment the checksum, and return it encrypted with the > session key. */ > cksum = adat.checksum + 1; > Index: 3_0_2p1.1/auth-krb5.c > --- 3_0_2p1.1/auth-krb5.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_named_keys.1(w)/auth-krb5.c Thu, 24 Jan 2002 10:52:24 -0500 > @@ -19,6 +19,7 @@ > #include > > extern ServerOptions options; > +int user_key_allowed(struct passwd *, Key *); > > static int > krb5_init(void *context) > @@ -52,6 +53,8 @@ > krb5_principal server; > krb5_data reply; > krb5_ticket *ticket; > + Key k; > + char *client_name; > int fd, ret; > > ret = 0; > @@ -95,14 +98,30 @@ > if (problem) > goto err; > > + if (!krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, > + &client_name)) > + goto err; > + > /* Check .k5login authorization now. */ > - if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, > - authctxt->pw->pw_name)) > + k.type = KEY_NAME; > + k.name = client_name; > + k.name_type = "krb5"; > + > + ret = user_key_allowed(authctxt->pw, &k); > + if (ret < 0) { > + ret = 0; > goto err; > + } > + if (ret == 0 && !krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, > + authctxt->pw->pw_name)) { > + log("SSHv1 Kerberos v5 %s authorization failed for %s to " > + "account %s", (ret == 0) ? ".k5login" : "authorized_keys", > + *client, authctxt->user); > + goto err; > + } > > if (client) > - krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, > - client); > + *client = client_name; > > packet_start(SSH_SMSG_AUTH_KERBEROS_RESPONSE); > packet_put_string((char *) reply.data, reply.length); Content-Description: patch against OpenSSH 3.0.2p1 w/ gsskeyex > Index: 3_0_2p1_w_gss.1/sshd.8 > --- 3_0_2p1_w_gss.1/sshd.8 Thu, 10 Jan 2002 14:22:14 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/sshd.8 Fri, 18 Jan 2002 14:15:53 -0500 > @@ -951,7 +951,8 @@ > is the default file that lists the public keys that are > permitted for RSA authentication in protocol version 1 > and for public key authentication (PubkeyAuthentication) > -in protocol version 2. > +in protocol version 2. It can also list key names or key patterns > +for external authentication systems, such as krb4, krb5, gsi, etc... > .Cm AuthorizedKeysFile > may be used to specify an alternative file. > .Pp > @@ -974,7 +975,19 @@ > For protocol version 2 the keytype is > .Dq ssh-dss > or > -.Dq ssh-rsa . > +.Dq ssh-rsa > +or > +.Dq ssh-named: > +or > +.Dq ssh-name-pat: . > +.Pp > +Named keys and key name patterns follow the latter two, in double > +quotes if they contain whitespace. Named key types may include: > +.Dq krb4 , > +.Dq krb5 > +and/or > +.Dq gsi , > +depending on what features are compiled in to OpenSSH. > .Pp > Note that lines in this file are usually several hundred bytes long > (because of the size of the RSA key modulus). > @@ -1036,6 +1049,10 @@ > This option is automatically disabled if > .Cm UseLogin > is enabled. > +.It Cm deny-access > +This option ends authorized_keys2 processing if the key matches. This > +option is only really useful with named key and named key pattern > +entries. > .It Cm no-port-forwarding > Forbids TCP/IP forwarding when this key is used for authentication. > Any port forward requests by the client will return an error. > Index: 3_0_2p1_w_gss.1/key.h > --- 3_0_2p1_w_gss.1/key.h Thu, 10 Jan 2002 14:22:14 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/key.h Fri, 18 Jan 2002 12:24:41 -0500 > @@ -35,7 +35,9 @@ > KEY_RSA, > KEY_DSA, > KEY_NULL, > - KEY_UNSPEC > + KEY_UNSPEC, > + KEY_NAME, > + KEY_NAME_PAT > }; > enum fp_type { > SSH_FP_SHA1, > @@ -54,12 +56,15 @@ > int flags; > RSA *rsa; > DSA *dsa; > + u_char *name; > + char *name_type; > }; > > Key *key_new(int); > Key *key_new_private(int); > void key_free(Key *); > int key_equal(Key *, Key *); > +int key_match(Key *a, Key *b); > char *key_fingerprint(Key *, enum fp_type, enum fp_rep); > char *key_type(Key *); > int key_write(Key *, FILE *); > Index: 3_0_2p1_w_gss.1/key.c > --- 3_0_2p1_w_gss.1/key.c Thu, 10 Jan 2002 14:22:14 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/key.c Fri, 18 Jan 2002 17:21:17 -0500 > @@ -57,6 +57,8 @@ > k->flags = 0; > k->dsa = NULL; > k->rsa = NULL; > + k->name = NULL; > + k->name_type = NULL; > switch (k->type) { > case KEY_RSA1: > case KEY_RSA: > @@ -73,6 +75,8 @@ > dsa->pub_key = BN_new(); > k->dsa = dsa; > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > case KEY_UNSPEC: > break; > default: > @@ -120,6 +124,13 @@ > DSA_free(k->dsa); > k->dsa = NULL; > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > + if (k->name != NULL) > + xfree(k->name); > + if (k->name_type != NULL) > + xfree(k->name_type); > + break; > case KEY_UNSPEC: > break; > default: > @@ -131,8 +142,9 @@ > int > key_equal(Key *a, Key *b) > { > - if (a == NULL || b == NULL || a->type != b->type) > + if (a == NULL || b == NULL || a->type != b->type) { > return 0; > + } > switch (a->type) { > case KEY_RSA1: > case KEY_RSA: > @@ -147,12 +159,65 @@ > BN_cmp(a->dsa->g, b->dsa->g) == 0 && > BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; > break; > + case KEY_NAME: > + if ((a->name_type == NULL && b->name_type == NULL) || > + (a->name_type == b->name_type)) > + return (strcmp(a->name, b->name) == 0); > + if (a->name_type == NULL || b->name_type == NULL) > + return 0; > + if (strcmp(a->name_type, b->name_type) == 0) > + return (strcmp(a->name, b->name) == 0); > + break; > + case KEY_NAME_PAT: > + return 0; > + break; > default: > fatal("key_equal: bad key type %d", a->type); > break; > } > return 0; > } > +int > +key_match(Key *a, Key *b) > +{ > + debug3("key_match: trying to match %x and %x", a, b); > + if (a == NULL || b == NULL) > + return 0; > + > + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); > + /* One key must be a name pattern, the other must be a name */ > + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && > + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) > + return 0; > + > + /* Both keys must have name types, or both must not */ > + /* or one key must have '*' as its name type */ > + if ((a->name_type == NULL && b->name_type != NULL) || > + (b->name_type == NULL && a->name_type != NULL)) { > + > + debug3("key_match: foo"); > + if (a->name_type != NULL && *(a->name_type) != '*') > + return 0; > + if (b->name_type != NULL && *(b->name_type) != '*') > + return 0; > + } > + > + /* Name type "*" matches any name type */ > + /* Otherwise name types must match */ > + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && > + (*(a->name_type) != '*' || *(b->name_type) != '*')) { > + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); > + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); > + return 0; > + } > + > + debug3("key_match: trying to match %s WITH %s", a->name, b->name); > + if (a->type == KEY_NAME_PAT) > + return match_pattern(b->name, a->name); > + else > + return match_pattern(a->name, b->name); > +} > + > > static u_char* > key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) > @@ -161,7 +226,7 @@ > EVP_MD_CTX ctx; > u_char *blob = NULL; > u_char *retval = NULL; > - int len = 0; > + u_int len = 0; > int nlen, elen; > > *dgst_raw_length = 0; > @@ -364,11 +429,12 @@ > { > Key *k; > int success = -1; > - char *cp, *space; > + char *cp, *space, *name_type; > int len, n, type; > u_int bits; > - u_char *blob; > + u_char *blob = NULL; > > + name_type = NULL; > cp = *cpp; > > switch(ret->type) { > @@ -391,6 +457,8 @@ > case KEY_UNSPEC: > case KEY_RSA: > case KEY_DSA: > + case KEY_NAME: > + case KEY_NAME_PAT: > space = strchr(cp, ' '); > if (space == NULL) { > debug3("key_read: no space"); > @@ -398,6 +466,19 @@ > } > *space = '\0'; > type = key_type_from_name(cp); > + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { > + char * colon = NULL; > + > + colon = strchr(cp, ':'); > + > + debug3("key_read: reading named%s key", > + (type == KEY_NAME) ? "" : " pattern"); > + > + if (colon != NULL && *(++colon) != '\0') { > + name_type = xstrdup(colon); > + } else > + name_type == NULL; > + } > *space = ' '; > if (type == KEY_UNSPEC) { > debug3("key_read: no key found"); > @@ -410,31 +491,83 @@ > } > if (ret->type == KEY_UNSPEC) { > ret->type = type; > + } else if (ret->type == KEY_NAME && type == KEY_NAME_PAT) { > + ret->type = type; > } else if (ret->type != type) { > /* is a key, but different type */ > debug3("key_read: type mismatch"); > return -1; > } > - len = 2*strlen(cp); > - blob = xmalloc(len); > - n = uudecode(cp, blob, len); > - if (n < 0) { > - error("key_read: uudecode %s failed", cp); > - return -1; > + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { > + char *p, *p1, ch; > + > + if (cp == NULL || *cp == '\0') > + return -1; > + > + debug3("key_read: reading named key %s", cp); > + k = key_new(ret->type); > + /* Skip whitespace */ > + for ( ; (*cp != '\0') && isspace(*cp) && (*cp != '\n') ; cp++ ) > + ; > + if (*cp == '"') { > + k->name = (unsigned char *) xstrdup(cp+1); > + p = k->name; > + for ( p1 = cp+1 ; *p1 != '\0' ; p1++ ) { > + if (*p1 == '\\') > + p1++; > + else if (*p1 == '"') > + break; > + *p++ = *p1; > + } > + *p = '\0'; > + debug3("key_read: quoted key: %s", k->name); > + } else { > + /* Ignore trailing whitespace */ > + for ( p = cp ; *p != '\0' && !isspace(*p) ; p++ ) > + ; > + ch = *p; > + *p = '\0'; > + k->name = (unsigned char *) xstrdup(cp); > + *p = ch; > + debug3("key_read: key: %s", k->name); > + } > + k->name_type = name_type; > + } else { > + len = 2*strlen(cp); > + blob = xmalloc(len); > + n = uudecode(cp, blob, len); > + if (n < 0) { > + error("key_read: uudecode %s failed", cp); > + return -1; > + } > + k = key_from_blob(blob, n); > } > - k = key_from_blob(blob, n); > if (k == NULL) { > error("key_read: key_from_blob %s failed", cp); > return -1; > } > - xfree(blob); > + if (blob != NULL) > + xfree(blob); > if (k->type != type) { > - error("key_read: type mismatch: encoding error"); > - key_free(k); > - return -1; > + if (! ((ret->type == KEY_NAME) && > + type == KEY_NAME_PAT)) { > + error("key_read: type mismatch: encoding error"); > + key_free(k); > + return -1; > + } > } > /*XXXX*/ > - if (ret->type == KEY_RSA) { > + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { > + /* > + if (ret->name != NULL) > + xfree(ret->name); > + */ > + ret->name = k->name; > + ret->name_type = k->name_type; > + k->name = NULL; > + k->name_type = NULL; > + success = 1; > + } else if (ret->type == KEY_RSA) { > if (ret->rsa != NULL) > RSA_free(ret->rsa); > ret->rsa = k->rsa; > @@ -488,7 +621,7 @@ > } > } else if ((key->type == KEY_DSA && key->dsa != NULL) || > (key->type == KEY_RSA && key->rsa != NULL)) { > - int len, n; > + u_int len, n; > u_char *blob, *uu; > key_to_blob(key, &blob, &len); > uu = xmalloc(2*len); > @@ -499,6 +632,12 @@ > } > xfree(blob); > xfree(uu); > + } else if (key->type == KEY_NAME && key->name != NULL) { > + fprintf(f, "%s ", key_ssh_name(key)); > + if (key->name_type != NULL) > + fprintf(f, ":%s", key->name_type); > + else > + fprintf(f, " \"%s\"", key->name); > } > return success; > } > @@ -515,6 +654,12 @@ > case KEY_DSA: > return "DSA"; > break; > + case KEY_NAME: > + return "Named"; > + break; > + case KEY_NAME_PAT: > + return "Name_Pattern"; > + break; > } > return "unknown"; > } > @@ -528,6 +673,12 @@ > case KEY_DSA: > return "ssh-dss"; > break; > + case KEY_NAME: > + return "ssh-named"; > + break; > + case KEY_NAME_PAT: > + return "ssh-name-pat"; > + break; > } > return "ssh-unknown"; > } > @@ -605,6 +756,14 @@ > BN_copy(n->rsa->n, k->rsa->n); > BN_copy(n->rsa->e, k->rsa->e); > break; > + case KEY_NAME: > + case KEY_NAME_PAT: > + n = key_new(k->type); > + n->name = xstrdup(k->name); > + if (k->name_type) { > + n->name_type = xstrdup(k->name_type); > + } > + break; > default: > fatal("key_from_private: unknown type %d", k->type); > break; > @@ -625,6 +784,26 @@ > return KEY_RSA; > } else if (strcmp(name, "ssh-dss") == 0){ > return KEY_DSA; > + } else if (strcmp(name, "ssh-named") == 0){ > + return KEY_NAME; > + } else if (strncmp(name, "ssh-named:", strlen("ssh-named:")) == 0){ > + return KEY_NAME; > + } else if (strcmp(name, "ssh-name-pat") == 0){ > + return KEY_NAME_PAT; > + } else if (strncmp(name, "ssh-name-pat:", > + strlen("ssh-name-pat:")) == 0){ > + return KEY_NAME_PAT; > + /* Backwards compatibility for previous named key entry forms at UBSW */ > + } else if (strcmp(name, "ssh-ext-named") == 0){ > + return KEY_NAME; > + } else if (strncmp(name, "ssh-ext-named:", > + strlen("ssh-ext-named:")) == 0){ > + return KEY_NAME; > + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ > + return KEY_NAME_PAT; > + } else if (strncmp(name, "ssh-ext-name-pat:", > + strlen("ssh-ext-name-pat:")) == 0){ > + return KEY_NAME_PAT; > } else if (strcmp(name, "null") == 0){ > return KEY_NULL; > } > Index: 3_0_2p1_w_gss.1/auth2.c > --- 3_0_2p1_w_gss.1/auth2.c Thu, 10 Jan 2002 14:22:14 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth2.c Fri, 18 Jan 2002 12:24:41 -0500 > @@ -80,7 +80,7 @@ > /* helper */ > static Authmethod *authmethod_lookup(const char *); > static char *authmethods_get(void); > -static int user_key_allowed(struct passwd *, Key *); > +int user_key_allowed(struct passwd *, Key *); > static int hostbased_key_allowed(struct passwd *, const char *, char *, Key *); > > /* auth */ > @@ -499,7 +499,7 @@ > buffer_dump(&b); > #endif > /* test for correct signature */ > - if (user_key_allowed(authctxt->pw, key) && > + if (user_key_allowed(authctxt->pw, key) > 0 && > key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) > authenticated = 1; > buffer_clear(&b); > @@ -516,7 +516,7 @@ > * if a user is not allowed to login. is this an > * issue? -markus > */ > - if (user_key_allowed(authctxt->pw, key)) { > + if (user_key_allowed(authctxt->pw, key) > 0) { > packet_start(SSH2_MSG_USERAUTH_PK_OK); > packet_put_string(pkalg, alen); > packet_put_string(pkblob, blen); > @@ -742,24 +742,31 @@ > continue; > } > } > - if (key_equal(found, key) && > - auth_parse_options(pw, options, file, linenum) == 1) { > - found_key = 1; > - debug("matching key found: file %s, line %lu", > - file, linenum); > - break; > + if (key_equal(found, key) || key_match(found, key)) { > + found_key = auth_parse_options(pw, options, file, linenum); > + if (found_key != 0) > + break; > + auth_clear_options(); > } > } > restore_uid(); > fclose(f); > key_free(found); > - if (!found_key) > + if (found_key == 0) > debug2("key not found"); > + else if (found_key > 0) { > + debug("matching key found: file %s, line %lu", > + file, linenum); > + auth_set_key_env(key); > + } else > + debug("matching deny key found: file %s, line %lu", > + file, linenum); > + > return found_key; > } > > /* check whether given key is in .ssh/authorized_keys* */ > -static int > +int > user_key_allowed(struct passwd *pw, Key *key) > { > int success; > @@ -768,7 +775,7 @@ > file = authorized_keys_file(pw); > success = user_key_allowed2(pw, key, file); > xfree(file); > - if (success) > + if (success != 0) > return success; > > /* try suffix "2" for backward compat, too */ > Index: 3_0_2p1_w_gss.1/auth-rsa.c > --- 3_0_2p1_w_gss.1/auth-rsa.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-rsa.c Fri, 18 Jan 2002 12:24:41 -0500 > @@ -232,7 +232,7 @@ > * If our options do not allow this key to be used, > * do not send challenge. > */ > - if (!auth_parse_options(pw, options, file, linenum)) > + if (auth_parse_options(pw, options, file, linenum) < 1) > continue; > > /* Perform the challenge-response dialog for this key. */ > Index: 3_0_2p1_w_gss.1/auth-options.h > --- 3_0_2p1_w_gss.1/auth-options.h Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-options.h Fri, 18 Jan 2002 12:24:41 -0500 > @@ -16,6 +16,8 @@ > #ifndef AUTH_OPTIONS_H > #define AUTH_OPTIONS_H > > +#include "key.h" > + > /* Linked list of custom environment strings */ > struct envstring { > struct envstring *next; > @@ -31,6 +33,8 @@ > extern struct envstring *custom_environment; > > int auth_parse_options(struct passwd *, char *, char *, u_long); > +void auth_set_key_env(Key *k); > void auth_clear_options(void); > + > > #endif > Index: 3_0_2p1_w_gss.1/auth-options.c > --- 3_0_2p1_w_gss.1/auth-options.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-options.c Fri, 18 Jan 2002 12:24:41 -0500 > @@ -56,8 +56,43 @@ > channel_clear_permitted_opens(); > } > > +void auth_set_key_env(Key *k) > +{ > + struct envstring *new_env; > + char *s; > + int len; > + > + if (k->type != KEY_NAME) > + return; > + > + len = strlen("SSH_AUTH_NAME="); > + len += strlen(k->name) + 1; > + s = xmalloc(len); > + snprintf(s, len, "SSH_AUTH_NAME=%s", k->name); > + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); > + new_env = xmalloc(sizeof(struct envstring)); > + new_env->s = s; > + new_env->next = custom_environment; > + custom_environment = new_env; > + > + if (k->name_type == NULL) > + return; > + > + len = strlen("SSH_AUTH_NAME_TYPE="); > + len += strlen(k->name_type) + 1; > + s = xmalloc(len); > + snprintf(s, len, "SSH_AUTH_NAME_TYPE=%s", k->name_type); > + > + new_env = xmalloc(sizeof(struct envstring)); > + new_env->s = s; > + new_env->next = custom_environment; > + custom_environment = new_env; > + > + return; > +} > + > /* > - * return 1 if access is granted, 0 if not. > + * return 1 if access is granted, 0 if not, -1 if access explicitly denied > * side effect: sets key option flags > */ > int > @@ -73,6 +108,12 @@ > return 1; > > while (*opts && *opts != ' ' && *opts != '\t') { > + cp = "deny-access"; > + if (strncasecmp(opts, cp, strlen(cp)) == 0) { > + log("Authentication successful, but authorization denied"); > + packet_send_debug("Permission denied"); > + return -1; > + } > cp = "no-port-forwarding"; > if (strncasecmp(opts, cp, strlen(cp)) == 0) { > packet_send_debug("Port forwarding disabled."); > Index: 3_0_2p1_w_gss.1/auth-krb4.c > --- 3_0_2p1_w_gss.1/auth-krb4.c Wed, 21 Nov 2001 10:38:46 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-krb4.c Fri, 18 Jan 2002 14:44:13 -0500 > @@ -40,6 +40,7 @@ > > #ifdef KRB4 > extern ServerOptions options; > +int user_key_allowed(struct passwd *, Key *); > > static int > krb4_init(void *context) > @@ -220,6 +221,7 @@ > socklen_t slen; > u_int cksum; > int r, s; > + Key k; > > s = packet_get_connection_in(); > > @@ -249,12 +251,27 @@ > *adat.pinst ? "." : "", adat.pinst, adat.prealm); > > /* Check ~/.klogin authorization now. */ > - if (kuserok(&adat, authctxt->user) != KSUCCESS) { > - log("Kerberos v4 .klogin authorization failed for %s to " > - "account %s", *client, authctxt->user); > + k.type = KEY_NAME; > + k.name = *client; > + k.name_type = "krb4"; > + > + r = user_key_allowed(authctxt->pw, &k); > + > + if (r < 0) { > + log("Kerberos v4 %s authorization failed for %s to " > + "account %s", "authorized_keys", *client, authctxt->user); > xfree(*client); > return (0); > } > + > + if (r == 0 && kuserok(&adat, authctxt->user) != KSUCCESS) { > + log("Kerberos v4 %s authorization failed for %s to " > + "account %s", (r == 0) ? ".klogin" : "authorized_keys", > + *client, authctxt->user); > + xfree(*client); > + return (0); > + } > + > /* Increment the checksum, and return it encrypted with the > session key. */ > cksum = adat.checksum + 1; > Index: 3_0_2p1_w_gss.1/auth-krb5.c > --- 3_0_2p1_w_gss.1/auth-krb5.c Thu, 10 Jan 2002 14:22:14 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/auth-krb5.c Fri, 18 Jan 2002 14:44:54 -0500 > @@ -22,6 +22,7 @@ > #endif /* !HEIMDAL */ > > extern ServerOptions options; > +int user_key_allowed(struct passwd *, Key *); > > static int > krb5_init(void *context) > @@ -55,6 +56,8 @@ > krb5_principal server; > krb5_data reply; > krb5_ticket *ticket; > + Key k; > + char *client_name; > int fd, ret; > > ret = 0; > @@ -110,14 +113,30 @@ > if (problem) > goto err; > > + if (!krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, > + &client_name)) > + goto err; > + > /* Check .k5login authorization now. */ > - if (!krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, > - authctxt->pw->pw_name)) > + k.type = KEY_NAME; > + k.name = client_name; > + k.name_type = "krb5"; > + > + ret = user_key_allowed(authctxt->pw, &k); > + if (ret < 0) { > + ret = 0; > goto err; > + } > + if (ret == 0 && !krb5_kuserok(authctxt->krb5_ctx, authctxt->krb5_user, > + authctxt->pw->pw_name)) { > + log("SSHv1 Kerberos v5 %s authorization failed for %s to " > + "account %s", (ret == 0) ? ".k5login" : "authorized_keys", > + *client, authctxt->user); > + goto err; > + } > > if (client) > - krb5_unparse_name(authctxt->krb5_ctx, authctxt->krb5_user, > - client); > + *client = client_name; > > packet_start(SSH_SMSG_AUTH_KERBEROS_RESPONSE); > packet_put_string((char *) reply.data, reply.length); > Index: 3_0_2p1_w_gss.1/gss-serv.c > --- 3_0_2p1_w_gss.1/gss-serv.c Thu, 10 Jan 2002 15:57:24 -0500 > +++ 3_0_2p1_w_gss_w_named_keys.14(w)/gss-serv.c Fri, 18 Jan 2002 12:24:41 -0500 > @@ -48,6 +48,7 @@ > extern ServerOptions options; > extern u_char *session_id2; > extern int session_id2_len; > +int user_key_allowed(struct passwd *, Key *); > > > typedef struct ssh_gssapi_cred_cache { > @@ -98,24 +99,39 @@ > ssh_gssapi_krb5_userok(char *name) { > krb5_principal princ; > int retval; > + char *by; > + Key k; > > if (ssh_gssapi_krb5_init() == 0) > return 0; > - > + > + k.type = KEY_NAME; > + k.name = gssapi_client_name.value; > + k.name_type = "krb5"; > + > if ((retval=krb5_parse_name(krb_context, gssapi_client_name.value, > &princ))) { > log("krb5_parse_name(): %.100s", > krb5_get_err_text(krb_context,retval)); > return 0; > } > - if (krb5_kuserok(krb_context, princ, name)) { > + > + /* Try authorized_keys first */ > + by = "authorized_keys"; > + retval = user_key_allowed(getpwnam(name), &k); > + if (retval < 0) { > + debug("ssh_gssapi_krb5_userok: access denied in %s", by); > + krb5_free_principal(krb_context, princ); > + return 0; > + } > + if (retval == 0 && krb5_kuserok(krb_context, princ, name)) { > + by = "krb5_kuserok"; > retval = 1; > - log("Authorized to %s, krb5 principal %s (krb5_kuserok)",name, > - (char *)gssapi_client_name.value); > } > - else > - retval = 0; > > + notice("Authorized to %s, krb5 principal %s (%s)", name, > + (char *)gssapi_client_name.value, by); > + > krb5_free_principal(krb_context, princ); > return retval; > } Content-Description: Legal Disclaimer > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Tue Jan 29 12:55:44 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Mon, 28 Jan 2002 19:55:44 -0600 (CST) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: from Tobias Ringstrom at "Jan 28, 2002 09:12:53 pm" Message-ID: <200201290155.g0T1tiP4011971@etoh.eviladmin.org> [..] > My overlapping reads/writes for sftp seems to be ignored at the moment. > > I'm not happy. > > /Tobias > One thing you must learn Tobias, unless things are clear cut as 'THE WAY' to go there is (and more than likely ever will be) a long period in time from patch conception to inclusion. And this is one in which is not 100% clear cut. Between NoDelay, COPY_SIZE, how many overlapping segments, and if we should let the user muck with them are all things that will affect how we accept the patch. I'm still waiting for you to provide any information on upping COPY_SIZE to 32k and retesting with multiple overlapping. I don't remember seeing such an email messages. However, this should also help lower the amount of overlapping request. As a result lower the cost of a missing request. I don't want to get into the case where sftp thrashes due to multiple pending requests out and a bad link that drops 2 out of 5 packets. Which would not only cause large amount of seeks() but also could trigger edge cases within the code for binary integerity. I don't have the patch infront of me..but there was some bits I did not care for if I remember right. - Ben From bob at proulx.com Tue Jan 29 16:17:46 2002 From: bob at proulx.com (Bob Proulx) Date: Mon, 28 Jan 2002 22:17:46 -0700 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <02a001c1a80e$232d62b0$1701000a@effugas> References: <018001c1a7b1$11b37c70$1701000a@effugas> <20020128085002.GB10384@faui02> <021701c1a7f4$f3125bd0$1701000a@effugas> <20020128122056.GB17992@faui02> <023901c1a7f9$d994afa0$1701000a@effugas> <20020128125727.GA26963@faui02> <025501c1a800$5d62d8b0$1701000a@effugas> <20020128140734.GA6774@faui02> <02a001c1a80e$232d62b0$1701000a@effugas> Message-ID: <15446.12410.138108.475252@torment.proulx.com> > > ??? scp has _zero_ to do with ssh. > SCP is *the* standard method of transfering files over SSH. It is the only > method that has always shipped with SSH. I get to teach a lot of users how to deal with security issues and how to live with firewalls. SSH is obviously a fundamental tool and always gets a major place in the tutorial. But the number two most important and fundamental tool is rsync. I never mention scp unless the user asks specifically about it. SSH and Rsync together form a complete set of replacement software for rlogin and rcp and reduces the number of different new things a user needs to learn about. Perhaps too much time, effort and emphasis is being placed on scp? Bob From djm at mindrot.org Tue Jan 29 16:34:04 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Jan 2002 16:34:04 +1100 (EST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128131842.I27398@sm2p1386swk.wdr.com> Message-ID: On Mon, 28 Jan 2002, Nicolas Williams wrote: > Will useful patches posted to this list receive any consideration for > inclusion in future releases of OpenSSH? > > The most important contributed patch, right now, from my point of view, > is Simon Wilkinson's GSS-API userauth/external key exchange patch. > > Will that be included? I'd like to see the KrbV integration patch included in portable, but I am yet to receive an independant review of it from someone who understands the Kerberos V API properly. I don't know it well enough to feel comfortable commiting it by myself - this is no reflection on Simon, just my own paranoia. IIRC the GSS-API patch was awaiting revision to match the drafts. -d From djm at mindrot.org Tue Jan 29 16:45:36 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Jan 2002 16:45:36 +1100 (EST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <03c801c1a83f$9e34c8f0$1701000a@effugas> Message-ID: On Mon, 28 Jan 2002, Dan Kaminsky wrote: > > they are "implemented" with -o. > > First of all, -o presumes an SSH backend. Markus's argument that SCP has > nothing to do with SSH thus doesn't work, -o presumes _a_ backend. Passing arbitrary options to the backend via -o is more backend-independent than passing SSH specific options via other command-line arguments. I wish people were as vigorous in auditing, patching or testing the CVS code as they were at arguing about trivialities such as -1 options in scp. -d From dbt at meat.net Tue Jan 29 17:27:34 2002 From: dbt at meat.net (David Terrell) Date: Mon, 28 Jan 2002 22:27:34 -0800 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128112648.GA17992@faui02>; from markus@openbsd.org on Mon, Jan 28, 2002 at 12:26:48PM +0100 References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> <20020128112648.GA17992@faui02> Message-ID: <20020128222734.B31828@pianosa.catch22.org> On Mon, Jan 28, 2002 at 12:26:48PM +0100, Markus Friedl wrote: > On Mon, Jan 28, 2002 at 11:55:03AM +0100, Wichert Akkerman wrote: > > Previously Markus Friedl wrote: > > > why do you need -1 and -2? > > > > Users want it, and it's very useful in situations where you need > > to specifiy the version due to existing keys, old servers, etc. > > hm, should there be an extra option for 0.0001% of all > use cases. I use -1, -2 -4 and -6 all the time. Well, mostly -4 and -1 these days. scp implies ssh. (In theory, yes, it can use any 8 bit clean transport, but in practice it implies ssh. If you really want to use this protocol over any transport, use rcmd(3) on a platform that lets you specify $RCMD). -o strikes me as mostly useless. If you're going to specify the long names and be familiar with them, then you might as well put them in .ssh/config and save yourself the typing. Most of the things that need overriding on the command line have their own options on the ssh command line which the user is more familiar with than the long (-o) option. So why not provide a single facility (call it -O perhaps) that passes optarg to the transport program on the command line, with simple whitespace splicing? scp -O '-4 -1' pianosa.catch22.org:/etc/motd . This gives users the convenience of the ssh short options without further bloating the scp command line, and is even little enough fuss that eventually you can kill -4 and -i and whatnot from scp. -- David Terrell | "Consumerism is neat." dbt at meat.net | - Brian Swetland http://wwn.nebcorp.com/ | From tori at ringstrom.mine.nu Tue Jan 29 19:29:37 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 09:29:37 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <200201290155.g0T1tiP4011971@etoh.eviladmin.org> Message-ID: On Mon, 28 Jan 2002, mouring wrote: > [..] > > My overlapping reads/writes for sftp seems to be ignored at the moment. > > > > I'm not happy. > > > > /Tobias > > > One thing you must learn Tobias, unless things are clear cut as 'THE WAY' > to go there is (and more than likely ever will be) a long period in time > from patch conception to inclusion. And this is one in which is not > 100% clear cut. Between NoDelay, COPY_SIZE, how many overlapping > segments, and if we should let the user muck with them are all things that > will affect how we accept the patch. Of course I understand that it may take some time. What I do not understand is whether a long silence after the first flurry of comments to a patch (or a suggested change) means that the patch is under consideration, if it was deemed unacceptable, or if it was simply forgotten. One other thing is that since I did not know who the maintainers were (there seem to be a whole bunch), I did not know what "suggestions" were "masked vetos". > I'm still waiting for you to provide any information on upping COPY_SIZE > to 32k and retesting with multiple overlapping. I don't remember seeing > such an email messages. Looking through my mailboxes, I cannot find such a request, and I do not remember one either. The closest I can find is "Also, you may want to check out pushing BLOCKSIZE (think that is right, not looking at the code) to 4092 which is the max size the RFC states. This may change your testing." This comment was made invalid IMHO after the Nagle interaction problem was found. > However, this should also help lower the amount of overlapping request. > As a result lower the cost of a missing request. I don't want to get > into the case where sftp thrashes due to multiple pending requests out > and a bad link that drops 2 out of 5 packets. Which would not only > cause large amount of seeks() but also could trigger edge cases within > the code for binary integerity. First of all, we only need more than one overlapping request if the delay-bandwidth product of the link is larger than the block size. I do not have any figures for a wide number of links. The reason why I thought I needed more was the interaction with the Nagle algorithm. The Nagle problem is orthogonal, but needs to be resolved. It seems to be very hard to agree on a solution, though. The latest version of the overlap patch (which is several weeks old now) contains code to reduce the request size if the server splits a request. With this mechanism, it should be safe to use a larger initial request size. > I don't have the patch infront of me..but there was some bits I did not > care for if I remember right. Please reconsider the patch in light of the nodelay findings. (And if you do benchmark it, please use TCP_NODELAY in both ends.) /Tobias -------------- next part -------------- diff -ru openssh-3.0.2p1.orig/sftp-client.c openssh-3.0.2p1.sftp/sftp-client.c --- openssh-3.0.2p1.orig/sftp-client.c Wed Jul 18 17:45:45 2001 +++ openssh-3.0.2p1.sftp/sftp-client.c Sun Jan 6 23:13:44 2002 @@ -45,6 +45,15 @@ /* How much data to read/write at at time during copies */ /* XXX: what should this be? */ #define COPY_SIZE 8192 +/* Maximum number of overlapping requests */ +#define OVERLAPPING_REQUESTS 1 + +/* A read/write request */ +struct request { + u_int id; + u_int len; + u_int64_t offset; +}; /* Message ID */ static u_int msg_id = 1; @@ -215,6 +224,44 @@ return(a); } +static int +find_request(struct request *rq, int num, u_int id) +{ + int i; + + for (i = 0; i < num; ++i) { + if (rq[i].id == id) + break; + } + + if (i == num) + fatal("Request ID mismatch (%d)", id); + + return i; +} + +static void +remove_request(struct request *rq, int *num, int i) +{ + memmove(rq + i, rq + i + 1, (*num - i - 1) * sizeof(struct request)); + --*num; +} + +static void +send_request(int fd, const char *handle, u_int handle_len, int type, + const struct request *rq, Buffer *m) +{ + buffer_clear(m); + buffer_put_char(m, SSH2_FXP_READ); + buffer_put_int(m, rq->id); + buffer_put_string(m, handle, handle_len); + buffer_put_int64(m, rq->offset); + buffer_put_int(m, rq->len); + send_msg(fd, m); + debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", + rq->id, rq->offset, rq->len); +} + int do_init(int fd_in, int fd_out) { @@ -674,12 +721,15 @@ int pflag) { int local_fd; - u_int expected_id, handle_len, mode, type, id; + u_int handle_len, mode, type, id; u_int64_t offset; char *handle; Buffer msg; Attrib junk, *a; int status; + struct request req[OVERLAPPING_REQUESTS + 1]; + int num_req = 0, max_req = 1, reply; + int write_error = 0, read_error = 0, write_errno; a = do_stat(fd_in, fd_out, remote_path, 0); if (a == NULL) @@ -726,87 +776,103 @@ /* Read from remote and write to local */ offset = 0; - for(;;) { - u_int len; + while (num_req > 0 || max_req > 0) { char *data; + u_int len; - id = expected_id = msg_id++; - - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_READ); - buffer_put_int(&msg, id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_int(&msg, COPY_SIZE); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_READ I:%d O:%llu S:%u", - id, (u_int64_t)offset, COPY_SIZE); + /* Send some more requests */ + while (num_req < max_req) { + req[num_req].id = msg_id++; + req[num_req].len = COPY_SIZE; + req[num_req].offset = offset; + offset += req[num_req].len; + num_req++; + send_request(fd_out, handle, handle_len, SSH2_FXP_READ, + &req[num_req - 1], &msg); + } buffer_clear(&msg); - get_msg(fd_in, &msg); type = buffer_get_char(&msg); id = buffer_get_int(&msg); debug3("Received reply T:%d I:%d", type, id); - if (id != expected_id) - fatal("ID mismatch (%d != %d)", id, expected_id); - if (type == SSH2_FXP_STATUS) { + reply = find_request(req, num_req, id); + + switch (type) { + case SSH2_FXP_STATUS: status = buffer_get_int(&msg); + if (status != SSH2_FX_EOF) + read_error = 1; + max_req = 0; + remove_request(req, &num_req, reply); + break; + case SSH2_FXP_DATA: + data = buffer_get_string(&msg, &len); + if (len > req[reply].len) + fatal("Received more data than asked for " + "%d > %d", len, req[reply].len); + + debug3("In read loop, got %d offset %llu", + len, req[reply].offset); + if ((lseek(local_fd, req[reply].offset, SEEK_SET) == -1 || + atomicio(write, local_fd, data, len) != len) && + !write_error) { + write_errno = errno; + write_error = 1; + max_req = 0; + } + xfree(data); - if (status == SSH2_FX_EOF) - break; + if (len == req[reply].len) + remove_request(req, &num_req, reply); else { - error("Couldn't read from remote " - "file \"%s\" : %s", remote_path, - fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - goto done; + /* Resend the request for the missing data */ + req[reply].id = msg_id++; + req[reply].len -= len; + req[reply].offset += len; + send_request(fd_out, handle, handle_len, + SSH2_FXP_READ, &req[reply], &msg); } - } else if (type != SSH2_FXP_DATA) { + if (max_req > 0 && max_req < OVERLAPPING_REQUESTS + 1) + ++max_req; + break; + default: fatal("Expected SSH2_FXP_DATA(%d) packet, got %d", - SSH2_FXP_DATA, type); - } - - data = buffer_get_string(&msg, &len); - if (len > COPY_SIZE) - fatal("Received more data than asked for %d > %d", - len, COPY_SIZE); - - debug3("In read loop, got %d offset %llu", len, - (u_int64_t)offset); - if (atomicio(write, local_fd, data, len) != len) { - error("Couldn't write to \"%s\": %s", local_path, - strerror(errno)); - do_close(fd_in, fd_out, handle, handle_len); - status = -1; - xfree(data); - goto done; + SSH2_FXP_DATA, type); } - - offset += len; - xfree(data); } - status = do_close(fd_in, fd_out, handle, handle_len); - /* Override umask and utimes if asked */ + if (read_error) { + error("Couldn't read from remote " + "file \"%s\" : %s", remote_path, + fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + } else if (write_error) { + error("Couldn't write to \"%s\": %s", local_path, + strerror(write_errno)); + status = -1; + do_close(fd_in, fd_out, handle, handle_len); + } else { + status = do_close(fd_in, fd_out, handle, handle_len); + + /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD - if (pflag && fchmod(local_fd, mode) == -1) + if (pflag && fchmod(local_fd, mode) == -1) #else - if (pflag && chmod(local_path, mode) == -1) + if (pflag && chmod(local_path, mode) == -1) #endif /* HAVE_FCHMOD */ - error("Couldn't set mode on \"%s\": %s", local_path, - strerror(errno)); - if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { - struct timeval tv[2]; - tv[0].tv_sec = a->atime; - tv[1].tv_sec = a->mtime; - tv[0].tv_usec = tv[1].tv_usec = 0; - if (utimes(local_path, tv) == -1) - error("Can't set times on \"%s\": %s", local_path, - strerror(errno)); + error("Couldn't set mode on \"%s\": %s", local_path, + strerror(errno)); + if (pflag && (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME)) { + struct timeval tv[2]; + tv[0].tv_sec = a->atime; + tv[1].tv_sec = a->mtime; + tv[0].tv_usec = tv[1].tv_usec = 0; + if (utimes(local_path, tv) == -1) + error("Can't set times on \"%s\": %s", + local_path, strerror(errno)); + } } - -done: close(local_fd); buffer_free(&msg); xfree(handle); @@ -825,6 +891,8 @@ struct stat sb; Attrib a; int status; + u_int32_t startid; + u_int32_t ackid; if ((local_fd = open(local_path, O_RDONLY, 0)) == -1) { error("Couldn't open local file \"%s\" for reading: %s", @@ -866,6 +934,8 @@ return(-1); } + startid = ackid = id + 1; + /* Read from local and write to remote */ offset = 0; for(;;) { @@ -883,29 +953,34 @@ if (len == -1) fatal("Couldn't read from \"%s\": %s", local_path, strerror(errno)); - if (len == 0) - break; - buffer_clear(&msg); - buffer_put_char(&msg, SSH2_FXP_WRITE); - buffer_put_int(&msg, ++id); - buffer_put_string(&msg, handle, handle_len); - buffer_put_int64(&msg, offset); - buffer_put_string(&msg, data, len); - send_msg(fd_out, &msg); - debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", - id, (u_int64_t)offset, len); + if (len != 0) { + buffer_clear(&msg); + buffer_put_char(&msg, SSH2_FXP_WRITE); + buffer_put_int(&msg, ++id); + buffer_put_string(&msg, handle, handle_len); + buffer_put_int64(&msg, offset); + buffer_put_string(&msg, data, len); + send_msg(fd_out, &msg); + debug3("Sent message SSH2_FXP_WRITE I:%d O:%llu S:%u", + id, (u_int64_t)offset, len); + } else if ( id < ackid ) + break; - status = get_status(fd_in, id); - if (status != SSH2_FX_OK) { - error("Couldn't write to remote file \"%s\": %s", - remote_path, fx2txt(status)); - do_close(fd_in, fd_out, handle, handle_len); - close(local_fd); - goto done; + if (id == startid || len == 0 || + id - ackid >= OVERLAPPING_REQUESTS) { + status = get_status(fd_in, ackid); + if (status != SSH2_FX_OK) { + error("Couldn't write to remote file \"%s\": %s", + remote_path, fx2txt(status)); + do_close(fd_in, fd_out, handle, handle_len); + close(local_fd); + goto done; + } + debug3("In write loop, got %d offset %llu", len, + (u_int64_t)offset); + ++ackid; } - debug3("In write loop, got %d offset %llu", len, - (u_int64_t)offset); offset += len; } From sperber at informatik.uni-tuebingen.de Tue Jan 29 19:55:44 2002 From: sperber at informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) Date: Tue, 29 Jan 2002 09:55:44 +0100 Subject: OpenSSH 3.0.2p1 vs kth-krb4 Message-ID: An embedded message was scrubbed... From: Richard Levitte - VMS Whacker Subject: Re: OpenSSH w/ kth-krb4 on AIX Date: Tue, 29 Jan 2002 09:36:09 +0100 (MET) Size: 3059 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020129/5f0a8b02/attachment.mht -------------- next part -------------- -- Cheers =8-} Mike Friede, V?lkerverst?ndigung und ?berhaupt blabla From rv at openusenet.org Tue Jan 29 22:06:49 2002 From: rv at openusenet.org (Russell Vincent) Date: Tue, 29 Jan 2002 11:06:49 +0000 Subject: Clusters and /etc/nologin Message-ID: <20020129110649.GB57760@riffraff.plig.net> On Tru64 clusters, a single machine can be marked for nologin by creating /etc/nologin_HOSTNAME. The attached patch does a check for this file if /etc/nologin is not found and treats it the same as /etc/nologin (or wherever nologin happens to be). Not sure if you wants this within a #ifdef. -Russell diff -cr openssh-3.0.2p1/session.c openssh/session.c *** openssh-3.0.2p1/session.c Sat Dec 1 23:37:08 2001 --- openssh/session.c Tue Jan 29 10:18:54 2002 *************** *** 1068,1073 **** --- 1068,1084 ---- # else /* HAVE_LOGIN_CAP */ if (pw->pw_uid) f = fopen(_PATH_NOLOGIN, "r"); + if ((f = fopen(_PATH_NOLOGIN, "r")) == NULL) { + char hname[MAXHOSTNAMELEN]; + if (gethostname(hname, MAXHOSTNAMELEN) == 0) { + char nologinpath[PATH_MAX]; + snprintf(nologinpath, PATH_MAX, "%s_%s", + _PATH_NOLOGIN, hname); + f = fopen(nologinpath, "r"); + } else + f = NULL; + + } # endif /* HAVE_LOGIN_CAP */ if (f) { /* /etc/nologin exists. Print its contents and exit. */ From Alexander.Dost at drkw.com Tue Jan 29 22:56:55 2002 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Tue, 29 Jan 2002 12:56:55 +0100 Subject: locked account accessable via pubkey auth Message-ID: maybe this is a silly question ;-) But why is it possible to login on a machine with a locked account (passwd -l ) via pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not happen. If this is the normal behaviour and built in intentionally what would be the easiest way to lock an account without deleting the users authorized_keys ? If not, what output do you need to verify the problem ? Alex From djm at mindrot.org Tue Jan 29 23:15:48 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Jan 2002 23:15:48 +1100 (EST) Subject: locked account accessable via pubkey auth In-Reply-To: Message-ID: On Tue, 29 Jan 2002, Dost, Alexander wrote: > maybe this is a silly question ;-) But why is it possible to > login on a machine with a locked account (passwd -l ) via > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > Solaris8 with PAM support so I thought this should not happen. > > If this is the normal behaviour and built in intentionally what > would be the easiest way to lock an account without deleting the > users authorized_keys ? If not, what output do you need to verify > the problem ? "locking" an account is really locking the password, since you are not using password authentication this is ignored. A way that should work is to mark the account as expired, or just rename the ~/.ssh/authorized_keys file -d From Alexander.Dost at drkw.com Tue Jan 29 23:28:07 2002 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Tue, 29 Jan 2002 13:28:07 +0100 Subject: locked account accessable via pubkey auth Message-ID: Thanks for the answer. Funny solution to my problem now is: do a passwd -l and -f so the account is expired and locked. When logging in, the user is asked to change the password (as password auth is enabled also) and entering the old login pw fails :-) Dirty but working. I agree that changing the authorized_keys file is a better way. Thanks for the help. Alex > -----Original Message----- > From: Damien Miller [SMTP:djm at mindrot.org] > Sent: Tuesday, January 29, 2002 13:16 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > On Tue, 29 Jan 2002, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to > > login on a machine with a locked account (passwd -l ) via > > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > > Solaris8 with PAM support so I thought this should not happen. > > > > If this is the normal behaviour and built in intentionally what > > would be the easiest way to lock an account without deleting the > > users authorized_keys ? If not, what output do you need to verify > > the problem ? > > "locking" an account is really locking the password, since you > are not using password authentication this is ignored. > > A way that should work is to mark the account as expired, or > just rename the ~/.ssh/authorized_keys file > > -d If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. From Jason.Lacoss-Arnold at AGEDWARDS.com Tue Jan 29 23:37:09 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Tue, 29 Jan 2002 06:37:09 -0600 Subject: locked account accessable via pubkey auth Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4DC@hqempn06.agedwards.com> What we're doing is adding the users to a special group called "disabled" and we have "DenyGroups disabled" directive in our sshd_config file. Since we're rolling out an account provisioning tool, we can customized it to add the user to that group when they're disabled. Alternatively, it could be done manually by policies/procedures, but I don't trust our operations folk to get it right. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dost, Alexander [mailto:Alexander.Dost at drkw.com] Sent: Tuesday, January 29, 2002 6:28 To: 'Damien Miller' Cc: openssh-unix-dev at mindrot.org Subject: RE: locked account accessable via pubkey auth Thanks for the answer. Funny solution to my problem now is: do a passwd -l and -f so the account is expired and locked. When logging in, the user is asked to change the password (as password auth is enabled also) and entering the old login pw fails :-) Dirty but working. I agree that changing the authorized_keys file is a better way. Thanks for the help. Alex > -----Original Message----- > From: Damien Miller [SMTP:djm at mindrot.org] > Sent: Tuesday, January 29, 2002 13:16 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > On Tue, 29 Jan 2002, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to > > login on a machine with a locked account (passwd -l ) via > > pubkey-authentication (authorized_keys) ? I use OpenSSH3.01p1on > > Solaris8 with PAM support so I thought this should not happen. > > > > If this is the normal behaviour and built in intentionally what > > would be the easiest way to lock an account without deleting the > > users authorized_keys ? If not, what output do you need to verify > > the problem ? > > "locking" an account is really locking the password, since you > are not using password authentication this is ignored. > > A way that should work is to mark the account as expired, or > just rename the ~/.ssh/authorized_keys file > > -d If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020129/35ead2cb/attachment.html From bugzilla-daemon at mindrot.org Tue Jan 29 23:47:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 29 Jan 2002 23:47:28 +1100 (EST) Subject: [Bug 83] New: fork() fails when there are PAM limits set Message-ID: <20020129124728.9B200EA54@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 Summary: fork() fails when there are PAM limits set Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vasil at dobrich.net Background: debian woody, kernel 2.4.17 The problem is, when you set some resource limits in /etc/security/limits.conf for group X - nproc 20 ( maximum of running user processes - 20 ), and try to log with some user with group X, sshd says 'fork failed - resource temporary unavialable'. There are no other processes running for this user, and as far as i've seen, it makes something like authenticate-set limits-fork()-setuid() , and because there is a moment when it's running under root with really lowered limits, it bombs out. Any solutions? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From matthew at debian.org Wed Jan 30 00:43:36 2002 From: matthew at debian.org (Matthew Vernon) Date: 29 Jan 2002 13:43:36 +0000 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: mouring's message of Mon, 28 Jan 2002 17:37:04 GMT References: <20020128163623.GI23607@wiggy.net> <200201281645.g0SGjWhk026516@etoh.eviladmin.org> Message-ID: <5bg04puvav.fsf@chiark.greenend.org.uk> mouring writes: > BTW.. I don't see -1/-2 request. Well, that's because Debian's scp supports -1 and -2 (it's a 2-line patch, IIRC). There are also quite a few other patches, which I must admit I've rather slowed down on sending upstream, since there seems to be no desire on the openssh team's part to consider including them. > BTW2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=51955&repeatmerged=yes > was fixed. You can take it off your wishlist. Noted, thanks. Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From Nicolas.Williams at ubsw.com Wed Jan 30 01:10:45 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 09:10:45 -0500 Subject: GSS/krb5 patches (was Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1) In-Reply-To: ; from djm@mindrot.org on Tue, Jan 29, 2002 at 04:34:04PM +1100 References: <20020128131842.I27398@sm2p1386swk.wdr.com> Message-ID: <20020129091043.P27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 04:34:04PM +1100, Damien Miller wrote: > On Mon, 28 Jan 2002, Nicolas Williams wrote: > > > Will useful patches posted to this list receive any consideration for > > inclusion in future releases of OpenSSH? > > > > The most important contributed patch, right now, from my point of view, > > is Simon Wilkinson's GSS-API userauth/external key exchange patch. > > > > Will that be included? > > I'd like to see the KrbV integration patch included in portable, but I am > yet to receive an independant review of it from someone who understands > the Kerberos V API properly. I don't know it well enough to feel > comfortable commiting it by myself - this is no reflection on Simon, just > my own paranoia. I'm using it. I've done minimal testing with Heimdal (compiles, links, the client works) and I'm using it with MIT krb5. Besides empirical evidence to Simon's MIT compat patch's stability and correctness I'm willing to put together a description of what it does and why it does it (i.e., what are the key Heimdal/MIT krb5 API differences). Is there anything else that you need to help any review of Simon's MIT krb5 compat patch? > IIRC the GSS-API patch was awaiting revision to match the drafts. Simon has posted the -02 draft version of his patch. The -03 of the gsskeyex draft does not make any changes to the on-the-wire protocol except for the addition of optional SSH_MSG_KEXGSS_ERROR (MAY) and SSH_MSG_USERAUTH_GSSAPI_ERROR (SHOULD) messages. So Simon's patch is compatible with the -02 and -03 versions of the gsskeyex draft. Again, I'm willing to help you review Simon's gsskeyex patches. Let me know how I can help. Also, I have developed a local patch for gsskeyex-01 backwards compatibility. I do not pretend that you assimilate this one though as you hadn't assimilated Simon's gsskeyex-01 patch for OpenSSH 2.9p2. Others may find it useful however. > -d Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From WhitakerK at MTMC.ARMY.MIL Wed Jan 30 01:29:15 2002 From: WhitakerK at MTMC.ARMY.MIL (Whitaker, Kenneth) Date: Tue, 29 Jan 2002 09:29:15 -0500 Subject: Issues with SFTP Message-ID: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> Things consider problems with sftp software - sftp manually first time to accept the fingerprint and anytime software is updated on host. - no ascii mode only binary - no verbose or indication of bytes transfered (you would do an ls after sftp is done) - no mput or mget (this may be a show stopper) but could script could generate itself with all the filenames takes coding. Kenneth Whitaker WhitakerK at mtmc.army.mil Information Systems Management Specialist 200 Stovall Street, RM 8N53-28 Alexandria VA 22332-5000 703.428.2512 Phone 703.428.3329 Fax 703.901.0277 Cell Phone 7039010277 at mobile.mycingular.com Beeper www.cingular.com - click digital messaging Services From ed at UDel.Edu Wed Jan 30 01:40:55 2002 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 29 Jan 2002 09:40:55 -0500 (EST) Subject: X.509 for verifying host keys Message-ID: Is anyone working on a patch for this feature? I don't remember seeing anyone say whether they were actually going to try to implement it in the current OpenSSH code... Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From lemming at netcentrum.cz Wed Jan 30 01:40:54 2002 From: lemming at netcentrum.cz (Michal Kara) Date: Tue, 29 Jan 2002 15:40:54 +0100 Subject: Key fingerprint logging Message-ID: <20020129154054.A20373@netcentrum.cz> Hello there! I have made a patch against OpenSSH 3.0.2p1 which allows the fingerprint of the accepted key to be printed in the log message. It works with SSH1-RSA and SSH2 pubkey (DSA+RSA) authentication. This feature is controllable by the LogKeyFingerprint config option (turned off by default). Michal Kara -------------- next part -------------- diff -u5 openssh-3.0.2p1.orig/auth-rsa.c openssh-3.0.2p1/auth-rsa.c --- openssh-3.0.2p1.orig/auth-rsa.c Mon Aug 6 23:01:49 2001 +++ openssh-3.0.2p1/auth-rsa.c Tue Jan 29 14:26:34 2002 @@ -118,11 +118,11 @@ * 0 if the client could not be authenticated, and 1 if authentication was * successful. This may exit if there is a serious protocol violation. */ int -auth_rsa(struct passwd *pw, BIGNUM *client_n) +auth_rsa(struct passwd *pw, BIGNUM *client_n, char *info, int info_size) { char line[8192], *file; int authenticated; u_int bits; FILE *f; @@ -179,11 +179,11 @@ * found, perform a challenge-response dialog to verify that the * user really has the corresponding private key. */ while (fgets(line, sizeof(line), f)) { char *cp; - char *options; + char *key_options; linenum++; /* Skip leading whitespace, empty and comment lines. */ for (cp = line; *cp == ' ' || *cp == '\t'; cp++) @@ -197,19 +197,19 @@ * for now. If there are no options, set the starting * address to NULL. */ if (*cp < '0' || *cp > '9') { int quoted = 0; - options = cp; + key_options = cp; for (; *cp && (quoted || (*cp != ' ' && *cp != '\t')); cp++) { if (*cp == '\\' && cp[1] == '"') cp++; /* Skip both */ else if (*cp == '"') quoted = !quoted; } } else - options = NULL; + key_options = NULL; /* Parse the key from the line. */ if (!auth_rsa_read_key(&cp, &bits, pk->e, pk->n)) { debug("%.100s, line %lu: non ssh1 key syntax", file, linenum); @@ -230,11 +230,11 @@ /* We have found the desired key. */ /* * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (!auth_parse_options(pw, key_options, file, linenum)) continue; /* Perform the challenge-response dialog for this key. */ if (!auth_rsa_challenge_dialog(pk)) { /* Wrong response. */ @@ -249,10 +249,19 @@ * authentication to be rejected. * Break out of the loop if authentication was successful; * otherwise continue searching. */ authenticated = 1; + + if (options.log_key_fingerprint == 1) { + Key *k = key_new(KEY_RSA); + RSA *old_rsa = k->rsa; + k->rsa = pk; + snprintf(info,info_size," fp %s",key_fingerprint(k,SSH_FP_MD5,SSH_FP_HEX)); + k->rsa = old_rsa; + key_free(k); + } break; } /* Restore the privileged uid. */ restore_uid(); diff -u5 openssh-3.0.2p1.orig/auth.h openssh-3.0.2p1/auth.h --- openssh-3.0.2p1.orig/auth.h Wed Jul 4 06:46:57 2001 +++ openssh-3.0.2p1/auth.h Tue Jan 29 13:45:29 2002 @@ -91,11 +91,11 @@ int auth_rhosts2(struct passwd *, const char *, const char *, const char *); int auth_rhosts_rsa(struct passwd *, const char *, RSA *); int auth_password(Authctxt *, const char *); -int auth_rsa(struct passwd *, BIGNUM *); +int auth_rsa(struct passwd *, BIGNUM *, char *, int); int auth_rsa_read_key(char **, u_int *, BIGNUM *, BIGNUM *); int auth_rsa_challenge_dialog(RSA *); #ifdef KRB4 #include diff -u5 openssh-3.0.2p1.orig/auth1.c openssh-3.0.2p1/auth1.c --- openssh-3.0.2p1.orig/auth1.c Tue Nov 13 13:46:19 2001 +++ openssh-3.0.2p1/auth1.c Tue Jan 29 13:40:20 2002 @@ -231,11 +231,11 @@ } /* RSA authentication requested. */ n = BN_new(); packet_get_bignum(n, &nlen); packet_integrity_check(plen, nlen, type); - authenticated = auth_rsa(pw, n); + authenticated = auth_rsa(pw, n, info, sizeof(info)); BN_clear_free(n); break; case SSH_CMSG_AUTH_PASSWORD: if (!options.password_authentication) { diff -u5 openssh-3.0.2p1.orig/auth2.c openssh-3.0.2p1/auth2.c --- openssh-3.0.2p1.orig/auth2.c Tue Nov 13 13:46:19 2001 +++ openssh-3.0.2p1/auth2.c Tue Jan 29 15:21:58 2002 @@ -58,10 +58,14 @@ extern int session_id2_len; static Authctxt *x_authctxt = NULL; static int one = 1; +static char real_info[1024] = " ssh2"; +static char *info = real_info + 5; +static int info_size = sizeof(real_info)-5; + typedef struct Authmethod Authmethod; struct Authmethod { char *name; int (*userauth)(Authctxt *authctxt); int *enabled; @@ -261,11 +265,11 @@ NULL)) authenticated = 0; #endif /* USE_PAM */ /* Log before sending the reply */ - auth_log(authctxt, authenticated, method, " ssh2"); + auth_log(authctxt, authenticated, method, real_info); if (authctxt->postponed) return; /* XXX todo: check if multiple auth methods are needed */ @@ -475,12 +479,16 @@ #ifdef DEBUG_PK buffer_dump(&b); #endif /* test for correct signature */ if (user_key_allowed(authctxt->pw, key) && - key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) + key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) { authenticated = 1; + + if (options.log_key_fingerprint == 1) + snprintf(info,info_size," fp %s",key_fingerprint(key,SSH_FP_MD5,SSH_FP_HEX)); + } buffer_clear(&b); xfree(sig); } else { debug("test whether pkalg/pkblob are acceptable"); packet_done(); diff -u5 openssh-3.0.2p1.orig/servconf.c openssh-3.0.2p1/servconf.c --- openssh-3.0.2p1.orig/servconf.c Tue Nov 13 14:03:15 2001 +++ openssh-3.0.2p1/servconf.c Tue Jan 29 14:23:41 2002 @@ -107,10 +107,11 @@ options->reverse_mapping_check = -1; options->client_alive_interval = -1; options->client_alive_count_max = -1; options->authorized_keys_file = NULL; options->authorized_keys_file2 = NULL; + options->log_key_fingerprint = -1; } void fill_default_server_options(ServerOptions *options) { @@ -227,10 +228,12 @@ else options->authorized_keys_file2 = _PATH_SSH_USER_PERMITTED_KEYS2; } if (options->authorized_keys_file == NULL) options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; + if (options->log_key_fingerprint == -1) + options->log_key_fingerprint = 0; } /* Keyword tokens. */ typedef enum { sBadOption, /* == unknown option */ @@ -259,11 +262,11 @@ sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, sBanner, sReverseMappingCheck, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, - sDeprecated + sDeprecated, sLogKeyFingerprint } ServerOpCodes; /* Textual representation of the tokens. */ static struct { const char *name; @@ -332,10 +335,11 @@ { "reversemappingcheck", sReverseMappingCheck }, { "clientaliveinterval", sClientAliveInterval }, { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "logkeyfingerprint", sLogKeyFingerprint }, { NULL, 0 } }; /* * Returns the number of the token pointed to by cp or sBadOption. @@ -863,10 +867,14 @@ log("%s line %d: Deprecated option %s", filename, linenum, arg); while(arg) arg = strdelim(&cp); break; + + case sLogKeyFingerprint: + intptr = &options->log_key_fingerprint; + goto parse_flag; default: fatal("%s line %d: Missing handler for opcode %s (%d)", filename, linenum, arg, opcode); } diff -u5 openssh-3.0.2p1.orig/servconf.h openssh-3.0.2p1/servconf.h --- openssh-3.0.2p1.orig/servconf.h Wed Sep 12 18:40:06 2001 +++ openssh-3.0.2p1/servconf.h Tue Jan 29 15:19:29 2002 @@ -128,10 +128,12 @@ char *authorized_keys_file; /* File containing public keys */ char *authorized_keys_file2; int pam_authentication_via_kbd_int; + int log_key_fingerprint; + } ServerOptions; void initialize_server_options(ServerOptions *); void read_server_config(ServerOptions *, const char *); void fill_default_server_options(ServerOptions *); diff -u5 openssh-3.0.2p1.orig/sshd.8 openssh-3.0.2p1/sshd.8 --- openssh-3.0.2p1.orig/sshd.8 Sun Dec 2 00:37:08 2001 +++ openssh-3.0.2p1/sshd.8 Tue Jan 29 15:12:08 2002 @@ -606,10 +606,15 @@ .It Cm LoginGraceTime The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 600 (seconds). +.It Cm LogKeyFingerprint +Specifies whether to log key fingerprint after successful +publickey authentication. +The default is +.Dq no . .It Cm LogLevel Gives the verbosity level that is used when logging messages from .Nm sshd . The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE and DEBUG. From openssh-unix-dev at thewrittenword.com Wed Jan 30 01:48:51 2002 From: openssh-unix-dev at thewrittenword.com (Albert Chin) Date: Tue, 29 Jan 2002 08:48:51 -0600 Subject: locked account accessable via pubkey auth In-Reply-To: ; from Alexander.Dost@drkw.com on Tue, Jan 29, 2002 at 12:56:55PM +0100 References: Message-ID: <20020129084851.A67094@oolong.il.thewrittenword.com> On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > maybe this is a silly question ;-) But why is it possible to login on a > machine with a locked account (passwd -l ) via pubkey-authentication > (authorized_keys) ? > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > happen. Check the list archives and you'll find others with the same problem. Noone has turned up a solution with Solaris 8/PAM yet. -- albert chin (china at thewrittenword.com) From markus at openbsd.org Wed Jan 30 01:51:58 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 15:51:58 +0100 Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> Message-ID: <20020129145158.GA27578@faui02> > Things consider problems with sftp software > > - sftp manually first time to accept the fingerprint and anytime software > is updated on host. this is a problem with your setup. don't blame sftp. > - no ascii mode only binary what is "ascii" ? > - no verbose or indication of bytes transfered (you would do an ls after > sftp is done) sftp is a unix tool, so it usually cries only on errors. > - no mput or mget (this may be a show stopper) but could script could > generate itself with all the filenames takes coding. use get * or put * -m From WhitakerK at MTMC.ARMY.MIL Wed Jan 30 01:56:27 2002 From: WhitakerK at MTMC.ARMY.MIL (Whitaker, Kenneth) Date: Tue, 29 Jan 2002 09:56:27 -0500 Subject: Issues with SFTP Message-ID: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> Hey, Thanks for the fast response. ascii Set the "representation type" to "network ASCII". binary Set the "representation type" to "image". verbose Toggle verbose mode. In verbose mode, all responses from the FTP server are displayed to the user. In addition, if verbose mode is on, when a file transfer completes, statistics regarding the efficiency of the transfer are reported. By default, verbose mode is on if ftp 's commands are coming from a terminal, and off otherwise. -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Tuesday, January 29, 2002 9:52 AM To: Whitaker, Kenneth Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Issues with SFTP > Things consider problems with sftp software > > - sftp manually first time to accept the fingerprint and anytime software > is updated on host. this is a problem with your setup. don't blame sftp. > - no ascii mode only binary what is "ascii" ? > - no verbose or indication of bytes transfered (you would do an ls after > sftp is done) sftp is a unix tool, so it usually cries only on errors. > - no mput or mget (this may be a show stopper) but could script could > generate itself with all the filenames takes coding. use get * or put * -m From markus at openbsd.org Wed Jan 30 02:03:40 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 16:03:40 +0100 Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> Message-ID: <20020129150340.GB27578@faui02> On Tue, Jan 29, 2002 at 09:56:27AM -0500, Whitaker, Kenneth wrote: > ascii Set the "representation type" to "network ASCII". > binary Set the "representation type" to "image". but the concept of 'ascii' is unknown to the sftp client, the server and the protocol. despite it's make sftp has nothing in common with ftp. > verbose Toggle verbose mode. In verbose mode, all > responses from the FTP server are displayed to the > user. In addition, if verbose mode is on, when a > file transfer completes, statistics regarding the > efficiency of the transfer are reported. By > default, verbose mode is on if ftp 's commands are > coming from a terminal, and off otherwise. someone could steal code from scp and implement this. From Nicolas.Williams at ubsw.com Wed Jan 30 02:01:08 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 10:01:08 -0500 Subject: X.509 for verifying host keys In-Reply-To: ; from ed@UDel.Edu on Tue, Jan 29, 2002 at 09:40:55AM -0500 References: Message-ID: <20020129100106.L27398@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 09:40:55AM -0500, Ed Phillips wrote: > Is anyone working on a patch for this feature? I don't remember seeing > anyone say whether they were actually going to try to implement it in the > current OpenSSH code... Careful... It sounds like you're volunteering... :) > Thanks, > > Ed > Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From wichert at wiggy.net Wed Jan 30 02:21:01 2002 From: wichert at wiggy.net (Wichert Akkerman) Date: Tue, 29 Jan 2002 16:21:01 +0100 Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> Message-ID: <20020129152101.GO23607@wiggy.net> Previously Whitaker, Kenneth wrote: > ascii Set the "representation type" to "network ASCII". > > binary Set the "representation type" to "image". There is no such thing as `network ASCII'. sftp is a tool to get a file from one machine to another securely without changing it. If you want to do crlf/cr conversion please use a seperate tool to do that. Wichert. -- _________________________________________________________________ /wichert at wiggy.net This space intentionally left occupied \ | wichert at deephackmode.org http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From Nicolas.Williams at ubsw.com Wed Jan 30 02:22:00 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 10:22:00 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from tori@ringstrom.mine.nu on Tue, Jan 29, 2002 at 09:29:37AM +0100 References: <200201290155.g0T1tiP4011971@etoh.eviladmin.org> Message-ID: <20020129102159.M27398@sm2p1386swk.wdr.com> What is the current consensus? Here's what I see so far: - non-SSH sockets: turn on TCP_NODELAY (all agree) - SSH connections, short term: - turn on TCP_NODELAY for interactive sessions (Markus; current state) - turn on TCP_NODELAY for all sessions (Tobias) - turn on TCP_NODELAY for all sessions that have active port or display forwarding or which are not exec sessions (myself) - SSHv2 connections, longer-term: - add a per-channel TCP_NODELAY channel request (Markus; I second) - add a per-channel Nagle at the SSHv2 layer (myself, but not convinced) Something is needed to make X11 display forwarding a happy thing and improve SFTP performance. The latter can probably be done by coallescing the write()s of those two packets that trigger Nagle. The former can be a trivial heuristic. All other TCP port forwarding should really be done without Nagle as well. What is a reasonable short-term consensus on when SSHv2 connections should have TCP_NODELAY set on both sides? Nico On Tue, Jan 29, 2002 at 09:29:37AM +0100, Tobias Ringstrom wrote: [...] > First of all, we only need more than one overlapping request if the > delay-bandwidth product of the link is larger than the block size. I do > not have any figures for a wide number of links. The reason why I thought > I needed more was the interaction with the Nagle algorithm. The Nagle > problem is orthogonal, but needs to be resolved. It seems to be very hard > to agree on a solution, though. [...] > Please reconsider the patch in light of the nodelay findings. (And if you > do benchmark it, please use TCP_NODELAY in both ends.) > > /Tobias -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Jason.Lacoss-Arnold at AGEDWARDS.com Wed Jan 30 02:27:15 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Tue, 29 Jan 2002 09:27:15 -0600 Subject: Issues with SFTP Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> It would be good to also have "hash" display progress as many ftp users consider it to be core functionality. Setting mget and mput as aliases to get and put would also ease confusion. Basically, if you're going to steal the semantics of ftp, please do it as fully as possible. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Tuesday, January 29, 2002 9:04 To: Whitaker, Kenneth Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Issues with SFTP On Tue, Jan 29, 2002 at 09:56:27AM -0500, Whitaker, Kenneth wrote: > ascii Set the "representation type" to "network ASCII". > binary Set the "representation type" to "image". but the concept of 'ascii' is unknown to the sftp client, the server and the protocol. despite it's make sftp has nothing in common with ftp. > verbose Toggle verbose mode. In verbose mode, all > responses from the FTP server are displayed to the > user. In addition, if verbose mode is on, when a > file transfer completes, statistics regarding the > efficiency of the transfer are reported. By > default, verbose mode is on if ftp 's commands are > coming from a terminal, and off otherwise. someone could steal code from scp and implement this. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020129/5ee5c36b/attachment.html From tori at ringstrom.mine.nu Wed Jan 30 02:39:43 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 16:39:43 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020129102159.M27398@sm2p1386swk.wdr.com> Message-ID: On Tue, 29 Jan 2002, Nicolas Williams wrote: > What is the current consensus? > > Here's what I see so far: > > - non-SSH sockets: turn on TCP_NODELAY (all agree) > > - SSH connections, short term: > > - turn on TCP_NODELAY for interactive sessions (Markus; current state) Which goes against all logic and theory, right? :-) > - turn on TCP_NODELAY for all sessions (Tobias) As a short time solution, yes. An option to turn Nagle back on for pty sessions (with no forwarding) would be nice. > - turn on TCP_NODELAY for all sessions that have active port or > display forwarding or which are not exec sessions (myself) If we can agree that Nagle should be on for pty sessions, it should be on iff the current ssh connection only contains pty sessions, i.e. no port forwarding channels, no sftp, no x11, etc. > - SSHv2 connections, longer-term: > > - add a per-channel TCP_NODELAY channel request (Markus; I second) This is very nice, but can we do this without breaking the (draft) RFC? Can it be done compatibly with older versions? > - add a per-channel Nagle at the SSHv2 layer (myself, but not convinced) I'm convinced that this cannot be Nagle-like, since the Nagle algorithm i needs to know whether there is any outstanding data on the connection. > Something is needed to make X11 display forwarding a happy thing and > improve SFTP performance. X11 already uses TCP_NODELAY, so that's not a problem. > The latter can probably be done by coallescing the write()s of those two > packets that trigger Nagle. That requires delaying the window adjustment packet until we have another packet to send, and to send them together. A timeout is also needed, but the real problem is that this breaks down (I think) when we have overlapping requests, which I really hope we will have real soon. In other words, sftp wants TCP_NODELAY. > The former can be a trivial heuristic. All other TCP port forwarding > should really be done without Nagle as well. > > What is a reasonable short-term consensus on when SSHv2 connections > should have TCP_NODELAY set on both sides? This is what I'd like to know as well... /Tobias From tori at ringstrom.mine.nu Wed Jan 30 02:42:43 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 16:42:43 +0100 (CET) Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> Message-ID: On Tue, 29 Jan 2002, Whitaker, Kenneth wrote: > > - no verbose or indication of bytes transfered (you would do an ls after > > sftp is done) > > sftp is a unix tool, so it usually cries only on errors. Still, a ncsftp (c.f. ncftp) tool would be nice, but it would probably be a separate package. /Tobias From markus at openbsd.org Wed Jan 30 02:43:03 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 16:43:03 +0100 Subject: Issues with SFTP In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> Message-ID: <20020129154303.GC27578@faui02> On Tue, Jan 29, 2002 at 09:27:15AM -0600, Lacoss-Arnold, Jason wrote: > It would be good to also have "hash" display progress as many ftp users > consider it to be core functionality. Setting mget and mput as aliases to > get and put would also ease confusion. Basically, if you're going to steal > the semantics of ftp, please do it as fully as possible. you cannot 100%. it's different. sftp avoids ftp's broken-ness. From markus at openbsd.org Wed Jan 30 02:44:12 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 16:44:12 +0100 Subject: Issues with SFTP In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> Message-ID: <20020129154412.GD27578@faui02> On Tue, Jan 29, 2002 at 09:27:15AM -0600, Lacoss-Arnold, Jason wrote: > It would be good to also have "hash" display progress as many ftp users > consider it to be core functionality. Setting mget and mput as aliases to > get and put would also ease confusion. Basically, if you're going to steal > the semantics of ftp, please do it as fully as possible. i don't consider "hash" core functionality. the only missing feature is "qui". -m From markus at openbsd.org Wed Jan 30 02:46:32 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 16:46:32 +0100 Subject: X.509 for verifying host keys In-Reply-To: References: Message-ID: <20020129154632.GE27578@faui02> On Tue, Jan 29, 2002 at 09:40:55AM -0500, Ed Phillips wrote: > Is anyone working on a patch for this feature? I don't remember seeing > anyone say whether they were actually going to try to implement it in the > current OpenSSH code... feel free. i might look into this. timeframe < 1 year. From jhawk at MIT.EDU Wed Jan 30 02:52:33 2002 From: jhawk at MIT.EDU (John Hawkinson) Date: Tue, 29 Jan 2002 10:52:33 -0500 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: References: <20020128131842.I27398@sm2p1386swk.wdr.com> Message-ID: <20020129155233.GB3585@multics.mit.edu> Damien Miller wrote on Tue, 29 Jan 2002 at 16:34:04 +1100 in : > I'd like to see the KrbV integration patch included in portable, but I am > yet to receive an independant review of it from someone who understands > the Kerberos V API properly. I don't know it well enough to feel > comfortable commiting it by myself - this is no reflection on Simon, just > my own paranoia. Is that what it's waiting for? I will grab a bunch of people together over here and make sure that we review it adequately and get back to you within the week. --jhawk (who will then subsequently submit his ssh.com krb5 v1 compat patches) From dan at doxpara.com Wed Jan 30 03:07:07 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 29 Jan 2002 08:07:07 -0800 Subject: X.509 for verifying host keys References: <20020129100106.L27398@sm2p1386swk.wdr.com> Message-ID: <04f101c1a8df$00293b00$1701000a@effugas> > > Is anyone working on a patch for this feature? I don't remember seeing > > anyone say whether they were actually going to try to implement it in the > > current OpenSSH code... > > Careful... It sounds like you're volunteering... :) Anyone actually working on this privately, email me. I'm honestly thinking of just supporting PEM files outright, though not abandoning the perfect forward secrecy of SSH. --Dan From sturle.sunde at usit.uio.no Wed Jan 30 03:01:42 2002 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 29 Jan 2002 17:01:42 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020128112648.GA17992@faui02> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> <20020128112648.GA17992@faui02> Message-ID: Markus Friedl writes: > On Mon, Jan 28, 2002 at 11:55:03AM +0100, Wichert Akkerman wrote: >> Previously Markus Friedl wrote: >>> why do you need -1 and -2? >> Users want it, and it's very useful in situations where you need >> to specifiy the version due to existing keys, old servers, etc. > hm, should there be an extra option for 0.0001% of all > use cases. It's usualy far more than that, since you have other authentication options availiable for SSH-1. And particularly for scp I like to use SSH-1 on fast local networks, since its's secure enough for most purposes, and much faster than SSH-2. -- Sturle ~~~~~~ From stevesk at pobox.com Wed Jan 30 03:01:07 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 29 Jan 2002 08:01:07 -0800 (PST) Subject: locked account accessable via pubkey auth In-Reply-To: Message-ID: On Tue, 29 Jan 2002, Dost, Alexander wrote: :maybe this is a silly question ;-) But why is it possible to login on a :machine with a locked account (passwd -l ) via pubkey-authentication :(authorized_keys) ? :I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not :happen. what does rlogind do under the same conditions with host equivalency configured? :If this is the normal behaviour and built in intentionally what would be the :easiest way to lock an account without deleting the users authorized_keys ? :If not, what output do you need to verify the problem ? in the PAM case, PAM decides, via pam_acct_mgmt(). if i do ``passwd -l user'' on HP-UX i see: Jan 29 07:34:26 jenny sshd[2601]: PAM rejected by account configuration[28]: Account is disabled - see Account Administrator From WhitakerK at MTMC.ARMY.MIL Wed Jan 30 03:08:07 2002 From: WhitakerK at MTMC.ARMY.MIL (Whitaker, Kenneth) Date: Tue, 29 Jan 2002 11:08:07 -0500 Subject: Issues with SFTP Message-ID: <7933C6521AA7D211A41A0000D11BAFBF0713AF63@hq11.army.mil> Can verbose become implemented in the next version ? The "get *" works ok but need this part to be more useful. prompt Toggle interactive prompting. Interactive prompt- ing occurs during multiple file transfers to allow the user to selectively retrieve or store files. By default, prompting is turned on. If prompting is turned off, any mget or mput will transfer all files, and any mdelete will delete all files. The ascii is only issue with DOS files anyway. -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Tuesday, January 29, 2002 10:04 AM To: Whitaker, Kenneth Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Issues with SFTP On Tue, Jan 29, 2002 at 09:56:27AM -0500, Whitaker, Kenneth wrote: > ascii Set the "representation type" to "network ASCII". > binary Set the "representation type" to "image". but the concept of 'ascii' is unknown to the sftp client, the server and the protocol. despite it's make sftp has nothing in common with ftp. > verbose Toggle verbose mode. In verbose mode, all > responses from the FTP server are displayed to the > user. In addition, if verbose mode is on, when a > file transfer completes, statistics regarding the > efficiency of the transfer are reported. By > default, verbose mode is on if ftp 's commands are > coming from a terminal, and off otherwise. someone could steal code from scp and implement this. From Nicolas.Williams at ubsw.com Wed Jan 30 03:08:19 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 11:08:19 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from tori@ringstrom.mine.nu on Tue, Jan 29, 2002 at 04:39:43PM +0100 References: <20020129102159.M27398@sm2p1386swk.wdr.com> Message-ID: <20020129110818.S27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 04:39:43PM +0100, Tobias Ringstrom wrote: > On Tue, 29 Jan 2002, Nicolas Williams wrote: > > > What is the current consensus? > > > > Here's what I see so far: > > > > - non-SSH sockets: turn on TCP_NODELAY (all agree) > > > > - SSH connections, short term: > > > > - turn on TCP_NODELAY for interactive sessions (Markus; current state) > > Which goes against all logic and theory, right? :-) Yes. But the problem probably is that the old Nagle algorithm and TCP congestion control in general probably needs revision to really work in newer networks. > > - turn on TCP_NODELAY for all sessions (Tobias) > > As a short time solution, yes. An option to turn Nagle back on for > pty sessions (with no forwarding) would be nice. I agree. But it's the core developers' agreement we need. > > - turn on TCP_NODELAY for all sessions that have active port or > > display forwarding or which are not exec sessions (myself) > > If we can agree that Nagle should be on for pty sessions, it should be > on iff the current ssh connection only contains pty sessions, i.e. no port > forwarding channels, no sftp, no x11, etc. Yes, but, wrt SFTP, I think that the two consecutive small write()s that lead to Nagle being triggered can and SHOULD be coalesced. I've not looked at sftp/sftpd's source, but you have; how hard would that be to implement? > > - SSHv2 connections, longer-term: > > > > - add a per-channel TCP_NODELAY channel request (Markus; I second) > > This is very nice, but can we do this without breaking the (draft) RFC? > Can it be done compatibly with older versions? I think so, but empirical testing would be needed to say for sure. This belongs in the IETF list. > > - add a per-channel Nagle at the SSHv2 layer (myself, but not convinced) > > I'm convinced that this cannot be Nagle-like, since the Nagle algorithm i > needs to know whether there is any outstanding data on the connection. So? SSHv2 is a transport layer, among other things. It already has flow control, so adding Nagle is conceptually possible - it needs a channel request to turn it on and off and it needs a packet (SSHv2 packet, not TCP) acknowledgement (which would be simple too since SSHv2 already runs over a sequenced, reliable transport and so handling packets/acks out of order is not an issue). > > Something is needed to make X11 display forwarding a happy thing and > > improve SFTP performance. > > X11 already uses TCP_NODELAY, so that's not a problem. I meant the SSH connection over which the forwarding is done. > > The latter can probably be done by coallescing the write()s of those two > > packets that trigger Nagle. > > That requires delaying the window adjustment packet until we have another > packet to send, and to send them together. A timeout is also needed, but > the real problem is that this breaks down (I think) when we have > overlapping requests, which I really hope we will have real soon. In > other words, sftp wants TCP_NODELAY. But, I thought your analysis pointed to Nagle as the bottleneck and, it seemed to me when I read it, that you were saying that overlapping requests wouldn't improve performance as much as disabling Nagle would. Well, not triggering Nagle seems to me like a more noble thing to do than just disabling it. Di I misunderstand your analysis? > > The former can be a trivial heuristic. All other TCP port forwarding > > should really be done without Nagle as well. > > > > What is a reasonable short-term consensus on when SSHv2 connections > > should have TCP_NODELAY set on both sides? > > This is what I'd like to know as well... > > /Tobias Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Wed Jan 30 03:10:15 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 17:10:15 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> <20020128112648.GA17992@faui02> Message-ID: <20020129161015.GF27578@faui02> On Tue, Jan 29, 2002 at 05:01:42PM +0100, Sturle Sunde wrote: > It's usualy far more than that, since you have other authentication > options availiable for SSH-1. And particularly for scp I like to use > SSH-1 on fast local networks, since its's secure enough for most > purposes, and much faster than SSH-2. SSH2+arcfour is much faster than SSH1+3des From markus at openbsd.org Wed Jan 30 03:11:25 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 17:11:25 +0100 Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF63@hq11.army.mil> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF63@hq11.army.mil> Message-ID: <20020129161125.GG27578@faui02> On Tue, Jan 29, 2002 at 11:08:07AM -0500, Whitaker, Kenneth wrote: > Can verbose become implemented in the next version ? if someone sends patches. > The "get *" works ok but need this part to be more useful. > > prompt Toggle interactive prompting. Interactive prompt- > ing occurs during multiple file transfers to allow > the user to selectively retrieve or store files. > By default, prompting is turned on. If prompting > is turned off, any mget or mput will transfer > all files, and any mdelete will delete all files. i think this is unlikely to happen, since we don't support mget and mput... -m From WhitakerK at MTMC.ARMY.MIL Wed Jan 30 03:14:49 2002 From: WhitakerK at MTMC.ARMY.MIL (Whitaker, Kenneth) Date: Tue, 29 Jan 2002 11:14:49 -0500 Subject: Issues with SFTP Message-ID: <7933C6521AA7D211A41A0000D11BAFBF0713AF67@hq11.army.mil> Who is the "someone" to sending the patch ? Your current "get a*" for example would grab every "a*" file no prompting. My goal is not losing functionality with the ftp command. -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Tuesday, January 29, 2002 11:11 AM To: Whitaker, Kenneth Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Issues with SFTP On Tue, Jan 29, 2002 at 11:08:07AM -0500, Whitaker, Kenneth wrote: > Can verbose become implemented in the next version ? if someone sends patches. > The "get *" works ok but need this part to be more useful. > > prompt Toggle interactive prompting. Interactive prompt- > ing occurs during multiple file transfers to allow > the user to selectively retrieve or store files. > By default, prompting is turned on. If prompting > is turned off, any mget or mput will transfer > all files, and any mdelete will delete all files. i think this is unlikely to happen, since we don't support mget and mput... -m From markus at openbsd.org Wed Jan 30 03:15:29 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 17:15:29 +0100 Subject: Issues with SFTP In-Reply-To: References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> Message-ID: <20020129161529.GI27578@faui02> On Tue, Jan 29, 2002 at 04:42:43PM +0100, Tobias Ringstrom wrote: > Still, a ncsftp (c.f. ncftp) tool would be nice, but it would probably be > a separate package. you know how to find and merge the source of sftp and ncftp..... From markus at openbsd.org Wed Jan 30 03:14:19 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 17:14:19 +0100 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: References: <20020129102159.M27398@sm2p1386swk.wdr.com> Message-ID: <20020129161419.GH27578@faui02> On Tue, Jan 29, 2002 at 04:39:43PM +0100, Tobias Ringstrom wrote: > > - turn on TCP_NODELAY for interactive sessions (Markus; current state) > > Which goes against all logic and theory, right? :-) please provide information _why_ ssh-1.2.12 did it this way. _if_ we know the reason for the current state _then_ we can think about changing things and then we can change things. From Nicolas.Williams at ubsw.com Wed Jan 30 03:12:36 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 11:12:36 -0500 Subject: X.509 for verifying host keys In-Reply-To: <04f101c1a8df$00293b00$1701000a@effugas>; from dan@doxpara.com on Tue, Jan 29, 2002 at 08:07:07AM -0800 References: <20020129100106.L27398@sm2p1386swk.wdr.com> <04f101c1a8df$00293b00$1701000a@effugas> Message-ID: <20020129111235.T27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 08:07:07AM -0800, Dan Kaminsky wrote: > Anyone actually working on this privately, email me. > > I'm honestly thinking of just supporting PEM files outright, though not > abandoning the perfect forward secrecy of SSH. Are you doing this merely to deal with known_host maintenance (i.e., to avoid it altogether)? Or do you want to do X.509 pubkey userauth as well? In the latter case you'll definitely need to support CA hierarchies and you'll need a way to do name-based authorization. Oh, gee, look at that, I just posted a patch which adds the necessary infrastructure for name-based authorization and enables it for Kerberos. :) > --Dan > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From dan at doxpara.com Wed Jan 30 03:40:33 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 29 Jan 2002 08:40:33 -0800 Subject: Issues with SFTP References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> Message-ID: <052901c1a8e3$abe15b40$1701000a@effugas> > i don't consider "hash" core functionality. the only > missing feature is "qui". mget is core functionality -- I screw up on this every time. filename globbing (ls *.txt) is too. sftp is not the minimalist tool. scp is. no, ssh user at host cat is. sftp came about because, uh, scp sucks an order of magnitude more than ftp.exe from Windows 95, and that OS doesn't even ship with TCP/IP by default. I'll work on sftp next week. --dan From Nicolas.Williams at ubsw.com Wed Jan 30 03:34:06 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 11:34:06 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020129161419.GH27578@faui02>; from markus@openbsd.org on Tue, Jan 29, 2002 at 05:14:19PM +0100 References: <20020129102159.M27398@sm2p1386swk.wdr.com> <20020129161419.GH27578@faui02> Message-ID: <20020129113405.U27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 05:14:19PM +0100, Markus Friedl wrote: > On Tue, Jan 29, 2002 at 04:39:43PM +0100, Tobias Ringstrom wrote: > > > - turn on TCP_NODELAY for interactive sessions (Markus; current state) > > > > Which goes against all logic and theory, right? :-) > > please provide information _why_ ssh-1.2.12 did it this way. What I find, on a cursory look in google, is that users were unhappy with the resulting latency. > _if_ we know the reason for the current state _then_ > we can think about changing things and then we can > change things. I think you're right that we need a per-channel request to disable Nagle. The question is what to do until that is possible. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Wed Jan 30 03:41:24 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 17:41:24 +0100 Subject: Issues with SFTP In-Reply-To: <052901c1a8e3$abe15b40$1701000a@effugas> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> <052901c1a8e3$abe15b40$1701000a@effugas> Message-ID: <20020129164124.GJ27578@faui02> On Tue, Jan 29, 2002 at 08:40:33AM -0800, Dan Kaminsky wrote: > > i don't consider "hash" core functionality. the only > > missing feature is "qui". > > mget is core functionality -- I screw up on this every time. what wrong with get? From Nicolas.Williams at ubsw.com Wed Jan 30 03:39:00 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 11:39:00 -0500 Subject: X.509 for verifying host keys In-Reply-To: <20020129111235.T27171@sm2p1386swk.wdr.com>; from willian on Tue, Jan 29, 2002 at 11:12:36AM -0500 References: <20020129100106.L27398@sm2p1386swk.wdr.com> <04f101c1a8df$00293b00$1701000a@effugas> <20020129111235.T27171@sm2p1386swk.wdr.com> Message-ID: <20020129113858.T27268@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 08:07:07AM -0800, Dan Kaminsky wrote: > Anyone actually working on this privately, email me. > > I'm honestly thinking of just supporting PEM files outright, though not > abandoning the perfect forward secrecy of SSH. You could always use gsskeyex w/ GSI and/or gsskeyex w/ krb5 w/ PKINIT... The gsskeyex stuff has perfect forward secrecy (it's a GSS-protected DH key exchange). Not that a PKINIT implementation is available for either Heimdal or MIT krb5; but one would be nice (hint, hint). > --Dan > Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Wed Jan 30 03:02:27 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 10:02:27 -0600 (CST) Subject: Key fingerprint logging In-Reply-To: <20020129154054.A20373@netcentrum.cz> from Michal Kara at "Jan 29, 2002 03:40:54 pm" Message-ID: <200201291602.g0TG2Rmh016291@etoh.eviladmin.org> > Hello there! > > I have made a patch against OpenSSH 3.0.2p1 which allows the fingerprint of > the accepted key to be printed in the log message. It works with SSH1-RSA and > SSH2 pubkey (DSA+RSA) authentication. > > This feature is controllable by the LogKeyFingerprint config option (turned > off by default). > Unless I am wrong I believe -current already has this funcionality. Just it does not add another configuration option since is is always on. - Ben From mouring at etoh.eviladmin.org Wed Jan 30 03:10:58 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 10:10:58 -0600 (CST) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: from Tobias Ringstrom at "Jan 29, 2002 09:29:37 am" Message-ID: <200201291610.g0TGAwJO016230@etoh.eviladmin.org> > On Mon, 28 Jan 2002, mouring wrote: > > > [..] > > > My overlapping reads/writes for sftp seems to be ignored at the moment. > > > > > > I'm not happy. > > > > > > /Tobias > > > > > One thing you must learn Tobias, unless things are clear cut as 'THE WAY' > > to go there is (and more than likely ever will be) a long period in time > > from patch conception to inclusion. And this is one in which is not > > 100% clear cut. Between NoDelay, COPY_SIZE, how many overlapping > > segments, and if we should let the user muck with them are all things that > > will affect how we accept the patch. > > Of course I understand that it may take some time. What I do not > understand is whether a long silence after the first flurry of comments to > a patch (or a suggested change) means that the patch is under > consideration, if it was deemed unacceptable, or if it was simply > forgotten. > If you don't want to be forgotten about log it and push the patch into the bugzilla tracking system. > One other thing is that since I did not know who the maintainers were > (there seem to be a whole bunch), I did not know what "suggestions" were > "masked vetos". > Markus would be considered the 'head' of the project. It is his baby. Damien, steves, a few others, and myself would end up being the core developers (either OpenBSD committers and/or portable tree committers). Just look at the release notes for a new version and that should list all of the developers. > > I'm still waiting for you to provide any information on upping COPY_SIZE > > to 32k and retesting with multiple overlapping. I don't remember seeing > > such an email messages. > > Looking through my mailboxes, I cannot find such a request, and I do not > remember one either. The closest I can find is "Also, you may want to > check out pushing BLOCKSIZE (think that is right, not looking at the code) > to 4092 which is the max size the RFC states. This may change your > testing." > My mistake.. BLOCKSIZE was what I was trying to remember. > This comment was made invalid IMHO after the Nagle interaction problem was > found. > > > However, this should also help lower the amount of overlapping request. > > As a result lower the cost of a missing request. I don't want to get > > into the case where sftp thrashes due to multiple pending requests out > > and a bad link that drops 2 out of 5 packets. Which would not only > > cause large amount of seeks() but also could trigger edge cases within > > the code for binary integerity. > > First of all, we only need more than one overlapping request if the > delay-bandwidth product of the link is larger than the block size. I do > not have any figures for a wide number of links. The reason why I thought > I needed more was the interaction with the Nagle algorithm. The Nagle > problem is orthogonal, but needs to be resolved. It seems to be very hard > to agree on a solution, though. > > The latest version of the overlap patch (which is several weeks old now) > contains code to reduce the request size if the server splits a request. > With this mechanism, it should be safe to use a larger initial request > size. > > > I don't have the patch infront of me..but there was some bits I did not > > care for if I remember right. > > Please reconsider the patch in light of the nodelay findings. (And if you > do benchmark it, please use TCP_NODELAY in both ends.) > Some bits.. Over it is fine. I'll take a look at it again. - Ben From mouring at etoh.eviladmin.org Wed Jan 30 03:16:53 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 10:16:53 -0600 (CST) Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF63@hq11.army.mil> from "Whitaker, Kenneth" at "Jan 29, 2002 11:08:07 am" Message-ID: <200201291616.g0TGGr3S030171@etoh.eviladmin.org> [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Can verbose become implemented in the next version ? > Implement it and it will get in faster. It is on the global list of things to do.. (Like my readline patch ) But has not occured. Better do it quick... I forsee a code freeze in the near future. > The "get *" works ok but need this part to be more useful. > > prompt Toggle interactive prompting. Interactive prompt- > ing occurs during multiple file transfers to allow > the user to selectively retrieve or store files. > By default, prompting is turned on. If prompting > is turned off, any mget or mput will transfer > all files, and any mdelete will delete all files. > I hate prompt. I hate it.. I hate it..I hate it. Why the hell would I want to be prompted for EVERY file in my mget when I know what the I'm asksing for =) Sorry, I've never been a fan of 'prompt'. Markus/Damien, if we consider adding prompt. I really ask we have it default 'off' since it is the most annoying thing in the world to remember. =) - Ben From WhitakerK at MTMC.ARMY.MIL Wed Jan 30 03:59:29 2002 From: WhitakerK at MTMC.ARMY.MIL (Whitaker, Kenneth) Date: Tue, 29 Jan 2002 11:59:29 -0500 Subject: Issues with SFTP Message-ID: <7933C6521AA7D211A41A0000D11BAFBF0713AF6E@hq11.army.mil> I agree with you on prompt (default off) - but it has it uses. Thanks for your support. -----Original Message----- From: mouring [mailto:mouring at etoh.eviladmin.org] Sent: Tuesday, January 29, 2002 11:17 AM To: Whitaker, Kenneth Cc: 'openssh-unix-dev at mindrot.org' Subject: Re: Issues with SFTP [Charset iso-8859-1 unsupported, filtering to ASCII...] > > Can verbose become implemented in the next version ? > Implement it and it will get in faster. It is on the global list of things to do.. (Like my readline patch ) But has not occured. Better do it quick... I forsee a code freeze in the near future. > The "get *" works ok but need this part to be more useful. > > prompt Toggle interactive prompting. Interactive prompt- > ing occurs during multiple file transfers to allow > the user to selectively retrieve or store files. > By default, prompting is turned on. If prompting > is turned off, any mget or mput will transfer > all files, and any mdelete will delete all files. > I hate prompt. I hate it.. I hate it..I hate it. Why the hell would I want to be prompted for EVERY file in my mget when I know what the I'm asksing for =) Sorry, I've never been a fan of 'prompt'. Markus/Damien, if we consider adding prompt. I really ask we have it default 'off' since it is the most annoying thing in the world to remember. =) - Ben From dan at doxpara.com Wed Jan 30 04:11:48 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 29 Jan 2002 09:11:48 -0800 Subject: Issues with SFTP References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> <052901c1a8e3$abe15b40$1701000a@effugas> <20020129164124.GJ27578@faui02> Message-ID: <055801c1a8e8$09b12d50$1701000a@effugas> > what wrong with get? why ls instead of list? why get instead of suck? why put instead of upload? why * instead of &? why sftp instead of scp? hell, why sftp instead of sfotp? (the o stands for other.) because that's what users already know. sftp is secure on the network and ftp to the user. There are lots of ftp clients but universally they all not only support but mandate mget for getting multiple files. SFTP exists because SCP isn't transparent enough (it sure as hell ain't faster). SCP wasn't very usable, so it wasn't used, so security suffered because FTP refused to die. SFTP was born, and has a chance to wipe out FTP. You wanna tell me SFTP should be less usable than Windows95 ftp.exe? :-) --Dan From markus at openbsd.org Wed Jan 30 04:20:30 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 18:20:30 +0100 Subject: Issues with SFTP In-Reply-To: <055801c1a8e8$09b12d50$1701000a@effugas> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> <052901c1a8e3$abe15b40$1701000a@effugas> <20020129164124.GJ27578@faui02> <055801c1a8e8$09b12d50$1701000a@effugas> Message-ID: <20020129172030.GM27578@faui02> On Tue, Jan 29, 2002 at 09:11:48AM -0800, Dan Kaminsky wrote: > > what wrong with get? > > why ls instead of list? > why get instead of suck? > why put instead of upload? > why * instead of &? > why sftp instead of scp? > hell, > why sftp instead of sfotp? (the o stands for other.) so you think sftp is only usable if it clones very possible command from every possible ftp client? From bugzilla-daemon at mindrot.org Wed Jan 30 04:31:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 04:31:39 +1100 (EST) Subject: [Bug 81] ssh cannot use ssh-askspass & passphrases as documented Message-ID: <20020129173139.12759EA9B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=81 dean.r.smart at mail.sprint.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From dean.r.smart at mail.sprint.com 2002-01-30 04:31 ------- D. Millers commnents are interesting. However it seems that they changes that I suggest are required to run scp in a nohup'd script, with no executables other that ssh and scp. The use of setsid would seem to not apply if one is using shell scripting and shell commands. The code change I suggest makes things work and it fails to use ssh-askpass without. So why is allow stdin used for ssh-add if is so dangerous. My understanding of the code, which is very limited, is that this variable allows the passphrase stdin to come from the stdout of sss-askpass. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tori at ringstrom.mine.nu Wed Jan 30 04:32:23 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 18:32:23 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <20020129110818.S27171@sm2p1386swk.wdr.com> Message-ID: On Tue, 29 Jan 2002, Nicolas Williams wrote: > Yes. But the problem probably is that the old Nagle algorithm and TCP > congestion control in general probably needs revision to really work in > newer networks. Why would Nagle not work well for pty sessions over modern networks that happen to have a high latency link? As for improved TCP congestion control, I thought ECN would help a lot once it is in wide-spread use. > > > - turn on TCP_NODELAY for all sessions that have active port or > > > display forwarding or which are not exec sessions (myself) > > > > If we can agree that Nagle should be on for pty sessions, it should be > > on iff the current ssh connection only contains pty sessions, i.e. no port > > forwarding channels, no sftp, no x11, etc. > > Yes, but, wrt SFTP, I think that the two consecutive small write()s that > lead to Nagle being triggered can and SHOULD be coalesced. I've not > looked at sftp/sftpd's source, but you have; how hard would that be to > implement? It's not very easy. Delaying the window adjustment packet, as described below, and implementing a timeout would take some time. I'm not very keen on doing it. It would be a very good thing, no doubt. > > > The latter can probably be done by coallescing the write()s of those two > > > packets that trigger Nagle. > > > > That requires delaying the window adjustment packet until we have another > > packet to send, and to send them together. A timeout is also needed, but > > the real problem is that this breaks down (I think) when we have > > overlapping requests, which I really hope we will have real soon. In > > other words, sftp wants TCP_NODELAY. > > But, I thought your analysis pointed to Nagle as the bottleneck and, it > seemed to me when I read it, that you were saying that overlapping > requests wouldn't improve performance as much as disabling Nagle would. That differs from case to case. Over localhost on Linux 2.4, overlapping requests did not help very much with Nagle enabled, but between two machines in a LAN, it did help a lot, even with Nagle enabled. Note that one of the machines was not very fast in that case. > Well, not triggering Nagle seems to me like a more noble thing to do > than just disabling it. What I'm saying is that when we have overlapping requests, we need to disable nagle, even if we could merge the window update packets with the requests or responses. Let's see if I can explain it. Consider a channel with a 2 s RTT, infinite throughput, infinitely fast computers, no window updates, and a Nagle timeout of 0.2 s. The write column is the time the process calls write(), and the send column is the time the TCP stack releases the packet on the wire. Req is a small request packet (<>MSS). Write Send Signal Arrival ----------------------------------- 0.0 0.0 Req#1 -> 1.0 0.01 0.2 Req#2 -> 1.2 (nagle delay) 1.0 1.0 <- Rsp#1 2.0 1.2 1.2 <- Rsp#2 2.2 2.0 2.2 Req#3 -> 3.2 (nagle delay) 2.2 2.4 Req#4 -> 3.4 (nagle delay) 3.2 3.2 <- Rsp#3 4.2 3.4 3.4 <- Rsp#4 4.4 Did I get it right, or did I miss something? As you can see, transmitting four data packets took 4.4 seconds. Without Nagle, it would have taken 4 second. /Tobias From dan at doxpara.com Wed Jan 30 04:41:23 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 29 Jan 2002 09:41:23 -0800 Subject: Issues with SFTP References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> <052901c1a8e3$abe15b40$1701000a@effugas> <20020129164124.GJ27578@faui02> <055801c1a8e8$09b12d50$1701000a@effugas> <20020129172030.GM27578@faui02> Message-ID: <059301c1a8ec$2b9492f0$1701000a@effugas> > so you think sftp is only usable if it clones very possible command > from every possible ftp client? You get into a car. There is no steering wheel, and the gas pedal is on the ceiling. Do you think a car is only usable if it clones every possible knob from every possible vehicle? No, but everything since the Model T has had a wheel and a gas pedal... s* transparently copied the syntax of r*; sftp is the first standard ssh app with its own command interpreter but it's no less bound to support the generic set of commands found in everything from Windows 95 to Solaris 2.5.1 to probably the ancient days of ftp. I'm actually really lucky on this -- unlike, say, ps, variant branches of ftp generally changed the name of the client code, making basic BSD-derived FTP pretty homogenous. Remember -- we *are* trying to eradicate the very insecure FTP protocol from the net. --Dan From openssh-unix-dev at thewrittenword.com Wed Jan 30 05:38:18 2002 From: openssh-unix-dev at thewrittenword.com (Albert Chin) Date: Tue, 29 Jan 2002 12:38:18 -0600 Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil>; from WhitakerK@MTMC.ARMY.MIL on Tue, Jan 29, 2002 at 09:29:15AM -0500 References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> Message-ID: <20020129123818.A75577@oolong.il.thewrittenword.com> On Tue, Jan 29, 2002 at 09:29:15AM -0500, Whitaker, Kenneth wrote: > Things consider problems with sftp software > > - sftp manually first time to accept the fingerprint and anytime software > is updated on host. > - no ascii mode only binary > - no verbose or indication of bytes transfered (you would do an ls after > sftp is done) > - no mput or mget (this may be a show stopper) but could script could > generate itself with all the filenames takes coding. We use http://www.xbill.org/sftp/. Doesn't have everything you want but it does have 'exec' which OpenSSH sftp does not (allows you to execute a remote command). -- albert chin (china at thewrittenword.com) From ed at UDel.Edu Wed Jan 30 05:38:28 2002 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 29 Jan 2002 13:38:28 -0500 (EST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: Message-ID: On 29 Jan 2002, Sturle Sunde wrote: > Date: 29 Jan 2002 17:01:42 +0100 > From: Sturle Sunde > To: Markus Friedl > Cc: openssh-unix-dev at mindrot.org > Subject: Re: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 > > Markus Friedl writes: > > On Mon, Jan 28, 2002 at 11:55:03AM +0100, Wichert Akkerman wrote: > >> Previously Markus Friedl wrote: > >>> why do you need -1 and -2? > >> Users want it, and it's very useful in situations where you need > >> to specifiy the version due to existing keys, old servers, etc. > > hm, should there be an extra option for 0.0001% of all > > use cases. > > It's usualy far more than that, since you have other authentication > options availiable for SSH-1. And particularly for scp I like to use > SSH-1 on fast local networks, since its's secure enough for most > purposes, and much faster than SSH-2. We use OpenSSH 2.9.9p2 scp and it has been at least 2-3 times faster than ssh-1.2.27 ever was - as far as the data transfer goes. The initial "setup the connection" times are much slower for us in v2, but scp transfers of any significant size (>1MB or so) makes up for it. I always wondered why ssh-1.2.27 was so SLOW... but just accepted it as the best we had at the time. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From djast at cs.toronto.edu Wed Jan 30 05:43:48 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 29 Jan 2002 13:43:48 -0500 Subject: Issues with SFTP In-Reply-To: Your message of "Tue, 29 Jan 2002 10:42:43 EST." Message-ID: <02Jan29.134352edt.453142-1882@jane.cs.toronto.edu> On Tue, 29 Jan 2002 10:42:43 EST, Tobias Ringstrom writes: > On Tue, 29 Jan 2002, Whitaker, Kenneth wrote: > > > > - no verbose or indication of bytes transfered (you would do an ls afte > r > > > sftp is done) > > > > sftp is a unix tool, so it usually cries only on errors. > > Still, a ncsftp (c.f. ncftp) tool would be nice, but it would probably be > a separate package. Even nicer (IMHO) would be an ftp->sftp proxy, such as the one provided by MindTerm, so that arbitrary existing FTP user interfaces (such as ncftp) could be used until the authors of those UIs support SFTP natively. I'd love to have the time to write one, but I don't see it happening anytime soon. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From gleblanc at linuxweasel.com Wed Jan 30 05:56:09 2002 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 29 Jan 2002 10:56:09 -0800 Subject: Issues with SFTP In-Reply-To: <20020129172030.GM27578@faui02> References: <6808DCE827EBD5119DFB0002A58EF4DA57E4E5@hqempn06.agedwards.com> <20020129154412.GD27578@faui02> <052901c1a8e3$abe15b40$1701000a@effugas> <20020129164124.GJ27578@faui02> <055801c1a8e8$09b12d50$1701000a@effugas> <20020129172030.GM27578@faui02> Message-ID: <1012330569.4315.17.camel@peecee> On Tue, 2002-01-29 at 09:20, Markus Friedl wrote: > On Tue, Jan 29, 2002 at 09:11:48AM -0800, Dan Kaminsky wrote: > > > what wrong with get? > > > > why ls instead of list? > > why get instead of suck? > > why put instead of upload? > > why * instead of &? > > why sftp instead of scp? > > hell, > > why sftp instead of sfotp? (the o stands for other.) > > so you think sftp is only usable if it clones very possible command > from every possible ftp client? I believe the point that's being made is that SOME effort should be made to make sftp act like ftp. That is, supporting the most commonly used commands. Personally, I use scp and rsync via ssh, and couldn't give a rats ass about sftp. :-) Greg -- Portland, Oregon, USA. From Nicolas.Williams at ubsw.com Wed Jan 30 06:08:21 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 14:08:21 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: ; from tori@ringstrom.mine.nu on Tue, Jan 29, 2002 at 06:32:23PM +0100 References: <20020129110818.S27171@sm2p1386swk.wdr.com> Message-ID: <20020129140820.X27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 06:32:23PM +0100, Tobias Ringstrom wrote: > On Tue, 29 Jan 2002, Nicolas Williams wrote: > > > Yes. But the problem probably is that the old Nagle algorithm and TCP > > congestion control in general probably needs revision to really work in > > newer networks. > > Why would Nagle not work well for pty sessions over modern networks that > happen to have a high latency link? *shrug* That's the complaint I see when I search for this on google. > As for improved TCP congestion control, I thought ECN would help a lot > once it is in wide-spread use. That's just it. > It's not very easy. Delaying the window adjustment packet, as described > below, and implementing a timeout would take some time. I'm not very keen > on doing it. It would be a very good thing, no doubt. Hmmm. > > Well, not triggering Nagle seems to me like a more noble thing to do > > than just disabling it. > > What I'm saying is that when we have overlapping requests, we need to > disable nagle, even if we could merge the window update packets with the > requests or responses. Let's see if I can explain it. Consider a channel > with a 2 s RTT, infinite throughput, infinitely fast computers, no window > updates, and a Nagle timeout of 0.2 s. The write column is the time the > process calls write(), and the send column is the time the TCP stack > releases the packet on the wire. Req is a small request packet (< and Rsp is a large response packet (>>MSS). > > Write Send Signal Arrival > ----------------------------------- [...] > Did I get it right, or did I miss something? As you can see, transmitting > four data packets took 4.4 seconds. Without Nagle, it would have taken 4 > second. yes, 200ms is way too much nowadays. Which is why Nagle needs updating, and why Nagle could be done much better at the SSHv2 layer... > /Tobias Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Wed Jan 30 06:10:21 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 20:10:21 +0100 Subject: Issues with SFTP In-Reply-To: <20020129123818.A75577@oolong.il.thewrittenword.com> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> <20020129123818.A75577@oolong.il.thewrittenword.com> Message-ID: <20020129191021.GA13774@faui02> On Tue, Jan 29, 2002 at 12:38:18PM -0600, Albert Chin wrote: > We use http://www.xbill.org/sftp/. That's something completely different. It does not use the sftp protocol. From rick_jones2 at hp.com Wed Jan 30 06:17:48 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 11:17:48 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: <20020129102159.M27398@sm2p1386swk.wdr.com> <20020129110818.S27171@sm2p1386swk.wdr.com> Message-ID: <3C56F55C.C548279C@hp.com> Nicolas Williams wrote: > > > - turn on TCP_NODELAY for interactive sessions (Markus; > > > current state) > > > > Which goes against all logic and theory, right? :-) All it took was a large enough customer with an application that had multi-byte escape sequences sent as single-byte sends and then poof, people started setting TCP_NODELAY on things like telnet sessions. > Yes. But the problem probably is that the old Nagle algorithm and TCP > congestion control in general probably needs revision to really work > in newer networks. Hmm, an interesting comment to leave dangling out there, but probably best for tcp-impl :) rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From Nicolas.Williams at ubsw.com Wed Jan 30 06:21:52 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 14:21:52 -0500 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <3C56F55C.C548279C@hp.com>; from rick_jones2@hp.com on Tue, Jan 29, 2002 at 11:17:48AM -0800 References: <20020129102159.M27398@sm2p1386swk.wdr.com> <20020129110818.S27171@sm2p1386swk.wdr.com> <3C56F55C.C548279C@hp.com> Message-ID: <20020129142151.Y27171@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 11:17:48AM -0800, Rick Jones wrote: > All it took was a large enough customer with an application that had > multi-byte escape sequences sent as single-byte sends and then poof, > people started setting TCP_NODELAY on things like telnet sessions. Sigh. > > Yes. But the problem probably is that the old Nagle algorithm and TCP > > congestion control in general probably needs revision to really work > > in newer networks. > > Hmm, an interesting comment to leave dangling out there, but probably > best for tcp-impl :) :) Let me clarify: the TCP that we were using in the old 80s, and which we're still using, needs revision. Revisions have, in fact taken place. But not all stacks implement, say, selective acknowledgements and all that. Sigh. > rick jones Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From kevin at tgivan.com Wed Jan 30 05:14:18 2002 From: kevin at tgivan.com (kevin at tgivan.com) Date: Tue, 29 Jan 2002 10:14:18 -0800 Subject: Issues with SFTP In-Reply-To: <20020129161529.GI27578@faui02> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> <20020129161529.GI27578@faui02> Message-ID: <20020129181417.GB22836@tgivan.com> Moin Markus! Markus Friedl schrieb am Dienstag, den 29. Januar 2002: > On Tue, Jan 29, 2002 at 04:42:43PM +0100, Tobias Ringstrom wrote: > > Still, a ncsftp (c.f. ncftp) tool would be nice, but it would > > probably be a separate package. > you know how to find and merge the source of sftp and ncftp..... Actually Markus, the commercial sftp (part of ssh.com's SSH source) includes the functionality similar to ncftp where it displays the amount transferred/ETA etc. -- Kevin Sindhu Systems Engineer TGI Technologies Inc. 107 E 3rd Avenue Tel: (604) 872-6676 Ext 321 Vancouver V5T 1C7 Fax: (604) 872-6601 British Columbia, Canada From rick_jones2 at hp.com Wed Jan 30 06:44:02 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 11:44:02 -0800 Subject: Issues with SFTP References: <200201291616.g0TGGr3S030171@etoh.eviladmin.org> Message-ID: <3C56FB82.D1F50F08@hp.com> > I hate prompt. I hate it.. I hate it..I hate it. Why the > hell would I want to be prompted for EVERY file in my mget when > I know what the I'm asksing for =) Sorry, > I've never been a fan of 'prompt'. > > Markus/Damien, if we consider adding prompt. I really ask we > have it default 'off' since it is the most annoying thing in the world > to remember. =) invoking the image of ftp by putting that string in the application name comes with a lot of baggage as I'm sure is becoming painfully aparant. everyone starts to ass-u-me that it will behave just like "ftp" only be secure. hence, if the default in virtually every other ftp is that prompt is on by default, it should be on by default when/if added to sftp. principle of least surprise... ...otherwise, someone (admittedly, perhaps not very bright, but that is what the PC and Web revolutions bring as their baggage...) who wants to copy only four of the five files in the directory, and not have the fifth overwrite one she has by the same name is going to be in for a rather unpleasant surprise... rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From mouring at etoh.eviladmin.org Wed Jan 30 06:06:50 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 13:06:50 -0600 (CST) Subject: Issues with SFTP In-Reply-To: <3C56FB82.D1F50F08@hp.com> from Rick Jones at "Jan 29, 2002 11:44:02 am" Message-ID: <200201291906.g0TJ6oGY004089@etoh.eviladmin.org> [..] > hence, if the default in virtually every other ftp is that prompt is on > by default, it should be on by default when/if added to sftp. principle > of least surprise... > > ...otherwise, someone (admittedly, perhaps not very bright, but that is > what the PC and Web revolutions bring as their baggage...) who wants to > copy only four of the five files in the directory, and not have the > fifth overwrite one she has by the same name is going to be in for a > rather unpleasant surprise... > I refer to you ncftp which by default (last I used it) it was off. People managed very well. - Ben From bugzilla-daemon at mindrot.org Wed Jan 30 06:57:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 06:57:19 +1100 (EST) Subject: [Bug 84] New: last command provides incorrect information on Solaris 8 Message-ID: <20020129195719.68BE8EB1A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=84 Summary: last command provides incorrect information on Solaris 8 Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wknox at mitre.org The utmpx entry done upon logout from ssh does not contain all the fields that the login record does - this prevents the last command from working properly on Solaris 8. I have created a patch to correct this (attached below). The problem with last without this patch exhibits itself when you run "last username" - entries come up indicating that you are still logged in because the last command cannot find the logout for that login (it looks for an entry with the same username, which is not being used in the logout utmpx entries currently). The patch, which is against 3.0.2p1, merely puts all the same information into the utmpx entry for both a login and a logout. This bugzilla entry duplicates an e-mail I sent in in late November, in case this comes up as a duplicate of a known issue. --- loginrec.c~ Mon Oct 29 21:50:40 2001 +++ loginrec.c Tue Jan 29 10:56:59 2002 @@ -701,6 +701,7 @@ line_stripname(utx->ut_line, li->line, sizeof(utx->ut_line)); set_utmpx_time(li, utx); utx->ut_pid = li->pid; + strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); if (li->type == LTYPE_LOGOUT) return; @@ -711,7 +712,6 @@ */ /* strncpy(): Don't necessarily want null termination */ - strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); # ifdef HAVE_HOST_IN_UTMPX strncpy(utx->ut_host, li->hostname, MIN_SIZEOF(utx->ut_host, li->hostname)); # endif @@ -942,9 +942,7 @@ { struct utmpx utx; - memset(&utx, '\0', sizeof(utx)); - set_utmpx_time(li, &utx); - line_stripname(utx.ut_line, li->line, sizeof(utx.ut_line)); + construct_utmpx(li, &utx); # ifdef HAVE_ID_IN_UTMPX line_abbrevname(utx.ut_id, li->line, sizeof(utx.ut_id)); # endif --- session.c~ Sat Dec 1 18:37:08 2001 +++ session.c Tue Jan 29 10:56:59 2002 @@ -1866,7 +1866,7 @@ /* Record that the user has logged out. */ if (s->pid != 0) - record_logout(s->pid, s->tty); + record_logout(s->pid, s->tty, s->pw->pw_name); /* Release the pseudo-tty. */ pty_release(s->tty); --- sshlogin.c~ Tue May 8 16:33:06 2001 +++ sshlogin.c Tue Jan 29 10:56:59 2002 @@ -94,11 +94,11 @@ /* Records that the user has logged out. */ void -record_logout(pid_t pid, const char *ttyname) +record_logout(pid_t pid, const char *ttyname, const char *user) { struct logininfo *li; - li = login_alloc_entry(pid, NULL, NULL, ttyname); + li = login_alloc_entry(pid, user, NULL, ttyname); login_logout(li); login_free_entry(li); } --- sshlogin.h~ Wed Jul 4 00:46:58 2001 +++ sshlogin.h Tue Jan 29 10:56:59 2002 @@ -17,7 +17,7 @@ void record_login(pid_t, const char *, const char *, uid_t, const char *, struct sockaddr *); -void record_logout(pid_t, const char *); +void record_logout(pid_t, const char *, const char *); u_long get_last_login_time(uid_t, const char *, char *, u_int); #endif ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From rick_jones2 at hp.com Wed Jan 30 06:53:24 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 11:53:24 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: Message-ID: <3C56FDB4.DD20B351@hp.com> > Let's see if I can explain it. Consider a channel with a 2 s RTT, > infinite throughput, infinitely fast computers, no window updates, and > a Nagle timeout of 0.2 s. The write column is the time the > process calls write(), and the send column is the time the TCP stack > releases the packet on the wire. Req is a small request packet > (<>MSS). There is no such thing as a Nagle timeout. There is a delayed ACK timeout. Indeed, the two interact, but they should not be merged :) > Write Send Signal Arrival > ----------------------------------- > 0.0 0.0 Req#1 -> 1.0 > 0.01 0.2 Req#2 -> 1.2 (nagle delay) > 1.0 1.0 <- Rsp#1 2.0 > 1.2 1.2 <- Rsp#2 2.2 > 2.0 2.2 Req#3 -> 3.2 (nagle delay) > 2.2 2.4 Req#4 -> 3.4 (nagle delay) > 3.2 3.2 <- Rsp#3 4.2 > 3.4 3.4 <- Rsp#4 4.4 > > Did I get it right, or did I miss something? As you can see, > transmitting four data packets took 4.4 seconds. Without Nagle, it > would have taken 4 second. On balance I think you got it right. If you do not ever have enough reqest/response data to match the bandwidth delay product of the link, you will probably have the occasional delay from Nagle and Delayed ACK. As you get closer and closer to matching the bandwidth delay product, the responses/requests will start clocking each other onto the network, and you will no longer "see" the dleayed ACK timouts in the transfer rate. rick -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From bugzilla-daemon at mindrot.org Wed Jan 30 06:58:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 06:58:48 +1100 (EST) Subject: [Bug 84] last command provides incorrect information on Solaris 8 Message-ID: <20020129195848.C79AEEB1C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=84 wknox at mitre.org changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-current |3.0.2p1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From rick_jones2 at hp.com Wed Jan 30 07:01:31 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 12:01:31 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: <20020129110818.S27171@sm2p1386swk.wdr.com> <20020129140820.X27171@sm2p1386swk.wdr.com> Message-ID: <3C56FF9B.E079BB93@hp.com> > > Did I get it right, or did I miss something? As you can see, > > transmitting four data packets took 4.4 seconds. Without Nagle, it > > would have taken 4 second. > > yes, 200ms is way too much nowadays. Which is why Nagle needs > updating, and why Nagle could be done much better at the SSHv2 > layer... My highschool had an excellent Physics teacher who knew how to make a lasting impression. At the beginning of the term, he wanted to make sure that all his students understood the distiction between mass and weight. So, he had all of us stand-up and start jumping up and down, shouting, at the top of our lungs, "Mass is NOT Weight! Mass is NOT Weight!" (imagine 20 or so prep-school boys in coats and ties if you care to complete the picture :) So, in this context, it would be good for everyone to stand-up at your computer and start jumping up and down and "shouting (quietly so as not to disturb the neighbors) "Nagle is not Delayed ACK!" "Nagle is not Delayed ACK!" "Nagle is not Delayed ACK!" Indeed, Nagle and Delayed ACK are related (perhaps not as intimately as mass and weight but it was the best I have at the moment :) but they are not the same. Also, I know of at least one stack that uses a 50 ms standalone ACK timer :) So, in the example, it would have been a difference of 4.1 versus 4.0 seconds so a 2.5% difference rather than a 10% difference in clock time. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From markus at openbsd.org Wed Jan 30 07:03:25 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 21:03:25 +0100 Subject: Issues with SFTP In-Reply-To: <20020129181417.GB22836@tgivan.com> References: <7933C6521AA7D211A41A0000D11BAFBF0713AF5F@hq11.army.mil> <20020129161529.GI27578@faui02> <20020129181417.GB22836@tgivan.com> Message-ID: <20020129200325.GA17391@faui02> On Tue, Jan 29, 2002 at 10:14:18AM -0800, kevin at tgivan.com wrote: > Moin Markus! > Markus Friedl schrieb am Dienstag, den 29. Januar 2002: > > On Tue, Jan 29, 2002 at 04:42:43PM +0100, Tobias Ringstrom wrote: > > > > Still, a ncsftp (c.f. ncftp) tool would be nice, but it would > > > probably be a separate package. > > > you know how to find and merge the source of sftp and ncftp..... > > Actually Markus, the commercial sftp (part of ssh.com's SSH source) > includes the functionality similar to ncftp where it displays the > amount transferred/ETA etc. this is in scp.c. just steal our code. From stevesk at pobox.com Wed Jan 30 07:02:44 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 29 Jan 2002 12:02:44 -0800 (PST) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <3C56F55C.C548279C@hp.com> Message-ID: On Tue, 29 Jan 2002, Rick Jones wrote: :> Yes. But the problem probably is that the old Nagle algorithm and TCP :> congestion control in general probably needs revision to really work :> in newer networks. : :Hmm, an interesting comment to leave dangling out there, but probably :best for tcp-impl :) well, most issues seem to stem from poor intereaction with fixed-timer delayed ACKs. are any stack doing something more intelligent? From rick_jones2 at hp.com Wed Jan 30 07:20:52 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 12:20:52 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: Message-ID: <3C570424.4286D9B4@hp.com> Kevin Steves wrote: > :Hmm, an interesting comment to leave dangling out there, but probably > :best for tcp-impl :) > > well, most issues seem to stem from poor intereaction with fixed-timer > delayed ACKs. are any stack doing something more intelligent? Only if they can be clairvoyant. One might initially say that any sub-MSS send should get an immediate ACK, but then you start sending all these otherwise bogus ACKs for otherwise correctly behaving apps - for example, the request/response of a single-byte (sub-mss) netperf TCP_RR test (think really fast typist :) would go from two TCP segments per transaction to four. That would basically double the CPU time spent in the networking stack. The stack would need to know whether or not the recieving app was going to send data the other way any time soon and whether or not the other side had more data to send. The best one can do from what I can think of as I type is to use a shorter standalone ACK interval and work to make sure that apps which interact poorly with Nagle are either writen to behave properly or if they are already behaving properly to (as much as I hate to say) disable Nagle. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From mouring at etoh.eviladmin.org Wed Jan 30 07:06:23 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 14:06:23 -0600 (CST) Subject: Issues with SFTP In-Reply-To: <20020129200325.GA17391@faui02> from Markus Friedl at "Jan 29, 2002 09:03:25 pm" Message-ID: <200201292006.g0TK6NrS007300@etoh.eviladmin.org> > On Tue, Jan 29, 2002 at 10:14:18AM -0800, kevin at tgivan.com wrote: > > Moin Markus! > > Markus Friedl schrieb am Dienstag, den 29. Januar 2002: > > > On Tue, Jan 29, 2002 at 04:42:43PM +0100, Tobias Ringstrom wrote: > > > > > > Still, a ncsftp (c.f. ncftp) tool would be nice, but it would > > > > probably be a separate package. > > > > > you know how to find and merge the source of sftp and ncftp..... > > > > Actually Markus, the commercial sftp (part of ssh.com's SSH source) > > includes the functionality similar to ncftp where it displays the > > amount transferred/ETA etc. > > this is in scp.c. just steal our code. Easier said than done. scp.c and sftp.c are written differently.. I was looking at it and I am almost tempted just to rewrite large parts of the progressupdate() and family and stick it into misc.c since it is not 100% related to rcp code that exists there. For those looking watch your 4 or global vars used. I hate globals.. They make things too interesting. =) - Ben From stevesk at pobox.com Wed Jan 30 08:07:31 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 29 Jan 2002 13:07:31 -0800 (PST) Subject: Issues with SFTP In-Reply-To: <200201292006.g0TK6NrS007300@etoh.eviladmin.org> Message-ID: On Tue, 29 Jan 2002, mouring wrote: :Easier said than done. scp.c and sftp.c are written differently.. I :was looking at it and I am almost tempted just to rewrite large parts :of the progressupdate() and family and stick it into misc.c since it :is not 100% related to rcp code that exists there. also note that code is originally from openbsd ftp, where it lives in util.c. From Nicolas.Williams at ubsw.com Wed Jan 30 08:08:38 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 16:08:38 -0500 Subject: Issues with SFTP In-Reply-To: <200201292006.g0TK6NrS007300@etoh.eviladmin.org>; from mouring@etoh.eviladmin.org on Tue, Jan 29, 2002 at 02:06:23PM -0600 References: <20020129200325.GA17391@faui02> <200201292006.g0TK6NrS007300@etoh.eviladmin.org> Message-ID: <20020129160836.N27398@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 02:06:23PM -0600, mouring wrote: > For those looking watch your 4 or global vars used. I hate > globals.. They make things too interesting. =) Amen! If use of globals in OpenSSH could be minimized and existing globals done away with or stuffed into a context structure and things like fatal() replaced with forms that do longjmp() or so and the select() loop changed so OpenSSH could fit into an external event loop, then there could be a real libssh that allows a single process to have multiple ssh connections. That's a lot of work, now. > - Ben Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Wed Jan 30 07:37:46 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 14:37:46 -0600 (CST) Subject: Issues with SFTP In-Reply-To: <20020129160836.N27398@sm2p1386swk.wdr.com> from Nicolas Williams at "Jan 29, 2002 04:08:38 pm" Message-ID: <200201292037.g0TKblkR003996@etoh.eviladmin.org> > On Tue, Jan 29, 2002 at 02:06:23PM -0600, mouring wrote: > > For those looking watch your 4 or global vars used. I hate > > globals.. They make things too interesting. =) > > Amen! > > If use of globals in OpenSSH could be minimized and existing globals > done away with or stuffed into a context structure and things like > fatal() replaced with forms that do longjmp() or so and the select() > loop changed so OpenSSH could fit into an external event loop, then > there could be a real libssh that allows a single process to have > multiple ssh connections. That's a lot of work, now. > Umm.. I hate them only because it is hard to steal and reuse function calls without digging around in the guts of an application. And half the time it is faster to rewrite the function then it is to fix the shoe horn.=) Besides, I believe we have done a good job trimming down and minimizing globals. Just some stuff is more pratical in a global space than it is in a smaller scope. - Ben From mouring at etoh.eviladmin.org Wed Jan 30 07:42:16 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 14:42:16 -0600 (CST) Subject: Issues with SFTP In-Reply-To: from Kevin Steves at "Jan 29, 2002 01:07:31 pm" Message-ID: <200201292042.g0TKgG96021760@etoh.eviladmin.org> > On Tue, 29 Jan 2002, mouring wrote: > :Easier said than done. scp.c and sftp.c are written differently.. I > :was looking at it and I am almost tempted just to rewrite large parts > :of the progressupdate() and family and stick it into misc.c since it > :is not 100% related to rcp code that exists there. > > also note that code is originally from openbsd ftp, where it lives in > util.c. > Where it was just as nasty as it originally was. But if we apply the patch I suggested for malloc()ed status bars in scp. I should port it to ftp/util.c to be consistant. - Ben From djm at mindrot.org Wed Jan 30 08:43:59 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 08:43:59 +1100 (EST) Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF5B@hq11.army.mil> Message-ID: On Tue, 29 Jan 2002, Whitaker, Kenneth wrote: > > Things consider problems with sftp software > > - sftp manually first time to accept the fingerprint and anytime > software is updated on host. Only if you overwrite the key files, this is not done by default. BTW if we just accepted the identity, then it wouldn't be _secure_ ftp anymore. > - no ascii mode only binary Nor will there be. > - no verbose or indication of bytes transfered (you would do an ls > after sftp is done) Send a patch > - no mput or mget (this may be a show stopper) but could script could > generate itself with all the filenames takes coding. get & put take multiple filenames -d From fcusack at fcusack.com Wed Jan 30 08:43:19 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 29 Jan 2002 13:43:19 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123102139.C15319@swamp.cacr.caltech.edu>; from gator@cacr.caltech.edu on Wed, Jan 23, 2002 at 10:21:39AM -0800 References: <3C4ECCD3.9090300@ccf.auth.gr> <20020123084549.A15319@swamp.cacr.caltech.edu> <20020123165359.GI5255@faui02> <20020123102139.C15319@swamp.cacr.caltech.edu> Message-ID: <20020129134319.C29096@google.com> On Wed, Jan 23, 2002 at 10:21:39AM -0800, Anne Carasik wrote: > On Wed, Jan 23, 2002 at 05:53:59PM +0100, Markus Friedl wrote: > > On Wed, Jan 23, 2002 at 08:45:49AM -0800, Anne Carasik wrote: > > > Last I heard (and it's been a while), OpenSSH is supposed to have some > > > spki support, but I'm not sure when it's going to be implemented. > > > > who said this? is there anyone working on patches? > > i think lsh has some spki thingy. > > > > I don't remember who said this, as this was a while back. All I remember > is the PKI thingy, and everyone was trying to do something with it. > > From a sysadmin standpoint, I'd like to be able to manage user keys with > PKI. > > You can probably do that with PAM, right? No, PAM won't support that, at least not as specified in OSF RFC 86.0 (which is what folks generally mean when they say "PAM"). My understanding of Linux-PAM is that it can support this. However, it's not even widely supported within Linux distros AFAIK. Any implementation using Linux-PAM would be non-portable. /fc From djm at mindrot.org Wed Jan 30 08:44:39 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 08:44:39 +1100 (EST) Subject: X.509 for verifying host keys In-Reply-To: Message-ID: On Tue, 29 Jan 2002, Ed Phillips wrote: > Is anyone working on a patch for this feature? I don't remember seeing > anyone say whether they were actually going to try to implement it in the > current OpenSSH code... I was going to have a go last weekend, but got distracted with other things. -d From djm at mindrot.org Wed Jan 30 08:45:06 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 08:45:06 +1100 (EST) Subject: Key fingerprint logging In-Reply-To: <20020129154054.A20373@netcentrum.cz> Message-ID: On Tue, 29 Jan 2002, Michal Kara wrote: > Hello there! > > I have made a patch against OpenSSH 3.0.2p1 which allows the > fingerprint of the accepted key to be printed in the log message. It > works with SSH1-RSA and SSH2 pubkey (DSA+RSA) authentication. This facility is already in the CVS version -d From djm at mindrot.org Wed Jan 30 08:49:19 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 08:49:19 +1100 (EST) Subject: Issues with SFTP In-Reply-To: <7933C6521AA7D211A41A0000D11BAFBF0713AF67@hq11.army.mil> Message-ID: On Tue, 29 Jan 2002, Whitaker, Kenneth wrote: > > Who is the "someone" to sending the patch ? > > Your current "get a*" for example would grab every "a*" file no > prompting. > > My goal is not losing functionality with the ftp command. sftp is not ftp. If you want a commandline sftp client which emulates the uglieness of ftp, you won't find it here. There are a few things missing from sftp - I wish people would try out Tobias' overlapping read/write patch instead of arguing about prompting and progress meters. -d From fcusack at fcusack.com Wed Jan 30 08:49:10 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 29 Jan 2002 13:49:10 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: <20020129084851.A67094@oolong.il.thewrittenword.com>; from openssh-unix-dev@thewrittenword.com on Tue, Jan 29, 2002 at 08:48:51AM -0600 References: <20020129084851.A67094@oolong.il.thewrittenword.com> Message-ID: <20020129134909.D29096@google.com> On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > maybe this is a silly question ;-) But why is it possible to login on a > > machine with a locked account (passwd -l ) via pubkey-authentication > > (authorized_keys) ? > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > happen. > > Check the list archives and you'll find others with the same problem. > Noone has turned up a solution with Solaris 8/PAM yet. huh.. This is definitely a bug; probably in the Solaris PAM libs. I can look into this, unfortunately not within a day or so. /fc From bugzilla-daemon at mindrot.org Wed Jan 30 09:03:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 09:03:00 +1100 (EST) Subject: [Bug 81] ssh cannot use ssh-askspass & passphrases as documented Message-ID: <20020129220300.4F026EB35@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=81 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID ------- Additional Comments From djm at mindrot.org 2002-01-30 09:02 ------- If you allow from stdin then something like: nohup sh -c "tar cvf - /home/blah | ssh foo 'gzip -9 > /home/backup/foo2'" will attempt to read the passphrase from the output of the tar command. If you wish to discuss this behaviour further, please use the mailing list and do not reopen the bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tori at ringstrom.mine.nu Wed Jan 30 08:48:40 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 22:48:40 +0100 (CET) Subject: [PATCH] Added NoDelay config option and nodelay subsystem option In-Reply-To: <3C56FDB4.DD20B351@hp.com> Message-ID: On Tue, 29 Jan 2002, Rick Jones wrote: > > Let's see if I can explain it. Consider a channel with a 2 s RTT, > > infinite throughput, infinitely fast computers, no window updates, and > > a Nagle timeout of 0.2 s. The write column is the time the > > process calls write(), and the send column is the time the TCP stack > > releases the packet on the wire. Req is a small request packet > > (<>MSS). > > There is no such thing as a Nagle timeout. There is a delayed ACK > timeout. Indeed, the two interact, but they should not be merged :) Right you are, but that changes the flow to: Write Send Signal Arrival ----------------------------------- 0.0 REQ1 sent 1.0 0.01 REQ2 queued (nagle) 1.0 RESP1 sent 2.0 2.0 REQ2 sent 3.0 2.0 REQ3 queued (nagle) 3.0 RESP2 sent 4.0 4.0 REQ3 sent 5.0 4.0 REQ4 queued (nagle) 5.0 RESP3 sent 6.0 6.0 REQ3 sent 7.0 7.0 RESP4 sent 8.0 So it takes 8 seconds instead, which is even more pathetic, and adding more overlapping would not help. Now you may say that I should merge the requests into one packet. Ok, let's do that, but let's also assume that transmission of the response takes 0.1 seconds due to limited throughput. Write Activity Arrival ------------------------------------ 0.0 REQ1 and REQ2 sent 1.0 1.0 RESP1 sent 2.1 1.0 RESP2 sent 2.2 2.1 REQ3 sent 3.1 2.2 REQ4 queued (nagle) 3.1 RESP3 sent 4.2 4.2 REQ4 sent 5.2 5.2 RESP4 sent 6.3 Still pathetic, mostly since we cannot merge REQ3 and REQ4. Nah, the whole point of Nagle is to prevent several small packet on the wire, which is exactly what we need to do overlapping requests. > On balance I think you got it right. If you do not ever have enough > reqest/response data to match the bandwidth delay product of the link, > you will probably have the occasional delay from Nagle and Delayed ACK. > > As you get closer and closer to matching the bandwidth delay product, > the responses/requests will start clocking each other onto the network, > and you will no longer "see" the dleayed ACK timouts in the transfer > rate. Then I'll assume an infinitely fast computer (which should not influence the result), and a 1 s RTT link with a throughput of one response packet per second. The bandwith delay product is 2 packets, thus we need two outstanding request at any time. I'll also assume infinitely short request packets. 0.0 REQ1 and REQ2 sent (will arrive at 0.5) 0.5 REQ1 arrives RESP1 is sent (link busy until 1.5, will arrive at 2) REQ2 arrives RESP2 is queued (link busy) 1.5 RESP2 is sent (link busy until 2.5, will arrive at 3) 2.0 RESP1 arrives REQ3 is sent (will arrive at 2.5) 2.5 REQ3 arrives RESP3 is sent (link busy until 3.5, will arrive at 4) 3.0 RESP2 arrives REQ4 is queued (NAGLE!!!) Without nagle, the network would be perfectly saturated, but with nagle, it seems that it will not. Prove me wrong! /Tobias From tori at ringstrom.mine.nu Wed Jan 30 09:07:28 2002 From: tori at ringstrom.mine.nu (Tobias Ringstrom) Date: Tue, 29 Jan 2002 23:07:28 +0100 (CET) Subject: Issues with SFTP In-Reply-To: <02Jan29.134352edt.453142-1882@jane.cs.toronto.edu> Message-ID: On Tue, 29 Jan 2002, Dan Astoorian wrote: > Even nicer (IMHO) would be an ftp->sftp proxy, such as the one provided > by MindTerm, so that arbitrary existing FTP user interfaces (such as > ncftp) could be used until the authors of those UIs support SFTP > natively. How do you specify the destination? /Tobias From markus at openbsd.org Wed Jan 30 09:21:51 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 29 Jan 2002 23:21:51 +0100 Subject: Issues with SFTP In-Reply-To: <20020129160836.N27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Jan 29, 2002 at 04:08:38PM -0500 References: <20020129200325.GA17391@faui02> <200201292006.g0TK6NrS007300@etoh.eviladmin.org> <20020129160836.N27398@sm2p1386swk.wdr.com> Message-ID: <20020129232150.A22990@folly> On Tue, Jan 29, 2002 at 04:08:38PM -0500, Nicolas Williams wrote: > do longjmp() please not. From djm at mindrot.org Wed Jan 30 09:41:09 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 09:41:09 +1100 (EST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: Message-ID: On Tue, 29 Jan 2002, Ed Phillips wrote: > We use OpenSSH 2.9.9p2 scp and it has been at least 2-3 times faster than > ssh-1.2.27 ever was - as far as the data transfer goes. The initial > "setup the connection" times are much slower for us in v2 Make sure you use RSA host keys and user keys - they are significantly faster than DSA in my experience -d From djm at mindrot.org Wed Jan 30 09:46:33 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 09:46:33 +1100 (EST) Subject: Issues with SFTP In-Reply-To: <20020129181417.GB22836@tgivan.com> Message-ID: On Tue, 29 Jan 2002, kevin at tgivan.com wrote: > > you know how to find and merge the source of sftp and ncftp..... > > Actually Markus, the commercial sftp (part of ssh.com's SSH source) > includes the functionality similar to ncftp where it displays the > amount transferred/ETA etc. ours could too, if someone was to send a patch From bugzilla-daemon at mindrot.org Wed Jan 30 09:39:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 09:39:36 +1100 (EST) Subject: [Bug 85] New: ssh -2 localhost od /bin/ls | true ignore SIGPIPE Message-ID: <20020129223936.7B33CEB64@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=85 Summary: ssh -2 localhost od /bin/ls | true ignore SIGPIPE Product: Portable OpenSSH Version: -current Platform: All OS/Version: Cygwin on 9X/ME Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: markus at openbsd.org ReportedBy: markus at openbsd.org % ssh -2 localhost od /bin/ls | true transfers and discards data, while protocol v1 does not: % ssh -1 localhost od /bin/ls | true Write failed flushing stdout buffer. write stdout: Broken pipe % ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You reported the bug, or are watching the reporter. From djast at cs.toronto.edu Wed Jan 30 09:40:53 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 29 Jan 2002 17:40:53 -0500 Subject: Issues with SFTP In-Reply-To: Your message of "Tue, 29 Jan 2002 17:07:28 EST." Message-ID: <02Jan29.174102edt.453142-1882@jane.cs.toronto.edu> On Tue, 29 Jan 2002 17:07:28 EST, Tobias Ringstrom writes: > On Tue, 29 Jan 2002, Dan Astoorian wrote: > > > Even nicer (IMHO) would be an ftp->sftp proxy, such as the one provided > > by MindTerm, so that arbitrary existing FTP user interfaces (such as > > ncftp) could be used until the authors of those UIs support SFTP > > natively. > > How do you specify the destination? You'd specify the destination, and the port on localhost on which to listen, when you launch the proxy; something like: % ftp2sftp -p 2121 remoteserver Your FTP client could then connect to ftp://localhost:2121/. The feature I'm talking about is called "FTP to SFTP Bridge" in MindTerm. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From bugzilla-daemon at mindrot.org Wed Jan 30 09:51:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 30 Jan 2002 09:51:48 +1100 (EST) Subject: [Bug 86] New: Port should not depend on ListenAddress Message-ID: <20020129225148.C87FDEB2C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=86 Summary: Port should not depend on ListenAddress Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: markus at openbsd.org From Nicolas.Williams at ubsw.com Wed Jan 30 09:40:33 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 29 Jan 2002 17:40:33 -0500 Subject: Issues with SFTP In-Reply-To: <20020129232150.A22990@folly>; from markus@openbsd.org on Tue, Jan 29, 2002 at 11:21:51PM +0100 References: <20020129200325.GA17391@faui02> <200201292006.g0TK6NrS007300@etoh.eviladmin.org> <20020129160836.N27398@sm2p1386swk.wdr.com> <20020129232150.A22990@folly> Message-ID: <20020129174032.O27398@sm2p1386swk.wdr.com> On Tue, Jan 29, 2002 at 11:21:51PM +0100, Markus Friedl wrote: > On Tue, Jan 29, 2002 at 04:08:38PM -0500, Nicolas Williams wrote: > > do longjmp() > > please not. Come on! I said "or whatever" :) Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From rick_jones2 at hp.com Wed Jan 30 10:04:10 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 15:04:10 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: Message-ID: <3C572A6A.6B60C488@hp.com> > > As you get closer and closer to matching the bandwidth delay > > product, the responses/requests will start clocking each other onto > > the network, and you will no longer "see" the dleayed ACK timouts in > > the transfer rate. > > Then I'll assume an infinitely fast computer (which should not > influence the result), and a 1 s RTT link with a throughput of one > response packet per second. The bandwith delay product is 2 packets, > thus we need two outstanding request at any time. I'll also assume > infinitely short request packets. > > 0.0 REQ1 and REQ2 sent (will arrive at 0.5) > 0.5 REQ1 arrives > RESP1 is sent (link busy until 1.5, will arrive at 2) > REQ2 arrives > RESP2 is queued (link busy) > 1.5 RESP2 is sent (link busy until 2.5, will arrive at 3) > 2.0 RESP1 arrives > REQ3 is sent (will arrive at 2.5) > 2.5 REQ3 arrives > RESP3 is sent (link busy until 3.5, will arrive at 4) > 3.0 RESP2 arrives > REQ4 is queued (NAGLE!!!) > > Without nagle, the network would be perfectly saturated, but with > nagle, it seems that it will not. Prove me wrong! OK, so REQ's are very very small, Nagle is ON, it takes 1s to completely toggle a RESP onto the wire and and the RTT is one second, so the one-way latency is 0.5 seconds. I'll assume a 200 millisecond standalone ACK, but the specific there isn't too important. App TCP Link TCP App 0.0 send(REQ1) xmit(REQ1) send(REQ2) queu(REQ2) 0.5 recv(REQ1) read(REQ1) busy(RSP1) xmit(RSP1) send(RSP1) 1.0 busy(RSP1) 1.5 read(RSP1) recv(RSP1) xmit(REQ2) send(REQ3) queu(REQ3) 2.0 recv(REQ2) read(REQ2) busy(RSP2) xmit(RSP2) send(RSP2) 2.5 busy(RSP2) 3.0 read(RSP2) recv(RSP2) xmit(REQ3) send(REQ4) queu(REQ4) and the process will repeat. So, I think you were too generous initially when you sent REQ1 and RES2 onto the wire at the same time at time 0.0. Now, what happens if the number of requests that the app sends is bandwidthXdelay +1? App TCP Link TCP App 0.0 send(REQ1) xmit(REQ1) send(REQ2) queu(REQ2) send(REQ3) queu(REQ3) 0.5 recv(REQ1) read(REQ1) busy(RSP1) xmit(RSP1) send(RSP1) 1.0 busy(RSP1) 1.5 read(RSP1) recv(RSP1) xmit(REQ2+3) send(REQ4) queu(REQ4) 2.0 recv(REQ2+3) read(REQ2) busy(RSP2) xmit(RSP2) send(RSP2) read(REQ3) xmit(RSP3) send(RSP3) 2.5 busy(RSP2) 3.0 read(RSP2) recv(RSP2) busy(RSP3) xmit(REQ4) send(REQ5) queu(REQ5) 3.5 busy(RSP3) recv(REQ4) read(REQ4) xmit(RSP4) send(RSP4) 4.0 read(RSP3) recv(RSP3) busy(RSP4) OK, I can see now that it will stop where you had things stop, so clearly bwdelay+1 is insufficient, I think we need bwdelay+2 in this instance with a socket buffer size of bwdelay. I tried to diagram it out and it was ugly, but I think it result in at least two REQ's being set at once each time after the intial singleton and tripple. The reason to have the socket buffer only bwdelay is so that when that first tripple hits the third response cannot go into the socket buffer and hit TCP until the fifth(?) request arrives, so the fourth response ACK's both the four request and the fifth request. (It does this because it was sent by the app to TCP after the fifth request arrived because the fifth request acked the second response) I think I have that right though I am in a maze of twist passages :) rick -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From tsn at gbdev.net Wed Jan 30 11:17:04 2002 From: tsn at gbdev.net (Tomas Svensson) Date: Wed, 30 Jan 2002 01:17:04 +0100 Subject: Issues with SFTP In-Reply-To: <02Jan29.174102edt.453142-1882@jane.cs.toronto.edu> References: <02Jan29.174102edt.453142-1882@jane.cs.toronto.edu> Message-ID: <7249561545.20020130011704@gbdev.net> >> > Even nicer (IMHO) would be an ftp->sftp proxy, such as the one provided >> > by MindTerm, so that arbitrary existing FTP user interfaces (such as >> > ncftp) could be used until the authors of those UIs support SFTP >> > natively. >> >> How do you specify the destination? DA> You'd specify the destination, and the port on localhost on which to DA> listen, when you launch the proxy; something like: DA> % ftp2sftp -p 2121 remoteserver DA> Your FTP client could then connect to ftp://localhost:2121/. DA> The feature I'm talking about is called "FTP to SFTP Bridge" in DA> MindTerm. I think specifying it as a part of the username would be lot better (USER user at host[:port]), you don't want to restart it for every remote host you want to connect to? (I use this syntax for my ftp->ftp-over-tls proxy, works fine with all clients tested so far except Smart(!)FTP for windows). -Tomas From mouring at etoh.eviladmin.org Wed Jan 30 11:16:20 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 18:16:20 -0600 (CST) Subject: Quick sftp status indicator. Message-ID: <200201300016.g0U0GKxN002193@etoh.eviladmin.org> I think my first send was eaten by elm.. Yuck I hate this programm.. Anyawys, first the disclaimer: This is barely tests, I submit this to the general population, but I will not submit this for review of rest of the OpenSSH team. Mainly because it is horrible at best. dealing with alarm() in a sane way is not fun. It does not compile clean, but works. IF anyone cares to clean it up.. fine. Issues: 1) progressmeter() args are off, sftp-client.c arguments are unsigned 64bit. 2) Had to globalize a few variables to use the current design of the indicator. 3) It is from OpenBSD cvs tree... Therefor scp.c fails to patch right. One has to manual patch it. With that being said.. have fun.. BTW.. Embeded in this patch is another patch I submited to clean up handling the alocation of the progress bar. - Ben Index: misc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.c,v retrieving revision 1.15 diff -u -r1.15 misc.c --- misc.c 2002/01/24 21:09:25 1.15 +++ misc.c 2002/01/29 23:16:28 @@ -310,3 +310,133 @@ args->list[args->num++] = xstrdup(buf); args->list[args->num] = NULL; } + +/* scp/sftp progression meter (from src/usr.bin/ftp/util.c) */ +static int +foregroundproc(void) +{ + static pid_t pgrp = -1; + int ctty_pgrp; + + if (pgrp == -1) + pgrp = getpgrp(); + + return ((ioctl(STDOUT_FILENO, TIOCGPGRP, &ctty_pgrp) != -1 && + ctty_pgrp == pgrp)); +} + +void +progressmeter(int flag, off_t statbytes, off_t totalbytes, char *curfile) +{ +#define STALLTIME 5 /* number of seconds before xfer assumed "stalled" */ + static const char prefixes[] = " KMGTP"; + static struct timeval lastupdate; + static off_t lastsize; + static u_char *progressbar = NULL; + static size_t progressbar_size = 0; + static struct timeval start; + struct timeval now, td, wait; + off_t cursize, abbrevsize; + double elapsed; + int ratio, barlength, i, remaining; + char buf[256]; + + if (flag == -1) { + (void) gettimeofday(&start, (struct timezone *) 0); + lastupdate = start; + lastsize = 0; + } + if (foregroundproc() == 0) + return; + + (void) gettimeofday(&now, (struct timezone *) 0); + cursize = statbytes; + if (totalbytes != 0) { + ratio = 100.0 * cursize / totalbytes; + ratio = MAX(ratio, 0); + ratio = MIN(ratio, 100); + } else + ratio = 100; + + snprintf(buf, sizeof(buf), "\r%-20.20s %3d%% ", curfile, ratio); + + barlength = getttywidth() - 51; + if (barlength > progressbar_size) { + progressbar_size = barlength; + progressbar = xrealloc(progressbar, barlength); + memset(progressbar, '*', barlength); + } + + if (barlength > 0) { + i = barlength * ratio / 100; + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + "|%.*s%*s|", i, progressbar, barlength - i, ""); + } + i = 0; + abbrevsize = cursize; + while (abbrevsize >= 100000 && i < sizeof(prefixes)) { + i++; + abbrevsize >>= 10; + } + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), " %5llu %c%c ", + (unsigned long long) abbrevsize, prefixes[i], + prefixes[i] == ' ' ? ' ' : 'B'); + + timersub(&now, &lastupdate, &wait); + if (cursize > lastsize) { + lastupdate = now; + lastsize = cursize; + if (wait.tv_sec >= STALLTIME) { + start.tv_sec += wait.tv_sec; + start.tv_usec += wait.tv_usec; + } + wait.tv_sec = 0; + } + timersub(&now, &start, &td); + elapsed = td.tv_sec + (td.tv_usec / 1000000.0); + + if (flag != 1 && + (statbytes <= 0 || elapsed <= 0.0 || cursize > totalbytes)) { + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + " --:-- ETA"); + } else if (wait.tv_sec >= STALLTIME) { + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + " - stalled -"); + } else { + if (flag != 1) + remaining = (int)(totalbytes / (statbytes / elapsed) - + elapsed); + else + remaining = elapsed; + + i = remaining / 3600; + if (i) + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + "%2d:", i); + else + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + " "); + i = remaining % 3600; + snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), + "%02d:%02d%s", i / 60, i % 60, + (flag != 1) ? " ETA" : " "); + } + atomicio(write, fileno(stdout), buf, strlen(buf)); + + if (flag == 1) { + alarm(0); + atomicio(write, fileno(stdout), "\n", 1); + statbytes = 0; + } +} + +int +getttywidth(void) +{ + struct winsize winsize; + + if (ioctl(fileno(stdout), TIOCGWINSZ, &winsize) != -1) + return (winsize.ws_col ? winsize.ws_col : 80); + else + return (80); +} Index: misc.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.h,v retrieving revision 1.11 diff -u -r1.11 misc.h --- misc.h 2002/01/24 21:09:25 1.11 +++ misc.h 2002/01/29 23:16:28 @@ -30,4 +30,9 @@ int num; int nalloc; }; + void addargs(arglist *, char *, ...) __attribute__((format(printf, 2, 3))); +void progressmeter(int flag, off_t statbytes, off_t totalbytes, char *curfile); + +#define PROGRESSTIME 1 /* alarm() interval for updating progress meter */ + Index: scp.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/scp.c,v retrieving revision 1.86 diff -u -r1.86 scp.c --- scp.c 2001/12/05 03:56:39 1.86 +++ scp.c 2002/01/29 23:16:29 @@ -83,24 +83,12 @@ #include "log.h" #include "misc.h" -/* For progressmeter() -- number of seconds before xfer considered "stalled" */ -#define STALLTIME 5 -/* alarm() interval for updating progress meter */ -#define PROGRESSTIME 1 - -/* Visual statistics about files as they are transferred. */ -void progressmeter(int); - -/* Returns width of the terminal (for progress meter calculations). */ -int getttywidth(void); +void updateprogressmeter(int ignore); int do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout, int argc); /* Struct for addargs */ arglist args; -/* Time a transfer started. */ -static struct timeval start; - /* Number of bytes of current file transferred so far. */ volatile off_t statbytes; @@ -542,7 +530,9 @@ } if (showprogress) { totalbytes = stb.st_size; - progressmeter(-1); + progressmeter(-1, statbytes, totalbytes, curfile); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); } /* Keep writing after an error so that we stay sync'd up. */ for (haderr = i = 0; i < stb.st_size; i += bp->cnt) { @@ -564,7 +554,7 @@ } } if (showprogress) - progressmeter(1); + progressmeter(1, statbytes, totalbytes, curfile); if (close(fd) < 0 && !haderr) haderr = errno; @@ -808,7 +798,9 @@ if (showprogress) { totalbytes = size; - progressmeter(-1); + progressmeter(-1, statbytes, totalbytes, curfile); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); } statbytes = 0; for (count = i = 0; i < size; i += 4096) { @@ -844,7 +836,8 @@ } } if (showprogress) - progressmeter(1); + progressmeter(1, statbytes, totalbytes, curfile); + if (count != 0 && wrerr == NO && (j = atomicio(write, ofd, bp->buf, count)) != count) { wrerr = YES; @@ -1039,140 +1032,14 @@ exit(1); } -static void +void updateprogressmeter(int ignore) -{ - int save_errno = errno; - - progressmeter(0); - signal(SIGALRM, updateprogressmeter); - alarm(PROGRESSTIME); - errno = save_errno; -} - -static int -foregroundproc(void) { - static pid_t pgrp = -1; - int ctty_pgrp; + int save_errno = errno; - if (pgrp == -1) - pgrp = getpgrp(); - - return ((ioctl(STDOUT_FILENO, TIOCGPGRP, &ctty_pgrp) != -1 && - ctty_pgrp == pgrp)); + progressmeter(0, statbytes, totalbytes, curfile); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); + errno = save_errno; } -void -progressmeter(int flag) -{ - static const char prefixes[] = " KMGTP"; - static struct timeval lastupdate; - static off_t lastsize; - struct timeval now, td, wait; - off_t cursize, abbrevsize; - double elapsed; - int ratio, barlength, i, remaining; - char buf[256]; - - if (flag == -1) { - (void) gettimeofday(&start, (struct timezone *) 0); - lastupdate = start; - lastsize = 0; - } - if (foregroundproc() == 0) - return; - - (void) gettimeofday(&now, (struct timezone *) 0); - cursize = statbytes; - if (totalbytes != 0) { - ratio = 100.0 * cursize / totalbytes; - ratio = MAX(ratio, 0); - ratio = MIN(ratio, 100); - } else - ratio = 100; - - snprintf(buf, sizeof(buf), "\r%-20.20s %3d%% ", curfile, ratio); - - barlength = getttywidth() - 51; - if (barlength > 0) { - i = barlength * ratio / 100; - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - "|%.*s%*s|", i, - "***************************************" - "***************************************" - "***************************************" - "***************************************", - barlength - i, ""); - } - i = 0; - abbrevsize = cursize; - while (abbrevsize >= 100000 && i < sizeof(prefixes)) { - i++; - abbrevsize >>= 10; - } - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), " %5llu %c%c ", - (unsigned long long) abbrevsize, prefixes[i], - prefixes[i] == ' ' ? ' ' : 'B'); - - timersub(&now, &lastupdate, &wait); - if (cursize > lastsize) { - lastupdate = now; - lastsize = cursize; - if (wait.tv_sec >= STALLTIME) { - start.tv_sec += wait.tv_sec; - start.tv_usec += wait.tv_usec; - } - wait.tv_sec = 0; - } - timersub(&now, &start, &td); - elapsed = td.tv_sec + (td.tv_usec / 1000000.0); - - if (flag != 1 && - (statbytes <= 0 || elapsed <= 0.0 || cursize > totalbytes)) { - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - " --:-- ETA"); - } else if (wait.tv_sec >= STALLTIME) { - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - " - stalled -"); - } else { - if (flag != 1) - remaining = (int)(totalbytes / (statbytes / elapsed) - - elapsed); - else - remaining = elapsed; - - i = remaining / 3600; - if (i) - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - "%2d:", i); - else - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - " "); - i = remaining % 3600; - snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf), - "%02d:%02d%s", i / 60, i % 60, - (flag != 1) ? " ETA" : " "); - } - atomicio(write, fileno(stdout), buf, strlen(buf)); - - if (flag == -1) { - signal(SIGALRM, updateprogressmeter); - alarm(PROGRESSTIME); - } else if (flag == 1) { - alarm(0); - atomicio(write, fileno(stdout), "\n", 1); - statbytes = 0; - } -} - -int -getttywidth(void) -{ - struct winsize winsize; - - if (ioctl(fileno(stdout), TIOCGWINSZ, &winsize) != -1) - return (winsize.ws_col ? winsize.ws_col : 80); - else - return (80); -} Index: sftp-client.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-client.c,v retrieving revision 1.19 diff -u -r1.19 sftp-client.c --- sftp-client.c 2001/12/19 07:18:56 1.19 +++ sftp-client.c 2002/01/29 23:16:31 @@ -37,6 +37,7 @@ #include "xmalloc.h" #include "log.h" #include "atomicio.h" +#include "misc.h" #include "sftp.h" #include "sftp-common.h" @@ -49,6 +50,11 @@ /* Message ID */ static u_int msg_id = 1; +/* Shit required for processmeter() to work BLECH */ +u_int64_t offset; +u_int64_t file_size; +u_int64_t filename; + static void send_msg(int fd, Buffer *m) { @@ -668,13 +674,23 @@ return(filename); } +void +updateprogressmeter(int ignore) +{ + int save_errno = errno; + + progressmeter(0, offset, file_size, filename); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); + errno = save_errno; +} + int do_download(int fd_in, int fd_out, char *remote_path, char *local_path, int pflag) { int local_fd; u_int expected_id, handle_len, mode, type, id; - u_int64_t offset; char *handle; Buffer msg; Attrib junk, *a; @@ -723,6 +739,12 @@ return(-1); } + file_size = a->size; + filename = remote_path; + progressmeter(-1, offset, file_size, filename); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); + /* Read from remote and write to local */ offset = 0; for (;;) { @@ -786,6 +808,7 @@ xfree(data); } status = do_close(fd_in, fd_out, handle, handle_len); + progressmeter(1, offset, file_size, filename); /* Override umask and utimes if asked */ if (pflag && fchmod(local_fd, mode) == -1) @@ -814,7 +837,6 @@ { int local_fd; u_int handle_len, id; - u_int64_t offset; char *handle; Buffer msg; struct stat sb; @@ -861,6 +883,12 @@ return(-1); } + file_size = a.size; + filename = local_path; + progressmeter(-1, offset, file_size, filename); + signal(SIGALRM, updateprogressmeter); + alarm(PROGRESSTIME); + /* Read from local and write to remote */ offset = 0; for (;;) { @@ -904,6 +932,7 @@ offset += len; } + progressmeter(1, offset, file_size, filename); if (close(local_fd) == -1) { error("Couldn't close local file \"%s\": %s", local_path, Index: sftp-int.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-int.c,v retrieving revision 1.41 diff -u -r1.41 sftp-int.c --- sftp-int.c 2001/12/19 07:18:56 1.41 +++ sftp-int.c 2002/01/29 23:16:32 @@ -382,7 +382,6 @@ err = -1; goto out; } - printf("Fetching %s to %s\n", g.gl_pathv[0], abs_dst); err = do_download(in, out, g.gl_pathv[0], abs_dst, pflag); goto out; } @@ -464,7 +463,6 @@ } abs_dst = make_absolute(abs_dst, pwd); } - printf("Uploading %s to %s\n", g.gl_pathv[0], abs_dst); err = do_upload(in, out, g.gl_pathv[0], abs_dst, pflag); goto out; } From djm at mindrot.org Wed Jan 30 12:11:26 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 12:11:26 +1100 (EST) Subject: Quick sftp status indicator. In-Reply-To: <200201300016.g0U0GKxN002193@etoh.eviladmin.org> Message-ID: On Tue, 29 Jan 2002, mouring wrote: > I think my first send was eaten by elm.. Yuck I hate this programm.. > > Anyawys, first the disclaimer: > > This is barely tests, I submit this to the general population, but > I will not submit this for review of rest of the OpenSSH team. > Mainly because it is horrible at best. dealing with alarm() in > a sane way is not fun. It does not compile clean, but works. > IF anyone cares to clean it up.. fine. > > Issues: > > 1) progressmeter() args are off, sftp-client.c arguments are unsigned 64bit. > > 2) Had to globalize a few variables to use the current design of the > indicator. > > 3) It is from OpenBSD cvs tree... Therefor scp.c fails to patch right. One > has to manual patch it. > > With that being said.. have fun.. BTW.. Embeded in this patch is another > patch I submited to clean up handling the alocation of the progress bar. I'd prefer to see do_upload and do_download take a callback to handle the progress meter. The stuff in sftp-client.[ch] should be protocol related only - no UI. -d From mouring at etoh.eviladmin.org Wed Jan 30 11:34:45 2002 From: mouring at etoh.eviladmin.org (mouring) Date: Tue, 29 Jan 2002 18:34:45 -0600 (CST) Subject: Quick sftp status indicator. In-Reply-To: from Damien Miller at "Jan 30, 2002 12:11:26 pm" Message-ID: <200201300034.g0U0YkMw005129@etoh.eviladmin.org> [..] > > With that being said.. have fun.. BTW.. Embeded in this patch is another > > patch I submited to clean up handling the alocation of the progress bar. > > I'd prefer to see do_upload and do_download take a callback to handle > the progress meter. The stuff in sftp-client.[ch] should be protocol > related only - no UI. > Mostly that is pretty easy. Only catch is dealing with how to get 'offset' in a reasonable away unless we span global vars over multiple files. - Ben From rick_jones2 at hp.com Wed Jan 30 12:45:50 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Tue, 29 Jan 2002 17:45:50 -0800 Subject: [PATCH] Added NoDelay config option and nodelay subsystem option References: <3C572A6A.6B60C488@hp.com> Message-ID: <3C57504E.4AF7D34C@hp.com> Just for grins, I decided to hack an initial request burst into the netperf TCP_RR test, and then run that test between two systems with dummynet installed. Dummynet allows simulation of link rate and delay (and loss rates and such) and pushes as a STREAMS module into HP-UX 11. I initially set-up dummynet to simulate a typical users DSL link with 128000 bps up, 384000bps down, and 100ms of delay. Making only partially informed guesses I assumed that a read request was something like 128 bytes, and the reply was around 8KB. If the bitrate back to me is 384000bps, roughly 5.8 transactions per second should be the maximum the TCP_RR test should report. At 384000 bps, it will take ~171 milliseconds to transmit the response onto the wire. When the burst is set to one, that means that there will be from the apps point of view two requests outstanding at any one time. The first TCP segment of a response will contain the ACK for that request, and it will only take 50 milliseconds (plus xmit time) for the queued request to get to the sender, so everything should saturate with a pre-burst of only one in this case: TCP REQUEST/RESPONSE TEST to 192.168.1.30 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec Pre-burst is 0 57344 57344 128 8192 10.01 3.40 57344 57344 Pre-burst is 1 57344 57344 128 8192 10.01 5.49 57344 57344 Pre-burst is 2 57344 57344 128 8192 10.01 5.49 57344 57344 There was no problem with Nagle here even with the sub-mss request size. the limit of 5.49 trans/s sounds good given the other overheads I didn't count in the 5.8 (headers etc) Now up the bitrate to 384/1500, keeping the 100 milliseconds. My theoretical max trans/s is now sometihng like 22.9. This change should mean that the transmission onto the wire should be < the RTT. It will also give me a higher transaction rate so my CPU util measures have some hope of accuracy... TCP REQUEST/RESPONSE TEST to 192.168.1.30 Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % I % U us/Tr us/Tr Pre-burst is 0 57344 57344 128 8192 10.01 7.09 0.15 -1.00 210.241 -1.000 57344 57344 Pre-burst is 1 57344 57344 128 8192 10.01 8.99 0.13 -1.00 139.903 -1.000 57344 57344 Pre-burst is 2 57344 57344 128 8192 10.01 12.69 0.14 -1.00 113.075 -1.000 57344 57344 Pre-burst is 3 57344 57344 128 8192 10.01 15.39 0.28 -1.00 183.987 -1.000 57344 57344 Pre-burst is 4 57344 57344 128 8192 10.01 16.09 0.32 -1.00 201.202 -1.000 57344 57344 Pre-burst is 5 57344 57344 128 8192 10.01 17.09 0.22 -1.00 128.477 -1.000 57344 57344 Pre-burst is 6 57344 57344 128 8192 10.01 21.08 0.27 -1.00 127.765 -1.000 57344 57344 Pre-burst is 7 57344 57344 128 8192 10.01 21.18 0.25 -1.00 117.972 -1.000 57344 57344 Pre-burst is 8 57344 57344 128 8192 10.01 21.18 0.30 -1.00 142.988 -1.000 57344 57344 Pre-burst is 9 57344 57344 128 8192 10.01 21.18 0.23 -1.00 107.349 -1.000 57344 57344 Pre-burst is 10 57344 57344 128 8192 10.01 21.28 0.18 -1.00 85.826 -1.000 57344 57344 Pre-burst is 11 57344 57344 128 8192 10.01 21.18 0.22 -1.00 104.132 -1.000 57344 57344 Pre-burst is 12 57344 57344 128 8192 10.01 21.28 0.16 -1.00 73.787 -1.000 57344 57344 Pre-burst is 13 57344 57344 128 8192 10.01 21.18 0.15 -1.00 73.119 -1.000 57344 57344 Pre-burst is 14 57344 57344 128 8192 10.01 21.28 0.12 -1.00 58.184 -1.000 57344 57344 you can see that the service demand is somewhat "noisy" but that once we get near to MSS/req size (11.41 here), there is a large drop in the service demand. Now, try the same thing with TCP_NODELAY set: TCP REQUEST/RESPONSE TEST to 192.168.1.30: nodelay Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % I % U us/Tr us/Tr Pre-burst is 0 57344 57344 128 8192 10.01 7.10 0.04 -1.00 60.621 -1.000 57344 57344 Pre-burst is 1 57344 57344 128 8192 10.01 13.89 0.17 -1.00 123.216 -1.000 57344 57344 Pre-burst is 2 57344 57344 128 8192 10.01 20.19 0.23 -1.00 114.587 -1.000 57344 57344 Pre-burst is 3 57344 57344 128 8192 10.01 21.29 0.43 -1.00 199.874 -1.000 57344 57344 Pre-burst is 4 57344 57344 128 8192 10.01 21.29 0.36 -1.00 168.648 -1.000 57344 57344 Pre-burst is 5 57344 57344 128 8192 10.01 21.29 0.26 -1.00 121.913 -1.000 57344 57344 Pre-burst is 6 57344 57344 128 8192 10.01 21.29 0.31 -1.00 145.254 -1.000 57344 57344 Pre-burst is 7 57344 57344 128 8192 10.01 21.29 0.15 -1.00 69.243 -1.000 57344 57344 Pre-burst is 8 57344 57344 128 8192 10.01 21.29 0.16 -1.00 76.577 -1.000 57344 57344 Pre-burst is 9 57344 57344 128 8192 10.01 21.29 0.15 -1.00 72.690 -1.000 57344 57344 Pre-burst is 10 57344 57344 128 8192 10.01 21.29 0.16 -1.00 74.079 -1.000 57344 57344 Pre-burst is 11 57344 57344 128 8192 10.01 21.29 0.20 -1.00 95.971 -1.000 57344 57344 Pre-burst is 12 57344 57344 128 8192 10.00 21.29 0.21 -1.00 96.921 -1.000 57344 57344 Pre-burst is 13 57344 57344 128 8192 10.00 21.29 0.19 -1.00 90.452 -1.000 57344 57344 Pre-burst is 14 57344 57344 128 8192 10.00 21.29 0.23 -1.00 107.179 -1.000 57344 57344 I will admit here that the behaviour is not as I expected. That setting TCP_NODELAY got to max trans/s sooner is not a big surprise. What was a surprise was that the service demand dropped sooner and then started going back up. I suspect it is all a matter of timing and whether or not there was some batching happening from other means. I suspect that initial congestion window also has something to do with it. Even if TCP_NODELAY is set, for a sufficiently large burst size, only the first N of the burst will go-out at once, and the remainder will sit there waiting for the congestion window to open. I suppose I need to look at tcpdump traces of all this :(.... time passes.... under HP-UX 11 it would seem that the tcp_cwnd_initial of 4*MSS translates into enough initial cwnd for all 14 of the first burst of 14 to be sent without cwnd delay when TCP_NODELAY is set. This is consistent with the cwnd being implemented on a byte-count basis. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From stevesk at pobox.com Wed Jan 30 15:10:01 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 29 Jan 2002 20:10:01 -0800 (PST) Subject: Issues with SFTP In-Reply-To: <055801c1a8e8$09b12d50$1701000a@effugas> Message-ID: On Tue, 29 Jan 2002, Dan Kaminsky wrote: :SFTP exists because SCP isn't transparent enough (it sure as hell ain't :faster). oh, can you educate us on the history of sftp and rcp/scp? SCP wasn't very usable, so it wasn't used, so security suffered :because FTP refused to die. really? SFTP was born, and has a chance to wipe out :FTP. You wanna tell me SFTP should be less usable than Windows95 ftp.exe? ::-) actually, HTTP is the FTP successor. everyone knows that. From openssh-unix-dev at thewrittenword.com Wed Jan 30 15:23:44 2002 From: openssh-unix-dev at thewrittenword.com (Albert Chin) Date: Tue, 29 Jan 2002 22:23:44 -0600 Subject: locked account accessable via pubkey auth In-Reply-To: <20020129134909.D29096@google.com>; from fcusack@fcusack.com on Tue, Jan 29, 2002 at 01:49:10PM -0800 References: <20020129084851.A67094@oolong.il.thewrittenword.com> <20020129134909.D29096@google.com> Message-ID: <20020129222343.A85197@oolong.il.thewrittenword.com> On Tue, Jan 29, 2002 at 01:49:10PM -0800, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. Any help would be *greatly* appreciated. Some references in the mailing list that might help: http://marc.theaimsgroup.com/?t=100636351300012&r=1&w=2 http://bugzilla.mindrot.org/show_bug.cgi?id=14 http://marc.theaimsgroup.com/?t=100528526900004&r=1&w=2 -- albert chin (china at thewrittenword.com) From djm at mindrot.org Wed Jan 30 15:39:38 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Jan 2002 15:39:38 +1100 (EST) Subject: locked account accessable via pubkey auth In-Reply-To: <20020129134909.D29096@google.com> Message-ID: On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d From dan at doxpara.com Wed Jan 30 19:01:39 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 00:01:39 -0800 Subject: Issues with SFTP References: Message-ID: <069901c1a964$58bb53e0$1701000a@effugas> > oh, can you educate us on the history of sftp and rcp/scp? If you like. Best I can tell, Tatu put together the entire ssh package to replace the Berkeley R* series of tools(rlogin, rsh, rcp, etc) The r, or remote series of tools, existed to change the context of a generally local command -- login, sh, cp -- as directly as possible into a remote command. So pipes were redirected, syntaxes were mildly updated to include hosts as well as paths, and so on. The security was very difficult to configure and wasn't meaningful anyway. So Tatu built s* equivalents for almost the entire r* series -- command line compatible to the point that you could (and still can!) symlink rcp to scp and all tools thinking they were shelling out to rcp would just work. (Interestingly enough, there is no s* equivalent to rexec. I'm not sure if that's right or so very wrong.) ssh was successful because it transparently mapped to workflows users already knew how to work with, and did so using reasonably straightforward methods. That it handled security much more reliably than the r* series could just sealed the deal. scp was the tool distributed with ssh to handle file transfers. For various reasons, it wasn't sufficient for most workflows -- and since FTP wouldn't tunnel over the port forwards ssh supported, the choice was between learning a new, less efficient workflow or being insecure. People chose insecurity, like they usually will. > SCP wasn't very usable, so it wasn't used, so security suffered > :because FTP refused to die. > > really? Really. Compare how much needs to be typed by the user in the FTP example vs. in the SSH example. Note the multiple apps required, the amount of redundancy, even the degree of punctuation syntax needed. Dan at EFFUGAS ~ $ ftp -i ftp> open 10.0.1.11 Name (10.0.1.11:Dan): temp Password: ftp> ls ftp> mkdir foo ftp> cd foo ftp> mput mid1.pdf ftp> get mid2.pdf ftp> mget * ftp> quit to: $ ssh temp at 10.0.1.11 ls temp at 10.0.1.11's password: $ ssh temp at 10.0.1.11 mkdir foo temp at 10.0.1.11's password: $ scp mid1.pdf temp at 10.0.1.11:foo temp at 10.0.1.11's password: $ scp temp at 10.0.1.11:foo/mid2.pdf . temp at 10.0.1.11's password: $ scp temp at 10.0.1.11:foo/* . temp at 10.0.1.11's password: FTP keeps state in the user interface and implements a pretty complete file transfer interface -- get, put, list, mget/mput, often resume. SCP does (m)get/put, nothing more, and loses state in between each command. FTP does better for most workflows. Just how it is. If you don't like SFTP, don't use it. I don't like SCP, and won't even document the use of SFTP -- I do everything with cat and tar and whatnot because they're most likely to work. > SFTP was born, and has a chance to wipe out > :FTP. You wanna tell me SFTP should be less usable than Windows95 ftp.exe? > ::-) > > actually, HTTP is the FTP successor. everyone knows that. Suuuuure, HTTP is the FTP successor. Go ask every web designer you know how they upload their website to the server. :-) HTTP is great for getting files statelessly, it's awkward as hell for putting files, and it's completely silent on listing available files, changing file modes, and so on. Don't get me wrong -- I like the protocol -- but a replacement for FTP it aint. WebDAV tried to be HTTP-doing-FTP, and would have succeeded had MS written a filesystem redirector. They didn't, so it failed completely. --Dan From dan at doxpara.com Wed Jan 30 19:47:43 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 00:47:43 -0800 Subject: locked account accessable via pubkey auth References: Message-ID: <06b801c1a96a$c8876af0$1701000a@effugas> > I don't think it is a bug even. Having accounts with locked passwords, but > still accessible via pubkey auth is a very useful thing. I agree, with one small caveat: Can a user unlock his own password? --Dan From Alexander.Dost at drkw.com Wed Jan 30 20:04:42 2002 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Wed, 30 Jan 2002 10:04:42 +0100 Subject: locked account accessable via pubkey auth Message-ID: If it is locked, the users is not allowed to change his own password. So he can not unlock it. You get a permission denied when trying to do so. Alex > -----Original Message----- > From: Dan Kaminsky [SMTP:dan at doxpara.com] > Sent: Wednesday, January 30, 2002 09:48 > To: Damien Miller; Frank Cusack > Cc: openssh-unix-dev at mindrot.org; Dost, Alexander > Subject: Re: locked account accessable via pubkey auth > > > I don't think it is a bug even. Having accounts with locked passwords, > but > > still accessible via pubkey auth is a very useful thing. > > I agree, with one small caveat: Can a user unlock his own password? > > --Dan > From dan at doxpara.com Wed Jan 30 20:14:27 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 01:14:27 -0800 Subject: locked account accessable via pubkey auth References: Message-ID: <06ca01c1a96e$846801f0$1701000a@effugas> > If it is locked, the users is not allowed to change his own password. So he > can not unlock it. You get a permission denied when trying to do so. Actually, that's really useful and very cool! Which platforms support this behavior -- just recent Solaris, or most Unixen? Can a user lock their own account? --Dan From Alexander.Dost at drkw.com Wed Jan 30 20:58:25 2002 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Wed, 30 Jan 2002 10:58:25 +0100 Subject: locked account accessable via pubkey auth Message-ID: I can only speak for Solaris (8). But the comand 'passwd -l' is restricted for root. I think this behaviour is the same for all Solaris versions, as the only way to unlock your password is to change it. Then the *LK* string is replaced by the new password in /etc/shadow. But when you try to change your password the first thing is to enter your login password, which is locked... Alex > -----Original Message----- > From: Dan Kaminsky [SMTP:dan at doxpara.com] > Sent: Wednesday, January 30, 2002 10:14 > To: Dost, Alexander; Damien Miller; Frank Cusack > Cc: openssh-unix-dev at mindrot.org > Subject: Re: locked account accessable via pubkey auth > > > If it is locked, the users is not allowed to change his own password. So > he > > can not unlock it. You get a permission denied when trying to do so. > > Actually, that's really useful and very cool! Which platforms support > this > behavior -- just recent Solaris, or most Unixen? > > Can a user lock their own account? > > --Dan > > If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. From markus at openbsd.org Wed Jan 30 21:08:39 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 30 Jan 2002 11:08:39 +0100 Subject: locked account accessable via pubkey auth In-Reply-To: References: Message-ID: <20020130100839.GA27350@faui02> On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > maybe this is a silly question ;-) But why is it possible to login on a > machine with a locked account (passwd -l ) via pubkey-authentication > (authorized_keys) ? expired passwords are very different from expired accounts: if a password is expired the password can longer be used. if an account is expired the account can longer be used. or am I missing something? From markus at openbsd.org Wed Jan 30 21:36:19 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 30 Jan 2002 11:36:19 +0100 Subject: Issues with SFTP In-Reply-To: <069901c1a964$58bb53e0$1701000a@effugas>; from dan@doxpara.com on Wed, Jan 30, 2002 at 12:01:39AM -0800 References: <069901c1a964$58bb53e0$1701000a@effugas> Message-ID: <20020130113619.B29765@folly> On Wed, Jan 30, 2002 at 12:01:39AM -0800, Dan Kaminsky wrote: > $ ssh temp at 10.0.1.11 ls > temp at 10.0.1.11's password: > $ ssh temp at 10.0.1.11 mkdir foo > temp at 10.0.1.11's password: > $ scp mid1.pdf temp at 10.0.1.11:foo > temp at 10.0.1.11's password: > $ scp temp at 10.0.1.11:foo/mid2.pdf . > temp at 10.0.1.11's password: > $ scp temp at 10.0.1.11:foo/* . > temp at 10.0.1.11's password: you can hack ssh to keep the authenticated connection open and send several commands over the authenticated connection. it's all in the protocol (v2), our server allows this. From markus at openbsd.org Wed Jan 30 21:38:11 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 30 Jan 2002 11:38:11 +0100 Subject: Issues with SFTP In-Reply-To: <069901c1a964$58bb53e0$1701000a@effugas>; from dan@doxpara.com on Wed, Jan 30, 2002 at 12:01:39AM -0800 References: <069901c1a964$58bb53e0$1701000a@effugas> Message-ID: <20020130113811.C29765@folly> On Wed, Jan 30, 2002 at 12:01:39AM -0800, Dan Kaminsky wrote: > (Interestingly enough, there is no s* equivalent to rexec. I'm not sure if > that's right or so very wrong.) probably because there is no rexec client command, and because rexec is too broken. From dan at doxpara.com Wed Jan 30 22:04:54 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 03:04:54 -0800 Subject: Issues with SFTP References: <069901c1a964$58bb53e0$1701000a@effugas> <20020130113811.C29765@folly> Message-ID: <073901c1a97d$f2c075b0$1701000a@effugas> > > (Interestingly enough, there is no s* equivalent to rexec. I'm not sure if > > that's right or so very wrong.) > > probably because there is no rexec client command, and > because rexec is too broken. Awww. My explanation is much more fun, though yours is probably correct. === > you can hack ssh to keep the authenticated connection open and send > several commands over the authenticated connection. it's all in the > protocol (v2), our server allows this. I have this nagging suspicion that connection caching is possible even with SSH1, but I'm still working on finding something that works. The biggest engineering hurdle is connecting new ssh invocations to an old session; that requires some actual ugliness (the subclients need to skip most SSH authentication, and the genuine client needs to export a link to either the SSH2 channel interface or a forwarded sh). We might be able to piggyback on some of the agent code. The usability problem with scp vs. ftp isn't just that authentication isn't cached. It's that nothing is -- present working directory, transfer modes, hell, we have to continually retype ssh or scp for each command. It was enough of a problem that sftp was born. --Dan From Jason.Lacoss-Arnold at AGEDWARDS.com Wed Jan 30 23:59:03 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Wed, 30 Jan 2002 06:59:03 -0600 Subject: locked account accessable via pubkey auth Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4FD@hqempn06.agedwards.com> No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/0d7eed4a/attachment.html From dan at doxpara.com Thu Jan 31 00:17:09 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 05:17:09 -0800 Subject: locked account accessable via pubkey auth References: <6808DCE827EBD5119DFB0002A58EF4DA57E4FD@hqempn06.agedwards.com> Message-ID: <077f01c1a990$6c3e46d0$1701000a@effugas> RE: locked account accessable via pubkey authSince normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/83342529/attachment.html From Jason.Lacoss-Arnold at AGEDWARDS.com Thu Jan 31 00:26:36 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Wed, 30 Jan 2002 07:26:36 -0600 Subject: locked account accessable via pubkey auth Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4FE@hqempn06.agedwards.com> As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [ mailto:djm at mindrot.org ] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/54eb8e22/attachment.html From dan at doxpara.com Thu Jan 31 00:42:44 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 05:42:44 -0800 Subject: locked account accessable via pubkey auth References: <6808DCE827EBD5119DFB0002A58EF4DA57E4FE@hqempn06.agedwards.com> Message-ID: <07a201c1a993$fed08690$1701000a@effugas> RE: locked account accessable via pubkey authWithout SSH, is there *any* other way to access a password-locked account than to su in from root? If not, I don't see it as being valid to allow a pubkey "backdoor" by default. It comes down to whether the platforms are equating "no password = no access". Unless something else has access with no password, we shouldn't be allowing such. Now, do we generally directly manage passwd/shadow files on Solaris, or do we usually go through PAM? Can PAM report an LK password state, so we could check for it before allowing pubkey? --dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Dan Kaminsky' ; 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 5:26 AM Subject: RE: locked account accessable via pubkey auth As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/0038bd76/attachment.html From Jason.Lacoss-Arnold at AGEDWARDS.com Thu Jan 31 00:46:35 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Wed, 30 Jan 2002 07:46:35 -0600 Subject: locked account accessable via pubkey auth Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E4FF@hqempn06.agedwards.com> No. ftp doesn't allow it. The console doesn't allow it. The r* commands would allow it, but we don't allow them for obvious reasons. But we feel that the tool we're using to rid ourselves of security holes shouldn't replicate security holes. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:43 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Without SSH, is there *any* other way to access a password-locked account than to su in from root? If not, I don't see it as being valid to allow a pubkey "backdoor" by default. It comes down to whether the platforms are equating "no password = no access". Unless something else has access with no password, we shouldn't be allowing such. Now, do we generally directly manage passwd/shadow files on Solaris, or do we usually go through PAM? Can PAM report an LK password state, so we could check for it before allowing pubkey? --dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Dan Kaminsky' ; 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 5:26 AM Subject: RE: locked account accessable via pubkey auth As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [ mailto:djm at mindrot.org ] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** **************************************************************************** *********** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. **************************************************************************** *********** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/2d670479/attachment.html From dan at doxpara.com Thu Jan 31 00:59:29 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jan 2002 05:59:29 -0800 Subject: locked account accessable via pubkey auth References: <6808DCE827EBD5119DFB0002A58EF4DA57E4FF@hqempn06.agedwards.com> Message-ID: <07b601c1a996$5661c0c0$1701000a@effugas> RE: locked account accessable via pubkey authHmmm, consistency with r* series vs. consistency with what is obviously the platform designer's intent. Probably the only time I've ever seen these two in direct conflict. I'm leaning towards agreeing with you on this...it's a really special case that someone would just want pubkey. Is there anyone who thinks this isn't an obscure but genuine platform-specific security issue, solved by adding a check before pubkey to see if the password is locked on platforms with locking implemented? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Dan Kaminsky' ; 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 5:46 AM Subject: RE: locked account accessable via pubkey auth No. ftp doesn't allow it. The console doesn't allow it. The r* commands would allow it, but we don't allow them for obvious reasons. But we feel that the tool we're using to rid ourselves of security holes shouldn't replicate security holes. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:43 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Without SSH, is there *any* other way to access a password-locked account than to su in from root? If not, I don't see it as being valid to allow a pubkey "backdoor" by default. It comes down to whether the platforms are equating "no password = no access". Unless something else has access with no password, we shouldn't be allowing such. Now, do we generally directly manage passwd/shadow files on Solaris, or do we usually go through PAM? Can PAM report an LK password state, so we could check for it before allowing pubkey? --dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Dan Kaminsky' ; 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 5:26 AM Subject: RE: locked account accessable via pubkey auth As an interesting side note, HP-UX used to also have this problem, but I just tested on an 11.0 trusted HP-UX box and disabling my account in SAM did actually disable it to ssh. Unfortunately, we don't have any untrusted systems, so I can't tell if it's a ramification of the HPs whole tcb shananigans (their version of shadow files) or if all of HP is similarly fixed. Also, I'm pretty sure that this behavior in Solaris way predated version 8. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Dan Kaminsky [mailto:dan at doxpara.com] Sent: Wednesday, January 30, 2002 7:17 To: Lacoss-Arnold, Jason; 'Damien Miller'; Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth Since normally it's impossible to access the account of a password-disabled account, should default behavior on Solaris be to assume password-disabled means access-disabled? It seems to me that the rest of the Solaris tools assume "no password = no access". Perhaps we should as well, and provide a separate configuration option to override to the useful but non-obvious pubkey-only mode. Thoughts? --Dan ----- Original Message ----- From: Lacoss-Arnold, Jason To: 'Damien Miller' ; Frank Cusack Cc: openssh-unix-dev at mindrot.org ; Dost, Alexander Sent: Wednesday, January 30, 2002 4:59 AM Subject: RE: locked account accessable via pubkey auth No, it's at best a really annoying "feature" but it feels more like a bug. Basically, it makes it a royal pain in the arse to disable an account when a user leaves since all of the Solaris tools assume that passwd=*LK* means that the account is disabled. Hence, if you actually want to disable the account you have to first use Sun's tool and additionally either change the shell to /bin/false or similar, put the user in a group that's listed in sshd_config's DenyGroups, go wipe out user keys and configs, or some other kludge. Kludging sucks. Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Tuesday, January 29, 2002 22:40 To: Frank Cusack Cc: openssh-unix-dev at mindrot.org; Dost, Alexander Subject: Re: locked account accessable via pubkey auth On Tue, 29 Jan 2002, Frank Cusack wrote: > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > maybe this is a silly question ;-) But why is it possible to login on a > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > (authorized_keys) ? > > > I use OpenSSH3.01p1on Solaris8 with PAM support so I thought this should not > > > happen. > > > > Check the list archives and you'll find others with the same problem. > > Noone has turned up a solution with Solaris 8/PAM yet. > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > look into this, unfortunately not within a day or so. I don't think it is a bug even. Having accounts with locked passwords, but still accessible via pubkey auth is a very useful thing. -d _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020130/f0d2bc41/attachment.html From cmadams at hiwaay.net Thu Jan 31 03:09:56 2002 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 30 Jan 2002 10:09:56 -0600 Subject: locked account accessable via pubkey auth In-Reply-To: <06ca01c1a96e$846801f0$1701000a@effugas> References: <06ca01c1a96e$846801f0$1701000a@effugas> Message-ID: <20020130160956.GM29419@HiWAAY.net> Once upon a time, Dan Kaminsky said: > > If it is locked, the users is not allowed to change his own password. So > he > > can not unlock it. You get a permission denied when trying to do so. > > Actually, that's really useful and very cool! Which platforms support this > behavior -- just recent Solaris, or most Unixen? I think the old shadow-utils had the -l/-u options to passwd to lock and unlock a password. I added them to the passwd command that Red Hat Linux uses several years ago and sent the patch to Red Hat (I don't know if other Linux distributions have it). > Can a user lock their own account? Remember, it is the password that is locked, not the account (that's what brought this thread up). And no, users can't do this; only root is allowed to use -l/-u. Compaq Tru64 Unix doesn't have this option to passwd. If you use enhanced security, you can "usermod -x administrative_lock_applied=1 " an account it can no longer log in at all (the account is locked, not the password). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Nicolas.Williams at ubsw.com Thu Jan 31 03:23:31 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 30 Jan 2002 11:23:31 -0500 Subject: locked account accessable via pubkey auth In-Reply-To: <07b601c1a996$5661c0c0$1701000a@effugas>; from dan@doxpara.com on Wed, Jan 30, 2002 at 05:59:29AM -0800 References: <6808DCE827EBD5119DFB0002A58EF4DA57E4FF@hqempn06.agedwards.com> <07b601c1a996$5661c0c0$1701000a@effugas> Message-ID: <20020130112329.P27398@sm2p1386swk.wdr.com> Leave things as they are please - do not add a check to see if the password field in the shadow entry is *LK*, that would not be generally useful (think: what if you're using only Kerberos for password validation?). Setting a user's shell to /bin/false works quite well. So does putting them in a deny group. And BTW, you do have the same sort of problem with, say, Samba. If you're using PAM you can always add write/install/use a PAM module whose job is to return PAM_PERM_DENIED or something from its pam_sm_acct_mgmt() for locked accounts using whatever mechanism youX prefer for checking for locked accounts. That's what PAM is there for. Better to write/install/use a PAM module than to add kludges to apps like OpenSSH. IMHO. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Darren.Moffat at eng.sun.com Thu Jan 31 04:55:09 2002 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 30 Jan 2002 09:55:09 -0800 (PST) Subject: locked account accessable via pubkey auth Message-ID: <200201301756.g0UHuK3g860089@jurassic.eng.sun.com> >On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: >> maybe this is a silly question ;-) But why is it possible to login on a >> machine with a locked account (passwd -l ) via pubkey-authentication >> (authorized_keys) ? > >expired passwords are very different from expired accounts: which are different to locked accounts. >if a password is expired the password can longer be used. correct. The password can be changed either by the user at login, r*/telnet/ssh/dtlogin in Solaris support this. ftp doesn't and can't due to protocol restrictions. >if an account is expired the account can longer be used. correct. This in Solaris is an absoulte date in time. The passwd command is used to set this but we have no easy way to reactivate the account other than chaning the date to something in the future. OpenSSH honours this when PAM is used. >or am I missing something? A locked account in Solaris is one who's password begins *LK*, this is what happens when running passwd -l . *NP* means that the password wasn't accessible to that user - either passwd.adjunct is in use for NIS or the NIS+ password table permissions are set so that only the user can see their password (if it was the user doing the lookup then it means that they haven't had their AUTH_DH keys registered with the local keyserv (ie not done a keylogin or had pam_unix run)). This works because *LK* can't possibly match the hashed password the user types in when crypt(3c) is used. But if like OpenSSH you don't always use pam_authenticate then this doesn't stop the user getting in if you only call pam_acct_mgmt. This is fixed in Solaris 9 the pam_unix_account module in Solaris 9 explicitly checks for the *LK* string so SSH logins with publickey to an account with *LK* as the first 4 chars of the password field will be denied - which is the correct behaviour. If you wish to disable password based login but do want to have publickey based login then use NP which is no password (this is what is used for the "system" accounts that should never have a login password set on them). An account can also be refused login because it has been idle too long, this is based on the last login date in lastlog - this is pretty much useless because it is on a per host basis rather than network wide. -- Darren J Moffat From djast at cs.toronto.edu Thu Jan 31 05:09:27 2002 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 30 Jan 2002 13:09:27 -0500 Subject: Issues with SFTP In-Reply-To: Your message of "Tue, 29 Jan 2002 19:17:04 EST." <7249561545.20020130011704@gbdev.net> Message-ID: <02Jan30.130928edt.453147-1882@jane.cs.toronto.edu> On Tue, 29 Jan 2002 19:17:04 EST, Tomas Svensson writes: [ Tobias Ringstrom writes:] > >> How do you specify the destination? [...] > I think specifying it as a part of the username would be lot better [...] Well, you'd need to deal with ssh's prompts for authentication (e.g., passphrases) somehow. If you want to write the code, by all means do it any way you see fit. :-) AppGate MindTerm (which has the only existing ftp->sftp proxy I'm aware of) works the way I've described. Most firewall products which implement (non-transparent) FTP proxying use other methods, including the one described by Tomas. FWIW, the current NcFTP client's firewall support implements about six different variations on that theme. I don't really want to generate further noise on openssh-unix-dev speculating about whether one approach is better than others unless there's someone listening who's ready, willing, and able to turn design into code. The question I was trying to raise here was whether it might make sense to put coding effort into creating such a proxy _instead of_ loading up the sftp client's UI with features, since there seem to be a lot of opinions on exactly what features the OpenSSH sftp client "should" have. Let's decide on "if" before we spend a lot of time on "how," yes? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From bugzilla-daemon at mindrot.org Thu Jan 31 09:24:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 09:24:36 +1100 (EST) Subject: [Bug 87] New: Last logon that gets reported upon login is the current login time Message-ID: <20020130222436.97AD3E917@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=87 Summary: Last logon that gets reported upon login is the current login time Product: Portable OpenSSH Version: 3.0.2p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wknox at mitre.org The last login time that gets reported with a Solaris PAM enabled build of OpenSSH 3.0.2p1 is the login time of the current session. Examining the mail archive, this was reported by Benn Oshrin on 10/12/2001, and he sent in a patch that moved the do_pam_session call into the do_login function in session.c. I can't find any discussion about why that patch did not get applied, but it hasn't, so I propose, instead of moving the do_pam_session call, to move the call to get_last_login_time into do_exec_pty and pass the resultant information to do_login. This has the unfortunate result of getting information that you may never use, but it seems that the portable release does have a few things in it explicit for one system or another, so this may be viable. The definition of do_login could be changed and the call could be made in do_exec_pty only on Solaris using PAM (using a #ifdef PAM_SUN_CODEBASE), but that seemed overly complicated to me. Any comments, anyone? Patch is below. --- session.c~ Sat Dec 1 18:37:08 2001 +++ session.c Tue Jan 29 16:14:25 2002 @@ -128,7 +128,7 @@ void do_exec_pty(Session *, const char *); void do_exec_no_pty(Session *, const char *); void do_exec(Session *, const char *); -void do_login(Session *, const char *); +void do_login(Session *, const char *, const time_t, const char *); #ifdef LOGIN_NEEDS_UTMPX static void do_pre_login(Session *s); #endif @@ -548,11 +548,17 @@ { int fdout, ptyfd, ttyfd, ptymaster; pid_t pid; + char hostname[MAXHOSTNAMELEN]; + time_t last_login_time; if (s == NULL) fatal("do_exec_pty: no session"); ptyfd = s->ptyfd; ttyfd = s->ttyfd; + /* Get the time and hostname when the user last logged in. */ + hostname[0] = '\0'; + last_login_time = get_last_login_time(s->pw->pw_uid, s->pw->pw_name, + hostname, sizeof(hostname)); #if defined(USE_PAM) do_pam_session(s->pw->pw_name, s->tty); @@ -584,7 +590,7 @@ /* record login, etc. similar to login(1) */ #ifndef HAVE_OSF_SIA if (!(options.use_login && command == NULL)) - do_login(s, command); + do_login(s, command, last_login_time, hostname); # ifdef LOGIN_NEEDS_UTMPX else do_pre_login(s); @@ -682,13 +688,11 @@ /* administrative, login(1)-like work */ void -do_login(Session *s, const char *command) +do_login(Session *s, const char *command, const time_t found_last_login_time, const char *last_host) { char *time_string; - char hostname[MAXHOSTNAMELEN]; socklen_t fromlen; struct sockaddr_storage from; - time_t last_login_time; struct passwd * pw = s->pw; pid_t pid = getpid(); @@ -706,13 +710,6 @@ } } - /* Get the time and hostname when the user last logged in. */ - if (options.print_lastlog) { - hostname[0] = '\0'; - last_login_time = get_last_login_time(pw->pw_uid, pw->pw_name, - hostname, sizeof(hostname)); - } - /* Record that there was a login on that tty from the remote host. */ record_login(pid, s->tty, pw->pw_name, pw->pw_uid, get_remote_name_or_ip(utmp_len, options.reverse_mapping_check), @@ -741,14 +738,14 @@ printf("%s\n", aixloginmsg); #endif /* WITH_AIXAUTHENTICATE */ - if (options.print_lastlog && last_login_time != 0) { - time_string = ctime(&last_login_time); + if (options.print_lastlog && found_last_login_time != 0) { + time_string = ctime(&found_last_login_time); if (strchr(time_string, '\n')) *strchr(time_string, '\n') = 0; - if (strcmp(hostname, "") == 0) + if (strcmp(last_host, "") == 0) printf("Last login: %s\r\n", time_string); else - printf("Last login: %s from %s\r\n", time_string, hostname); + printf("Last login: %s from %s\r\n", time_string, last_host); } do_motd(); @@ -1866,7 +1863,7 @@ /* Record that the user has logged out. */ if (s->pid != 0) - record_logout(s->pid, s->tty); + record_logout(s->pid, s->tty, s->pw->pw_name); /* Release the pseudo-tty. */ pty_release(s->tty); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mstone at cs.loyola.edu Thu Jan 31 10:49:29 2002 From: mstone at cs.loyola.edu (Michael Stone) Date: Wed, 30 Jan 2002 18:49:29 -0500 Subject: Issues with SFTP In-Reply-To: <069901c1a964$58bb53e0$1701000a@effugas>; from dan@doxpara.com on Wed, Jan 30, 2002 at 12:01:39AM -0800 References: <069901c1a964$58bb53e0$1701000a@effugas> Message-ID: <20020130184929.N20374@justice.loyola.edu> On Wed, Jan 30, 2002 at 12:01:39AM -0800, Dan Kaminsky wrote: > (Interestingly enough, there is no s* equivalent to rexec. I'm not sure if > that's right or so very wrong.) other than the fact that rexec starts with 'r' it has no relation to the 'r' commands. -- Mike Stone From fcusack at fcusack.com Thu Jan 31 11:00:50 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 16:00:50 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: ; from djm@mindrot.org on Wed, Jan 30, 2002 at 03:39:38PM +1100 References: <20020129134909.D29096@google.com> Message-ID: <20020130160050.T29096@google.com> On Wed, Jan 30, 2002 at 03:39:38PM +1100, Damien Miller wrote: > On Tue, 29 Jan 2002, Frank Cusack wrote: > > > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > > maybe this is a silly question ;-) But why is it possible to login on a > > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > > (authorized_keys) ? > > > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > > look into this, unfortunately not within a day or so. > > I don't think it is a bug even. Having accounts with locked passwords, but > still accessible via pubkey auth is a very useful thing. I agree, that is useful, but whether or not it's a bug depends on the meaning of 'passwd -l'. SUSv2 does not define the passwd command, so I guess this is implementation-dependent. On Solaris 8, passwd(8) says -l "Locks password entry for _name_". It does not say that it locks the *account*. So this would seem to be consistent with pubkey auth still being allowed. Even so, I would tend to think it should lock the "account". I don't know if this list is a good place for it, but personally I would be interested in hearing arguments for either. Can someone report on what the HP-UX man page says? I'd also be interested to see the man page for HP-UX getspent(). (Another email in this thread says HP-UX prevents pubkey auth after 'passwd -l'.) /fc From Darren.Moffat at eng.sun.com Thu Jan 31 11:06:07 2002 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 30 Jan 2002 16:06:07 -0800 (PST) Subject: locked account accessable via pubkey auth Message-ID: <200201310007.g0V07J3g944666@jurassic.eng.sun.com> >On Solaris 8, passwd(8) says -l "Locks password entry for _name_". It does >not say that it locks the *account*. So this would seem to be consistent >with pubkey auth still being allowed. Even so, I would tend to think it >should lock the "account". I don't know if this list is a good place for >it, but personally I would be interested in hearing arguments for either. It is a bug and it has been fixed in Solaris 9, see my other email for the details. -- Darren J Moffat From fcusack at fcusack.com Thu Jan 31 11:18:36 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 16:18:36 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: <200201301756.g0UHuK3g860089@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Jan 30, 2002 at 09:55:09AM -0800 References: <200201301756.g0UHuK3g860089@jurassic.eng.sun.com> Message-ID: <20020130161835.V29096@google.com> On Wed, Jan 30, 2002 at 09:55:09AM -0800, Darren Moffat wrote: > This is fixed in Solaris 9 the pam_unix_account module in Solaris 9 explicitly > checks for the *LK* string so SSH logins with publickey to an account with > *LK* as the first 4 chars of the password field will be denied - which is the > correct behaviour. Please make sure the man page is updated. :-) For Solaris 8 it says the password is locked (not the account). /fc From fcusack at fcusack.com Thu Jan 31 11:24:47 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 16:24:47 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: <20020130112329.P27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Jan 30, 2002 at 11:23:31AM -0500 References: <6808DCE827EBD5119DFB0002A58EF4DA57E4FF@hqempn06.agedwards.com> <07b601c1a996$5661c0c0$1701000a@effugas> <20020130112329.P27398@sm2p1386swk.wdr.com> Message-ID: <20020130162446.W29096@google.com> On Wed, Jan 30, 2002 at 11:23:31AM -0500, Nicolas Williams wrote: > Leave things as they are please - do not add a check to see if the > password field in the shadow entry is *LK*, that would not be generally > useful (think: what if you're using only Kerberos for password > validation?). I have to agree with Nico here, don't try to second guess the system designers. On Solaris (up to 8, anyway), it seems that 'passwd -l' is NOT intended to lock the account. Those that want other behaviour should take it up with the vendor (or switch vendors). FWIW, I do think this is a "bug" in that it really should lock the account. Apparently, Sun thinks so also (as Darren points out). /fc From fcusack at fcusack.com Thu Jan 31 11:10:26 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 16:10:26 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: <20020130160956.GM29419@HiWAAY.net>; from cmadams@hiwaay.net on Wed, Jan 30, 2002 at 10:09:56AM -0600 References: <06ca01c1a96e$846801f0$1701000a@effugas> <20020130160956.GM29419@HiWAAY.net> Message-ID: <20020130161025.U29096@google.com> On Wed, Jan 30, 2002 at 10:09:56AM -0600, Chris Adams wrote: > Once upon a time, Dan Kaminsky said: > > > If it is locked, the users is not allowed to change his own password. So > > he > > > can not unlock it. You get a permission denied when trying to do so. > > > > Actually, that's really useful and very cool! Which platforms support this > > behavior -- just recent Solaris, or most Unixen? > > I think the old shadow-utils had the -l/-u options to passwd to lock and > unlock a password. > > I added them to the passwd command that Red Hat Linux uses several years > ago and sent the patch to Red Hat (I don't know if other Linux > distributions have it). > > > Can a user lock their own account? > > Remember, it is the password that is locked, not the account (that's > what brought this thread up). And no, users can't do this; only root is > allowed to use -l/-u. That's not what the RH-Linux man page says: -l This option is used to lock the specified account This is from a passwd-0.64.1-1, shadow-utils-19990827-10 system. However, a quick look through the pam-0.72-20 sources shows that the account is not locked; just the password (for both pam_pwdb and pam_unix). ie, pam_acct_mgmt() returns no error for an "account" locked with 'passwd -l'. /fc From Darren.Moffat at eng.sun.com Thu Jan 31 12:02:37 2002 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 30 Jan 2002 17:02:37 -0800 (PST) Subject: locked account accessable via pubkey auth Message-ID: <200201310103.g0V13o3g954659@jurassic.eng.sun.com> >On Wed, Jan 30, 2002 at 11:23:31AM -0500, Nicolas Williams wrote: >> Leave things as they are please - do not add a check to see if the >> password field in the shadow entry is *LK*, that would not be generally >> useful (think: what if you're using only Kerberos for password >> validation?). The you should NOT be marking the account as being locked you should give it an invalid password entry - eg NP. >I have to agree with Nico here, don't try to second guess the system >designers. On Solaris (up to 8, anyway), it seems that 'passwd -l' is >NOT intended to lock the account. Those that want other behaviour should >take it up with the vendor (or switch vendors). It has always been a bug. However until PAM became a public API in Solaris 2.6 it wasn't possible to augment the authentication so most apps just did strcmp(crypt(getpass()), sp->sp_pwd) and with *LK* you couldn't get a success. When PAM was introduced the difference between the account being locked and password being something invalid be came more obvious, pam_sm_uthenticate() in pam_unix(5) checks the password that the user offers matches what is stored encrypted in the relevant nameservice. pam_acct_mgmt() checks the account validity (password aging, expiry etc). Most of the time applications call pam_authenticate() first and with the pam_unix(5) module you never get any further. sshd, cron are the obvious exceptions to that. cron was where we found this issue. It is logged as bug# 4506972 in SunSolve. As justification from existing documentation I offer: pam_sm_acct_mgmt(3pam) says: The pam_sm_acct_mgmt() function determines whether or not the current user's account and password are valid. This includes checking for password and account expiration, and valid login times. The user in question is specified by a prior call to pam_start(), and is referenced by the authen- tication handle, pamh, which is passed as the first argument to pam_sm_acct_mgmt(). The following flags may be set in the flags field: The pam_acct_mgmt() function is called to determine if the current user's account is valid. It checks for password and account expiration, and verifies access hour restrictions. This function is typically called after the user has been authenticated with pam_authenticate(3PAM). pam_unix(5) says: Unix Account Management Module The UNIX account management component provides a function to perform account management, pam_sm_acct_mgmt(). The function retrieves the user's password entry from the UNIX password database and verifies that the user's account and password have not expired. The following options may be passed in to the UNIX service module: shadow(4) defines a valid password: password A 13-character encrypted password for the user, a lock string to indicate that the login is not accessible, or no string, which shows that there is no password for the login. All Solaris code used *LK* to mean locked. NIS+ uses *NP* to mean I'm not giving it to you. Note that it doesn't actually say what the lock string is until Solaris 9. New in Solaris 9 is pam_unix_account(5) which says: pam_unix_account provides functionality to the PAM account management stack. The function pam(3PAM) function retrieves password aging information from the repositories specified in nsswitch.conf(4), and verifies that the user's account and password have not expired. passwd(1)'s description of the -l flag does still say: -l Locks password entry for name. Note that it doesn't say it locks the password it says locks the "password entry", implying it disables access to the account. I agree this could be clearer - I'll see what I can do about getting it changed. -- Darren J Moffat From sturle.sunde at usit.uio.no Thu Jan 31 12:23:09 2002 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 31 Jan 2002 02:23:09 +0100 Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: <20020129161015.GF27578@faui02> References: <200201280710.g0S7AB32021616@etoh.eviladmin.org> <20020128095539.GN31953@wiggy.net> <20020128100534.GD10384@faui02> <20020128105503.GC19577@wiggy.net> <20020128112648.GA17992@faui02> <20020129161015.GF27578@faui02> Message-ID: Markus Friedl writes: > On Tue, Jan 29, 2002 at 05:01:42PM +0100, Sturle Sunde wrote: >> It's usualy far more than that, since you have other authentication >> options availiable for SSH-1. And particularly for scp I like to use >> SSH-1 on fast local networks, since its's secure enough for most >> purposes, and much faster than SSH-2. > > SSH2+arcfour is much faster than SSH1+3des My tests show they are about the same speed on most architectures. I do have arcfour as the first cipher on the list for SSH2, but SSH1+blowfish is much faster than SSH2+arcfour. My testing also show that arcfour falls behind om Pentium IV, where blowfish is the fastest. In fact arcfour on Pentium IV is slower than arcfour on Pentium III. Is that just my OpenSSL library, or do other people get the same results? -- Sturle All eyes were on Ford Prefect. Some of them were on stalks. ~~~~~~ -- Douglas Adams, So long, and thanks for all the fish From cmadams at hiwaay.net Thu Jan 31 12:25:17 2002 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 30 Jan 2002 19:25:17 -0600 Subject: locked account accessable via pubkey auth In-Reply-To: <20020130161025.U29096@google.com> References: <06ca01c1a96e$846801f0$1701000a@effugas> <20020130160956.GM29419@HiWAAY.net> <20020130161025.U29096@google.com> Message-ID: <20020131012517.GG16470@HiWAAY.net> Once upon a time, Frank Cusack said: > That's not what the RH-Linux man page says: > > -l This option is used to lock the specified account > > This is from a passwd-0.64.1-1, shadow-utils-19990827-10 system. > > However, a quick look through the pam-0.72-20 sources shows that the account > is not locked; just the password (for both pam_pwdb and pam_unix). ie, > pam_acct_mgmt() returns no error for an "account" locked with 'passwd -l'. Oh well. The patch I submitted back in 1998 said that it locked the password, not the account. :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fcusack at fcusack.com Thu Jan 31 12:42:18 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 17:42:18 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: <200201310103.g0V13o3g954659@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Jan 30, 2002 at 05:02:37PM -0800 References: <200201310103.g0V13o3g954659@jurassic.eng.sun.com> Message-ID: <20020130174218.G29096@google.com> On Wed, Jan 30, 2002 at 05:02:37PM -0800, Darren Moffat wrote: > New in Solaris 9 is pam_unix_account(5) which says: > > pam_unix_account provides functionality to the PAM account > management stack. The function pam(3PAM) function retrieves > password aging information from the repositories specified > in nsswitch.conf(4), and verifies that the user's account > and password have not expired. hmm... This seems broken. If I want a certain service to check pam_unix, I list it in pam.conf. Instead, I'm now supposed to call pam_unix_account() specifically? Is pam_unix_account() somehow different than the normal pam account mgmt w/ pam_unix in pam.conf? The intent of this (AFAICT) is so that an app can always check against pam_unix, regardless of what's in pam.conf -- broken. Sorry, this is getting OT. Oh, there's a typo in that man page, it looks like it should read "The function pam_unix_account(3PAM)". :-) > passwd(1)'s description of the -l flag does still say: > -l Locks password entry for name. > > > Note that it doesn't say it locks the password it says locks the "password > entry", implying it disables access to the account. I agree this could > be clearer - I'll see what I can do about getting it changed. Do you know if a patch will be available for Solaris 8? /fc From djm at mindrot.org Thu Jan 31 12:59:47 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 31 Jan 2002 12:59:47 +1100 (EST) Subject: [PATCH] Add scp -1 and -2 options to OpenSSH-3.0.2p1 In-Reply-To: Message-ID: On 31 Jan 2002, Sturle Sunde wrote: > Markus Friedl writes: > > SSH2+arcfour is much faster than SSH1+3des > > My tests show they are about the same speed on most architectures. I > do have arcfour as the first cipher on the list for SSH2, but > SSH1+blowfish is much faster than SSH2+arcfour. You might want to try one of the truncated MACs, this may have some affect on performance. e.g. ssh -oCiphers=arcfour -oMacs=hmac-md5-96 yourhost HMAC-MD5 is also a little faster than HMAC-SHA1. -d From fcusack at fcusack.com Thu Jan 31 13:11:50 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 18:11:50 -0800 Subject: X.509 support in ssh (revisited) In-Reply-To: <20020123120434.W27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Jan 23, 2002 at 12:04:36PM -0500 References: <20020123163056.22889.qmail@itchy.demag.rwth-aachen.de> <20020123120434.W27398@sm2p1386swk.wdr.com> Message-ID: <20020130181150.H29096@google.com> Took me a few days to catch up on this dying thread, sorry to bring it into "mostly dead" state. :-) mm.. MLT X.509 support would be very useful for a site like mine, where I have many thousands of hosts and want an option besides GSS-API/krb5. I don't want to (necessarily) depend on the KDC being online; and am comfortable disting a CRL at some interval. /fc From tim at multitalents.net Thu Jan 31 13:32:34 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 30 Jan 2002 18:32:34 -0800 (PST) Subject: locked account accessable via pubkey auth In-Reply-To: <20020130160050.T29096@google.com> Message-ID: On Wed, 30 Jan 2002, Frank Cusack wrote: > On Wed, Jan 30, 2002 at 03:39:38PM +1100, Damien Miller wrote: > > On Tue, 29 Jan 2002, Frank Cusack wrote: > > > > > On Tue, Jan 29, 2002 at 08:48:51AM -0600, Albert Chin wrote: > > > > On Tue, Jan 29, 2002 at 12:56:55PM +0100, Dost, Alexander wrote: > > > > > maybe this is a silly question ;-) But why is it possible to login on a > > > > > machine with a locked account (passwd -l ) via pubkey-authentication > > > > > (authorized_keys) ? > > > > > > huh.. This is definitely a bug; probably in the Solaris PAM libs. I can > > > look into this, unfortunately not within a day or so. > > > > I don't think it is a bug even. Having accounts with locked passwords, but > > still accessible via pubkey auth is a very useful thing. > > I agree, that is useful, but whether or not it's a bug depends on the meaning > of 'passwd -l'. SUSv2 does not define the passwd command, so I guess this > is implementation-dependent. > > On Solaris 8, passwd(8) says -l "Locks password entry for _name_". It does > not say that it locks the *account*. So this would seem to be consistent > with pubkey auth still being allowed. Even so, I would tend to think it > should lock the "account". I don't know if this list is a good place for > it, but personally I would be interested in hearing arguments for either. > > Can someone report on what the HP-UX man page says? I'd also be interested > to see the man page for HP-UX getspent(). (Another email in this thread > says HP-UX prevents pubkey auth after 'passwd -l'.) I don't have HP-UX but here are a few other platforms. SCO -l Lock user name out of the system by applying an administrative lock; only system administrators may do this and they must specify name. -u Remove any administrative lock applied to user name; only sys- tem administrators may do this and they must specify name. Caldera OpenLinux 3.1 Account maintenance User accounts may be locked and unlocked with the -l and -u flags. The -l option disables an account by changing the password to a value which matches no possible encrypted value. The -u option re-enables an account by changing the password back to its previous value. The -d option deletes the password of an account (be careful). UnixWare/OpenUnix -l Lock the password entry for login_name. > > /fc > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fcusack at fcusack.com Thu Jan 31 14:19:22 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 30 Jan 2002 19:19:22 -0800 Subject: locked account accessable via pubkey auth In-Reply-To: ; from tim@multitalents.net on Wed, Jan 30, 2002 at 06:32:34PM -0800 References: <20020130160050.T29096@google.com> Message-ID: <20020130191922.U29096@google.com> On Wed, Jan 30, 2002 at 06:32:34PM -0800, Tim Rice wrote: > On Wed, 30 Jan 2002, Frank Cusack wrote: > > Can someone report on what the HP-UX man page says? I'd also be interested > > to see the man page for HP-UX getspent(). (Another email in this thread > > says HP-UX prevents pubkey auth after 'passwd -l'.) > > I don't have HP-UX but here are a few other platforms. > > SCO > Caldera OpenLinux 3.1 > UnixWare/OpenUnix And what does pam_acct_mgmt() return on these platforms after 'passwd -l'? (ie, does sshd w/PAM support still allow pubkey auth) /fc From tim at multitalents.net Thu Jan 31 15:52:08 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 30 Jan 2002 20:52:08 -0800 (PST) Subject: locked account accessable via pubkey auth In-Reply-To: <20020130191922.U29096@google.com> Message-ID: On Wed, 30 Jan 2002, Frank Cusack wrote: > On Wed, Jan 30, 2002 at 06:32:34PM -0800, Tim Rice wrote: > > On Wed, 30 Jan 2002, Frank Cusack wrote: > > > Can someone report on what the HP-UX man page says? I'd also be interested > > > to see the man page for HP-UX getspent(). (Another email in this thread > > > says HP-UX prevents pubkey auth after 'passwd -l'.) > > > > I don't have HP-UX but here are a few other platforms. > > > > SCO > > Caldera OpenLinux 3.1 > > UnixWare/OpenUnix > > And what does pam_acct_mgmt() return on these platforms after 'passwd -l'? > (ie, does sshd w/PAM support still allow pubkey auth) Caldera is the only one that uses PAM. They all allow login with pubkey auth if the password is locked. > > /fc > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Thu Jan 31 16:13:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 16:13:54 +1100 (EST) Subject: [Bug 60] OpenSSH 3.0.2p1 configure script fails on NEXTSTEP Message-ID: <20020131051354.73D3EE957@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=60 tim at multitalents.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From tim at multitalents.net 2002-01-31 16:13 ------- looks like a compiler bug. ....from your config.log > In file included from configure:1351: > confdefs.h:2: parse error at null character .... confdefs.h does indeed get created before any tests. But that is done as part of the autoconf macros and not part of OpenSSH ------- 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 Jan 31 16:37:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 16:37:44 +1100 (EST) Subject: [Bug 45] configure refines a function in skey, which then bombs Message-ID: <20020131053744.8F0ACE957@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=45 ------- Additional Comments From tim at multitalents.net 2002-01-31 16:37 ------- Autoconf uses char (*f) (); in all it's AC_CHECK_FUNC tests. Seems like skey should be fixed. Feel free to provide a patch to autoconf.ac that uses AC_TRY_RUN instead of AC_CHECK_FUNC(skey_keyinfo, ------- 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 Jan 31 16:45:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 16:45:48 +1100 (EST) Subject: [Bug 51] scp fails on linux boxes Message-ID: <20020131054548.771BEE957@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=51 tim at multitalents.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From tim at multitalents.net 2002-01-31 16:45 ------- It works here on RedHat 6.2 Perhaps you need some updates on your linux machine. (ftp://updates.redhat.com) ------- 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 Jan 31 18:37:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 18:37:52 +1100 (EST) Subject: [Bug 88] New: scp for OpenSSH v3.0.2p1 fails to commercial SSH v3.1.0 server (new -t option to SSH's scp) Message-ID: <20020131073752.431A5E957@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=88 Summary: scp for OpenSSH v3.0.2p1 fails to commercial SSH v3.1.0 server (new -t option to SSH's scp) Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: brectanu at naxs.net Not really a bug in OpenSSH, but a OpenSSH scp compatibility issue with SSH v3.1.0. OpenSSH v3.0.2p1 send a 'scp -v -t' command to the SSH v3.1.0 server. The SSH v3.1.0 server's scp command now has a '-t' option to put it into SSH1 compatibility mode. If SSH1 compatibility mode is not installed the transfer fails. SSH v3.1.0 reports: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). lost connection ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From matthew at debian.org Thu Jan 31 20:54:36 2002 From: matthew at debian.org (Matthew Vernon) Date: 31 Jan 2002 09:54:36 +0000 Subject: [Bug 83] New: fork() fails when there are PAM limits set In-Reply-To: bugzilla-daemon@mindrot.org's message of Tue, 29 Jan 2002 13:32:01 GMT References: <20020129124728.9B200EA54@shitei.mindrot.org> Message-ID: <5b4rl23kwz.fsf@chiark.greenend.org.uk> bugzilla-daemon at mindrot.org writes: > The problem is, when you set some resource limits in /etc/security/limits.conf > for group X - nproc 20 ( maximum of running user processes - 20 ), and try to > log with some user with group X, sshd says 'fork failed - resource temporary > unavialable'. There are no other processes running for this user, and as far as > i've seen, it makes something like authenticate-set limits-fork()-setuid() , and > because there is a moment when it's running under root with really lowered > limits, it bombs out. > Any solutions? My understanding of this is that it's a result of a fundamental mis-design of PAM - you have to do the entire PAM conversation in one go (as root), so this sort of PAM-based limiting is always going to be prone to this sort of error. Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From bugzilla-daemon at mindrot.org Thu Jan 31 21:16:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:16:52 +1100 (EST) Subject: [Bug 89] New: [PATCH] make the Waiting for forwarded connections to terminate... message more helpful Message-ID: <20020131101652.A2E56EB8A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=89 Summary: [PATCH] make the Waiting for forwarded connections to terminate... message more helpful Product: Portable OpenSSH Version: 3.0p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: matthew at debian.org CC: openssh-unix-dev at mindrot.org Hi, The following patch makes this message a bit more helpful to the less experienced user. diff -u -r openssh-3.0p1-orig/serverloop.c openssh-3.0p1/serverloop.c --- openssh-3.0p1-orig/serverloop.c Fri Oct 12 02:35:06 2001 +++ openssh-3.0p1/serverloop.c Thu Nov 8 18:12:10 2001 @@ -557,7 +557,7 @@ if (!channel_still_open()) break; if (!waiting_termination) { - const char *s = "Waiting for forwarded connectio ns to terminate...\r\n"; + const char *s = "Waiting for forwarded connectio ns to terminate... (press ~& to background)\r\n"; char *cp; waiting_termination = 1; buffer_append(&stderr_buffer, s, strlen(s)); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. From fcusack at fcusack.com Thu Jan 31 21:11:13 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 31 Jan 2002 02:11:13 -0800 Subject: [Bug 83] New: fork() fails when there are PAM limits set In-Reply-To: <5b4rl23kwz.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Thu, Jan 31, 2002 at 09:54:36AM +0000 References: <20020129124728.9B200EA54@shitei.mindrot.org> <5b4rl23kwz.fsf@chiark.greenend.org.uk> Message-ID: <20020131021112.A32485@google.com> On Thu, Jan 31, 2002 at 09:54:36AM +0000, Matthew Vernon wrote: > bugzilla-daemon at mindrot.org writes: > > > The problem is, when you set some resource limits in /etc/security/limits.conf > > for group X - nproc 20 ( maximum of running user processes - 20 ), and try to > > log with some user with group X, sshd says 'fork failed - resource temporary > > unavialable'. There are no other processes running for this user, and as far as > > i've seen, it makes something like authenticate-set limits-fork()-setuid() , and > > because there is a moment when it's running under root with really lowered > > limits, it bombs out. > > Any solutions? > > My understanding of this is that it's a result of a fundamental > mis-design of PAM - you have to do the entire PAM conversation in one > go (as root), so this sort of PAM-based limiting is always going to be > prone to this sort of error. I don't see how this is a problem with PAM? You do have to do the entire conversation in one go, but not as root (other than a possible requirement for access to some resources like /etc/shadow -- but, eg, with krb5 you MUST NOT be root when doing PAM auth). Regardless, why would PAM trip up here, and why would the conversation matter? Limits such as described would not be managed during pam_authenticate() (when the conversation happens). Perhaps I am not familiar enough with nuances of debian's PAM implementation. /fc From bugzilla-daemon at mindrot.org Thu Jan 31 21:22:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:22:06 +1100 (EST) Subject: [Bug 90] New: [PATCH] Make the quiet options behave consistently Message-ID: <20020131102206.5EF54EB8A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=90 Summary: [PATCH] Make the quiet options behave consistently Product: Portable OpenSSH Version: 3.0.2p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: matthew at debian.org This makes the quiet options behave in a more consistent way, and documents that behaviour accurately ------- 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 Jan 31 21:23:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:23:47 +1100 (EST) Subject: [Bug 90] [PATCH] Make the quiet options behave consistently Message-ID: <20020131102347.4133DEB97@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=90 ------- Additional Comments From matthew at debian.org 2002-01-31 21:23 ------- Created an attachment (id=13) quiet options 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 Jan 31 21:29:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:29:30 +1100 (EST) Subject: [Bug 91] New: timeout patches Message-ID: <20020131102930.99ADAEB9B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=91 Summary: timeout patches Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: matthew at debian.org This patch provides protocol-level timeouts, and a timeout for the banner-exchange 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 Thu Jan 31 21:31:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:31:44 +1100 (EST) Subject: [Bug 91] timeout patches Message-ID: <20020131103144.2EB5CEBA3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=91 ------- Additional Comments From matthew at debian.org 2002-01-31 21:31 ------- Created an attachment (id=14) timeout patches (work by Ian Jackson and Matthew Vernon) ------- 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 Jan 31 21:46:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:46:29 +1100 (EST) Subject: [Bug 83] fork() fails when there are PAM limits set Message-ID: <20020131104629.E687EEBA7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=83 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.0.2p1 |-current ------- Additional Comments From djm at mindrot.org 2002-01-31 21:46 ------- I'm putting some replies from the openssh-unix-dev mailing list into the bug so we capture the history in one place. On Thu, 2002-01-31 at 21:11, Frank Cusack wrote: > On Thu, Jan 31, 2002 at 09:54:36AM +0000, Matthew Vernon wrote: > > My understanding of this is that it's a result of a fundamental > > mis-design of PAM - you have to do the entire PAM conversation in one > > go (as root), so this sort of PAM-based limiting is always going to be > > prone to this sort of error. > > I don't see how this is a problem with PAM? You do have to do the > entire conversation in one go, but not as root (other than a possible > requirement for access to some resources like /etc/shadow -- but, eg, > with krb5 you MUST NOT be root when doing PAM auth). Regardless, why > would PAM trip up here, and why would the conversation matter? Limits > such as described would not be managed during pam_authenticate() (when the > conversation happens). Perhaps I am not familiar enough with nuances > of debian's PAM implementation. The problem is that we call pam_session as root, before we fork the child. Therefore the server picks up the limits, rather than the child. I recall that we tried moving the pam_session call to the child a while (~18 months) ago to avoid this problem, but other stuff broke much worse. IIRC the breakage was because we did pam_session stuff in one process (as non-root) and then did cleanup in another process (as root). A possible way around this is with a gratuitous fork() before we call pam_session, but that is pretty ugly. ------- 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 Jan 31 21:51:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 21:51:27 +1100 (EST) Subject: [Bug 91] timeout patches Message-ID: <20020131105127.58EF3EBE5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=91 ------- Additional Comments From djm at mindrot.org 2002-01-31 21:51 ------- 1. This should really be two patches - protocol keepalives are a very different beast to connection timeouts. 2. Connection/read timeouts should use select() rather then alarm()+blocking ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Thu Jan 31 22:09:10 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 31 Jan 2002 12:09:10 +0100 Subject: x509 for hostkeys. Message-ID: <20020131120909.A28305@folly> This (very quick) patch allows you to connect with the commercial ssh.com windows client and use x509 certs for hostkeys. You have to import your CA cert (ca.crt) in the windows client and certify your hostkey: $ cat << 'EOF' > x509v3.cnf CERTPATHLEN = 1 CERTUSAGE = digitalSignature,keyCertSign CERTIP = 0.0.0.0 [x509v3_CA] basicConstraints=critical,CA:true,pathlen:$ENV::CERTPATHLEN keyUsage=$ENV::CERTUSAGE [x509v3_IPAddr] subjectAltName=IP:$ENV::CERTIP [x509v3_DNSName] subjectAltName=DNS:$ENV::CERTDNS EOF $ CERTDNS=myipaddr; export CERTDNS $ openssl req -new -key /etc/ssh_host_rsa_key -out HOSTKEY.csr $ openssl x509 -req -days 365 -in HOSTKEY.csr -CA ca.crt \ -CAkey ca.key -CAcreateserial \ -extfile x509v3.cnf -extensions x509v3_DNSName \ -out HOSTKEY.crt $ umask 077 $ cat /etc/ssh_host_rsa_key HOSTKEY.crt > /etc/ssh_host_rsa_key+cert $ echo HostKey /etc/ssh_host_rsa_key+cert > sshd_config-test $ sudo sshd -p 2222 -ddd -f sshd_config-test Index: authfile.c =================================================================== RCS file: /home/markus/cvs/ssh/authfile.c,v retrieving revision 1.45 diff -u -r1.45 authfile.c --- authfile.c 29 Dec 2001 21:56:01 -0000 1.45 +++ authfile.c 31 Jan 2002 10:50:53 -0000 @@ -460,6 +460,24 @@ error("PEM_read_PrivateKey: mismatch or " "unknown EVP_PKEY save_type %d", pk->save_type); } + if (prv != NULL) { + /* try to get a certificate if we have the private key */ + prv->x509 = PEM_read_X509(fp, NULL, NULL, (char *)passphrase); + if (prv->x509 != NULL) { + debug("PEM_read_X509"); +#ifdef DEBUG_X509 + X509_print_fp(stdout, prv->x509); + { + EVP_PKEY *pkey = X509_get_pubkey(prv->x509); + if (pkey->type == EVP_PKEY_RSA) { + debug("PEM_read_X509 -> RSA"); + } else if (pkey->type == EVP_PKEY_DSA) { + debug("PEM_read_X509 -> DSA"); + } + } +#endif + } + } fclose(fp); if (pk != NULL) EVP_PKEY_free(pk); Index: key.c =================================================================== RCS file: /home/markus/cvs/ssh/key.c,v retrieving revision 1.39 diff -u -r1.39 key.c --- key.c 25 Jan 2002 22:07:40 -0000 1.39 +++ key.c 31 Jan 2002 10:26:53 -0000 @@ -53,10 +53,12 @@ RSA *rsa; DSA *dsa; k = xmalloc(sizeof(*k)); + memset(k, 0, sizeof(*k)); k->type = type; k->flags = 0; k->dsa = NULL; k->rsa = NULL; + k->x509 = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -141,6 +143,10 @@ fatal("key_free: bad key type %d", k->type); break; } + if (k->x509 != NULL) { + X509_free(k->x509); + k->x509 = NULL; + } xfree(k); } int @@ -538,6 +544,8 @@ { switch (k->type) { case KEY_RSA: + if (k->x509) + return "x509v3-sign-rsa"; return "ssh-rsa"; break; case KEY_DSA: @@ -641,6 +649,10 @@ return KEY_RSA; } else if (strcmp(name, "ssh-dss") == 0) { return KEY_DSA; + } else if (strcmp(name, "x509v3-sign-rsa") == 0) { + return KEY_RSA; + } else if (strcmp(name, "x509v3-sign-dss") == 0) { + return KEY_DSA; } debug2("key_type_from_name: unknown key type '%s'", name); return KEY_UNSPEC; @@ -739,9 +751,16 @@ buffer_put_bignum2(&b, key->dsa->pub_key); break; case KEY_RSA: - buffer_put_cstring(&b, key_ssh_name(key)); - buffer_put_bignum2(&b, key->rsa->e); - buffer_put_bignum2(&b, key->rsa->n); + if (key->x509) { + /* XXX ssh.com does not accept a key name here */ + len = i2d_X509(key->x509, NULL); + buf = buffer_append_space(&b, len); + i2d_X509(key->x509, &buf); + } else { + buffer_put_cstring(&b, key_ssh_name(key)); + buffer_put_bignum2(&b, key->rsa->e); + buffer_put_bignum2(&b, key->rsa->n); + } break; default: error("key_to_blob: unsupported key type %d", key->type); Index: key.h =================================================================== RCS file: /home/markus/cvs/ssh/key.h,v retrieving revision 1.17 diff -u -r1.17 key.h --- key.h 17 Sep 2001 19:27:15 -0000 1.17 +++ key.h 30 Jan 2002 15:23:11 -0000 @@ -28,6 +28,7 @@ #include #include +#include typedef struct Key Key; enum types { @@ -53,6 +54,7 @@ int flags; RSA *rsa; DSA *dsa; + X509 *x509; }; Key *key_new(int); Index: ssh-rsa.c =================================================================== RCS file: /home/markus/cvs/ssh/ssh-rsa.c,v retrieving revision 1.15 diff -u -r1.15 ssh-rsa.c --- ssh-rsa.c 25 Jan 2002 21:42:11 -0000 1.15 +++ ssh-rsa.c 31 Jan 2002 09:23:53 -0000 @@ -91,7 +91,11 @@ } /* encode signature */ buffer_init(&b); +#if 0 buffer_put_cstring(&b, "ssh-rsa"); +#else + buffer_put_cstring(&b, key_ssh_name(key)); +#endif buffer_put_string(&b, sig, slen); len = buffer_len(&b); ret = xmalloc(len); From bugzilla-daemon at mindrot.org Thu Jan 31 22:53:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 22:53:22 +1100 (EST) Subject: [Bug 91] timeout patches Message-ID: <20020131115322.9D21AEBEC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=91 ------- Additional Comments From markus at openbsd.org 2002-01-31 22:53 ------- please try to have one feature per patch. 1. as to protocolkeepalive: isn't this what tcp-keepalives are for? 2. why use sigaction? sshd does a similar thing, but just uses alarm() 3. why not wrap exchange_indentification into alarm, like sshd does? 4. not all ssh1 implementations will accept your ignore message ------- 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 Jan 31 22:54:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 22:54:24 +1100 (EST) Subject: [Bug 60] OpenSSH 3.0.2p1 configure script fails on NEXTSTEP Message-ID: <20020131115424.DD5F3EBEC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=60 abe at purdue.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From abe at purdue.edu 2002-01-31 22:54 ------- tim at multitalents.net says: > > confdefs.h does indeed get created before any tests. > But that is done as part of the autoconf macros and not part > of OpenSSH As distributed openssh-3.0.2p1.tar.gz contains no confdefs.h -- I just checked in a fresh download at 1340Z on January 31, 2002. If you type "./configure" out of the box as the INSTALL script says, there will be no confdefs.h. ------- 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 Jan 31 22:56:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 22:56:28 +1100 (EST) Subject: [Bug 90] [PATCH] Make the quiet options behave consistently Message-ID: <20020131115628.62902EBEC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=90 ------- Additional Comments From markus at openbsd.org 2002-01-31 22:56 ------- fine, but LogLevel updates are missing from the manpage dif. ------- 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 Jan 31 23:02:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 23:02:11 +1100 (EST) Subject: [Bug 88] scp for OpenSSH v3.0.2p1 fails to commercial SSH v3.1.0 server (new -t option to SSH's scp) Message-ID: <20020131120211.B52BDEBF7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=88 ------- Additional Comments From markus at openbsd.org 2002-01-31 23:01 ------- this is an installation error on the target host, see: scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). ------- 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 Jan 31 23:27:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 31 Jan 2002 23:27:43 +1100 (EST) Subject: [Bug 60] OpenSSH 3.0.2p1 configure script fails on NEXTSTEP Message-ID: <20020131122743.2B475EBF4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=60 ------- Additional Comments From djm at mindrot.org 2002-01-31 23:27 ------- We're not supposed to ship a confdefs.h file. It is configure's job to create it. This seems to be an autoconf bug. Could someone who is affected by this problem please raise a bug with the autoconf developers? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Jason.Lacoss-Arnold at AGEDWARDS.com Thu Jan 31 23:53:32 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Thu, 31 Jan 2002 06:53:32 -0600 Subject: [Bug 89] New: [PATCH] make the Waiting for forwarded connecti ons to terminate... message more helpful Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E515@hqempn06.agedwards.com> Shouldn't that acutally pull the value of EscapeChar out of the users environment (and possibly default to the old message if they don't have one defined at all)? Thanks, --Jason Lacoss-Arnold, Systems Technical Specialist Technical Services - Unix Arch. 314-955-8501 -----Original Message----- From: bugzilla-daemon at mindrot.org [mailto:bugzilla-daemon at mindrot.org] Sent: Thursday, January 31, 2002 4:17 To: openssh-unix-dev at mindrot.org Subject: [Bug 89] New: [PATCH] make the Waiting for forwarded connections to terminate... message more helpful http://bugzilla.mindrot.org/show_bug.cgi?id=89 Summary: [PATCH] make the Waiting for forwarded connections to terminate... message more helpful Product: Portable OpenSSH Version: 3.0p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: matthew at debian.org CC: openssh-unix-dev at mindrot.org Hi, The following patch makes this message a bit more helpful to the less experienced user. diff -u -r openssh-3.0p1-orig/serverloop.c openssh-3.0p1/serverloop.c --- openssh-3.0p1-orig/serverloop.c Fri Oct 12 02:35:06 2001 +++ openssh-3.0p1/serverloop.c Thu Nov 8 18:12:10 2001 @@ -557,7 +557,7 @@ if (!channel_still_open()) break; if (!waiting_termination) { - const char *s = "Waiting for forwarded connectio ns to terminate...\r\n"; + const char *s = "Waiting for forwarded connectio ns to terminate... (press ~& to background)\r\n"; char *cp; waiting_termination = 1; buffer_append(&stderr_buffer, s, strlen(s)); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************** WARNING: All e-mail sent to and from this address will be received or otherwise recorded by the A.G. Edwards corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020131/624a8876/attachment.html