From mouring at etoh.eviladmin.org Fri Mar 1 01:56:00 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 28 Feb 2002 08:56:00 -0600 (CST) Subject: Update to solaris package creation Message-ID: Can someone else from the Solaris realm that uses our package system verify that this should be done? It looks right, but I want another opinion before commiting. - Ben > On Wed, 27 Feb 2002, Antonio Navarro wrote: > >> Hi Ben, >> >> I have made some modifications to the buildpkg.sh script that is >> distributed with openssh. >> >> I am sending it to you in case you find my modification useful. >> >> BTW, nice script! >> >> The modifications are: >> - the rc?.d scripts are hard links not soft links >> - removed one of the BASEDIR entries in the pkginfo >> - modified the awk script that filters the prototype so that the system >> directories are marked as shared (using ? for permissions, owner and group) >> >> that's more or less about it. --- buildpkg.sh.orig Fri Oct 19 15:36:24 2001 +++ buildpkg.sh Thu Feb 28 08:50:09 2002 @@ -42,10 +42,10 @@ ../opensshd.in > $FAKE_ROOT/etc/init.d/opensshd chmod 711 $FAKE_ROOT/etc/init.d/opensshd -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc0.d/K30opensshd -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc0.d/K30opensshd +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd ## Ok, this is outright wrong, but it will work. I'm tired of pkgmk @@ -61,7 +61,6 @@ NAME=OpenSSH Portable for Solaris DESC="Secure Shell remote access utility; replaces telnet and rlogin/rsh." VENDOR="OpenSSH Portable Team - http://www.openssh.com/portable.html" -BASEDIR=$FAKE_ROOT ARCH=$ARCH VERSION=$VERSION CATEGORY=Security @@ -72,9 +71,15 @@ echo "Building prototype file..." find . | egrep -v "prototype|pkginfo" | sort | pkgproto $PROTO_ARGS | \ awk ' - BEGIN { print "i pkginfo" } - { $5="root"; $6="sys"; } - { print; }' > prototype + BEGIN { print "i pkginfo"; \ + split("/opt /etc /etc/init.d /etc/rcS.d /etc/rd0.d /etc/rc1.d /etc/rc2.d",sys_files); } + { + for (dir in sys_files) { if ( $3 != sys_files[dir] ) + { $5="root"; $6="sys"; } + else + { $4="?"; $5="?"; $6="?"; break;} + } } + { print; }' > prototype ## Step back a directory and now build the package. echo "Building package.." From mouring at etoh.eviladmin.org Fri Mar 1 01:57:10 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 28 Feb 2002 08:57:10 -0600 (CST) Subject: UseLogin under AIX 4.3.3 In-Reply-To: Message-ID: This is under -current and under 3.0.2p1? - Ben On Thu, 28 Feb 2002, Manton, Doug wrote: > Hi, > > If I enable "UseLogin" under AIX, I get the following message upon > login: > > /dev/pts/2: 3004-004 You must "exec" login from the lowest login > shell. > > The manpage states: > > "In order to preserve the integrity of the system, only one session at a > time is > allowed to be logged in to a port. This means that the login command > entered > from the shell prompt cannot succeed, as both the original session and > the new > login session would be on the same port. However, the exec login command > succeeds because a new shell replaces the current one. The login command > is > typically a built-in shell command, causing the shell to replace > itself." > > Any ideas how I could fix this? I wouldn't usually enable this option, > but I am trying to PD a problem on a system that will not trust a user > account that comes in via SSH and I am hoping that using login will > solve the problem. > > Many thanks, > > Doug Manton, AT&T Business Commercial Security > > From markus at openbsd.org Fri Mar 1 01:56:31 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 28 Feb 2002 15:56:31 +0100 Subject: ssh1 vs ssh2 speed (Re: Call for testing.) In-Reply-To: <20020226150515.G28221@greenie.muc.de>; from gert@greenie.muc.de on Tue, Feb 26, 2002 at 03:05:15PM +0100 References: <20020222184742.GB24557@faui02> <20020226135212.F28221@greenie.muc.de> <20020226130505.GC10496@faui02> <20020226150515.G28221@greenie.muc.de> Message-ID: <20020228155631.A10421@folly> On Tue, Feb 26, 2002 at 03:05:15PM +0100, Gert Doering wrote: > diff -u -r1.5 Makefile > --- Makefile 22 Feb 2002 12:31:35 -0000 1.5 > +++ Makefile 26 Feb 2002 14:06:21 -0000 > @@ -23,6 +23,10 @@ > rsa-agent rsa-agent.pub rsa1-agent rsa1-agent.pub \ using the script from http://www.monkey.org/~markus/openssh/cipher-speed.sh shows that ssh2 not slower than ssh1 (at least on the machines i tested). test try ciphers: proto 2 cipher 3des-cbc mac hmac-md5 97.40 real 47.00 user 0.93 sys test try ciphers: proto 1 cipher 3des 103.94 real 49.75 user 1.26 sys -m From markus at openbsd.org Fri Mar 1 02:08:41 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 28 Feb 2002 16:08:41 +0100 Subject: OpenSSH and OpenSSL snapshots In-Reply-To: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com>; from Paul-AndrePanon@SierraSystems.com on Mon, Jan 21, 2002 at 04:07:36PM -0800 References: <2417BD0B3A2D5A4086512AD8BDDB1D4E02B08AFE@svvan2000.sierrasys.com> Message-ID: <20020228160841.A18462@folly> On Mon, Jan 21, 2002 at 04:07:36PM -0800, Panon, Paul-Andre wrote: > 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. a recent snapshot from www.openssh.com/portable.html should work with recent openssl (0.9.7) snapshots. From dmanton at emea.att.com Fri Mar 1 03:22:18 2002 From: dmanton at emea.att.com (Manton, Doug) Date: Thu, 28 Feb 2002 16:22:18 -0000 Subject: UseLogin under AIX 4.3.3 Message-ID: > This is under -current and under 3.0.2p1 Yes. A quick test shows it is broken under 2.9, too :-( Here is the output from openssh-SNAP-20020226: # /usr/local/sbin/sshd -p 222 -d -d -d debug3: Seeing PRNG from /usr/local/libexec/ssh-rand-helper debug1: sshd version OpenSSH_3.0.2p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 222 on 0.0.0.0. Server listening on 0.0.0.0 port 222. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 32937 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: list_hostkey_types: ssh-rsa,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-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,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-c bc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,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: 128/256 debug1: bits set: 1609/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1587/3191 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 test service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for test debug2: input_userauth_request: try method none Failed none for test from 127.0.0.1 port 32937 ssh2 debug1: userauth-request for user test 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=test devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for test from 127.0.0.1 port 32937 ssh2 debug1: userauth-request for user test service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Accepted password for test from 127.0.0.1 port 32937 ssh2 debug3: Trying to reverse map address 127.0.0.1. debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/2 debug3: tty_parse_modes: SSH2 n_bytes 251 debug3: tty_parse_modes: ospeed 9600 debug3: tty_parse_modes: ispeed 9600 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 8 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 255 debug3: tty_parse_modes: 7 255 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug3: tty_parse_modes: 11 25 debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 14 22 debug3: tty_parse_modes: 30 0 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 37 0 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 0 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 0 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug3: tty_parse_modes: 52 0 debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 0 debug3: tty_parse_modes: 55 0 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 0 debug3: tty_parse_modes: 60 0 debug3: tty_parse_modes: 61 0 debug3: tty_parse_modes: 62 0 debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 71 0 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell setsid: Not owner debug1: fd 4 setting TCP_NODELAY debug1: channel 0: rfd 9 isatty debug1: fd 9 setting O_NONBLOCK debug2: fd 8 is O_NONBLOCK debug1: Received SIGCHLD. debug1: session_by_pid: pid 7930 debug1: session_exit_message: session 0 channel 0 pid 7930 debug1: channel request 0: exit-status debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed debug1: session_close: session 0 pid 7930 debug1: session_pty_cleanup: session 0 release /dev/pts/2 debug2: notify_done: reading debug1: channel 0: read<=0 rfd 9 len -1 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug1: channel 0: send close debug3: channel 0: will not send data after close debug1: channel 0: rcvd close debug3: channel 0: will not send data after close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: server-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e -1 Connection closed by remote host. Closing connection to 127.0.0.1 # /usr/local/bin/ssh -p 222 -v -v -v test at localhost OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /usr/local/etc/ssh_config debug3: Seeing PRNG from /usr/local/libexec/ssh-rand-helper 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 localhost [127.0.0.1] port 222. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (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/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, 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 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-c bc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,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: 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-c bc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 123/256 debug1: bits set: 1587/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: bits set: 1609/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 debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try privkey: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: try privkey: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: try privkey: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password test at localhost's password: debug1: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 8 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 255 debug3: tty_make_modes: 7 255 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 0 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 0 debug3: tty_make_modes: 55 0 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 0 debug3: tty_make_modes: 60 0 debug3: tty_make_modes: 61 0 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug1: channel request 0: shell debug1: fd 3 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Environment: TZ=GMT0BST,M3.5.0,M10.5.0 SSH_CLIENT=127.0.0.1 32937 222 SSH_TTY=/dev/pts/2 TERM=vt100 AUTHSTATE=compat PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/local/bin LANG=en_GB LOCPATH=/usr/lib/nls/loc NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/en_US/%N:/usr/lib/nls/ms g/%L/%N.cat:/usr/lib/nls/msg/en_US/%N.cat LC__FASTMSG=true ODMDIR=/etc/objrepos DOCUMENT_SERVER_MACHINE_NAME=localhost DOCUMENT_SERVER_PORT=49213 CGI_DIRECTORY=/var/docsearch/cgi-bin DOCUMENT_DIRECTORY=/usr/docsearch/html IMQCONFIGSRV=/etc/IMNSearch IMQCONFIGCL=/etc/IMNSearch/dbcshelp debug3: channel_close_fds: channel 0: r -1 w -1 e -1 /dev/pts/2: 3004-004 You must "exec" login from the lowest login shell. debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: channel 0: rcvd close debug1: channel 0: close_read debug1: channel 0: input open -> closed debug3: channel 0: will not send data after close debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel_close_fds: channel 0: r -1 w -1 e 6 Connection to localhost closed. debug1: Transferred: stdin 0, stdout 0, stderr 33 bytes in 7.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 4.7 debug1: Exit status 1 Hmm... Doug Manton, AT&T Business Commercial Security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2714 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020228/7de7045c/attachment.bin From edgy at us.ibm.com Fri Mar 1 00:42:21 2002 From: edgy at us.ibm.com (Edward Geraghty) Date: Thu, 28 Feb 2002 08:42:21 -0500 Subject: UseLogin under AIX 4.3.3 Message-ID: Hey Doug, This is probably the well known /var/adm/wtmp, /etc/utmp corruption bug. There is a IBM tech note to fix this but basically just backup and clear /var/adm/wtmp and /etc/utmp. This can be done in any method you like "cat /dev/null > filename". Also check to see that your diskspace for / and /var is not filled. I think this problem came about when disk space fills and utmp/wtmp are incompletely written. EdGy "Manton, Doug" @mindrot.org on 02/28/2002 06:49:32 Sent by: openssh-unix-dev-admin at mindrot.org To: openssh-unix-dev at mindrot.org cc: Subject: UseLogin under AIX 4.3.3 Hi, If I enable "UseLogin" under AIX, I get the following message upon login: ? /dev/pts/2: 3004-004 You must "exec" login from the lowest login shell. The manpage states: "In order to preserve the integrity of the system, only one session at a time is allowed to be logged in to a port. This means that the login command entered from the shell prompt cannot succeed, as both the original session and the new login session would be on the same port. However, the exec login command succeeds because a new shell replaces the current one. The login command is typically a built-in shell command, causing the shell to replace itself." Any ideas how I could fix this?? I wouldn't usually enable this option, but I am trying to PD a problem on a system that will not trust a user account that comes in via SSH and I am hoping that using login will solve the problem. Many thanks, Doug Manton, AT&T Business Commercial Security From tim at multitalents.net Fri Mar 1 03:53:20 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 28 Feb 2002 08:53:20 -0800 (PST) Subject: Update to solaris package creation In-Reply-To: Message-ID: On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > Can someone else from the Solaris realm that uses our package system > verify that this should be done? It looks right, but I want > another opinion before commiting. I'm working on some changes to the packing script. I'll check this out. [snip] > >> The modifications are: > >> - the rc?.d scripts are hard links not soft links I prefer hard links too. Anyone else vote for this? > >> - removed one of the BASEDIR entries in the pkginfo I had allready caught that. > >> - modified the awk script that filters the prototype so that the system > >> directories are marked as shared (using ? for permissions, owner and group) Cool. I was still working on that part. > >> > >> that's more or less about it. > > --- buildpkg.sh.orig Fri Oct 19 15:36:24 2001 > +++ buildpkg.sh Thu Feb 28 08:50:09 2002 > @@ -42,10 +42,10 @@ > ../opensshd.in > $FAKE_ROOT/etc/init.d/opensshd > chmod 711 $FAKE_ROOT/etc/init.d/opensshd > > -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd > -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc0.d/K30opensshd > -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd > -ln -s ../init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd > +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rcS.d/K30opensshd > +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc0.d/K30opensshd > +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc1.d/K30opensshd > +ln $FAKE_ROOT/etc/init.d/opensshd $FAKE_ROOT/etc/rc2.d/S98opensshd > > > ## Ok, this is outright wrong, but it will work. I'm tired of pkgmk > @@ -61,7 +61,6 @@ > NAME=OpenSSH Portable for Solaris > DESC="Secure Shell remote access utility; replaces telnet and rlogin/rsh." > VENDOR="OpenSSH Portable Team - http://www.openssh.com/portable.html" > -BASEDIR=$FAKE_ROOT > ARCH=$ARCH > VERSION=$VERSION > CATEGORY=Security > @@ -72,9 +71,15 @@ > echo "Building prototype file..." > find . | egrep -v "prototype|pkginfo" | sort | pkgproto $PROTO_ARGS | \ > awk ' > - BEGIN { print "i pkginfo" } > - { $5="root"; $6="sys"; } > - { print; }' > prototype > + BEGIN { print "i pkginfo"; \ > + split("/opt /etc /etc/init.d /etc/rcS.d /etc/rd0.d /etc/rc1.d /etc/rc2.d",sys_files); } > + { > + for (dir in sys_files) { if ( $3 != sys_files[dir] ) > + { $5="root"; $6="sys"; } > + else > + { $4="?"; $5="?"; $6="?"; break;} > + } } > + { print; }' > prototype > > ## Step back a directory and now build the package. > echo "Building package.." > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From fcusack at fcusack.com Fri Mar 1 04:06:58 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 28 Feb 2002 09:06:58 -0800 Subject: Update to solaris package creation In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Feb 28, 2002 at 08:56:00AM -0600 References: Message-ID: <20020228090658.D8884@google.com> On Thu, Feb 28, 2002 at 08:56:00AM -0600, Ben Lindstrom wrote: > > Can someone else from the Solaris realm that uses our package system > verify that this should be done? It looks right, but I want > another opinion before commiting. > > - Ben > > > On Wed, 27 Feb 2002, Antonio Navarro wrote: > >> > >> The modifications are: > >> - the rc?.d scripts are hard links not soft links yep, that's the norm on solaris > >> - removed one of the BASEDIR entries in the pkginfo yep, that shouldn't be there > >> - modified the awk script that filters the prototype so that the system > >> directories are marked as shared (using ? for permissions, owner and group) good /fc From mouring at etoh.eviladmin.org Fri Mar 1 03:25:57 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 28 Feb 2002 10:25:57 -0600 (CST) Subject: Update to solaris package creation In-Reply-To: Message-ID: On Thu, 28 Feb 2002, Tim Rice wrote: > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > > > Can someone else from the Solaris realm that uses our package system > > verify that this should be done? It looks right, but I want > > another opinion before commiting. > > I'm working on some changes to the packing script. I'll check this out. > I assume your generalizing this to SCO? Please send me the patches before commit them if you are so I can test under solaris. - Ben From peterw at usa.net Fri Mar 1 04:18:39 2002 From: peterw at usa.net (Peter Watkins) Date: Thu, 28 Feb 2002 12:18:39 -0500 Subject: Update to solaris package creation (init script links) In-Reply-To: ; from tim@multitalents.net on Thu, Feb 28, 2002 at 08:53:20AM -0800 References: Message-ID: <20020228121839.C31570@usa.net> On Thu, Feb 28, 2002 at 08:53:20AM -0800, Tim Rice wrote: > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > [snip] > > >> The modifications are: > > >> - the rc?.d scripts are hard links not soft links > > I prefer hard links too. Anyone else vote for this? I generally prefer soft links -- it seems odd that after cd /etc/init.d; mv foo foo.old; mv foo.new foo you'd still have the old script executed. But hard links are what Sun uses for its SysV S/K entities, so I see the logic. Basically I don't like how Sun does it, but understand the logic of OpenSSH behaving in the same manner as the OS vendor; that's probably the better way to behave, for consistency's sake. :-( -Peter From mouring at etoh.eviladmin.org Fri Mar 1 03:46:02 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 28 Feb 2002 10:46:02 -0600 (CST) Subject: Update to solaris package creation (init script links) In-Reply-To: <20020228121839.C31570@usa.net> Message-ID: On Thu, 28 Feb 2002, Peter Watkins wrote: > On Thu, Feb 28, 2002 at 08:53:20AM -0800, Tim Rice wrote: > > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > [snip] > > > >> The modifications are: > > > >> - the rc?.d scripts are hard links not soft links > > > > I prefer hard links too. Anyone else vote for this? > > I generally prefer soft links -- it seems odd that after > cd /etc/init.d; mv foo foo.old; mv foo.new foo > you'd still have the old script executed. But hard links are what > Sun uses for its SysV S/K entities, so I see the logic. Basically > I don't like how Sun does it, but understand the logic of OpenSSH > behaving in the same manner as the OS vendor; that's probably the > better way to behave, for consistency's sake. :-( > I tend to agree personally which is why I used soft links to start with. But I think that the behavior of the OS Vendor should be honored even if it runs against my grain. =) - Ben From d-b at home.se Fri Mar 1 04:46:34 2002 From: d-b at home.se (Daniel Bergman) Date: Thu, 28 Feb 2002 18:46:34 +0100 Subject: Update to solaris package creation (init script links) In-Reply-To: <20020228121839.C31570@usa.net> References: <20020228121839.C31570@usa.net> Message-ID: <159256418.1014921994@localhost> I agree with you, even though I prefer soft-link I think one should follow the Sun way for consistency. But I have to admit - I do create soft symlinks for my own RC-scripts ,-) Regards, Daniel > On Thu, Feb 28, 2002 at 08:53:20AM -0800, Tim Rice wrote: >> On Thu, 28 Feb 2002, Ben Lindstrom wrote: > >> [snip] >> > >> The modifications are: >> > >> - the rc?.d scripts are hard links not soft links >> >> I prefer hard links too. Anyone else vote for this? > > I generally prefer soft links -- it seems odd that after > cd /etc/init.d; mv foo foo.old; mv foo.new foo > you'd still have the old script executed. But hard links are what > Sun uses for its SysV S/K entities, so I see the logic. Basically > I don't like how Sun does it, but understand the logic of OpenSSH > behaving in the same manner as the OS vendor; that's probably the > better way to behave, for consistency's sake. :-( > > -Peter > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Daniel Bergman Phone: 08 - 55066265 Mobile: 070 - 289 30 39 Fax: 08 - 59827056 Email: d-b at home.se From tom at avatar.itc.nrcs.usda.gov Fri Mar 1 04:45:20 2002 From: tom at avatar.itc.nrcs.usda.gov (Tom Rudnick) Date: Thu, 28 Feb 2002 10:45:20 -0700 (MST) Subject: Can't untar snapshot.. scard missing from CVS? Message-ID: <200202281745.KAA11425@avatar.itc.nrcs.usda.gov> Hello- I'm testing the current versions on UnixWare 2.x and have run into the following problems: After downloading the nightly snapshot, untar fails with "Directory Checksum error". Gunzip is successful, but the tar fails. Failing the snapshot extraction, I checked out a clean copy from the CVS. Configure fails when it hits the "/scard" directory, which is empty. I touched "/scard/Makefile.in", and configure then ran to completion. So, two things... 1. Is there a blocksize option on tar when the snapshots were created? My extract command is: gzcat openssh-SNAP-20020228.tar.gz | tar xvof - Separately unzipping and untarring gives the same error. 2. Is the /scard stuff missing from the CVS? I think I saw something about this on the list previously, so forgive my faulty memory. I'm very pleased with OpenSSH 3.0.2, and am glad to contribute to testing on my platforms. -Tom Rudnick -- ----------------/---------------------------------------------- Tom Rudnick | USDA Natural Resources Conservation Service Fort Collins,CO | tom at avatar.itc.nrcs.usda.gov (970) 295-5427 ** The 3rd Millennium started Jan 1, 2001. see: ** ** http://aa.usno.navy.mil/AA/faq/docs/millennium.html ** -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From tim at multitalents.net Fri Mar 1 05:32:27 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 28 Feb 2002 10:32:27 -0800 (PST) Subject: Update to solaris package creation In-Reply-To: Message-ID: On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > On Thu, 28 Feb 2002, Tim Rice wrote: > > > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > > > > > > Can someone else from the Solaris realm that uses our package system > > > verify that this should be done? It looks right, but I want > > > another opinion before commiting. > > > > I'm working on some changes to the packing script. I'll check this out. > > > I assume your generalizing this to SCO? Please send me the > patches before commit them if you are so I can test under > solaris. Not SCO really but any SVR4/SVR5 based system. Mostly I want it to work outside of the source tree. I'll have it tested on Solaris 7 & 8, and 4 versions of UnixWare/OpenUNIX before I send it along. > > - Ben > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Fri Mar 1 05:55:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 1 Mar 2002 05:55:10 +1100 (EST) Subject: [Bug 130] New: segfault on connect / Red Hat 6.1 w/OpenSSL 0.9.6c Message-ID: <20020228185510.22F63E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=130 Summary: segfault on connect / Red Hat 6.1 w/OpenSSL 0.9.6c Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jon at xisp.net The client segfaults and I'm afraid the server is doing the same thing since it dies when I try to connect. I just built openssl 0.9.6c, which appears to be the most recent version, and it passed the 'make test' routines, so that appears not to be the problem. It's an old Red Hat 6.1 box that's on-site and thus can't be replaced or safely upgraded. [root at andromeda openssh-3.0.2p1]# gdb ./ssh GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run -v jon at leapfrog.baltimorons.org Starting program: /usr/src/openssh-3.0.2p1/./ssh -v jon at leapfrog.baltimorons.org which: no vim in +(/usr/local/bin::/usr/bin:/bin:/usr/games:/usr/X11R6/bin:/usr/local/games:/usr/ +sbin:/sbin:) OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /etc/ssh/ssh_config 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 leapfrog.baltimorons.org [216.181.177.189] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (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/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, 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 Program received signal SIGSEGV, Segmentation fault. buffer_get (buffer=0x101e6be4, buf=0xbffff870 "\201i\005\b\214???#g\005\b?k\036\020", len=4) at buffer.c:114 114 if (len > buffer->end - buffer->offset) (gdb) quit The program is running. Exit anyway? (y or n) y ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bill.taylor at esker.com Fri Mar 1 06:24:46 2002 From: bill.taylor at esker.com (Taylor, Bill) Date: Thu, 28 Feb 2002 13:24:46 -0600 Subject: Packet sizes from ssh 2 session, ssh 1 session and telnet Message-ID: I have built an emulation connection method which uses ssh 1 or 2 connections. We have a speed problem and it seems the way I have done things a simple "ps -ax" result will be a number of 40-80 byte packets from ssh 2, a number of about 250 byte packets in ssh 1 and telnet sends about 1000 byte chunks. Did I set the sessions up wrong? Is this configurable somehow? When I did a ssh -2 host from an openssh 3.0.2 system to another one the behaviour seemed similar as with my midified code base. ???? Bill Taylor 608-219-4430 From mjt at tls.msk.ru Fri Mar 1 08:15:02 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Fri, 01 Mar 2002 00:15:02 +0300 Subject: PATCH: nroff detection wrong, by default uses mantype=cat References: Message-ID: <3C7E9DD6.861ABFDC@tls.msk.ru> Pekka Savola wrote: > [] > Please take a look at the configure without a patch: > > --8<-- > for as_dir in /usr/bin:/usr/ucb ^^^^^ > do > IFS=$as_save_IFS ^^^^^^^^^^^^^^^^ I assume that IFS was changed somewhere before this for_loop, and now it is restored to it's original value (why w/o quotes?!). I *suspect* there should be IFS=: right before this loop. If there is no such assignment, it should be autoconf's bug. Regards, Michael. From bugzilla-daemon at mindrot.org Fri Mar 1 08:58:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 1 Mar 2002 08:58:09 +1100 (EST) Subject: [Bug 131] New: Problems with sshd's compiled in default PATH. Message-ID: <20020228215809.0A3C9E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 Summary: Problems with sshd's compiled in default PATH. Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: smithj9870 at yahoo.com Would it be possible to change the USER_PATH or _PATH_STDPATH variables to not be defined at compile time which makes them get permanently built into the sshd binary. Instead make it a config option that could be changed post-install? One use of this is being able to make the software relocatable, except for the /etc (sysconfig) files, which would really help in some circumstances. It could be an option in the /etc/ssh/sshd_config file, similar to the Subsystem option for sftp. Currently you can just relocate it yourself as long as you make sure the PATH is set correctly elsewhere, but leaving the old built in path component there could be considered a security risk. ~Jason ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 1 09:49:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 1 Mar 2002 09:49:37 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020228224937.720C2EA96@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2002-03-01 09:49 ------- Such an option exists: your shell initialisation files - /etc/profile, /etc/csh.cshrc, etc. I can't possibly imagine how using the system-defined path could be a security risk, unless the system itself is busted. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 1 10:01:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 1 Mar 2002 10:01:56 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020228230156.234BEEA96@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From markus at openbsd.org 2002-03-01 10:01 ------- but /etc/profile is only sourced for interactive shells, i think. adding /etc/ssh/environment could help ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Fri Mar 1 13:00:57 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 28 Feb 2002 18:00:57 -0800 (PST) Subject: PATCH: nroff detection wrong, by default uses mantype=cat In-Reply-To: <3C7E9DD6.861ABFDC@tls.msk.ru> Message-ID: On Fri, 1 Mar 2002, Michael Tokarev wrote: > Pekka Savola wrote: > > > [] > > Please take a look at the configure without a patch: > > > > --8<-- > > for as_dir in /usr/bin:/usr/ucb > ^^^^^ > > do > > IFS=$as_save_IFS > ^^^^^^^^^^^^^^^^ > I assume that IFS was changed somewhere before this for_loop, and now it > is restored to it's original value (why w/o quotes?!). I *suspect* there > should be IFS=: right before this loop. If there is no such assignment, > it should be autoconf's bug. What version of autoconf are you running? Or are you running the configure in the tar balls? My configure looks like this ... ac_save_IFS=$IFS; IFS=$ac_path_separator ac_dummy="/usr/bin:/usr/ucb" for ac_dir in $ac_dummy; do IFS=$ac_save_IFS test -z "$ac_dir" && ac_dir=. ... I don't see "for as_dir" anywhere in configure. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From police at terrabox.com Fri Mar 1 15:13:38 2002 From: police at terrabox.com (police at terrabox.com) Date: Thu, 28 Feb 2002 22:13:38 -0600 (CST) Subject: sftp question Message-ID: I have openssh on my solaris servers, my question or concern I need to lockdown/jail the sftp users so they won't cd out of their home dir (setup of an anonymous ftp servers) and destroy or view other sftp users files. Is this doable with openssh?? From pekkas at netcore.fi Fri Mar 1 18:40:14 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 1 Mar 2002 09:40:14 +0200 (EET) Subject: PATCH: nroff detection wrong, by default uses mantype=cat In-Reply-To: Message-ID: On Thu, 28 Feb 2002, Tim Rice wrote: > Or are you running the configure in the tar balls? > > My configure looks like this > ... > ac_save_IFS=$IFS; IFS=$ac_path_separator > ac_dummy="/usr/bin:/usr/ucb" > for ac_dir in $ac_dummy; do > IFS=$ac_save_IFS > test -z "$ac_dir" && ac_dir=. > ... > > I don't see "for as_dir" anywhere in configure. Perhaps the autoconf generating the snapshot tarballs (where I got my version, which is different from yours) is broken? It seems functionally similar though. -- 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 Jason.Lacoss-Arnold at AGEDWARDS.com Sat Mar 2 02:03:45 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Fri, 1 Mar 2002 09:03:45 -0600 Subject: sftp question Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E65F@hqempn06.agedwards.com> You'd have to give them a special shell (i.e. rksh). -----Original Message----- From: police at terrabox.com To: openssh-unix-dev at mindrot.org Sent: 2/28/02 10:13 PM Subject: sftp question I have openssh on my solaris servers, my question or concern I need to lockdown/jail the sftp users so they won't cd out of their home dir (setup of an anonymous ftp servers) and destroy or view other sftp users files. Is this doable with openssh?? _______________________________________________ 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/20020301/49c4f402/attachment.html From bugzilla-daemon at mindrot.org Sat Mar 2 02:27:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 02:27:51 +1100 (EST) Subject: [Bug 132] New: connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020301152751.07A38E93F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 Summary: connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Product: Portable OpenSSH Version: -current Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dwd at bell-labs.com sshd versions 1.2.20+ sometimes lies about the host key size by one bit and the OpenSSH ssh client reports a message like Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. I've only observed it to report even numbers and have an actual size of one less. Similarly, ssh clients of the same vintage require reported sizes that are even numbers which can be a problem if one of old host keys that are actually one bit off are moved forward from the old SSH to OpenSSH. I will attach a 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 Sat Mar 2 02:29:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 02:29:18 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020301152918.EACFDE956@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From dwd at bell-labs.com 2002-03-02 02:29 ------- Created an attachment (id=30) Patch against CVS of March 1, 2003 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 03:03:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 03:03:51 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301160351.ADC2EE933@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From smithj9870 at yahoo.com 2002-03-02 03:03 ------- About the shell initialization files: I MUST strongly disagree with this statement from both a security and system administration point of view. Your solution does not change the fact that the potentially dangerous/insecure path is still compiled into the sshd binary, plus it is the responsibility of the ssh subsystem to configure itself properly. This path is required by the ssh daemon so it can find its scp program, it should NOT be up to the sys admin to modify every possible shell config file to fix this potential problem and security hole. Also, editing one config file is much simpler than editing at least two (and maybe more) shell config files. Since sshd makes the requirement that it has to be able to find its scp program, it should be up to the ssh subsystem to solve the problem and not leave it to shell config files. I find your suggested solution totally unacceptable and ask that you think about this problem a little more. About /etc/ssh/environment: I did not see this mentioned in the ssh documentation/man pages, only the $HOME/.ssh/environment file. Will this always be read even if the user has the corresponding file in their home directory and will it override the PATH setting compiled into the sshd binary? ~Jason ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 03:32:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 03:32:59 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301163259.A761CE93F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From mouring at eviladmin.org 2002-03-02 03:32 ------- > About the shell initialization files: I MUST strongly disagree with this > statement from both a security and system administration point of view. Your > solution does not change the fact that the potentially dangerous/insecure path > is still compiled into the sshd binary [..] from defines.h # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" My God.. if that is 'potentailly dangerous/insecure' then every UNIX in the world's default path is insecure. I am speaking as an admin. At worse it addes on $PREFIX/bin. To the *END* of the search path. And if you change it via --with-default-path (like what Redhat does to include /usr/local/bin FIRST which is lame) then you should should know what your doing. > [..], plus it is the responsibility of the ssh subsystem to configure > itself properly. This path is required by the ssh daemon so it can find > its scp program, it should NOT be up to the sys admin to modify every Subsystem != scp. Subsystem is a v2 feature that is *NOT* used by scp. If you want to ensure that the subsystem ALWAYS finds the RIGHT file.. FULLY path it out in the sshd_config. (Which is is by default: 'Subsystem sftp /usr/libexec/sftp-server'). Subsystem has *NOTHING* to do with scp. Do you see a 'Subsystem scp ..'? I sure don't. Pretty much what scp is doing is a 'ssh user at site scp [..]'. No subsystems here.. I'm sorry, but if you want to complain that there is is not a 'DefaultPATH' configuration directive do so (Better yet write up a simple patch and provide it). Just leave this dribble about 'security' out of it since it is a load of crap. But in any case I can tell you have not a CLUE as to what the difference between 'remote command exec' and 'subsystems'. You really should do your homework better before ranting. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 04:15:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 04:15:52 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301171552.EF040E92C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From smithj9870 at yahoo.com 2002-03-02 04:15 ------- Obviously you didn't read the beginning of this thread, the original submission was about the problem of making a relocatable package, possibly installing ssh in an unusual path, for example lets say /home/username/bin. That path will get added to _PATH_STDPATH and compiled into the sshd binary. Now install it somewhere else and that useless and potentially dangerous path will still be in the sshd binary, and on the new system, who knows what will be in there. Do you honestly believe that isn't a security problem? What I am complaining about is that I am NOT adding that path by hand, instead ssh's configure script decides all by itself that it MUST include that path to find scp, which is a completely WRONG assumption made by the configure script if the ssh package is relocated! Am I being clear enough now? And don't make assumptions when you start your rant. By subsystem I am being more general and referring to the ssh subsystem of a running computer system, ie. the ssh programs and their config files. The ssh configure script should NOT make assumptions about where it thinks its scp program will always be and compile that into the ssh daemon. And if you don't think having an incorrect and unnecessary path component compiled into a root level daemon is a potential security problem then I think you have more to learn about system administration and security. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 05:42:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 05:42:18 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301184218.5C45AE92C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From mouring at eviladmin.org 2002-03-02 05:42 ------- Two things. 1. --with-default-path will disable OpenSSH adding in the $PREFIX/bin (we assume that since you are smart enough to set your own default path, you will be smart enough to know where you are putting scp). 2. 'subsystems' vs 'remote exec'. Use the right terms if you are going to argue for including a feature. Otherwise it makes you look like you've not bothered to learn the product. No, I still don't feel this is a security hole unless you are doing stupid things like --with-prefix=/home/user/ while building your package. And if you are then we can not do much stop you from doing stupid things. =) And I have nothing against something called 'DefaultPATH'.. I do have something against people shouting the sky is falling. As I said.. drop the 'It is a security issue', provide a patch, and show that /etc/profile, /etc/ssh/enviroment, etc are not valid generic solutions. Relocatable packages are problematic at best depending on the web of dependancies. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 06:18:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 06:18:06 +1100 (EST) Subject: [Bug 133] New: hard-coded umask(022) in ssh.c:main() too inflexible Message-ID: <20020301191806.BE871EAA4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=133 Summary: hard-coded umask(022) in ssh.c:main() too inflexible Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wspraul at q-ag.de There is a hardcoded umask(022) call right at the beginning of ssh.c:main(). The getuserattr() system does not exist in Linux, so there is no way to predefine other umasks for scp (scp does not evaluate .bashrc etc.). E.g. I would like to define umask(002) to that uploaded files are group writable. I understand the umask(022) might be important in some cases (setuid root), but I also think there should be a switch to turn that off and just continue with the previous process umask. Either in the config file or as a command line switch. Wolfgang ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 08:02:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:02:25 +1100 (EST) Subject: [Bug 134] New: PAM headers not found during configure Message-ID: <20020301210225.D6CB3E916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=134 Summary: PAM headers not found during configure Product: Portable OpenSSH Version: 3.0.2p1 Platform: MIPS OS/Version: IRIX Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: cg1maverick at c4.com After installing PAM, I recieve the following error message on my system during a ./configure: configure: error: PAM headers not found I have PAM installed and turned on the --with-pam flag. Is there a certain flag I need to set in order for the configure script to find my PAM header files? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 08:07:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:07:31 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301210731.CB659E95D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From smithj9870 at yahoo.com 2002-03-02 08:07 ------- > 1. --with-default-path will disable OpenSSH adding in the $PREFIX/bin (we > assume that since you are smart enough to set your own default path, you will > be smart enough to know where you are putting scp). That will only solve one of the problems, having the incorrect path compiled into the sshd binary, not how sshd will be able to find scp if it has been moved or installed somewhere unusual. > 2. 'subsystems' vs 'remote exec'. Use the right terms if you are going to > argue for including a feature. Otherwise it makes you look like you've not > bothered to learn the product. I am not responsible for your misunderstanding me and going on a rant. Maybe I should have been a little more clear, but you do not have to assume I mean something else by subsystem and imply that I am an idiot. > No, I still don't feel this is a security hole unless you are doing stupid > things like --with-prefix=/home/user/ while building your package. And if > you are then we can not do much stop you from doing stupid things. =) That path was just an example. Just because you can't think if a way to take advantage of a vulnerability doesn't mean the current method is 100% safe. Also try to remember that not everyone installs software in the "standard" places, some sites might have other requirements. Do you agree that a system with the smallest number of vulnerabilities is more secure? Why would you advocate adding a directory to the path just so a daemon can find one file? Is that really being minimal? > And I have nothing against something called 'DefaultPATH'.. I do have > something against people shouting the sky is falling. As I said.. drop the > 'It is a security issue', provide a patch, and show that /etc/profile, > /etc/ssh/enviroment, etc are not valid generic solutions. So I guess no one ever uses ssh to login as root to do remote system administration then? You know for sure that there is absolutely no security risk with the current design then? And root doesn't have to worry about what sshd decides to stick in it's path just because it thinks scp is somewhere? Like I said before, the simplest and correct solution is to have a config option that tells sshd where scp is, instead of adding another directory to the path that the user might not need. This might not be a problem if ssh is being installed in a usual place like /usr or /usr/local, but try to think of the more general case where some site decides to install it somewhere you never thought of. /etc/profile is NOT the appropriate place to put this path, it is only an ugly kludge to fix the real problem, especially when it might only be needed so sshd can find one thing (scp). Why should the sys admin have to add that path to the general system shell config scripts, and have to make sure all possible scripts are correct, just because sshd can't find something without it? It should be the responsibility of sshd to configure this since it needs to know about it. And about patches, tell me why I should waste my time writing a patch when my suggestion has been shot down from the very beginning and negatively criticized over and over. If you want people to contribute patches to an opensource project then you should have an open mind and treat them with respect. Again, try to look at the more general case, not just the "normal" install everything in /usr case. I think you will see that the current design is not the best possible one. > Relocatable packages are problematic at best depending on the web of > dependancies. I know about the problems with relocatable packages, but ssh is fairly simple, just a few executables, some documentation and a few config files. Built correctly, it should be easily relocatable except for one or more of the config files. ~Jason ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 08:08:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:08:26 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020301210826.F40D3E961@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From markus at openbsd.org 2002-03-02 08:08 ------- what is this for? the warning is in ssh intentionally. the error has nothing to do with the software version of the server, it's a problem with 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 Sat Mar 2 08:16:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:16:18 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301211618.BFC74E95D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From markus at openbsd.org 2002-03-02 08:16 ------- % grep _PATH_DEFPATH /usr/include/paths.h #define _PATH_DEFPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" i don't see why it's insecure to use this 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 Sat Mar 2 08:23:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:23:00 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301212300.74C06E962@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From markus at openbsd.org 2002-03-02 08:22 ------- "the simplest and correct solution is to have a config option that tells sshd where scp is" that's very wrong. sshd should not know about scp at all. it has nothing to do with scp. if scp is not in the default path, then your setup is broken. if there are dangerous things in the default path, then the default path is wrong or your system is broken. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 08:30:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:30:46 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301213046.9AC51E96F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From mouring at eviladmin.org 2002-03-02 08:30 ------- His issue stems from two things. 1. portable may add a $PREFIX/bin if --with-default-path is not used and $PREFIX != /usr 2. He seems to think that one can magicly detect we are doing a 'scp' and handle it via some magic. What he forgets is that END USERS also need to be able to type 'scp' at the prompt to run the command. So either we add the path to an internal default path or to a 'commonly used' configuration file (/etc/profile, /etc/ssh/enviroment, etc). That is my last 0.02c on the issue since it is pointless. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 08:45:02 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 08:45:02 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020301214502.4E22DE965@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From dwd at bell-labs.com 2002-03-02 08:44 ------- Since this is a normal case, I don't think the warning belongs there in the client. I have many users who have no control over what the remote end is, and the warning will mess up their scripts. On the server side, it would be unacceptable to regenerate SSH1 host keys when I upgrade from old SSH to OpenSSH, and some of those old keys are an odd size and the old SSH client chokes on them if we don't round them up to an even number like the old SSH server did. Compat.c already simulates many old bugs so I don't think one more would hurt. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 09:32:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 09:32:24 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301223224.53E53E916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From smithj9870 at yahoo.com 2002-03-02 09:32 ------- > % grep _PATH_DEFPATH /usr/include/paths.h > #define _PATH_DEFPATH > "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" > > i don't see why it's insecure to use this path. Where did I ever mention _PATH_DEFPATH? Your point here is completely irrelevent to what I was talking about. > "the simplest and correct solution is to have a config option > that tells sshd where scp is" > > that's very wrong. sshd should not know about scp at all. > it has nothing to do with scp. If sshd is going to execute scp on behalf of the user because of a remote scp command, then you are wrong, it should know exactly what it is executing and from where. It should NOT rely on the user to have setup their path correctly. If you are talking about an interactive shell then you are correct. But these are two completely different cases! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 09:57:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 09:57:43 +1100 (EST) Subject: [Bug 131] Problems with sshd's compiled in default PATH. Message-ID: <20020301225743.83584E916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=131 ------- Additional Comments From markus at openbsd.org 2002-03-02 09:57 ------- sshd should not know where 'ls' is stored. sshd should not know where 'pwd' is stored. sshd should not know where 'scp' is stored. sshd must rely in the path, since it does not know that there is a 'ls', a 'pwd' or a 'scp' binary. sshd does not rely on the user setting up the path. sshd relies on the admin to setup the path correctly, and the path set by the admin has to be trusted. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 2 10:06:13 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Mar 2002 10:06:13 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020301230613.188A4E977@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From markus at openbsd.org 2002-03-02 10:06 ------- but the warning is for the case you try to disable. and it does not depend on a specific versions of the sshd. another option would be: change the log() to verbose() so it's not in the default ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Sat Mar 2 15:55:42 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 02 Mar 2002 15:55:42 +1100 Subject: Support for AIX native (.bff) packages: patch available Message-ID: <3C805B4E.1B4D351D@zip.com.au> Hello All, I've written basic support for creating AIX native packages (ie installp/SMIT installable .bff's) that lives in contrib/aix. It is based on Ben Lindstrom's Solaris buildpkg.sh. It requires no special tools and all code was either written by me or derived from the openssh distribution itself. It is made available under the same terms as buildpkg.sh (ie public domain). There's still some rough edges but it works for me. The script has been tested on AIX 4.2.1 and the resulting package installs on 4.2.1 and 4.3.3. My intention is to get it merged into the OpenSSH portable distribution once it's in a fit condition. I'm very interested in feedback and suggestions to improve the quality and suitablity for inclusion. The (~12 KB) patch can be downloaded from : http://www.zip.com.au/~dtucker/openssh-3.0.2p1-aixbff.patch http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-aixbff.patch -Daz. From police at terrabox.com Sat Mar 2 18:09:11 2002 From: police at terrabox.com (police at terrabox.com) Date: Sat, 2 Mar 2002 01:09:11 -0600 (CST) Subject: sftp question In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E65F@hqempn06.agedwards.com> Message-ID: I did, it works fine with ssh user at host, but it does not work for sftp user at host I still can cd out. On Fri, 1 Mar 2002, Lacoss-Arnold, Jason wrote: > You'd have to give them a special shell (i.e. rksh). > > -----Original Message----- > From: police at terrabox.com > To: openssh-unix-dev at mindrot.org > Sent: 2/28/02 10:13 PM > Subject: sftp question > > I have openssh on my solaris servers, my question or concern I need to > lockdown/jail the sftp users so they won't cd out of their home dir > (setup > of an anonymous ftp servers) and destroy or view other sftp users files. > Is this doable with openssh?? > > _______________________________________________ > 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 dmanton at emea.att.com Sun Mar 3 02:38:24 2002 From: dmanton at emea.att.com (Manton, Doug) Date: Sat, 2 Mar 2002 15:38:24 -0000 Subject: UseLogin under AIX 4.3.3 Message-ID: > This is probably the well known /var/adm/wtmp, /etc/utmp corruption > bug. > There is a IBM tech note to fix this but basically just backup and clear > /var/adm/wtmp and > /etc/utmp. This can be done in any method you like "cat /dev/null > > filename". Also check > to see that your diskspace for / and /var is not filled. I think this > problem came about > when disk space fills and utmp/wtmp are incompletely written. No such luck. This problem occurs on every AIX system I have tried -- including the fresh install of 4.3.3 ML9 that went onto my new software build server. Thanks for the tip. I'll continue my investigation. Does UseLogin work in your environment? Doug Manton, AT&T Business Commercial Security ---------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2714 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020302/32f6910f/attachment.bin From mouring at etoh.eviladmin.org Sun Mar 3 03:43:13 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 2 Mar 2002 10:43:13 -0600 (CST) Subject: Support for AIX native (.bff) packages: patch available In-Reply-To: <3C805B4E.1B4D351D@zip.com.au> Message-ID: Nice. However since it has a lot of fixed information (unlike the Solaris' package) you are going to have to be willing to maintain it or convert it to a pure dynamic system. That was the main reason why the Solaris buildpkg.sh was rewritten to ensure that I did not have to muck with it very offen. =) However, if you are willing to ensure it is up-to-date on future releases I'd be happy to include it. - Ben On Sat, 2 Mar 2002, Darren Tucker wrote: > Hello All, > I've written basic support for creating AIX native packages (ie installp/SMIT installable .bff's) that lives in contrib/aix. It is based on Ben Lindstrom's Solaris buildpkg.sh. It requires no special tools and all code was either written by me or derived from the openssh distribution itself. It is made available under the same terms as buildpkg.sh (ie public domain). > > There's still some rough edges but it works for me. The script has been tested on AIX 4.2.1 and the resulting package installs on 4.2.1 and 4.3.3. My intention is to get it merged into the OpenSSH portable distribution once it's in a fit condition. > > I'm very interested in feedback and suggestions to improve the quality and suitablity for inclusion. > > The (~12 KB) patch can be downloaded from : > http://www.zip.com.au/~dtucker/openssh-3.0.2p1-aixbff.patch > http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-aixbff.patch > > -Daz. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mouring at etoh.eviladmin.org Sun Mar 3 05:07:46 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 2 Mar 2002 12:07:46 -0600 (CST) Subject: Support for AIX native (.bff) packages: patch available In-Reply-To: <3C805B4E.1B4D351D@zip.com.au> Message-ID: Since I don't have AIX I can't test this. But this is a quick script to automate building your inventory file. If I knew what type of checksum it wanted I would throw the code in (see attachment). However, you should beable to extract out the $PREFIX by doing like: PREFIX=`grep "^prefix=" Makefile | cut -d = -f 2` And the script should be pretty much be automated. Allowing the package builder to build to their --prefix targed location. We are getting close to 3.1 release.. so I think this will have to go in at the start of 3.2. Unless Damien and Markus think that this is an non-issue and I'll important the current version now. - Ben -------------- next part -------------- find fake/ -ls | awk '{\ if (NR != 1) {\ ## Encode permissions in oct u=0; g=0; o=0;\ if (substr($3,2,1) == "r") u=u+4;\ if (substr($3,3,1) == "w") u=u+2;\ if (substr($3,4,1) == "x") u=u+1;\ if (substr($3,5,1) == "r") g=g+4;\ if (substr($3,6,1) == "w") g=g+2;\ if (substr($3,7,1) == "x") g=g+1;\ if (substr($3,8,1) == "r") o=o+4;\ if (substr($3,9,1) == "w") o=o+2;\ if (substr($3,10,1) == "x") o=o+1;\ ## Start to display inventory information print substr($11, 5, length($11) - 1)":";\ print "\tclass=apply,inventory,openssh";\ print "\towner=root";\ print "\tgroup=system";\ print "\tmode="u""g""o;\ if (substr($3, 0, 1) == "-") { ## Entry is File print "\ttype=FILE";\ print "\tsize="$7;\ ## One should system() out do a checksum print "\tchecksum=VOLATILE";\ } else if (substr($3, 0, 1) == "l") { \ ## Entry is SymLink print "\ttype=SYMLINK";\ print "\ttarget="$13;\ } else {\ ## Entry Assumed (wrongly?) Directory print "\ttype=DIRECTORY";\ }\ }\ }' From dtucker at zip.com.au Sun Mar 3 12:35:11 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Mar 2002 12:35:11 +1100 Subject: Support for AIX native (.bff) packages: patch available References: Message-ID: <3C817DCF.D332F021@zip.com.au> Ben Lindstrom wrote: > Nice. Thanks! > However since it has a lot of fixed information (unlike the Solaris' > package) you are going to have to be willing to maintain it or convert > it to a pure dynamic system. That was the main reason why the Solaris > buildpkg.sh was rewritten to ensure that I did not have to muck with it > very offen. =) I know. The hard-coded paths and inventory files are the "rough edges" I mentioned. I plan to eliminate them. I was also hoping I could find a more elegant way to get the octal modes than parsing "ls", but I haven't. I'll incorporate your inventory.sh script and rework the rest. There's a couple of wrinkles, though, eg if any of the files live on the root filesystem (eg --sysconfdir=/etc) then you need to generate a different type of package. The package format is slightly weird (matching the rest of AIX!) and I'm still coming to grips with it. > However, if you are willing to ensure it is up-to-date on future releases > I'd be happy to include it. Excellent. I'll let you know when the rework is done so you can take another look. -Daz. From dtucker at zip.com.au Sun Mar 3 13:36:01 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Mar 2002 13:36:01 +1100 Subject: Solaris buildpkg.sh: postinstall script added References: Message-ID: <3C818C10.4F4652EB@zip.com.au> Hello. I've added a postinstall script and a few mods to the Solaris buildpkg.sh to: * Save previous configs and create them from defaults if necessary * (re)start sshd This has been tested on Solaris 2.6 only. The patch can be had from either of: http://www.zip.com.au/~dtucker/openssh-3.0.2p1-buildpkg.patch http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-buildpkg.patch -Daz. From mouring at etoh.eviladmin.org Sun Mar 3 14:22:02 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 2 Mar 2002 21:22:02 -0600 (CST) Subject: Solaris buildpkg.sh: postinstall script added In-Reply-To: <3C818C10.4F4652EB@zip.com.au> Message-ID: Hmm.. Not the package management's job to handle restarting of sevices. + if [ -f $PIDDIR/sshd.pid ] + then + pid=\`cat $PIDDIR/sshd.pid\` + if ps -p \$pid | grep sshd >/dev/null + then + echo "Stopping sshd (pid \$pid)." + kill \$pid + fi + fi I don't like the idea. I have personally never liked it. I'd rather have the post install script inform the admin that they must restart sshd for the new version to take affect. Reason being is there are times you install upgrade packages for general testing, and you don't want them to kill your known good sshd. Even on test platforms.. =) It makes people very growly when they have to get up from their desks and restat sshd from the sun console. =) - Ben On Sun, 3 Mar 2002, Darren Tucker wrote: > Hello. > I've added a postinstall script and a few mods to the Solaris > buildpkg.sh to: > > * Save previous configs and create them from defaults if necessary > * (re)start sshd > > This has been tested on Solaris 2.6 only. > > The patch can be had from either of: > http://www.zip.com.au/~dtucker/openssh-3.0.2p1-buildpkg.patch > http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-buildpkg.patch > > -Daz. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Sun Mar 3 17:37:56 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Mar 2002 17:37:56 +1100 Subject: Support for AIX native (.bff) packages: patch available References: Message-ID: <3C81C4C4.55270FA5@zip.com.au> Ben Lindstrom wrote: > And the script should be pretty much be automated. Allowing the package > builder to build to their --prefix targed location. I've completed the modifications. I think I've got all of the path assumptions. I also found an fixed a number of bugs. I've successfully built and installed packages after specifying (in separate builds) --prefix=/usr/local/ssh and --sysconfdir=/etc. It doesn't handle the latter case in the technically correct manner but it seems to work anyway..... Please let me know how this one looks. The new patches (against the 3.0.2p1 distribution) can be had from either of http://www.zip.com.au/~dtucker/openssh-3.0.2p1-aixbff2.patch http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-aixbff2.patch -Daz. From dtucker at zip.com.au Sun Mar 3 20:09:03 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Mar 2002 20:09:03 +1100 Subject: Solaris buildpkg.sh: postinstall script added References: Message-ID: <3C81E82F.41BD6CD2@zip.com.au> Ben Lindstrom wrote: [restarting daemons from postinstall scripts] > Reason being is there are times you install upgrade packages for > general testing, and you don't want them to kill your known good > sshd. Even on test platforms.. =) It makes people very growly when > they have to get up from their desks and restat sshd from the sun > console. =) As I said in a private (because I forgot to cc the list) message if you upgrade sshd and don't test it before logging out then you deserve what you get :-) Ben pointed out that it's a personal preference thing, and he's right. While it's really easy to restart it yourself if that's what you want it's too late if you didn't want to. So, how about: # Check for running sshd and start if not running if [ -f $piddir/sshd.pid ] then pid=\`cat $piddir/sshd.pid\` if ps -p \$pid | grep sshd >/dev/null then echo "sshd already running (pid \$pid)." else echo "Starting sshd." $sbindir/sshd fi fi -Daz. From dwliz at sky.net Sun Mar 3 22:08:44 2002 From: dwliz at sky.net (cvyrliz) Date: Sun, 3 Mar 2002 03:08:44 -0800 Subject: Are you confident? rgt Message-ID: <20020303112034.28508E881@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020303/e17d9ad4/attachment.html From d-b at home.se Mon Mar 4 06:19:16 2002 From: d-b at home.se (Daniel Bergman) Date: Sun, 03 Mar 2002 20:19:16 +0100 Subject: Solaris buildpkg.sh: postinstall script added In-Reply-To: <3C81E82F.41BD6CD2@zip.com.au> References: <3C81E82F.41BD6CD2@zip.com.au> Message-ID: <424018095.1015186756@localhost> I agree with Ben. On a few occasions I've logged on to a server using an old SSH version, installed the new SSH package, killed the old SSH parent process and launched the new SSH for testing. If I'm satisfied with the new SSH version I would simply make it permanent and exit the forked-off old SSH process that I'm currently using, thus removing the old SSH version from the running system. I think pre/post package scripts shouldn't mess with running processes. Regards, Daniel > Ben Lindstrom wrote: > [restarting daemons from postinstall scripts] >> Reason being is there are times you install upgrade packages for >> general testing, and you don't want them to kill your known good >> sshd. Even on test platforms.. =) It makes people very growly when >> they have to get up from their desks and restat sshd from the sun >> console. =) > > As I said in a private (because I forgot to cc the list) message if you > upgrade sshd and don't test it before logging out then you deserve what > you get :-) > > Ben pointed out that it's a personal preference thing, and he's right. > While it's really easy to restart it yourself if that's what you want > it's too late if you didn't want to. > > So, how about: > ># Check for running sshd and start if not running > if [ -f $piddir/sshd.pid ] > then > pid=\`cat $piddir/sshd.pid\` > if ps -p \$pid | grep sshd >/dev/null > then > echo "sshd already running (pid \$pid)." > else > echo "Starting sshd." > $sbindir/sshd > fi > fi > > -Daz. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Daniel Bergman Phone: 08 - 55066265 Mobile: 070 - 289 30 39 Fax: 08 - 59827056 Email: d-b at home.se From dtucker at zip.com.au Mon Mar 4 07:38:55 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 04 Mar 2002 07:38:55 +1100 Subject: Solaris buildpkg.sh: postinstall script added References: <3C81E82F.41BD6CD2@zip.com.au> <424018095.1015186756@localhost> Message-ID: <3C8289DF.5C450AB6@zip.com.au> Daniel Bergman wrote: > > I agree with Ben. [snip] > I think pre/post package scripts shouldn't mess with running processes. Shouldn't mess with a process that already running, or shouldn't mess with running a new process? I mean is it OK to start the daemon if it's not running? (Even if there's one running and didn't find it, the new one will exit when it can't bind() to 22.) If it's inappropriate, the whole fragment can be deleted, the rest of the postinstall won't be affected. To top it off, I mixed up the AIX and Solaris scripts and posted the piece from the wrong one. Whoops. > ># Check for running sshd and start if not running > > if [ -f $piddir/sshd.pid ] > > then > > pid=\`cat $piddir/sshd.pid\` > > if ps -p \$pid | grep sshd >/dev/null > > then > > echo "sshd already running (pid \$pid)." > > else > > echo "Starting sshd." > > $sbindir/sshd Should be : /etc/init.d/opensshd start > > fi > > fi -Daz. From d-b at home.se Mon Mar 4 07:58:15 2002 From: d-b at home.se (Daniel Bergman) Date: Sun, 03 Mar 2002 21:58:15 +0100 Subject: Solaris buildpkg.sh: postinstall script added In-Reply-To: <3C8289DF.5C450AB6@zip.com.au> References: <3C81E82F.41BD6CD2@zip.com.au> <424018095.1015186756@localhost>+0100 (ECTD) <3C8289DF.5C450AB6@zip.com.au> Message-ID: <429957245.1015192695@localhost> Actually, I think the script shouldn't start SSH no matter what since I believe it should be done interactive by an administrator. But I see your point, would be handy though. Regards, Daniel >> >> I agree with Ben. > [snip] >> I think pre/post package scripts shouldn't mess with running processes. > > Shouldn't mess with a process that already running, or shouldn't mess > with running a new process? I mean is it OK to start the daemon if it's > not running? (Even if there's one running and didn't find it, the new one > will exit when it can't bind() to 22.) > > If it's inappropriate, the whole fragment can be deleted, the rest of the > postinstall won't be affected. > > To top it off, I mixed up the AIX and Solaris scripts and posted the > piece from the wrong one. Whoops. > >> ># Check for running sshd and start if not running >> > if [ -f $piddir/sshd.pid ] >> > then >> > pid=\`cat $piddir/sshd.pid\` >> > if ps -p \$pid | grep sshd >/dev/null >> > then >> > echo "sshd already running (pid \$pid)." >> > else >> > echo "Starting sshd." >> > $sbindir/sshd > Should be : /etc/init.d/opensshd start >> > fi >> > fi > > -Daz. > > -- Daniel Bergman Phone: 08 - 55066265 Mobile: 070 - 289 30 39 Fax: 08 - 59827056 Email: d-b at home.se From bugzilla-daemon at mindrot.org Mon Mar 4 11:53:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 4 Mar 2002 11:53:12 +1100 (EST) Subject: [Bug 134] PAM headers not found during configure Message-ID: <20020304005312.61E8FE917@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=134 ------- Additional Comments From djm at mindrot.org 2002-03-04 11:53 ------- Do you have the pam-devel package installed? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From webmaster at mindrot.org Tue Mar 5 01:38:49 2002 From: webmaster at mindrot.org (webmaster at mindrot.org) Date: Mon, 4 Mar 2002 22:38:49 +0800 Subject: Fw: http://www.openssh.org/es/ Message-ID: <20020304134419.3C5AFE904@shitei.mindrot.org> ----- Original Message ----- From: crisha at trafficbbs.net To: webmaster at mindrot.org Sent: 2002-3-4 22:38:39 Subject: http://www.openssh.org/es/ Hello, You may have spent much on lots of ways to achieve these - search engine registrations, website promotions, press release, email sending?- Here Traffic BBS presents you a unique method economically and professionally converting a PC into personal message distribution center! Traffic BBS assists you to post your message or ad to over 1,200,000+ message boards on the web worldwide. Along with a hyperlink to your website or email address, a message of your business, product, service or offer will be promptly submitted to targeted bulletin boards. You can expect instant response! Get your business, service, product or offer seen! Best Regards, Crisha Wenston Sales & Marketing www.trafficbbs.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020304/9dc3298c/attachment.html From dtucker at zip.com.au Tue Mar 5 01:12:08 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Mar 2002 01:12:08 +1100 Subject: Support for AIX native (.bff) packages: patch available References: <3C81C4C4.55270FA5@zip.com.au> Message-ID: <3C8380B8.DD2B3CFD@zip.com.au> Hello All, I've finished the 3rd and hopefully last edition of my patch to add AIX native (SMIT/installp installable lpp/bff) format package support, based on Ben Lindstrom's Solaris buildpkg.sh. This contains the following changes, relative to the previous patch: * remove daemon (re)start from postinstall due to feedback from list * adds a couple of sanity checks * recode inventory.sh to use perl and handle setuid files correctly. * add comments * remove redirect on "make install" so it behaves more like buildpkg.sh This was tested and the resulting packages installed on AIX versions 4.2.1 and 4.3.3. I don't intend making any further changes unless they are due to problems or suitability for inclusion in the main distribution. I'm also interested in feedback (good or bad) from anyone who has tried this for themselves. The 8KB patch (against 3.0.2p1) can be had from either of: http://www.zip.com.au/~dtucker/openssh-3.0.2p1-aixbff3.patch http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-aixbff3.patch -Daz. From bugzilla-daemon at mindrot.org Tue Mar 5 03:33:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 5 Mar 2002 03:33:24 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020304163324.44399E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From dwd at bell-labs.com 2002-03-05 03:33 ------- That would be fine with me to have it be only in verbose mode. However, SSH_BUG_SERVERLIESSIZE is still needed because the old clients require key sizes to be reported as an even number of bits, and we wouldn't want to emulate that bug for newer clients. You say that it doesn't depend on the version of sshd and I assume that extends to the ssh client, but I think it's fair to only accommodate the clients known to be picky and which are still pretty commonly found. I will attach a new suggested patch. I have added a comment explaining the known scenario which the warning is for so people who look will know that it is intentionally for this 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 Tue Mar 5 03:35:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 5 Mar 2002 03:35:12 +1100 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020304163512.5E34BE994@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 ------- Additional Comments From dwd at bell-labs.com 2002-03-05 03:35 ------- Created an attachment (id=31) New patch changing server lies log()s to verbose()s ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From wknox at mitre.org Tue Mar 5 07:24:09 2002 From: wknox at mitre.org (William R. Knox) Date: Mon, 4 Mar 2002 15:24:09 -0500 (EST) Subject: Update to solaris package creation (init script links) In-Reply-To: <20020228121839.C31570@usa.net> Message-ID: I also do tend towards soft links, but only if I'm not installing as a package (which I tend to avoid) - after all, I don't tend to want to move a part of the package out of the way and put a new one in. In my mind, that (partially, at least) defeats the point of having a package, which is knowing exactly what you have in place. So I would agree that, in this instance, it should be hard links (i.e. following the vendor's standard). Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation On Thu, 28 Feb 2002, Peter Watkins wrote: > Date: Thu, 28 Feb 2002 12:18:39 -0500 > From: Peter Watkins > To: Tim Rice > Cc: Ben Lindstrom , > OpenSSH Development > Subject: Re: Update to solaris package creation (init script links) > > On Thu, Feb 28, 2002 at 08:53:20AM -0800, Tim Rice wrote: > > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > [snip] > > > >> The modifications are: > > > >> - the rc?.d scripts are hard links not soft links > > > > I prefer hard links too. Anyone else vote for this? > > I generally prefer soft links -- it seems odd that after > cd /etc/init.d; mv foo foo.old; mv foo.new foo > you'd still have the old script executed. But hard links are what > Sun uses for its SysV S/K entities, so I see the logic. Basically > I don't like how Sun does it, but understand the logic of OpenSSH > behaving in the same manner as the OS vendor; that's probably the > better way to behave, for consistency's sake. :-( > > -Peter > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Tue Mar 5 07:40:18 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 4 Mar 2002 15:40:18 -0500 Subject: Update to solaris package creation (init script links) In-Reply-To: ; from wknox@mitre.org on Mon, Mar 04, 2002 at 03:24:09PM -0500 References: <20020228121839.C31570@usa.net> Message-ID: <20020304154017.C27398@sm2p1386swk.wdr.com> This can always be made a package option folks. There are several ways to accomplish that, but the cleanest is to have the postinstall script installf the links and select soft vs. hard based on the setting of some pkg variable, defaulted to hard. That variable's value could either be queried for by a request script, or, far more simply, left to be provided in a response file by the savvy sysadmin who really likes soft links. Cheers, Nico On Mon, Mar 04, 2002 at 03:24:09PM -0500, William R. Knox wrote: > I also do tend towards soft links, but only if I'm not installing as a > package (which I tend to avoid) - after all, I don't tend to want to move > a part of the package out of the way and put a new one in. In my mind, > that (partially, at least) defeats the point of having a package, which is > knowing exactly what you have in place. So I would agree that, in this > instance, it should be hard links (i.e. following the vendor's standard). > > Bill Knox > Senior Operating Systems Programmer/Analyst > The MITRE Corporation > > On Thu, 28 Feb 2002, Peter Watkins wrote: > > > Date: Thu, 28 Feb 2002 12:18:39 -0500 > > From: Peter Watkins > > To: Tim Rice > > Cc: Ben Lindstrom , > > OpenSSH Development > > Subject: Re: Update to solaris package creation (init script links) > > > > On Thu, Feb 28, 2002 at 08:53:20AM -0800, Tim Rice wrote: > > > On Thu, 28 Feb 2002, Ben Lindstrom wrote: > > > > > [snip] > > > > >> The modifications are: > > > > >> - the rc?.d scripts are hard links not soft links > > > > > > I prefer hard links too. Anyone else vote for this? > > > > I generally prefer soft links -- it seems odd that after > > cd /etc/init.d; mv foo foo.old; mv foo.new foo > > you'd still have the old script executed. But hard links are what > > Sun uses for its SysV S/K entities, so I see the logic. Basically > > I don't like how Sun does it, but understand the logic of OpenSSH > > behaving in the same manner as the OS vendor; that's probably the > > better way to behave, for consistency's sake. :-( > > > > -Peter > > _______________________________________________ > > 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 -- -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 Mar 5 13:52:06 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 4 Mar 2002 20:52:06 -0600 (CST) Subject: Support for AIX native (.bff) packages: patch available In-Reply-To: <3C8380B8.DD2B3CFD@zip.com.au> Message-ID: This is now included in the CVS tree since it does not have any current dependances, and will be included in 3.1 release. Thanks. - Ben On Tue, 5 Mar 2002, Darren Tucker wrote: > Hello All, > I've finished the 3rd and hopefully last edition of my patch to add AIX > native (SMIT/installp installable lpp/bff) format package support, based > on Ben Lindstrom's Solaris buildpkg.sh. > > This contains the following changes, relative to the previous patch: > * remove daemon (re)start from postinstall due to feedback from list > * adds a couple of sanity checks > * recode inventory.sh to use perl and handle setuid files correctly. > * add comments > * remove redirect on "make install" so it behaves more like buildpkg.sh > > This was tested and the resulting packages installed on AIX versions > 4.2.1 and 4.3.3. > > I don't intend making any further changes unless they are due to > problems or suitability for inclusion in the main distribution. I'm also > interested in feedback (good or bad) from anyone who has tried this for > themselves. > > The 8KB patch (against 3.0.2p1) can be had from either of: > http://www.zip.com.au/~dtucker/openssh-3.0.2p1-aixbff3.patch > http://home.usf.advantra.com.au/~dtucker/openssh-3.0.2p1-aixbff3.patch > > -Daz. From tim at multitalents.net Tue Mar 5 16:39:22 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 4 Mar 2002 21:39:22 -0800 (PST) Subject: Update to solaris package creation Message-ID: Here is a new buildpkg.sh for your review before commiting to CVS. THe patch was larger than the script so I've attached the complete script. Changes: This should now work on any system that has SVR4 style package tools. It now requires that you run it from your build dir. (you might have a read only source tree). CATAGORY="Security,application" Solaris 8 man page says CATEGORY* A comma-separated list of categories under which a package may be displayed. A package must at least ^^^^ belong to the system or application category. One could argue that it should be system instead of application. Added and enhanced Antonio Navarro's awk mods. > - modified the awk script that filters the prototype so that the system > directories are marked as shared (using ? for permissions, owner and group) All system directories listed in SYSTEM_DIR= will have ? ? ? Now using nawk because on Solaris, awk is the old version. There are now some options on building your package. You can change the options in buildpkg.sh or create a config.local file in your build dir that buildpkg.sh will source of it exists. SYSVINIT_NAME=opensshd (Some might prefer sshd) USE_SYM_LINKS=no The consensus was use hard links on the init scripts. Set to yes for sym links. PRE_INS_STOP=no If you want preinstall to stop sshd POST_INS_START=no If you want postinstall to start sshd MAKE=${MAKE:="make"} In case your system make is brain dead I've added a preremove that will stop sshd before removing it. I've renamed the config files so multiple installs will not overwrite. (Thanks to Darren Tucker for reminding me about ssh_prng_cmds) Added some logic to deal with systems that don't have /etc/rcS.d Fixed the pkgmk, pkgtrans parts to work on Solaris and other systems. Enjoy. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- #!/bin/sh # # Fake Root Solaris/SVR4/SVR5 Build System - Prototype # # The following code has been provide under Public Domain License. I really # don't care what you use it for. Just as long as you don't complain to me # nor my employer if you break it. - Ben Lindstrom (mouring at eviladmin.org) # umask 022 # Options for building the package # You can create a config.local with your customized options PKGNAME=OpenSSH SYSVINIT_NAME=opensshd USE_SYM_LINKS=no PRE_INS_STOP=no POST_INS_START=no MAKE=${MAKE:="make"} SYSTEM_DIR="/etc \ /etc/init.d \ /etc/rcS.d \ /etc/rc0.d \ /etc/rc1.d \ /etc/rc2.d \ /opt \ /opt/bin \ /usr \ /usr/bin \ /usr/lib \ /usr/sbin \ /usr/share \ /usr/share/man \ /usr/share/man/man1 \ /usr/share/man/man8 \ /usr/local \ /usr/local/bin \ /usr/local/etc \ /usr/local/libexec \ /usr/local/man \ /usr/local/man/man1 \ /usr/local/man/man8 \ /usr/local/sbin \ /usr/local/share \ /var \ /var/run" # We may need to buiild as root so we make sure PATH is set up # only set the path if it's not set already [ -d /usr/local/bin ] && { echo $PATH | grep ":/usr/local/bin" > /dev/null 2>&1 [ $? -ne 0 ] && PATH=$PATH:/usr/local/bin } [ -d /usr/ccs/bin ] && { echo $PATH | grep ":/usr/ccs/bin" > /dev/null 2>&1 [ $? -ne 0 ] && PATH=$PATH:/usr/ccs/bin } export PATH # [ -f Makefile ] || { echo "Please run this script from your build directory" exit 1 } OPENSSHD_IN=`dirname $0`/opensshd.in case ${OPENSSHD_IN} in /*) ;; *) OPENSSHD_IN=../${OPENSSHD_IN} ;; esac # we will look for config.local to override the above options [ -s ./config.local ] && . ./config.local ## Start by faking root install echo "Faking root install..." START=`pwd` FAKE_ROOT=$START/package mkdir $FAKE_ROOT ${MAKE} install-nokeys DESTDIR=$FAKE_ROOT ## Fill in some details, like prefix and sysconfdir ETCDIR=`grep "^sysconfdir=" Makefile | sed 's/sysconfdir=//'` prefix=`grep "^prefix=" Makefile | cut -d = -f 2` PIDDIR=`grep "^piddir=" Makefile | cut -d = -f 2` SRCDIR=`grep "^srcdir=" Makefile | cut -d = -f 2` ## Extract common info requires for the 'info' part of the package. VERSION=`tail -1 ${SRCDIR}/version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` eval ETCDIR=$ETCDIR UNAME_S=`uname -s` case ${UNAME_S} in SunOS) UNAME_S=Solaris ARCH=`uname -p` RCS_D=yes ;; *) ARCH=`uname -m` ;; esac cd $FAKE_ROOT ## Setup our run level stuff while we are at it. mkdir -p $FAKE_ROOT/etc/init.d [ "$RCS_D" = yes ] && mkdir -p $FAKE_ROOT/etc/rcS.d mkdir -p $FAKE_ROOT/etc/rc0.d mkdir -p $FAKE_ROOT/etc/rc1.d mkdir -p $FAKE_ROOT/etc/rc2.d # We don't want to overwrite config files on multiple installs mv $FAKE_ROOT/$ETCDIR/ssh_config $FAKE_ROOT/$ETCDIR/ssh_config.default mv $FAKE_ROOT/$ETCDIR/sshd_config $FAKE_ROOT/$ETCDIR/sshd_config.default [ -f $FAKE_ROOT/$ETCDIR/ssh_prng_cmds ] && \ mv $FAKE_ROOT/$ETCDIR/ssh_prng_cmds $FAKE_ROOT/$ETCDIR/ssh_prng_cmds.default ## setup our initscript correctly sed -e "s#%%configDir%%#$ETCDIR#g" \ -e "s#%%openSSHDir%%#$prefix#g" \ -e "s#%%pidDir%%#$PIDDIR#g" \ ${OPENSSHD_IN} > $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} chmod 744 $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} if [ "${USE_SYM_LINKS}" = yes ] then [ "$RCS_D" = yes ] && \ ln -s ../init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rcS.d/K30${SYSVINIT_NAME} ln -s ../init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc0.d/K30${SYSVINIT_NAME} ln -s ../init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc1.d/K30${SYSVINIT_NAME} ln -s ../init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc2.d/S98${SYSVINIT_NAME} else [ "$RCS_D" = yes ] && \ ln $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rcS.d/K30${SYSVINIT_NAME} ln $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc0.d/K30${SYSVINIT_NAME} ln $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc1.d/K30${SYSVINIT_NAME} ln $FAKE_ROOT/etc/init.d/${SYSVINIT_NAME} $FAKE_ROOT/etc/rc2.d/S98${SYSVINIT_NAME} fi ## Ok, this is outright wrong, but it will work. I'm tired of pkgmk ## whining. for i in *; do PROTO_ARGS="$PROTO_ARGS $i=/$i"; done ## Build info file echo "Building pkginfo file..." cat > pkginfo << _EOF PKG=$PKGNAME NAME="OpenSSH Portable for ${UNAME_S}" DESC="Secure Shell remote access utility; replaces telnet and rlogin/rsh." VENDOR="OpenSSH Portable Team - http://www.openssh.com/portable.html" ARCH=$ARCH VERSION=$VERSION CATEGORY="Security,application" BASEDIR=/ _EOF ## Build preinstall file echo "Building preinstall file..." cat > preinstall << _EOF #! /sbin/sh # [ "${PRE_INS_STOP}" = "yes" ] && [ -f /etc/init.d/${SYSVINIT_NAME} ] && [ -f /etc/init.d/${SYSVINIT_NAME} stop exit 0 _EOF ## Build postinstall file echo "Building postinstall file..." cat > postinstall << _EOF #! /sbin/sh # [ -f $ETCDIR/ssh_config ] || \\ cp -p $ETCDIR/ssh_config.default $ETCDIR/ssh_config [ -f $ETCDIR/sshd_config ] || \\ cp -p $ETCDIR/sshd_config.default $ETCDIR/sshd_config [ -f $ETCDIR/ssh_prng_cmds.default ] && { [ -f $ETCDIR/ssh_prng_cmds ] || \\ cp -p $ETCDIR/ssh_prng_cmds.default $ETCDIR/ssh_prng_cmds } [ "${POST_INS_START}" = "yes" ] && [ -f /etc/init.d/${SYSVINIT_NAME} ] && [ -f /etc/init.d/${SYSVINIT_NAME} start exit 0 _EOF ## Build preremove file echo "Building preremove file..." cat > preremove << _EOF #! /sbin/sh # [ -f /etc/init.d/${SYSVINIT_NAME} ] && [ -f /etc/init.d/${SYSVINIT_NAME} stop exit 0 _EOF ## Next Build our prototype echo "Building prototype file..." cat >mk-proto.awk << _EOF BEGIN { print "i pkginfo"; print "i preinstall"; \\ print "i postinstall"; print "i preremove"; \\ split("$SYSTEM_DIR",sys_files); } { for (dir in sys_files) { if ( \$3 != sys_files[dir] ) { \$5="root"; \$6="sys"; } else { \$4="?"; \$5="?"; \$6="?"; break;} } } { print; } _EOF find . | egrep -v "prototype|pkginfo|mk-proto.awk" | sort | \ pkgproto $PROTO_ARGS | nawk -f mk-proto.awk > prototype ## Step back a directory and now build the package. echo "Building package.." cd .. pkgmk -d ${FAKE_ROOT} -f $FAKE_ROOT/prototype -o echo | pkgtrans -os ${FAKE_ROOT} ${START}/$PKGNAME-$UNAME_S-$ARCH-$VERSION.pkg rm -rf $FAKE_ROOT From twmachuga at hotmail.com Tue Mar 5 17:45:14 2002 From: twmachuga at hotmail.com (Timothy Machuga) Date: Tue, 05 Mar 2002 01:45:14 -0500 Subject: Terminal periodically hangs Message-ID: Ssh connects and authenticates correctly, but sessions periodically hang for minutes at a time. This behaviour also occurs when sftp is used to transfer files - the connection will periodically hang, and then resume transfer. No problem piping rsync over ssh, though (rsync -e ssh ack ugh:/home/foo/ack). Both ssh and sftp problem occur when server is accessed over internal LAN or external DSL/modem connections. This sounds similar to the "[Bug 124] Terminal hangs when data is streaming to it..." (only that was on a different architecture). Was that issue ever resolved? Server is running RedHat 7.2. Both the openSSH 3.0.2p1-1 i386 RPM and a compile of the March 3rd snaphsot exhibit symptoms. Any help would be appreciated - I'm hoping that this is a known issue... -Tim Machuga _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From lrjohn at pumkinpatch.com Tue Mar 5 18:53:06 2002 From: lrjohn at pumkinpatch.com (mrkjohn) Date: Mon, 4 Mar 2002 23:53:06 -0800 Subject: New stuff... rsm Message-ID: <20020305080450.3E406E918@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020304/e3536049/attachment.html From dtucker at zip.com.au Tue Mar 5 19:11:17 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Mar 2002 19:11:17 +1100 Subject: Update to solaris package creation References: Message-ID: <3C847DA5.C3DF1882@zip.com.au> Tim Rice wrote: > Here is a new buildpkg.sh for your review before commiting to CVS. I found this a bit untidy: ETCDIR=`grep "^sysconfdir=" Makefile | sed 's/sysconfdir=//'` prefix=`grep "^prefix=" Makefile | cut -d = -f 2` PIDDIR=`grep "^piddir=" Makefile | cut -d = -f 2` SRCDIR=`grep "^srcdir=" Makefile | cut -d = -f 2` eval ETCDIR=$ETCDIR I used someting like this, however it does mean a couple of search-and-replaces (eg ETCDIR -> sysconfdir): for confvar in prefix exec_prefix bindir sbindir libexecdir datadir mandir sysconfdir piddir do eval $confvar=`grep "^$confvar=" Makefile | cut -d = -f 2` done -Daz. From dtucker at zip.com.au Tue Mar 5 20:50:13 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Mar 2002 20:50:13 +1100 Subject: Support for AIX native (.bff) packages: patch available References: Message-ID: <3C8494D5.FEFDCAE5@zip.com.au> Ben Lindstrom wrote [about AIX package build]: > This is now included in the CVS tree since it does not have any > current dependances, and will be included in 3.1 release. Excellent! I've just pulled the CVS tree to run through it. I'll keep an eye on it in future for breakage. I have one suggestion though: chmod a+x contrib/aix/*.sh Thanks, -Daz. From Zoran.Milojevic at SS8.com Wed Mar 6 01:23:44 2002 From: Zoran.Milojevic at SS8.com (Zoran Milojevic) Date: Tue, 5 Mar 2002 09:23:44 -0500 Subject: Update to solaris package creation Message-ID: <8BAF8B40C4D2D411ADC300508BD63D6901A38E11@mail.ss8.ca> How about adding: [ "$POST_INS_START" = "yes" ] && PRE_INST_STOP=yes somewhere before the whole "preinstall" thing, so that start does not fail if there is another sshd running? (it will fail anyway if the running sshd has a startup script with a different name, but we can at least try) I would also omit checking the startup script existence in postinstall, or at least print some nasty looking error message if it is not there. Just don't fail silently. Cheers, Zoran -- Zoran Milojevic SS8 Networks Inc. http://www.ss8.com "One Better" Tel: +1-613-592-2100/x3231 Fax: +1-613-592-9634 From jason at heddings.com Wed Mar 6 02:52:31 2002 From: jason at heddings.com (jason heddings) Date: Tue, 5 Mar 2002 08:52:31 -0700 Subject: sftp-server configuration Message-ID: Hello! I am fairly new to using sftp and had a question regarding its configuration. Many ftp servers allow you to restrict user access to a particular directory and when a user logs in, s/he cannot move outside of that directory path. Most of the time, they cannot even see what directory path they are in. Is this possible to do with sftp-server? Thanks! --Jason From jkau at jasper.k12.ga.us Wed Mar 6 08:05:33 2002 From: jkau at jasper.k12.ga.us (Jason Kau) Date: Tue, 5 Mar 2002 16:05:33 -0500 Subject: Fwd: SFTP and alphabetical directory listings Message-ID: <1015362333.3c85331dcdc88@mail.jasper.k12.ga.us> Hello, I apologize if this is not the appropriate mailing list for this question. Is there a reason why the "sftp" client included with OpenSSH does not present an alphabetical listing of files when you do "ls"? I use the OpenSSH 3.0.2p1 "sftp" client on Linux, Solaris, AIX, and Digital UNIX. Is this the expected behavior and is there any way to make it do alphabetical directory listings or do I need to delve into the code and add this functionality myself? Thanks! -- Jason Kau Consultant Jasper County Schools Monticello, GA From gvinjamu at cceb.upenn.edu Wed Mar 6 08:13:34 2002 From: gvinjamu at cceb.upenn.edu (Govind Vinjamuri) Date: Tue, 05 Mar 2002 16:13:34 -0500 Subject: sftp Message-ID: <3C8534FE.9A18B671@cceb.upenn.edu> I am having setting up sftp, using openssh 2.92 on solaris. the sshd_config has subsystem sftp as /usr/local/libexec/sftp-server and I donot have libexec under /usr/local is sftpa seperate package I need to configure thanks in advance From stevesk at pobox.com Wed Mar 6 12:08:03 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 5 Mar 2002 17:08:03 -0800 (PST) Subject: Fwd: SFTP and alphabetical directory listings In-Reply-To: <1015362333.3c85331dcdc88@mail.jasper.k12.ga.us> Message-ID: On Tue, 5 Mar 2002, Jason Kau wrote: :Is there a reason why the "sftp" client included with OpenSSH does not present :an alphabetical listing of files when you do "ls"? no one has written code to do that yet. :I use the OpenSSH 3.0.2p1 "sftp" client on Linux, Solaris, AIX, and Digital :UNIX. Is this the expected behavior and is there any way to make it do :alphabetical directory listings or do I need to delve into the code and add :this functionality myself? the latter. From mouring at etoh.eviladmin.org Wed Mar 6 14:29:40 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 5 Mar 2002 21:29:40 -0600 (CST) Subject: Update to solaris package creation In-Reply-To: Message-ID: Over all it looks fine.. only comment I have is preremove and preinstall scripts should not exist if you tell it not to start/stop OpenSSH from the package. If they do exist then the admin be prompted.. With the default 'n' if your doing a non-attendented install. Mainly because build time is not the correct time to decide if OpenSSH should be started or stopped. Again we revert back to Admin's (installer) choice. One could argue the same about hardlinks vs softlinks also.. But I won't make it since I don't care. =) - Ben On Mon, 4 Mar 2002, Tim Rice wrote: > > Here is a new buildpkg.sh for your review before commiting to CVS. > THe patch was larger than the script so I've attached the complete script. > > Changes: > > This should now work on any system that has SVR4 style package tools. > It now requires that you run it from your build dir. (you might have > a read only source tree). > > CATAGORY="Security,application" > > Solaris 8 man page says > CATEGORY* > A comma-separated list of categories under which a > package may be displayed. A package must at least > ^^^^ > belong to the system or application category. > > One could argue that it should be system instead of application. > > Added and enhanced Antonio Navarro's awk mods. > > - modified the awk script that filters the prototype so that the system > > directories are marked as shared (using ? for permissions, owner and group) > All system directories listed in SYSTEM_DIR= will have ? ? ? > Now using nawk because on Solaris, awk is the old version. > > There are now some options on building your package. > You can change the options in buildpkg.sh or create a config.local > file in your build dir that buildpkg.sh will source of it exists. > SYSVINIT_NAME=opensshd (Some might prefer sshd) > USE_SYM_LINKS=no > The consensus was use hard links on the init scripts. > Set to yes for sym links. > > PRE_INS_STOP=no If you want preinstall to stop sshd > POST_INS_START=no If you want postinstall to start sshd > MAKE=${MAKE:="make"} In case your system make is brain dead > > > I've added a preremove that will stop sshd before removing it. > > I've renamed the config files so multiple installs will not overwrite. > (Thanks to Darren Tucker for reminding me about ssh_prng_cmds) > > Added some logic to deal with systems that don't have /etc/rcS.d > > Fixed the pkgmk, pkgtrans parts to work on Solaris and other systems. > > Enjoy. > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > From Ulrich.Windl at rz.uni-regensburg.de Wed Mar 6 18:42:38 2002 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 6 Mar 2002 08:42:38 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys Message-ID: <3C85D67D.14958.26F9B4@localhost> Hello, I think I found a problem that should not happen: An OpenSSH client v3.0.2 on Solaris and an OpenSSH server 2.3.0p1 on HP- UX had a problem when authenticating: Password login worked fine, but a password for an existing and configured RSA1 key was never asked, the key never tried. It always fell back to plain password authentication. After fiddling with the client configuration without success, I found out that using "ssh -1" made the client succeed. So I can only guess that this is a failure to negotiate a common protocol. I thin kthat my installation is correct, but I found some odd messages in syslog of the server during these tests: sshd[24574]: WARNING: /usr/local/etc/primes does not exist, using old prime sshd[4319]: bad pkalg ssh-rsa sshd[7157]: Bad options in .ssh/authorized_keys file, line 2: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2lTEPCqTfl5Umv Regards, Ulrich From gert at greenie.muc.de Wed Mar 6 19:29:14 2002 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 6 Mar 2002 09:29:14 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <3C85D67D.14958.26F9B4@localhost>; from Ulrich Windl on Wed, Mar 06, 2002 at 08:42:38AM +0100 References: <3C85D67D.14958.26F9B4@localhost> Message-ID: <20020306092914.A11526@greenie.muc.de> Hi, On Wed, Mar 06, 2002 at 08:42:38AM +0100, Ulrich Windl wrote: > Password login worked fine, but a password for an existing and > configured RSA1 key was never asked, the key never tried. It always > fell back to plain password authentication. > > After fiddling with the client configuration without success, I found > out that using "ssh -1" made the client succeed. RSA1 keys won't be used on "-2" connections, they're protocol 1 only. So without "-1" you effectively do not *have* a key, and thus ssh won't ask you for a password. 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 Ulrich.Windl at rz.uni-regensburg.de Wed Mar 6 20:13:15 2002 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 6 Mar 2002 10:13:15 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <20020306092914.A11526@greenie.muc.de> References: <3C85D67D.14958.26F9B4@localhost>; from Ulrich Windl on Wed, Mar 06, 2002 at 08:42:38AM +0100 Message-ID: <3C85EBBA.22462.79F00E@localhost> On 6 Mar 2002, at 9:29, Gert Doering wrote: > Hi, > > On Wed, Mar 06, 2002 at 08:42:38AM +0100, Ulrich Windl wrote: > > Password login worked fine, but a password for an existing and > > configured RSA1 key was never asked, the key never tried. It always > > fell back to plain password authentication. > > > > After fiddling with the client configuration without success, I found > > out that using "ssh -1" made the client succeed. > > RSA1 keys won't be used on "-2" connections, they're protocol 1 only. > > So without "-1" you effectively do not *have* a key, and thus ssh won't > ask you for a password. However if you disable plain password in the client's configuration, no connection can be made using the auto-negotiated protocol, while the v1 protocol would work just fine. The problem seems to be that OpenSSH uses version numbers to decide about features, while an explicit feature list would be the way to go. OpenSSH will never know all the implementations of the SSH protocol. Ulrich From gert at greenie.muc.de Wed Mar 6 21:50:59 2002 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 6 Mar 2002 11:50:59 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <3C85EBBA.22462.79F00E@localhost>; from Ulrich Windl on Wed, Mar 06, 2002 at 10:13:15AM +0100 References: <3C85D67D.14958.26F9B4@localhost>; <20020306092914.A11526@greenie.muc.de> <3C85EBBA.22462.79F00E@localhost> Message-ID: <20020306115059.A19924@greenie.muc.de> Hi, On Wed, Mar 06, 2002 at 10:13:15AM +0100, Ulrich Windl wrote: > > > Password login worked fine, but a password for an existing and > > > configured RSA1 key was never asked, the key never tried. It always > > > fell back to plain password authentication. > > > > > > After fiddling with the client configuration without success, I found > > > out that using "ssh -1" made the client succeed. > > > > RSA1 keys won't be used on "-2" connections, they're protocol 1 only. > > > > So without "-1" you effectively do not *have* a key, and thus ssh won't > > ask you for a password. > > However if you disable plain password in the client's configuration, no > connection can be made using the auto-negotiated protocol, while the v1 > protocol would work just fine. That's the way it is. V2 is the default now (documented in the release notes to 2.9, if I remember correctly), and it won't use V1 keys. > The problem seems to be that OpenSSH uses version numbers to decide > about features, while an explicit feature list would be the way to go. > OpenSSH will never know all the implementations of the SSH protocol. I can't follow you here. The server states what protocols it can do, and the client knows which one it prefers in case there are multiple options. If you want to stay with protocol 1 for servers that support it, put "protocol 1,2" into your ssh_config file. Then ssh will default to "-1" and fall back to "-2" for servers that don't support ssh protocol 1 (and of course your key won't work then, no matter how much you complain - protocol 1 keys *do not work* with protocol 2). 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 Ulrich.Windl at rz.uni-regensburg.de Wed Mar 6 21:58:40 2002 From: Ulrich.Windl at rz.uni-regensburg.de (Ulrich Windl) Date: Wed, 6 Mar 2002 11:58:40 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <20020306115059.A19924@greenie.muc.de> References: <3C85EBBA.22462.79F00E@localhost>; from Ulrich Windl on Wed, Mar 06, 2002 at 10:13:15AM +0100 Message-ID: <3C86046F.23105.DA74F2@localhost> On 6 Mar 2002, at 11:50, Gert Doering wrote: > Hi, > > On Wed, Mar 06, 2002 at 10:13:15AM +0100, Ulrich Windl wrote: > > > > Password login worked fine, but a password for an existing and > > > > configured RSA1 key was never asked, the key never tried. It always > > > > fell back to plain password authentication. > > > > > > > > After fiddling with the client configuration without success, I found > > > > out that using "ssh -1" made the client succeed. > > > > > > RSA1 keys won't be used on "-2" connections, they're protocol 1 only. > > > > > > So without "-1" you effectively do not *have* a key, and thus ssh won't > > > ask you for a password. > > > > However if you disable plain password in the client's configuration, no > > connection can be made using the auto-negotiated protocol, while the v1 > > protocol would work just fine. > > That's the way it is. V2 is the default now (documented in the release > notes to 2.9, if I remember correctly), and it won't use V1 keys. > > > The problem seems to be that OpenSSH uses version numbers to decide > > about features, while an explicit feature list would be the way to go. > > OpenSSH will never know all the implementations of the SSH protocol. > > I can't follow you here. The server states what protocols it can do, and > the client knows which one it prefers in case there are multiple options. If the server can do v1 RSA keys, and the client can, but the server cannot do v2 password, why is the "default" used, and not the negotiated (i.e. v1 RSA key). I mean protocol version is one constant, but security policy is a variable. If the server announces to accept RSA1 keys, and the client can use it, why not? > > If you want to stay with protocol 1 for servers that support it, put > > "protocol 1,2" > > into your ssh_config file. Then ssh will default to "-1" and fall back to > "-2" for servers that don't support ssh protocol 1 (and of course your > key won't work then, no matter how much you complain - protocol 1 keys > *do not work* with protocol 2). Almost: If the client would fall back to v1 if v2 failed to establish a connection (no authentication method available), it would be fine. If a good negotiation took place, the right protocol would be used automatically. I still think that at least within OpenSSH the compatibility should be as good as possible. Ulrich From gert at greenie.muc.de Wed Mar 6 22:11:16 2002 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 6 Mar 2002 12:11:16 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <3C86046F.23105.DA74F2@localhost>; from Ulrich Windl on Wed, Mar 06, 2002 at 11:58:40AM +0100 References: <3C85EBBA.22462.79F00E@localhost>; <20020306115059.A19924@greenie.muc.de> <3C86046F.23105.DA74F2@localhost> Message-ID: <20020306121116.B19924@greenie.muc.de> Hi, On Wed, Mar 06, 2002 at 11:58:40AM +0100, Ulrich Windl wrote: > > > The problem seems to be that OpenSSH uses version numbers to decide > > > about features, while an explicit feature list would be the way to go. > > > OpenSSH will never know all the implementations of the SSH protocol. > > > > I can't follow you here. The server states what protocols it can do, and > > the client knows which one it prefers in case there are multiple options. > > If the server can do v1 RSA keys, and the client can, but the server > cannot do v2 password, why is the "default" used, and not the > negotiated (i.e. v1 RSA key). Protocol version is negotiated before authentication variants are negotiated, and there is no way to query the server "which authentication versions can you do for which protocol". As such, RSA1 key is NOT "the negotiated". Doesn't strike me as too useful anyway - why would anyone permit password for v1 and not for v2 or vice versa? > I mean protocol version is one constant, but security policy is a > variable. If the server announces to accept RSA1 keys, and the client > can use it, why not? Protocol first, authentication options *inside* that protocol. [..] > Almost: If the client would fall back to v1 if v2 failed to establish a > connection (no authentication method available), it would be fine. If a > good negotiation took place, the right protocol would be used > automatically. The protocol doesn't permit this (and this is nothing the OpenSSH people can affect, the IETF secsh people are the one to change this). 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 markus at openbsd.org Wed Mar 6 22:21:13 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 6 Mar 2002 12:21:13 +0100 Subject: Compatibility issue: OpenSSH v2.3.0p1 vs. 3.0.2: RSA keys In-Reply-To: <3C86046F.23105.DA74F2@localhost> References: <3C85EBBA.22462.79F00E@localhost> <3C86046F.23105.DA74F2@localhost> Message-ID: <20020306112113.GC28777@faui02> the problem is that protocol version negotiation and authentication method negotiation are not related. the server offers all protocol versions it supports. then the client decides with version to use. then client tries all available authentication methods for this protocol. with 'Protocol 2,1' in ssh_config the client will always use protocol v2 if the server supports this. at this point the client does not know what authentication methods the server will allow. what you probably want is try ssh2 with pubkey try ssh1 with pubkey try ssh2 with password try ssh1 with password but this won't work. try ssh1 with pubkey i see no simple solution to your problem. From bugzilla-daemon at mindrot.org Thu Mar 7 11:28:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Mar 2002 11:28:45 +1100 (EST) Subject: [Bug 125] with BSM auditing, cron editing thru ssh session causes cron jobs to fail Message-ID: <20020307002845.594B1E8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=125 ------- Additional Comments From stevesk at pobox.com 2002-03-07 11:28 ------- Sun has not yet provided patches for BSM. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Thu Mar 7 16:07:27 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 07 Mar 2002 16:07:27 +1100 Subject: Terminal periodically hangs References: Message-ID: <3C86F58F.3080009@mindrot.org> Timothy Machuga wrote: > > Ssh connects and authenticates correctly, but sessions periodically hang > for minutes at a time. Are you sure you don't have packet loss between the two endpoints? I haven't seen this problem. -d From djm at mindrot.org Thu Mar 7 16:11:43 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 07 Mar 2002 16:11:43 +1100 Subject: Fwd: SFTP and alphabetical directory listings References: <1015362333.3c85331dcdc88@mail.jasper.k12.ga.us> Message-ID: <3C86F68F.8050206@mindrot.org> Jason Kau wrote: > Hello, > > I apologize if this is not the appropriate mailing list for this question. > > Is there a reason why the "sftp" client included with OpenSSH does not present > an alphabetical listing of files when you do "ls"? No one has written support for it. The "ls" implementation is very basic at the moment, we just take whatever the server sends us, in what ever order they send it. Ideally the ls should be rewritten to use the remote glob() function supplied by sftp-glob.[ch] and generate the long listings itself, rather than use the longname attribute from the server. This would make it possible to do things like "ls -l *.foo", "ls -C", etc. I suspect that the longname attribute will be going away in a future rev of the filexfer draft anyway, so such a rewrite will need to happy eventually. -d From djm at mindrot.org Thu Mar 7 16:12:40 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 07 Mar 2002 16:12:40 +1100 Subject: sftp References: <3C8534FE.9A18B671@cceb.upenn.edu> Message-ID: <3C86F6C8.30002@mindrot.org> Govind Vinjamuri wrote: > I am having setting up sftp, using openssh 2.92 on solaris. > > the sshd_config has subsystem sftp as /usr/local/libexec/sftp-server and > I donot have libexec under /usr/local > > is sftpa seperate package I need to configure No, it should have been installed. How did you install OpenSSH? -d From bugzilla-daemon at mindrot.org Thu Mar 7 20:15:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Mar 2002 20:15:41 +1100 (EST) Subject: [Bug 135] New: Sudden freeze of SSH2 on clients from masqueraded subnet (behind firewall) Message-ID: <20020307091541.B7382E916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=135 Summary: Sudden freeze of SSH2 on clients from masqueraded subnet (behind firewall) 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: walter at techfak.uni-bielefeld.de Background: sshd openssh-2.9.9p2,openssh-3.0.2 only SSH2 (former ssh SSH1) ssh openssh-2.9.9p2 (former openssh-2.2??) server [C0] OS Linux 2.4.10-4GB-SMP firewall [C1] OS Linux 2.2.16 with ipchains masquerading [C2] client [C2] OS Linux 2.2.16 behind [C1] tcp/ip via pppoe on aDSL Since general upgrades to openssh-2.9.9p2 (same with sshd/openssh-3.0.2) the SSH2 (RSA-auth) connection from [C2] client behind the firewall [C1] to server [C0] freezes suddenly. This occurs repeatable when return packets get large (e.g. "ls -l" in big dirs, or "cvs update"). Before the connection was set up properly and worked for small packets. At the same time ssh-connections between [C1] and [C0] are not affected (both directions). Packet-logging on ppp did not show anything. Opening-up the firewall rules did not help. Any help is greatly appreciated Thanks in advance ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Thu Mar 7 22:55:57 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:55:57 +0100 Subject: OpenSSH 3.1 released Message-ID: <20020307115557.GA8914@faui02> OpenSSH 3.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== - /etc/ssh/ now default directory for keys and configuration files - ssh-keygen no longer defaults to a specific key type (rsa1); use ssh-keygen -t {rsa,dsa,rsa1} - sshd x11 forwarding listens on localhost by default; see sshd X11UseLocalhost option to revert to prior behaviour if your older X11 clients do not function with this configuration Other Changes: ============== - ssh ~& escape char functions now for both protocol versions - sshd ReverseMappingCheck option changed to VerifyReverseMapping to clarify its function; ReverseMappingCheck can still be used - public key fingerprint is now logged with LogLevel=VERBOSE - reason logged for disallowed logins (e.g., no shell, etc.) - more robust error handling for x11 forwarding - improved packet/window size handling in ssh2 - use of regex(3) has been removed - fix SIGCHLD races in sshd (seen on Solaris) - sshd -o option added - sftp -B -R -P options added - ssh-add now adds all 3 default keys - ssh-keyscan bug fixes - ssh-askpass for hostkey dialog - fix fd leak in sshd on SIGHUP - TCP_NODELAY set on X11 and TCP forwarding endpoints OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From pekkas at netcore.fi Fri Mar 8 02:00:53 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 7 Mar 2002 17:00:53 +0200 (EET) Subject: OpenSSH Security Advisory (adv.channelalloc) (fwd) Message-ID: whoops, not announce. -- 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 ---------- Forwarded message ---------- Date: Thu, 7 Mar 2002 16:59:38 +0200 (EET) From: Pekka Savola To: Markus Friedl Cc: openssh-unix-announce at mindrot.org Subject: Re: OpenSSH Security Advisory (adv.channelalloc) On Thu, 7 Mar 2002, Markus Friedl wrote: > 2. Impact: > > This bug can be exploited locally by an authenticated user > logging into a vulnerable OpenSSH server Can you elaborate a bit what this means..? I'm mostly puzzled about the use of the word 'locally' as it seems to contradict with logging into, unless e.g. IP source and destination must be equal or something. -- 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 provos at citi.umich.edu Fri Mar 8 02:05:49 2002 From: provos at citi.umich.edu (Niels Provos) Date: Thu, 7 Mar 2002 10:05:49 -0500 Subject: OpenSSH Security Advisory (adv.channelalloc) (fwd) In-Reply-To: References: Message-ID: <20020307150549.GI13197@citi.citi.umich.edu> On Thu, Mar 07, 2002 at 05:00:53PM +0200, Pekka Savola wrote: > On Thu, 7 Mar 2002, Markus Friedl wrote: > > 2. Impact: > > > > This bug can be exploited locally by an authenticated user > > logging into a vulnerable OpenSSH server > > Can you elaborate a bit what this means..? I'm mostly puzzled about the > use of the word 'locally' as it seems to contradict with logging into, > unless e.g. IP source and destination must be equal or something. You need an account on the machine. That is equivalent to a local attack even if you need to initiate a network connection. The channel forwarding happens only after authentication. Niels. From bugzilla-daemon at mindrot.org Fri Mar 8 03:16:13 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 03:16:13 +1100 (EST) Subject: [Bug 136] New: setgid() deemed to fail for non-suid ssh client on linux if using other than primary group Message-ID: <20020307161613.1E4D9E95E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=136 Summary: setgid() deemed to fail for non-suid ssh client on linux if using other than primary group 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: daniel.mueller at tm.uka.de On Linux (at least -- I don?t know about BSD), trying to use a non-suid-root ssh client while having switched to a group other than the calling user's primary group (by sg or newgrp) fails with an error message: setgid : Operation not permitted Looking for the reason of the failure, I found it in the function permanently_set_uid() in uidswap.c: It tries to set the gid to the value from /etc/passwd, which (at least on Linux) can only succeed if either the process has superuser privileges (the binary is installed suid root) or the real or effective gid is already that value. If a user is currently using a gid of a group that she is member of but which isn't her primary group from /etc/passwd, setgid() fails. A solution could be either - to do nothing in permanently_set_uid() when euid != 0 (this is similar to the behaviour of temporarily_use_uid()). I'll append the short patch for this; I'm using it as a quick solution. - or to set the uid/gid to the real uid/gid, thereby dropping any privileges that a suid-non-root binary might have. This might be a bit cleaner and needs a little more changing (I haven't done this yet, but can do on demand). Regards, Daniel M?ller --- uidswap.c~ Thu Aug 16 01:17:22 2001 +++ uidswap.c Thu Mar 7 16:12:25 2002 @@ -147,6 +147,7 @@ { if (temporarily_use_uid_effective) fatal("restore_uid: temporarily_use_uid effective"); + if (geteuid() != 0) return; if (setgid(pw->pw_gid) < 0) fatal("setgid %u: %.100s", (u_int) pw->pw_gid, strerror(errno)); if (setuid(pw->pw_uid) < 0) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 03:19:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 03:19:00 +1100 (EST) Subject: [Bug 137] New: 'make install' fails because of missing uudecode Message-ID: <20020307161900.3DEDBE96B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=137 Summary: 'make install' fails because of missing uudecode Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: info at fortytwo.eu.org make[1]: Entering directory `/usr/src/openssh-3.0.2p1-patched/scard' uudecode Ssh.bin.uu make[1]: uudecode: Command not found make[1]: *** [Ssh.bin] Error 127 make[1]: Leaving directory `/usr/src/openssh-3.0.2p1-patched/scard' make: *** [scard-install] Error 2 It is not mentioned in the FAQ/in README and INSTALL that uudecode is needed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 03:47:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 03:47:25 +1100 (EST) Subject: [Bug 138] New: Incorrect OpenSSL version requirment? Message-ID: <20020307164725.DDCE4E96B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 Summary: Incorrect OpenSSL version requirment? Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: weldon at excelsus.com In the "INSTALL" file of the portible 3.1p1. It says you will need: "OpenSSL 0.9.5a or greater:" On Linux and FreeBSD, I cannot get it to compile with SSL lower than 0.9.6 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:14:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:14:26 +1100 (EST) Subject: [Bug 139] New: OpenSSH portable build fails on linux in 3.1p1 due to missing declarations Message-ID: <20020307171426.A3283E96E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=139 Summary: OpenSSH portable build fails on linux in 3.1p1 due to missing declarations Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P1 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: vjo at dulug.duke.edu The openssh portable build for 3.1p1 fails, due to the missing function EVP_CIPHER_CTX_set_key_length and missing declarations for EVP_CIPH_CBC_MODE, EVP_CIPH_VARIABLE_LENGTH, and EVP_CIPH_ALWAYS_CALL_INIT. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:49:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:49:50 +1100 (EST) Subject: [Bug 139] OpenSSH portable build fails on linux in 3.1p1 due to missing declarations Message-ID: <20020307174950.C782DE976@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=139 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From mouring at eviladmin.org 2002-03-08 04:49 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:49:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:49:55 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020307174955.95984E977@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vjo at dulug.duke.edu ------- Additional Comments From mouring at eviladmin.org 2002-03-08 04:49 ------- *** Bug 139 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:51:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:51:21 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020307175121.72C12E977@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From mouring at eviladmin.org 2002-03-08 04:51 ------- Documentation has been corrected. Yes 0.9.6 is required at this time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:51:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:51:47 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020307175147.908F7E97F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2002-03-08 04:51 ------- Documentation has been corrected. Yes 0.9.6 is required at this time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 04:53:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 04:53:24 +1100 (EST) Subject: [Bug 140] New: Solaris 8 cannot create pkg in OpenSSH 3.1p1 Message-ID: <20020307175324.E59D9E98A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=140 Summary: Solaris 8 cannot create pkg in OpenSSH 3.1p1 Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mozilla at mediaone.net Hello, I have just successfully compiled OpenSSH 3.1p1 and tried to create the Solaris pkg from contrib/solaris/buildpkg.sh, all is fine, seeing as this machine had OpenSSH 3.0.2p1 installed. However when running the buildpkg.sh script I error out with this Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 05:26:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 05:26:16 +1100 (EST) Subject: [Bug 141] New: openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020307182616.9048FE978@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 Summary: openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wayne at qconcepts.net When rebuilding openssh-3.1p1-1.src.rpm, on a RedHat Linux 6.1 machine, the following error occurs: i386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall -Wpointer-arith -Wno- uninitialized -I. -I. -DSSHDIR=\"/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 cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.2018 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.2018 (%build) On this build, the following changes have been made on the openssh.spec file: # Do we want to disable building of x11-askpass? (1=yes 0=no) %define no_x11_askpass 1 # Do we want to disable building of gnome-askpass? (1=yes 0=no) %define no_gnome_askpass 1 # Do we want to link against a static libcrypto? (1=yes 0=no) %define static_libcrypto 0 # Do we want smartcard support (1=yes 0=no) %define scard 0 # Use Redhat 7.0 pam control file # %define redhat7 0 The machine has the following library versions: glibc-profile-2.1.3-23 compat-glibc-5.2-2.0.7.1 glib-1.2.6-2 glib-devel-1.2.6-2 glib10-1.0.6-6 glibc-devel-2.1.2-11 glibc-2.1.3-23 rpm-4.0.2-6x rpm-devel-4.0.2-6x openssl-0.9.5a-7.6.x openssl-misc-0.9.5a-3 openssl-devel-0.9.5a-7.6.x ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:19:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:19:17 +1100 (EST) Subject: [Bug 142] New: OpenSSH 3.1 with patch will not build on OpenBSD 2.8 Message-ID: <20020307191917.E0D95E982@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=142 Summary: OpenSSH 3.1 with patch will not build on OpenBSD 2.8 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: OpenBSD Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: stanx at tta.com With patch openbsd28_3.1.patch applied per directions, OpenSSH 3.1 still does not build on OpenBSD 2.8. Error is in cipher.c, see following output from make: lurp# make ===> lib cc -O2 -DKRB4 -I/usr/include/kerberosIV -DAFS -I/usr/src/usr.bin/ssh/lib/.. -c /usr/src/usr.bin/ssh/lib/../cipher.c -o cipher.o /usr/src/usr.bin/ssh/lib/../cipher.c: In function `cipher_init': /usr/src/usr.bin/ssh/lib/../cipher.c:200: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c:210: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c: In function `cipher_crypt': /usr/src/usr.bin/ssh/lib/../cipher.c:220: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c: In function `cipher_cleanup': /usr/src/usr.bin/ssh/lib/../cipher.c:227: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_init': /usr/src/usr.bin/ssh/lib/../cipher.c:280: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:299: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c:300: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c:301: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_cbc': /usr/src/usr.bin/ssh/lib/../cipher.c:314: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:318: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c:319: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c:320: void value not ignored as it ought to be /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_cleanup': /usr/src/usr.bin/ssh/lib/../cipher.c:329: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c: In function `evp_ssh1_3des': /usr/src/usr.bin/ssh/lib/../cipher.c:346: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:347: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:348: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:349: structure has no member named `flags' /usr/src/usr.bin/ssh/lib/../cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) /usr/src/usr.bin/ssh/lib/../cipher.c:349: (Each undeclared identifier is reported only once /usr/src/usr.bin/ssh/lib/../cipher.c:349: for each function it appears in.) /usr/src/usr.bin/ssh/lib/../cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) /usr/src/usr.bin/ssh/lib/../cipher.c: In function `evp_ssh1_bf': /usr/src/usr.bin/ssh/lib/../cipher.c:392: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:394: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_init': /usr/src/usr.bin/ssh/lib/../cipher.c:413: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_cbc': /usr/src/usr.bin/ssh/lib/../cipher.c:440: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_cleanup': /usr/src/usr.bin/ssh/lib/../cipher.c:477: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c: In function `evp_rijndael': /usr/src/usr.bin/ssh/lib/../cipher.c:494: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:495: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:496: warning: assignment from incompatible pointer type /usr/src/usr.bin/ssh/lib/../cipher.c:497: structure has no member named `flags' /usr/src/usr.bin/ssh/lib/../cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) /usr/src/usr.bin/ssh/lib/../cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) /usr/src/usr.bin/ssh/lib/../cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/usr.bin/ssh/lib. *** Error code 1 Stop in /usr/src/usr.bin/ssh. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:24:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:24:21 +1100 (EST) Subject: [Bug 143] New: Add reference to "rsync" in FAQ and documentation. Message-ID: <20020307192421.1BE9FE986@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=143 Summary: Add reference to "rsync" in FAQ and documentation. Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dwheeler at dwheeler.com There have been a number of people who want to copy only changed files using the OpenSSH toolkit. Please add the following text to the FAQ and the scp man page, so that people will know how to do it: How can I copy just the changed files? One way to copy only the changed files using OpenSSH is by using another package named "rsync". rsync can transfer just the differences between two sets of files, and can use "ssh" to implement it. For example, to copy the changed files from the local directory /home/joe/stuff (and its descendants) to the user joeuser at computer joe.com, directory /home/joeuser/stuff, do this: rsync -a --rsh="ssh" /home/joe/stuff joeuser at joe.com:/home/joeuser/stuff The "-a" option tries to make everything the same on the remote system (including symbolic links, permissions, and timestamps), and the "--rsh" option indicates that ssh should be used as the (secure) transport. Especially useful rsync options include -C (which skips copying certain useless files), -z (which compresses before sending over a network), -v (verbose status information), and --progress (show status of the file transfer). Note that this only works if the remote system has an ssh server, permits the user to log in using ssh, and is at least somewhat Unix-like. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:30:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:30:53 +1100 (EST) Subject: [Bug 142] OpenSSH 3.1 with patch will not build on OpenBSD 2.8 Message-ID: <20020307193053.5A5D6E98A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=142 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|OpenSSH 3.1 with patch will |OpenSSH 3.1 with patch will |not build on OpenBSD 2.8 |not build on OpenBSD 2.8 ------- Additional Comments From markus at openbsd.org 2002-03-08 06:30 ------- a new patch for 2.8/2.7 has been released ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:36:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:36:39 +1100 (EST) Subject: [Bug 139] OpenSSH portable build fails on linux in 3.1p1 due to missing declarations Message-ID: <20020307193639.B60F2E986@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=139 ------- Additional Comments From markus at openbsd.org 2002-03-08 06:36 ------- Created an attachment (id=32) patch for openssl < 0.9.6 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:39:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:39:35 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020307193935.24A97E986@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From markus at openbsd.org 2002-03-08 06:39 ------- does this patch help http://bugzilla.mindrot.org/showattachment.cgi?attach_id=32 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:43:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:43:23 +1100 (EST) Subject: [Bug 144] New: configure.in missing in distributions Message-ID: <20020307194323.F25D4E977@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=144 Summary: configure.in missing in distributions Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bbense at stanford.edu configure.in is missing in the distributed version of 3.1p1. This makes tracking any local modifications extremely difficult. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:49:14 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:49:14 +1100 (EST) Subject: [Bug 144] configure.in missing in distributions Message-ID: <20020307194914.5F03DE9A3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=144 bbense at stanford.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From bbense at stanford.edu 2002-03-08 06:49 ------- Never Mind, I found configure.ac. MORE SLEEP, LESS COFFEE... Sorry for the mistake. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mjs at ams.org Fri Mar 8 06:42:40 2002 From: mjs at ams.org (Matt Studley) Date: Thu, 7 Mar 2002 14:42:40 -0500 (EST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random Message-ID: has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? That release of Solaris was the first (I believe) to incorporate their own /dev/random which OpenSSH 3.1 doesn't seem to like too much. When I run the configure, it reports that Random Number Source is set to use the rand-helper. If I use the ANDIrand Solaris package as my /dev/random, It configures properly (Random Number Source is set to OpenSSL internal ONLY). Has anyone else run into this problem? Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" From bugzilla-daemon at mindrot.org Fri Mar 8 06:50:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:50:26 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020307195026.38D35E9A4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary| openssh-3.1p1-1.src.rpm |openssh-3.1p1-1.src.rpm will |will not build on RedHat |not build on RedHat Linux |Linux 6.1 |6.1 ------- Additional Comments From markus at openbsd.org 2002-03-08 06:50 ------- http://bugzilla.mindrot.org/showattachment.cgi?attach_id=32 does this help? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 06:59:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 06:59:46 +1100 (EST) Subject: [Bug 145] New: sshd fails to increment AIX login failed counter Message-ID: <20020307195946.C4363E9AA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=145 Summary: sshd fails to increment AIX login failed counter Product: Portable OpenSSH Version: -current Platform: Other OS/Version: AIX Status: NEW Severity: security Priority: P1 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mandar at webchat.chatsystems.com Failed password attempts fail to increment the default AIX loginretries counter. This can be used as a password crack exploit on AIX boxes. Fixes to auth1.c, auth2.c, auth.c - # diff -rc auth.c.old auth.c *** auth.c.old Mon Mar 4 20:42:43 2002 --- auth.c Thu Mar 7 14:46:40 2002 *************** *** 231,236 **** --- 231,242 ---- get_remote_ipaddr(), get_remote_port(), info); + + #ifdef WITH_AIXAUTHENTICATE + if (authenticated == 0 && strcmp(method, "password") == 0) + loginfailed(authctxt->user, get_canonical_hostname (options.reverse_mapping_check), "ssh"); + #endif /* WITH_AIXAUTHENTICATE */ + } /* # diff -rc auth1.c.old auth1.c *** auth1.c.old Thu Feb 14 04:39:50 2002 --- auth1.c Thu Mar 7 14:42:34 2002 *************** *** 337,347 **** return; if (authctxt->failures++ > AUTH_FAIL_MAX) { - #ifdef WITH_AIXAUTHENTICATE - loginfailed(authctxt->user, - get_canonical_hostname (options.verify_reverse_mapping), - "ssh"); - #endif /* WITH_AIXAUTHENTICATE */ packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } --- 337,342 ---- # diff -rc auth2.c.old auth2.c *** auth2.c.old Tue Feb 26 13:09:43 2002 --- auth2.c Thu Mar 7 14:42:42 2002 *************** *** 262,272 **** authctxt->success = 1; } else { if (authctxt->failures++ > AUTH_FAIL_MAX) { - #ifdef WITH_AIXAUTHENTICATE - loginfailed(authctxt->user, - get_canonical_hostname (options.verify_reverse_mapping), - "ssh"); - #endif /* WITH_AIXAUTHENTICATE */ packet_disconnect(AUTH_FAIL_MSG, authctxt->user); } methods = authmethods_get(); --- 262,267 ---- ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bfriday at lasierra.edu Fri Mar 8 06:54:42 2002 From: bfriday at lasierra.edu (Brian Friday) Date: Thu, 7 Mar 2002 11:54:42 -0800 (PST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: Yup ran into that problem on two of my servers here. The /dev/random via SUNWski package doesn't get picked up by the configure for openssh. Also manually defining it doesn't result in it being picked up. I've been meaning to switch to ANDIrand for those two servers so I did and everything worked out fine. Not sure why it didn't pick that up... Sincerely, Brian Friday Systems Administrator La Sierra University (909) 785-2554 x2 From mjs at ams.org Fri Mar 8 07:06:21 2002 From: mjs at ams.org (Matt Studley) Date: Thu, 7 Mar 2002 15:06:21 -0500 (EST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: How were you able to manually define /dev/random using 3.1p1? It looks to me like the --with-random= configure option went away in this release. Is this correct, or am I just doing this wrong? Thanks. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Thu, 7 Mar 2002, Brian Friday wrote: > > > Yup ran into that problem on two of my servers here. The /dev/random via > SUNWski package doesn't get picked up by the configure for openssh. Also > manually defining it doesn't result in it being picked up. > > I've been meaning to switch to ANDIrand for those two servers so I did and > everything worked out fine. Not sure why it didn't pick that up... > > Sincerely, > > Brian Friday > Systems Administrator > La Sierra University > (909) 785-2554 x2 > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bfriday at lasierra.edu Fri Mar 8 07:13:02 2002 From: bfriday at lasierra.edu (Brian Friday) Date: Thu, 7 Mar 2002 12:13:02 -0800 (PST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: Hmm... Well if the --with-random has gone away that would explain why my default configure scripts didn't have it pick it up. (now that you mention it I think I remember talk about that being removed...). To keep things standard around my different servers I usually have a executable text file with all my configure options already called: ./configure \ --with-pam \ etc... That way when I just need the source and that .cfg file of mine to go through and compile everything. Course as more programs are getting much better at finding the things they need without my defining them those .cfg files of mine are getting smaller and in some cases totally deleted. But the basic issue is the configure script is not correctly picking up the /dev/random I spaced and didn't save the configure information when I was doing my initial configures on those systems. But in all cases end result was the software being configured to use the internal random generator rather than anything else. Sincerely, Brian Friday Systems Administrator La Sierra University (909) 785-2554 x2 From bugzilla-daemon at mindrot.org Fri Mar 8 07:22:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:22:51 +1100 (EST) Subject: [Bug 146] New: OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020307202251.AE706EA27@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 Summary: OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: BSDI Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: spike at indra.com OpenSSH 3.1p1 will not build on BSD/OS 4.2 Two files fail: ssh-agent.c: In function `lookup_identity': ssh-agent.c:135: warning: implicit declaration of function `TAILQ_FOREACH' ssh-agent.c:135: `next' undeclared (first use in this function) ssh-agent.c:135: (Each undeclared identifier is reported only once ssh-agent.c:135: for each function it appears in.) ssh-agent.c:135: syntax error before `{' ssh-agent.c:138: warning: control reaches end of non-void function ssh-agent.c: At top level: ssh-agent.c:111: warning: `idtab_init' defined but not used ssh-agent.c:131: warning: `lookup_identity' defined but not used *** Error code 1 BSDI's lacks TAILQ_FOREACH. While openbsd-compat/fake-queue.h can provide TAILQ_FOREACH, defining HAVE_BOGUS_SYS_QUEUE_H does not work. is included by a number of system includes, causing _SYS_QUEUE_H_ to be defined by the time fake-queue.h is included which in turn ifdefs out all of fake-queue.h. ssh-rand-helper.c: In function `get_random_bytes_prngd': ssh-rand-helper.c:154: `ulong' undeclared (first use in this function) ssh-rand-helper.c:154: (Each undeclared identifier is reported only once ssh-rand-helper.c:154: for each function it appears in.) ssh-rand-helper.c:154: syntax error before `0x7f000001' *** Error code 1 (continuing) defines.h defines: #ifndef INADDR_LOOPBACK #define INADDR_LOOPBACK ((ulong)0x7f000001) #endif It should probably be "u_long". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 07:25:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:25:16 +1100 (EST) Subject: [Bug 147] New: ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Message-ID: <20020307202516.C6A54EA2A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=147 Summary: ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Product: Portable OpenSSH Version: 3.0p1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P4 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Darren.Moffat at Sun.COM This was discovered while testing against Vandyke at Connectathon 2002. The protocol requires that both the client and server understand that passwords can expire. A server can send to the client SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, if the users password has expired draft-ietf-secsh-userauth-15.txt: Section 5 says: Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT allow an expired password to be used for authentication. OpenSSH sshd is compilant with MUST NOT part but doesn't do the SHOULD. If PAM is used on platforms that support it then the correct thing happens since pam_chauthtok is run later on and if that fails the session is disconnected using fatal(). This doesn't need to be changed but it would be nice if it worked as per the draft. Similarly A client may also send a new password in the SSH2_MSG_USERAUTH_REQUEST, OpenSSH's sshd current ignores this and log's not supported. Currently an OpenSSH client receiving SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ from a server will die because that packet is not expected. I have a partial solution for the client side support of recieving a SSH_MSG_USERAUTH_PASSWD_CHANGEREQ but it needs further testing and cleanup. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 07:33:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:33:07 +1100 (EST) Subject: [Bug 148] New: Key Exchange Guesses not supported Message-ID: <20020307203307.9E825EA2C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 Summary: Key Exchange Guesses not supported Product: Portable OpenSSH Version: 3.0p1 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Darren.Moffat at Sun.COM This was discovered at Connectathon 2002 while testing against SSH.COM with their compat flags disabled (they currently don't send guess to any OpenSSH server since they know it isn't implemented). draft-ietf-secsh-transport-13.txt 5. Key Exchange Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. Guess is considered wrong, if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 5.1). Otherwise, the guess is considered to be right and the optimistically sent packet MUST be handled as the first key exchange packet. The current code for kex in OpenSSH assumes that they only acceptable packet is a NEWKEYS by using this code fragment: packet_read_expect(SSH2_MSG_NEWKEYS); SSH2_MSG_KEXDH_INIT can arrive if the other side sends a guess. I have a partial solution (only works if the client guess was our prefered), solution for the server side but this needs client support as well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From vinschen at redhat.com Fri Mar 8 07:29:50 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 7 Mar 2002 21:29:50 +0100 Subject: OpenSSH 3.1 released In-Reply-To: <20020307115557.GA8914@faui02> References: <20020307115557.GA8914@faui02> Message-ID: <20020307212950.D13590@cygbert.vinschen.de> On Thu, Mar 07, 2002 at 12:55:57PM +0100, Markus Friedl wrote: > OpenSSH 3.1 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. I'm seeing a lot of build problems on various systems when reaading this maiiling list. I just want the developers to know that 3.1p1 built cleanly on Cygwin. I've already released it as part of the Cygwin net distribution. Thanks for your work, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From bugzilla-daemon at mindrot.org Fri Mar 8 07:38:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:38:44 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020307203844.3F948EA39@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mouring at eviladmin.org 2002-03-08 07:38 ------- I just went through someone with this problem. And HAVE_BOGUS_SYS_QUEUE_H worked for them. However you must have BOTH HAVE_SYS_QUEUE_H and HAVE_BOGUS_SYS_QUEUE_H set. As for INADDR_LOOPBACK. I'd like to know where on BSD/OS that is defined so we can check and include it correctly. Otherwise the correct fix (which I am verifying with the SCO 3 fokes) is to change it to #define INADDR_LOOPBACK (0x7f000001L) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 07:56:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:56:31 +1100 (EST) Subject: [Bug 147] ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Message-ID: <20020307205631.81B35E977@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=147 ------- Additional Comments From markus at openbsd.org 2002-03-08 07:56 ------- Created an attachment (id=33) does this untested patch help (most of the work by johan.andersson at appgate.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 Fri Mar 8 07:58:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 07:58:21 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020307205821.849B4EA2C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From gleblanc at linuxweasel.com 2002-03-08 07:58 ------- This seems to fix it on my Red Hat Linux 6.2 based system (openssl-0.9.5a) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 08:10:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 08:10:33 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20020307211033.32AF4E9A9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2002-03-08 08:10 ------- packet_read_expect(SSH2_MSG_NEWKEYS); ^^^ hm, i never thought i need to implement this, but now it seems so. but i don't think it's related to this line. i think if the keyinit packet has first_kex_follows set i have to continue parsing the packet.... not sure how to implement this (ugly?) optimization ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From drk at sgi.com Fri Mar 8 08:02:15 2002 From: drk at sgi.com (David Kaelbling) Date: Thu, 07 Mar 2002 16:02:15 -0500 Subject: Irix joblimits failure (was: Re: New snapshot) Message-ID: <3C87D557.BB0A9612@sgi.com> IRIX has a compatibility mechanism that lets you test for optional symbols (like jlimit_start) at run-time. I think these patches will let all all IRIX 6.5 systems build images that will test for job limit support dynamically: --- ./configure.ac Wed Feb 27 01:12:35 2002 +++ ../openssh-3.1p1/./configure.ac Thu Mar 7 15:50:21 2002 @@ -115,7 +115,7 @@ AC_DEFINE(WITH_IRIX_ARRAY) AC_DEFINE(WITH_IRIX_PROJECT) AC_DEFINE(WITH_IRIX_AUDIT) - AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) + AC_DEFINE(WITH_IRIX_JOBS) AC_DEFINE(BROKEN_INET_NTOA) ;; *-*-linux*) --- ./openbsd-compat/port-irix.c Tue Feb 19 15:02:49 2002 +++ ../openssh-3.1p1/./openbsd-compat/port-irix.c Thu Mar 7 15:35:21 2002 @@ -3,13 +3,20 @@ #if defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) || defined(WITH_IRIX_ARRAY) #ifdef WITH_IRIX_PROJECT -#include +# include #endif /* WITH_IRIX_PROJECT */ #ifdef WITH_IRIX_JOBS -#include -#endif +# include +# include +# if !defined(JLIMIT_CPU) +/* Simulate job limit support so we can still test for it at runtime. */ +typedef __int64_t jid_t; +extern jid_t jlimit_startjob(char *, uid_t, char *); +# pragma optional jlimit_startjob +# endif +#endif /* WITH_IRIX_JOBS */ #ifdef WITH_IRIX_AUDIT -#include +# include #endif /* WITH_IRIX_AUDIT */ void @@ -27,10 +34,16 @@ #endif /* WITH_IRIX_JOBS */ #ifdef WITH_IRIX_JOBS - jid = jlimit_startjob(pw->pw_name, pw->pw_uid, "interactive"); - if (jid == -1) - fatal("Failed to create job container: %.100s", + if (_MIPS_SYMBOL_PRESENT(jlimit_startjob)) { + jid = jlimit_startjob(pw->pw_name, pw->pw_uid, "interactive"); + if (jid == -1) { + if (errno == ENOPKG) + jid = 0; + else + fatal("Failed to create job container: %.100s", strerror(errno)); + } + } #endif /* WITH_IRIX_JOBS */ #ifdef WITH_IRIX_ARRAY /* initialize array session */ (Hopefully that didn't get line-wrapped. If it did I can try again.) The JLIMIT_CPU test is to try and recognize when we are compiling on a system without the job limit headers. Thanks, David -- David KAELBLING Silicon Graphics Computer Systems 1 Cabot Rd, suite 250; Hudson, MA 01749 781.839.2157, fax ...2357 From sxw at dcs.ed.ac.uk Fri Mar 8 08:08:06 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Thu, 7 Mar 2002 21:08:06 +0000 (GMT) Subject: Kerberos/GSSAPI and OpenSSH 3.1p1 Message-ID: I've now received a number of enquires about my Kerberos patches for OpenSSH being ported to the 3.1p1 release. I'm currently away from my development systems. I intend upon releasing updated versions of both the protocol v1 Kerberos patch, and the v2 GSSAPI patch upon my return in a week or so's time. This release will include patches courtesy of Nicolas Williams to provide full backwards compatibility with previous v2 patches. Hope that sets some minds to rest. Cheers, Simon From bugzilla-daemon at mindrot.org Fri Mar 8 08:33:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 08:33:32 +1100 (EST) Subject: [Bug 140] Solaris 8 cannot create pkg in OpenSSH 3.1p1 Message-ID: <20020307213332.DB73FEA3B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=140 ------- Additional Comments From mozilla at mediaone.net 2002-03-08 08:33 ------- Ok found the bug, In $openSSH/contrib/solaris/buildpkg.sh line 13: VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` needs to change to line 13: VERSION=`tail -2 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` This fixes the pkgcreation problem on Solaris 8 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 08:34:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 08:34:33 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020307213433.1B825EA47@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From wayne at qconcepts.net 2002-03-08 08:34 ------- This allows the rpm to compile and install; however, sshd is unusable after the install. I get the following errors (from ssh -v): OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 500 geteuid 0 anon 1 debug1: Connecting to foo [x.x.x.x] port 22. debug1: temporarily_use_uid: 500/500 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 500/500 (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 /home/wearl/.ssh/identity type 0 debug1: identity file /home/wearl/.ssh/id_rsa type -1 debug1: identity file /home/wearl/.ssh/id_dsa type -1 debug1: Remote protocol version 1.5, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'foo' is known and matches the RSA1 host key. debug1: Found key in /home/foo/.ssh/known_hosts:6 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x8063550(0x0) I cannot now ssh out of or into this machine. When cipher.c compiles, it still gives the following warnings: i386-redhat-linux-gcc -O2 -march=i386 -mcpu=i686 -Wall -Wpointer-arith -Wno- uninitialized -I. -I. -DSSHDIR=\"/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 cipher.c cipher.c: In function `cipher_init': cipher.c:177: warning: unused variable `klen' cipher.c: In function `ssh1_3des_init': cipher.c:268: warning: assignment from incompatible pointer type cipher.c: In function `ssh1_3des_cbc': cipher.c:297: warning: assignment from incompatible pointer type cipher.c: In function `ssh1_3des_cleanup': cipher.c:311: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:328: warning: assignment from incompatible pointer type cipher.c:329: warning: assignment from incompatible pointer type cipher.c:330: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_bf': cipher.c:373: warning: assignment from incompatible pointer type cipher.c:375: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:421: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:458: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:475: warning: assignment from incompatible pointer type cipher.c:476: warning: assignment from incompatible pointer type cipher.c:477: warning: assignment from incompatible pointer type ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mbrown at adacgeo.com Fri Mar 8 08:36:41 2002 From: mbrown at adacgeo.com (Mike Brown) Date: Thu, 07 Mar 2002 15:36:41 -0600 Subject: 3.1 not there Message-ID: <3C87DD69.668B3CC@adacgeo.com> The mirror links point to openssh-3.1p1.tar.gz, but none of the sites have the file. The Linux RPM files are there though. Just thought you'd like to know, if you don't already. MB -- Mike Brown (mbrown at adacgeo.com) (Soon to be: Michael.L.Brown at Philips.com) ADAC, Madison, WI (Philips Radiation Oncology Systems) Desk: 608-288-6969 Fax: 608-298-2101 You design it, I'll build it! From bugzilla-daemon at mindrot.org Fri Mar 8 09:21:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 09:21:16 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020307222116.F3D98EA2A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From mandar at webchat.chatsystems.com 2002-03-08 09:21 ------- I had the same compile issues under AIX 4.3.3. However, the patch resolved this, and I have no subsequent problems running sshd...just a heads up. - Mandar ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 09:31:03 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 09:31:03 +1100 (EST) Subject: [Bug 145] sshd fails to increment AIX login failed counter Message-ID: <20020307223103.A665CEA33@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=145 ------- Additional Comments From mandar at webchat.chatsystems.com 2002-03-08 09:30 ------- Realized the option structure member name has changed with 3.1p1...new diff for auth.c attached: # diff -rc auth.c auth.c.old *** auth.c Thu Mar 7 16:55:14 2002 --- auth.c.old Mon Mar 4 20:42:43 2002 *************** *** 231,242 **** get_remote_ipaddr(), get_remote_port(), info); - - #ifdef WITH_AIXAUTHENTICATE - if (authenticated == 0 && strcmp(method, "password") == 0) - loginfailed(authctxt->user, get_canonical_hostname (options.verify_reverse_mapping), "ssh"); - #endif /* WITH_AIXAUTHENTICATE */ - } /* --- 231,236 ---- ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gert at greenie.muc.de Fri Mar 8 09:32:46 2002 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 7 Mar 2002 23:32:46 +0100 Subject: SCO 3 / CVS version Message-ID: <20020307233246.A24544@greenie.muc.de> Hi, just to give you a quick "success" note: current portable CVS snapshot builds mostly fine on SCO3. The only remaining problem is truncate() in sftp-server.c - SCO3 can replace ftruncate() with chsize() (detected by configure and works), but has no truncate() equivalent. Run-time testing tomorrow, but I do not expect 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 bugzilla-daemon at mindrot.org Fri Mar 8 10:07:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 10:07:08 +1100 (EST) Subject: [Bug 149] New: --with-random=[FILE] no longer available Message-ID: <20020307230708.416CAEA53@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=149 Summary: --with-random=[FILE] no longer available Product: Portable OpenSSH Version: -current Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: erik.welch at philips.com It is listed as being available in the INSTALL file ($Id: INSTALL,v 1.48 2001/12/27 22:57:34 djm Exp $) "--with-random=/some/file", but does not seem to be available on configure. The following command only finds "--with-rand-helper" ./configure --help |grep random Configuring openssh-3.1p1 with the --with-random=/dev/random flag generates the following messages (among others): Random number source: ssh-rand-helper ssh-rand-helper collects from: Command hashing (timeout 200) WARNING: you are using the builtin random number collection service. Please read WARNING.RNG and request that your OS vendor includes kernel-based random number collection in future versions of your OS. Solaris has a /dev/random package available (SUNWski) in the "Easy Access Server" CD. It is much easier to install than prngd/egd for large environments where we packagify apps for quick installation... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Fri Mar 8 10:24:57 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 8 Mar 2002 10:24:57 +1100 (EST) Subject: [Bug 140] Solaris 8 cannot create pkg in OpenSSH 3.1p1 (fwd) Message-ID: <200203072324.g27NOvr19921@gate.dodgy.net.au> Forwarded message: > In $openSSH/contrib/solaris/buildpkg.sh > line 13: > VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` > needs to change to > line 13: > VERSION=`tail -2 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` > > This fixes the pkgcreation problem on Solaris 8 This affected the AIX package build too (sigh) but I think we'd be better off with: VERSION=`grep SSH_VERSION ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` So next time someone adds an emply line somewhere it won't break again. -Daz. From bugzilla-daemon at mindrot.org Fri Mar 8 10:35:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 10:35:33 +1100 (EST) Subject: [Bug 149] --with-random=[FILE] no longer available Message-ID: <20020307233533.08425EA6B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=149 ------- Additional Comments From djm at mindrot.org 2002-03-08 10:35 ------- The best fix is to rebuild OpenSSL with support for /dev/random built-in. That way all libcrypto-using apps will automatically pick up support for it. As a workaround you can do this: cat << EOF >> ssh-rand-helper.devrandom #!/bin/sh dd if=/dev/random bs=48 count=1 2>/dev/null EOF ./configure [options] --with-rand-helper make cp ssh-rand-helper.devrandom ssh-rand-helper make install ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Fri Mar 8 10:44:18 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 8 Mar 2002 10:44:18 +1100 (EST) Subject: OpenSSH-3.1p1 AIX packaging bug [patch] Message-ID: <200203072344.g27NiIS19970@gate.dodgy.net.au> Hello, The change in release number broke some some assumptions in buildbff.sh: * SSH_VERSION was always on the last line of version.h * The OpenSSH version number would give a valid installp version (which must have four parts). Thanks to Mandar Mirashi for pointing this out. Anyone affected can try the following patch which works for me and hopefully will behave sanely in future. -Daz. diff -c -r openssh-3.1p1/contrib/aix/buildbff.sh openssh-3.1p1-aix/contrib/aix/buildbff.sh *** openssh-3.1p1/contrib/aix/buildbff.sh Tue Mar 5 13:38:37 2002 --- openssh-3.1p1-aix/contrib/aix/buildbff.sh Fri Mar 8 09:08:03 2002 *************** *** 15,23 **** PATH=$PATH:`pwd` # set path for external tools export PATH ! ## Extract common info requires for the 'info' part of the package. ! VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` ! BFFVERSION=`echo $VERSION | sed 's/p/./g'` echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" PKGDIR=package --- 15,34 ---- PATH=$PATH:`pwd` # set path for external tools export PATH ! # ! # Extract common info requires for the 'info' part of the package. ! # AIX requires 4-part version numbers ! # ! VERSION=`grep SSH_VERSION ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` ! MAJOR=`echo $VERSION | cut -f 1 -d p | cut -f 1 -d .` ! MINOR=`echo $VERSION | cut -f 1 -d p | cut -f 2 -d .` ! PATCH=`echo $VERSION | cut -f 1 -d p | cut -f 3 -d .` ! PORTABLE=`echo $VERSION | cut -f 2 -d p` ! if [ "$PATCH" = "" ] ! then ! PATCH=0 ! fi ! BFFVERSION=`printf "%d.%d.%d.%d" $MAJOR $MINOR $PATCH $PORTABLE` echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" PKGDIR=package From eparker at mindsec.com Fri Mar 8 11:08:55 2002 From: eparker at mindsec.com (Erik Parker) Date: Thu, 7 Mar 2002 18:08:55 -0600 (CST) Subject: alternative compression lib? Message-ID: Has anyone looked into a way to disable zlib from openssh or perhaps find another library that can easily be put in place? I did read the back logs of the list, and noticed it mentioned zlib is a fundlemental part of the system, and can not be removed.. For security sake, I wonder if there is anyway around having zlib installed. -Erik From bugzilla-daemon at mindrot.org Fri Mar 8 11:25:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 11:25:52 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020308002552.A6C3EEA59@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From dgp at nist.gov 2002-03-08 11:25 ------- It appears to me that the claim in the INSTALL file that OpenSSH 3.1p1 requires only OpenSSL 0.9.5a or greater is FALSE. As reported in the original description, the cipher.c file of OpenSSH 3.1p1 will not compile against OpenSSL 0.9.5a headers. The "flags" field was not added to the EVP_CIPHER struct until release 0.9.6. After upgrading my OpenSSL installation to 0.9.6c, things were fine. The INSTALL file of OpenSSH should be updated to reflect the dependence on OpenSSL 0.9.6. Additional checks in the ./configure would be a good idea too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mandar at webchat.chatsystems.com Fri Mar 8 11:21:07 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Thu, 7 Mar 2002 18:21:07 -0600 (CST) Subject: --prefix at runtime Message-ID: Does OpenSSH support using a different --prefix at runtime? I have different customers installing ssh in different locations, and I'd really prefer to maintain one build for them, and only have them change their runtime environment as appropriate. Usually, the order is 1. Is --prefix defined on the command line? If not, 2. Is prefix defined via an environment variable? If not, 3. Use compiled in --prefix I was wondering if something similar already exists, or do we need to code this in...haven't dug through the code to check..thanks :-) Mandar Mirashi Maintainer: ftp.undernet.org, Undernet IRC FAQ. ftp://rtfm.mit.edu/pub/usenet/alt.irc.undernet For IRC help/Undernet information, check out http://www.undernet.org From bugzilla-daemon at mindrot.org Fri Mar 8 11:38:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 11:38:29 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020308003829.2F29CEA75@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From spike at indra.com 2002-03-08 11:38 ------- > I just went through someone with this problem. And HAVE_BOGUS_SYS_QUEUE_H > worked for them. However you must have BOTH HAVE_SYS_QUEUE_H and > HAVE_BOGUS_SYS_QUEUE_H set. I tried this, and had no luck. As a test I even removed the #ifdefs in ssh-agent.c to force fake-queue.h to be included. If I'm reading gcc -E right, and it's been a long time since I have, the problem lies in getting included before fake-queue.h. The include path looks like: includes.h -> config.h -> defines.h -> -> -> Then defines _SYS_QUEUE_H_ so that when fake-queue.h, it's all ifdef'ed out (and of course it would explode if both were included). I pasted the define for TAILQ_FOREACH into ssh-agent.c and it compiles fine. So it's probably just a case of finding a more graceful way of doing that. > As for INADDR_LOOPBACK. I'd like to know where on BSD/OS that is defined > so we can check and include it correctly. It's defined in : #ifndef INADDR_LOOPBACK #define INADDR_LOOPBACK (u_long)0x7F000001 #endif I included that in defines.h and it compiled as well. Having done that I installed 3.1p1. The server works fine, but the clients all failed with: (rand child) setuid: Operation not permitted ssh-rand-helper child produced insufficient data Removing the setuid bit from "ssh" solved this problem. Digging a little deeper it looks like original_uid and original_euid are never initialized. ->Spike ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 11:38:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 11:38:01 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020308003801.5FB88EA75@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From jason at rndpkt.org 2002-03-08 11:37 ------- Created an attachment (id=34) Patches openssh.spc in contrib/redhat to check for correct OpenSSL ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 8 11:39:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 11:39:57 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020308003957.390BFEA7D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From jason at rndpkt.org 2002-03-08 11:39 ------- OpenSSH 3.1 required OpenSSL >= 0.9.6. See bugs 138 & 139 as to the updated documentation. I've attached a patch to fix contrib/redhat/openssh.spec to make the RPM dependencies correct. Not sure this covers all the issues here, but I think it does. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Fri Mar 8 12:50:08 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 7 Mar 2002 17:50:08 -0800 (PST) Subject: SCO 3 / CVS version In-Reply-To: <20020307233246.A24544@greenie.muc.de> Message-ID: On Thu, 7 Mar 2002, Gert Doering wrote: > Hi, > > just to give you a quick "success" note: current portable CVS snapshot > builds mostly fine on SCO3. The only remaining problem is truncate() in > sftp-server.c - SCO3 can replace ftruncate() with chsize() (detected by > configure and works), but has no truncate() equivalent. This is a known issue. > > Run-time testing tomorrow, but I do not expect nasty surprises. The sshd server will probably work fine but the ssh client is broken on SCO3. I haven't had time to fix it. It's been a while since I looked at the problem but I think it had to with seteuid() not working as documented on SCO. > > gert > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From mouring at etoh.eviladmin.org Fri Mar 8 13:35:48 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 7 Mar 2002 20:35:48 -0600 (CST) Subject: alternative compression lib? In-Reply-To: Message-ID: What is wrong with zlib? Outside the fact that it has it's share of badly written code. - Ben On Thu, 7 Mar 2002, Erik Parker wrote: > > Has anyone looked into a way to disable zlib from openssh or perhaps find > another library that can easily be put in place? > > I did read the back logs of the list, and noticed it mentioned zlib is a > fundlemental part of the system, and can not be removed.. > > For security sake, I wonder if there is anyway around having zlib > installed. > > -Erik > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jmknoble at pobox.com Fri Mar 8 14:25:33 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 7 Mar 2002 22:25:33 -0500 Subject: --prefix at runtime In-Reply-To: ; from mandar@webchat.chatsystems.com on Thu, Mar 07, 2002 at 06:21:07PM -0600 References: Message-ID: <20020307222533.A12163@zax.half.pint-stowp.cx> Circa 2002-Mar-07 18:21:07 -0600 dixit mandar at webchat.chatsystems.com: : Does OpenSSH support using a different --prefix at runtime? I have : different customers installing ssh in different locations, and I'd really : prefer to maintain one build for them, and only have them change their : runtime environment as appropriate. : : Usually, the order is : : 1. Is --prefix defined on the command line? If not, : : 2. Is prefix defined via an environment variable? If not, : : 3. Use compiled in --prefix : : I was wondering if something similar already exists, or do we need to code : this in...haven't dug through the code to check..thanks :-) The only locations that OpenSSH depends on compiled-in values for are the files in $(sysconfdir). For example: $(sysconfdir)/ssh_config $(sysconfdir)/sshd_config $(sysconfdir)/ssh_known_hosts Check the ssh(1) and sshd(8) man pages for the complete list. Everything else can be installed wherever you'd like. Of course, it takes a bit more trouble to configure things if they don't go in the compile-time location, but there are several different parameters to take care of: ssh: - The location of ssh-askpass. Configurable via the SSH_ASKPASS environment variable. sshd: - The location of sftp-server. Configurable in sshd_config. - The default PATH (needed to find the scp program). Configurable in $(sysconfdir)/environment. - The location of the pidfile. Configurable in sshd_config. etc. Use the man pages. You should be able to do this without modifying source code, as long as $(sysconfdir) remains consistent. -- 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/20020307/58e9767a/attachment.bin From mandar at webchat.chatsystems.com Fri Mar 8 14:50:32 2002 From: mandar at webchat.chatsystems.com (mandar at webchat.chatsystems.com) Date: Thu, 7 Mar 2002 21:50:32 -0600 (CST) Subject: --prefix at runtime In-Reply-To: <20020307222533.A12163@zax.half.pint-stowp.cx> Message-ID: Sigh...unfortunately, my sysconfdir isn't consistent across different customers. Each has his own convention/location for sysconfdir.. I guess I'll have to dig into the source and submit a patch..thanks for the comments.. - Mandar On Thu, 7 Mar 2002, Jim Knoble wrote: > Date: Thu, 7 Mar 2002 22:25:33 -0500 > From: Jim Knoble > To: openssh-unix-dev at mindrot.org > Subject: Re: --prefix at runtime > > Circa 2002-Mar-07 18:21:07 -0600 dixit mandar at webchat.chatsystems.com: > > : Does OpenSSH support using a different --prefix at runtime? I have > : different customers installing ssh in different locations, and I'd really > : prefer to maintain one build for them, and only have them change their > : runtime environment as appropriate. > : > : Usually, the order is > : > : 1. Is --prefix defined on the command line? If not, > : > : 2. Is prefix defined via an environment variable? If not, > : > : 3. Use compiled in --prefix > : > : I was wondering if something similar already exists, or do we need to code > : this in...haven't dug through the code to check..thanks :-) > > The only locations that OpenSSH depends on compiled-in values for are > the files in $(sysconfdir). For example: > > $(sysconfdir)/ssh_config > $(sysconfdir)/sshd_config > $(sysconfdir)/ssh_known_hosts > > Check the ssh(1) and sshd(8) man pages for the complete list. > > Everything else can be installed wherever you'd like. Of course, it > takes a bit more trouble to configure things if they don't go in the > compile-time location, but there are several different parameters to > take care of: > > ssh: > > - The location of ssh-askpass. Configurable via the SSH_ASKPASS > environment variable. > > sshd: > > - The location of sftp-server. Configurable in sshd_config. > > - The default PATH (needed to find the scp program). Configurable > in $(sysconfdir)/environment. > > - The location of the pidfile. Configurable in sshd_config. > > etc. > > Use the man pages. You should be able to do this without modifying > source code, as long as $(sysconfdir) remains consistent. > > -- > jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ > (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) > From jmknoble at pobox.com Fri Mar 8 15:21:00 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 7 Mar 2002 23:21:00 -0500 Subject: --prefix at runtime In-Reply-To: ; from mandar@webchat.chatsystems.com on Thu, Mar 07, 2002 at 09:50:32PM -0600 References: <20020307222533.A12163@zax.half.pint-stowp.cx> Message-ID: <20020307232100.B12163@zax.half.pint-stowp.cx> Circa 2002-Mar-07 21:50:32 -0600 dixit mandar at webchat.chatsystems.com: : Sigh...unfortunately, my sysconfdir isn't consistent across different : customers. Each has his own convention/location for sysconfdir.. How different are the conventions? They can't be that bad. Would symlinks from /etc/ssh suffice? How about browbeating the customers into accepting the standard location (/etc/ssh), reminding them of the benefits that real portability gives them? -- 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/20020307/5f3fcf46/attachment.bin From mcrodenas at sinectis.com.ar Fri Mar 8 15:22:36 2002 From: mcrodenas at sinectis.com.ar (=?iso-8859-1?Q?Myriam_Cinthia_R=F3denas?=) Date: Fri, 8 Mar 2002 01:22:36 -0300 Subject: Openssh for minix Message-ID: <009d01c1c658$e1637d60$a2423bc8@miriamro> Hello. I'm interested in the implement the Openssh for Minix. Can you confirm me if this topic was implemented? Sorry for my english, but it ins't my native language. Thanks in advance, Myriam from Argentina. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020308/fc926248/attachment.html From rutom at batnet.com Fri Mar 8 19:15:20 2002 From: rutom at batnet.com (ncesara) Date: Fri, 8 Mar 2002 00:15:20 -0800 Subject: What's up? lurgi Message-ID: <20020308082746.47710E8EA@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020308/d4c68fdb/attachment.html From tomh at po.crl.go.jp Fri Mar 8 19:41:25 2002 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Fri, 8 Mar 2002 17:41:25 +0900 (JST) Subject: OpenSSH 3.1 released In-Reply-To: <20020307115557.GA8914@faui02> Message-ID: The OpenSSH SRP patch has been updated vs. the latest snapshot that contains the security fix; this patch also applies cleanly to 3.1p1 (you still have to run autoheader and autoconf). See the README.SRP file for configuration and installation instructions. http://freshmeat.net/branches/18592/ From mdb at juniper.net Fri Mar 8 20:39:24 2002 From: mdb at juniper.net (Mark D. Baushke) Date: Fri, 08 Mar 2002 01:39:24 -0800 Subject: Solaris 2.6 needs '#define HAVE_BOGUS_SYS_QUEUE_H 1' to build OpenSSH 3.1p1 Message-ID: <200203080939.g289dPT04169@merlot.juniper.net> I needed to manually add a '#define HAVE_BOGUS_SYS_QUEUE_H 1' to the config.h file to get OpenSSH 3.1p1 to properly build under Solaris 2.6. Without it, the system is included rather than using the openbsd-compat/fake-queue.h and the various TAILQ_* macros are not defined. I suspect that the configure.ac file needs to be updated to add the lines: if test "$sol2ver" -eq 6; then AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) fi under the *-*-solaris* entry. -- Mark From aspa at kronodoc.fi Fri Mar 8 20:44:15 2002 From: aspa at kronodoc.fi (Marko Asplund) Date: Fri, 8 Mar 2002 11:44:15 +0200 (EET) Subject: preferred key exchange methods Message-ID: is there a way of specifying preferred key exchange methods on client end with OpenSSL 3.1 using ssh2? i'm trying to determine which key exchange method is actually being used for a connection but i'm i bit confused by the debug messages: ... 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: 121/256 debug1: bits set: 1553/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host 'foo.faa.fi (128.214.56.84)' can't be established. RSA key fingerprint is 84:e2:3f:20:c4:61:e0:3e:ba:04:f6:62:98:73:97:a0. Are you sure you want to continue connecting (yes/no)? the debug messages indicate Diffie-Hellman key exchange is used but with an RSA key. is this correct? -- aspa From oliver.faenger at cityweb.de Fri Mar 8 22:17:45 2002 From: oliver.faenger at cityweb.de (Oliver =?iso-8859-15?q?F=E4nger?=) Date: Fri, 8 Mar 2002 12:17:45 +0100 Subject: buildpkg.sh in OpenSSH_3.1p1 Message-ID: <200203081117.g28BHjJ01522@linux012.intern.cityweb.de> Hi, version.h in OpenSSH_3.1p1 has an Newline after #define SSH_VERSION "OpenSSH_3.1p1" so tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//' does give back a version number regards Oliver -- Oliver F?nger - Phone +49 201 8501 319 Cityweb Network GmbH & Co. KG Friedrichstr. 12 - Fax +49 201 8501 104 45128 Essen - email oliver.faenger at cityweb.de From phil-openssh-unix-dev at ipal.net Fri Mar 8 22:18:10 2002 From: phil-openssh-unix-dev at ipal.net (Phil Howard) Date: Fri, 8 Mar 2002 05:18:10 -0600 Subject: building openssh executeables mostly statically Message-ID: <20020308111810.GA10267@vega.ipal.net> Is there a configure option to build OpenSSH mostly statically? I want to have openssl libraries statically linked. I'd prefer libc (and related) not be, and libz could go either way. -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/ | ----------------------------------------------------------------- From markus at openbsd.org Fri Mar 8 22:19:46 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 8 Mar 2002 12:19:46 +0100 Subject: preferred key exchange methods In-Reply-To: References: Message-ID: <20020308111946.GA19360@faui02> On Fri, Mar 08, 2002 at 11:44:15AM +0200, Marko Asplund wrote: > is there a way of specifying preferred key exchange methods on client end > with OpenSSL 3.1 using ssh2? you can switch the preferred key type but not key-exchange method. HostKeyAlgorithms Specifies the protocol version 2 host key algorithms that the client wants to use in order of preference. The default for this option is: ``ssh-rsa,ssh-dss''. From bugzilla-daemon at mindrot.org Fri Mar 8 22:34:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 22:34:38 +1100 (EST) Subject: [Bug 150] New: configure option --with-ipaddr-display seems to have no effect Message-ID: <20020308113438.2DD84EAA2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=150 Summary: configure option --with-ipaddr-display seems to have no effect Product: Portable OpenSSH Version: -current Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P3 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: stefan_rodenstein at braun.de On an HP-UX 11.00 server, I used CC=/usr/bin/cc CFLAGS="+DAportable -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib" ./configure \ --prefix=/bag/local --sysconfdir=/etc/ssh --sbindir=/bag/local/bin \ --libexecdir=/bag/local/bin --with-ssl-dir=/bag/openssl \ --with-catman=cat --with-pid-dir=/etc/ssh --with-ipaddr-display to configure openssh-3.1p1, but after start of the new sshd binary and ssh to the HP server, I get rodenss at ginkgo:~$ echo $DISPLAY localhost:13.0 rodenss at ginkgo:~$ xterm X11 connection rejected because of wrong authentication. X connection to localhost:13.0 broken (explicit kill or server shutdown). What I exptected is: rodenss at ginkgo:~$ echo $DISPLAY 10.100.53.39:13.0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From chris.ridd at messagingdirect.com Fri Mar 8 22:35:55 2002 From: chris.ridd at messagingdirect.com (Chris Ridd) Date: Fri, 08 Mar 2002 11:35:55 -0000 Subject: contrib/solaris/buildpkg.sh buglet Message-ID: <372510000.1015587355@bagheera.isode.com> Hi, The line grabbing the version out of version.h is slightly broken in 3.1p1: VERSION=`tail -1 ../../version.h | sed [.....] because there's an extra blank line at the end of version.h. It would be more robust if the script did something like this instead: VERSION=`grep SSH_VERSION ../../version.h | sed [....] Cheers, Chris From bugzilla-daemon at mindrot.org Fri Mar 8 22:50:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Mar 2002 22:50:34 +1100 (EST) Subject: [Bug 150] configure option --with-ipaddr-display seems to have no effect Message-ID: <20020308115034.E3BE0E9B9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=150 ------- Additional Comments From markus at openbsd.org 2002-03-08 22:50 ------- does this help? Important Changes: ================== - sshd x11 forwarding listens on localhost by default; see sshd X11UseLocalhost option to revert to prior behaviour if your older X11 clients do not function with this configuration ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From aspa at kronodoc.fi Fri Mar 8 23:00:18 2002 From: aspa at kronodoc.fi (Marko Asplund) Date: Fri, 8 Mar 2002 14:00:18 +0200 (EET) Subject: small OpenSSH RPM spec patch In-Reply-To: Message-ID: here's a small patch for making it easier to build OpenSSH RPM packages on Linux using an OpenSSL library installed somewhere else than the default location. -- aspa -------------- next part -------------- *** /home1/aspa/openssh.spec Fri Mar 8 13:45:01 2002 --- openssh.spec Fri Mar 8 13:56:37 2002 *************** *** 16,21 **** --- 16,25 ---- # Do we want smartcard support (1=yes 0=no) %define scard 0 + # Specify OpenSSL location. + %define with_openssl_dir 0 + %define openssl_dir /usr + # Use Redhat 7.0 pam control file %define redhat7 0 *************** *** 161,166 **** --- 165,174 ---- EXTRA_OPTS="$EXTRA_OPTS --with-ipv4-default " %endif + %if %{with_openssl_dir} + EXTRA_OPTS="$EXTRA_OPTS --with-ssl-dir=%{openssl_dir} " + %endif + %configure \ --libexecdir=%{_libexecdir}/openssh \ --datadir=%{_datadir}/openssh \ *************** *** 171,177 **** $EXTRA_OPTS %if %{static_libcrypto} ! perl -pi -e "s|-lcrypto|/usr/lib/libcrypto.a|g" Makefile %endif make --- 179,185 ---- $EXTRA_OPTS %if %{static_libcrypto} ! perl -pi -e "s|-lcrypto|%{openssl_dir}/lib/libcrypto.a|g" Makefile %endif make From Kennie.Cruz at ece.uprm.edu Sat Mar 9 01:15:10 2002 From: Kennie.Cruz at ece.uprm.edu (Kennie Cruz) Date: Fri, 08 Mar 2002 10:15:10 -0400 Subject: Problems with Solaris 8 and OpenSSH 3.1p1 Message-ID: <175870508.1015582510@dieleitung.ece.uprm.edu> When compiling the software it breaks with an error on the cipher.c file. Lot's of warnings and error of undeclared stuff. Snippet follows: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -Iyes -I/usr/local/include -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 Any help will be appreciated. From pat at hyene.org Sat Mar 9 01:54:29 2002 From: pat at hyene.org (Patrick Bertholon) Date: Fri, 8 Mar 2002 15:54:29 +0100 (CET) Subject: OpenSSH 3.1p1 compile problem under NetBSD 1.5.2 Message-ID: Hi gurus, I got a problem compiling openssh 3.1p1 (portable version) under NetBSD 1.5.2. on an alpha machine. The problem occurs in cipher.c, where gcc complains about something that looks like openssl symbols... As I'm quite new to the BSD architecture, I don't really know how to fix it. Attached file are: my make log file, and the (gzipped) config.log file. Note that I've also tried the CVS version, and that the same problem occurs. Thx for your help, Patrick P.S.: Please cc me the answers since I'm not on the mailing list ! -------------- next part -------------- (cd openbsd-compat && make) gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) *** Error code 1 Stop. -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/octet-stream Size: 13778 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020308/36c8fa50/attachment.obj From mdb at juniper.net Sat Mar 9 02:06:51 2002 From: mdb at juniper.net (Mark D. Baushke) Date: Fri, 08 Mar 2002 07:06:51 -0800 Subject: Solaris 2.6 needs '#define HAVE_BOGUS_SYS_QUEUE_H 1' to build OpenSSH 3.1p1 In-Reply-To: Mail from "Mark D. Baushke" dated Fri, 08 Mar 2002 01:39:24 PST <200203080939.g289dPT04169@merlot.juniper.net> Message-ID: <200203081506.g28F6pT15557@merlot.juniper.net> After looking more closely the root-cause of the problem was that someone had installed a /usr/local/sys/queue.h file on the system that does not have all of the macros needed for openssh to work properly. (It appears to be a circa 1993 version of the berkeley sys/queue.h file.) So, in the general case, solaris 2.6 should not need the hack I outlined in my previous message. -- Mark > From: "Mark D. Baushke" > Date: Fri, 08 Mar 2002 01:39:24 -0800 > > I needed to manually add a '#define HAVE_BOGUS_SYS_QUEUE_H 1' to the > config.h file to get OpenSSH 3.1p1 to properly build under Solaris > 2.6. Without it, the system is included rather than > using the openbsd-compat/fake-queue.h and the various TAILQ_* macros > are not defined. > > I suspect that the configure.ac file needs to be updated to add the > lines: > > if test "$sol2ver" -eq 6; then > AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > fi > > under the *-*-solaris* entry. > > -- Mark > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From amir at instantis.com Sat Mar 9 02:58:43 2002 From: amir at instantis.com (Amir Hejazi) Date: Fri, 8 Mar 2002 07:58:43 -0800 Subject: [openssh-unix-announce] OpenSSH 3.1 released In-Reply-To: <20020307115557.GA8914@faui02> Message-ID: Good Day All, Would someone please answer why I can NOT get to work scp without passowrd between 2 Solaris boxes with OpenSSH (3.0.2p1) . Thanks very much ... Amir. -----Original Message----- From: openssh-unix-announce-admin at mindrot.org [mailto:openssh-unix-announce-admin at mindrot.org]On Behalf Of Markus Friedl Sent: Thursday, March 07, 2002 3:56 AM To: openssh-unix-announce at mindrot.org; openssh-unix-dev at mindrot.org Cc: lwn at lwn.net; announce at openbsd.org; misc at openbsd.org; dengue at deadly.org; news at linuxsecurity.com; secureshell at securityfocus.com Subject: [openssh-unix-announce] OpenSSH 3.1 released OpenSSH 3.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== - /etc/ssh/ now default directory for keys and configuration files - ssh-keygen no longer defaults to a specific key type (rsa1); use ssh-keygen -t {rsa,dsa,rsa1} - sshd x11 forwarding listens on localhost by default; see sshd X11UseLocalhost option to revert to prior behaviour if your older X11 clients do not function with this configuration Other Changes: ============== - ssh ~& escape char functions now for both protocol versions - sshd ReverseMappingCheck option changed to VerifyReverseMapping to clarify its function; ReverseMappingCheck can still be used - public key fingerprint is now logged with LogLevel=VERBOSE - reason logged for disallowed logins (e.g., no shell, etc.) - more robust error handling for x11 forwarding - improved packet/window size handling in ssh2 - use of regex(3) has been removed - fix SIGCHLD races in sshd (seen on Solaris) - sshd -o option added - sftp -B -R -P options added - ssh-add now adds all 3 default keys - ssh-keyscan bug fixes - ssh-askpass for hostkey dialog - fix fd leak in sshd on SIGHUP - TCP_NODELAY set on X11 and TCP forwarding endpoints OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. _______________________________________________ openssh-unix-announce at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-announce From jax at purematrix.com Sat Mar 9 03:10:44 2002 From: jax at purematrix.com (Jack J. Woehr) Date: Fri, 08 Mar 2002 09:10:44 -0700 Subject: [openssh-unix-announce] OpenSSH 3.1 released References: Message-ID: <3C88E284.B1ADFA6C@purematrix.com> Amir Hejazi wrote: > Good Day All, > Would someone please answer why I can NOT get to work scp without passowrd > between 2 > Solaris boxes with OpenSSH (3.0.2p1) . Must be because you're configured wrong. I have that setup working right now as we speak. 1. Generate keys 2. Append $HOME/.ssh/identity.pub on box1 to $HOME/.ssh/authorized_keys on box2 3. scp box1:/foo/bar/afile box2:/foo/bar/afile -- Jack J. Woehr # Power always thinks it has a great soul Senior Consultant # and ... that it is doing God's service Purematrix, Inc. # when it is violating all his Laws. www.purematrix.com # - John Adams From dan at doxpara.com Sun Mar 10 03:17:43 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 9 Mar 2002 08:17:43 -0800 Subject: [openssh-unix-announce] OpenSSH 3.1 released References: Message-ID: <013501c1c785$f130f5a0$1701000a@effugas> > Good Day All, > Would someone please answer why I can NOT get to work scp without passowrd > between 2 > Solaris boxes with OpenSSH (3.0.2p1) . Most likely because you need to get pubkey authentication up and running first -- scp piggybacks on top of ssh, so you need to get ssh able to work without a password first. Some things to check: 1) Do you have correct permissions on your ~/.ssh directory? sshd won't trust an authorized_keys or authorized_keys2 file if anyone else can write to it, or if the directory it's living in is modifiable by anyone else. 2) Are you using the correct SSH protocol for the keys that are set up? If you have SSH1 pubkey setup(contents of identity.pub added to remote ~/.ssh/authorized_keys) but are connecting using SSH2, pubkey will fail. You can either connect using SSH1(scp -1 or ssh -1 will work) or add SSH2 keys. These methods from HPYN2K might help. Good luck! ? Cause remote host to accept SSH1 keypair in lieu of password: cat ~/.ssh/identity.pub | ssh -1 user at host "cd ~ && umask 077 && mkdir -p .ssh && cat >> ~/.ssh/authorized_keys" ? Cause remote host to accept SSH2 keypair in lieu of password: cat ~/.ssh/id_dsa.pub | ssh user at host "cd ~ && umask 077 && mkdir -p .ssh && cat >> ~/.ssh/authorized_keys2" Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com From bugzilla-daemon at mindrot.org Sat Mar 9 03:27:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 03:27:51 +1100 (EST) Subject: [Bug 151] New: 3.0.2p1 and 3.1p1 fail to build. Message-ID: <20020308162751.7D2B8EABD@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=151 Summary: 3.0.2p1 and 3.1p1 fail to build. Product: Portable OpenSSH Version: 3.0.2p1 Platform: MIPS OS/Version: IRIX Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jamie at photon.com First uname and compiler versions: %uname -aR IRIX64 banshee 6.5 6.5.11m 01101246 IP25 %cc -version MIPSpro Compilers: Version 7.3.1.2m I have just recieved 7.3.1.3m from SGI, but cannot update compilers until I've had a chance to announce to all developers that the change is coming, and when. %cat /etc/compiler.defaults -DEFAULT:abi=n32:isa=mips3:proc=r4k The above to build the binaries 32bit, as I have Indigo R4000 and Indy R4xxx machines I have to support as well. %gcc -v Reading specs from /usr/local/gcc-2.95.1/lib/gcc-lib/mips-sgi-irix6.5/2.95.1/specs gcc version 2.95.1 19990816 (release) And now for the make output: First with MIPSpro: %gmake (cd openbsd-compat && gmake) gmake[1]: Entering directory `/home/jamie/compile/6.5/openssh-3.1p1/openbsd-compat' cc -L/usr/local/lib -I/usr/local/include -I. -I.. -I. -I./.. -I/usr/local/openssl/include -L/usr/local/lib -I/usr/local/include -I/usr/local/include -DHAVE_CONFIG_H -c getcwd.c cc-1101 cc: WARNING File = /usr/include/sys/dir.h, Line = 100 "DIR" has already been declared in the current scope. } DIR; ^ cc-1515 cc: WARNING File = getcwd.c, Line = 162 A value of type "struct direct *" cannot be assigned to an entity of type "struct dirent *". if (!(dp = readdir(dir))) ^ cc-1565 cc: ERROR File = getcwd.c, Line = 164 The struct "dirent" has no field "d_fileno". if (dp->d_fileno == ino) ^ cc-1515 cc: WARNING File = getcwd.c, Line = 169 A value of type "struct direct *" cannot be assigned to an entity of type "struct dirent *". if (!(dp = readdir(dir))) ^ cc-1565 cc: ERROR File = getcwd.c, Line = 173 The struct "dirent" has no field "d_namlen". memmove(bup, dp->d_name, dp->d_namlen + 1); ^ cc-1565 cc: ERROR File = getcwd.c, Line = 190 The struct "dirent" has no field "d_namlen". if (bpt - pt < dp->d_namlen + (first ? 1 : 2)) { ^ cc-1565 cc: ERROR File = getcwd.c, Line = 210 The struct "dirent" has no field "d_namlen". bpt -= dp->d_namlen; ^ cc-1565 cc: ERROR File = getcwd.c, Line = 211 The struct "dirent" has no field "d_namlen". memmove(bpt, dp->d_name, dp->d_namlen); ^ 5 errors detected in the compilation of "getcwd.c". gmake[1]: *** [getcwd.o] Error 2 gmake[1]: Leaving directory `/home/jamie/compile/6.5/openssh-3.1p1/openbsd-compat' gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2 I did a 'gmake distclean' and reran configure allowing autoconfig to find gcc between these two build attempts. 3.0.2p1 and 3.1p1 fail in the same place with the same error with both compilers. And now for GCC: %gmake (cd openbsd-compat && gmake) gmake[1]: Entering directory `/home/jamie/compile/6.5/openssh-3.1p1/openbsd-compat' gcc -L/usr/local/lib -I/usr/local/include -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/usr/local/openssl/include -L/usr/local/lib -I/usr/local/include -I/usr/local/include -DHAVE_CONFIG_H -c getcwd.c In file included from getcwd.c:39: /usr/include/sys/dir.h:100: conflicting types for `DIR' /usr/include/dirent.h:56: previous declaration of `DIR' getcwd.c: In function `getcwd': getcwd.c:162: warning: assignment from incompatible pointer type getcwd.c:164: structure has no member named `d_fileno' getcwd.c:169: warning: assignment from incompatible pointer type getcwd.c:173: structure has no member named `d_namlen' getcwd.c:190: structure has no member named `d_namlen' getcwd.c:210: structure has no member named `d_namlen' getcwd.c:211: structure has no member named `d_namlen' gmake[1]: *** [getcwd.o] Error 1 gmake[1]: Leaving directory `/home/jamie/compile/6.5/openssh-3.1p1/openbsd-compat' gmake: *** [openbsd-compat/libopenbsd-compat.a] Error 2 Any help or pointers are appreciated. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Sat Mar 9 03:30:47 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 8 Mar 2002 08:30:47 -0800 (PST) Subject: buildpkg.sh in OpenSSH_3.1p1 In-Reply-To: <200203081117.g28BHjJ01522@linux012.intern.cityweb.de> Message-ID: On Fri, 8 Mar 2002, Oliver [iso-8859-15] F?nger wrote: > Hi, > > version.h in OpenSSH_3.1p1 has an Newline after > > #define SSH_VERSION "OpenSSH_3.1p1" > > so > tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//' > > does give back a version number > > regards > > Oliver buildpkg.sh is currently being updated. The new version will use VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//'` You will have to modify the path to use this in the old version as the new one will be run from your build directory. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sat Mar 9 04:01:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 04:01:51 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020308170151.79588EAAA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From burt at bnl.gov 2002-03-09 04:01 ------- Markus, Your patch did allow us to compile with OpenSSL 0.9.5a. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From staff01 at openharbor.com Sat Mar 9 04:03:58 2002 From: staff01 at openharbor.com (Staff Account) Date: Fri, 8 Mar 2002 09:03:58 -0800 (PST) Subject: compile bug for 3.1p1 under Solaris Message-ID: <200203081703.g28H3wm28005@buffy.hq.openharbor.com> Hi, There seems to be a bug in the 3.1p1 code compiling under Solaris. The error is below. I saw that someone was having the same problem under linux and that they had already reported the bug but I just wanted to make _sure_ it was reported. BTW, I'm running Solaris 2.7, openssl 0.9.6a, and zlib 1.1.3. Thanks. -C. cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 From bugzilla-daemon at mindrot.org Sat Mar 9 04:16:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 04:16:25 +1100 (EST) Subject: [Bug 151] 3.0.2p1 and 3.1p1 fail to build. Message-ID: <20020308171625.30BF7EAC5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=151 ------- Additional Comments From tim at multitalents.net 2002-03-09 04:16 ------- Does IRIX not have it's own getcwd()? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 04:24:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 04:24:55 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020308172455.5F69DEA85@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From burt at bnl.gov 2002-03-09 04:24 ------- ... but apparently breaks ssh1 compatibility (or something miscompiled to do so: $ ssh -v -1 bar.chm.bnl.gov OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f [ ... ] debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 [ ... ] debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x8060fb8(0x0) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 04:35:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 04:35:11 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020308173511.CF0D4EAAA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From markus at openbsd.org 2002-03-09 04:35 ------- what happens if you additionally replace cipher_init from cipher.c with void cipher_init(CipherContext *cc, Cipher *cipher, const u_char *key, u_int keylen, const u_char *iv, u_int ivlen, int encrypt) { static int dowarn = 1; EVP_CIPHER *type; int klen; if (cipher->number == SSH_CIPHER_DES) { if (dowarn) { error("Warning: use of DES is strongly discouraged " "due to cryptographic weaknesses"); dowarn = 0; } if (keylen > 8) keylen = 8; } cc->plaintext = (cipher->number == SSH_CIPHER_NONE); if (keylen < cipher->key_len) fatal("cipher_init: key length %d is insufficient for %s.", keylen, cipher->name); if (iv != NULL && ivlen < cipher->block_size) fatal("cipher_init: iv length %d is insufficient for %s.", ivlen, cipher->name); cc->cipher = cipher; type = (*cipher->evptype)(); if (type->key_len < cipher->key_len) type->key_len = cipher->key_len; EVP_CIPHER_CTX_init(&cc->evp); EVP_CipherInit(&cc->evp, type, (u_char *)key, (u_char *)iv, (encrypt == CIPHER_ENCRYPT)); } ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From staff01 at openharbor.com Sat Mar 9 05:09:25 2002 From: staff01 at openharbor.com (Staff Account) Date: Fri, 8 Mar 2002 10:09:25 -0800 (PST) Subject: compile bug for 3.1p1 under Solaris Message-ID: <200203081809.g28I9PP21071@buffy.hq.openharbor.com> Hi, I installed OpenSSL 0.9.6c and that fixed my compile error. Thanks. -C. . From bugzilla-daemon at mindrot.org Sat Mar 9 05:26:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 05:26:56 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020308182656.987B6EA7D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From gleblanc at linuxweasel.com 2002-03-09 05:26 ------- I tested that I could ssh into and out of a machine running ssh with the patch from Markus, and it worked fine. Is anyone aware of other places where OpenSSH requires OpenSSL 0.9.6? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 05:37:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 05:37:35 +1100 (EST) Subject: [Bug 150] configure option --with-ipaddr-display seems to have no effect Message-ID: <20020308183735.99AEEEAD2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=150 ------- Additional Comments From stevesk at pobox.com 2002-03-09 05:37 ------- in general, X11 clients need R6 libs to work with a localhost X11 forwarding server. on HP-UX 11 /usr/bin/X11/xterm uses R5 libs. try /usr/contrib/bin/X11/xterm which is in the X11.X11-RUN-CTRB fileset. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 06:24:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 06:24:39 +1100 (EST) Subject: [Bug 152] New: Build failure on Sparc/Solaris 2.8 with Sun cc or gcc Message-ID: <20020308192439.2D2E3EACD@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=152 Summary: Build failure on Sparc/Solaris 2.8 with Sun cc or gcc Product: Portable OpenSSH Version: 3.0.2p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: zed at debian.org This affects both 3.0.2p1 and 3.1p1. Somehow, data from header files is being lost during compiles. Configure is run as: CC=gcc ./configure --prefix=$PREFIX \ --infodir=$PREFIX/share/info \ --mandir=$PREFIX/share/man \ --sysconfdir=$PREFIX/etc \ --with-xauth=/usr/openwin/bin/xauth \ --with-rsh=/usr/bin/rsh \ --with-4in6 --with-pam \ --disable-suid-ssh \ --with-default-path=/usr/local/free/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/openwin/bin Running make from here gets to: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/free/include -I/usr/local/include -DSSHDIR=\"/usr/local/free/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/free/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/free/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/free/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/local/free/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ttymodes.c In file included from ttymodes.c:297: ttymodes.h: In function `tty_make_modes': ttymodes.h:125: `IXANY' undeclared (first use in this function) ttymodes.h:125: (Each undeclared identifier is reported only once ttymodes.h:125: for each function it appears in.) ttymodes.h:159: `ONLCR' undeclared (first use in this function) In file included from ttymodes.c:392: ttymodes.h: In function `tty_parse_modes': ttymodes.h:125: `IXANY' undeclared (first use in this function) ttymodes.h:159: `ONLCR' undeclared (first use in this function) which of course are defined in /usr/include/sys/termios.h, which is pulled in from /usr/include/termios.h. Manually adding #include to the top of ttymodes.h has no effect. Adding in the IXANY and ONLCR #defines to the top of ttymodes.h gets it a little farther, but then it dies at: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/free/include -I/usr/local/include -DSSHDIR=\"/usr/local/free/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/free/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/free/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/free/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/local/free/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh.c ssh.c: In function `main': ssh.c:620: warning: implicit declaration of function `snprintf' ssh.c: In function `x11_get_proto': ssh.c:835: warning: implicit declaration of function `strlcpy' ssh.c: In function `ssh_session': ssh.c:898: storage size of `ws' isn't known ssh.c:936: warning: implicit declaration of function `ioctl' ssh.c:936: `TIOCGWINSZ' undeclared (first use in this function) ssh.c:936: (Each undeclared identifier is reported only once ssh.c:936: for each function it appears in.) ssh.c:898: warning: unused variable `ws' ssh.c: In function `ssh_session2_setup': ssh.c:1055: storage size of `ws' isn't known ssh.c:1061: `TIOCGWINSZ' undeclared (first use in this function) ssh.c:1055: warning: unused variable `ws' make: *** [ssh.o] Error 1 I can get around the TIOCGWINSZ problem the same way, but I'm defeated by whatever strange thing is going on with ws. At first, I thought I had somehow managed to mangle my gcc install, but upgrading from gcc 2.94 to gcc 3.0.4 had no effect, and I didn't do anything out of the ordinary on the compile procedure. So then I tried again, only with CC=cc, using the sun compiler. I got stopped at exactly the same points, albeit with slightly different errors: cc -g -I. -I. -I/usr/local/free/include -I/usr/local/include -DSSHDIR=\"/usr/local/free/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/free/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/free/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/free/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/local/free/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh.c "ssh.c", line 898: incomplete struct/union/enum winsize: ws "ssh.c", line 936: undefined symbol: TIOCGWINSZ "ssh.c", line 938: undefined struct/union member: ws_row "ssh.c", line 939: undefined struct/union member: ws_col "ssh.c", line 940: undefined struct/union member: ws_xpixel "ssh.c", line 941: undefined struct/union member: ws_ypixel "ssh.c", line 1055: incomplete struct/union/enum winsize: ws "ssh.c", line 1061: undefined symbol: TIOCGWINSZ "ssh.c", line 1066: undefined struct/union member: ws_col "ssh.c", line 1067: undefined struct/union member: ws_row "ssh.c", line 1068: undefined struct/union member: ws_xpixel "ssh.c", line 1069: undefined struct/union member: ws_ypixel cc: acomp failed for ssh.c make: *** [ssh.o] Error 2 At first I thought that somehow the header protective #defines were being set without the header data actually being loaded, but when I removed the specific #defines I mentioned above and tried adding: #undef _TERMIO_H #undef _SYS_TERMIO_H #include to the top of ttymodes.h, it again stopped at the same spot. A complete build log can be made available upon request. -- Zed Pobre Department of Mathematics, Louisiana State University ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 06:24:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 06:24:47 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020308192447.31FFDEAD5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 wayne at qconcepts.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From wayne at qconcepts.net 2002-03-09 06:24 ------- When building with OpenSSL 0.9.6, openssh-3.1p1-1.src.rpm builds and installs correctly, even without Markus' patch. FYI: There is no OpenSSL 0.9.6 package for RedHat 6.1 - 0.9.5a is the last released. One can build the library from the 7.x srpm, and install with the -- nodeps option to rpm(OpenSSH 3.0 depends on 0.9.5a, but works fine with 0.9.6). Of course, this is not directly an OpenSSH issue, but may be of use to RedHat Linux users. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 08:33:05 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 08:33:05 +1100 (EST) Subject: [Bug 153] New: NULL pointer passed to xfree() during client connection Message-ID: <20020308213305.BAFEAE932@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=153 Summary: NULL pointer passed to xfree() during client connection Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: karmilow at intencorp.com sshd passes a NULL pointer to xfree(), preventing ssh clients from connecting to the server. The problem occurs on multiple servers and clients: orion:/etc/rc.d# ./rc.sshd start debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 65.56.115.228 port 1622 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.1p1 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none 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: 133/256 debug1: bits set: 1543/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1596/3191 xfree: NULL pointer given as argument debug1: Calling cleanup 0x806662c(0x0) The following lines were written to /var/log/syslog when the client attempted to connect during the debug session (refer to transcript above): Mar 8 15:39:02 orion sshd[16231]: fatal: xfree: NULL pointer given as argument Mar 8 15:51:09 orion sshd[16264]: fatal: Cannot bind any address. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Sat Mar 9 09:02:12 2002 From: djm at mindrot.org (Damien Miller) Date: Sat, 09 Mar 2002 09:02:12 +1100 Subject: building openssh executeables mostly statically References: <20020308111810.GA10267@vega.ipal.net> Message-ID: <3C8934E4.7080003@mindrot.org> Phil Howard wrote: > Is there a configure option to build OpenSSH mostly statically? > I want to have openssl libraries statically linked. I'd prefer > libc (and related) not be, and libz could go either way. You have to hand edit the makefile. Have a look at contrib/redhat/openssh.spec to see how to do it with perl. -d From Ovanes.Manucharyan at exodus.net Sat Mar 9 09:06:00 2002 From: Ovanes.Manucharyan at exodus.net (Ovanes Manucharyan) Date: Fri, 8 Mar 2002 14:06:00 -0800 Subject: FW: Unable to compile latest release on Linux Message-ID: -----Original Message----- From: Ovanes Manucharyan Sent: Thursday, March 07, 2002 3:34 PM To: 'openssh at openssh.com' Subject: Unable to compile latest release on Linux Hello, I tried to compile the latest portable version (openssh-3.1p1) to no avail. I tried 2 different configuration combinations with the same problem. ./configure --with-pam --with-tcp-wrappers --with-md5-passwords and ./configure Attached is my results of "make". I'm doing this on Redhat 7.0 Ovanes -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Thursday, March 07, 2002 3:57 AM To: announce at openbsd.org; security-announce at openbsd.org; openssh-unix-dev at mindrot.org; openssh-unix-announce at mindrot.org Cc: BUGTRAQ at securityfocus.com; misc at openbsd.org; lwn at lwn.net Subject: OpenSSH Security Advisory (adv.channelalloc) 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From bugzilla-daemon at mindrot.org Sat Mar 9 09:21:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:21:18 +1100 (EST) Subject: [Bug 154] New: make failes: make: *** [cipher.o] Error 1 Message-ID: <20020308222118.BEC78EAD4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=154 Summary: make failes: make: *** [cipher.o] Error 1 Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: hatlas at depaul.edu RedHat 7.1 and 6.2 using configure --with-md5-passwords (or with no options): gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function)cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function)cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 [root at news openssh-3.1p1]# ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 09:27:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:27:01 +1100 (EST) Subject: [Bug 130] segfault on connect / Red Hat 6.1 w/OpenSSL 0.9.6c Message-ID: <20020308222701.A2893EADF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=130 ------- Additional Comments From djm at mindrot.org 2002-03-09 09:26 ------- Are you sure that you don't have any old OpenSSL headers lying around? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 09:28:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:28:35 +1100 (EST) Subject: [Bug 135] Sudden freeze of SSH2 on clients from masqueraded subnet (behind firewall) Message-ID: <20020308222835.DC9FAEAE2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=135 ------- Additional Comments From djm at mindrot.org 2002-03-09 09:28 ------- This is probably masquerading related. Unless you can replicate it on a clean connection, it is not a problem with 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 Sat Mar 9 09:29:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:29:35 +1100 (EST) Subject: [Bug 154] make failes: make: *** [cipher.o] Error 1 Message-ID: <20020308222935.8A99BEAE8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=154 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From djm at mindrot.org 2002-03-09 09:29 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 09:29:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:29:41 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020308222941.B8DA4EAEA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hatlas at depaul.edu ------- Additional Comments From djm at mindrot.org 2002-03-09 09:29 ------- *** Bug 154 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From andy.ozment at cc.gatech.edu Sat Mar 9 09:25:03 2002 From: andy.ozment at cc.gatech.edu (Andy Ozment) Date: Fri, 08 Mar 2002 17:25:03 -0500 Subject: Cannot run OpenSSH 3.1p1 on Solaris 8, Irix 6.5.14, Irix 6.5.4, SunOS 4.1.3_U1 - ssh-rand-helper child produced insufficient data Message-ID: <3C893A3F.2C9137E9@no-spam.edu> I have successfully compiled OpenSSH 3.1p1 for the following systems: Solaris 8 Solaris 7 Irix 6.5.14 Irix 6.5.4 SunOS 4.1.3_U1 Unfortunately, the new sshd is not working on any of the above systems with the exception of Solaris 7. (I then put the Solaris 7 executables on Solaris 8, and they worked there too.) This is the error I'm getting: $ /usr/etc/sshd -D -d -d -d debug3: Seeing PRNG from /usr/libexec/ssh-rand-helper ssh-rand-helper child produced insufficient data I compiled with: tried both openssl 0.9.6b and 0.9.6c prngd 0.9.23 zlib 1.1.3 Checking my random number pool shows that I have plenty of bits available: $ egc-irix.pl /var/run/egd-pool get 32800 bits of entropy in pool $ /usr/sbin/sshd -D -d -d -d debug3: Seeing PRNG from /usr/libexec/ssh-rand-helper ssh-rand-helper child produced insufficient data Anybody have any ideas? Andy -- Andy Ozment Research Scientist Georgia Tech College of Computing From bugzilla-daemon at mindrot.org Sat Mar 9 09:43:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 09:43:28 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020308224328.5BF92EAE9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From skvidal at phy.duke.edu 2002-03-09 09:43 ------- the cipher_init change does not help the problem debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x8063550(0x0) still throwing an error on any ssh1 connection ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 10:01:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 10:01:11 +1100 (EST) Subject: [Bug 130] segfault on connect / Red Hat 6.1 w/OpenSSL 0.9.6c Message-ID: <20020308230111.CE31DE92D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=130 jon at xisp.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From jon at xisp.net 2002-03-09 10:01 ------- I am certain, yes --- there was no openssl prior to my installation of it. However, I just built OpenSSH 3.1p1 on the box and it works. So whatever it was appears to have gone away with the new version. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From anonymous at no-spam.edu Sat Mar 9 10:22:22 2002 From: anonymous at no-spam.edu (Andy Ozment) Date: Fri, 08 Mar 2002 18:22:22 -0500 Subject: Cannot run OpenSSH 3.1p1 on Solaris 8, Irix 6.5.14, Irix 6.5.4, SunOS 4.1.3_U1 - ssh-rand-helper child produced insufficient data References: <3C893A3F.2C9137E9@no-spam.edu> Message-ID: <3C8947AE.31DAA636@cc.gatech.edu> I forgot to mention the configure options I used when building the executables. Sun OS 4.1.3_U1: ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --with-tcp-wrappers \ --with-utmpx \ --with-prngd-socket=/var/run/egd-pool \ --with-ssl-dir=. \ --with-pid-dir=/var/run \ --with-cppflags="-D_POSIX_VDISABLE" Irix 6.5.14 / 6.5.4: ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --with-ssl-dir=/usr/lib32 \ --with-tcp-wrappers=/usr/local/lib/libwrap.a \ --with-utmpx \ --with-prngd-socket=/var/run/egd-pool \ --with-ldflags="-L/usr/local/lib" \ --with-pid-dir=/var/run Solaris 7/8: ./configure \ --prefix=/usr \ --sysconfdir=/etc/ssh \ --with-ssl-dir=/usr/local/lib \ --with-pam \ --with-tcp-wrappers \ --with-utmpx \ --with-prngd-socket=/var/run/egd-pool \ --with-pid-dir=/var/run \ --with-cppflags="-DPAM_TTY_KLUDGE=1" From bfoster at hotresponse.com Sat Mar 9 11:16:36 2002 From: bfoster at hotresponse.com (Bob Foster) Date: Fri, 08 Mar 2002 16:16:36 -0800 Subject: SSH Commands Initiated from Apache Fail Message-ID: Hi, I don't know if this is a bug or not. I use Apache web server and perl cgi's and modules to start a shell script which runs a simple ssh command: /usr/local/bin/ssh $dest rm -r /directory/tree/to/be/removed This works fine from the command line. However, when run from the web server, it fails. The error return code is 255. The user in both cases is the same and publickey authentication is used. Any ideas? Thanks! Bob Foster From mjt at tls.msk.ru Sat Mar 9 11:54:14 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sat, 09 Mar 2002 03:54:14 +0300 Subject: Little cleanup for -lz Message-ID: <3C895D36.B241D3E5@tls.msk.ru> Here is a first patch in a series of similar ones (I hope). This patch is to make -lz used for only those programs that *really* need zlib (namely, ssh and sshd for now). There is no need to load libz.so for ssh-keygen, sftp and others. Related question. It seems ssh's configure script pickups -lnsl on linux -- what for? It is required on solaris, but not on linux. But on solaris, one need to use -lsocket -lnsl in order to do any network code (i.e. BOTH libs are for BSD socket operations). Are there other platforms exists where ssh uses OTHER features/symbols from -lnsl? And from -lutil (EXCEPT login()/logwtmp()/whatether needed for sshd only)? Regards, Michael. BTW, please don't blame me: I NOT tested this patch AT ALL (but it is very trivial): right now I have no working autoconf-2. It is a big trouble -- dealing with incompatibility in autoconf. I'll have it soon. -------------- next part -------------- --- openssh-3.1p1/configure.ac.zlib Wed Feb 27 09:12:35 2002 +++ openssh-3.1p1/configure.ac Sat Mar 9 03:35:52 2002 @@ -359,6 +359,7 @@ ) dnl zlib is required +ZLIB_LDFLAGS= AC_ARG_WITH(zlib, [ --with-zlib=PATH Use zlib in PATH], [ @@ -367,15 +368,15 @@ fi if test -d "$withval/lib"; then if test -n "${need_dash_r}"; then - LDFLAGS="-L${withval}/lib -R${withval}/lib ${LDFLAGS}" + ZLIB_LDFLAGS="-L${withval}/lib -R${withval}/lib" else - LDFLAGS="-L${withval}/lib ${LDFLAGS}" + ZLIB_LDFLAGS="-L${withval}/lib" fi else if test -n "${need_dash_r}"; then - LDFLAGS="-L${withval} -R${withval} ${LDFLAGS}" + ZLIB_LDFLAGS="-L${withval} -R${withval}" else - LDFLAGS="-L${withval} ${LDFLAGS}" + ZLIB_LDFLAGS="-L${withval}" fi fi if test -d "$withval/include"; then @@ -386,7 +387,9 @@ ] ) -AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first or check config.log ***])) +AC_CHECK_LIB(z, deflate, ZLIB_LDFLAGS="$ZLIB_LDFLAGS -lz"; AC_SUBST(ZLIB_LDFLAGS), + AC_MSG_ERROR([*** zlib missing - please install first or check config.log ***]), + $ZLIB_LDFLAGS) dnl UnixWare 2.x AC_CHECK_FUNC(strcasecmp, --- openssh-3.1p1/Makefile.in.zlib Tue Feb 26 22:24:22 2002 +++ openssh-3.1p1/Makefile.in Sat Mar 9 03:41:32 2002 @@ -31,6 +31,7 @@ CFLAGS=@CFLAGS@ CPPFLAGS=-I. -I$(srcdir) @CPPFLAGS@ $(PATHS) @DEFS@ LIBS=@LIBS@ +ZLIB_LDFLAGS=@ZLIB_LDFLAGS@ LIBPAM=@LIBPAM@ LIBWRAP=@LIBWRAP@ AR=@AR@ @@ -99,10 +100,10 @@ $(RANLIB) $@ ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS) - $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) + $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(ZLIB_LDFLAGS) $(LIBS) sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) - $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBS) + $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(ZLIB_LDFLAGS) $(LIBWRAP) $(LIBPAM) $(LIBS) scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o $(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) From jqllwilliam at moon.net Sat Mar 9 12:07:21 2002 From: jqllwilliam at moon.net (wiewilliam) Date: Fri, 8 Mar 2002 17:07:21 -0800 Subject: Will you meet me again? fnkcb Message-ID: <20020309011951.B1F0CE95F@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020308/832c2248/attachment.html From samkaski at vortex.ll.sci.fi Sat Mar 9 12:22:02 2002 From: samkaski at vortex.ll.sci.fi (Samuli Kaski) Date: Sat, 9 Mar 2002 03:22:02 +0200 (EET) Subject: 3.1p1 + OpenSSL 0.9.5a -> no can do Message-ID: What should I do in order to be able to compile OpenSSH 3.1p1 with OpenSSL 0.9.5a? I get a lot of EVP related compile errors in cipher.c, appended. Thanks. Samuli cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 From markwag at u.washington.edu Sat Mar 9 12:39:30 2002 From: markwag at u.washington.edu (Mark Wagner) Date: Fri, 08 Mar 2002 17:39:30 -0800 Subject: krb5 problem: KRB5CCNAME is ""; possible fix for OpenSSH 3.0.2p1 Message-ID: <200203090139.g291dU911095@gandalf.radonc.washington.edu> I'm using a OpenSSH 3.0.2p1 with the krb5 patch from . I'm getting KRB5CCNAME set to "" even though mentions fixing it. This causes things like kinit to fail with a somewhat uninformative error message. The relevant sshd_config lines I use are: # To change Kerberos options KerberosAuthentication yes KerberosOrLocalPasswd yes #AFSTokenPassing no KerberosTicketCleanup yes # Kerberos TGT Passing does only work with the AFS kaserver KerberosTgtPassing no I'm using MIT Kerberos. As far as I can tell (after scanning the code for a few hours and I'm not a programmer) the problem is in auth_krb5_password. 244 problem = krb5_cc_resolve(authctxt->krb5_ctx, "MEMORY:", 245 &authctxt->krb5_fwd_ccache); the name "MEMORY:" seems to cause krb5_cc_get_name at 287 authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt-> krb5_ctx, authctxt->krb5_fwd_ccache); to return "" rather than NULL, so that sesssion.c sets KRB5CCNAME in the shell environment to "" in lines 1294-1296. I've tried two changes that seem to fix the problem. The first is a simple hack of replacing line 287 with 287 authctxt->krb5_ticket_file = NULL. The second is to replace lines 244 and 245 with 244 { 245 char ccname[35]; 246 247 snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d", authctxt->pw->pw_uid); 248 problem = krb5_cc_resolve(authctxt->krb5_ctx, ccname, 249 &authctxt->krb5_fwd_ccache); 250 } (The security implications of the latter make me nervous. I hope Kerberos is handling writing to /tmp carefully and there isn't some interaction between sshd and Kerberos such that the file is read as root and the user can tell sshd to look at an arbitrary file.) I do not subscribe to this list but I will check the archive for responses. -- Mark Wagner markwag at u.washington.edu University of Washington Medical Center Unix System Administrator, Radiation Oncology and Radiology From dtucker at zip.com.au Sat Mar 9 13:48:03 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Mar 2002 13:48:03 +1100 Subject: OpenSSH-3.1p1 AIX buildbff.sh patch Message-ID: <3C8977E3.C37498A8@zip.com.au> Hello All, Attached is a patch makes the following changes to contrib/aix relative to 3.1p1: * Gets version number from ssh -V as suggested by Tim Rice. * Does a better job of generating valid AIX package version numbers (fixes inutoc "format of the toc file is invalid" and "invalid level" errors reported by Mandar Mirashi). * Tests for "make install" failure and doesn't generate empty package in that case. * Generate file sizes in inventory file. Tested and resulting packages installed on AIX 4.2.1 and 4.3.3. Please review and let me know of problems or apply if OK (and chmod a+x contrib/aix/*.sh). Thanks, -Daz. -------------- next part -------------- diff -c -r openssh-3.1p1/contrib/aix/buildbff.sh openssh-3.1p1-aix/contrib/aix/buildbff.sh *** openssh-3.1p1/contrib/aix/buildbff.sh Tue Mar 5 13:38:37 2002 --- openssh-3.1p1-aix/contrib/aix/buildbff.sh Sat Mar 9 11:43:36 2002 *************** *** 11,31 **** umask 022 PKGNAME=openssh ! PATH=$PATH:`pwd` # set path for external tools export PATH ! ## Extract common info requires for the 'info' part of the package. ! VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` ! BFFVERSION=`echo $VERSION | sed 's/p/./g'` ! ! echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" ! PKGDIR=package ! ! # Clean build directory and package file rm -rf $PKGDIR mkdir $PKGDIR - rm -f $PKGNAME-$VERSION.bff if [ ! -f ../../Makefile ] then --- 11,24 ---- umask 022 PKGNAME=openssh + PKGDIR=package ! PATH=`pwd`:$PATH # set path for external tools export PATH ! # Clean build directory rm -rf $PKGDIR mkdir $PKGDIR if [ ! -f ../../Makefile ] then *************** *** 40,45 **** --- 33,61 ---- cd ../.. make install-nokeys DESTDIR=$FAKE_ROOT + if [ $? -gt 0 ] + then + echo "Fake root install failed, stopping." + exit 1 + fi + + # + # Extract common info requires for the 'info' part of the package. + # AIX requires 4-part version numbers + # + VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//' | cut -f 2 -d _` + MAJOR=`echo $VERSION | cut -f 1 -d p | cut -f 1 -d .` + MINOR=`echo $VERSION | cut -f 1 -d p | cut -f 2 -d .` + PATCH=`echo $VERSION | cut -f 1 -d p | cut -f 3 -d .` + PORTABLE=`echo $VERSION | cut -f 2 -d p` + if [ "$PATCH" = "" ] + then + PATCH=0 + fi + BFFVERSION=`printf "%d.%d.%d.%d" $MAJOR $MINOR $PATCH $PORTABLE` + + echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" + # # Fill in some details, like prefix and sysconfdir # the eval also expands variables like sysconfdir=${prefix}/etc *************** *** 175,180 **** --- 191,197 ---- # file list on the fly and feed it to backup using -i # echo Creating $PKGNAME-$VERSION.bff with backup... + rm -f $PKGNAME-$VERSION.bff ( echo "./lpp_name" find . ! -name lpp_name -a ! -name . -print diff -c -r openssh-3.1p1/contrib/aix/inventory.sh openssh-3.1p1-aix/contrib/aix/inventory.sh *** openssh-3.1p1/contrib/aix/inventory.sh Tue Mar 5 13:38:37 2002 --- openssh-3.1p1-aix/contrib/aix/inventory.sh Sat Mar 9 11:04:45 2002 *************** *** 52,58 **** } elsif ( -f $_ ) { # Entry is File print "\ttype=FILE\n"; ! print "\tsize=VOLATILE\n"; print "\tchecksum=VOLATILE\n"; } elsif ( -d $_ ) { # Entry is Directory --- 52,58 ---- } elsif ( -f $_ ) { # Entry is File print "\ttype=FILE\n"; ! print "\tsize=$sz\n"; print "\tchecksum=VOLATILE\n"; } elsif ( -d $_ ) { # Entry is Directory From bonomo at maddog.sal.wisc.edu Sat Mar 9 14:10:57 2002 From: bonomo at maddog.sal.wisc.edu (Richard Bonomo) Date: Fri, 8 Mar 2002 21:10:57 -0600 (CST) Subject: IRIX SSH oddity Message-ID: <200203090310.VAA33525@maddog.sal.wisc.edu> I installed an SGI-compiled binary distribution of openssh and opensshd on our IRIX 6.5.x systems. I am finding that when I run ssh on my workstations, I keep getting this "Not enough entropy in RNG" error. It seems to be getting worse in that it took, literally, 20-40 attempts before I finally got to a password request on a couple of occasions today. (It had been taking 3 or 4). Whom could I ask about this? This is truly annoying, and I have not been able to find much about this particular problem from the sources I have checked so far... I think this is version 2.9p2 Rich -- ************************************************ Richard Bonomo UW Space Astronomy Laboratory ph: (608) 263-4683 telefacsimile: (608) 263-0361 SAL-related email: bonomo at sal.wisc.edu ************************************************ From bugzilla-daemon at mindrot.org Sat Mar 9 14:43:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 14:43:39 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020309034339.B5C5AEB06@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From cajoline at chaosengine.de 2002-03-09 14:43 ------- I have verified this problem. I built rpms from the openssh-3.1p1-2 redhat srpm (modified spec) and installed it on the same system, RHL 6.2 i386, 2.2.19- 6.2.12 errata kernel, with openssl-0.9.5a-7.6.x installed. However, in my experience, the problem only occurs if AES-256 or AES-192 ciphers are used; ssh and sshd both work fine as long as they are not forced to use these two ciphers. This is just fyi, installing openssl 0.9.6 solves the problem, as noted in the last comment. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Ovanes.Manucharyan at exodus.net Fri Mar 8 10:33:46 2002 From: Ovanes.Manucharyan at exodus.net (Ovanes Manucharyan) Date: Thu, 7 Mar 2002 15:33:46 -0800 Subject: Unable to compile latest release on Linux Message-ID: Hello, I tried to compile the latest portable version (openssh-3.1p1) to no avail. I tried 2 different configuration combinations with the same problem. ./configure --with-pam --with-tcp-wrappers --with-md5-passwords and ./configure Attached is my results of "make". I'm doing this on Redhat 7.0 Ovanes -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Thursday, March 07, 2002 3:57 AM To: announce at openbsd.org; security-announce at openbsd.org; openssh-unix-dev at mindrot.org; openssh-unix-announce at mindrot.org Cc: BUGTRAQ at securityfocus.com; misc at openbsd.org; lwn at lwn.net Subject: OpenSSH Security Advisory (adv.channelalloc) 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From dirk.meyer at dinoex.sub.org Sat Mar 9 19:25:27 2002 From: dirk.meyer at dinoex.sub.org (Dirk Meyer) Date: Sat, 09 Mar 2002 09:25:27 +0100 Subject: PATCH defines.h for FreeBSD 2.2.8 Message-ID: I suggest a patch to make openssh-potable-3.1p1 compile under FreeBSD 2.2.8 (ulong) is undefined (u_long) is used everywhere else in the source. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer at dinoex.sub.org],[dirk.meyer at guug.de],[dinoex at FreeBSD.org] --- defines.h.orig Tue Feb 26 17:40:49 2002 +++ defines.h Fri Mar 8 18:51:27 2002 @@ -146,7 +146,7 @@ including rpc/rpc.h breaks Solaris 6 */ #ifndef INADDR_LOOPBACK -#define INADDR_LOOPBACK ((ulong)0x7f000001) +#define INADDR_LOOPBACK ((u_long)0x7f000001) #endif /* Types */ From ccarlso4 at email.usps.gov Sat Mar 9 06:41:22 2002 From: ccarlso4 at email.usps.gov (Charles Carlson) Date: Fri, 8 Mar 2002 13:41:22 -0600 Subject: Makefile problem with Solaris Message-ID: <01C1C6A6.EFE222D0.ccarlso4@email.usps.gov> When using GCC + Solaris, you should not use -I/usr/include. This causes an error. see http://www.science.uva.nl/pub/solaris/solaris2/Q5.9.html From markus at openbsd.org Sat Mar 9 20:16:00 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 9 Mar 2002 10:16:00 +0100 Subject: Problems with Solaris 8 and OpenSSH 3.1p1 In-Reply-To: <175870508.1015582510@dieleitung.ece.uprm.edu>; from Kennie.Cruz@ece.uprm.edu on Fri, Mar 08, 2002 at 10:15:10AM -0400 References: <175870508.1015582510@dieleitung.ece.uprm.edu> Message-ID: <20020309101600.B1515@folly> On Fri, Mar 08, 2002 at 10:15:10AM -0400, Kennie Cruz wrote: > When compiling the software it breaks with an error on the cipher.c file. > Lot's of warnings and error of undeclared stuff. does this help? Index: cipher.c =================================================================== RCS file: /home/markus/cvs/ssh/cipher.c,v retrieving revision 1.52 diff -u -r1.52 cipher.c --- cipher.c 18 Feb 2002 13:05:32 -0000 1.52 +++ cipher.c 9 Mar 2002 08:09:29 -0000 @@ -44,6 +44,11 @@ #include #include "rijndael.h" +#if OPENSSL_VERSION_NUMBER <= 0x0090600fL +#define SSH_OLD_EVP +#define EVP_CIPHER_CTX_get_app_data(e) ((e)->app_data) +#endif + static EVP_CIPHER *evp_ssh1_3des(void); static EVP_CIPHER *evp_ssh1_bf(void); static EVP_CIPHER *evp_rijndael(void); @@ -171,7 +176,11 @@ int encrypt) { static int dowarn = 1; +#ifdef SSH_OLD_EVP + EVP_CIPHER *type; +#else const EVP_CIPHER *type; +#endif int klen; if (cipher->number == SSH_CIPHER_DES) { @@ -195,7 +204,13 @@ type = (*cipher->evptype)(); +#ifdef SSH_OLD_EVP + if (type->key_len < cipher->key_len) + type->key_len = cipher->key_len; EVP_CIPHER_CTX_init(&cc->evp); + EVP_CipherInit(&cc->evp, type, (u_char *)key, (u_char *)iv, + (encrypt == CIPHER_ENCRYPT)); +#else if (EVP_CipherInit(&cc->evp, type, NULL, (u_char *)iv, (encrypt == CIPHER_ENCRYPT)) == 0) fatal("cipher_init: EVP_CipherInit failed for %s", @@ -210,6 +225,7 @@ if (EVP_CipherInit(&cc->evp, NULL, (u_char *)key, NULL, -1) == 0) fatal("cipher_init: EVP_CipherInit: set key failed for %s", cipher->name); +#endif } void @@ -217,15 +233,23 @@ { if (len % cc->cipher->block_size) fatal("cipher_encrypt: bad plaintext length %d", len); +#ifdef SSH_OLD_EVP + EVP_Cipher(&cc->evp, dest, (u_char *)src, len); +#else if (EVP_Cipher(&cc->evp, dest, (u_char *)src, len) == 0) fatal("evp_crypt: EVP_Cipher failed"); +#endif } void cipher_cleanup(CipherContext *cc) { +#ifdef SSH_OLD_EVP + EVP_CIPHER_CTX_cleanup(&cc->evp); +#else if (EVP_CIPHER_CTX_cleanup(&cc->evp) == 0) error("cipher_cleanup: EVP_CIPHER_CTX_cleanup failed"); +#endif } /* @@ -296,6 +320,11 @@ EVP_CIPHER_CTX_init(&c->k1); EVP_CIPHER_CTX_init(&c->k2); EVP_CIPHER_CTX_init(&c->k3); +#ifdef SSH_OLD_EVP + EVP_CipherInit(&c->k1, EVP_des_cbc(), k1, NULL, enc); + EVP_CipherInit(&c->k2, EVP_des_cbc(), k2, NULL, !enc); + EVP_CipherInit(&c->k3, EVP_des_cbc(), k3, NULL, enc); +#else if (EVP_CipherInit(&c->k1, EVP_des_cbc(), k1, NULL, enc) == 0 || EVP_CipherInit(&c->k2, EVP_des_cbc(), k2, NULL, !enc) == 0 || EVP_CipherInit(&c->k3, EVP_des_cbc(), k3, NULL, enc) == 0) { @@ -304,6 +333,7 @@ EVP_CIPHER_CTX_set_app_data(ctx, NULL); return (0); } +#endif return (1); } static int @@ -315,10 +345,16 @@ error("ssh1_3des_cbc: no context"); return (0); } +#ifdef SSH_OLD_EVP + EVP_Cipher(&c->k1, dest, (u_char *)src, len); + EVP_Cipher(&c->k2, dest, dest, len); + EVP_Cipher(&c->k3, dest, dest, len); +#else if (EVP_Cipher(&c->k1, dest, (u_char *)src, len) == 0 || EVP_Cipher(&c->k2, dest, dest, len) == 0 || EVP_Cipher(&c->k3, dest, dest, len) == 0) return (0); +#endif return (1); } static int @@ -346,7 +382,9 @@ ssh1_3des.init = ssh1_3des_init; ssh1_3des.cleanup = ssh1_3des_cleanup; ssh1_3des.do_cipher = ssh1_3des_cbc; +#ifndef SSH_OLD_EVP ssh1_3des.flags = EVP_CIPH_CBC_MODE | EVP_CIPH_VARIABLE_LENGTH; +#endif return (&ssh1_3des); } @@ -494,7 +532,9 @@ rijndal_cbc.init = ssh_rijndael_init; rijndal_cbc.cleanup = ssh_rijndael_cleanup; rijndal_cbc.do_cipher = ssh_rijndael_cbc; +#ifndef SSH_OLD_EVP rijndal_cbc.flags = EVP_CIPH_CBC_MODE | EVP_CIPH_VARIABLE_LENGTH | EVP_CIPH_ALWAYS_CALL_INIT; +#endif return (&rijndal_cbc); } From bugzilla-daemon at mindrot.org Sat Mar 9 20:28:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 20:28:41 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020309092841.DA457EB1A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From markus at openbsd.org 2002-03-09 20:28 ------- Created an attachment (id=35) this should make AES > 128 work (and 3des in ssh1) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Mar 9 20:30:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Mar 2002 20:30:41 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020309093041.A1029EB1F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From markus at openbsd.org 2002-03-09 20:30 ------- this should help for 3des/ssh1 http://bugzilla.mindrot.org/showattachment.cgi?attach_id=35 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Sat Mar 9 20:24:14 2002 From: markus at openbsd.org (Markus Friedl) Date: Sat, 9 Mar 2002 10:24:14 +0100 Subject: 3.1p1 + OpenSSL 0.9.5a -> no can do In-Reply-To: ; from samkaski@vortex.ll.sci.fi on Sat, Mar 09, 2002 at 03:22:02AM +0200 References: Message-ID: <20020309102414.C1515@folly> On Sat, Mar 09, 2002 at 03:22:02AM +0200, Samuli Kaski wrote: > What should I do in order to be able to compile OpenSSH 3.1p1 with > OpenSSL 0.9.5a? I get a lot of EVP related compile errors in cipher.c, > appended. Thanks. does this help? http://bugzilla.mindrot.org/showattachment.cgi?attach_id=35 From samkaski at vortex.ll.sci.fi Sat Mar 9 20:39:12 2002 From: samkaski at vortex.ll.sci.fi (Samuli Kaski) Date: Sat, 9 Mar 2002 11:39:12 +0200 (EET) Subject: 3.1p1 + OpenSSL 0.9.5a -> no can do In-Reply-To: <20020309102414.C1515@folly> Message-ID: Yes compile-wise but at least PuTTY gets broken(*), both the latest release and development versions. OpenSSH clients seem fine. Samuli (*) "Incorrect CRC received on packet" On Sat, 9 Mar 2002, Markus Friedl wrote: > On Sat, Mar 09, 2002 at 03:22:02AM +0200, Samuli Kaski wrote: > > What should I do in order to be able to compile OpenSSH 3.1p1 with > > OpenSSL 0.9.5a? I get a lot of EVP related compile errors in cipher.c, > > appended. Thanks. > > does this help? > > http://bugzilla.mindrot.org/showattachment.cgi?attach_id=35 > From samkaski at vortex.ll.sci.fi Sat Mar 9 21:55:28 2002 From: samkaski at vortex.ll.sci.fi (Samuli Kaski) Date: Sat, 9 Mar 2002 12:55:28 +0200 (EET) Subject: 3.1p1 + OpenSSL 0.9.5a -> no can do In-Reply-To: <20020309102414.C1515@folly> Message-ID: Follow-up: it seems to brake SSH1, SSH2 is fine (even with PuTTY). Samuli On Sat, 9 Mar 2002, Markus Friedl wrote: > On Sat, Mar 09, 2002 at 03:22:02AM +0200, Samuli Kaski wrote: > > What should I do in order to be able to compile OpenSSH 3.1p1 with > > OpenSSL 0.9.5a? I get a lot of EVP related compile errors in cipher.c, > > appended. Thanks. > > does this help? > > http://bugzilla.mindrot.org/showattachment.cgi?attach_id=35 > From bugzilla-daemon at mindrot.org Sun Mar 10 03:41:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Mar 2002 03:41:06 +1100 (EST) Subject: [Bug 152] Build failure on Sparc/Solaris 2.8 with Sun cc or gcc Message-ID: <20020309164106.28AC3E904@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=152 carson at taltos.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From carson at taltos.org 2002-03-10 03:41 ------- I just built stock 3.1p1 on Solaris 8/SPARC with Forte 6 (cc 5.1) with no problems. I suspect something on your system is unhappy. Try removing the - I/usr/local/include and see if that fixes things. If so, track down what you have in /usr/local/include that's breaking stuff. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 10 11:03:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Mar 2002 11:03:35 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020310000335.2B6B8E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From patl at cag.lcs.mit.edu 2002-03-10 11:03 ------- With http://bugzilla.mindrot.org/showattachment.cgi?attach_id=35 applied I get exactly the same failure as with the earlier patch: host1$ ./ssh -v -1 host2 [stuff elided] debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x8063930(0x0) I am running Red Hat 6.2 with all current updates. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From pdb_ml at yahoo.com.au Sun Mar 10 11:04:08 2002 From: pdb_ml at yahoo.com.au (=?iso-8859-1?q?Peter=20Bray?=) Date: Sun, 10 Mar 2002 11:04:08 +1100 (EST) Subject: OpenSSH-3.1p1 strips binaries by default - can not disbale Message-ID: <20020310000408.77491.qmail@web20305.mail.yahoo.com> Greetings, As the subject states "OpenSSH-3.1p1 strips binaries by default" and there is no ./configure --disable-strip or the like. In fact the "-s" to install are hardcoded into Makefile.in. Other distributions which support --disable-strip have a variable like ${STRIP} where the current "-s" hardcode is, which means even if the ./configure option is not present, it is simple to disable at "make install" time Regards, Peter Bray Sydney, Australia http://movies.yahoo.com.au - Yahoo! Movies - Vote for your nominees in our online Oscars pool. From farymer at lfx.org Sun Mar 10 16:34:57 2002 From: farymer at lfx.org (Dain Kaplan) Date: Sat, 9 Mar 2002 21:34:57 -0800 Subject: libssh Message-ID: All~ I recently started coding an SFTP client in Qt, since i noticed their seemed to be a lack of one with a gui for really any platform that didn't cost money. I wrote most of the FTP portion, and then I decided to begin working on the SFTP part. I couldn't really find documentation for an sshlib to use for developing this portion of my program. Sorry if i'm sending this email to the wrong place, i couldn't find a direct email to anyone at openssh and i thought the user list wasn't what i was looking for. Does anyone know of any documentation for libssh? From looking through the openssh code, it seemed that i might have to write my own based of libssl using some of the openssh code as an example. If there is already something that i could use, then i'd much rather do that =). Any direction or help would be great, thanks. --dain From mouring at etoh.eviladmin.org Sun Mar 10 16:31:31 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 9 Mar 2002 23:31:31 -0600 (CST) Subject: libssh In-Reply-To: Message-ID: I suggest looking at the sftp-*.c files.. mainly sftp-client.c for information on protocol details. Our sftp spawns ssh to create the session. the 'libssh' is not a usable library. It is there to short compile time. - Ben On Sat, 9 Mar 2002, Dain Kaplan wrote: > All~ > I recently started coding an SFTP client in Qt, since i noticed their seemed > to be a lack of one with a gui for really any platform that didn't cost > money. I wrote most of the FTP portion, and then I decided to begin working > on the SFTP part. I couldn't really find documentation for an sshlib to use > for developing this portion of my program. Sorry if i'm sending this email > to the wrong place, i couldn't find a direct email to anyone at openssh and > i thought the user list wasn't what i was looking for. > > Does anyone know of any documentation for libssh? From looking through the > openssh code, it seemed that i might have to write my own based of libssl > using some of the openssh code as an example. If there is already something > that i could use, then i'd much rather do that =). Any direction or help > would be great, thanks. > > > --dain > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From bugzilla-daemon at mindrot.org Sun Mar 10 20:04:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Mar 2002 20:04:53 +1100 (EST) Subject: [Bug 155] New: OpenSSH 3.1p1 fails to compile on BSDi 4.0 Message-ID: <20020310090453.038C0E93A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=155 Summary: OpenSSH 3.1p1 fails to compile on BSDi 4.0 Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: BSDI Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: tansympp at singnet.com.sg Hello, I OpenSSH 3.1p1 fails to compile on my BSDi4.0 box running gcc 2.7.2.1, and with OpenSSL 0.9.6b installed. The previous version OpenSSH 3.0.2p1 compiles cleanly though. The error that I got from OpenSSH 3.1p1 while compiling is gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib - L/usr/local/lib -lssh -lopenbsd-compat -lssh -lutil -lz -lcrypto gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. - I/usr/local/ssl/include -I/usr/local/lib -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand- helper\" -DHAVE_CONFIG_H -c ssh-agent.c ssh-agent.c: In function `lookup_identity': ssh-agent.c:135: warning: implicit declaration of function `TAILQ_FOREACH' ssh-agent.c:135: `next' undeclared (first use this function) ssh-agent.c:135: (Each undeclared identifier is reported only once ssh-agent.c:135: for each function it appears in.) ssh-agent.c:135: syntax error before `{' ssh-agent.c:138: warning: control reaches end of non-void function ssh-agent.c: At top level: ssh-agent.c:111: warning: `idtab_init' defined but not used ssh-agent.c:131: warning: `lookup_identity' defined but not used *** Error code 1 Stop. Is there something I have missed? The configure options that I specified were "- -with-tcp-wrappers=/usr/local/lib" and "--with-ipv4-default". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From markus at openbsd.org Thu Mar 7 22:56:33 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 7 Mar 2002 12:56:33 +0100 Subject: OpenSSH Security Advisory (adv.channelalloc) Message-ID: <20020307115633.GA8924@faui02> 1. Systems affected: All versions of OpenSSH between 2.0 and 3.0.2 contain an off-by-one error in the channel code. OpenSSH 3.1 and later are not affected. 2. Impact: This bug can be exploited locally by an authenticated user logging into a vulnerable OpenSSH server or by a malicious SSH server attacking a vulnerable OpenSSH client. 3. Solution: Upgrade to OpenSSH 3.1 or apply the following patch. 4. Credits: This bug was discovered by Joost Pol Appendix: Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.170 retrieving revision 1.171 diff -u -r1.170 -r1.171 --- channels.c 27 Feb 2002 21:23:13 -0000 1.170 +++ channels.c 4 Mar 2002 19:37:58 -0000 1.171 @@ -146,7 +146,7 @@ { Channel *c; - if (id < 0 || id > channels_alloc) { + if (id < 0 || id >= channels_alloc) { log("channel_lookup: %d: bad id", id); return NULL; } From mdb at juniper.net Mon Mar 11 03:31:47 2002 From: mdb at juniper.net (Mark D. Baushke) Date: Sun, 10 Mar 2002 08:31:47 -0800 Subject: [Bug 155] New: OpenSSH 3.1p1 fails to compile on BSDi 4.0 In-Reply-To: Mail from bugzilla-daemon@mindrot.org dated Sun, 10 Mar 2002 20:04:53 +1100 <20020310090453.038C0E93A@shitei.mindrot.org> Message-ID: <200203101631.g2AGVlT25672@merlot.juniper.net> >ssh-agent.c:135: warning: implicit declaration of function `TAILQ_FOREACH' I had the same problem until I removed /usr/local/include/sys/queue.h that had been left over from an old version of the Berkeley DB package. If your system has a /usr/include/sys/queue.h, then it is likely broken and you could try adding '#define HAVE_BOGUS_SYS_QUEUE_H 1' to your config.h file to see if this lets you build the sources. If your system does not have a /usr/include/sys/queue.h file, then look in the directories that are being searched by the -I options to your gcc command for a sys/queue.h file. From mouring at etoh.eviladmin.org Mon Mar 11 03:59:28 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 10 Mar 2002 10:59:28 -0600 (CST) Subject: [Bug 155] New: OpenSSH 3.1p1 fails to compile on BSDi 4.0 In-Reply-To: <200203101631.g2AGVlT25672@merlot.juniper.net> Message-ID: This works for 4.0 and 4.1 BSD/OS. It fails for 4.2 and is not required on 4.3+ The reason it fails for 4.2 is because they changed where sys/queues.h if a debug session with someone else was right. So I'm unsure how to proceed to ensure it works in all BSD/OS cases without breaking our fake-queues.h into smaller pieces. Or moving the includes into the defines.h - Ben On Sun, 10 Mar 2002, Mark D. Baushke wrote: > >ssh-agent.c:135: warning: implicit declaration of function `TAILQ_FOREACH' > > I had the same problem until I removed /usr/local/include/sys/queue.h > that had been left over from an old version of the Berkeley DB package. > > If your system has a /usr/include/sys/queue.h, then it is likely > broken and you could try adding '#define HAVE_BOGUS_SYS_QUEUE_H 1' to > your config.h file to see if this lets you build the sources. > > If your system does not have a /usr/include/sys/queue.h file, then look > in the directories that are being searched by the -I options > to your gcc command for a sys/queue.h file. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Mon Mar 11 06:17:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 06:17:57 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020310191757.1A374E915@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From markus at openbsd.org 2002-03-11 06:17 ------- Created an attachment (id=36) another revision of the cipher.c 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 Mon Mar 11 06:22:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 06:22:22 +1100 (EST) Subject: [Bug 141] openssh-3.1p1-1.src.rpm will not build on RedHat Linux 6.1 Message-ID: <20020310192222.95BE5E97D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=141 ------- Additional Comments From markus at openbsd.org 2002-03-11 06:22 ------- Created an attachment (id=37) this should work.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Mon Mar 11 06:13:41 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 10 Mar 2002 11:13:41 -0800 (PST) Subject: [Bug 155] New: OpenSSH 3.1p1 fails to compile on BSDi 4.0 In-Reply-To: Message-ID: On Sun, 10 Mar 2002, Ben Lindstrom wrote: :The reason it fails for 4.2 is because they changed where sys/queues.h :if a debug session with someone else was right. : :So I'm unsure how to proceed to ensure it works in all BSD/OS cases :without breaking our fake-queues.h into smaller pieces. Or moving :the includes into the defines.h is there a reason we cannot *always* use our queues.h? is there any platform where that implementation will not function correctly? From bugzilla-daemon at mindrot.org Mon Mar 11 06:30:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 06:30:35 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020310193035.8A743E9BA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From markus at openbsd.org 2002-03-11 06:30 ------- http://bugzilla.mindrot.org/showattachment.cgi?attach_id=37 ^^ this works for me with 3des-ssh1 and aes256-cbc (as used by PUTTY) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 11 06:41:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 06:41:56 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020310194156.74DFBE9C2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From patl at cag.lcs.mit.edu 2002-03-11 06:41 ------- Yup, that makes 3des with protocol 1 work. Thanks! "blowfish" is still broken, though. Any chance of fixing it, too? We have some automated scripts here which specify Blowfish for speed. Yes, we should migrate to protocol 2 and AES. But not this weekend :-). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Mon Mar 11 09:14:54 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 10 Mar 2002 14:14:54 -0800 (PST) Subject: Cannot run OpenSSH 3.1p1 on Solaris 8, Irix 6.5.14, Irix 6.5.4, SunOS 4.1.3_U1 - ssh-rand-helper child produced insufficient data In-Reply-To: <3C893A3F.2C9137E9@no-spam.edu> Message-ID: On Fri, 8 Mar 2002, Andy Ozment wrote: :Checking my random number pool shows that I have plenty of bits :available: :$ egc-irix.pl /var/run/egd-pool get : 32800 bits of entropy in pool :$ /usr/sbin/sshd -D -d -d -d :debug3: Seeing PRNG from /usr/libexec/ssh-rand-helper :ssh-rand-helper child produced insufficient data i don't know. that message is output when ssh-rand-helper does not return 48 bytes of output. what does: ssh-rand-helper|od -b show? when you ran configure, did it show the correct path to the prngd socket? From bugzilla-daemon at mindrot.org Mon Mar 11 10:42:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 10:42:09 +1100 (EST) Subject: [Bug 156] New: Problem interacting with SSH on DigitalUnix Message-ID: <20020310234209.C196FE9C8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=156 Summary: Problem interacting with SSH on DigitalUnix Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: alberto.gianoli at fe.infn.it The problem happens trying to copy a file from a linux machine with openssh to an Alpha with Tru64Unix 5.0 and SSH 3.1.0. Normal ssh and sftp connections work without any problem. Even doing an scp from the alpha to the linux machine works, but not the viceversa. I have tried several versions of openssh, from 2.9 to the latest (both redhat versions and plain openssh versions), but they all generate the same problem. Here is what I get when I add the verbose option (giano is my linux box while axpfe is the True64 machine): giano:~/ >scp -oProtocol=2 -v code.c xyz at axpfe:giano.c Executing: program /usr/bin/ssh host axpfe, user xyz, command scp -v -t giano.c OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 24230 geteuid 0 anon 1 debug1: Connecting to axpfe [192.84.144.22] port 22. debug1: temporarily_use_uid: 24230/30069 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 24230/30069 (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 /home/gianoli/.ssh/id_rsa type -1 debug1: identity file /home/gianoli/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version 3.1.0 SSH Secure Shell (non-commercial) debug1: no match: 3.1.0 SSH Secure Shell (non-commercial) Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 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: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 487/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'axpfe' is known and matches the DSA host key. debug1: Found key in /home/gianoli/.ssh/known_hosts2:5 debug1: bits set: 543/1024 debug1: ssh_dss_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 debug1: next auth method to try is publickey debug1: try privkey: /home/gianoli/.ssh/id_rsa debug1: try pubkey: /home/gianoli/.ssh/id_dsa debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x8086da0 hint 1 debug1: read PEM private key done: type DSA debug1: ssh-userauth2 successful: method publickey debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: Sending command: scp -v -t giano.c debug1: channel request 0: exec debug1: channel 0: open confirm rwindow 100000 rmax 32768 scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd close debug1: channel 0: output open -> drain debug1: channel 0: close_read debug1: channel 0: input open -> closed debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 255 lost connection Apparently something sent from openssh confuses the ssh daemon on the alpha who tries to switch to protocol 1. This problem is always repeatable (I never succeded to transfer a file) and, as I already said, limited to scp (ssh and sftp work without a glitch). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Mon Mar 11 13:22:15 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 10 Mar 2002 20:22:15 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? Message-ID: <1015813336.12561.0.camel@UberGeek> Just curious. There seems to be an awful lot in the source, but no actual configure option. Please advise. -- 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 From djm at mindrot.org Mon Mar 11 13:54:52 2002 From: djm at mindrot.org (Damien Miller) Date: Mon, 11 Mar 2002 13:54:52 +1100 (EST) Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <1015813336.12561.0.camel@UberGeek> Message-ID: On 10 Mar 2002, Austin Gonyou wrote: > Just curious. There seems to be an awful lot in the source, but no > actual configure option. We are waiting on a compatibility patch so our auth-krb5.c will compile against MIT krbV. -d From bugzilla-daemon at mindrot.org Mon Mar 11 14:17:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 14:17:21 +1100 (EST) Subject: [Bug 156] Problem interacting with SSH on DigitalUnix Message-ID: <20020311031721.A1940E927@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=156 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From mouring at eviladmin.org 2002-03-11 14:17 ------- scp: warning: Executing scp1 compatibility. scp: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). OpenSSH's scp is rcp protocol. And requires you to have scp1 from SSH Corp installed for it to work since SSH Corp decided to break backwards compability otherwise. Please use sftp or ensure scp1 is in your $PATH. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Mon Mar 11 16:24:52 2002 From: tim at multitalents.net (Tim Rice) Date: Sun, 10 Mar 2002 21:24:52 -0800 (PST) Subject: Update to solaris package creation In-Reply-To: Message-ID: On Tue, 5 Mar 2002, Ben Lindstrom wrote: > > Over all it looks fine.. only comment I have is preremove and preinstall > scripts should not exist if you tell it not to start/stop OpenSSH > from the package. > > If they do exist then the admin be prompted.. With the default 'n' if > your doing a non-attendented install. > > Mainly because build time is not the correct time to decide if OpenSSH > should be started or stopped. Again we revert back to Admin's (installer) > choice. > > One could argue the same about hardlinks vs softlinks also.. But I > won't make it since I don't care. =) > > - Ben > OK I've made a few changes after looking at the feedback. You are now prompted at install time if you want symbolic links, restart the daemon, etc. (defaults to no) I've used Darren Tucker's bits to grab the info out of Makefile The Version info now comes straight from ssh -V I included support for building a test package that will not overwrite anything in /etc/*.d Here are the comments about that from buildpkg.sh # uncommenting TEST_DIR and using configure--prefix=/var/tmp and # PKGNAME=tOpenSSH should allow testing a package without interfering # with a real OpenSSH package on a system. #TEST_DIR=/var/tmp # leave commented out for production build I've added a perl script to fix PrintMotd in sshd_confg (should be no) You can now optionally set PermitRootLogin no and X11Forwarding yes at package build time. # uncomment these next two as needed #PERMIT_ROOT_LOGIN=no #X11_FORWARDING=yes It works good here on Solaris 7 & 8, UnixWare 2.1.3 & 7.1.1 Other testers welcome. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- #!/bin/sh # # Fake Root Solaris/SVR4/SVR5 Build System - Prototype # # The following code has been provide under Public Domain License. I really # don't care what you use it for. Just as long as you don't complain to me # nor my employer if you break it. - Ben Lindstrom (mouring at eviladmin.org) # umask 022 # # Options for building the package # You can create a config.local with your customized options # # uncommenting TEST_DIR and using configure--prefix=/var/tmp and # PKGNAME=tOpenSSH should allow testing a package without interfering # with a real OpenSSH package on a system. #TEST_DIR=/var/tmp # leave commented out for production build PKGNAME=OpenSSH SYSVINIT_NAME=opensshd MAKE=${MAKE:="make"} # uncomment these next two as needed #PERMIT_ROOT_LOGIN=no #X11_FORWARDING=yes # list of system directories we do NOT want to change owner/group/perms # when installing our package SYSTEM_DIR="/etc \ /etc/init.d \ /etc/rcS.d \ /etc/rc0.d \ /etc/rc1.d \ /etc/rc2.d \ /opt \ /opt/bin \ /usr \ /usr/bin \ /usr/lib \ /usr/sbin \ /usr/share \ /usr/share/man \ /usr/share/man/man1 \ /usr/share/man/man8 \ /usr/local \ /usr/local/bin \ /usr/local/etc \ /usr/local/libexec \ /usr/local/man \ /usr/local/man/man1 \ /usr/local/man/man8 \ /usr/local/sbin \ /usr/local/share \ /var \ /var/run \ /var/tmp \ /tmp" # We may need to buiild as root so we make sure PATH is set up # only set the path if it's not set already [ -d /usr/local/bin ] && { echo $PATH | grep ":/usr/local/bin" > /dev/null 2>&1 [ $? -ne 0 ] && PATH=$PATH:/usr/local/bin } [ -d /usr/ccs/bin ] && { echo $PATH | grep ":/usr/ccs/bin" > /dev/null 2>&1 [ $? -ne 0 ] && PATH=$PATH:/usr/ccs/bin } export PATH # [ -f Makefile ] || { echo "Please run this script from your build directory" exit 1 } # we will look for config.local to override the above options [ -s ./config.local ] && . ./config.local ## Start by faking root install echo "Faking root install..." START=`pwd` OPENSSHD_IN=`dirname $0`/opensshd.in FAKE_ROOT=$START/package [ -d $FAKE_ROOT ] && rm -fr $FAKE_ROOT mkdir $FAKE_ROOT ${MAKE} install-nokeys DESTDIR=$FAKE_ROOT if [ $? -gt 0 ] then echo "Fake root install failed, stopping." exit 1 fi ## Fill in some details, like prefix and sysconfdir for confvar in prefix exec_prefix bindir sbindir libexecdir datadir mandir sysconfdir piddir do eval $confvar=`grep "^$confvar=" Makefile | cut -d = -f 2` done ## Extract common info requires for the 'info' part of the package. VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//'` UNAME_S=`uname -s` case ${UNAME_S} in SunOS) UNAME_S=Solaris ARCH=`uname -p` RCS_D=yes DEF_MSG="(default: n)" ;; *) ARCH=`uname -m` ;; esac ## Setup our run level stuff while we are at it. mkdir -p $FAKE_ROOT${TEST_DIR}/etc/init.d ## setup our initscript correctly sed -e "s#%%configDir%%#${sysconfdir}#g" \ -e "s#%%openSSHDir%%#$prefix#g" \ -e "s#%%pidDir%%#${piddir}#g" \ ${OPENSSHD_IN} > $FAKE_ROOT${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} chmod 744 $FAKE_ROOT${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} [ "${PERMIT_ROOT_LOGIN}" = no ] && \ perl -p -i -e "s/#PermitRootLogin yes/PermitRootLogin no/" \ $FAKE_ROOT/${sysconfdir}/sshd_config [ "${X11_FORWARDING}" = yes ] && \ perl -p -i -e "s/#X11Forwarding no/X11Forwarding yes/" \ $FAKE_ROOT/${sysconfdir}/sshd_config # fix PrintMotd perl -p -i -e "s/#PrintMotd yes/PrintMotd no/" \ $FAKE_ROOT/${sysconfdir}/sshd_config # We don't want to overwrite config files on multiple installs mv $FAKE_ROOT/${sysconfdir}/ssh_config $FAKE_ROOT/${sysconfdir}/ssh_config.default mv $FAKE_ROOT/${sysconfdir}/sshd_config $FAKE_ROOT/${sysconfdir}/sshd_config.default [ -f $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds ] && \ mv $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds $FAKE_ROOT/${sysconfdir}/ssh_prng_cmds.default cd $FAKE_ROOT ## Ok, this is outright wrong, but it will work. I'm tired of pkgmk ## whining. for i in *; do PROTO_ARGS="$PROTO_ARGS $i=/$i"; done ## Build info file echo "Building pkginfo file..." cat > pkginfo << _EOF PKG=$PKGNAME NAME="OpenSSH Portable for ${UNAME_S}" DESC="Secure Shell remote access utility; replaces telnet and rlogin/rsh." VENDOR="OpenSSH Portable Team - http://www.openssh.com/portable.html" ARCH=$ARCH VERSION=$VERSION CATEGORY="Security,application" BASEDIR=/ CLASSES="none" _EOF ## Build preinstall file echo "Building preinstall file..." cat > preinstall << _EOF #! /sbin/sh # [ "\${PRE_INS_STOP}" = "yes" ] && ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} stop exit 0 _EOF ## Build postinstall file echo "Building postinstall file..." cat > postinstall << _EOF #! /sbin/sh # [ -f ${sysconfdir}/ssh_config ] || \\ cp -p ${sysconfdir}/ssh_config.default ${sysconfdir}/ssh_config [ -f ${sysconfdir}/sshd_config ] || \\ cp -p ${sysconfdir}/sshd_config.default ${sysconfdir}/sshd_config [ -f ${sysconfdir}/ssh_prng_cmds.default ] && { [ -f ${sysconfdir}/ssh_prng_cmds ] || \\ cp -p ${sysconfdir}/ssh_prng_cmds.default ${sysconfdir}/ssh_prng_cmds } # make rc?.d dirs only if we are doing a test install [ -n "${TEST_DIR}" ] && { [ "$RCS_D" = yes ] && mkdir -p ${TEST_DIR}/etc/rcS.d mkdir -p ${TEST_DIR}/etc/rc0.d mkdir -p ${TEST_DIR}/etc/rc1.d mkdir -p ${TEST_DIR}/etc/rc2.d } if [ "\${USE_SYM_LINKS}" = yes ] then [ "$RCS_D" = yes ] && \ installf ${PKGNAME} $TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s installf ${PKGNAME} $TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s installf ${PKGNAME} $TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s installf ${PKGNAME} $TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=../init.d/${SYSVINIT_NAME} s else [ "$RCS_D" = yes ] && \ installf ${PKGNAME} $TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l installf ${PKGNAME} $TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l installf ${PKGNAME} $TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l installf ${PKGNAME} $TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME}=$TEST_DIR/etc/init.d/${SYSVINIT_NAME} l fi installf -f ${PKGNAME} [ "\${POST_INS_START}" = "yes" ] && ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} start exit 0 _EOF ## Build preremove file echo "Building preremove file..." cat > preremove << _EOF #! /sbin/sh # ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} stop exit 0 _EOF ## Build request file echo "Building request file..." cat > request << _EOF trap 'exit 3' 15 USE_SYM_LINKS=no PRE_INS_STOP=no POST_INS_START=no # Use symbolic links? ans=\`ckyorn -d n \ -p "Do you want symbolic links for the start/stop scripts? ${DEF_MSG}"\` || exit \$? case \$ans in [y,Y]*) USE_SYM_LINKS=yes ;; esac # determine if should restart the daemon if [ -s ${piddir}/sshd.pid -a -f ${TEST_DIR}/etc/init.d/${SYSVINIT_NAME} ] then ans=\`ckyorn -d n \ -p "Should the running sshd daemon be restarted? ${DEF_MSG}"\` || exit \$? case \$ans in [y,Y]*) PRE_INS_STOP=yes POST_INS_START=yes ;; esac else # determine if we should start sshd ans=\`ckyorn -d n \ -p "Start the sshd daemon after installing this package? ${DEF_MSG}"\` || exit \$? case \$ans in [y,Y]*) POST_INS_START=yes ;; esac fi # make parameters available to installation service, # and so to any other packaging scripts cat >\$1 < space << _EOF # extra space required by start/stop links added by installf in postinstall $TEST_DIR/etc/rc0.d/K30${SYSVINIT_NAME} 0 1 $TEST_DIR/etc/rc1.d/K30${SYSVINIT_NAME} 0 1 $TEST_DIR/etc/rc2.d/S98${SYSVINIT_NAME} 0 1 _EOF [ "$RCS_D" = yes ] && \ echo "$TEST_DIR/etc/rcS.d/K30${SYSVINIT_NAME} 0 1" >> space ## Next Build our prototype echo "Building prototype file..." cat >mk-proto.awk << _EOF BEGIN { print "i pkginfo"; print "i preinstall"; \\ print "i postinstall"; print "i preremove"; \\ print "i request"; print "i space"; \\ split("$SYSTEM_DIR",sys_files); } { for (dir in sys_files) { if ( \$3 != sys_files[dir] ) { \$5="root"; \$6="sys"; } else { \$4="?"; \$5="?"; \$6="?"; break;} } } { print; } _EOF find . | egrep -v "prototype|pkginfo|mk-proto.awk" | sort | \ pkgproto $PROTO_ARGS | nawk -f mk-proto.awk > prototype ## Step back a directory and now build the package. echo "Building package.." cd .. pkgmk -d ${FAKE_ROOT} -f $FAKE_ROOT/prototype -o echo | pkgtrans -os ${FAKE_ROOT} ${START}/$PKGNAME-$UNAME_S-$ARCH-$VERSION.pkg rm -rf $FAKE_ROOT From jhawk at MIT.EDU Mon Mar 11 17:00:42 2002 From: jhawk at MIT.EDU (John Hawkinson) Date: Mon, 11 Mar 2002 01:00:42 -0500 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: References: <1015813336.12561.0.camel@UberGeek> Message-ID: <20020311060042.GF8045@multics.mit.edu> Damien Miller wrote on Mon, 11 Mar 2002 at 13:54:52 +1100 in : > On 10 Mar 2002, Austin Gonyou wrote: > > > Just curious. There seems to be an awful lot in the source, but no > > actual configure option. > > We are waiting on a compatibility patch so our auth-krb5.c will compile > against MIT krbV. So in the meantime, you can either use Heimdal instead of MIT krb5, or you can get Simon Wilkinson's patch from "http://www.sxw.org.uk/computing/patches/openssh.html". --jhawk From bugzilla-daemon at mindrot.org Mon Mar 11 22:24:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 11 Mar 2002 22:24:39 +1100 (EST) Subject: [Bug 157] New: X11 Forwarding breaks Message-ID: <20020311112439.F3716E927@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=157 Summary: X11 Forwarding breaks Product: Portable OpenSSH Version: 3.1p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: michael.exner at mrz.uni-magdeburg.de After updating Openssh from 2.9p2 to 3.1p1 some applications fail to tunnel X11. While the X11-Forwarding works for some X-Clients (xload, xclock and even sam) other clients (netscape and the X-Clients of Omniback) are reporting "connection to localhost:12.0 broken (explicit kill or server shutdown)". (With openssh 2.9.p2 all was fine) I don't know if this is a bug or a configuration-failure, so please let me know about this. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fam.muck at telda.net Mon Mar 11 22:50:52 2002 From: fam.muck at telda.net (Andreas Muck) Date: Mon, 11 Mar 2002 12:50:52 +0100 Subject: Password-Authentication with openssh-3.1p1 fails Message-ID: <3C8CA82C.21486.302AFD@localhost> Hallo out there, I've got a strange problem after updating my openssh-installation from 2.9.9p2 (SuSE-package) to openssh-3.1p1 (Installation from the source with a modified src.rpm). I will give you as much information as possible and I hope there is anybody who can help me. I asked in detail in usenet-groups but nobody had any idea to fix my problem by configuration. My system is a SuSE-Linux 7.2: -kernel 2.4.16-4GB (original SuSE-7.2-package) -pam 0.75 (SuSE-7.3-package after rebuilding) -previous openssh-version: 2.9.9p2 (original SuSE-7.2-package) On this system I could work with openssh as expected: authentication works with pubkey- and password-authentication (other authentication-methods were not allowed). After updating my openssh-package to the current version pubkey-authentication still works but password-authentication fails in every case. I compiled openssh-3.1p1 as follows (options included in the src.rpm): ./configure \ --mandir=%{_mandir} \ --prefix=%{prefix} \ --infodir=%{_infodir} \ --sysconfdir=/etc/ssh \ --libexecdir=%{prefix}/lib/ssh \ --with-tcp-wrappers \ --with-pam make Software- and package-building works fine. After installation I can connect to localhost via pubkey- authentication (server running in debug-mode): andreas at home:~ > ssh localhost Enter passphrase for key '/home/andreas/.ssh/id_rsa': Last login: Sat Mar 9 19:48:41 2002 from console Have a lot of fun... debug1: PAM establishing creds Environment: USER=andreas LOGNAME=andreas HOME=/home/andreas PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail/andreas SHELL=/bin/bash SSH_CLIENT=127.0.0.1 1046 22 SSH_TTY=/dev/pts/4 TERM=xterm andreas at home:~ > When I disable my authorized_keys-files I would expect password-authentication - which takes place, but I've got no connection even if I type my correct password (you can be sure that the password used is correct): andreas at home:~ > mv ./.ssh/authorized_keys2 \ ./.ssh/authorized_keys2.orig andreas at home:~ > ssh localhost andreas at localhost's password: Permission denied, please try again. andreas at localhost's password: Permission denied, please try again. andreas at localhost's password: Permission denied (publickey,password,keyboard-interactive). andreas at home:~ > Here is server-output in debug-mode: bash-2.05# sshd -4 -d debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 1053 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.1p1 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none 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: 121/256 debug1: bits set: 1655/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1583/3191 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 andreas service ssh-connection method none debug1: attempt 0 failures 0 debug1: Starting up PAM with username "andreas" debug1: PAM setting rhost to "localhost" Failed none for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys debug1: restore_uid debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method publickey debug1: attempt 2 failures 2 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys debug1: restore_uid debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method keyboard-interactive debug1: attempt 3 failures 3 debug1: keyboard-interactive devs debug1: auth2_challenge: user=andreas devs= debug1: kbdint_alloc: devices '' Failed keyboard-interactive for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method password debug1: attempt 4 failures 4 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method passworddebug1: attempt 5 failures 5 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method passworddebug1: attempt 6 failures 6 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 Connection closed by 127.0.0.1 debug1: Calling cleanup 0x8052ce0(0x0) debug1: Calling cleanup 0x8068e20(0x0) bash-2.05# That is the part of /var/log/messages generated by PAM: Mar 9 20:14:55 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:14:55 home PAM-unix2[1045]: username=[andreas] Mar 9 20:14:55 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Mar 9 20:14:59 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:14:59 home PAM-unix2[1045]: username=[andreas] Mar 9 20:14:59 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Mar 9 20:15:04 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:15:04 home PAM-unix2[1045]: username=[andreas] Mar 9 20:15:04 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Here is my /etc/pam.d/sshd: #%PAM-1.0 auth required /lib/security/pam_unix.so debug # \ set_secrpc auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_unix.so password required /lib/security/pam_pwcheck.so md5 \ use_cracklib password required /lib/security/pam_unix.so md5 \ use_first_pass use_authtok session required /lib/security/pam_unix.so none # \ trace or debug session required /lib/security/pam_limits.so This /etc/pam.d/sshd works fine with openssh-2.9.9p2 (SuSE-package). My /etc/ssh/sshd_config is empty (all entries are comments) except for the sftp-subsystem. My ~/.ssh/config is empty too. I think there is a problem with PAM, but I'm sure my configuration is valid. It seems that openssh passes a wrong password to PAM which results in an error. So, much thanks for your effort fighting through my infos, I hope there is anybody who has any idea! Ciao Andreas From RGiersig at a1.net Tue Mar 12 00:38:42 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Mon, 11 Mar 2002 14:38:42 +0100 Subject: Logging of client commands, possible? Message-ID: <150026148fac.148fac150026@a1.net> Hi folks, sorry if this has been discussed before, I did a quick search on the mailing list but found nothing pertinent. My question: is it possible to log all data that is sent from the ssh client to the sshd server? Rationale: I'd like to log all commands that users execute when being logged in via ssh. And I mean all, as the system in question is a sensitive production server, so the shell history isn't quite sufficient. I've found nothing in the manpages, only syslog levels (DEBUG1..4) are mentioned. A cursory glance through the CVS source didn't show any logging facilities and didn't answer the question if the syslog level debugging can handle that, so I'm asking the developers. Has this concept been discussed before? Thanks in advance, Roland -- RGiersig at cpan.org From dan at doxpara.com Wed Mar 13 01:55:38 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Mar 2002 06:55:38 -0800 Subject: Logging of client commands, possible? References: <150026148fac.148fac150026@a1.net> Message-ID: <000901c1c9d5$f9078080$1701000a@effugas> > sorry if this has been discussed before, I did a quick search on the > mailing list but found nothing pertinent. > > My question: is it possible to log all data that is sent from the ssh > client to the sshd server? > > Rationale: I'd like to log all commands that users execute when being > logged in via ssh. And I mean all, as the system in question is a > sensitive production server, so the shell history isn't quite > sufficient. There are TTY snooping apps, but SSH can be used to execute commands without a TTY. (For example, one can use SSH to execute a non-snooping SSHD that would escape the TTY sniffer. But that's pretty damn obscure.) Recording all traffic in and out of SSHD is certainly possible, and for the highly sensitive environment you refer to, not necessarily a bad idea... Hmmm. If you need something urgently, some variation on messing around with script might help. The ugliness of making this happen right is a good sign that building this into OpenSSH might be the right idea. But: # mv /bin/csh /bin/csh_real # cat > /bin/csh #!/bin/sh exec script -q /tmp/log.$$ csh_real # chmod 0755 /bin/csh ...*does* seem to have a useful effect, without involving kernel level sniffing. There are *all* sorts of problems -- the logs are owned by the users, the logger shows up and can be killed by the user, and I don't even want to think about how to trace /bin/sh like that -- but it ain't bad for about 5 minutes of thought :-) --Dan From mouring at etoh.eviladmin.org Tue Mar 12 01:56:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 08:56:47 -0600 (CST) Subject: Logging of client commands, possible? In-Reply-To: <000901c1c9d5$f9078080$1701000a@effugas> Message-ID: On Tue, 12 Mar 2002, Dan Kaminsky wrote: > > sorry if this has been discussed before, I did a quick search on the > > mailing list but found nothing pertinent. > > > > My question: is it possible to log all data that is sent from the ssh > > client to the sshd server? > > > > Rationale: I'd like to log all commands that users execute when being > > logged in via ssh. And I mean all, as the system in question is a > > sensitive production server, so the shell history isn't quite > > sufficient. > > There are TTY snooping apps, but SSH can be used to execute commands without > a TTY. (For example, one can use SSH to execute a non-snooping SSHD that > would escape the TTY sniffer. But that's pretty damn obscure.) > > Recording all traffic in and out of SSHD is certainly possible, and for the > highly sensitive environment you refer to, not necessarily a bad idea... > > Hmmm. If you need something urgently, some variation on messing around with > script might help. The ugliness of making this happen right is a good sign > that building this into OpenSSH might be the right idea. But: > > # mv /bin/csh /bin/csh_real > # cat > /bin/csh > #!/bin/sh > exec script -q /tmp/log.$$ csh_real > # chmod 0755 /bin/csh > > ...*does* seem to have a useful effect, without involving kernel level > sniffing. There are *all* sorts of problems -- the logs are owned by the > users, the logger shows up and can be killed by the user, and I don't even > want to think about how to trace /bin/sh like that -- but it ain't bad for > about 5 minutes of thought :-) > Problems like someone uploading a shell script called 'whiterabit.sh' and then running it? And at the end of the script it removes itself? Using System Auditing Reports is the only sane way of doing this. As it was pointed out in secureshell@ - Ben From dan at doxpara.com Wed Mar 13 02:49:42 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Mar 2002 07:49:42 -0800 Subject: Logging of client commands, possible? References: Message-ID: <001c01c1c9dd$86deac60$1701000a@effugas> > Problems like someone uploading a shell script called 'whiterabit.sh' > and then running it? And at the end of the script it removes itself? > > Using System Auditing Reports is the only sane way of doing this. As > it was pointed out in secureshell@ I'm not sure it's sane, but it's definitely the "correct" method. Correct doesn't mean usable, though. Enforcing accountability among trusted peers is often even more important than maintaining security -- when something breaks, first you want to know who broke it, then you want to know what they did to cause the break. The problem with security-complete reports is they're pretty damn unparseable -- this file was opened, that data was sent, and it all adds up. For sheer usefulness, it can be nice just to see an interactive history. That being said, I wouldn't underestimate the strength of TTY logs. Attackers really rarely check to see if their bytestreams are being monitored at the endpoint -- note the logs of Mitnick's hack from a few years back. I consider this request somewhat orthogonal to the security aspects of SSH -- it's a trait of the shell environment that the admin would like SSH to securely provide, rather than a trait of the security SSH is applying to the system. --Dan From mouring at etoh.eviladmin.org Tue Mar 12 02:17:50 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 09:17:50 -0600 (CST) Subject: Logging of client commands, possible? In-Reply-To: <001c01c1c9dd$86deac60$1701000a@effugas> Message-ID: On Tue, 12 Mar 2002, Dan Kaminsky wrote: > > Problems like someone uploading a shell script called 'whiterabit.sh' > > and then running it? And at the end of the script it removes itself? > > > > Using System Auditing Reports is the only sane way of doing this. As > > it was pointed out in secureshell@ > > I'm not sure it's sane, but it's definitely the "correct" method. Correct > doesn't mean usable, though. > If your SAR is well written there is a 'command logging' mode. Which logs all exec() that occur from a user. It is better for getting an idea of what the user did before diving into the true SAR reports. But on an average the only way to ensure security is via the detail sar report. Otherwise you end up with the binary version of 'whiterabbit.sh'... And of course if we are talking about root users here then they could disable SAR as the first few things in the script/binary and renable it before remove the binary. - Ben From jolumape_al at hotmail.com Tue Mar 12 03:11:34 2002 From: jolumape_al at hotmail.com (Jose Luis) Date: Mon, 11 Mar 2002 11:11:34 -0500 Subject: (no subject) Message-ID: _________________________________________________________________ Descargue GRATUITAMENTE MSN Explorer en http://explorer.yupimsn.com/intl.asp From RGiersig at a1.net Tue Mar 12 03:43:06 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Mon, 11 Mar 2002 17:43:06 +0100 Subject: Logging of client commands, possible? Message-ID: > > Using System Auditing Reports is the only sane way of doing > > this. As it was pointed out in secureshell@ > > I'm not sure it's sane, but it's definitely the "correct" method. > Correct doesn't mean usable, though. > > Enforcing accountability among trusted peers is often even more > importantthan maintaining security -- when something breaks, first > you want to know > who broke it, then you want to know what they did to cause the break. Right. I concurr that SARs are the correct way to do this and even tried to set them up, but alas, configuration was a nightmare and usability was abysmal. I haven't looked into TTY auditing, that of course would be the best thing if the kernel gives you the possibility to log what is sent via a pseudo-terminal. But I don't think that that there are many OSes with that ability... > I consider this request somewhat orthogonal to the security > aspects of SSH -- it's a trait of the shell environment that > the admin would like SSH to securely provide, rather than > a trait of the security SSH is applying to the system. You are right of course, but given that SSHD is a single point of authenticated data flow, adding logging to SSHD gives maximum flexibility. Instead of having to enforce the usage of a certain shell that does logging and thus restricting the users choices (one user wants bash, that one zsh, that one ksh...) I simply log what the client sends to the server. This also includes what gets sent via 'scp', so that whiterabbit.sh gets logged too. Of course there are a lot of holes to be plugged, port-forwarding for example, to make this hacker- proofed... As of orthogonal, I don't think so. SSH is very strong on authorisation, why should auditing be left out? Anyway, what's the chance that a patch for logging would be accepted and incorporated? Cheers! Roland -- RGiersig at cpan.org From Nicolas.Williams at ubsw.com Tue Mar 12 04:34:49 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 11 Mar 2002 12:34:49 -0500 Subject: Logging of client commands, possible? In-Reply-To: ; from RGiersig@a1.net on Mon, Mar 11, 2002 at 05:43:06PM +0100 References: Message-ID: <20020311123448.F27398@sm2p1386swk.wdr.com> On Mon, Mar 11, 2002 at 05:43:06PM +0100, RGiersig at a1.net wrote: > I haven't looked into TTY auditing, that of course would be the best > thing if the kernel gives you the possibility to log what is sent via a > pseudo-terminal. But I don't think that that there are many OSes with > that ability... There's no technical reason why sshd couldn't implement TTY logging. > > I consider this request somewhat orthogonal to the security > > aspects of SSH -- it's a trait of the shell environment that > > the admin would like SSH to securely provide, rather than > > a trait of the security SSH is applying to the system. > > You are right of course, but given that SSHD is a single point of > authenticated data flow, adding logging to SSHD gives maximum > flexibility. Instead of having to enforce the usage of a certain shell > that does logging and thus restricting the users choices (one user > wants bash, that one zsh, that one ksh...) I simply log what the client > sends to the server. This also includes what gets sent via 'scp', so > that whiterabbit.sh gets logged too. Of course there are a lot of > holes to be plugged, port-forwarding for example, to make this hacker- > proofed... You're saying that with you'd really like to be able to get detailed activity logs sorted by session and that makes you think that sshd is the right place to build in the necessary technology. There is only one way to safely get detailed activity logs and that's throguh kernel hooks (that's part of what BSM auditing does on Solaris, for example). But you could kluge it by using library interposition techniques, e.g., through an LD_PRELOADable object that wraps around all the system calls and library routines that you care about - then sshd's only role would be to enforce the LD_PRELOAD setting (you can also use library filters and eschew LD_PRELOAD). Regardless, activity logging, other than TTY logging, doesn't belong in sshd, and tty logging can be done externally to sshd, with varying degrees of difficulty depending on what facilities the OS provides. > As of orthogonal, I don't think so. SSH is very strong on > authorisation, why should auditing be left out? Whose job is it to log what activity? How can sshd log what children processes are doing? By tracing them? Keep dreaming - that would be double plus unfun. See above about session-sorting sar and also see above about logging through library filtering. > Anyway, what's the chance that a patch for logging would be accepted > and incorporated? > > Cheers! > > Roland > -- > RGiersig at cpan.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 Tue Mar 12 05:15:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 05:15:17 +1100 (EST) Subject: [Bug 157] X11 Forwarding breaks Message-ID: <20020311181517.3C747E9F8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=157 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From stevesk at pobox.com 2002-03-12 05:15 ------- closing as dup of 150 *** This bug has been marked as a duplicate of 150 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 12 05:15:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 05:15:22 +1100 (EST) Subject: [Bug 150] configure option --with-ipaddr-display seems to have no effect Message-ID: <20020311181522.3A92DE9FA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=150 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.exner at mrz.uni- | |magdeburg.de ------- Additional Comments From stevesk at pobox.com 2002-03-12 05:15 ------- *** Bug 157 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Tue Mar 12 05:15:11 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 11 Mar 2002 12:15:11 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <20020311060042.GF8045@multics.mit.edu> References: <20020311060042.GF8045@multics.mit.edu> Message-ID: <1015870511.15387.4.camel@UberGeek> Gotcha, that would explain the code. Thx for this! On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > Damien Miller wrote on Mon, 11 Mar 2002 > at 13:54:52 +1100 in > : > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > Just curious. There seems to be an awful lot in the source, but no > > > actual configure option. > > > > We are waiting on a compatibility patch so our auth-krb5.c will > compile > > against MIT krbV. > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > you can get Simon Wilkinson's patch from > "http://www.sxw.org.uk/computing/patches/openssh.html". > > --jhawk -- 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 From bugzilla-daemon at mindrot.org Tue Mar 12 05:23:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 05:23:52 +1100 (EST) Subject: [Bug 150] configure option --with-ipaddr-display seems to have no effect Message-ID: <20020311182352.42F15EA02@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=150 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com ------- Additional Comments From stevesk at pobox.com 2002-03-12 05:23 ------- for hp-ux 11, navigator-v479-us.hppa1.1-hp-hpux11.tar.gz functions correctly with localhost DISPLAY. /opt/netscape/netscape: shared executable shared library dynamic path search: SHLIB_PATH disabled second embedded path disabled first Not Defined shared library list: dynamic /usr/lib/Motif2.1/libXm.4 dynamic /usr/lib/X11R6/libXt.3 dynamic /usr/lib/X11R6/libX11.3 dynamic /usr/lib/X11R6/libXext.3 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 12 06:42:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 06:42:20 +1100 (EST) Subject: [Bug 158] New: ssh-add trips up due to missing key types Message-ID: <20020311194220.53950EA08@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 Summary: ssh-add trips up due to missing key types Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P4 Component: ssh-add AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wknox at mitre.org ssh-add will now return a non-zero status when adding keys, due solely to the fact that one or more key types was never created. I propose that if a key file just doesn't exist, that is an intentional act that should not result in a non-zero exit (this is of any concern to me because I have scripts for our users that depend on a zero exit of ssh-add when they run it in order to continue, and I can't tell what other people may have done which will break, and I just think backwards compatibilty is a good thing when it is easy). I have a patch which I will attach. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 12 06:43:28 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 06:43:28 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020311194328.692BAEA0A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From wknox at mitre.org 2002-03-12 06:43 ------- Created an attachment (id=38) Patch to fix described problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jmarin at isp.qnet.com.pe Mon Mar 11 20:51:56 2002 From: jmarin at isp.qnet.com.pe (Jose Luis Marin Perez) Date: Mon, 11 Mar 2002 14:51:56 +0500 Subject: Problem ssh: Permission denied Message-ID: <3C8C7E3B.163ED4E5@isp.qnet.com.pe> Dear Sirs, I have installed openssh-3.1p1 in a RedHat-7.1 server (By default openssh-2.5.2), I have not problem in the installation but when treatment to login to this server leaves the following message to me: root at 192.168.100.1's password: Permission denied (publickey,password,keyboard-interactive). I have seen the file sshd_config and if this qualified so that it can enter like root. I have initiated sshd in debug mode, and I as much enclose to this mail logs to you of the client as of the server. That I can do? Thanks Jose Luis -------------- next part -------------- [root at olidata /]# ssh -v -v -v 192.168.100.1 OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /usr/local/etc/ssh_config 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 192.168.100.1 [192.168.100.1] port 22. debug1: temporarily_use_uid: 0/0 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/0 (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/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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: 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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 123/256 debug1: bits set: 1559/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts The authenticity of host '192.168.100.1 (192.168.100.1)' can't be established. RSA key fingerprint is 9e:4b:75:ab:4a:c9:ca:5b:a1:2f:00:50:85:85:30:62. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.100.1' (RSA) to the list of known hosts. debug1: bits set: 1589/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 debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try privkey: /root/.ssh/identity debug3: no such identity: /root/.ssh/identity debug1: try privkey: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: try privkey: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password root at 192.168.100.1's password: debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive Permission denied, please try again. root at 192.168.100.1's password: debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive Permission denied, please try again. root at 192.168.100.1's password: debug1: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: no more auth methods to try Permission denied (publickey,password,keyboard-interactive). debug1: Calling cleanup 0x8061d70(0x0) -------------- next part -------------- debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.100.253 port 1332 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.1p1 [root at firewall /]# sshd -d -d -d debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.100.253 port 1333 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.1p1 debug1: list_hostkey_types: ssh-rsa,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-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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: 135/256 debug1: bits set: 1598/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1581/3191 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 root service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for root debug2: input_userauth_request: try method none Failed none for root from 192.168.100.253 port 1333 ssh2 debug1: userauth-request for user root 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=root devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for root from 192.168.100.253 port 1333 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Failed password for root from 192.168.100.253 port 1333 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 3 failures 3 debug2: input_userauth_request: try method password Failed password for root from 192.168.100.253 port 1333 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 4 failures 4 debug2: input_userauth_request: try method password Failed password for root from 192.168.100.253 port 1333 ssh2 Connection closed by 192.168.100.253 debug1: Calling cleanup 0x8065278(0x0) -------------- next part -------------- # $OpenBSD: sshd_config,v 1.48 2002/02/19 02:50:59 deraadt Exp $ # This is the sshd server system-wide configuration file. See sshd(8) # for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #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 #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 600 #PermitRootLogin yes #StrictModes yes #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # rhosts authentication should not be used #RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in /usr/local/etc/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options # KerberosAuthentication automatically enabled if keyfile exists #KerberosAuthentication yes #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # AFSTokenPassing automatically enabled if k_hasafs() is true #AFSTokenPassing yes # Kerberos TGT Passing only works with the AFS kaserver #KerberosTgtPassing no # Set this to 'yes' to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt yes #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #KeepAlive yes #UseLogin no #MaxStartups 10 # no default banner path #Banner /some/path #VerifyReverseMapping no # override default of no subsystems Subsystem sftp /usr/local/libexec/sftp-server From mouring at etoh.eviladmin.org Tue Mar 12 06:16:18 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 13:16:18 -0600 (CST) Subject: Problem ssh: Permission denied In-Reply-To: <3C8C7E3B.163ED4E5@isp.qnet.com.pe> Message-ID: did you define --with-pam when you did ./configure ? - Ben On Mon, 11 Mar 2002, Jose Luis Marin Perez wrote: > Dear Sirs, > > I have installed openssh-3.1p1 in a RedHat-7.1 server (By default > openssh-2.5.2), I have not problem in the installation but when > treatment to login to this server leaves the following message to me: > > root at 192.168.100.1's password: > Permission denied (publickey,password,keyboard-interactive). > > I have seen the file sshd_config and if this qualified so that it can > enter like root. > > I have initiated sshd in debug mode, and I as much enclose to this mail > logs to you of the client as of the server. > > That I can do? > > Thanks > Jose Luis > From reskusic at uiuc.edu Tue Mar 12 07:55:53 2002 From: reskusic at uiuc.edu (Raymond M. Reskusich) Date: Mon, 11 Mar 2002 14:55:53 -0600 Subject: best way to submit enhancement code Message-ID: <20020311145552.C27613@hume.cso.uiuc.edu> Greetings, I've got some feature enhancement code that I'd like to feed back into the main project, but to date I've had a hard time of it. I've written openssh at openssh.com and added a ticket to Bugzilla to no avail, and now I thought I'd pass it by this list. Mainly what I'm wondering is: 1. Where is the best place to submit patches for feature enhancement code to? Is there a specific type of diff that is preferred? 2. Does feature code need to be in the form of a patch to the base project, or will a patch to the portable tree suffice? Raymond M. Reskusich -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 236 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020311/f38521c7/attachment.bin From mjs at ams.org Tue Mar 12 07:58:23 2002 From: mjs at ams.org (Matt Studley) Date: Mon, 11 Mar 2002 15:58:23 -0500 (EST) Subject: scp and Solaris ACLs Message-ID: Has anyone had a problem with scp not retaining ACLs set on the original file under Solaris 8? When I have a file that has ACLs set and I use scp or rsync -e ssh to copy the file (local->local or local->remote) the ACLs are gone from the copied file(s). Is this a known issue or am I just missing something (a flag for instance) when performing the copy? Thanks in advance for your help. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" From wknox at mitre.org Tue Mar 12 08:03:19 2002 From: wknox at mitre.org (William R. Knox) Date: Mon, 11 Mar 2002 16:03:19 -0500 (EST) Subject: best way to submit enhancement code In-Reply-To: <20020311145552.C27613@hume.cso.uiuc.edu> Message-ID: On the page http://openssh.org/portable.html, there is a link to guidelines which you are asked to follow, and they also state there that unified diff is the preferred format. And the developers of the base code certainly do monitor this list, as it is not specific to the portable code, so patches to the portable code are certainly a good starting point. Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation On Mon, 11 Mar 2002, Raymond M. Reskusich wrote: > Date: Mon, 11 Mar 2002 14:55:53 -0600 > From: Raymond M. Reskusich > To: openssh-unix-dev at mindrot.org > Subject: best way to submit enhancement code > > Greetings, > > I've got some feature enhancement code that I'd like to feed back into > the main project, but to date I've had a hard time of it. I've > written openssh at openssh.com and added a ticket to Bugzilla to no > avail, and now I thought I'd pass it by this list. Mainly what I'm > wondering is: > > 1. Where is the best place to submit patches for feature enhancement > code to? Is there a specific type of diff that is preferred? > 2. Does feature code need to be in the form of a patch to the base > project, or will a patch to the portable tree suffice? > > Raymond M. Reskusich > > > From Darren.Moffat at eng.sun.com Tue Mar 12 08:08:56 2002 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Mon, 11 Mar 2002 13:08:56 -0800 (PST) Subject: scp and Solaris ACLs Message-ID: <200203112110.g2BLAdD0294177@jurassic.eng.sun.com> >Has anyone had a problem with scp not retaining ACLs set on the original >file under Solaris 8? When I have a file that has ACLs set and I use scp They won't be preserved because the code to do so doesn't exist. >or rsync -e ssh to copy the file (local->local or local->remote) the ACLs >are gone from the copied file(s). Is this a known issue or am I just >missing something (a flag for instance) when performing the copy? Thanks >in advance for your help. rcp in Solaris does preserve them but only because it uses a special version of rcp on both sides. This only makes sense if the source and destination are both Solaris. rcp in Solaris works this out by looking for the presence of /usr/lib/sunw,rcp as the command to run, if it exists (it is actually a link to /usr/bin/rcp) it knows that acls can be passed. A similar think would need to be done for scp. The scp in Solaris 9 does NOT contain this support. -- Darren J Moffat From abhi at acc.com Tue Mar 12 08:29:57 2002 From: abhi at acc.com (Abhijeet Thakare) Date: Mon, 11 Mar 2002 13:29:57 -0800 Subject: Use of Private Keys Message-ID: Hi All, We have public and private keys on the server and clients. The client uses its private key in public key authentication. I am not able to figure out where/how we are using the server's private key? Thanks, Abhijeet From bugzilla-daemon at mindrot.org Tue Mar 12 08:52:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 08:52:17 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020311215217.C5A2DEB24@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From wknox at mitre.org 2002-03-12 08:52 ------- OK, the patch I had didn't take into account the fact that if you specify a file on the command line, you would get no warning that the file didn't exist. Not a good idea. So, here is an updated patch that makes sure to only disregard default files, not ones you specify. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 12 08:53:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 08:53:21 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020311215321.52212EB30@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From wknox at mitre.org 2002-03-12 08:53 ------- Created an attachment (id=39) Updated patch to only disregard errors finding default keys ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From eparker at mindsec.com Tue Mar 12 08:57:19 2002 From: eparker at mindsec.com (Erik Parker) Date: Mon, 11 Mar 2002 15:57:19 -0600 (CST) Subject: Zlib security bug. In-Reply-To: <20020311215321.52212EB30@shitei.mindrot.org> Message-ID: Thought I'd pass this along, now that it's public: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zlib Advisory 2002-03-11 zlib Compression Library Corrupts malloc Data Structures via Double Free Original release date: March 11, 2002 Last revised: March 11, 2002 Source: This advisory is based on a CERT advisory written by Jeffrey P. Lanza http://www.kb.cert.org/vuls/id/368819 Systems Affected * Any software that is linked against zlib 1.1.3 or earlier * Any data compression library derived from zlib 1.1.3 or earlier Overview There is a vulnerability in the zlib shared library that may introduce vulnerabilities into any program that includes zlib. This vulnerability has been assigned a CVE name of CAN-2002-0059 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0059 I. Description There is a vulnerability in the decompression algorithm used by the popular zlib compression library. If an attacker is able to pass a specially-crafted block of invalid compressed data to a program that includes zlib, the program's attempt to decompress the crafted data can cause the zlib routines to corrupt the internal data structures maintained by malloc. The vulnerability results from a programming error that causes segments of dynamically allocated memory to be released more than once (aka. "double-freed"). Specifically, when inftrees.c:huft_build() encounters the crafted data, it returns an unexpected Z_MEM_ERROR to inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to infblock.c:inflate_blocks(), the inflate_blocks function tries to free an internal data structure a second time. Because this vulnerability interferes with the proper allocation and de-allocation of dynamic memory, it may be possible for an attacker to influence the operation of programs that include zlib. In most circumstances, this influence will be limited to denial of service or information leakage, but it is theoretically possible for an attacker to insert arbitrary code into a running program. This code would be executed with the permissions of the vulnerable program. II. Impact This vulnerability may introduce vulnerabilities into any program that includes the affected library. Depending upon how and where the zlib routines are called from the given program, the resulting vulnerability may have one or more of the following impacts: denial of service, information leakage, or execution of arbitrary code. III. Solution Upgrade your version of zlib The maintainers of zlib have released version 1.1.4 to address this vulnerability. Any software that is linked against or derived from an earlier version of zlib should be upgraded immediately. The latest version of zlib is available at http://www.zlib.org The md5 sums of the source archives are: abc405d0bdd3ee22782d7aa20e440f08 zlib-1.1.4.tar.gz ea16358be41384870acbdc372f9db152 zlib-1.1.4.tar.bz2 IV. Acknowledgments Thanks to Owen Taylor and Mark Cox of Redhat, Inc. for the reporting and research of this vulnerability. This document is available from http://www.gzip.org/zlib/advisory-2002-03-11.txt The public PGP key of zlib author Jean-loup Gailly is available from http://www.gzip.org/zlib/jloup.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8jSR02aJ9JQGWcacRAuDEAKCWdrRkWeJV9lYU5z8NN56s3m8eKACglR4m 42KDUGHuftBkwACTMCnZLEo= =3yLS -----END PGP SIGNATURE----- From brettporter at yahoo.com Tue Mar 12 09:13:39 2002 From: brettporter at yahoo.com (=?iso-8859-1?q?Brett=20Porter?=) Date: Tue, 12 Mar 2002 09:13:39 +1100 (EST) Subject: Writing a Java OpenSSH implementation In-Reply-To: <20020311145552.C27613@hume.cso.uiuc.edu> Message-ID: <20020311221339.39827.qmail@web9105.mail.yahoo.com> Hi, I'm currently writing an SSH library for Java that will have a BSD license. The main reason for this is so that it can be freely incorporated into Apache Ant, but also because there doesn't seem to be any free, comprehensive implementations. A couple of SSH1 implementations under GPL, and then Mindbright v1 (GPL) which has gone commercial since. The website is: http://quietcoffee.sourceforge.net (better names welcome :) Now, my intention is to roughly port OpenSSH as much as possible into Pure Java (obviously C to OO doesn't always go smoothly, but so far so good). This allows patches in OpenSSH to be ported quickly to Java within reason. I'm using JCE (which is now standard in the latest Sun JDK) to replace the OpenSSL calls. Is there someone I can speak to about various license/copyright issues? I'm planning on retaining the copyright and disclaimer of the C source files that the Java is based on, and adding my own to the top. Also, is this the appropriate place to ask dev. questions? I have a pretty reasonable knowledge of crypto algorithms, but am only starting out on the way SSH uses them and its internals. I don't want to be intrusive here, but I imagine the newsgroup/user list is probably not the right place. Finally, how would I get the project listed on the web page with the other limited list? I'd like to speed interest in the project as much as possible and hopefully grab a couple of extra Java developers :) Oh, and out of interest - I live in Sydney, Australia. So my mail should be fast since this mail server is in Melbourne :) Thanks in advance for your help! Cheers, Brett http://movies.yahoo.com.au - Yahoo! Movies - Vote for your nominees in our online Oscars pool. From dan at doxpara.com Wed Mar 13 09:23:35 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Mar 2002 14:23:35 -0800 Subject: scp and Solaris ACLs References: <200203112110.g2BLAdD0294177@jurassic.eng.sun.com> Message-ID: <004501c1ca14$8d1f9b20$1701000a@effugas> Interesting question: Can rcp be cajoled to use ssh as its transport? What happens if rsh is symlinked to ssh, but rcp is kept identical? --Dan ----- Original Message ----- From: "Darren Moffat" To: Cc: Sent: Monday, March 11, 2002 1:08 PM Subject: Re: scp and Solaris ACLs > >Has anyone had a problem with scp not retaining ACLs set on the original > >file under Solaris 8? When I have a file that has ACLs set and I use scp > > They won't be preserved because the code to do so doesn't exist. > > >or rsync -e ssh to copy the file (local->local or local->remote) the ACLs > >are gone from the copied file(s). Is this a known issue or am I just > >missing something (a flag for instance) when performing the copy? Thanks > >in advance for your help. > > rcp in Solaris does preserve them but only because it uses a special > version of rcp on both sides. > > This only makes sense if the source and destination are both Solaris. > rcp in Solaris works this out by looking for the presence of /usr/lib/sunw,rcp > as the command to run, if it exists (it is actually a link to /usr/bin/rcp) it > knows that acls can be passed. > > A similar think would need to be done for scp. The scp in Solaris 9 does > NOT contain this support. > > -- > Darren J Moffat > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From apronk at csi.co.nz Tue Mar 12 09:27:19 2002 From: apronk at csi.co.nz (Adrian Pronk) Date: Tue, 12 Mar 2002 11:27:19 +1300 Subject: scp completes but ssh subprocess in deadlock with sshd Message-ID: I've just built openssh 3.1 for my Redhat 5.1 system (running on a 486 DX-66) using the latest zlib and openssl libraries. Connecting to the machine with ssh seems to work fine (although it takes a while to initiate a connection). But when I transfer a file to the machine with scp, it seems to work fine and the scp completes, but an ssh sub-process remains behind on the client and an sshd sub-process remains behind on the host. When I strace them, the client is waiting on a socket and the host is waiting on three different fd's (under 5.1, its hard to tell what they are without making an effort :) ). I did not compile the system on the target machine (which is my firewall). My old development machine was a RH 5.1 box. I bought a new box recently and put RH 7.2 on it. I copied the development RH 5.1 file system on to it (including /dev). I then chroot'ed to that directory , mounted a new /proc and had my 5.1 development environment back. I compiled (make install) openSSL, zlib, openSSH on this and copied the likely output files to the target machine. I wouldn't think this development environment would break anything. Does anyone know off the top of their heads what the problem might be? If not, I'll get stuck in and have a look at the code and see if I can see anything. -- Adrian From dan at doxpara.com Wed Mar 13 09:43:47 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Mar 2002 14:43:47 -0800 Subject: Logging of client commands, possible? References: <20020311123448.F27398@sm2p1386swk.wdr.com> Message-ID: <005c01c1ca17$5fa286f0$1701000a@effugas> > Regardless, activity logging, other than TTY logging, doesn't belong in > sshd, and tty logging can be done externally to sshd, with varying > degrees of difficulty depending on what facilities the OS provides. The ugliness of doing this for each platforms begs for a SSHD solution. Interesting point: Disable tty-less modes, port forwarding, and direct command execution on a machine with no other way in but sshd (and no way back out) and indeed tty logging *does* capture the total set of available behaviors for that machine. This was actually done for a rather critical machine providing access There might be some exceptions, but you just can't deny that it's certainly imaginable that it's more useful to see a TTY log than the output of "/bin/sh -x" on an arbitrary shell script...that's kinda my feeling about the interactive logs. If nothing else, it's a critical adjunct to obtuse SAR logs. Hell, .bash_history is useful, and there ain't much that's easier to screw with. --Dan From Nicolas.Williams at ubsw.com Tue Mar 12 09:52:24 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 11 Mar 2002 17:52:24 -0500 Subject: Logging of client commands, possible? In-Reply-To: <005c01c1ca17$5fa286f0$1701000a@effugas>; from dan@doxpara.com on Tue, Mar 12, 2002 at 02:43:47PM -0800 References: <20020311123448.F27398@sm2p1386swk.wdr.com> <005c01c1ca17$5fa286f0$1701000a@effugas> Message-ID: <20020311175222.G27398@sm2p1386swk.wdr.com> On Tue, Mar 12, 2002 at 02:43:47PM -0800, Dan Kaminsky wrote: > > Regardless, activity logging, other than TTY logging, doesn't belong in > > sshd, and tty logging can be done externally to sshd, with varying > > degrees of difficulty depending on what facilities the OS provides. > > The ugliness of doing this for each platforms begs for a SSHD solution. I won't deny this :) Talk to the OpenSSH folk about it :) > Interesting point: Disable tty-less modes, port forwarding, and direct > command execution on a machine with no other way in but sshd (and no way > back out) and indeed tty logging *does* capture the total set of available > behaviors for that machine. This was actually done for a rather critical > machine providing access Well, have you read Cryptonomicon? I believe one can obfuscate one's tty session such that you might not really figure out what was done merely through a keystroke replay. > There might be some exceptions, but you just can't deny that it's certainly > imaginable that it's more useful to see a TTY log than the output of > "/bin/sh -x" on an arbitrary shell script...that's kinda my feeling about > the interactive logs. If nothing else, it's a critical adjunct to obtuse > SAR logs. I think a tty-log plus a history of exec*()s and open()s and creat()s and so on would be a rather complete record, yes. But ultimately a sufficiently nasty and savvy user can get 'round such logging (though the obfuscation necessary might itself raise enough red flags that you could catch such a user). > --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 Stephan.Larrison at developonline.com Tue Mar 12 10:20:37 2002 From: Stephan.Larrison at developonline.com (Stephan Larrison) Date: Mon, 11 Mar 2002 16:20:37 -0700 Subject: Blocking SCP Message-ID: I am running into a bit of a problem and I wanted to know if anyone out there has some experience that could be helpful. Here is the scenario. I have been asked to make changes to OpenSSH that will prevent a user from copying files on a server running SSH via SCP, but will still allow them to copy files from their local machine to the server via SCP. The first part of the problem was relatively simple. I have modified scp.c so that it can prevent remote copies, but still allow local copies. However, there is another piece to this that is still problematic. With the modified SCP, it is possible for a user to SSH into our servers, then SSH back to their own client, and use a local copy of SCP to copy files from our server. I am trying to prevent this from happening. What I am looking for is one of a few things 1) An existing solution to my problem 2) Help in developing a solution to my problem. I find that when I make any modification to the sshd.c listener program (even something as simple as a single printf) and move it into place, SSH Clients trying to connect to the server are first warned that a man-in-the-middle attack may be taking place, and when they try to override the warning, entering the password will no longer allow them to connect. If there is no existing solution to the problem at hand, I am looking for a way to make changes to the listener program so that I can prevent a user from using a local copy of SCP to move data. BTW, I am aware that you can move files back and forth with CAT piping through SSH, but I still need to block SCP. Thanks in advance for any help you can give me. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020311/68696eef/attachment.html From austin at coremetrics.com Tue Mar 12 12:07:14 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 11 Mar 2002 19:07:14 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <20020311060042.GF8045@multics.mit.edu> References: <20020311060042.GF8045@multics.mit.edu> Message-ID: <1015895234.17689.0.camel@UberGeek> With respect to the patches, if *anyone* knows, how is the configure supposed to happen? Just say --with-kerberos4? Is there another option? I can't seem to see it if there is. TIA. On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > Damien Miller wrote on Mon, 11 Mar 2002 > at 13:54:52 +1100 in > : > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > Just curious. There seems to be an awful lot in the source, but no > > > actual configure option. > > > > We are waiting on a compatibility patch so our auth-krb5.c will > compile > > against MIT krbV. > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > you can get Simon Wilkinson's patch from > "http://www.sxw.org.uk/computing/patches/openssh.html". > > --jhawk -- 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 From dan at doxpara.com Wed Mar 13 12:29:41 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Mar 2002 17:29:41 -0800 Subject: Logging of client commands, possible? References: <20020311123448.F27398@sm2p1386swk.wdr.com> <005c01c1ca17$5fa286f0$1701000a@effugas> <20020311175222.G27398@sm2p1386swk.wdr.com> Message-ID: <007a01c1ca2e$8c3dc7d0$1701000a@effugas> > I believe one can obfuscate one's tty session such that you might not > really figure out what was done merely through a keystroke replay. Ah, but if the only incoming channel of de-obfuscation code is itself tapped, it's actually provably impossible to successfully obfuscate the code. The best case I can think of involves encrypting to a naturally cycled file, uploading the encrypted code, decrypting against the file already there, and letting the file itself expire...and even that has problems (like it's pretty damn noisy *laughs*). Believe me, I'm quite evil enough to determine breaks in the system, but hell, it can't *hurt* to have TTY logs on production machines, especially if they're sent off-host in realtime. > > There might be some exceptions, but you just can't deny that it's certainly > > imaginable that it's more useful to see a TTY log than the output of > > "/bin/sh -x" on an arbitrary shell script...that's kinda my feeling about > > the interactive logs. If nothing else, it's a critical adjunct to obtuse > > SAR logs. > > I think a tty-log plus a history of exec*()s and open()s and creat()s > and so on would be a rather complete record, yes. But ultimately a > sufficiently nasty and savvy user can get 'round such logging (though the > obfuscation necessary might itself raise enough red flags that you could > catch such a user). As I've been saying, often the "enemy" is lack of documentation and accountability, not an active attacker. Production machines need histories of who did what when. exec() is an incomplete and near-useless history -- would you rather have the output of ./configure or all the exec()'s that it contained? Different problems, thus my claim of orthogonality to the security -- but NOT the functionality aspect of SSH. --Dan From stevesk at pobox.com Tue Mar 12 13:04:50 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 11 Mar 2002 18:04:50 -0800 (PST) Subject: sys/queue.h Message-ID: removes HAVE_BOGUS_SYS_QUEUE_H and always use our queue.h. ok? Index: acconfig.h =================================================================== RCS file: /var/cvs/openssh/acconfig.h,v retrieving revision 1.122 diff -u -r1.122 acconfig.h --- acconfig.h 26 Feb 2002 16:40:49 -0000 1.122 +++ acconfig.h 12 Mar 2002 02:11:39 -0000 @@ -14,7 +14,6 @@ /* SCO workaround */ #undef BROKEN_SYS_TERMIO_H -#undef HAVE_BOGUS_SYS_QUEUE_H /* Define if you have SCO protected password database */ #undef HAVE_SCO_PROTECTED_PW Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.25 diff -u -r1.25 configure.ac --- configure.ac 8 Mar 2002 03:50:58 -0000 1.25 +++ configure.ac 12 Mar 2002 02:11:54 -0000 @@ -63,7 +63,6 @@ AC_DEFINE(BROKEN_GETADDRINFO) dnl AIX handles lastlog as part of its login message AC_DEFINE(DISABLE_LASTLOG) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) ;; *-*-cygwin*) LIBS="$LIBS /usr/lib/textmode.o" @@ -123,7 +122,6 @@ check_for_libcrypt_later=1 AC_DEFINE(DONT_TRY_OTHER_AF) AC_DEFINE(PAM_TTY_KLUDGE) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) inet6_default_4in6=yes ;; mips-sony-bsd|mips-sony-newsos4) @@ -175,7 +173,6 @@ CPPFLAGS="$CPPFLAGS -DSUNOS4" AC_CHECK_FUNCS(getpwanam) AC_DEFINE(PAM_SUN_CODEBASE) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) conf_utmp_location=/etc/utmp conf_wtmp_location=/var/adm/wtmp conf_lastlog_location=/var/adm/lastlog @@ -185,7 +182,6 @@ CPPFLAGS="$CPPFLAGS -I/usr/local/include" LDFLAGS="$LDFLAGS -L/usr/local/lib" LIBS="$LIBS -lc89" - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_DEFINE(USE_PIPES) ;; *-sni-sysv*) @@ -195,7 +191,6 @@ IPADDR_IN_DISPLAY=yes AC_DEFINE(USE_PIPES) AC_DEFINE(IP_TOS_IS_BROKEN) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) # /usr/ucblib/libucb.a no longer needed on ReliantUNIX # Attention: always take care to bind libsocket and libnsl before libc, # otherwise you will find lots of "SIOCGPGRP errno 22" on syslog @@ -227,7 +222,6 @@ AC_DEFINE(USE_PIPES) AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_DEFINE(BROKEN_SAVED_UIDS) AC_CHECK_FUNCS(getluid setluid) MANTYPE=man @@ -242,7 +236,6 @@ AC_DEFINE(USE_PIPES) AC_DEFINE(HAVE_SCO_PROTECTED_PW) AC_DEFINE(DISABLE_SHADOW) - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) AC_CHECK_FUNCS(getluid setluid) MANTYPE=man ;; @@ -327,7 +320,7 @@ netinet/in_systm.h paths.h poll.h pty.h \ rpc/types.h security/pam_appl.h shadow.h stddef.h stdint.h \ strings.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h \ - sys/poll.h sys/queue.h sys/select.h sys/stat.h \ + sys/poll.h sys/select.h sys/stat.h \ sys/stropts.h sys/sysmacros.h sys/time.h \ sys/ttcompat.h sys/un.h time.h ttyent.h usersec.h \ util.h utime.h utmp.h utmpx.h) Index: sftp-client.c =================================================================== RCS file: /var/cvs/openssh/sftp-client.c,v retrieving revision 1.24 diff -u -r1.24 sftp-client.c --- sftp-client.c 26 Feb 2002 18:02:44 -0000 1.24 +++ sftp-client.c 12 Mar 2002 02:12:01 -0000 @@ -30,11 +30,7 @@ #include "includes.h" RCSID("$OpenBSD: sftp-client.c,v 1.24 2002/02/24 16:57:19 markus Exp $"); -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) -#include -#else #include "openbsd-compat/fake-queue.h" -#endif #include "buffer.h" #include "bufaux.h" Index: ssh-agent.c =================================================================== RCS file: /var/cvs/openssh/ssh-agent.c,v retrieving revision 1.85 diff -u -r1.85 ssh-agent.c --- ssh-agent.c 5 Mar 2002 18:59:45 -0000 1.85 +++ ssh-agent.c 12 Mar 2002 02:12:08 -0000 @@ -34,13 +34,8 @@ */ #include "includes.h" -RCSID("$OpenBSD: ssh-agent.c,v 1.82 2002/03/04 17:27:39 stevesk Exp $"); - -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) -#include -#else #include "openbsd-compat/fake-queue.h" -#endif +RCSID("$OpenBSD: ssh-agent.c,v 1.82 2002/03/04 17:27:39 stevesk Exp $"); #include #include Index: ssh-keyscan.c =================================================================== RCS file: /var/cvs/openssh/ssh-keyscan.c,v retrieving revision 1.42 diff -u -r1.42 ssh-keyscan.c --- ssh-keyscan.c 5 Mar 2002 01:54:53 -0000 1.42 +++ ssh-keyscan.c 12 Mar 2002 02:12:11 -0000 @@ -9,11 +9,7 @@ #include "includes.h" RCSID("$OpenBSD: ssh-keyscan.c,v 1.35 2002/03/04 18:30:23 stevesk Exp $"); -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) -#include -#else #include "openbsd-compat/fake-queue.h" -#endif #include #include From mouring at etoh.eviladmin.org Tue Mar 12 12:30:46 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 19:30:46 -0600 (CST) Subject: sys/queue.h In-Reply-To: Message-ID: It is too late by time it tries to load it in the individual C files for BSD/OS. It has to be loaded before #include in defines.h or else 4.2 fails. - Ben On Mon, 11 Mar 2002, Kevin Steves wrote: > removes HAVE_BOGUS_SYS_QUEUE_H and always use our queue.h. ok? > > Index: acconfig.h > =================================================================== > RCS file: /var/cvs/openssh/acconfig.h,v > retrieving revision 1.122 > diff -u -r1.122 acconfig.h > --- acconfig.h 26 Feb 2002 16:40:49 -0000 1.122 > +++ acconfig.h 12 Mar 2002 02:11:39 -0000 > @@ -14,7 +14,6 @@ > > /* SCO workaround */ > #undef BROKEN_SYS_TERMIO_H > -#undef HAVE_BOGUS_SYS_QUEUE_H > > /* Define if you have SCO protected password database */ > #undef HAVE_SCO_PROTECTED_PW > Index: configure.ac > =================================================================== > RCS file: /var/cvs/openssh/configure.ac,v > retrieving revision 1.25 > diff -u -r1.25 configure.ac > --- configure.ac 8 Mar 2002 03:50:58 -0000 1.25 > +++ configure.ac 12 Mar 2002 02:11:54 -0000 > @@ -63,7 +63,6 @@ > AC_DEFINE(BROKEN_GETADDRINFO) > dnl AIX handles lastlog as part of its login message > AC_DEFINE(DISABLE_LASTLOG) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > ;; > *-*-cygwin*) > LIBS="$LIBS /usr/lib/textmode.o" > @@ -123,7 +122,6 @@ > check_for_libcrypt_later=1 > AC_DEFINE(DONT_TRY_OTHER_AF) > AC_DEFINE(PAM_TTY_KLUDGE) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > inet6_default_4in6=yes > ;; > mips-sony-bsd|mips-sony-newsos4) > @@ -175,7 +173,6 @@ > CPPFLAGS="$CPPFLAGS -DSUNOS4" > AC_CHECK_FUNCS(getpwanam) > AC_DEFINE(PAM_SUN_CODEBASE) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > conf_utmp_location=/etc/utmp > conf_wtmp_location=/var/adm/wtmp > conf_lastlog_location=/var/adm/lastlog > @@ -185,7 +182,6 @@ > CPPFLAGS="$CPPFLAGS -I/usr/local/include" > LDFLAGS="$LDFLAGS -L/usr/local/lib" > LIBS="$LIBS -lc89" > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > AC_DEFINE(USE_PIPES) > ;; > *-sni-sysv*) > @@ -195,7 +191,6 @@ > IPADDR_IN_DISPLAY=yes > AC_DEFINE(USE_PIPES) > AC_DEFINE(IP_TOS_IS_BROKEN) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > # /usr/ucblib/libucb.a no longer needed on ReliantUNIX > # Attention: always take care to bind libsocket and libnsl before libc, > # otherwise you will find lots of "SIOCGPGRP errno 22" on syslog > @@ -227,7 +222,6 @@ > AC_DEFINE(USE_PIPES) > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > AC_DEFINE(BROKEN_SAVED_UIDS) > AC_CHECK_FUNCS(getluid setluid) > MANTYPE=man > @@ -242,7 +236,6 @@ > AC_DEFINE(USE_PIPES) > AC_DEFINE(HAVE_SCO_PROTECTED_PW) > AC_DEFINE(DISABLE_SHADOW) > - AC_DEFINE(HAVE_BOGUS_SYS_QUEUE_H) > AC_CHECK_FUNCS(getluid setluid) > MANTYPE=man > ;; > @@ -327,7 +320,7 @@ > netinet/in_systm.h paths.h poll.h pty.h \ > rpc/types.h security/pam_appl.h shadow.h stddef.h stdint.h \ > strings.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h \ > - sys/poll.h sys/queue.h sys/select.h sys/stat.h \ > + sys/poll.h sys/select.h sys/stat.h \ > sys/stropts.h sys/sysmacros.h sys/time.h \ > sys/ttcompat.h sys/un.h time.h ttyent.h usersec.h \ > util.h utime.h utmp.h utmpx.h) > Index: sftp-client.c > =================================================================== > RCS file: /var/cvs/openssh/sftp-client.c,v > retrieving revision 1.24 > diff -u -r1.24 sftp-client.c > --- sftp-client.c 26 Feb 2002 18:02:44 -0000 1.24 > +++ sftp-client.c 12 Mar 2002 02:12:01 -0000 > @@ -30,11 +30,7 @@ > #include "includes.h" > RCSID("$OpenBSD: sftp-client.c,v 1.24 2002/02/24 16:57:19 markus Exp $"); > > -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) > -#include > -#else > #include "openbsd-compat/fake-queue.h" > -#endif > > #include "buffer.h" > #include "bufaux.h" > Index: ssh-agent.c > =================================================================== > RCS file: /var/cvs/openssh/ssh-agent.c,v > retrieving revision 1.85 > diff -u -r1.85 ssh-agent.c > --- ssh-agent.c 5 Mar 2002 18:59:45 -0000 1.85 > +++ ssh-agent.c 12 Mar 2002 02:12:08 -0000 > @@ -34,13 +34,8 @@ > */ > > #include "includes.h" > -RCSID("$OpenBSD: ssh-agent.c,v 1.82 2002/03/04 17:27:39 stevesk Exp $"); > - > -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) > -#include > -#else > #include "openbsd-compat/fake-queue.h" > -#endif > +RCSID("$OpenBSD: ssh-agent.c,v 1.82 2002/03/04 17:27:39 stevesk Exp $"); > > #include > #include > Index: ssh-keyscan.c > =================================================================== > RCS file: /var/cvs/openssh/ssh-keyscan.c,v > retrieving revision 1.42 > diff -u -r1.42 ssh-keyscan.c > --- ssh-keyscan.c 5 Mar 2002 01:54:53 -0000 1.42 > +++ ssh-keyscan.c 12 Mar 2002 02:12:11 -0000 > @@ -9,11 +9,7 @@ > #include "includes.h" > RCSID("$OpenBSD: ssh-keyscan.c,v 1.35 2002/03/04 18:30:23 stevesk Exp $"); > > -#if defined(HAVE_SYS_QUEUE_H) && !defined(HAVE_BOGUS_SYS_QUEUE_H) > -#include > -#else > #include "openbsd-compat/fake-queue.h" > -#endif > #include > > #include > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From stevesk at pobox.com Tue Mar 12 13:24:14 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 11 Mar 2002 18:24:14 -0800 (PST) Subject: sys/queue.h In-Reply-To: Message-ID: On Mon, 11 Mar 2002, Ben Lindstrom wrote: :It is too late by time it tries to load it in the individual C files :for BSD/OS. It has to be loaded before #include in :defines.h or else 4.2 fails. hmm. is this a symbol clash or does that include sys/queue.h? if the latter, is their queue.h #ifdef protected? i'm thinking of: defines.h: #define _SYS_QUEUE_H_ #include /* For IPv6 macros */ #undef _SYS_QUEUE_H_ From mouring at etoh.eviladmin.org Tue Mar 12 12:55:40 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 19:55:40 -0600 (CST) Subject: sys/queue.h In-Reply-To: Message-ID: On Mon, 11 Mar 2002, Kevin Steves wrote: > On Mon, 11 Mar 2002, Ben Lindstrom wrote: > :It is too late by time it tries to load it in the individual C files > :for BSD/OS. It has to be loaded before #include in > :defines.h or else 4.2 fails. > > hmm. is this a symbol clash or does that include sys/queue.h? > > if the latter, is their queue.h #ifdef protected? i'm thinking of: > > defines.h: > > #define _SYS_QUEUE_H_ > #include /* For IPv6 macros */ > #undef _SYS_QUEUE_H_ > > From jheiden2 at pop3.utoledo.edu Tue Mar 12 13:39:16 2002 From: jheiden2 at pop3.utoledo.edu (John Heiden) Date: Mon, 11 Mar 2002 21:39:16 -0500 Subject: Can't get 3.1p1 to compile under Solaris 8 Message-ID: <3C8D6A53.6C028145@pop3.utoledo.edu> OK, I feel like an idiot, but I can't get 3.1p1 to compile under Solaris 8. Older versions I've gotten set up, but can't with this latest one. I have followed both the general directions and the directions in contrib/solaris, and neither one works. Since I have Solaris, here's the output from the directions in contrib/solaris... ./configure --with-pam ====================================================== configure:4318: checking sys/ttcompat.h usability configure:4327: gcc -c -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/l ocal/include conftest.c >&5 In file included from configure:4356: /usr/include/sys/ttcompat.h:48: parse error before "mblk_t" /usr/include/sys/ttcompat.h:60: parse error before '}' token /usr/include/sys/ttcompat.h:51: storage size of `t_new_sgttyb' isn't known /usr/include/sys/ttcompat.h:52: storage size of `t_new_tchars' isn't known /usr/include/sys/ttcompat.h:53: storage size of `t_new_ltchars' isn't known configure:4330: $? = 1 configure: failed program was: #line 4321 "configure" ======================================================= cd contrib/solaris; ./buildpkg.sh ===================================================== Faking root install... ./buildpkg.sh: make: not found Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from ====================================================== Any help you can give would be *GREATLY* appreciated! John Heiden Network Engineer The University of Toledo Toledo, OH 43606 jheiden2 at pop3.utoledo.edu From charles.yuan at cps.com.au Tue Mar 12 13:42:19 2002 From: charles.yuan at cps.com.au (Charles Yuan) Date: Tue, 12 Mar 2002 13:42:19 +1100 Subject: Error with building openssh-3.1p1 package Message-ID: <000801c1c96f$87694320$940110ac@cyuan> Hi Ben, We experienced a problem with building openssh-3.1p1 package. Here are the steps and error messages: ./configure (looks OK) make (OK) cd contrib/solaris; ./buildpkg.sh (Error): Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from Could you help me to have a look the reasons? Kind regards, Dr. Charles Yuan Senior Unix Systems Administrator CPS Systems Pty Ltd charles.yuan at cps.com.au From mouring at etoh.eviladmin.org Tue Mar 12 13:11:49 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 20:11:49 -0600 (CST) Subject: Error with building openssh-3.1p1 package In-Reply-To: <000801c1c96f$87694320$940110ac@cyuan> Message-ID: Where it gets the version number in buildpkg.sh change it from -1 to -2. There is a revised package script by Tim to expand it to all srv4 systems. It may or may not be in the 3.1p2 release (being done to handle compiling issues). - Ben On Tue, 12 Mar 2002, Charles Yuan wrote: > Hi Ben, > > We experienced a problem with building openssh-3.1p1 package. Here are the > steps and error messages: > > ./configure (looks OK) > make (OK) > cd contrib/solaris; ./buildpkg.sh (Error): > > Building pkginfo file... > Building prototype file... > Building package.. > ## Building pkgmap from package prototype file. > ## Processing pkginfo file. > pkgmk: ERROR: parameter cannot be null > ## Packaging was not successful. > pkgtrans: ERROR: unable to complete package transfer > - no packages were selected from > olaris> > > Could you help me to have a look the reasons? > > Kind regards, > > Dr. Charles Yuan > Senior Unix Systems Administrator > CPS Systems Pty Ltd > charles.yuan at cps.com.au > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From morty at frakir.org Tue Mar 12 14:04:07 2002 From: morty at frakir.org (Mordechai T. Abzug) Date: Mon, 11 Mar 2002 22:04:07 -0500 Subject: patch for password expiration under Solaris? Message-ID: <20020311220407.A3430@red-sonja.frakir.org> I'm looking to move some Solaris 2.6 and 7 machines to openssh. Showstopper bug: openssh (up to 3.1p1) doesn't seem to correctly implement expired passwords. Looking back through the archive, it looks like Dave Dykstra submitted a patch for this problem relative to an older version of openssh at least as early as last August: http://msgs.securepoint.com/cgi-bin/get/openssh-unix-dev-0108/77.html The patch seems to work on one of my test machines, after some minimal finagling. Is this patch the standard solution to this problem? Thanks! - Morty From maxy at rt.mipt.ru Tue Mar 12 14:34:30 2002 From: maxy at rt.mipt.ru (Maxim Ryabenko) Date: Tue, 12 Mar 2002 06:34:30 +0300 Subject: problem with environment detecting Message-ID: <200203120334.g2C3Yhgj022283@frtk-campus-gw.mipt.ru> Hello! I want to detect some environment on a remote host (in C program, getenv()), but it is failed. Here is a little program which I try to run on a remote host with command: "#ssh myhost myecho" /* myecho */ #include main (){ char *dir; if ((dir = getenv("MYDIR")) != NULL) printf ("environment is %s\n",dir); else printf ("enviroment is not specified.\n"); } it returns "enviroment is not specified.", although the environment MYDIR is specified in /etc/profile on a remote host. In this way I can detect only $PATH, $USER, $HOSTNAME, but not MYDIR :( On the other hand "./ssh myhost echo $MYDIR" works correctly What is wrong? Thank you! Maxim From mouring at etoh.eviladmin.org Tue Mar 12 13:57:40 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 20:57:40 -0600 (CST) Subject: problem with environment detecting In-Reply-To: <200203120334.g2C3Yhgj022283@frtk-campus-gw.mipt.ru> Message-ID: On Tue, 12 Mar 2002, Maxim Ryabenko wrote: > Hello! > > I want to detect some environment on a remote host (in C program, getenv()), > but it is failed. Here is a little program which I try to run on a remote > host with command: "#ssh myhost myecho" > > /* myecho */ > #include > main (){ > char *dir; > if ((dir = getenv("MYDIR")) != NULL) > printf ("environment is %s\n",dir); > else > printf ("enviroment is not specified.\n"); > } > > it returns "enviroment is not specified.", although the environment MYDIR is > specified in /etc/profile on a remote host. > In this way I can detect only $PATH, $USER, $HOSTNAME, but not MYDIR :( > > On the other hand "./ssh myhost echo $MYDIR" works correctly > First off do: ./ssh myhost echo \$MYDIR All $xx and * are resolved BEFORE commands run.. the escape ensure it is not. Second /etc/profile is not read by non-tty sessions. try: ssh -t myhost echo \$MYDIR to see if you get better results. - Ben From fcusack at fcusack.com Tue Mar 12 14:49:01 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 11 Mar 2002 19:49:01 -0800 Subject: sys/queue.h In-Reply-To: ; from stevesk@pobox.com on Mon, Mar 11, 2002 at 06:24:14PM -0800 References: Message-ID: <20020311194900.K27876@google.com> On Mon, Mar 11, 2002 at 06:24:14PM -0800, Kevin Steves wrote: > On Mon, 11 Mar 2002, Ben Lindstrom wrote: > :It is too late by time it tries to load it in the individual C files > :for BSD/OS. It has to be loaded before #include in > :defines.h or else 4.2 fails. > > hmm. is this a symbol clash or does that include sys/queue.h? > > if the latter, is their queue.h #ifdef protected? i'm thinking of: > > defines.h: > > #define _SYS_QUEUE_H_ > #include /* For IPv6 macros */ > #undef _SYS_QUEUE_H_ That seems bad; if netinet/in.h includes sys/queue.h it's because it needs definitions there. Instead, just include openssh's sys/queue.h before netinet/in.h, and #define the appropriate macro. /fc From stevesk at pobox.com Tue Mar 12 15:13:09 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 11 Mar 2002 20:13:09 -0800 (PST) Subject: sys/queue.h In-Reply-To: <20020311194900.K27876@google.com> Message-ID: On Mon, 11 Mar 2002, Frank Cusack wrote: :> hmm. is this a symbol clash or does that include sys/queue.h? :> :> if the latter, is their queue.h #ifdef protected? i'm thinking of: :> :> defines.h: :> :> #define _SYS_QUEUE_H_ :> #include /* For IPv6 macros */ :> #undef _SYS_QUEUE_H_ : :That seems bad; if netinet/in.h includes sys/queue.h it's because it :needs definitions there. maybe, or perhaps it's a defect. someone familiar with BSDOS needs to chime in here. :Instead, just include openssh's sys/queue.h :before netinet/in.h, and #define the appropriate macro. i'm not sure, as i may make diff audits more tedious. have you ever diff'd all of native against portable? welcome to my world. From maxy at rt.mipt.ru Tue Mar 12 15:23:42 2002 From: maxy at rt.mipt.ru (Maxim Ryabenko) Date: Tue, 12 Mar 2002 07:23:42 +0300 Subject: problem with environment detecting In-Reply-To: <3C8D7B07.57D724C0@boeing.com> References: <200203120334.g2C3Yhgj022283@frtk-campus-gw.mipt.ru> <3C8D7B07.57D724C0@boeing.com> Message-ID: <200203120423.g2C4Ntgj031306@frtk-campus-gw.mipt.ru> > The remote /etc/profile is not executed when you run a remote command > using ssh. Your remote echo appears to do what you want because > variables get expanded inside double quotes. Try it like this: > > ssh myhost 'echo $MYDIR' > > If you want the remote profile to be executed, you have to do something > like this: > > ssh myhost '. /etc/profile; echo $MYDIR' > > Happy computing! > > Paul Allen Thank you, Paul and Ben. this is what I want, ssh myhost '. /etc/profile; echo $MYDIR' It works good, thank you. Problem was not in standard command "echo". It was in my program (see prev. message). This one works ....... if ((dir = getenv("MYDIR")) != NULL) ....... But this not ....... if ((dir = getenv("PATH")) != NULL) ....... It seems that there is another place (not /etc/profile), where environments PATH etc. are stored. But where? Can I put my environment there and do not run . /etc/profile like this: ssh myhost '. /etc/profile; ............' Thank you so much! p.s. sorry, my English is worst. Maxim From mouring at etoh.eviladmin.org Tue Mar 12 14:47:54 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Mar 2002 21:47:54 -0600 (CST) Subject: sys/queue.h In-Reply-To: Message-ID: On Mon, 11 Mar 2002, Kevin Steves wrote: > On Mon, 11 Mar 2002, Frank Cusack wrote: > :> hmm. is this a symbol clash or does that include sys/queue.h? > :> > :> if the latter, is their queue.h #ifdef protected? i'm thinking of: > :> > :> defines.h: > :> > :> #define _SYS_QUEUE_H_ > :> #include /* For IPv6 macros */ > :> #undef _SYS_QUEUE_H_ > : > :That seems bad; if netinet/in.h includes sys/queue.h it's because it > :needs definitions there. > > maybe, or perhaps it's a defect. someone familiar with BSDOS needs to > chime in here. > > :Instead, just include openssh's sys/queue.h > :before netinet/in.h, and #define the appropriate macro. > > i'm not sure, as i may make diff audits more tedious. have you ever diff'd > all of native against portable? welcome to my world. > > I can agree with you there.. I've done a few.. Not top on my list of fun ways to spend an evening. =) But also a good time to look at the code and go, "is there a better way of doing this without all this hacking". - Ben From bob at proulx.com Tue Mar 12 16:40:24 2002 From: bob at proulx.com (Bob Proulx) Date: Mon, 11 Mar 2002 22:40:24 -0700 Subject: 3.1p1 breaks X11 forwarding Message-ID: <15501.38088.248386.30275@torment.proulx.com> I just recently updated to 3.1p1 and it seems that some X11 forwarding connections are broken while others work. For instance xterm always works fine. But Synchronize (group calendar program) always crashes with the following error. This happens even if I disable access control using 'xhost +'. X11 connection rejected because of wrong authentication. Secondly, in going back to 3.0.2p1 to try to work around this problem I was able to crash ssh with the following error. I window killed a forwarded xterm which was running a separate X11 program also forwarded. The child tunneled X11 program appeared to hang and I killed the application. This crashed the underlying ssh with this message. Received disconnect from 216.17.153.58: 2: Received ieof for nonexistent channel 8. Sorry I don't have solutions. I just thought I would report the problems. Thanks for carying the torch with this wonderful useful program. Bob From kevin at atomicgears.com Tue Mar 12 17:11:10 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Mon, 11 Mar 2002 22:11:10 -0800 (PST) Subject: 3.1p1 breaks X11 forwarding In-Reply-To: <15501.38088.248386.30275@torment.proulx.com> Message-ID: On Mon, 11 Mar 2002, Bob Proulx wrote: :I just recently updated to 3.1p1 and it seems that some X11 forwarding :connections are broken while others work. For instance xterm always :works fine. But Synchronize (group calendar program) always crashes :with the following error. This happens even if I disable access :control using 'xhost +'. : : X11 connection rejected because of wrong authentication. what OS? X11UseLocalhost Specifies whether sshd should bind the X11 forwarding server to the loopback address or to the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to ``localhost''. This prevents remote hosts from connecting to the fake display. However, some older X11 clients may not function with this configuration. X11UseLocalhost may be set to ``no'' to specify that the forwarding server should be bound to the wild- card address. The argument must be ``yes'' or ``no''. The de- fault is ``yes''. also: http://bugzilla.mindrot.org/show_bug.cgi?id=150 :Secondly, in going back to 3.0.2p1 to try to work around this problem :I was able to crash ssh with the following error. I window killed a :forwarded xterm which was running a separate X11 program also :forwarded. The child tunneled X11 program appeared to hang and I :killed the application. This crashed the underlying ssh with this :message. : :Received disconnect from 216.17.153.58: 2: Received ieof for nonexistent channel 8. can you submit that (plus exact how-to-dup details) to http://bugzilla.mindrot.org/ From fcusack at fcusack.com Tue Mar 12 18:25:58 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 11 Mar 2002 23:25:58 -0800 Subject: sys/queue.h In-Reply-To: ; from stevesk@pobox.com on Mon, Mar 11, 2002 at 08:13:09PM -0800 References: <20020311194900.K27876@google.com> Message-ID: <20020311232558.H30616@google.com> On Mon, Mar 11, 2002 at 08:13:09PM -0800, Kevin Steves wrote: > i'm not sure, as i may make diff audits more tedious. have you ever diff'd > all of native against portable? welcome to my world. Well, I would argue that the two should be one and the same. /fc From bob at proulx.com Tue Mar 12 18:52:18 2002 From: bob at proulx.com (Bob Proulx) Date: Tue, 12 Mar 2002 00:52:18 -0700 Subject: 3.1p1 breaks X11 forwarding In-Reply-To: References: <15501.38088.248386.30275@torment.proulx.com> Message-ID: <15501.46002.146859.423043@torment.proulx.com> > : X11 connection rejected because of wrong authentication. > > what OS? Homebrew GNU/Linux of my own compilation, Redhat 7.1 with my own compile of ssh, HP-UX 10.20, HP-UX 11.0, HP-UX 11.11, I got caried away and updated everything before I found the problem. As you can see I don't think the OS is significant here. But in this particular case I am using HP-UX as the sshd server. [As a trip down memory lane one of the other apps that always crashes is piglet. But synchronize also exhibits the problem.] > X11UseLocalhost I don't think that is the problem. The xterm comes through fine back to back with other failing commands. I am $DISPLAYing onto the local machine. So localhost at 127.0.0.1:12.0 should be fine. Although I have previously been seeing the local_ip_address:12.0. ssh -X remotehost xterm & # works synchronize & # fails with wrong authentication message piglet & # fails with wrong authentication message xterm & # works xclock & # fails xterm & # works This happens when using either Protocol 1 or Protocol 2. As you can see I can run commands back to back in the same window and see one work and one fail. > also: > http://bugzilla.mindrot.org/show_bug.cgi?id=150 That is the same as the problem I am describing. > echo $DISPLAY > localhost:13.0 > What I exptected is: > rodenss at ginkgo:~$ echo $DISPLAY > 10.100.53.39:13.0 This has a similar message and similar DISPLAY behavior and the problem is almost certainly related. > /usr/bin/X11/xterm uses R5 libs. I am using color xterm-159 compiled by me moons ago and it has been in solid use since then. I think I compiled it using the R6 libs. The shipped xterm is ancient. It is probably pertinent that I am using a recently compiled xterm using later libraries than the xterm shipped with hpux. I am using the shipped (or patched) X11 libs on a 10.20 machine to compile the xterm as I did not compile the X11 libs. Other stock applications are causing the crash but this one does not. > try /usr/contrib/bin/X11/xterm That one has a broken resize, no sigwinch capability, and I remove it with prejudice whenever I install a new system so that it does not get invoked by accident. It is a very frustrating version. > :Secondly, in going back to 3.0.2p1 to try to work around this problem > :I was able to crash ssh with the following error. I window killed a > :forwarded xterm which was running a separate X11 program also > :forwarded. The child tunneled X11 program appeared to hang and I > :killed the application. This crashed the underlying ssh with this > :message. > : > :Received disconnect from 216.17.153.58: 2: Received ieof for nonexistent channel 8. > > can you submit that (plus exact how-to-dup details) to > http://bugzilla.mindrot.org/ I don't think I can generate a recipe for someone else to recreate this unless they have synchronize handy which I don't expect. http://www.crosswind.com/sitemap.htm#sync. The details are that I am running the X11 client on my GNU/Linux desktop. ssh-3.0.2p1 -X hpux to sshd-3.1p1. There start up 'xterm -e synchronize'. The xterm comes up but the synchronize window never does. Running tcpdump in another window shows no network activity. After ten minutes kill the xterm with a window manager window pulldown kill (FVWM2). The original ssh -X connection then dies with that message. When I try 'xterm -e xclock' I never get the xclock window and killing xterm does not generate a death of the ssh client. Bob From gert at greenie.muc.de Tue Mar 12 19:48:02 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Mar 2002 09:48:02 +0100 Subject: sys/queue.h In-Reply-To: ; from Ben Lindstrom on Mon, Mar 11, 2002 at 09:47:54PM -0600 References: Message-ID: <20020312094802.A13427@greenie.muc.de> Hi, On Mon, Mar 11, 2002 at 09:47:54PM -0600, Ben Lindstrom wrote: > But also a good time to look at the code and go, "is there a better > way of doing this without all this hacking". What about having *two* openbsd-compat/fake-queue.h files? One that has the basic things (TAILQ_FIRST, TAILQ_END, TAILQ_NEXT, ...) and the second one has only only TAILQ_FOREACH(). I see three kinds of operating systems here: - full , with TAILQ_FOREACH (OpenBSD) -> include system file - working , but lacking TAILQ_FOREACH (AIX, BSDI) -> include system file plus "openbsd-compat/fake-tailq.h" - no at all, or an unusable one. (SCO3 - has queue.h, but has no TAILQ_* macros) -> include "openbsd-compat/fake-queue.h" plus "fake-tailq.h" so the test "do we need to include openbsd-compat/fake-queue.h or not" is a bit too binary for this threefold problem... 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 gert at greenie.muc.de Tue Mar 12 19:51:13 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Mar 2002 09:51:13 +0100 Subject: 3.1p1 breaks X11 forwarding In-Reply-To: <15501.46002.146859.423043@torment.proulx.com>; from Bob Proulx on Tue, Mar 12, 2002 at 12:52:18AM -0700 References: <15501.38088.248386.30275@torment.proulx.com> <15501.46002.146859.423043@torment.proulx.com> Message-ID: <20020312095113.B13427@greenie.muc.de> Hi, On Tue, Mar 12, 2002 at 12:52:18AM -0700, Bob Proulx wrote: > > X11UseLocalhost > > I don't think that is the problem. Don't discuss with developers, try it out. Some X11 apps are "difficult" when it comes to $DISPLAY and 127.0.0.1 - there was a long thread in the mailing list about this a few months ago. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From dtucker at zip.com.au Tue Mar 12 20:23:42 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Mar 2002 20:23:42 +1100 Subject: Error with building openssh-3.1p1 package References: Message-ID: <3C8DC91E.E0C31B76@zip.com.au> Ben Lindstrom wrote: [Solaris buildpkg updates] > It may or may not be in the 3.1p2 release (being done to handle compiling > issues). On a related issue, what are the odds of the fix for the AIX buildbff getting in? (and chmod'ed +x?) It experienced similar breakage. I posted a patch a couple of days ago but it's also available here: http://www.zip.com.au/~dtucker/openssh-3.1p1-aixbff.patch Are the issues mentioned applicable to the AIX package build too? -Daz. From bugzilla-daemon at mindrot.org Tue Mar 12 20:32:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Mar 2002 20:32:20 +1100 (EST) Subject: [Bug 159] New: Password-Authentication with openssh-3.1p1 fails Message-ID: <20020312093220.31514EB73@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=159 Summary: Password-Authentication with openssh-3.1p1 fails Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: fam.muck at telda.net CC: fam.muck at telda.net Hallo out there, I've got a strange problem after updating my openssh-installation from 2.9.9p2 (SuSE-package) to openssh-3.1p1 (Installation from the source with a modified src.rpm). I will give you as much information as possible and I hope there is anybody who can help me. I asked in detail in usenet-groups but nobody had any idea to fix my problem by configuration. My system is a SuSE-Linux 7.2: -kernel 2.4.16-4GB (original SuSE-7.2-package) -pam 0.75 (SuSE-7.3-package after rebuilding) -previous openssh-version: 2.9.9p2 (original SuSE-7.2-package) On this system I could work with openssh as expected: authentication works with pubkey- and password-authentication (other authentication-methods were not allowed). After updating my openssh-package to the current version pubkey-authentication still works but password-authentication fails in every case. I compiled openssh-3.1p1 as follows (options included in the src.rpm): ./configure \ --mandir=%{_mandir} \ --prefix=%{prefix} \ --infodir=%{_infodir} \ --sysconfdir=/etc/ssh \ --libexecdir=%{prefix}/lib/ssh \ --with-tcp-wrappers \ --with-pam make Software- and package-building works fine. After installation I can connect to localhost via pubkey- authentication (server running in debug-mode): andreas at home:~ > ssh localhost Enter passphrase for key '/home/andreas/.ssh/id_rsa': Last login: Sat Mar 9 19:48:41 2002 from console Have a lot of fun... debug1: PAM establishing creds Environment: USER=andreas LOGNAME=andreas HOME=/home/andreas PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail/andreas SHELL=/bin/bash SSH_CLIENT=127.0.0.1 1046 22 SSH_TTY=/dev/pts/4 TERM=xterm andreas at home:~ > When I disable my authorized_keys-files I would expect password-authentication - which takes place, but I've got no connection even if I type my correct password (you can be sure that the password used is correct): andreas at home:~ > mv ./.ssh/authorized_keys2 \ ./.ssh/authorized_keys2.orig andreas at home:~ > ssh localhost andreas at localhost's password: Permission denied, please try again. andreas at localhost's password: Permission denied, please try again. andreas at localhost's password: Permission denied (publickey,password,keyboard-interactive). andreas at home:~ > Here is server-output in debug-mode: bash-2.05# sshd -4 -d debug1: sshd version OpenSSH_3.1p1 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 1053 debug1: Client protocol version 2.0; client software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.1p1 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none 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: 121/256 debug1: bits set: 1655/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1583/3191 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 andreas service ssh-connection method none debug1: attempt 0 failures 0 debug1: Starting up PAM with username "andreas" debug1: PAM setting rhost to "localhost" Failed none for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys debug1: restore_uid debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method publickey debug1: attempt 2 failures 2 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys debug1: restore_uid debug1: temporarily_use_uid: 500/100 (e=0) debug1: trying public key file /home/andreas/.ssh/authorized_keys2 debug1: restore_uid Failed publickey for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method keyboard-interactive debug1: attempt 3 failures 3 debug1: keyboard-interactive devs debug1: auth2_challenge: user=andreas devs= debug1: kbdint_alloc: devices '' Failed keyboard-interactive for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method password debug1: attempt 4 failures 4 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method passworddebug1: attempt 5 failures 5 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 debug1: userauth-request for user andreas service ssh-connection method passworddebug1: attempt 6 failures 6 debug1: PAM Password authentication for "andreas" failed[7]: Authentication failure Failed password for andreas from 127.0.0.1 port 1053 ssh2 Connection closed by 127.0.0.1 debug1: Calling cleanup 0x8052ce0(0x0) debug1: Calling cleanup 0x8068e20(0x0) bash-2.05# That is the part of /var/log/messages generated by PAM: Mar 9 20:14:55 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:14:55 home PAM-unix2[1045]: username=[andreas] Mar 9 20:14:55 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Mar 9 20:14:59 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:14:59 home PAM-unix2[1045]: username=[andreas] Mar 9 20:14:59 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Mar 9 20:15:04 home PAM-unix2[1045]: pam_sm_authenticate() called Mar 9 20:15:04 home PAM-unix2[1045]: username=[andreas] Mar 9 20:15:04 home PAM-unix2[1045]: wrong password, return \ PAM_AUTH_ERR Here is my /etc/pam.d/sshd: #%PAM-1.0 auth required /lib/security/pam_unix.so debug # \ set_secrpc auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_unix.so password required /lib/security/pam_pwcheck.so md5 \ use_cracklib password required /lib/security/pam_unix.so md5 \ use_first_pass use_authtok session required /lib/security/pam_unix.so none # \ trace or debug session required /lib/security/pam_limits.so This /etc/pam.d/sshd works fine with openssh-2.9.9p2 (SuSE-package). My /etc/ssh/sshd_config is empty (all entries are comments) except for the sftp-subsystem. My ~/.ssh/config is empty too. I think there is a problem with PAM, but I'm sure my configuration is valid. It seems that openssh passes a wrong password to PAM which results in an error. So, much thanks for your effort fighting through my infos, I hope there is anybody who has any idea! Ciao Andreas ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bob at proulx.com Tue Mar 12 20:34:53 2002 From: bob at proulx.com (Bob Proulx) Date: Tue, 12 Mar 2002 02:34:53 -0700 Subject: 3.1p1 breaks X11 forwarding In-Reply-To: <20020312095113.B13427@greenie.muc.de> References: <15501.38088.248386.30275@torment.proulx.com> <15501.46002.146859.423043@torment.proulx.com> <20020312095113.B13427@greenie.muc.de> Message-ID: <15501.52157.44017.146027@torment.proulx.com> > > > X11UseLocalhost > > I don't think that is the problem. > > Don't discuss with developers, try it out. I get to eat my own words. I apologize for second guessing Kevin. I was fixated on the changes from 2.9.9 to 3.0.2 to 3.1 and was in disbelief at how something that obviously could not be the problem could be the problem. I tried the following: sshd -p 2200 -o 'PidFile /tmp/sshd.pid' -o 'X11UseLocalhost no' And it worked! The different X11 programs all worked fine. That appears to resolve the problem. > Some X11 apps are "difficult" when it comes to $DISPLAY and 127.0.0.1 - > there was a long thread in the mailing list about this a few months ago. I will have to search the archives some more and see what that was all about. On the surface it makes no sense to me that a program would know the difference between "localhost" which resolves to 127.0.0.1 which is a valid address and "hostname" which resolves to 15.6.91.87 which is also a valid address. [Something to do with the old unix:0 issue?] But if this has all been discussed before I don't want to drag people down again with it now. Thanks for excellent assistance. Even if I did prove myself wrong in the process. :-) Bob From RGiersig at a1.net Tue Mar 12 21:58:12 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Tue, 12 Mar 2002 11:58:12 +0100 Subject: Logging of client commands, possible? Message-ID: <13e98213e191.13e19113e982@a1.net> > > I believe one can obfuscate one's tty session such that you > > might not really figure out what was done merely through a > > keystroke replay. > > Ah, but if the only incoming channel of de-obfuscation code is itself > tapped, it's actually provably impossible to successfully > obfuscate the code. Right, and don't forget that ssh already provides strong authentication, so that should be enough to be able to point a finger at somebody and have the inquisition take over. "What were you uploading there?" > > I think a tty-log plus a history of exec*()s and open()s and > > creat()s> and so on would be a rather complete record, yes. But > > ultimately a sufficiently nasty and savvy user can get 'round > > such logging (though the obfuscation necessary might itself > > raise enough red flags that you could catch such a user). > > As I've been saying, often the "enemy" is lack of documentation and > accountability, not an active attacker. Production machines need > histories of who did what when. That's exactly my point. Providing a secure, stable, shared computing environment to untrusted users is nearly impossible, so we don't have to go that way (but it's of course interesting to talk about it). If I had to do this, I'd run multiple virtual machines and give every user her own. Proper load-balancing and quotas does the rest... So I'll summarize my wishes: per-connection logging of what gets sent from the client to the server. When a connection gets accepted, a logfile is created in a logdir whose filename contains a timestamp, pid of the sshd process that handles the connection, if a terminal is requested, authenticated user name and hostname from where the connection came. If the session uses a tty, a timestamp is written periodically to the logfile (once a minute) to give an indication what happened when. X forwarding could be logged the same way, as well as other forwarded ports. Anybody from the openssh developer team reading this? Roland -- RGiersig at cpan.org From dan at doxpara.com Wed Mar 13 22:05:04 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 13 Mar 2002 03:05:04 -0800 Subject: Logging of client commands, possible? References: <13e98213e191.13e19113e982@a1.net> Message-ID: <00b001c1ca7e$edcc6510$1701000a@effugas> > So I'll summarize my wishes: per-connection logging of what gets sent > from the client to the server. I get the off feeling you wouldn't mind logging what the server sends back to the client ;-) > When a connection gets accepted, a > logfile is created in a logdir whose filename contains a timestamp, pid > of the sshd process that handles the connection, if a terminal is > requested, authenticated user name and hostname from where the > connection came. If the session uses a tty, a timestamp is written > periodically to the logfile (once a minute) to give an indication what > happened when. X forwarding could be logged the same way, as well as > other forwarded ports. I'm thinking more about leaving the exact configuration of the log format up to sshd_config, complete with variable completion. Beyond dumping to a file, it might be useful to specify a command which is executed for each incoming SSH connection that gets piped the traffic of the TTY. One could imagine an off-host backup of all communication through that host. Only problem is that this is a beautiful, beautiful method for capturing the passwords of those who chain their SSH connections(type the password to host2 into host1). This is a *huge* problem with SSH in practical usage, and while it's completely unnecessary, the behavior isn't convenient enough to eliminate yet. Of course, black hats aren't having any problem making trojan builds, now are they. --Dan From gert at greenie.muc.de Tue Mar 12 22:21:48 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Mar 2002 12:21:48 +0100 Subject: Disconnecting: Corrupted check bytes on input. Message-ID: <20020312122148.D15653@greenie.muc.de> Hi, just "cvs update"'d to get the latest portable version, to start rebuilding our AIX systems to get zlib-1.1.4 and the channel-bug fix. SSH protocol 2 seems to work nicely, ssh protocol 1 doesn't work properly. Environment: AIX 4.3.3, openssl 0.9.6c, openssh as of today (Mar 12, 11:20 GMT). Client/blowfish, to openssh 3.0p1 or to 2.5.1p1: debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x20009598(0x0) Client/3des: debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying rhosts or /etc/hosts.equiv with RSA host authentication. debug1: Remote: Accepted for hilb0.medat.de [172.30.1.8] by /etc/hosts.equiv. debug1: Received RSA challenge for host key from server. debug1: Sending response to host key RSA challenge. debug1: Remote: Rhosts with RSA host authentication accepted. debug1: Rhosts or /etc/hosts.equiv with RSA host authentication accepted by server. (works) Server: same game - incoming connection with "-1 -c blowfish": debug1: Client protocol version 1.5; client software version 1.2.20 debug1: match: 1.2.20 pat 1.2.18*,1.2.19*,1.2.20*,1.2.21*,1.2.22* debug1: Local version string SSH-1.99-OpenSSH_3.1p1-GD/PM debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: blowfish debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x20008e58(0x0) -2 or -c 3des work. I have seen this error message a few times on this list, so I assume Markus knows what is causing this. Am I correct in assuming that the fix just hasn't propagated to -portable yet, and all I can do is to be patient? 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 markus at openbsd.org Tue Mar 12 22:36:21 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Mar 2002 12:36:21 +0100 Subject: Disconnecting: Corrupted check bytes on input. In-Reply-To: <20020312122148.D15653@greenie.muc.de> References: <20020312122148.D15653@greenie.muc.de> Message-ID: <20020312113621.GA20871@faui02> On Tue, Mar 12, 2002 at 12:21:48PM +0100, Gert Doering wrote: > Environment: AIX 4.3.3, openssl 0.9.6c, openssh as of today (Mar 12, 11:20 this really happens with openssl > 0.9.5 ? From morty at frakir.org Tue Mar 12 22:42:58 2002 From: morty at frakir.org (Mordechai T. Abzug) Date: Tue, 12 Mar 2002 06:42:58 -0500 Subject: patch for password expiration under Solaris? In-Reply-To: <20020311220407.A3430@red-sonja.frakir.org> References: <20020311220407.A3430@red-sonja.frakir.org> Message-ID: <20020312064258.A7006@red-sonja.frakir.org> On Mon, Mar 11, 2002 at 10:04:07PM -0500, Mordechai T. Abzug wrote: > I'm looking to move some Solaris 2.6 and 7 machines to openssh. > Showstopper bug: openssh (up to 3.1p1) doesn't seem to correctly > implement expired passwords. [snip] Never mind -- ./configure --with-pam is the solution to that problem. Sorry. - Morty From gert at greenie.muc.de Tue Mar 12 22:53:30 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Mar 2002 12:53:30 +0100 Subject: Disconnecting: Corrupted check bytes on input. In-Reply-To: <20020312113621.GA20871@faui02>; from Markus Friedl on Tue, Mar 12, 2002 at 12:36:21PM +0100 References: <20020312122148.D15653@greenie.muc.de> <20020312113621.GA20871@faui02> Message-ID: <20020312125330.E15653@greenie.muc.de> hi, On Tue, Mar 12, 2002 at 12:36:21PM +0100, Markus Friedl wrote: > On Tue, Mar 12, 2002 at 12:21:48PM +0100, Gert Doering wrote: > > Environment: AIX 4.3.3, openssl 0.9.6c, openssh as of today (Mar 12, 11:20 > this really happens with openssl > 0.9.5 ? Ummm. gd at hilb0:/gnulocal/src/openssh_cvs> ./ssh -v -1 hilb1 OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f I'm not sure where it found that one, I was sure I had 0.9.6c installed as the system default. Bah. Ah. Forgot "make install" in the openssl directory :-( Re-built, using OpenSSL 0.9.6c now (really!), and now it works: debug1: Encryption type: blowfish debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying rhosts or /etc/hosts.equiv with RSA host authentication. debug1: Remote: Accepted for ... by /etc/hosts.equiv. debug1: Received RSA challenge for host key from server. debug1: Sending response to host key RSA challenge. thanks, and sorry. 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 schott at rzg.mpg.de Tue Mar 12 23:08:35 2002 From: schott at rzg.mpg.de (Andreas Schott) Date: Tue, 12 Mar 2002 13:08:35 +0100 Subject: OpenSSH 3.1: ssh-rand-helper Message-ID: <15501.61379.403512.967043@pilatus.rzg.mpg.de> Dear openssh-developers, the new external program ssh-rand-helper appeared in OpenSSH 3.1. While the SFTP_SERVER is defined using a _PATH_SFTP_SERVER pointing to SFTP_SERVER in Makefile.in and defining a default-path in pathnames.h the ssh-rand-helper is simply SSH_RAND_HELPER and defined with a fixed path in Makefile.in and not having a default in pathnames.h. I propose a handling analogous to the sftp-server binary. *** Makefile.in.orig Tue Feb 26 20:24:22 2002 --- Makefile.in Tue Mar 12 12:42:05 2002 *************** *** 18,23 **** --- 18,24 ---- SSH_PROGRAM=@bindir@/ssh ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass SFTP_SERVER=$(libexecdir)/sftp-server + SSH_RAND_HELPER=$(libexecdir)/ssh-rand-helper PATHS= -DSSHDIR=\"$(sysconfdir)\" \ -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \ *************** *** 24,30 **** -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \ -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \ -D_PATH_SSH_PIDDIR=\"$(piddir)\" \ ! -DSSH_RAND_HELPER=\"$(libexecdir)/ssh-rand-helper\" CC=@CC@ LD=@LD@ --- 25,31 ---- -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \ -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \ -D_PATH_SSH_PIDDIR=\"$(piddir)\" \ ! -D_PATH_SSH_RAND_HELPER=\"$(SSH_RAND_HELPER)\" CC=@CC@ LD=@LD@ *** entropy.c.orig Tue Jan 22 11:57:54 2002 --- entropy.c Tue Mar 12 12:48:26 2002 *************** *** 67,73 **** return; } ! debug3("Seeing PRNG from %s", SSH_RAND_HELPER); if ((devnull = open("/dev/null", O_RDWR)) == -1) fatal("Couldn't open /dev/null: %s", strerror(errno)); --- 67,73 ---- return; } ! debug3("Seeing PRNG from %s", _PATH_SSH_RAND_HELPER); if ((devnull = open("/dev/null", O_RDWR)) == -1) fatal("Couldn't open /dev/null: %s", strerror(errno)); *************** *** 91,99 **** _exit(1); } ! execl(SSH_RAND_HELPER, "ssh-rand-helper", NULL); fprintf(stderr, "(rand child) Couldn't exec '%s': %s\n", ! SSH_RAND_HELPER, strerror(errno)); _exit(1); } --- 91,99 ---- _exit(1); } ! execl(_PATH_SSH_RAND_HELPER, "ssh-rand-helper", NULL); fprintf(stderr, "(rand child) Couldn't exec '%s': %s\n", ! _PATH_SSH_RAND_HELPER, strerror(errno)); _exit(1); } *** pathnames.h.orig Sun Feb 10 08:32:29 2002 --- pathnames.h Tue Mar 12 12:47:44 2002 *************** *** 139,144 **** --- 139,148 ---- #ifndef _PATH_SFTP_SERVER #define _PATH_SFTP_SERVER "/usr/libexec/sftp-server" #endif + /* for ssh-rand-helper */ + #ifndef _PATH_SSH_RAND_HELPER + #define _PATH_SSH_RAND_HELPER "/usr/libexec/ssh-rand-helper" + #endif #ifndef _PATH_LS #define _PATH_LS "ls" #endif BTW, there seems to be a strange problem with starting sshd from a watchdog-script started from inittab. I always got a ssh-rand-helper child produced insufficient data This dissappeared, when I redirected stdout and stderr of the startup-script into a file. This was a quite unexpected behaviour. With kind regards, Andreas Schott. ---------------------------------------------------------------- http://www.rzg.mpg.de/~ays | :-O Wissen ist Macht! email: schott at rzg.mpg.de | 8-( Ich wei? nichts. phone/fax: +49 89 3299-2180/1301 | ;-> Macht auch nichts. From Nicolas.Williams at ubsw.com Wed Mar 13 00:37:41 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 12 Mar 2002 08:37:41 -0500 Subject: Logging of client commands, possible? In-Reply-To: <13e98213e191.13e19113e982@a1.net>; from RGiersig@a1.net on Tue, Mar 12, 2002 at 11:58:12AM +0100 References: <13e98213e191.13e19113e982@a1.net> Message-ID: <20020312083739.H27398@sm2p1386swk.wdr.com> On Tue, Mar 12, 2002 at 11:58:12AM +0100, RGiersig at a1.net wrote: > > > I believe one can obfuscate one's tty session such that you > > > might not really figure out what was done merely through a > > > keystroke replay. > > > > Ah, but if the only incoming channel of de-obfuscation code is itself > > tapped, it's actually provably impossible to successfully > > obfuscate the code. You need to know the state of the host in order to reconstruct fully what happened given only a keystroke/output log. > Right, and don't forget that ssh already provides strong > authentication, so that should be enough to be able to point a finger > at somebody and have the inquisition take over. "What were you > uploading there?" Yes, obfuscation ought to raise eyebrows. Can you write heuristic algorithms for detection of obfuscation? I bet most of us humans can detect obfuscation with sufficient accuracy. > > As I've been saying, often the "enemy" is lack of documentation and > > accountability, not an active attacker. Production machines need > > histories of who did what when. Can't log everything. You cannot know everything there is to know about your systems. > That's exactly my point. Providing a secure, stable, shared computing > environment to untrusted users is nearly impossible, so we don't have > to go that way (but it's of course interesting to talk about it). If I > had to do this, I'd run multiple virtual machines and give every user > her own. Proper load-balancing and quotas does the rest... :) Deterrence through controls, logging and monitoring that enable decent post-mortems and some IDS along with decent restore capabilities. > So I'll summarize my wishes: per-connection logging of what gets sent > from the client to the server. When a connection gets accepted, a > logfile is created in a logdir whose filename contains a timestamp, pid > of the sshd process that handles the connection, if a terminal is > requested, authenticated user name and hostname from where the > connection came. If the session uses a tty, a timestamp is written > periodically to the logfile (once a minute) to give an indication what > happened when. X forwarding could be logged the same way, as well as > other forwarded ports. You mean per-channel, per-connection. SSHv2 supports multiple channels and what not. Do you want to log each packet in cleartext and with timestamps? Or just a stream of bytes for each channel direction? If the former then you'll need a replay tool. > Anybody from the openssh developer team reading this? I hope so. I do think that channel logging could be very useful. > Roland > -- > RGiersig at cpan.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 pekkas at netcore.fi Wed Mar 13 01:25:49 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 12 Mar 2002 16:25:49 +0200 (EET) Subject: 3.1p1 breaks X11 forwarding In-Reply-To: <15501.46002.146859.423043@torment.proulx.com> Message-ID: Hello all, Just as heads-up: On all-Linux systems, the necessity X11UseLocalhost=no (in some, more complex scenarios) also depends on whether IPv6 is enabled in sshd or not. I've yet to corner down what's causing this but I've seen a few cases that: (assuming X11UseLocalhost yes is the default) WORKS: sshd -4 WORKS: sshd -o 'X11UseLocalhost no' DOESN'T WORK: sshd (the application used was xterm). If this doesn't happen without Linux, it may be due to the Linux mapped-address implementation. I believe this will also have to do with the fact whether IPv6 has been enabled in X11 along the path. On Tue, 12 Mar 2002, Bob Proulx wrote: > > : X11 connection rejected because of wrong authentication. > > > > what OS? > > Homebrew GNU/Linux of my own compilation, Redhat 7.1 with my own > compile of ssh, HP-UX 10.20, HP-UX 11.0, HP-UX 11.11, I got caried > away and updated everything before I found the problem. As you can > see I don't think the OS is significant here. But in this particular > case I am using HP-UX as the sshd server. [As a trip down memory lane > one of the other apps that always crashes is piglet. But synchronize > also exhibits the problem.] > > > X11UseLocalhost > > I don't think that is the problem. The xterm comes through fine back > to back with other failing commands. I am $DISPLAYing onto the local > machine. So localhost at 127.0.0.1:12.0 should be fine. Although I > have previously been seeing the local_ip_address:12.0. > > ssh -X remotehost > xterm & # works > synchronize & # fails with wrong authentication message > piglet & # fails with wrong authentication message > xterm & # works > xclock & # fails > xterm & # works > > This happens when using either Protocol 1 or Protocol 2. As you can > see I can run commands back to back in the same window and see one > work and one fail. > > > also: > > http://bugzilla.mindrot.org/show_bug.cgi?id=150 > > That is the same as the problem I am describing. > > > echo $DISPLAY > > localhost:13.0 > > What I exptected is: > > rodenss at ginkgo:~$ echo $DISPLAY > > 10.100.53.39:13.0 > > This has a similar message and similar DISPLAY behavior and the > problem is almost certainly related. > > > /usr/bin/X11/xterm uses R5 libs. > > I am using color xterm-159 compiled by me moons ago and it has been in > solid use since then. I think I compiled it using the R6 libs. The > shipped xterm is ancient. > > It is probably pertinent that I am using a recently compiled xterm > using later libraries than the xterm shipped with hpux. I am using > the shipped (or patched) X11 libs on a 10.20 machine to compile the > xterm as I did not compile the X11 libs. Other stock applications are > causing the crash but this one does not. > > > try /usr/contrib/bin/X11/xterm > > That one has a broken resize, no sigwinch capability, and I remove it > with prejudice whenever I install a new system so that it does not get > invoked by accident. It is a very frustrating version. > > > :Secondly, in going back to 3.0.2p1 to try to work around this problem > > :I was able to crash ssh with the following error. I window killed a > > :forwarded xterm which was running a separate X11 program also > > :forwarded. The child tunneled X11 program appeared to hang and I > > :killed the application. This crashed the underlying ssh with this > > :message. > > : > > :Received disconnect from 216.17.153.58: 2: Received ieof for nonexistent channel 8. > > > > can you submit that (plus exact how-to-dup details) to > > http://bugzilla.mindrot.org/ > > I don't think I can generate a recipe for someone else to recreate > this unless they have synchronize handy which I don't expect. > http://www.crosswind.com/sitemap.htm#sync. > > The details are that I am running the X11 client on my GNU/Linux > desktop. ssh-3.0.2p1 -X hpux to sshd-3.1p1. There start up 'xterm -e > synchronize'. The xterm comes up but the synchronize window never > does. Running tcpdump in another window shows no network activity. > After ten minutes kill the xterm with a window manager window pulldown > kill (FVWM2). The original ssh -X connection then dies with that > message. When I try 'xterm -e xclock' I never get the xclock window > and killing xterm does not generate a death of the ssh client. > > Bob > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- 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 stevesk at pobox.com Wed Mar 13 04:57:50 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 12 Mar 2002 09:57:50 -0800 (PST) Subject: 3.1p1 breaks X11 forwarding In-Reply-To: Message-ID: On Tue, 12 Mar 2002, Pekka Savola wrote: :Just as heads-up: On all-Linux systems, the necessity X11UseLocalhost=no :(in some, more complex scenarios) also depends on whether IPv6 is enabled :in sshd or not. : :I've yet to corner down what's causing this but I've seen a few cases :that: : :(assuming X11UseLocalhost yes is the default) :WORKS: sshd -4 :WORKS: sshd -o 'X11UseLocalhost no' :DOESN'T WORK: sshd : :(the application used was xterm). : :If this doesn't happen without Linux, it may be due to the Linux :mapped-address implementation. : :I believe this will also have to do with the fact whether IPv6 has been :enabled in X11 along the path. strange. i was thinking of doing the following a while back, but IPv6 X11 is apparently on the horizon, so we left it. are your X clients IPv6 capable? Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.146 diff -u -r1.146 channels.c --- channels.c 6 Dec 2001 18:20:32 -0000 1.146 +++ channels.c 7 Dec 2001 18:56:35 -0000 @@ -2411,7 +2411,7 @@ display_number++) { port = 6000 + display_number; memset(&hints, 0, sizeof(hints)); - hints.ai_family = IPv4or6; + hints.ai_family = AF_INET; hints.ai_flags = gateway_ports ? AI_PASSIVE : 0; hints.ai_socktype = SOCK_STREAM; snprintf(strport, sizeof strport, "%d", port); From austin at coremetrics.com Wed Mar 13 05:08:14 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 12 Mar 2002 12:08:14 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <53A10F824E50D511820800508BDF3F2201AD1EE7@fszhtv12.wpafb.af.mil> References: <53A10F824E50D511820800508BDF3F2201AD1EE7@fszhtv12.wpafb.af.mil> Message-ID: <1015956494.20554.2.camel@UberGeek> Kewl. I was trying to figure out how to re-build the configure..but autoconf complains that configure.in isn't there. I'll try the autoreconf and see. On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > For 3.0.2p1, after you apply the patches, you need to run the > 'autoreconf' > command from autoconf 2.5 or higher. After that, you should be able to > run > configure with --kerberos5=PATH. It worked for me with redhat 7.1, but > the > patches keep failing for me under Solaris 8. Unfortunately, I don't know > enough C yet to even begin to troubleshoot it. > > Has anyone else run into this problem with the patches in Solaris 8? > > Thanks, > > Eric > > -----Original Message----- > From: Austin Gonyou [mailto:austin at coremetrics.com] > Sent: Monday, March 11, 2002 8:07 PM > To: John Hawkinson > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > With respect to the patches, if *anyone* knows, how is the configure > supposed to happen? Just say --with-kerberos4? Is there another option? > I can't seem to see it if there is. TIA. > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > Damien Miller wrote on Mon, 11 Mar 2002 > > at 13:54:52 +1100 in > > : > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > Just curious. There seems to be an awful lot in the source, but no > > > > actual configure option. > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > compile > > > against MIT krbV. > > > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > > you can get Simon Wilkinson's patch from > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > --jhawk > -- > 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 > _______________________________________________ > 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 From austin at coremetrics.com Wed Mar 13 05:10:33 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 12 Mar 2002 12:10:33 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <53A10F824E50D511820800508BDF3F2201AD1EE7@fszhtv12.wpafb.af.mil> References: <53A10F824E50D511820800508BDF3F2201AD1EE7@fszhtv12.wpafb.af.mil> Message-ID: <1015956633.20431.5.camel@UberGeek> Ok..I'm sorry I'm so dumb..but autoreconf just returns to a prompt..and no configure is created. Can autoconf be used to create the configure? If so, what file can I symlink to configure.in. On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > For 3.0.2p1, after you apply the patches, you need to run the > 'autoreconf' > command from autoconf 2.5 or higher. After that, you should be able to > run > configure with --kerberos5=PATH. It worked for me with redhat 7.1, but > the > patches keep failing for me under Solaris 8. Unfortunately, I don't know > enough C yet to even begin to troubleshoot it. > > Has anyone else run into this problem with the patches in Solaris 8? > > Thanks, > > Eric > > -----Original Message----- > From: Austin Gonyou [mailto:austin at coremetrics.com] > Sent: Monday, March 11, 2002 8:07 PM > To: John Hawkinson > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > With respect to the patches, if *anyone* knows, how is the configure > supposed to happen? Just say --with-kerberos4? Is there another option? > I can't seem to see it if there is. TIA. > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > Damien Miller wrote on Mon, 11 Mar 2002 > > at 13:54:52 +1100 in > > : > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > Just curious. There seems to be an awful lot in the source, but no > > > > actual configure option. > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > compile > > > against MIT krbV. > > > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > > you can get Simon Wilkinson's patch from > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > --jhawk > -- > 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 > _______________________________________________ > 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 From acox at ia.primustel.com Wed Mar 13 05:14:59 2002 From: acox at ia.primustel.com (Aran Cox) Date: 12 Mar 2002 12:14:59 -0600 Subject: error compiling openssh-3.1p1 under SCO OpenServer 5.0.5 Message-ID: <1015956899.16560.30.camel@benway.cv.telegroup.com> Trying to compile openssh-3.1p1 on SCO using: export CCFLAGS='-L/usr/local/lib -I/usr/local/include' ./configure --sysconfdir=/etc/ssh --with-rsh=/usr/bin/rcmd --exec-prefix=/usr OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /etc/ssh sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin Manpage format: man PAM support: no KerberosIV support: no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: ssh-rand-helper ssh-rand-helper collects from: Command hashing (timeout 200) Host: i686-pc-sco3.2v5.0.5 Compiler: cc Compiler flags: -g Preprocessor flags: -I/usr/local/ssl/include -I/usr/local/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/lib Libraries: -lz -lsocket -lprot -lx -ltinfo -lm -lcrypto sftp-server will be disabled. Your compiler does not support 64bit integers. WARNING: you are using the builtin random number collection service. Please read WARNING.RNG and request that your OS vendor includes kernel-based random number collection in future versions of your OS. I get this: cc -g -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/etc/ssh\" -DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c "cipher.c", line 200: error: operand cannot have void type: op "==" "cipher.c", line 200: error: operands have incompatible types: op "==" "cipher.c", line 210: error: operand cannot have void type: op "==" "cipher.c", line 210: error: operands have incompatible types: op "==" "cipher.c", line 220: error: operand cannot have void type: op "==" "cipher.c", line 220: error: operands have incompatible types: op "==" "cipher.c", line 227: error: operand cannot have void type: op "==" "cipher.c", line 227: error: operands have incompatible types: op "==" "cipher.c", line 280: warning: assignment type mismatch "cipher.c", line 299: error: operand cannot have void type: op "==" "cipher.c", line 299: error: operands have incompatible types: op "==" "cipher.c", line 300: error: operand cannot have void type: op "==" "cipher.c", line 300: error: operands have incompatible types: op "==" "cipher.c", line 301: error: operand cannot have void type: op "==" "cipher.c", line 301: error: operands have incompatible types: op "==" "cipher.c", line 314: warning: assignment type mismatch "cipher.c", line 318: error: operand cannot have void type: op "==" "cipher.c", line 318: error: operands have incompatible types: op "==" "cipher.c", line 319: error: operand cannot have void type: op "==" "cipher.c", line 319: error: operands have incompatible types: op "==" "cipher.c", line 320: error: operand cannot have void type: op "==" "cipher.c", line 320: error: operands have incompatible types: op "==" "cipher.c", line 329: warning: assignment type mismatch "cipher.c", line 346: warning: assignment type mismatch "cipher.c", line 347: warning: assignment type mismatch "cipher.c", line 348: warning: assignment type mismatch "cipher.c", line 349: error: improper member use: flags "cipher.c", line 349: error: undefined symbol: EVP_CIPH_CBC_MODE "cipher.c", line 349: error: undefined symbol: EVP_CIPH_VARIABLE_LENGTH "cipher.c", line 392: warning: assignment type mismatch "cipher.c", line 394: warning: assignment type mismatch "cipher.c", line 413: warning: assignment type mismatch "cipher.c", line 440: warning: assignment type mismatch "cipher.c", line 477: warning: assignment type mismatch "cipher.c", line 494: warning: assignment type mismatch "cipher.c", line 495: warning: assignment type mismatch "cipher.c", line 496: warning: assignment type mismatch "cipher.c", line 497: error: improper member use: flags "cipher.c", line 497: error: undefined symbol: EVP_CIPH_CBC_MODE "cipher.c", line 497: error: undefined symbol: EVP_CIPH_VARIABLE_LENGTH "cipher.c", line 498: error: undefined symbol: EVP_CIPH_ALWAYS_CALL_INIT *** Error code 1 (bu21) I am using the SCO development environment to compile on SCO OpenServer 5.0.5 using openssl-0.9.5a. Any suggestions? From stevesk at pobox.com Wed Mar 13 05:16:50 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 12 Mar 2002 10:16:50 -0800 (PST) Subject: 3.1p1 breaks X11 forwarding In-Reply-To: <15501.52157.44017.146027@torment.proulx.com> Message-ID: On Tue, 12 Mar 2002, Bob Proulx wrote: :> Some X11 apps are "difficult" when it comes to $DISPLAY and 127.0.0.1 - :> there was a long thread in the mailing list about this a few months ago. : :I will have to search the archives some more and see what that was all :about. On the surface it makes no sense to me that a program would :know the difference between "localhost" which resolves to 127.0.0.1 :which is a valid address and "hostname" which resolves to 15.6.91.87 :which is also a valid address. [Something to do with the old unix:0 :issue?] But if this has all been discussed before I don't want to :drag people down again with it now. it has to do with aggresive optimizations and assumptions made in Xlib about when an inet display should really mean to use the local transport. there are also issues with X authority handling where "127.0.0.1" is special-cased to FamilyLocal. HP does something special when display is hostname, which is why we have IPADDR_IN_DISPLAY. From mouring at etoh.eviladmin.org Wed Mar 13 04:45:24 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 12 Mar 2002 11:45:24 -0600 (CST) Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <1015956494.20554.2.camel@UberGeek> Message-ID: You must use Autoconf 2.52 or greater. - Ben On 12 Mar 2002, Austin Gonyou wrote: > Kewl. I was trying to figure out how to re-build the configure..but > autoconf complains that configure.in isn't there. I'll try the > autoreconf and see. > > On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > > For 3.0.2p1, after you apply the patches, you need to run the > > 'autoreconf' > > command from autoconf 2.5 or higher. After that, you should be able to > > run > > configure with --kerberos5=PATH. It worked for me with redhat 7.1, but > > the > > patches keep failing for me under Solaris 8. Unfortunately, I don't know > > enough C yet to even begin to troubleshoot it. > > > > Has anyone else run into this problem with the patches in Solaris 8? > > > > Thanks, > > > > Eric > > > > -----Original Message----- > > From: Austin Gonyou [mailto:austin at coremetrics.com] > > Sent: Monday, March 11, 2002 8:07 PM > > To: John Hawkinson > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > > > > With respect to the patches, if *anyone* knows, how is the configure > > supposed to happen? Just say --with-kerberos4? Is there another option? > > I can't seem to see it if there is. TIA. > > > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > > Damien Miller wrote on Mon, 11 Mar 2002 > > > at 13:54:52 +1100 in > > > : > > > > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > > > Just curious. There seems to be an awful lot in the source, but no > > > > > actual configure option. > > > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > > compile > > > > against MIT krbV. > > > > > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > > > you can get Simon Wilkinson's patch from > > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > > > --jhawk > > -- > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Nicolas.Williams at ubsw.com Wed Mar 13 05:24:33 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 12 Mar 2002 13:24:33 -0500 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <1015956633.20431.5.camel@UberGeek>; from austin@coremetrics.com on Tue, Mar 12, 2002 at 12:10:33PM -0600 References: <53A10F824E50D511820800508BDF3F2201AD1EE7@fszhtv12.wpafb.af.mil> <1015956633.20431.5.camel@UberGeek> Message-ID: <20020312132431.I27398@sm2p1386swk.wdr.com> You need a newer version of autoconf. Cheers, Nico On Tue, Mar 12, 2002 at 12:10:33PM -0600, Austin Gonyou wrote: > Ok..I'm sorry I'm so dumb..but autoreconf just returns to a prompt..and > no configure is created. Can autoconf be used to create the configure? > If so, what file can I symlink to configure.in. > > > On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > > For 3.0.2p1, after you apply the patches, you need to run the > > 'autoreconf' > > command from autoconf 2.5 or higher. After that, you should be able to > > run > > configure with --kerberos5=PATH. It worked for me with redhat 7.1, but > > the > > patches keep failing for me under Solaris 8. Unfortunately, I don't know > > enough C yet to even begin to troubleshoot it. > > > > Has anyone else run into this problem with the patches in Solaris 8? > > > > Thanks, > > > > Eric > > > > -----Original Message----- > > From: Austin Gonyou [mailto:austin at coremetrics.com] > > Sent: Monday, March 11, 2002 8:07 PM > > To: John Hawkinson > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > > > > With respect to the patches, if *anyone* knows, how is the configure > > supposed to happen? Just say --with-kerberos4? Is there another option? > > I can't seem to see it if there is. TIA. > > > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > > Damien Miller wrote on Mon, 11 Mar 2002 > > > at 13:54:52 +1100 in > > > : > > > > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > > > Just curious. There seems to be an awful lot in the source, but no > > > > > actual configure option. > > > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > > compile > > > > against MIT krbV. > > > > > > So in the meantime, you can either use Heimdal instead of MIT krb5, or > > > you can get Simon Wilkinson's patch from > > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > > > --jhawk > > -- > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > 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 austin at coremetrics.com Wed Mar 13 05:43:22 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 12 Mar 2002 12:43:22 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <20020312132431.I27398@sm2p1386swk.wdr.com> References: <20020312132431.I27398@sm2p1386swk.wdr.com> Message-ID: <1015958602.21190.5.camel@UberGeek> THX. Sure seems so. Isn't 2.13 newer than 2.5 though? I will check it out and find the source of this issue. Thx. On Tue, 2002-03-12 at 12:24, Nicolas Williams wrote: > You need a newer version of autoconf. > > Cheers, > > Nico > > > On Tue, Mar 12, 2002 at 12:10:33PM -0600, Austin Gonyou wrote: > > Ok..I'm sorry I'm so dumb..but autoreconf just returns to a > prompt..and > > no configure is created. Can autoconf be used to create the configure? > > If so, what file can I symlink to configure.in. > > > > > > On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > > > For 3.0.2p1, after you apply the patches, you need to run the > > > 'autoreconf' > > > command from autoconf 2.5 or higher. After that, you should be able > to > > > run > > > configure with --kerberos5=PATH. It worked for me with redhat 7.1, > but > > > the > > > patches keep failing for me under Solaris 8. Unfortunately, I don't > know > > > enough C yet to even begin to troubleshoot it. > > > > > > Has anyone else run into this problem with the patches in Solaris 8? > > > > > > Thanks, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Austin Gonyou [mailto:austin at coremetrics.com] > > > Sent: Monday, March 11, 2002 8:07 PM > > > To: John Hawkinson > > > Cc: openssh-unix-dev at mindrot.org > > > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > > > > > > > With respect to the patches, if *anyone* knows, how is the configure > > > supposed to happen? Just say --with-kerberos4? Is there another > option? > > > I can't seem to see it if there is. TIA. > > > > > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > > > Damien Miller wrote on Mon, 11 Mar 2002 > > > > at 13:54:52 +1100 in > > > > : > > > > > > > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > > > > > Just curious. There seems to be an awful lot in the source, > but no > > > > > > actual configure option. > > > > > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > > > compile > > > > > against MIT krbV. > > > > > > > > So in the meantime, you can either use Heimdal instead of MIT > krb5, or > > > > you can get Simon Wilkinson's patch from > > > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > > > > > --jhawk > > > -- > > > 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 > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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. -- 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 From austin at coremetrics.com Wed Mar 13 05:44:02 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 12 Mar 2002 12:44:02 -0600 Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: References: Message-ID: <1015958642.21240.7.camel@UberGeek> Ahhh..i see. 2.5x...not 2.5...big difference. :) Thanks! On Tue, 2002-03-12 at 11:45, Ben Lindstrom wrote: > > You must use Autoconf 2.52 or greater. > > - Ben > > On 12 Mar 2002, Austin Gonyou wrote: > > > Kewl. I was trying to figure out how to re-build the configure..but > > autoconf complains that configure.in isn't there. I'll try the > > autoreconf and see. > > > > On Tue, 2002-03-12 at 05:38, Pavlov Eric J Contr AFRL/MLOC wrote: > > > For 3.0.2p1, after you apply the patches, you need to run the > > > 'autoreconf' > > > command from autoconf 2.5 or higher. After that, you should be able > to > > > run > > > configure with --kerberos5=PATH. It worked for me with redhat 7.1, > but > > > the > > > patches keep failing for me under Solaris 8. Unfortunately, I don't > know > > > enough C yet to even begin to troubleshoot it. > > > > > > Has anyone else run into this problem with the patches in Solaris 8? > > > > > > Thanks, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Austin Gonyou [mailto:austin at coremetrics.com] > > > Sent: Monday, March 11, 2002 8:07 PM > > > To: John Hawkinson > > > Cc: openssh-unix-dev at mindrot.org > > > Subject: Re: Does OpenSSH 3.x support KRB5 directly? > > > > > > > > > With respect to the patches, if *anyone* knows, how is the configure > > > supposed to happen? Just say --with-kerberos4? Is there another > option? > > > I can't seem to see it if there is. TIA. > > > > > > On Mon, 2002-03-11 at 00:00, John Hawkinson wrote: > > > > Damien Miller wrote on Mon, 11 Mar 2002 > > > > at 13:54:52 +1100 in > > > > : > > > > > > > > > > > > > On 10 Mar 2002, Austin Gonyou wrote: > > > > > > > > > > > Just curious. There seems to be an awful lot in the source, > but no > > > > > > actual configure option. > > > > > > > > > > We are waiting on a compatibility patch so our auth-krb5.c will > > > > compile > > > > > against MIT krbV. > > > > > > > > So in the meantime, you can either use Heimdal instead of MIT > krb5, or > > > > you can get Simon Wilkinson's patch from > > > > "http://www.sxw.org.uk/computing/patches/openssh.html". > > > > > > > > --jhawk > > > -- > > > 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 > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 From Nicolas.Williams at ubsw.com Wed Mar 13 05:47:46 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 12 Mar 2002 13:47:46 -0500 Subject: scp completes but ssh subprocess in deadlock with sshd In-Reply-To: ; from apronk@csi.co.nz on Tue, Mar 12, 2002 at 11:27:19AM +1300 References: Message-ID: <20020312134745.J27398@sm2p1386swk.wdr.com> We're seeing the same problem here, but with 2.9p2 clients and 3.0.2p1 servers on Solaris. It seems to be a reliably reproduceable problem, but looking carefully it really seems like a non-deterministic problem. I suspect a race. We have captured some useful debug messages + other info which I will be posting to bugzilla. In all cases, whether the ssh hangs or not we see that both the server and the client have called channel_free() to free channel 0 (the session), that both have closed both sides of the channel and that the server sent the exit-status message and that the client received it. The only difference is that the client ends up going into a select() w/o timeout selecting for read on the SSH connection socket. This is really weird; there should be no calls to channel_free() between the (compat20 && session_closed && !channel_still_open()) check at the top of the client loop and the call to client_wait_until_can_do_something(), so I don't see how there can be a race condition. Yet there it is. In any case scp does exit even if the ssh hangs at the end. I am baffled. Cheers, Nico On Tue, Mar 12, 2002 at 11:27:19AM +1300, Adrian Pronk wrote: > I've just built openssh 3.1 for my Redhat 5.1 system (running on a 486 > DX-66) using the latest zlib and openssl libraries. > > Connecting to the machine with ssh seems to work fine (although it takes a > while to initiate a connection). > > But when I transfer a file to the machine with scp, it seems to work fine > and the scp completes, but an ssh sub-process remains behind on the client > and an sshd sub-process remains behind on the host. When I strace them, > the client is waiting on a socket and the host is waiting on three > different fd's (under 5.1, its hard to tell what they are without making an > effort :) ). > > I did not compile the system on the target machine (which is my firewall). > My old development machine was a RH 5.1 box. I bought a new box recently > and put RH 7.2 on it. I copied the development RH 5.1 file system on to it > (including /dev). I then chroot'ed to that directory , mounted a new /proc > and had my 5.1 development environment back. I compiled (make install) > openSSL, zlib, openSSH on this and copied the likely output files to the > target machine. I wouldn't think this development environment would break > anything. > > Does anyone know off the top of their heads what the problem might be? If > not, I'll get stuck in and have a look at the code and see if I can see > anything. > > -- > Adrian > > _______________________________________________ > 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 pekkas at netcore.fi Wed Mar 13 06:12:53 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 12 Mar 2002 21:12:53 +0200 (EET) Subject: 3.1p1 breaks X11 forwarding In-Reply-To: Message-ID: On Tue, 12 Mar 2002, Kevin Steves wrote: > On Tue, 12 Mar 2002, Pekka Savola wrote: > :Just as heads-up: On all-Linux systems, the necessity X11UseLocalhost=no > :(in some, more complex scenarios) also depends on whether IPv6 is enabled > :in sshd or not. > : > :I've yet to corner down what's causing this but I've seen a few cases > :that: > : > :(assuming X11UseLocalhost yes is the default) > :WORKS: sshd -4 > :WORKS: sshd -o 'X11UseLocalhost no' > :DOESN'T WORK: sshd > : > :(the application used was xterm). > : > :If this doesn't happen without Linux, it may be due to the Linux > :mapped-address implementation. > : > :I believe this will also have to do with the fact whether IPv6 has been > :enabled in X11 along the path. > > strange. i was thinking of doing the following a while back, but IPv6 X11 > is apparently on the horizon, so we left it. are your X clients IPv6 > capable? The clients I've used are IPv4-only. I also heard a (vague) report that from a FreeBSD client this would have worked slightly betterm but I can't confirm that. I hope to be able to figure out why this appears to work in some cases, and not in others, but I'm not sure if I'll have that much luck... > Index: channels.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/channels.c,v > retrieving revision 1.146 > diff -u -r1.146 channels.c > --- channels.c 6 Dec 2001 18:20:32 -0000 1.146 > +++ channels.c 7 Dec 2001 18:56:35 -0000 > @@ -2411,7 +2411,7 @@ > display_number++) { > port = 6000 + display_number; > memset(&hints, 0, sizeof(hints)); > - hints.ai_family = IPv4or6; > + hints.ai_family = AF_INET; > hints.ai_flags = gateway_ports ? AI_PASSIVE : 0; > hints.ai_socktype = SOCK_STREAM; > snprintf(strport, sizeof strport, "%d", port); > > > -- 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 gert at greenie.muc.de Wed Mar 13 07:39:25 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Mar 2002 21:39:25 +0100 Subject: error compiling openssh-3.1p1 under SCO OpenServer 5.0.5 In-Reply-To: <1015956899.16560.30.camel@benway.cv.telegroup.com>; from Aran Cox on Tue, Mar 12, 2002 at 12:14:59PM -0600 References: <1015956899.16560.30.camel@benway.cv.telegroup.com> Message-ID: <20020312213925.A28668@greenie.muc.de> hi, On Tue, Mar 12, 2002 at 12:14:59PM -0600, Aran Cox wrote: > I am using the SCO development environment to compile on SCO > OpenServer 5.0.5 using openssl-0.9.5a. You need openssl-0.9.6 - there is a patch for 0.9.5a around, but it has other issues. 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 bugzilla-daemon at mindrot.org Wed Mar 13 08:04:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 08:04:12 +1100 (EST) Subject: [Bug 160] New: Race condition in clientloop.c? Message-ID: <20020312210412.6D316E97A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=160 Summary: Race condition in clientloop.c? Product: Portable OpenSSH Version: 3.0.2p1 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams at ubsw.com We sometimes see SCP exit while leaving a hung SSH behind. SSH is left stuck in a poll()/select() waiting for the SSH connection socket to be readable. Nothing in the -v -v -v output is untoward. The server-side sshd -d -d -d output is the same whether the client hangs or not. In either case the client and server both close and free the last open channel (the session channel). See the "scp completes but ssh subprocess in deadlock with sshd" thread on the openssh-unix-dev post list. I will attach a tar file containing ssh -vvv and ssh -ddd output, lsof output, etc... for good scps and hanging sshs. Note that a select() wrapper was LD_PRELOADed into ssh that prints the list of file descriptors being selected for in every call to select(); source will be attached. This bug appears to be a race condition in the client. Versions of OpenSSH affected apparently include 2.9p2, 3.0.2p1 and 3.1p1. See these openssh-unix-dev posts: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101588612615615&w=2 http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=101596073221780&w=2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From imorgan at nas.nasa.gov Wed Mar 13 08:09:16 2002 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 12 Mar 2002 13:09:16 -0800 (PST) Subject: patch for password expiration under Solaris? In-Reply-To: <20020311220407.A3430@red-sonja.frakir.org> from "Mordechai T. Abzug" at Mar 11, 2002 10:04:07 PM Message-ID: <200203122109.NAA14467@nopython.nas.nasa.gov> Bug 14 includes a patch that is essentially Dave's patch. That worked up through 3.0.2p1. I tried it with 3.1.p1 and the patch did not apply completely. You should be able to avoid the issue for Solaris by using PAM. Use the --with-pam configure options. On Mon Mar 11 19:04:07 2002, Mordechai T. Abzug wrote: > > > I'm looking to move some Solaris 2.6 and 7 machines to openssh. > Showstopper bug: openssh (up to 3.1p1) doesn't seem to correctly > implement expired passwords. > > Looking back through the archive, it looks like Dave Dykstra submitted > a patch for this problem relative to an older version of openssh at > least as early as last August: > > http://msgs.securepoint.com/cgi-bin/get/openssh-unix-dev-0108/77.html > > The patch seems to work on one of my test machines, after some minimal > finagling. Is this patch the standard solution to this problem? > > Thanks! > > - Morty > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Iain Morgan NAS Desktop Support Group From acox at ia.primustel.com Wed Mar 13 08:11:09 2002 From: acox at ia.primustel.com (Aran Cox) Date: 12 Mar 2002 15:11:09 -0600 Subject: error compiling openssh-3.1p1 under SCO OpenServer 5.0.5 In-Reply-To: <20020312213925.A28668@greenie.muc.de> References: <1015956899.16560.30.camel@benway.cv.telegroup.com> <20020312213925.A28668@greenie.muc.de> Message-ID: <1015967469.3745.7.camel@benway.cv.telegroup.com> Thanks for the response! Perhaps someone should update the INSTALL file if openssl-0.9.6 is required now? Currently it still reads 0.9.5.a (which I have.) On Tue, 2002-03-12 at 14:39, Gert Doering wrote: > hi, > > On Tue, Mar 12, 2002 at 12:14:59PM -0600, Aran Cox wrote: > > I am using the SCO development environment to compile on SCO > > OpenServer 5.0.5 using openssl-0.9.5a. > > You need openssl-0.9.6 - there is a patch for 0.9.5a around, but it has > other issues. > > 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 markus at openbsd.org Wed Mar 13 08:54:11 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Mar 2002 22:54:11 +0100 Subject: Use of Private Keys In-Reply-To: ; from abhi@acc.com on Mon, Mar 11, 2002 at 01:29:57PM -0800 References: Message-ID: <20020312225411.B28682@folly> On Mon, Mar 11, 2002 at 01:29:57PM -0800, Abhijeet Thakare wrote: > I am not able to figure out where/how we are using the server's private key? man sshd: Whenever a client connects the daemon responds with its public host and server keys. The client compares the RSA host key against its own database to verify that it has not changed. The client then generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the serv- er. ... the server uses its private key to prove its indentity to the connecting user. From bugzilla-daemon at mindrot.org Wed Mar 13 09:10:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 09:10:12 +1100 (EST) Subject: [Bug 160] Race condition in clientloop.c? Message-ID: <20020312221012.0816CE967@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=160 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-13 09:10 ------- Created an attachment (id=40) Debug output, lsof output, etc... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Wed Mar 13 09:18:47 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Mar 2002 23:18:47 +0100 Subject: Logging of client commands, possible? In-Reply-To: <13e98213e191.13e19113e982@a1.net>; from RGiersig@a1.net on Tue, Mar 12, 2002 at 11:58:12AM +0100 References: <13e98213e191.13e19113e982@a1.net> Message-ID: <20020312231847.C28682@folly> On Tue, Mar 12, 2002 at 11:58:12AM +0100, RGiersig at a1.net wrote: > Anybody from the openssh developer team reading this? i'd like to capture unencrypted ssh packets in pcap format, just like openbsd's isakmpd does. and add support to tcpdump and etherreal for interpreting these packet, this would make debugging simpler. From bugzilla-daemon at mindrot.org Wed Mar 13 11:46:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 11:46:25 +1100 (EST) Subject: [Bug 161] New: Cannot build afs support on Solaris platform Message-ID: <20020313004625.C5F85E99C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=161 Summary: Cannot build afs support on Solaris platform Product: Portable OpenSSH Version: -current Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: scott.packard at jpl.nasa.gov When building with the --with-afs option the make bombs out when building sshconnect1.c, claiming an undefined function k_hasafs(). I googled a little and found that this function (and others like it) are in either AIX or perhaps *BSD kernels. They are not part of Solaris. When I commented out that check, then I get a different error in the same module about krb_time_to_life (sic). It appears to me that the 3.1p1 afs portion has not been ported. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Thu Mar 14 11:43:12 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 13 Mar 2002 16:43:12 -0800 Subject: Logging of client commands, possible? References: <13e98213e191.13e19113e982@a1.net> <20020312231847.C28682@folly> Message-ID: <002b01c1caf1$3896f1b0$1701000a@effugas> > i'd like to capture unencrypted ssh packets in > pcap format, just like openbsd's isakmpd does. > and add support to tcpdump and etherreal for > interpreting these packet, this would make > debugging simpler. isakmpd can do this probably because it's linked so deeply with the OS and the kernel; sshd never actually sees the raw packets and we probably don't want to complete the engineering effort to let it. It ain't unimaginable -- libpcap is a decently portable and usable library, and we'd simply have to set it to sniff for packets sent to the appropriate host involving the randomly selected local port number. However, we certainly wouldn't want to put this dependancy in generic builds of SSH. Here's the code segments to add. You probably want to fork off the sniffer. I do note this is useless for us Cygwin types (oh what I would do for libpcap to work right under Win32 *sigh*). #include pcap_t *pcap; /* PCAP descriptor */ u_char *packet; /* Our newly captured packet */ struct pcap_pkthdr pkthdr; /* PCAP packet information structure */ struct bpf_program fp; /* Structure to hold the compiled prog */ char pfprogram[255]; char dev[255]; int immediate = 1; int promisc = 1; /* set default interface to sniff on */ snprintf(dev, sizeof(dev), "%s", pcap_lookupdev(NULL)); /* create sniffer rule */ snprintf(pfprogram, sizeof(pfprogram), "host %s and port %i", host, local_port); /* Begin sniffing...fork here if ya like */ pcap = pcap_open_live(dev, 65535, promisc, 5, NULL); if (pcap == NULL) { perror("pcap_open_live"); exit(EXIT_FAILURE); } if (ioctl(pcap_fileno(pcap), BIOCIMMEDIATE, &immediate)) { //perror("Couldn't set BPF to Immediate Mode."); } /* Compile and set the filter program */ if (pcap_compile(pcap, &fp, pfprogram, 1, 0x0) == -1) { pcap_perror(pcap, "pcap_compile"); exit(EXIT_FAILURE); } if (pcap_setfilter(pcap, &fp) == -1) { pcap_perror(pcap, "pcap_setfilter"); exit(EXIT_FAILURE); } /* Get the next packet from the queue, */ while (1) { packet = (u_char *) pcap_next(pcap, &pkthdr); // do something with each packet, save to disk or parse or whatever. } Another approach is the ssldump method of using access to the private key to drive the parser in a custom tcpdump variant; this doesn't work too well in SSH because we actually have some forward secrecy to speak of :-) We'd need to find a way to allow the session key to be dumped, probably with an escape sequence feeding into the base64 encoder function. Launch the sniffer w/ that key as an argument and it'd be able to parse encrypted sessions. Honestly though, best approach is just to support -c none as a compile time switch, and justify it on the basis that it lets us better search for slow corruption attacks *without* cipher armoring... --Dan From bugzilla-daemon at mindrot.org Wed Mar 13 12:38:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 12:38:22 +1100 (EST) Subject: [Bug 159] Password-Authentication with openssh-3.1p1 fails Message-ID: <20020313013822.A9204E99D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=159 ------- Additional Comments From jason at rndpkt.org 2002-03-13 12:38 ------- Can you please publish your /etc/pam.d/sshd file here? It sounds like the pam stack is either not finding the sshd file or else there's an error within the file. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 13 12:41:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 12:41:35 +1100 (EST) Subject: [Bug 159] Password-Authentication with openssh-3.1p1 fails Message-ID: <20020313014135.79326E9A7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=159 ------- Additional Comments From jason at rndpkt.org 2002-03-13 12:41 ------- Oops... didn't see it your earlier post. Please try the following for your /etc/pam.d/sshd and see if it resolves the problem: #%PAM-1.0 auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From abhi at acc.com Wed Mar 13 13:03:21 2002 From: abhi at acc.com (Abhijeet Thakare) Date: Tue, 12 Mar 2002 18:03:21 -0800 Subject: Use of Server's Private Key In-Reply-To: <20020312225411.B28682@folly> Message-ID: Hi, I only find this information in SSH1 draft. SSH2 draft does not specify the use of server's private keys as SSH1 draft. So how do we use server's private keys with ssh2 client and ssh2 server. Thanks, Abhijeet -----Original Message----- From: Markus Friedl [mailto:markus at openbsd.org] Sent: Tuesday, March 12, 2002 1:54 PM To: Abhijeet Thakare Cc: Openssh-Unix-Dev at Mindrot. Org Subject: Re: Use of Private Keys On Mon, Mar 11, 2002 at 01:29:57PM -0800, Abhijeet Thakare wrote: > I am not able to figure out where/how we are using the server's private key? man sshd: Whenever a client connects the daemon responds with its public host and server keys. The client compares the RSA host key against its own database to verify that it has not changed. The client then generates a 256 bit random number. It encrypts this random number using both the host key and the server key, and sends the encrypted number to the serv- er. ... the server uses its private key to prove its indentity to the connecting user. From macrosoft at 263.net Wed Mar 13 13:06:35 2002 From: macrosoft at 263.net (Ãûɽ´ó´¨) Date: Wed, 13 Mar 2002 10:06:35 +0800 (CST) Subject: =?gb2312?B?c2NwIGNhbid0IHJ1biBhZnRlciBhZGRpbmcgYXV0aGVudGljYXRpb24gbWV0aG9k?= Message-ID: <3C8EB42B.000037.02179@mta2> I have add an authentication method to openSSH, I call it ICCAuthentication, much like RSAAuthentication, but the RSA private key is in the IC card. I did not change any source code of scp. I mean scp.c. I set all authentication methods to "no" in sshd_config but ICCAuthentication yes. ssh works very well with this authentication method. But scp is not good with it. scp always run_err() in the following context in scp.c: void sink(argc, argv) { .... ..... if(first){ run_err("%s",cp); exit(1); } ...... ...... } That means that "first" is always true. What does "sink" mean anyway ? Why ? Thanks. __________________________________________ ?????????????????????(http://mail.263.net/mmail/index.html) ????????95963??????????(http://www.263.net/0ji/StarDialer.exe) ????????????????(http://95963.263.net/) ??????????,????????(http://shopping.263.net/class004.htm) From carson at taltos.org Wed Mar 13 13:13:47 2002 From: carson at taltos.org (Carson Gaspar) Date: Tue, 12 Mar 2002 21:13:47 -0500 Subject: problem with environment detecting In-Reply-To: <200203120423.g2C4Ntgj031306@frtk-campus-gw.mipt.ru> References: <200203120423.g2C4Ntgj031306@frtk-campus-gw.mipt.ru> Message-ID: <282809437.1015967627@[192.168.0.1]> ssh host 'echo foo' invokes shell -c 'echo foo' under the covers. Under most shells, the login environment will _not_ be sourced. ssh host invokes -shell The magic leading - in ARGV[0] causes the shell to read it's login environment. This is the same behaviour as rsh/rlogin. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From djm at mindrot.org Wed Mar 13 14:11:43 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Mar 2002 14:11:43 +1100 (EST) Subject: sys/queue.h In-Reply-To: Message-ID: On Mon, 11 Mar 2002, Kevin Steves wrote: > removes HAVE_BOGUS_SYS_QUEUE_H and always use our queue.h. ok? Yes, but let's call it bsd-queue.h or something. It is not fake. -d From djm at mindrot.org Wed Mar 13 14:13:07 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Mar 2002 14:13:07 +1100 (EST) Subject: patch for password expiration under Solaris? In-Reply-To: <20020311220407.A3430@red-sonja.frakir.org> Message-ID: On Mon, 11 Mar 2002, Mordechai T. Abzug wrote: > > I'm looking to move some Solaris 2.6 and 7 machines to openssh. > Showstopper bug: openssh (up to 3.1p1) doesn't seem to correctly > implement expired passwords. If you build with --with-pam it does. -d From djm at mindrot.org Wed Mar 13 14:17:03 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Mar 2002 14:17:03 +1100 (EST) Subject: Logging of client commands, possible? In-Reply-To: <13e98213e191.13e19113e982@a1.net> Message-ID: On Tue, 12 Mar 2002, RGiersig at a1.net wrote: > So I'll summarize my wishes: per-connection logging of what gets sent > from the client to the server. When a connection gets accepted, a > logfile is created in a logdir whose filename contains a timestamp, pid > of the sshd process that handles the connection, if a terminal is > requested, authenticated user name and hostname from where the > connection came. If the session uses a tty, a timestamp is written > periodically to the logfile (once a minute) to give an indication what > happened when. X forwarding could be logged the same way, as well as > other forwarded ports. > > Anybody from the openssh developer team reading this? I won't speak for the others, but I don't want to turn OpenSSH into snoopware. All the more so if the snopping is going not going to be effective (e.g. whiterabbit.sh, whiterabbit.bin). -d From djm at mindrot.org Wed Mar 13 14:19:12 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Mar 2002 14:19:12 +1100 (EST) Subject: Does OpenSSH 3.x support KRB5 directly? In-Reply-To: <1015956633.20431.5.camel@UberGeek> Message-ID: On 12 Mar 2002, Austin Gonyou wrote: > Ok..I'm sorry I'm so dumb..but autoreconf just returns to a prompt..and > no configure is created. Can autoconf be used to create the configure? > If so, what file can I symlink to configure.in. Make sure you use autoconf >= 2.52 -d From djm at mindrot.org Wed Mar 13 14:20:18 2002 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Mar 2002 14:20:18 +1100 (EST) Subject: error compiling openssh-3.1p1 under SCO OpenServer 5.0.5 In-Reply-To: <1015956899.16560.30.camel@benway.cv.telegroup.com> Message-ID: On 12 Mar 2002, Aran Cox wrote: Please check bugzilla before posting: http://bugzilla.mindrot.org/show_bug.cgi?id=138 From bugzilla-daemon at mindrot.org Wed Mar 13 15:07:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 15:07:55 +1100 (EST) Subject: [Bug 162] New: Tunneling of ssh over ssh seems broken Message-ID: <20020313040755.32A5BE930@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=162 Summary: Tunneling of ssh over ssh seems broken Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jl at itu.dk Hi, This is for 3.1p2, but it is not in Bugzilla version system yet! The last many years I have been tunneling ssh through ssh. What I do is to ssh to a special port on my localhost. This port is then (using ssh :-) ) forwarded to a remote ssh server. This has worked perfect for a long time! Until my upgrade to 3.1p2 the ssh1 system correctly asked the remote server at the end of the line for a name (and a host key). The remote server name was the key in the host table. Now, however, ssh saves the key under localhost!!! This is really uncool since I easily run five tunnels to five different remote servers (on five local port no's), so...... Whoever changed it.... Is this a bug, or am I using ssh in the wrong way! Thanks, - Jakob Lichtenberg ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Wed Mar 13 13:35:23 2002 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 12 Mar 2002 18:35:23 -0800 (PST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: On Thu, 7 Mar 2002, Matt Studley wrote: :has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? :That release of Solaris was the first (I believe) to incorporate their own :/dev/random which OpenSSH 3.1 doesn't seem to like too much. I don't see a /dev/random driver on Solaris 8 2/02, and can't find any mention in the release documentation. From fcusack at fcusack.com Wed Mar 13 15:35:31 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 12 Mar 2002 20:35:31 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: ; from stevesk@pobox.com on Tue, Mar 12, 2002 at 06:35:23PM -0800 References: Message-ID: <20020312203531.V3349@google.com> On Tue, Mar 12, 2002 at 06:35:23PM -0800, Kevin Steves wrote: > On Thu, 7 Mar 2002, Matt Studley wrote: > :has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? > :That release of Solaris was the first (I believe) to incorporate their own > :/dev/random which OpenSSH 3.1 doesn't seem to like too much. > > I don't see a /dev/random driver on Solaris 8 2/02, and can't find any > mention in the release documentation. It's in SUNWski, do you have that installed? /dev/random is a fifo in SUNWski (created at boot time). I dunno about Solaris 8 02/02, but SUNWski was previously available unbundled for 2.6+, but only for 32-bit. /fc From AErickson at resumeauthor.com Wed Mar 13 15:41:28 2002 From: AErickson at resumeauthor.com (Adam Erickson) Date: Tue, 12 Mar 2002 23:41:28 -0500 Subject: Career Oportunities Message-ID: <200203130442.g2D4gNr11420@chmls06.mediaone.net> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020312/843f7e85/attachment.html From paul.l.allen at boeing.com Wed Mar 13 16:50:35 2002 From: paul.l.allen at boeing.com (Paul Allen) Date: Tue, 12 Mar 2002 21:50:35 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random References: <20020312203531.V3349@google.com> Message-ID: <3C8EE8AB.DDA336BA@boeing.com> Frank Cusack wrote: > > On Tue, Mar 12, 2002 at 06:35:23PM -0800, Kevin Steves wrote: > > On Thu, 7 Mar 2002, Matt Studley wrote: > > :has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? > > :That release of Solaris was the first (I believe) to incorporate their own > > :/dev/random which OpenSSH 3.1 doesn't seem to like too much. > > > > I don't see a /dev/random driver on Solaris 8 2/02, and can't find any > > mention in the release documentation. > > It's in SUNWski, do you have that installed? /dev/random is a fifo in > SUNWski (created at boot time). SUNWski was part of the web server product that was bundled with the server versions of Solaris 2.6 and Solaris 7. It was not on the regular install CD. You had to rummage around on the CD with all the extra software to find it and install it manually. You can also download it as part of a patch from SunSolve, if you have such access. Just search for "SUNWski". (Note that it's been over a year since I checked this fact!) > I dunno about Solaris 8 02/02, but SUNWski was previously available > unbundled for 2.6+, but only for 32-bit. Sun discontinued their web server with Solaris 8, so SUNWski disappeared. The one from the Solaris 7 media pack worked fine on all the Solaris 8 boxes I tried it on. These were mostly Ultra 5 and 10 machines. 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 bugzilla-daemon at mindrot.org Wed Mar 13 19:38:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 19:38:59 +1100 (EST) Subject: [Bug 159] Password-Authentication with openssh-3.1p1 fails Message-ID: <20020313083859.7CC3FEA39@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=159 ------- Additional Comments From fam.muck at telda.net 2002-03-13 19:38 ------- Well, it seems I'm out of luck. pam_stack.so is not included in my pam- distribution (SuSE Linux) and I'm not able to find the source in the net except in RedHat-Distributions. But I don't want to rotate my pam-system with pam from another Linux-distribution - maybe after such an "update" openssh works, but many other applications do not so :-) SuSE and RedHat pam-stacks differ in many points. But why do you mean, pam could not find the sshd binary? The identical stack worked fine with my previous openssh-version and I didn't change any file- locations. sshd resides in /usr/sbin/ before and after the update. And the logs seem to say that communication between sshd and pam works as it should. pam_unix2.so recognizes a wrong password but (of course) you can be sure I use the correct password! I'm not a professional but I would think sshd passes a wrong password to pam (or why should pam detect a wrong password when I type the correct one?). Very strange things seem to happen. Andreas ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Wed Mar 13 19:47:43 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 13 Mar 2002 09:47:43 +0100 Subject: Logging of client commands, possible? In-Reply-To: References: <13e98213e191.13e19113e982@a1.net> Message-ID: <20020313084743.GC29625@faui02> On Wed, Mar 13, 2002 at 02:17:03PM +1100, Damien Miller wrote: > > Anybody from the openssh developer team reading this? > > I won't speak for the others, but I don't want to turn OpenSSH into > snoopware. All the more so if the snopping is going not going to be > effective (e.g. whiterabbit.sh, whiterabbit.bin). I agree with Damien here. I'm just interested in the plaintext for debugging the protocol implementation. It's not OpenSSH's job to spy the users. From bugzilla-daemon at mindrot.org Wed Mar 13 20:07:40 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 13 Mar 2002 20:07:40 +1100 (EST) Subject: [Bug 162] Tunneling of ssh over ssh seems broken Message-ID: <20020313090740.2FDD8EA4B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=162 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-03-13 20:07 ------- the pre-3.x behaviour can be restored with this option: NoHostAuthenticationForLocalhost This option can be used if the home directory is shared across machines. In this case localhost will refer to a different ma- chine on each of the machines and the user will get many warnings about changed host keys. However, this option disables host au- thentication for localhost. The argument to this keyword must be ``yes'' or ``no''. The default is to check the host key for lo- calhost. however, the use of HostKeyAlias is recommended ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Wed Mar 13 21:18:38 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 13 Mar 2002 02:18:38 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: <3C8EE8AB.DDA336BA@boeing.com>; from paul.l.allen@boeing.com on Tue, Mar 12, 2002 at 09:50:35PM -0800 References: <20020312203531.V3349@google.com> <3C8EE8AB.DDA336BA@boeing.com> Message-ID: <20020313021837.A7032@google.com> On Tue, Mar 12, 2002 at 09:50:35PM -0800, Paul Allen wrote: > Frank Cusack wrote: > > Sun discontinued their web server with Solaris 8, so SUNWski > disappeared. > The one from the Solaris 7 media pack worked fine on all the Solaris 8 > boxes I tried it on. These were mostly Ultra 5 and 10 machines. Right, but only in 32-bit. I found ANDIrand to be good. I was under the impression that in Sol 8 02/02, there is again a SUNWski package, now supporting 64-bit. A doc on the matter (sunsolve 27606) says to install SUNWski but that /dev/random will be back in Sol. 9. The doc has a pointer to ANDIrand. /fc From fcusack at fcusack.com Wed Mar 13 21:31:03 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Wed, 13 Mar 2002 02:31:03 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: <3C8EE8AB.DDA336BA@boeing.com>; from paul.l.allen@boeing.com on Tue, Mar 12, 2002 at 09:50:35PM -0800 References: <20020312203531.V3349@google.com> <3C8EE8AB.DDA336BA@boeing.com> Message-ID: <20020313023102.B7032@google.com> BTW, I may as well post it, you can get SUNWski here: - 105710-01 (sparc, intl, free), - 106754-01 (sparc, us, free), - 106755-01 (x86, intl, free), or - 106756-01 (x86, us, contract only). The intl/us refs are because the patches are for the Sun webserver products, of which there are different SSL key strengths across versions, I imagine. I wouldn't think the SUNWski package is affected by that difference, though. You'll have to extract the package from the patch (not difficult). /fc From skmike1289 at hotmail.com Wed Mar 13 22:18:54 2002 From: skmike1289 at hotmail.com (rmgrmike) Date: Wed, 13 Mar 2002 03:18:54 -0800 Subject: What's the scoop? svbgm Message-ID: <20020313112708.65FF5E8EA@shitei.mindrot.org> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020313/2684cc8a/attachment.html From frank.winkler at germany.sun.com Thu Mar 14 00:17:19 2002 From: frank.winkler at germany.sun.com (Frank Winkler) Date: Wed, 13 Mar 2002 14:17:19 +0100 Subject: OpenSSH - configure Message-ID: <3C8F515F.34D8A8A9@germany.sun.com> Hi there ! I'm just building OpenSSH 3.1 and just found out that the 'configure' script seems to have the same bug as the one provided with 3.0.1: the resulting Makefile has a wrong entry in the include list (.../lib instead of .../include). Looking at the prefix, I suppose this is caused by either '--with-zlib' or '--with-ssl-dir' but I didn't check this in detail yet. After correcting this, the code compiles without problems :) ... Can anybody confirm this behavior? Regards -- --------------------------------------------------------------------------- Frank Winkler frank.winkler at germany.sun.com Sun Microsystems - Remote Admin Center Sonnenallee 1 Voice +49 89 46008.2755 85551 Heimstetten - Germany Fax +49 89 46008.2740 From RGiersig at a1.net Thu Mar 14 00:37:25 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Wed, 13 Mar 2002 14:37:25 +0100 Subject: Logging of client commands, possible? Message-ID: <182771ec14.1ec1418277@a1.net> > > i'd like to capture unencrypted ssh packets in > > pcap format, just like openbsd's isakmpd does. > > and add support to tcpdump and etherreal for > > interpreting these packet, this would make > > debugging simpler. > > isakmpd can do this probably because it's linked so deeply with > the OS and the kernel; sshd never actually sees the raw packets > and we probably don't want to complete the engineering effort > to let it. I think you misunderstood this. Markus is just proposing a dump format, which IMHO makes perfect sense. After decrypting the packet it gets dumped in the same format that tcpdump is using, so you then can use 'tcpdump -r dumpfile' to display it. Did I get that right? Roland -- RGiersig at cpan.org From RGiersig at a1.net Thu Mar 14 00:51:16 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Wed, 13 Mar 2002 14:51:16 +0100 Subject: Logging of client commands, possible? Message-ID: <1b8991b729.1b7291b899@a1.net> > > I won't speak for the others, but I don't want to turn OpenSSH into > > snoopware. All the more so if the snopping is going not going to be > > effective (e.g. whiterabbit.sh, whiterabbit.bin). > > I agree with Damien here. > > I'm just interested in the plaintext for debugging the protocol > implementation. It's not OpenSSH's job to spy the users. Well, that's a matter of usage, not technical capability. Most tools can be used for both good and bad. How about amending the startup protocol to tell the client "This session will be logged."? Apart from that, SSHs job is to secure communication *between* hosts, not what is going on inside. An evil admin can still add some sort of snooping, e.g. by modifying/wrapping the user's shell, so IMHO it doesn't make sense to take a holier-than-you stance on this issue. Knifes are much too useful for cutting your lunch meat to be abolished because you can stab people with them. And I see SSH as a swiss army knife. Now *firearms* are a different matter... Roland -- RGiersig at cpan.org From mjs at ams.org Thu Mar 14 00:54:51 2002 From: mjs at ams.org (Matt Studley) Date: Wed, 13 Mar 2002 08:54:51 -0500 (EST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: One does exist with that release. In /etc/init.d there is the cryptorand script which creates the device when run. Take a look at /usr/lib/security/cryptorand. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Tue, 12 Mar 2002, Kevin Steves wrote: > On Thu, 7 Mar 2002, Matt Studley wrote: > :has anyone had a problem building 3.1p1 with Solaris 8 (2/02 release)? > :That release of Solaris was the first (I believe) to incorporate their own > :/dev/random which OpenSSH 3.1 doesn't seem to like too much. > > I don't see a /dev/random driver on Solaris 8 2/02, and can't find any > mention in the release documentation. > From dan at doxpara.com Fri Mar 15 01:00:07 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 14 Mar 2002 06:00:07 -0800 Subject: Logging of client commands, possible? References: <182771ec14.1ec1418277@a1.net> Message-ID: <00a301c1cb60$8c739ad0$1701000a@effugas> > I think you misunderstood this. Markus is just proposing a dump > format, which IMHO makes perfect sense. After decrypting the packet it > gets dumped in the same format that tcpdump is using, so you then can > use 'tcpdump -r dumpfile' to display it. Did I get that right? tcpdump parses packet headers(IP, TCP, etc.) sshd just gets a reliable socket to suck data from. It doesn't decrypt packets, it decrypts the datastream off the socket, whether it's coming from packets or not. That's why we can do something like: ssh -o "ProxyCommand sshd -i" user at host what are you suggesting, faking packet headers? :-) --Dan From markus at openbsd.org Thu Mar 14 00:59:13 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 13 Mar 2002 14:59:13 +0100 Subject: Logging of client commands, possible? In-Reply-To: <1b8991b729.1b7291b899@a1.net> References: <1b8991b729.1b7291b899@a1.net> Message-ID: <20020313135913.GA15104@faui02> On Wed, Mar 13, 2002 at 02:51:16PM +0100, RGiersig at a1.net wrote: > Apart from that, SSHs job is to secure communication *between* hosts, > not what is going on inside. Yes, you are right. And because SSH does not care about what's going on inside it does not snoop ttys. On Unix, tools should do _one_ thing and do it well, not 1000 things is a very mediocre way. From dan at doxpara.com Fri Mar 15 01:38:32 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 14 Mar 2002 06:38:32 -0800 Subject: Logging of client commands, possible? References: <1b8991b729.1b7291b899@a1.net> <20020313135913.GA15104@faui02> Message-ID: <00b301c1cb65$ea21e5b0$1701000a@effugas> > Yes, you are right. > > And because SSH does not care about what's going on inside it does > not snoop ttys. On Unix, tools should do _one_ thing and do it well, not > 1000 things is a very mediocre way. Markus, If I wanted one tool to do one thing, I'd use Telnet over SSL. :-) OpenSSH is *all* about the integration of generic encapsulators into a common tool. In this case, we'd be integrating a cross platform method to encapsulate TTY logging methods, as an alternative to painful, non-portable solutions. OpenSSH is already providing TTY services; logging functionality is all over the place in TTY tools(script, most GUI telnet clients, etc.) This ain't a big jump; in fact I'd be surprised if it's more than a few dozen lines of code to diff in. A *really* nice aspect of friendly TTY logs(we'll leave attacker-logs to the SAR reports, though I doubt there's any disagreement that TTY logs would supplement SAR's by helping filter out innocent traffic) is that they'd automatically drop whatever didn't show up on the TTY, i.e. typed passwords. That would make captured logs an order of magnitude less security sensitive -- big win. I *very* much see the wisdom in your nervousness. Spyware is certainly not something SSH should be. But spyware sends your data to someone else -- security monitoring retains your own data for your own future analysis. This isn't a small distinction. Every DRM system in existance is based on the concept that your computer should do something for someone else instead of you. Every firewall in existance is based on the concept that your network should behave how you wish it to, no matter what anyone else wants. The latter is compatible with base concepts of property(that which is mine ought not betray me); the former violates those concepts with abandon. I posit that the administrator of an SSH daemon is presumed to have the right to view all data that passes over it. They're administering the cryptographic keys, it's their property(or they've been granted legitimate access to control it), and possibly their job if somebody breaks something. Obfuscating access to that data because we think other people might not want their limited contribution to be abused in some arbitrary way -- sound familiar? That's just another DRM applying security through obscurity, and I think we can both agree that StO ain't the philosophy of OpenSSH. A compelling argument against integrating this form of logging is that it's more likely to be hacked onto a server than it is legitimately deployed. My response would be that hackers have more interesting tools to play with, and the fact that I've had to point administrators at hacker tools is a bit embarassing. It'd be like if VNC didn't exist and entire networks were managed with BackOrifice :-) A more compelling argument is that administrators don't necessarily have the right to monitor their own servers. Certainly, it'd be unethical to monitor the desktop of an employee -- as a couple federal judges have started to note. But production machines are usually systems with very stringent rules about who should be changing what and what kind of backoff plans need to be in place first; certainly there's a legitimate place for this kind of monitoring and I'm not sure it's fair to make the policy statement that the illegitimate abuses override all possible legitimate uses. Thoughts? I definitely see your perspectives on this...perhaps we can limit abuses by making this a compile time option? Mind you, I *hate* compile time options, but we could at least throw up a banner referencing ECPA1986 if it was enabled. --Dan From RGiersig at a1.net Thu Mar 14 01:38:39 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Wed, 13 Mar 2002 15:38:39 +0100 Subject: Logging of client commands, possible? Message-ID: <200851fe33.1fe3320085@a1.net> > > Apart from that, SSHs job is to secure communication *between* > > hosts, not what is going on inside. > > Yes, you are right. > > And because SSH does not care about what's going on inside it does > not snoop ttys. On Unix, tools should do _one_ thing and do it > well, not 1000 things is a very mediocre way. I'll word that differently in that I'd say "tools should solve *one* problem". SSH does a *lot* of very different things, forwarding X displays, propagating tty settings and signals, to name a few. You are right, I could write a tty snooping app that interposes itself between SSH and a shell, but this app would have to deal with tty and signal forwarding, just as SSH, so I would steal the work already done in SSH, strip out the network part and put in logging instead. Probably 80% of the code would be shared with SSH. So why not inserting the logging into SSH in the first place? Makes sense? Roland -- RGiersig at cpan.org From RGiersig at a1.net Thu Mar 14 01:52:23 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Wed, 13 Mar 2002 15:52:23 +0100 Subject: Logging of client commands, possible? Message-ID: <21dba217ad.217ad21dba@a1.net> > > Did I get that right? > > tcpdump parses packet headers(IP, TCP, etc.) ... > what are you suggesting, faking packet headers? :-) Sorry, got it the wrong way around, SSL is doing the encryption, of course, stupid me. Mixed up the protocol layers... Roland -- RGiersig at cpan.org From RGiersig at a1.net Thu Mar 14 02:15:41 2002 From: RGiersig at a1.net (RGiersig at a1.net) Date: Wed, 13 Mar 2002 16:15:41 +0100 Subject: Logging of client commands, possible? Message-ID: <20be422933.2293320be4@a1.net> > OpenSSH is already providing TTY services; logging > functionality is all over the place in TTY tools(script, > most GUI telnet clients, etc.) This ain't a big jump; > in fact I'd be surprised if it's more than a few > dozen lines of code to diff in. Oh yeah, didn't think about that, the SSH client is also missing logging facilities (like xterm and telnet). > A *really* nice aspect of friendly TTY logs (we'll leave > attacker-logs to the SAR reports, though I doubt there's any > disagreement that TTY logs would supplement SAR's by helping > filter out innocent traffic) is that they'd automatically drop > whatever didn't show up on the TTY, i.e. typed passwords. > That would make captured logs an order of magnitude less security > sensitive -- big win. Hmm, turning off logging when the pty is set to -echo? Nice idea, but I'd definitely would make that optional so the admin still can specify: "I want all, I might have to deal with black hats" or "OK, I just want to see what trusted users are doing and if they are doing something fishy". If a trusted user does the whole session with -echo, that's definitely finshy... > ... > Thoughts? I definitely see your perspectives on > this... perhaps we can limit abuses by making this a > compile time option? Mind you, I *hate* compile time > options, but we could at least throw up a banner > referencing ECPA1986 if it was enabled. No, please, no compile-time options!! I'd propose amending the connection protocol so the client can display a warning like "WARNING! This connection will be logged on the server side. Do you still want to connect? (Y/N)", but then you need some way to always answer 'yes' to that for automatisation purposes etc. You could store that as an option with the hostkeys... Roland -- RGiersig at cpan.org From marc.fournier at acadiau.ca Thu Mar 14 02:23:49 2002 From: marc.fournier at acadiau.ca (Marc G. Fournier) Date: Wed, 13 Mar 2002 11:23:49 -0400 (AST) Subject: 3.1p1 under Solaris x86 5.7 fails to compile ... Message-ID: <20020313112308.U308-100000@atelier.acadiau.ca> file missing? (cd openbsd-compat && make) make[1]: Entering directory `/usr/local/src/openssh-3.1p1/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/openssh-3.1p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/slocal/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/slocal/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/slocal/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/slocal/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/slocal/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 Marc G. Fournier marc.fournier at acadiau.ca Senior Systems Administrator Acadia University "These are my opinions, which are not necessarily shared by my employer" From stevesk at pobox.com Thu Mar 14 02:37:34 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 13 Mar 2002 07:37:34 -0800 (PST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: On Wed, 13 Mar 2002, Matt Studley wrote: :One does exist with that release. In /etc/init.d there is the cryptorand :script which creates the device when run. Take a look at :/usr/lib/security/cryptorand. I don't see either of those. Perhaps because I installed Developer System Support 64-bit vs. the entire distribution? Are there release notes that refer to this? I didn't find anything on docs.sun.com. From bugzilla-daemon at mindrot.org Thu Mar 14 02:53:39 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 02:53:39 +1100 (EST) Subject: [Bug 163] New: /dev/random not used Message-ID: <20020313155339.92008EA7E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=163 Summary: /dev/random not used Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: critical Priority: P1 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: geek+openssh at cmu.edu Solaris8 with SUNWski installed (provides /dev/random). Symptom: "./configure --with-random=/dev/random" yields checking whether OpenSSL's headers match the library... yes checking whether OpenSSL's PRNG is internally seeded... no configure: WARNING: *** Forcing use of OpenSSL's non-self-seeding PRNG Checking the configure script, it no longer accepts --with-random, and doesn't check /dev/random (or /dev/urandom for that matter). The INSTALL file still indicates that this should work. I attempted to work around the problem with "--with-prngd-socket=/dev/random" to no avail. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Mar 14 02:44:12 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 13 Mar 2002 07:44:12 -0800 (PST) Subject: Unable to compile openssh on HP-UX 11 In-Reply-To: <3DCD5E22BC2DD511BED100D0B7E3AD17025C2274@L47XDTO1.publix.com> Message-ID: On Wed, 13 Mar 2002, Charles Straubel wrote: :I am trying to build openssh on an HP-UX 11.0 machine. I have installed :zlib 1.1.3, openssl 0.9.5a and Perl 5.6.0. :syntax error in file ./mdoc2man.pl at line 39, next 2 tokens "use strict" : :syntax error in file ./mdoc2man.pl at line 73, next 2 tokens "ParseMacro(" : :syntax error in file ./mdoc2man.pl at line 82, next 2 tokens "my (" : :syntax error in file ./mdoc2man.pl at line 452, next 2 tokens "my $tmp " : :Execution of ./mdoc2man.pl aborted due to compilation errors. : :*** Error exit code 255 it seems your perl is wrong. my guess is configure found /usr/contrib/bin/perl which won't work. also, for HP-UX users: "Building and Installing OpenSSH on HP-UX" http://www.atomicgears.com/papers/osshhpux.html From mjs at ams.org Thu Mar 14 02:52:22 2002 From: mjs at ams.org (Matt Studley) Date: Wed, 13 Mar 2002 10:52:22 -0500 (EST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: Message-ID: That could be the problem. I'm not sure whether or not the SUNWski package is included with the Developer install, but it is included with 'full' install. If you do a pkginfo SUNWski does it return anything? Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Wed, 13 Mar 2002, Kevin Steves wrote: > On Wed, 13 Mar 2002, Matt Studley wrote: > :One does exist with that release. In /etc/init.d there is the cryptorand > :script which creates the device when run. Take a look at > :/usr/lib/security/cryptorand. > > I don't see either of those. Perhaps because I installed Developer System > Support 64-bit vs. the entire distribution? Are there release notes that > refer to this? I didn't find anything on docs.sun.com. > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From emsecrist at micron.com Thu Mar 14 04:01:30 2002 From: emsecrist at micron.com (emsecrist) Date: Wed, 13 Mar 2002 10:01:30 -0700 Subject: Problem with buildpkg.sh Message-ID: <9527E8B90F21D4118B8800508B6C011702A6519D@ntlex01.lehi.micron.com> I am attempting to successfully run the buildpkg.sh script which is located in the contrib/solaris directory. I am receiving the following error: Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from I have read the README, and the only step that I am unsure about is the first one. Excuse me if this is dumb question, but what is the CVS tree? When I attempt to run step #1, which is make -F Makefile.in distprep, I get an error. I am assuming since I don't know what the CVS tree is, that I am ok to skip this step. Any help would be greatly appreciated. From tim at multitalents.net Thu Mar 14 04:40:18 2002 From: tim at multitalents.net (Tim Rice) Date: Wed, 13 Mar 2002 09:40:18 -0800 (PST) Subject: Problem with buildpkg.sh In-Reply-To: <9527E8B90F21D4118B8800508B6C011702A6519D@ntlex01.lehi.micron.com> Message-ID: On Wed, 13 Mar 2002, emsecrist wrote: > I am attempting to successfully run the buildpkg.sh script which is located > in the contrib/solaris directory. I am receiving the following error: > > Building pkginfo file... > Building prototype file... > Building package.. > ## Building pkgmap from package prototype file. > ## Processing pkginfo file. > pkgmk: ERROR: parameter cannot be null > ## Packaging was not successful. Grab the updated buildpkg.sh from a current snapshot or check the archives for Subject: Re: Update to solaris package creation The new version that is now in CVS was posted to this list. If you don't want the new version, change tail -1 to tail -2 > pkgtrans: ERROR: unable to complete package transfer > - no packages were selected from > > > I have read the README, and the only step that I am unsure about is the > first one. Excuse me if this is dumb question, but what is the CVS tree? > When I attempt to run step #1, which is make -F Makefile.in distprep, I get > an error. I am assuming since I don't know what the CVS tree is, that I am > ok to skip this step. Any help would be greatly appreciated. If you are building from a tarball you can ignore step #1 -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Thu Mar 14 06:04:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 06:04:15 +1100 (EST) Subject: [Bug 164] New: X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020313190415.94451EA85@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 Summary: X-forwarding when connecting to an IPv6-enabled host doesn't work. Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: carljohan at kjellander.com When connecting to an IPv6-enabled host with X-forwarding enabled sshd on the other end only opens a tunnel on ::1:6010 (ip6-localhost) and not 127.0.0.1:6010 (ip4-localhost). Reproducible: Always Steps to reproduce: 1. Login to a host that supports both IPv4 and IPv6 with X-forwarding turned on. ssh -X user at ipv6host Actual result: Sshd on the host you connected to only opens forwarding of port 6010 (x11-ssh-offset) on ip6-localhost, ::1, and not ip4-localhost, 127.0.0.1 as seen here: [ipv6host]# netstat -l -n | grep 6010 tcp 0 0 ::1:6010 :::* LISTEN Expected result: Sshd should open forwarding at least 127.0.0.1, but preferably both 127.0.0.1 and ::1. On a ipv4-only host everything works ok: [ipv4onlyhost]# netstat -l -n | grep 6010 tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN I have only tested this on Linux but it may apply to other OSes as well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 14 06:17:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 06:17:42 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020313191742.8A226EA96@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From stevesk at pobox.com 2002-03-14 06:17 ------- can you provide sshd -d output? i want to see any debug messages from x11_create_display_inet(). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Thu Mar 14 05:19:40 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 13 Mar 2002 19:19:40 +0100 Subject: Use of Server's Private Key In-Reply-To: ; from abhi@acc.com on Tue, Mar 12, 2002 at 06:03:21PM -0800 References: <20020312225411.B28682@folly> Message-ID: <20020313191940.B30329@folly> On Tue, Mar 12, 2002 at 06:03:21PM -0800, Abhijeet Thakare wrote: > I only find this information in SSH1 draft. SSH2 draft does not specify the > use of server's private keys as SSH1 draft. So how do we use server's > private keys with ssh2 client and ssh2 server. see "Diffie-Hellman Key Exchange" in draft-ietf-secsh-transport-XX.txt From seabra at cyclades.com Thu Mar 14 06:54:57 2002 From: seabra at cyclades.com (Edson Ap. Seabra) Date: Wed, 13 Mar 2002 11:54:57 -0800 Subject: CrossCompiling Openssh. Message-ID: <3C8FAE90.D88A5D84@cyclades.com> Hi, I am trying to cross compile openssh-3.1p1 for PPC. I am using linux host Hard Hat 6.2. In this machine I could compile and install the openssh. When I run the configure enabling "cross compile" It gives the following error: checking for logwtmp... yes checking for strftime... yes checking for GLOB_ALTDIRFUNC support... yes checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... configure: error: c an not run test program while cross compiling This is the configure command that is issued from a Make file: CC=/opt/hardhat/devkit/ppc/8xx/bin/ppc_8xx-gcc RANLIB="/opt/hardhat/devkit/ppc/8 xx/bin/ppc_8xx-ranlib" AR="/opt/hardhat/devkit/ppc/8xx/bin/ppc_8xx-ar" LD="/opt/ hardhat/devkit/ppc/8xx/bin/ppc_8xx-gcc" NM="/opt/hardhat/devkit/ppc/8xx/bin/ppc_ 8xx-nm" STRIP="/opt/hardhat/devkit/ppc/8xx/bin/ppc_8xx-strip --remove-section=.n ote --remove-section=.comment" OBJCOPY="/opt/hardhat/devkit/ppc/8xx/bin/ppc_8xx- objcopy" OBJDUMP="/opt/hardhat/devkit/ppc/8xx/bin/ppc_8xx-objdump" MAKE="make" \ ./configure --prefix=/ \ --sysconfdir=/etc/ssh \ --with-ssl-dir=/home/edson/tslinux/openssl \ --with-openssl-src=/home/edson/tslinux/openssl \ --without-pam \ --disable-utmpx --disable-wtmpx \ --host=powerpc-hardhat-linux \ --build=powerpc-hardhat-linux \ --with-ldflags="-s" \ --with-cflags="" \ --with-random=/dev/urandom Any clue will be appreciated. Thanks in advance, Edson. From ewheeler at kaico.com Thu Mar 14 07:07:34 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Wed, 13 Mar 2002 12:07:34 -0800 (PST) Subject: zlib compression, the exploit, and OpenSSH Message-ID: Attached is a zlib advisory and a debug dump of ssh with compression enabled. Most of the debug is superflous, so I have underlined the two points to look at. When creating an ssh connection, compression on the line is done *before* authentication -- This means an unauthorized attacker could, conceivable, leverage root access by connecting with to the ssh server requesting zlib compression and sending a specialy tailored packet. The CERT advisory for zlib's bug is also attached. I would like to start a discussion on the following points: 1. What is the exposure to this bug? 2. What are the logistics of moving all non-critical external library calls (zlib in this case, but others if they exist) *after* authentication? 3. Does OpenSSH statically link (or can it/does it by default) to the zlib library -- will updating the zlib library to 1.1.4 take care of the situation? 4. Are there any proactive measures besides moving non-critical library calls after authentication which could be done within the OpenSSH code? Any input on this matter would be greatly appreciated. --Eric OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/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 501 geteuid 0 anon 1 debug1: Connecting to raid [63.105.24.128] port 22. debug1: temporarily_use_uid: 501/501 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 501/501 (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 /home/eric/.ssh/identity type 0 debug1: identity file /home/eric/.ssh/id_rsa type -1 debug1: identity file /home/eric/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_2.5.1p2 debug1: match: OpenSSH_2.5.1p2 pat ^OpenSSH_2\.5\.[012] Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 zlib debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 142/256 debug1: bits set: 1025/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'raid' is known and matches the DSA host key. debug1: Found key in /home/eric/.ssh/known_hosts2:1 debug1: bits set: 1077/2049 debug1: len 55 datafellows 49152 debug1: ssh_dss_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: Enabling compression at level 6. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ debug1: next auth method to try is publickey debug1: try privkey: /home/eric/.ssh/id_rsa debug1: try pubkey: /home/eric/.ssh/id_dsa debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8094f80 hint 2 debug1: read PEM private key done: type DSA debug1: sig size 20 20 debug1: ssh-userauth2 successful: method publickey debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug1: client_init id 0 arg 0 debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting authentication agent forwarding. debug1: channel request 0: shell debug1: channel 0: open confirm rwindow 0 rmax 16384 -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 ---------- Forwarded message ---------- Date: Tue, 12 Mar 2002 13:48:06 -0500 (EST) From: CERT Advisory To: cert-advisory at cert.org Subject: CERT Advisory CA-2002-07 Double Free Bug in zlib Compression Library -----BEGIN PGP SIGNED MESSAGE----- CERT Advisory CA-2002-07 Double Free Bug in zlib Compression Library Original release date: March 12, 2002 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Any software that is linked to zlib 1.1.3 or earlier may be affected * Data compression libraries derived from zlib 1.1.3 or earlier may contain a similar bug Overview There is a bug in the zlib compression library that may manifest itself as a vulnerability in programs that are linked with zlib. This may allow an attacker to conduct a denial-of-service attack, gather information, or execute arbitrary code. It is important to note that the CERT/CC has not received any reports of exploitation of this bug. Based on the information available to us at this time, it is difficult to determine whether this bug can be successfully exploited. However, given the widespread deployment of zlib, we have published this document as a proactive measure. I. Description There is a bug in the decompression algorithm used by the popular zlib compression library. If an attacker is able to pass a specially-crafted block of invalid compressed data to a program that includes zlib, the program's attempt to decompress the crafted data can cause the zlib routines to corrupt the internal data structures maintained by malloc. The bug results from a programming error that causes segments of dynamically allocated memory to be released more than once (i.e., "double-freed"). Specifically, when inftrees.c:huft_build() encounters the crafted data, it returns an unexpected Z_MEM_ERROR to inftrees.c:inflate_trees_dynamic(). When a subsequent call is made to infblock.c:inflate_blocks(), the inflate_blocks function tries to free an internal data structure a second time. Because this bug interferes with the proper allocation and deallocation of dynamic memory, it may be possible for an attacker to influence the operation of programs that include zlib. In most circumstances, this influence will be limited to denial of service or information leakage, but it is theoretically possible for an attacker to insert arbitrary code into a running program. This code would be executed with the permissions of the vulnerable program. The CERT/CC is tracking this issue as VU#368819. This reference number corresponds to CVE candidate CAN-2002-0059. II. Impact This bug may introduce vulnerabilities into any program that includes the affected library. Depending upon how and where the zlib routines are called from the given program, the resulting vulnerability may have one or more of the following impacts: denial of service, information leakage, or execution of arbitrary code. III. Solution Upgrade your version of zlib The maintainers of zlib have released version 1.1.4 to address this vulnerability. Upgrade any software that is linked to or derived from an earlier version of zlib. The latest version of zlib is available at http://www.zlib.org These are the MD5 checksums for zlib version 1.1.4: abc405d0bdd3ee22782d7aa20e440f08 zlib-1.1.4.tar.gz 9bf1d36ced334b0cf1f996f5c8171018 zlib114.zip Apply a patch from your vendor The zlib compression library is freely available and used by many vendors in a wide variety of applications. Any one of these applications may contain vulnerabilities that are introduced by this vulnerability. Appendix A contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Please contact your vendor directly. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Apple Computer, Inc. Mac OS X and Mac OS X Server do not contain this vulnerability. Compaq Computer Corporation COMPAQ COMPUTER CORPORATION ----------------------------- x-ref: SSRT0818 zlib At the time of writing this document, Compaq continues to evaluate this potential problem and impacts to Compaq released software. Compaq will implement solutions based on the conclusion of this evaluation as necessary. Compaq will provide notice of any new patches as a result any required solution through standard patch notification procedures and be available from your normal Compaq Services support channel. COMPAQ COMPUTER CORPORATION ----------------------------- Conectiva Linux Conectiva Linux supported versions (5.0, 5.1, 6.0, 7.0, ferramentas graficas and ecomerce) are affected by the zlib vulnerability. Updates will be sent to our security mailing lists and be available at our ftp site and mirrors. The updates will include a new version of zlib itself and also other packages which include their own version of zlib or are linked statically to the system-wide copy of zlib. Engarde EnGarde Secure Linux Community and Professional are both vulnerable to the zlib bugs. Guardian Digital addressed this vulnerability in ESA-20020311-008 which may be found at: http://www.linuxsecurity.com/advisories/other_advisory-1960.html EnGarde Secure Professional users may upgrade their systems using the Guardian Digital Secure Network. FreeBSD FreeBSD is not vulnerable, as the FreeBSD malloc implementation detects and complains about several programming errors including this kind of double free. Fujitsu Fujitsu's UXP/V operating system is not affected by the zlib vulnerability because it does not support zlib. Hewlett-Packard Company HP is not vulnerable. IBM Corporation IBM's AIX operating system, version 5.1, ships with open source-originated zlib that is used with the Redhat Package Manager (rpm) to install applications that are included in the AIX-Linux Affinity Toolkit. zlib (libz.a) is a shared library in AIX. AIX 5.1 is susceptible to the described vulnerability. AIX 4.3.x does not ship with zlib, but customers who install zlib and use it will be similarly vulnerable. IBM will make the patched version of zlib available as soon as it is made available to us. OpenBSD OpenBSD is not vulnerable as OpenBSD's malloc implementation detects double freeing of memory. The zlib shipped with OpenBSD has been fixed in OpenBSD-current in January 2002. Openwall GNU/*/Linux All versions of Openwall GNU/*/Linux (Owl) prior to the 2002/02/15 Owl-current snapshot are affected by the zlib double-free vulnerability. Owl-current after 2002/02/15 includes the proper fixes in its userland packages. In order to not place the users of other vendors' products at additional risk, we have agreed to delay documenting this as a security change and including the fixes in Owl 0.1-stable until there's a coordinated public announcement. While we don't normally support this kind of a policy (releasing a fix before there's an announcement), this time handling the vulnerability in this way was consistent with the state of things by the time the (already publicly known) bug was first realized to be a security vulnerability. The zlib bug could affect the following Owl packages: gnupg, openssh, rpm, texinfo (not necessarily in a security sense). Of these, the OpenSSH could potentially allow for an active remote attack resulting in a root compromise. If only SSH protocol version 1 is allowed in the OpenSSH server this is reduced to a local attack, but reverse remote attack possibilities by a malicious server remain. Additionally, any third-party software that makes use of the provided zlib library could be affected. Parts of the Linux 2.2 kernel included in Owl were also affected by the vulnerability. Fortunately, those parts (Deflate compression support for PPP and the experimental Deflate compression extension to IrDA) are normally not used by the Owl userland. The bug has been corrected starting with Linux 2.2.20-ow2 which has been made public and a part of both Owl-current and Owl 0.1-stable on 2002/03/03. This change, however, will only be documented in the publicly-available change logs on the coordinated public announcement date. Red Hat, Inc. Red Hat Linux ships with a zlib library that is vulnerable to this issue. Although most packages in Red Hat Linux use the shared zlib library we have identified a number of packages that either statically link to zlib or contain an internal version of the zlib code. Updates to zlib and these packages as well as our advisory note are available from the following URL. Users of the Red Hat Network can use the up2date tool to automatically upgrade their systems. http://www.redhat.com/support/errata/RHSA-2002-026.html Red Hat would like to thank CERT/CC for their help in coordinating this issue with other vendors. SGI SGI acknowledges the zlib vulnerabilities reported by CERT and is currently investigating. No further information is available at this time. For the protection of all our customers, SGI does not disclose, discuss or confirm vulnerabilities until a full investigation has occurred and any necessary patch(es) or release streams are available for all vulnerable and supported IRIX operating systems. Until SGI has more definitive information to provide, customers are encouraged to assume all security vulnerabilities as exploitable and take appropriate steps according to local site security policies and requirements. As further information becomes available, additional advisories will be issued via the normal SGI security information distribution methods including the wiretap mailing list on http://www.sgi.com/support/security/. XFree86 XFree86 versions 4.0 through 4.2.0 include zlib version 1.0.8. XFree86 3.x includes zlib version 1.0.4. The zlib code included with XFree86 is only used on some platforms. This is determined by the setting of HasZlib in the imake config files in the xc/config/cf source directory. If HasZlib is set to YES in the platform's vendor.cf file(s), then the system-provided zlib is used instead of the XFree86-provided version. XFree86 uses the system-provided zlib by default only on the following platforms: FreeBSD 2.2 and later NetBSD 1.2.2 and later OpenBSD Darwin Debian Linux The zlib code in XFree86 has been fixed in the CVS repository (trunk and the xf-4_2-branch branch) as of 14 February 2002. A source patch for XFree86 4.2.0 will be available from ftp://ftp.xfree86.org/pub/XFree86/4.2.0/fixes/. The following XFree86 4.2.0 binary distributions provided by XFree86 include and use a vulnerable version of zlib: Linux-alpha-glibc22 Linux-ix86-glibc22 When updated binaries are available, it'll be documented at http://www.xfree86.org/4.2.0/UPDATES.html. To check if an installation of XFree86 includes zlib, see if the following file exists: /usr/X11R6/lib/libz.a To check if an XFree86 X server is dynamically linked with zlib, look for a line containing 'libz' in the output of 'ldd /usr/X11R6/bin/XFree86'. Various vendors repackage and distribute XFree86, and may use settings and configurations different from those described here. zlib.org All users of zlib versions 1.1.3 or earlier should obtain the latest version, 1.1.4 or later, from http://www.zlib.org, in order to avoid this vulnerability as well as other possible vulnerabilities in versions prior to 1.1.3 when decompressing invalid data. Appendix B. - References * http://bugzilla.gnome.org/show_bug.cgi?id=70594 * http://www.kb.cert.org/vuls/id/368819 * http://www.libpng.org/pub/png/pngapps.html * http://www.redhat.com/support/errata/RHSA-2002-026.html _________________________________________________________________ The CERT/CC thanks Owen Taylor and Mark Cox of Red Hat, Inc. for reporting this vulnerability. We also thank Mark Adler of zlib.org for contributing to our research and Matthias Clasen for contributing to the discovery of this vulnerability. _________________________________________________________________ This document was written by Jeffrey P. Lanza. ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-2002-07.html ______________________________________________________________________ CERT/CC Contact Information Email: cert at cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo at cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 2002 Carnegie Mellon University. Revision History Mar 12, 2002: Initial release -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQCVAwUBPI5JsqCVPMXQI2HJAQFAvAP/f380BKQqJmAVsjL/482b86Mw8RL5k+Ov +ww1YfccKHTJdDlsqpIgX8LV59OII4KL31lAYrMrT2wJopY7wn7OSUvX7Z2aOLYE 0XQyjm5rT2mP9IKybBsHkXwHlTWZOi9iGnd9zSDndBgEaBifolcOh87z4zkE+noS OzDiRjPbg7s= =zhZM -----END PGP SIGNATURE----- From bugzilla-daemon at mindrot.org Thu Mar 14 08:25:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 08:25:26 +1100 (EST) Subject: [Bug 160] Race condition in clientloop.c? Message-ID: <20020313212526.4F3F5EAA9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=160 Nicolas.Williams at ubsw.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-14 08:25 ------- Aha! Yes, there is a race. It's there in 2.9p2, but apparently not in 3.0.2p1. Essentially the "if (compat20 && session_closed && !channel_still_open())" check at the top of the client loop is not close enough to the call to select() in client_wait_until_can_do_something(). In fact, client_wait_until_can_do_something() calls channel_prepare_select() which calls channel_handler() which may well call chan_is_dead() which may leave no channels open and yet client_wait_until_can_do_something() will still go into the select(). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nalin at redhat.com Thu Mar 14 08:23:59 2002 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 13 Mar 2002 16:23:59 -0500 Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: ; from ewheeler@kaico.com on Wed, Mar 13, 2002 at 12:07:34PM -0800 References: Message-ID: <20020313162359.B28344@redhat.com> On Wed, Mar 13, 2002 at 12:07:34PM -0800, ewheeler at kaico.com wrote: > 3. Does OpenSSH statically link (or can it/does it by default) to the > zlib library -- will updating the zlib library to 1.1.4 take care of the > situation? I can't speak to the rest of your questions, but because the portable tree doesn't bundle its own copy of zlib, OpenSSH links against the version installed on the system it's being compiled on. Usually that's a shared library if your OS has shared libraries, but it's going to be OS-specific. Nalin From djm at mindrot.org Thu Mar 14 08:29:55 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Mar 2002 08:29:55 +1100 (EST) Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: Message-ID: On Wed, 13 Mar 2002, ewheeler at kaico.com wrote: > Attached is a zlib advisory and a debug dump of ssh with compression > enabled. Most of the debug is superflous, so I have underlined the two > points to look at. When creating an ssh connection, compression on the > line is done *before* authentication -- This means an unauthorized > attacker could, conceivable, leverage root access by connecting with to > the ssh server requesting zlib compression and sending a specialy tailored > packet. The CERT advisory for zlib's bug is also attached. > > I would like to start a discussion on the following points: > > 1. What is the exposure to this bug? The vulnerability can be triggered, but whether this can be leveraged into an exploit remains to be seen. > 2. What are the logistics of moving all non-critical external library > calls (zlib in this case, but others if they exist) *after* > authentication? Not easy, what's "non-critical"? > 3. Does OpenSSH statically link (or can it/does it by default) to the > zlib library -- will updating the zlib library to 1.1.4 take care of the > situation? Depends on the system. > 4. Are there any proactive measures besides moving non-critical library > calls after authentication which could be done within the OpenSSH code? Work is underway to improve things: http://www.citi.umich.edu/u/provos/ssh/privsep.html -d From djm at mindrot.org Thu Mar 14 08:33:41 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Mar 2002 08:33:41 +1100 (EST) Subject: CrossCompiling Openssh. In-Reply-To: <3C8FAE90.D88A5D84@cyclades.com> Message-ID: On Wed, 13 Mar 2002, Edson Ap. Seabra wrote: > Hi, > > I am trying to cross compile openssh-3.1p1 for PPC. > > I am using linux host Hard Hat 6.2. In this machine I could > compile and install the openssh. > > When I run the configure enabling "cross compile" It gives > the following error: Cross compilation is not currently supported - noone has sent us patches to get it working. -d From djm at mindrot.org Thu Mar 14 08:35:20 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Mar 2002 08:35:20 +1100 (EST) Subject: 3.1p1 under Solaris x86 5.7 fails to compile ... In-Reply-To: <20020313112308.U308-100000@atelier.acadiau.ca> Message-ID: On Wed, 13 Mar 2002, Marc G. Fournier wrote: > > file missing? No, you forgot to check bugzilla: http://bugzilla.mindrot.org/show_bug.cgi?id=138 From ewheeler at kaico.com Thu Mar 14 09:11:29 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Wed, 13 Mar 2002 14:11:29 -0800 (PST) Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: Message-ID: Damien -- Do you know when the changes listed at http://www.citi.umich.edu/u/provos/ssh/privsep.html will be merged into the OpenSSH tree, or if they ever will (or, I suppose, already have been)? I have not looked yet, but is there documention on setting up privilege separation? --Eric On Thu, 14 Mar 2002, Damien Miller wrote: > On Wed, 13 Mar 2002, ewheeler at kaico.com wrote: > > > Attached is a zlib advisory and a debug dump of ssh with compression > > enabled. Most of the debug is superflous, so I have underlined the two > > points to look at. When creating an ssh connection, compression on the > > line is done *before* authentication -- This means an unauthorized > > attacker could, conceivable, leverage root access by connecting with to > > the ssh server requesting zlib compression and sending a specialy tailored > > packet. The CERT advisory for zlib's bug is also attached. > > > > I would like to start a discussion on the following points: > > > > 1. What is the exposure to this bug? > > The vulnerability can be triggered, but whether this can be leveraged > into an exploit remains to be seen. > > > 2. What are the logistics of moving all non-critical external library > > calls (zlib in this case, but others if they exist) *after* > > authentication? > > Not easy, what's "non-critical"? > > > 3. Does OpenSSH statically link (or can it/does it by default) to the > > zlib library -- will updating the zlib library to 1.1.4 take care of the > > situation? > > Depends on the system. > > > 4. Are there any proactive measures besides moving non-critical library > > calls after authentication which could be done within the OpenSSH code? > > Work is underway to improve things: > > http://www.citi.umich.edu/u/provos/ssh/privsep.html > > -d > -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From ewheeler at kaico.com Thu Mar 14 09:17:39 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Wed, 13 Mar 2002 14:17:39 -0800 (PST) Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: Message-ID: Damien -- I should have tagged this on my previous email, but oops! > > 2. What are the logistics of moving all non-critical external library > > calls (zlib in this case, but others if they exist) *after* > > authentication? > > Not easy, what's "non-critical"? Well, zlib could be considered "non-critical" before authentication -- The amount of data passed during authentication is small and need not be compressed (IMO). I am not familiar enough with OpenSSH's code to know if there are other superflous calls, and none of the debug output gives a hint to something which could wait until after auth. As I understand the SSH protocol, enabling zlib compression (SSH_CMSG_REQUEST_COMPRESSION) /could/ be done after authentication if the code to handle SSH_CMSG_REQUEST_COMPRESSION was implemented in the body of the ssh protocol rather than only during prep. If this breaks RFC, it could be an option in sshd_config and ssh_config so other ssh implementations can still work with it if necessary. --Eric On Thu, 14 Mar 2002, Damien Miller wrote: > On Wed, 13 Mar 2002, ewheeler at kaico.com wrote: > > > Attached is a zlib advisory and a debug dump of ssh with compression > > enabled. Most of the debug is superflous, so I have underlined the two > > points to look at. When creating an ssh connection, compression on the > > line is done *before* authentication -- This means an unauthorized > > attacker could, conceivable, leverage root access by connecting with to > > the ssh server requesting zlib compression and sending a specialy tailored > > packet. The CERT advisory for zlib's bug is also attached. > > > > I would like to start a discussion on the following points: > > > > 1. What is the exposure to this bug? > > The vulnerability can be triggered, but whether this can be leveraged > into an exploit remains to be seen. > > > > 3. Does OpenSSH statically link (or can it/does it by default) to the > > zlib library -- will updating the zlib library to 1.1.4 take care of the > > situation? > > Depends on the system. > > > 4. Are there any proactive measures besides moving non-critical library > > calls after authentication which could be done within the OpenSSH code? > > Work is underway to improve things: > > http://www.citi.umich.edu/u/provos/ssh/privsep.html > > -d > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From djm at mindrot.org Thu Mar 14 09:22:58 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Mar 2002 09:22:58 +1100 (EST) Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: Message-ID: On Wed, 13 Mar 2002, ewheeler at kaico.com wrote: > Damien -- > > I should have tagged this on my previous email, but oops! > > > > 2. What are the logistics of moving all non-critical external library > > > calls (zlib in this case, but others if they exist) *after* > > > authentication? > > > > Not easy, what's "non-critical"? > > Well, zlib could be considered "non-critical" before authentication -- > The amount of data passed during authentication is small and need not be > compressed (IMO). I am not familiar enough with OpenSSH's code to know if > there are other superflous calls, and none of the debug output gives a > hint to something which could wait until after auth. > > As I understand the SSH protocol, enabling zlib compression > (SSH_CMSG_REQUEST_COMPRESSION) /could/ be done after authentication if the > code to handle SSH_CMSG_REQUEST_COMPRESSION was implemented in the body of > the ssh protocol rather than only during prep. If this breaks RFC, it > could be an option in sshd_config and ssh_config so other ssh > implementations can still work with it if necessary. Those messages are for SSH protocol 1 only. The only way you could do it for SSH protocol 2 is to perform a rekey after authentication. This effort would be better spent getting Niels' privsep code running properly. -d From djm at mindrot.org Thu Mar 14 09:28:56 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Mar 2002 09:28:56 +1100 (EST) Subject: Logging of client commands, possible? In-Reply-To: <00b301c1cb65$ea21e5b0$1701000a@effugas> Message-ID: On Thu, 14 Mar 2002, Dan Kaminsky wrote: > > Yes, you are right. > > > > And because SSH does not care about what's going on inside it does > > not snoop ttys. On Unix, tools should do _one_ thing and do it well, not > > 1000 things is a very mediocre way. > > Markus, > > If I wanted one tool to do one thing, I'd use Telnet over SSL. :-) > OpenSSH is *all* about the integration of generic encapsulators into a > common tool. In this case, we'd be integrating a cross platform method to > encapsulate TTY logging methods, as an alternative to painful, non-portable > solutions. ... and it will still be useless against anyone with 1/4 of a clue, who can upload a script or binary and execute that. The place for this is a dedicated tty snooper or, better yet, real system audit logs. -d From provos at citi.umich.edu Thu Mar 14 09:50:49 2002 From: provos at citi.umich.edu (Niels Provos) Date: Wed, 13 Mar 2002 17:50:49 -0500 Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: References: Message-ID: <20020313225049.GO4715@citi.citi.umich.edu> On Wed, Mar 13, 2002 at 02:11:29PM -0800, ewheeler at kaico.com wrote: > Do you know when the changes listed at > http://www.citi.umich.edu/u/provos/ssh/privsep.html will be merged into > the OpenSSH tree, or if they ever will (or, I suppose, already have > been)? I have not looked yet, but is there documention on setting up > privilege separation? My hope is that the privilege separation will be integrated into the official OpenSSH tree. Currently, if you download the version from my webpage, privilege separation is enabled by default. It can be disabled with 'UsePrivilegeSeparation=no'. Most OpenSSH features are already supported. Markus and I are working on getting the few remaining things straightend out. Niels. From bugzilla-daemon at mindrot.org Thu Mar 14 10:12:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 10:12:38 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020313231238.86ACDEACD@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From carljohan at kjellander.com 2002-03-14 10:12 ------- Created an attachment (id=41) Patch to configure.ac to make sshd forward X11 on both IPv6 and IPv4. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ewheeler at kaico.com Thu Mar 14 10:21:55 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Wed, 13 Mar 2002 15:21:55 -0800 (PST) Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: <20020313225049.GO4715@citi.citi.umich.edu> Message-ID: Wonderful, I look forward to seeing it in the tree. For the moment, I will be unable to use the privilege separation code since all of our systems are linux based rather than bsd. I will watch the list to see when it enters the portable tree. --Eric On Wed, 13 Mar 2002, Niels Provos wrote: > On Wed, Mar 13, 2002 at 02:11:29PM -0800, ewheeler at kaico.com wrote: > > Do you know when the changes listed at > > http://www.citi.umich.edu/u/provos/ssh/privsep.html will be merged into > > the OpenSSH tree, or if they ever will (or, I suppose, already have > > been)? I have not looked yet, but is there documention on setting up > > privilege separation? > My hope is that the privilege separation will be integrated into the > official OpenSSH tree. Currently, if you download the version from > my webpage, privilege separation is enabled by default. It can be > disabled with 'UsePrivilegeSeparation=no'. > > Most OpenSSH features are already supported. Markus and I are working > on getting the few remaining things straightend out. > > Niels. > -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From bugzilla-daemon at mindrot.org Thu Mar 14 10:30:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 10:30:35 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020313233035.C8836E941@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From carljohan at kjellander.com 2002-03-14 10:30 ------- What is the meaning of DONT_TRY_OTHER_AF? It's only enabled on linux and is the source of this problem. Without it sshd opens forwarding on both IPv6 and IPv4. Are there any bad sideeffects of this? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Fri Mar 15 11:03:18 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 14 Mar 2002 16:03:18 -0800 Subject: Logging of client commands, possible? References: Message-ID: <013601c1cbb4$d00efec0$1701000a@effugas> > ... and it will still be useless against anyone with 1/4 of a clue, who > can upload a script or binary and execute that. > > The place for this is a dedicated tty snooper or, better yet, real system > audit logs. AAAAAAAAAARGH. Just because somebody can lie doesn't mean I'd prefer an EKG to a confession! This is an *adjunct* to real system audit logs, which really, really suck when it comes to providing a useful history. You think people need hackers for their servers to break? There's an old refrain about malice, stupidity, and some swamp land in florida you might like :-) Damnit, Damien, which of these do you wanna debug to figure out who broke your production server? [root at localhost libdivxdecore-0.4.7]# ./configure loading cache ./config.cache checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... found checking for working autoconf... found or + echo -n 'checking whether the C++ compiler (c++ ) works... ' checking whether the C++ compiler (c++ ) works... + echo 'configure:1755: checking whether the C++ compiler (c++ ) works' + ac_ext=C + ac_cpp=$CXXCPP $CPPFLAGS + ac_compile=${CXX-g++} -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext 1>&5 + ac_link=${CXX-g++} -o conftest${ac_exeext} $CXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5 + cross_compiling=no + cat + eval echo configure:1771: '"${CXX-g++}' -o 'conftest${ac_exeext}' '$CXXFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"' or even rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 stat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 stat64("/usr/local/sbin/sleep", 0xbffff700) = -1 ENOENT (No such file or directory) stat64("/usr/local/bin/sleep", 0xbffff700) = -1 ENOENT (No such file or directory) stat64("/sbin/sleep", 0xbffff700) = -1 ENOENT (No such file or directory) stat64("/bin/sleep", {st_mode=S_IFREG|0755, st_size=11612, ...}) = 0 stat64("/bin/sleep", {st_mode=S_IFREG|0755, st_size=11612, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0 _llseek(255, -7665, [22525], SEEK_CUR) = 0 fork() = 19523 [pid 19509] rt_sigprocmask(SIG_SETMASK, [], [pid 19523] getpid( [pid 19509] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 19523] <... getpid resumed> ) = 19523 [pid 19509] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 [pid 19509] rt_sigprocmask(SIG_BLOCK, [CHLD], [pid 19523] close(255 --Dan From bugzilla-daemon at mindrot.org Thu Mar 14 11:16:40 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 11:16:40 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020314001640.CC6F0EADA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 carljohan at kjellander.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor ------- Additional Comments From carljohan at kjellander.com 2002-03-14 11:16 ------- Maybe this isn't a bug at all, maybe it's a feature. DISPLAY is set to localhost:0 and localhost doesn't resolve to ::1 as standard. Adding this line to /etc/hosts makes apps connect to the IPv6 tunnel. ::1 localhost But I still can't figure out why linux is the only system that shouldn't open the tunnel on both IPv4 and IPv6. Changing the severity to minor. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 14 11:25:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 11:25:55 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020314002555.E3B1CEAD8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From djm at mindrot.org 2002-03-14 11:25 ------- The reason is that we are running afoul of a fix to avoid a quirk in Linux's IPv6 support. IIRC a wildcard bind() on IPv4 will cause a subsequent IPv6 bind() to fail. Since we are not using wildcard binds in the localhost X11 case, the following patch should help. Please report on whether this is the 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 Thu Mar 14 11:27:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 11:27:08 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020314002708.765A0EAE1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From djm at mindrot.org 2002-03-14 11:27 ------- Created an attachment (id=42) Tries all AFs when binding to localhost ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 14 13:27:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 13:27:09 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020314022709.3EB6EE94C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From carljohan at kjellander.com 2002-03-14 13:27 ------- Nope that didn't work. Maybe you reversed the meaning of AI_PASSIVE? I'm attaching a patch that uses x11_use_localhost instead. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 14 13:29:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 13:29:45 +1100 (EST) Subject: [Bug 164] X-forwarding when connecting to an IPv6-enabled host doesn't work. Message-ID: <20020314022945.B6957EAE2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=164 ------- Additional Comments From carljohan at kjellander.com 2002-03-14 13:29 ------- Created an attachment (id=43) Attach to both AFs even in linux when connecting to localhost ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From abhi at acc.com Thu Mar 14 14:02:49 2002 From: abhi at acc.com (Abhijeet Thakare) Date: Wed, 13 Mar 2002 19:02:49 -0800 Subject: SCP or RCP standards Message-ID: Hi All, I am looking for SCP or RCP standards. I searched on the web but I am not able to find the standards. Please mail me the link where I can find the standards for SCP or RCP. Thanks, Abhijeet From bugzilla-daemon at mindrot.org Thu Mar 14 17:55:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 17:55:47 +1100 (EST) Subject: [Bug 165] New: Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020314065547.B45E6E94A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 Summary: Problem with SSH1 Keys on RedHat7.2 Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mmahler at 141.com OpenSSH 3.1 installed on RedHat 7.2 seems to have a problem with SSH 1. Here is a copy of the debug info: debug1: Received encrypted confirmation. debug1: RSA authentication using agent refused. debug1: Trying RSA authentication with key '/home/sisyphus/.ssh/identity' debug1: Server refused our key. debug1: Doing challenge response authentication. debug1: No challenge. debug1: Doing password authentication. If I throw back on OpenSSH 3.0 the key is accepted. here is the same system, same config file, same authorized key file same key. only difference is OpenSSH 3.0 instead of 3.1 debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: RSA authentication using agent refused. debug1: Trying RSA authentication with key '/home/sisyphus/.ssh/identity' debug1: Received RSA challenge from server. Enter passphrase for RSA key '/home/sisyphus/.ssh/identity': ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 14 21:44:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Mar 2002 21:44:37 +1100 (EST) Subject: [Bug 166] New: ssh-add gives annoying messages for non-exsisting keys Message-ID: <20020314104437.B254EEAED@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=166 Summary: ssh-add gives annoying messages for non-exsisting keys Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: cagri at ripe.net It is a totally cosmetic thing but, ssh-add of 3.1p1 gives the following messages when keys are not explicitly listed in the cmd line. --------------------------- penguin:~$ ssh-add /home/cagri/.ssh/id_rsa: No such file or directory /home/cagri/.ssh/id_dsa: No such file or directory Enter passphrase for cagri at penguin: --------------------------- everything is fine & working, however these messages could be misleading for ignorant users. I think it would be a good idea to give some messages which does not look like an "error message" or even no message at all. I've tested it on linux x86, I do not think it depends on OS or architecture. Regards. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From marc.fournier at acadiau.ca Thu Mar 14 02:23:49 2002 From: marc.fournier at acadiau.ca (Marc G. Fournier) Date: Wed, 13 Mar 2002 11:23:49 -0400 (AST) Subject: 3.1p1 under Solaris x86 5.7 fails to compile ... Message-ID: <20020313112308.U308-100000@atelier.acadiau.ca> file missing? (cd openbsd-compat && make) make[1]: Entering directory `/usr/local/src/openssh-3.1p1/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/openssh-3.1p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/slocal/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/slocal/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/slocal/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/slocal/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/usr/slocal/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 Marc G. Fournier marc.fournier at acadiau.ca Senior Systems Administrator Acadia University "These are my opinions, which are not necessarily shared by my employer" From bugzilla-daemon at mindrot.org Fri Mar 15 01:40:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 01:40:06 +1100 (EST) Subject: [Bug 166] ssh-add gives annoying messages for non-exsisting keys Message-ID: <20020314144006.BDE83EB09@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=166 ------- Additional Comments From wknox at mitre.org 2002-03-15 01:40 ------- This appears to me to be a duplicate of bug #158. Try the second attachment to that bug (a patch against ssh-add.c) and see if that helps. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 01:53:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 01:53:41 +1100 (EST) Subject: [Bug 166] ssh-add gives annoying messages for non-exsisting keys Message-ID: <20020314145341.B359CEB0D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=166 ------- Additional Comments From cagri at ripe.net 2002-03-15 01:53 ------- Yes, patch for #158 this solves. Sorry for the duplicate report. Thanks.. -- cagri ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 02:06:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 02:06:23 +1100 (EST) Subject: [Bug 166] ssh-add gives annoying messages for non-exsisting keys Message-ID: <20020314150623.2D549EB11@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=166 wknox at mitre.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From wknox at mitre.org 2002-03-15 02:06 ------- *** This bug has been marked as a duplicate of 158 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 02:06:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 02:06:27 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020314150627.C47A5EB13@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 wknox at mitre.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cagri at ripe.net ------- Additional Comments From wknox at mitre.org 2002-03-15 02:06 ------- *** Bug 166 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From anton at chuvakin.org Fri Mar 15 02:22:31 2002 From: anton at chuvakin.org (Anton Chuvakin) Date: Thu, 14 Mar 2002 10:22:31 -0500 (EST) Subject: recovering SSH2 sessions while knowing the key and how to have it Message-ID: Hello all, I hope it is the right forum to ask the question, since it is more about openssh internals then about usage. I want to do a weird thing with my openssh daemon for the honeypot setup. Namely, I want it to covertly broadcast the session key, so that, upon sniffing the session, the contents can be recovered. My C skills will be sufficient to find a session key by digging into the ssh source. But my problem is building a recovery tool. Honestly, I have no idea how to approach it, while I have some idea about ssh protocol. Thus, I would appreciate *ANY* feedback on that, even a pile of ideas is better than what I have now. P.S. If you are familiar with honeynet setup, please do not suggest that I use LKM or a trojaned bash to do the session recovery. I will! I just need a second layer of defense here. Also, recovering scp-ed files is kinda tricky via LKM. Thanks a lot in advance. I will appreciate any help! Best, P.S. Please, do answer directly to me as well as to the list. -- Anton A. Chuvakin, Ph.D. http://www.chuvakin.org http://www.info-secure.org From markus at openbsd.org Fri Mar 15 03:36:58 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 14 Mar 2002 17:36:58 +0100 Subject: zlib compression, the exploit, and OpenSSH In-Reply-To: References: Message-ID: <20020314163657.GB1319@faui02> On Wed, Mar 13, 2002 at 12:07:34PM -0800, ewheeler at kaico.com wrote: > 2. What are the logistics of moving all non-critical external library > calls (zlib in this case, but others if they exist) *after* > authentication? this would only work if we disallowed compression until after authentication and start to rekey after successful authentication. From bugzilla-daemon at mindrot.org Fri Mar 15 05:17:14 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 05:17:14 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020314181714.3E721E906@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mdev at idg.nl 2002-03-15 05:17 ------- Created an attachment (id=44) sftp-int.c: cmds[] to sftp_cmds[] ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 05:19:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 05:19:37 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020314181937.C66FCEB8F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mdev at idg.nl 2002-03-15 05:19 ------- On a 4.1 system I had the same errors and an additional one. The fake-queue, was fixable by: CFLAGS=-DHAVE_BOGUS_SYS_QUEUE_H=1 The additional error is in sftp-int.c. The build fails on: gcc -o sftp sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o -L. -Lopenbsd-compat/ -L/weblib/local/lib -L/usr/lib -Lyes -lssh -l openbsd-compat -lutil -lz -lcrypto /usr/lib/libc.a(prandom.o)(.data+0x0): multiple definition of `cmds' sftp-int.o(.rodata+0x48): first defined here ld: Warning: size of symbol `cmds' changed from 256 to 40 in prandom.o make: *** [sftp] Error 1 I renamed cmds to sftp_cmds and all is well. See uploaded patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From johan.adolfsson at axis.com Fri Mar 15 05:27:07 2002 From: johan.adolfsson at axis.com (johan.adolfsson at axis.com) Date: Thu, 14 Mar 2002 19:27:07 +0100 Subject: CrossCompiling Openssh. References: Message-ID: <02de01c1cb85$d9072ea0$8eb270d5@homeip.net> Actually I sent a patch back in 2000-12-18, but I guess it was to ugly to get accepted or something. Others have found it useful though. /Johan ----- Original Message ----- From: "Damien Miller" To: "Edson Ap. Seabra" Cc: Sent: den 13 mars 2002 22:33 Subject: Re: CrossCompiling Openssh. > On Wed, 13 Mar 2002, Edson Ap. Seabra wrote: > > > Hi, > > > > I am trying to cross compile openssh-3.1p1 for PPC. > > > > I am using linux host Hard Hat 6.2. In this machine I could > > compile and install the openssh. > > > > When I run the configure enabling "cross compile" It gives > > the following error: > > Cross compilation is not currently supported - noone has sent us > patches to get it working. > > -d > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dharmendra.mohan at cacheflow.com Fri Mar 15 05:50:43 2002 From: dharmendra.mohan at cacheflow.com (Mohan, Dharmendra) Date: Thu, 14 Mar 2002 10:50:43 -0800 Subject: sshd signal handling Message-ID: Hi, I am running into a problem with sshd. sshd is invoked by a process (say X) which sends sighup to it if there is a configuration change automatically. If user changes the configuration in quick succession then sshd gets terminated. I think the problem is that sshd installs its signal handlers after key generation is done. It takes a while for key generation (server key, I am using ssh protocol version 1) step to be complete. If user changes the configuration in quick succession then X ends up sending sighups to the sshd process causing it to be killed since it is still in the process of generating the server key and yet to install the sighup handler. I could fix this by putting the installation of sighup signal handler before the key generation step. It works fine as sighup handler keeps handling the sighup signals and then later on re-reads the configuration file since received_sighup variable is set to 1. My question is by making this change, will I be creating any security hole? Is there a better way to fix it? Is there a reason why signal handlers are not installed first? Any help will be greatly appreciated. Thanks, Dm From bugzilla-daemon at mindrot.org Fri Mar 15 06:23:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 06:23:10 +1100 (EST) Subject: [Bug 159] Password-Authentication with openssh-3.1p1 fails Message-ID: <20020314192310.57FD0E90D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=159 fam.muck at telda.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From fam.muck at telda.net 2002-03-15 06:23 ------- Hallo out there, seems that the reported phenomenon is not related to openssh. I changed the first line from my auth-stack in /etc/pam.d/sshd from auth required /lib/security/pam_unix.so to auth required /lib/security/pam_unix_auth.so and all works. That's why I mean we have to look for the bug in pam_unix.so. I wrote a bug report to the maintainer of pam_unix.so. Thanks for your effort I go on and close the bug on this site. Ciao Andreas ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 06:53:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 06:53:00 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020314195300.BC531EBA1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mouring at eviladmin.org 2002-03-15 06:52 ------- Why are we renaming things without any reasoning behind it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From imorgan at nas.nasa.gov Fri Mar 15 06:51:05 2002 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 14 Mar 2002 11:51:05 -0800 (PST) Subject: Problem with utmp on IRIX Message-ID: <200203141952.LAA13313@nopython.nas.nasa.gov> Hello all, It looks like there is a problem with how OpenSSH writes the id field in utmp and utmpx on IRIX. OpenSSH and IRIX use somewhat differnt conventions for the id field and this seems to create a problem under some circumstances. Under some (as yet undetermined) circumstances IRIX leaves a DEAD_PROCESS record that still has a username and pid associated with it. When this happens, cuserid() and getlogin() can get fooled into using the old record rather than the record writtne by sshd. I wrote a small program to extract some of the information from the utmpx file and have included some output her to help illustrate the issue. octane30.root./tmp: 51> /bin/tty /dev/ttyq3 octane30.root./tmp: 52> ./utxent | grep ttyq3 onufer:ttyq3:q3:8:1006:1896751 root:ttyq3:tyq3:7:0:1955158 octane30.root./tmp: 53> ps -fp 1896751 UID PID PPID C STIME TTY TIME CMD octane30.root./tmp: 54> who am i onufer ttyq3 Mar 13 13:34 octane30.root./tmp: 55> whoami root octane30.root./tmp: 56> I made a very minor alteration to loginrec.c which seems to have eliminated the issue on the systems that I have tested it on. diff -u src/loginrec.c irix6.5/loginrec.c --- src/loginrec.c Mon Oct 29 18:50:40 2001 +++ irix6.5/loginrec.c Wed Mar 6 11:33:40 2002 @@ -564,6 +564,10 @@ if (strncmp(src, "/dev/", 5) == 0) src += 5; + /* Make the ut_id field consistent with IRIX */ + if (strncmp(src, "tty", 3) == 0) + src += 3; + len = strlen(src); if (len > 0) { -- Iain Morgan NAS Desktop Support Group From ed.wilts at merrillcorp.com Fri Mar 15 07:30:23 2002 From: ed.wilts at merrillcorp.com (Ed Wilts) Date: Thu, 14 Mar 2002 14:30:23 -0600 Subject: Encrypted file transfers Message-ID: An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020314/ea8e5a03/attachment.html From kwhite at kevbo.org Fri Mar 15 07:54:39 2002 From: kwhite at kevbo.org (Kevin White) Date: Thu, 14 Mar 2002 15:54:39 -0500 Subject: OpenSSH 3.1 and OpenBSD 2.8 problem Message-ID: <3C910E0F.4050400@kevbo.org> I'm having trouble with OpenSSH 3.1 on an OpenBSD 2.8 box. I apply the patch (the second patch, date/time March 7 12:41 GMT) and I can't connect to it from any other box using Version 1 protocols. I get this: (collector1 is an OpenBSD 3.0 box running OpenSSH 3.1) [kwhite at collector1 kwhite]$ ssh -1 -v scooby.local OpenSSH_3.1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1000 geteuid 0 anon 1 debug1: Connecting to scooby.local [172.16.1.110] port 22. debug1: temporarily_use_uid: 1000/1000 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 1000/1000 (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 /home/kwhite/.ssh/identity type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1 debug1: match: OpenSSH_3.1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'scooby.local' is known and matches the RSA1 host key. debug1: Found key in /home/kwhite/.ssh/known_hosts:12 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. Disconnecting: Corrupted check bytes on input. debug1: Calling cleanup 0x1a504(0x0) I tried a couple different ciphers, and got the same thing. Any ideas? I got these warnings on compile, which kind of bothered me, actually: cc -O2 -DKRB4 -I/usr/include/kerberosIV -DAFS -I/c/Work/Master-2.8/src/usr.bin/ssh/lib/.. -c /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c -o cipher.o /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_init': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:268: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_cbc': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:297: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh1_3des_cleanup': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:311: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `evp_ssh1_3des': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:328: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:329: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:330: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `evp_ssh1_bf': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:373: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:375: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_init': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:394: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_cbc': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:421: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `ssh_rijndael_cleanup': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:458: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c: In function `evp_rijndael': /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:475: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:476: warning: assignment from incompatible pointer type /c/Work/Master-2.8/src/usr.bin/ssh/lib/../cipher.c:477: warning: assignment from incompatible pointer type Kevin From raji at sgi.com Fri Mar 15 11:06:30 2002 From: raji at sgi.com (Rajeswari Raghunath) Date: Thu, 14 Mar 2002 16:06:30 -0800 Subject: Permission denied Message-ID: <3C913B06.FC910241@sgi.com> Hi, I installed openssh3.1p1 on two IRIX test systems which have both ipv6/v4 stack. When tried to execute ssh, it says permission denied and it fails. I did add --with-pam when i did configure, installed pam libraries also on the test systems. user1 at system1~ 59 % /usr/freeware/bin/ssh user1 at system1 /usr/bin/true user1 at system1's password: Permission denied, please try again. user1 at system1's password: But when i installed the same software on another set of two sytems which has only v4 stack, it doesn't fail this way. What could be going wrong here? Thanks, raji. From rdump at river.com Fri Mar 15 10:45:48 2002 From: rdump at river.com (Richard Johnson) Date: Thu, 14 Mar 2002 16:45:48 -0700 Subject: OpenSSH vs AIX 4.3.3 => 5.1 utmp patch Message-ID: The patch below follows changes in AIX utmp handling made between AIX 4.3.3 and 5.1. With it, utmp entries are properly recorded again. The patch applies to OpenSSH 3.1p1, and seems to work fine. The co-worker who sent me the patch hasn't tested backwards compatibility on AIX 4.3.3 systems. Richard ------- *** openssh-2.9.9p2/auth-passwd.c.org Tue Jul 3 23:21:15 2001 --- openssh-2.9.9p2/auth-passwd.c Tue Oct 2 10:13:47 2001 *************** *** 147,153 **** } #endif #ifdef WITH_AIXAUTHENTICATE ! return (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0); #endif #ifdef KRB4 if (options.kerberos_authentication == 1) { --- 147,157 ---- } #endif #ifdef WITH_AIXAUTHENTICATE ! if (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0) ! return 1; ! loginfailed(authctxt->user, ! get_canonical_hostname(options.reverse_mapping_check), "ssh"); ! return 0; #endif #ifdef KRB4 if (options.kerberos_authentication == 1) { *** openssh-2.9.9p2/auth2.c.org Tue Oct 2 17:54:29 2001 --- openssh-2.9.9p2/auth2.c Tue Oct 2 17:54:56 2001 *************** *** 275,280 **** --- 275,287 ---- /* XXX todo: check if multiple auth methods are needed */ if (authenticated == 1) { + #ifdef WITH_AIXAUTHENTICATE + /* We don't have a pty yet, so just label the line as "ssh" */ + if (loginsuccess(authctxt->user?authctxt->user:"NOUSER", + get_canonical_hostname(options.reverse_mapping_check), + "ssh", &aixloginmsg) < 0) + aixloginmsg = NULL; + #endif /* WITH_AIXAUTHENTICATE */ /* turn off userauth */ dispatch_set(SSH2_MSG_USERAUTH_REQUEST, &protocol_error); packet_start(SSH2_MSG_USERAUTH_SUCCESS); From macrosoft at 263.net Fri Mar 15 12:38:19 2002 From: macrosoft at 263.net (Simon Polar Bear) Date: Fri, 15 Mar 2002 09:38:19 +0800 (CST) Subject: =?gb2312?B?c2NwICdzIHByb2JsZW0=?= Message-ID: <3C91508B.00000F.19348@mta2> I have add an authentication method to openSSH, I call it ICCAuthentication, much like RSAAuthentication, but the RSA private key is in the IC card. I did not change any source code of scp. I mean scp.c. I set all authentication methods to "no" in sshd_config but ICCAuthentication yes. ssh works very well with this authentication method. But scp is not good with it. scp always run_err() in the following context in scp.c: void sink(argc, argv) { .... ..... if(first){ run_err("%s",cp); exit(1); } ...... ...... } That means that "first" is always true. What does "sink" mean anyway ? Why ? Thanks. __________________________________________ ?????????????????????(http://mail.263.net/mmail/index.html) ????????95963??????????(http://www.263.net/0ji/StarDialer.exe) ????????????????(http://95963.263.net/) ??????????,????????(http://shopping.263.net/class004.htm) From bugzilla-daemon at mindrot.org Fri Mar 15 17:19:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 17:19:31 +1100 (EST) Subject: [Bug 167] New: WARNING: sys/ttcompat.h: present but cannot be compiled. Message-ID: <20020315061931.F14E8E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=167 Summary: WARNING: sys/ttcompat.h: present but cannot be compiled. Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dhighley at highley-recommended.com Building openssh 3.1p1 on Sparc Solaris 8 platform. The configure step output the warnings below: #include configure:4345: result: no configure:4349: checking sys/ttcompat.h presence configure:4356: gcc -E -I/usr/local/include conftest.c configure:4362: $? = 0 configure:4380: result: yes configure:4391: WARNING: sys/ttcompat.h: present but cannot be compiled. configure:4393: WARNING: sys/ttcompat.h: check for missing prerequisite headers? configure:4395: WARNING: sys/ttcompat.h: proceeding with the preprocessor's resu lt configure:4398: checking for sys/ttcompat.h ssh builds and will run but xterms end up going into inverse video mode. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Fri Mar 15 17:28:11 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 14 Mar 2002 22:28:11 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: ; from mjs@ams.org on Wed, Mar 13, 2002 at 08:54:51AM -0500 References: Message-ID: <20020314222811.A8579@google.com> On Wed, Mar 13, 2002 at 08:54:51AM -0500, Matt Studley wrote: > One does exist with that release. In /etc/init.d there is the cryptorand > script which creates the device when run. Take a look at > /usr/lib/security/cryptorand. OK, I've just downloaded 02/02 and do not see SUNWski. Are you sure you aren't picking this up from some local jumpstart setup? I would like to see 'pkginfo -x SUNWski'. /fc From fcusack at fcusack.com Fri Mar 15 17:40:48 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 14 Mar 2002 22:40:48 -0800 Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: <20020314222811.A8579@google.com>; from fcusack@fcusack.com on Thu, Mar 14, 2002 at 10:28:11PM -0800 References: <20020314222811.A8579@google.com> Message-ID: <20020314224047.A20590@google.com> On Thu, Mar 14, 2002 at 10:28:11PM -0800, Frank Cusack wrote: > On Wed, Mar 13, 2002 at 08:54:51AM -0500, Matt Studley wrote: > > One does exist with that release. In /etc/init.d there is the cryptorand > > script which creates the device when run. Take a look at > > /usr/lib/security/cryptorand. > > OK, I've just downloaded 02/02 and do not see SUNWski. Are you sure you > aren't picking this up from some local jumpstart setup? I would like > to see 'pkginfo -x SUNWski'. Additionally, the release notes for 02/02 don't mention /dev/random nor SUNWski. /fc From bugzilla-daemon at mindrot.org Fri Mar 15 18:22:05 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 18:22:05 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020315072205.B9325E92F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mdev at idg.nl 2002-03-15 18:22 ------- The reasoning is, that this bug is similar to: http://www.openldap.org/lists/openldap-bugs/200005/msg00032.html And that prandom.o is in libc. Another reason is, that 'cmds' is likely to conflict unless you protect it, since it's quite a common name. I don't know the reason for using sftp's own structure, instead of using the libc provided structure, so if it can be modified to use libc's. The only reference to cmds I found in /usr/include was: /usr/include/arpa/telnet.h Which also uses it's own name: #ifdef TELCMDS char *telcmds[] = { "EOF", "SUSP", "ABORT", "EOR", "SE", "NOP", "DMARK", "BRK", "IP", "AO", "AYT", "EC", "EL", "GA", "SB", "WILL", "WONT", "DO", "DONT", "IAC", 0, }; #else extern char *telcmds[]; #endif So it seemed the logical thing to do. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From nakaji at tutrp.tut.ac.jp Fri Mar 15 19:43:56 2002 From: nakaji at tutrp.tut.ac.jp (NAKAJI Hiroyuki) Date: Fri, 15 Mar 2002 17:43:56 +0900 Subject: OpenSSH on mips-sony-bsd Message-ID: <878z8ui5kj.fsf@boggy.acest.tutrp.tut.ac.jp> Dear developpers, I have some problem with the latest openssh available via CVS. The target host is detected as mips-sony-bsd, SONY NEWS-OS 4.2.1R, which is an old type OS based on 4.3BSD. At first, this system has VSTATUS defined but no _POSIX_VDISABLE which both are used in openbsd-compat/readpassphrase.c. Second, some header files on this OS do not include and it causes many syntax error. For example, dev_t used in and defined in . I checked the openssh source and found that a directive about is defined in config.h.in but it is not used in configure (and configure.ac). To fix these problem, I made a very ad-hoc patch. Here is. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh.diff Type: application/octet-stream Size: 1258 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020315/d7749db4/attachment.obj -------------- next part -------------- There is another not-so-serious problem. When I logged in this host from another host with 'ssh -X', some X applications get error. For example, nakaji at clare:nakaji$ echo $DISPLAY localhost:11.0 nakaji at clare:nakaji$ /usr/bin/X11/xterm channel 0: istate 8 != open channel 0: ostate 64 != open X connection to localhost:11.0 broken (explicit kill or server shutdown). And some other X applications do not. The difference between them is that the former (error) is preinstalled with this OS and it is X11R5, and the latter is installed with X11R6. Strange... Any hint? Thanks in advance. -- NAKAJI Hiroyuki From markus at openbsd.org Fri Mar 15 19:45:05 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 15 Mar 2002 09:45:05 +0100 Subject: Key Pair Conversion Openssh => SSH2 In-Reply-To: References: Message-ID: <20020315084505.GA17802@faui02> On Thu, Mar 14, 2002 at 12:12:20PM -0800, Bob Smith wrote: > i find it amusing that the OpenBSD web site states on the main index page > "Our efforts emphasize portability, standardization,...." but by not > following standards like secsh's key format you're failing according to > your own goals. This is not exactly the truth. You have to consider your user base before you consider switching to a completely different key format and make their life harder. This is why OpenSSH uses a one-key-per-line representation of the public key (for all protocol versions). OpenSSH tries to make switching to protocol v2 easy for existing users and not as hard as possible. You should also remember the history: back when protocol v2 support was added to OpenSSH there was not standard (not even a documentation) for the IETF-SECSH key format you are referring to. However, we provide tools for converting keys. From bugzilla-daemon at mindrot.org Fri Mar 15 20:21:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 20:21:27 +1100 (EST) Subject: [Bug 168] New: "Could not find working OpenSSL library" Message-ID: <20020315092127.5DEE5EBC8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=168 Summary: "Could not find working OpenSSL library" Product: Portable OpenSSH Version: older versions Platform: All OS/Version: All Status: NEW Severity: minor Priority: P1 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dtaylor at ejasent.com On Solaris 2.7 sparc, with OpenSSL installed in /usr/local/ssl, "configure --with-ssl-dir=/usr/local/ssl" fails with error "Could not find working OpenSSL library, please install or check config.log" config.log contains: ------------------------------------------------------------------ configure:4605: gcc -o conftest -g -O2 -Wall -I/usr/local/include -I/opt -L/usr/local/lib -R/usr/local/lib -L/opt -R/opt conftest.c -lz -lsocket -lnsl -lgen -lcrypto 1>&5 configure:4594: openssl/rand.h: No such file or directory configure: failed program was: #line 4591 "configure" #include "confdefs.h" #include #include ------------------------------------------------------------------ The problem seems to result from this loop: ------------------------------------------------------------------ for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl /usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do # Try to use $ssldir/include if it exists, otherwise # $ssldir if test -d "$ssldir/include" ; then CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include" ------------------------------------------------------------------ Since "saved_CPPFLAGS" (which is set to /usr/local/include) is never updated, this loop merely appends the last existing directory (which is /opt on my system) to CPPFLAGS. Seems it should either append *all* existing include directories from the "for" list", or only use the directory passed with the "--with-ssl-dir" option. An easy workaround is to remove all but "/usr/local/ssl" from the "for" list. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 15 20:25:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Mar 2002 20:25:49 +1100 (EST) Subject: [Bug 168] "Could not find working OpenSSL library" Message-ID: <20020315092549.C73CAEBCC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=168 ------- Additional Comments From dtaylor at ejasent.com 2002-03-15 20:25 ------- The openssh version is 2.5.2p2, but the relevant code in 3.1p1 "configure" looks the same. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mcardenas at ya.com Fri Mar 15 21:56:11 2002 From: mcardenas at ya.com (Manuel =?iso-8859-1?Q?Carde=F1as?=) Date: Fri, 15 Mar 2002 11:56:11 +0100 Subject: Problem with scp in Openssh3.1p1 Message-ID: <5.1.0.14.0.20020315104932.054ab610@pop.mailcorp.ya.com> (Excume for my poor english) Hi! I'm having a problem with scp since I installed openssh 3.1p1. Server: Openssh 3.1p1 Client: Openssh ANY_VERSION $ scp -v -v -v -v -v -p -C user at machine1:/etc/passwd ./machine1.passwd Executing: program /usr/bin/ssh host machine1, user user, command scp -v -p -f /etc/passwd Sending file modes: C0644 473 passwd 473 bytes... it's ok $ scp -v -v -v -v -v -p -C user at machine2:/etc/passwd ./machine2.passwd Executing: program /usr/bin/ssh host machine2, user user, command scp -v -p -f /etc/passwd Sending file modes: C0644 17592186044416 passwd 17592186044416 bytes... oh my god! The size of files on "machine2" always is "17592186044416" ?? ciao. -- Manuel Carde?as aka manu -- From mjs at ams.org Sat Mar 16 00:08:49 2002 From: mjs at ams.org (Matt Studley) Date: Fri, 15 Mar 2002 08:08:49 -0500 (EST) Subject: OpenSSH-3.1p1 Solaris build with /dev/random In-Reply-To: <20020314222811.A8579@google.com> Message-ID: Here is the result of the pkginfo -x SUNWski: SUNWski SKI 1.0 Software (User Package) (sparc) 1.0,REV=1998.09.24.00.00 Now that you mention it, this could have been from a jumpstart install. We are currently in the middle of a migration and some of the machines are being brought up by the jumpstart system. I could have sworn that I had used ANDIrand for the jumpstart configuration though. Also, we recently purchased some SUN Netra X1's and T1's and they already had a /dev/random when they booted. Strange. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Thu, 14 Mar 2002, Frank Cusack wrote: > On Wed, Mar 13, 2002 at 08:54:51AM -0500, Matt Studley wrote: > > One does exist with that release. In /etc/init.d there is the cryptorand > > script which creates the device when run. Take a look at > > /usr/lib/security/cryptorand. > > OK, I've just downloaded 02/02 and do not see SUNWski. Are you sure you > aren't picking this up from some local jumpstart setup? I would like > to see 'pkginfo -x SUNWski'. > > /fc > From f_mohr at yahoo.de Sat Mar 16 00:20:50 2002 From: f_mohr at yahoo.de (=?iso-8859-1?q?frank=20mohr?=) Date: Fri, 15 Mar 2002 14:20:50 +0100 (CET) Subject: [Bug 167] New: WARNING: sys/ttcompat.h: present but cannot be compiled. In-Reply-To: <20020315061931.F14E8E902@shitei.mindrot.org> Message-ID: <20020315132050.43560.qmail@web20510.mail.yahoo.com> > Building openssh 3.1p1 on Sparc Solaris 8 platform. The configure > step output > the warnings below: ... > configure:4391: WARNING: sys/ttcompat.h: present but cannot be > compiled. > configure:4393: WARNING: sys/ttcompat.h: check for missing > prerequisite headers? > configure:4395: WARNING: sys/ttcompat.h: proceeding with the > preprocessor's resu > lt > configure:4398: checking for sys/ttcompat.h got the same warning message on SunOS 5.6 too. > ssh builds and will run but xterms end up going into inverse video > mode. I didn't have that result (connected from SunOS 8, Linux and AIX) Frank __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Ihre E-Mail noch individueller? - http://domains.yahoo.de From b_smith44 at hotmail.com Sat Mar 16 00:52:30 2002 From: b_smith44 at hotmail.com (Bob Smith) Date: Fri, 15 Mar 2002 05:52:30 -0800 Subject: Key Pair Conversion Openssh => SSH2 Message-ID: i do realize that openssh was around long before the secsh draft, and as i said in the last thread i don't really know which key format is better, it seems to me they both have their benefits. i raised this issue again only because it seems that not a week goes by without someone posting a question about key formats... people are obviously confused about this. and just to agree with your next point, yes, people are confused about a lot of things, but when the confusion is caused by not following a standard then that's something that can be fixed with out the user needing a lobotomy. i'm really not trying to bash anyone here, i do appreciate the work done by the openbsd team, but since it is the open source community that is continually harassing and belittling corporations for not following open standards i really think that the open source community should make following standards the number two priority, before functionality, before performance and before portability... i'll give you that security should come first. >From: Markus Friedl ... >You have to consider your user base before you consider switching to a >completely different key format and make their life harder. This is why >OpenSSH uses a one-key-per-line representation of the public key (for >all protocol versions). > >OpenSSH tries to make switching to protocol v2 easy for existing users >and not as hard as possible. > >You should also remember the history: back when protocol v2 support was >added to OpenSSH there was not standard (not even a documentation) for >the IETF-SECSH key format you are referring to. However, we provide >tools for converting keys. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From dan at doxpara.com Sat Mar 16 01:52:01 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 15 Mar 2002 06:52:01 -0800 Subject: Key Pair Conversion Openssh => SSH2 References: Message-ID: <004101c1cc30$f73d49d0$1701000a@effugas> > i do realize that openssh was around long before the secsh draft, and as i > said in the last thread i don't really know which key format is better, it > seems to me they both have their benefits. i raised this issue again only > because it seems that not a week goes by without someone posting a question > about key formats... people are obviously confused about this. and just to > agree with your next point, yes, people are confused about a lot of things, > but when the confusion is caused by not following a standard then that's > something that can be fixed with out the user needing a lobotomy. > > i'm really not trying to bash anyone here, i do appreciate the work done by > the openbsd team, but since it is the open source community that is > continually harassing and belittling corporations for not following open > standards i really think that the open source community should make > following standards the number two priority, before functionality, before > performance and before portability... i'll give you that security should > come first. The short version: Our standard came first, their standard is one broken thing from a series of broken things, === I'll be the first to admit that there are interesting conclusions that can be drawn from the typology of "conspicuous outrage" directed towards actions of the "weak" vs. actions of the "powerful", but I do not believe anyone will be guilted into supporting a questionable format from a questionable design process anytime soon. To be honest, standards always fall back to the status quo, and OpenSSH implemented the SSH Key Management Status Quo, prior to the unfortunate (but undeniable) fiasco of the SSH2 Non-Deployment. It just ain't a Standard if nobody will deploy it. A little history: Ssh.com's attempt to migrate the market to SSH2 could sadly be studied as a step by step guide to bungling a migration. --New clients couldn't connect to old servers --Old clients couldn't connect to new servers --A massive crackdown on open licensing was instituted --The protocol was new, complex, unfamiliar, and untrusted --Configuration was quite different --Complete misrepresentations were made about how SSH2 differed (the "it offers on a completely different level of the packet", perhaps a reference to the as-of-yet-still-unimplemented optional MAC header, but utterly false beyond that) --No new features to justify the pain, except perhaps at the cryptographic layer. (OK, channels could command forward now, and the crypto *really was* fixed. But that's about it.) All this, all at once, now throw in broken key management, and that's What Went Wrong. Ahh, but why broken? The belief was that appropriating the file system would make update processes far more elegant; you'd simply use standard file tools to manipulate your keyspace. In theory, moderately elegant. In practice, though...well, a one megabyte hosts file is quite manageable; one thousand individual host files are not. Updating a mesh of the former requires one thousand transfer operations; updating a mesh of the latter requires one *million*. Which do you prefer? Now, we could arguably adopt the SSH2 key format and then retain one-file-many-keys storage semantics, but then there'd be *three* standards for key management. What's the user to expect? The user really shouldn't have to care. In my opinion, it's pretty clear that SSH requires a protocol standard for exchanging keys to be used for future authentications. It's quite ridiculous to have to know the exact file semantics necessary to cause the remote server to allow future logins using a given key, for the same reason it'd be absolutely ridiculous to have to manually copy /etc/ssh/ssh_host_rsa_key.pub into the local known_hosts representation. We can simplify the process somewhat -- an escape sequence that emits the pubkey that *should* have authenticated that session into whatever text editor is listening on the remote side would eliminate some of the need for tar/scp hacks -- but in all honesty, until there's something better on the wire, I don't see the very real problem you complain about (pubkey management is needlessly annoying) going away. Key formats need to be handled by the clients maintaining the key. If the remote side wants to throw their keys in a MySQL database, my client shouldn't have to understand remote SQL invocation. If the remote side wants all keys encoded in complete bit expanded form, one bit per line, my client shouldn't have to care. File formats for individual keys are actually quite important -- and indeed, a single format that can be run through a command like "ssh-key-import" will be of some use. But the fact that individual key transfer and integration of that key into an authentication database are quite conflated means that simply syncing to SSH2 is leaving the core problem unsolved -- we're still forcing the client to care about how the server will store a key. Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com From dan at doxpara.com Sat Mar 16 02:01:08 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 15 Mar 2002 07:01:08 -0800 Subject: Key Pair Conversion Openssh => SSH2 References: Message-ID: <008b01c1cc32$3ccaa870$1701000a@effugas> Oops, didn't finish that sentence. Q: Why no secsh key format throughout openssh? A: The short version: Our standard came first(and from Tatu!), their standard is one broken thing from a series of broken things, and the solution to the very, very real problem of users being unable to make remote servers integrate their local pubkeys into their authentication subsystems *isn't* to standardize on some file format but rather to make key exchange an integral part of the protocol. Using file operations to control a network protocol is incorrect, inconsistent, and perhaps even generally wrong. Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com From bugzilla-daemon at mindrot.org Sat Mar 16 03:30:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 16 Mar 2002 03:30:27 +1100 (EST) Subject: [Bug 167] WARNING: sys/ttcompat.h: present but cannot be compiled. Message-ID: <20020315163027.20DA0EBDA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=167 ------- Additional Comments From stevesk at pobox.com 2002-03-16 03:30 ------- the error is for use of an indefined type: "/usr/include/sys/ttcompat.h", line 48: syntax error before or at: mblk_t "/usr/include/sys/ttcompat.h", line 48: cannot recover from previous errors cc: acomp failed for conftest.c i think it needs sys/stream.h defined prior. i would guess the xterm problem is not caused by this. also, we do not use or HAVE_SYS_TTCOMPAT_H so why do we test for it? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jason at dour.org Sat Mar 16 04:20:47 2002 From: jason at dour.org (Jason A. Dour) Date: Fri, 15 Mar 2002 12:20:47 -0500 Subject: PATCH: sftp-server logging. Message-ID: <20020315122047.A22509@dour.org> This is another take on logging for sftp-server. Given the number of private email requests I've received for this patch, I assume there is signifigant enough interest to request it be reviewed for inclusion into the release. The patch is against 3.1p1, and is completely disabled by default. To enable logging, one must use compile time directives (-DSFTP_LOGGING). This was done due to prior comments by openssh developers who felt logging should be a disable alternative at best. Feedback is appreciated. Cheers, Jason # "Jason A. Dour" http://dour.org/ # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ -------------- next part -------------- *** sftp-server.c.orig Thu Mar 14 15:00:51 2002 --- sftp-server.c Fri Mar 15 11:57:48 2002 *************** *** 52,57 **** --- 52,66 ---- /* Version of client */ int version; + #ifdef SFTP_LOGGING + /* User information. */ + #define CUNAME cuname ? cuname : "UNKNOWN" + struct passwd *upw; + uid_t cuid; + pid_t ppid; + char *cuname; + #endif + /* portable attibutes, etc. */ typedef struct Stat Stat; *************** *** 93,98 **** --- 102,126 ---- return ret; } + #ifdef SFTP_LOGGING + char* + status_to_logstr(int status) + { + switch (status) { + case SSH2_FX_OK: + return "Successful"; + case SSH2_FX_NO_SUCH_FILE: + return "No such file or directory"; + case SSH2_FX_PERMISSION_DENIED: + return "Permission denied."; + case SSH2_FX_BAD_MESSAGE: + return "Bad message"; + default: + return "Unknown error"; + } + } + #endif + static int flags_from_portable(int pflags) { *************** *** 115,120 **** --- 143,173 ---- return flags; } + #ifdef SFTP_LOGGING + void + sflags_from_portable(char *psflags, int pflags) + { + if (pflags & SSH2_FXF_READ) + *psflags = 'r'; + psflags++; + if (pflags & SSH2_FXF_WRITE) + *psflags = 'w'; + psflags++; + if (pflags & SSH2_FXF_APPEND) + *psflags = 'a'; + psflags++; + if (pflags & SSH2_FXF_CREAT) + *psflags = 'c'; + psflags++; + if (pflags & SSH2_FXF_TRUNC) + *psflags = 't'; + psflags++; + if (pflags & SSH2_FXF_EXCL) + *psflags = 'e'; + return; + } + #endif + static Attrib * get_attrib(void) { *************** *** 370,375 **** --- 423,431 ---- version = buffer_get_int(&iqueue); TRACE("client version %d", version); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Client version %d.", ppid, cuid, CUNAME, version); + #endif buffer_init(&msg); buffer_put_char(&msg, SSH2_FXP_VERSION); buffer_put_int(&msg, SSH2_FILEXFER_VERSION); *************** *** 383,388 **** --- 439,447 ---- u_int32_t id, pflags; Attrib *a; char *name; + #ifdef SFTP_LOGGING + char sflags[7] = "------"; + #endif int handle, fd, flags, mode, status = SSH2_FX_FAILURE; id = get_int(); *************** *** 390,407 **** --- 449,478 ---- pflags = get_int(); /* portable flags */ a = get_attrib(); flags = flags_from_portable(pflags); + #ifdef SFTP_LOGGING + sflags_from_portable(&sflags[0], pflags); + #endif mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm : 0666; TRACE("open id %d name %s flags %d mode 0%o", id, name, pflags, mode); fd = open(name, flags, mode); if (fd < 0) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) File/Dir open failed - %s: %s (%s,%04o)", ppid, cuid, CUNAME, status_to_logstr(status), name, sflags, mode); + #endif } else { handle = handle_new(HANDLE_FILE, xstrdup(name), fd, NULL); if (handle < 0) { close(fd); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) File/Dir open failed - Could not allocate SFTP handle: %s (%s,%04o).", ppid, cuid, CUNAME, name, sflags, mode); + #endif } else { send_handle(id, handle); status = SSH2_FX_OK; + #ifdef SFTP_LOGGING + log("(%d/%d/%s) File/Dir opened: %s (%s,%04o).", ppid, cuid, CUNAME, name, sflags, mode); + #endif } } if (status != SSH2_FX_OK) *************** *** 591,613 **** TRACE("setstat id %d name %s", id, name); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { ret = truncate(name, a->size); ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { ret = chmod(name, a->perm & 0777); ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) { ret = utimes(name, attrib_to_tv(a)); ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { ret = chown(name, a->uid, a->gid); ! if (ret == -1) status = errno_to_portable(errno); } send_status(id, status); xfree(name); --- 662,708 ---- TRACE("setstat id %d name %s", id, name); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { ret = truncate(name, a->size); ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Truncate file failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); + } else { + log("(%d/%d/%s) Truncated file: %s.", ppid, cuid, CUNAME, name); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { ret = chmod(name, a->perm & 0777); ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir permissions failed - %s: %s (%04o).", ppid, cuid, CUNAME, status_to_logstr(status), name, a->perm & 0777); + } else { + log("(%d/%d/%s) Set file/dir permissions: %s (%04o).", ppid, cuid, CUNAME, name, a->perm & 0777); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) { ret = utimes(name, attrib_to_tv(a)); ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir times failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); + } else { + log("(%d/%d/%s) Set file/dir times: %s.", ppid, cuid, CUNAME, name); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { ret = chown(name, a->uid, a->gid); ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir owner/group failed - %s: %s (%d/%d).", ppid, cuid, CUNAME, status_to_logstr(status), name, a->uid, a->gid); + } else { + log("(%d/%d/%s) Set file/dir owner/group: %s (%d/%d).", ppid, cuid, CUNAME, name, a->uid, a->gid); + #endif + } } send_status(id, status); xfree(name); *************** *** 630,640 **** name = handle_to_name(handle); if (fd < 0 || name == NULL) { status = SSH2_FX_FAILURE; } else { if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { ret = ftruncate(fd, a->size); ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { #ifdef HAVE_FCHMOD --- 725,744 ---- name = handle_to_name(handle); if (fd < 0 || name == NULL) { status = SSH2_FX_FAILURE; + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir stats failed - could not get name from handle: %d.", ppid, cuid, CUNAME, handle); + #endif } else { if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { ret = ftruncate(fd, a->size); ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Truncate file failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); + } else { + log("(%d/%d/%s) Truncated file: %s.", ppid, cuid, CUNAME, name); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { #ifdef HAVE_FCHMOD *************** *** 642,649 **** #else ret = chmod(name, a->perm & 0777); #endif ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) { #ifdef HAVE_FUTIMES --- 746,759 ---- #else ret = chmod(name, a->perm & 0777); #endif ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir permissions failed - %s: %s (%04o).", ppid, cuid, CUNAME, status_to_logstr(status), name, a->perm & 0777); + } else { + log("(%d/%d/%s) Set file/dir permissions: %s (%04o).", ppid, cuid, CUNAME, name, a->perm & 0777); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_ACMODTIME) { #ifdef HAVE_FUTIMES *************** *** 651,658 **** #else ret = utimes(name, attrib_to_tv(a)); #endif ! if (ret == -1) status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { #ifdef HAVE_FCHOWN --- 761,774 ---- #else ret = utimes(name, attrib_to_tv(a)); #endif ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir times failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); + } else { + log("(%d/%d/%s) Set file/dir times: %s.", ppid, cuid, CUNAME, name); + #endif + } } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { #ifdef HAVE_FCHOWN *************** *** 660,667 **** #else ret = chown(name, a->uid, a->gid); #endif ! if (ret == -1) status = errno_to_portable(errno); } } send_status(id, status); --- 776,789 ---- #else ret = chown(name, a->uid, a->gid); #endif ! if (ret == -1) { status = errno_to_portable(errno); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Set file/dir owner/group failed - %s: %s (%d/%d).", ppid, cuid, CUNAME, status_to_logstr(status), name, a->uid, a->gid); + } else { + log("(%d/%d/%s) Set file/dir owner/group: %s (%d/%d).", ppid, cuid, CUNAME, name, a->uid, a->gid); + #endif + } } } send_status(id, status); *************** *** 804,810 **** name = get_string(NULL); TRACE("remove id %d name %s", id, name); ret = unlink(name); ! status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; send_status(id, status); xfree(name); } --- 926,942 ---- name = get_string(NULL); TRACE("remove id %d name %s", id, name); ret = unlink(name); ! if (ret == -1) { ! status = errno_to_portable(errno); ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) File deletion failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); ! #endif ! } else { ! status = SSH2_FX_OK; ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) File deleted: %s.", ppid, cuid, CUNAME, name); ! #endif ! } send_status(id, status); xfree(name); } *************** *** 824,830 **** a->perm & 0777 : 0777; TRACE("mkdir id %d name %s mode 0%o", id, name, mode); ret = mkdir(name, mode); ! status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; send_status(id, status); xfree(name); } --- 956,972 ---- a->perm & 0777 : 0777; TRACE("mkdir id %d name %s mode 0%o", id, name, mode); ret = mkdir(name, mode); ! if (ret == -1) { ! status = errno_to_portable(errno); ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Directory creation failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); ! #endif ! } else { ! status = SSH2_FX_OK; ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Directory created: %s.", ppid, cuid, CUNAME, name); ! #endif ! } send_status(id, status); xfree(name); } *************** *** 840,846 **** name = get_string(NULL); TRACE("rmdir id %d name %s", id, name); ret = rmdir(name); ! status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; send_status(id, status); xfree(name); } --- 982,998 ---- name = get_string(NULL); TRACE("rmdir id %d name %s", id, name); ret = rmdir(name); ! if (ret == -1) { ! status = errno_to_portable(errno); ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Directory deletion failed - %s: %s.", ppid, cuid, CUNAME, status_to_logstr(status), name); ! #endif ! } else { ! status = SSH2_FX_OK; ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Directory deleted: %s.", ppid, cuid, CUNAME, name); ! #endif ! } send_status(id, status); xfree(name); } *************** *** 885,891 **** /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { ret = rename(oldpath, newpath); ! status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; } send_status(id, status); xfree(oldpath); --- 1037,1057 ---- /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { ret = rename(oldpath, newpath); ! if (ret == -1) { ! status = errno_to_portable(errno); ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) File/Dir renaming failed - %s: %s -> %s.", ppid, cuid, CUNAME, status_to_logstr(status), oldpath, newpath); ! #endif ! } else { ! status = SSH2_FX_OK; ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) File/Dir renamed: %s -> %s.", ppid, cuid, CUNAME, oldpath, newpath); ! #endif ! } ! #ifdef SFTP_LOGGING ! } else { ! log("(%d/%d/%s) File/Dir renaming failed - Target name exists: %s -> %s.", ppid, cuid, CUNAME, oldpath, newpath); ! #endif } send_status(id, status); xfree(oldpath); *************** *** 931,937 **** /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { ret = symlink(oldpath, newpath); ! status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; } send_status(id, status); xfree(oldpath); --- 1097,1117 ---- /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { ret = symlink(oldpath, newpath); ! if (ret == -1) { ! status = errno_to_portable(errno); ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Symbolic link creation failed - %s: %s -> %s.", ppid, cuid, CUNAME, status_to_logstr(status), oldpath, newpath); ! #endif ! } else { ! status = SSH2_FX_OK; ! #ifdef SFTP_LOGGING ! log("(%d/%d/%s) Symbolic link created: %s -> %s.", ppid, cuid, CUNAME, oldpath, newpath); ! #endif ! } ! #ifdef SFTP_LOGGING ! } else { ! log("(%d/%d/%s) Symbolic link creation failed - Target name exists: %s -> %s.", ppid, cuid, CUNAME, oldpath, newpath); ! #endif } send_status(id, status); xfree(oldpath); *************** *** 946,951 **** --- 1126,1134 ---- id = get_int(); request = get_string(NULL); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) Extended operation attempted - Ignoring.", ppid, cuid, CUNAME); + #endif send_status(id, SSH2_FX_OP_UNSUPPORTED); /* MUST */ xfree(request); } *************** *** 965,970 **** --- 1148,1156 ---- msg_len = GET_32BIT(cp); if (msg_len > 256 * 1024) { error("bad message "); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) SFTP session closing (%s).", ppid, cuid, CUNAME, "Bad Message"); + #endif exit(11); } if (buffer_len(&iqueue) < msg_len + 4) *************** *** 1050,1055 **** --- 1236,1260 ---- __progname = get_progname(av[0]); handle_init(); + #ifdef SFTP_LOGGING + /* Initialize the username of the user running the process. */ + cuid = getuid(); + if ((upw = getpwuid(cuid)) == NULL) { + cuname = NULL; + } else { + cuname = xstrdup(upw->pw_name); + } + + /* Initialize the parent process ID. */ + ppid = getppid(); + + /* Initialize the logfile. */ + log_init("sftp-server", SYSLOG_LEVEL_INFO, SYSLOG_FACILITY_AUTH, 0); + + /* Log session start. */ + log("(%d/%d/%s) SFTP session started.", ppid, cuid, CUNAME); + #endif + #ifdef DEBUG_SFTP_SERVER log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0); #endif *************** *** 1087,1092 **** --- 1292,1300 ---- if (select(max+1, rset, wset, NULL, NULL) < 0) { if (errno == EINTR) continue; + #ifdef SFTP_LOGGING + log("(%d/%d/%s) SFTP session closing (%s).", ppid, cuid, CUNAME, "Select Error"); + #endif exit(2); } *************** *** 1096,1104 **** --- 1304,1318 ---- len = read(in, buf, sizeof buf); if (len == 0) { debug("read eof"); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) SFTP session closing (%s).", ppid, cuid, CUNAME, "EOF"); + #endif exit(0); } else if (len < 0) { error("read error"); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) SFTP session closing (%s).", ppid, cuid, CUNAME, "Read Error"); + #endif exit(1); } else { buffer_append(&iqueue, buf, len); *************** *** 1109,1114 **** --- 1323,1331 ---- len = write(out, buffer_ptr(&oqueue), olen); if (len < 0) { error("write error"); + #ifdef SFTP_LOGGING + log("(%d/%d/%s) SFTP session closing (%s).", ppid, cuid, CUNAME, "Write Error"); + #endif exit(1); } else { buffer_consume(&oqueue, len); From mouring at etoh.eviladmin.org Sat Mar 16 03:52:24 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 15 Mar 2002 10:52:24 -0600 (CST) Subject: PATCH: sftp-server logging. In-Reply-To: <20020315122047.A22509@dour.org> Message-ID: For argument sake: + if ((upw = getpwuid(cuid)) == NULL) { + cuname = NULL; + } else { + cuname = xstrdup(upw->pw_name); + } Ermm.. Under what case should getpwuid() fail and still allow the user to keep the connection? I can think of none. It should terminate with an error. - Ben On Fri, 15 Mar 2002, Jason A. Dour wrote: > This is another take on logging for sftp-server. Given the number > of private email requests I've received for this patch, I assume > there is signifigant enough interest to request it be reviewed for > inclusion into the release. > > The patch is against 3.1p1, and is completely disabled by default. > To enable logging, one must use compile time directives > (-DSFTP_LOGGING). This was done due to prior comments by openssh > developers who felt logging should be a disable alternative at best. > > Feedback is appreciated. > > > Cheers, > Jason > # "Jason A. Dour" http://dour.org/ > # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ > From jason at dour.org Sat Mar 16 05:49:03 2002 From: jason at dour.org (Jason A. Dour) Date: Fri, 15 Mar 2002 13:49:03 -0500 Subject: PATCH: sftp-server logging. In-Reply-To: References: <20020315122047.A22509@dour.org> Message-ID: <20020315134903.B22509@dour.org> On Fri, Mar 15, 2002 at 10:52:24AM -0600, Ben Lindstrom wrote: > > For argument sake: > > + if ((upw = getpwuid(cuid)) == NULL) { > + cuname = NULL; > + } else { > + cuname = xstrdup(upw->pw_name); > + } > > Ermm.. Under what case should getpwuid() fail and still allow the > user to keep the connection? I can think of none. It should > terminate with an error. I didn't make it fail because sftp-server (presently) does not do any checking on the validity of the user calling the program, instead relying on the sshd to handle all sanity checking. It would be easy enough to dump out with an error, but that would've changed the order of operations for sftp-server beyond the scopr of just logging, which is something I would leave for discussions here. If that's agreed to be a Good Thing, then I'll gladly alter and resubmit the patch. Any other thoughts? Cheers, Jason # "Jason A. Dour" http://dour.org/ # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ From drk at sgi.com Sat Mar 16 07:01:04 2002 From: drk at sgi.com (David Kaelbling) Date: Fri, 15 Mar 2002 15:01:04 -0500 Subject: Use of NGROUPS_MAX on IRIX Message-ID: <3C925300.3F3B3E35@sgi.com> On IRIX systems getgroups() can actually return as many as NGROUPS_UMAX entries (32), since NGROUPS_MAX (16) is tunable. Here is a small patch that uses the bigger constant: --- ./defines.h Tue Feb 26 11:40:49 2002 +++ ../openssh-3.1p1/./defines.h Fri Mar 15 14:29:34 2002 @@ -104,6 +104,11 @@ #endif #endif +#ifdef NGROUPS_UMAX +#undef NGROUPS_MAX +#define NGROUPS_MAX NGROUPS_UMAX +#endif + #ifndef O_NONBLOCK /* Non Blocking Open */ # define O_NONBLOCK 00004 #endif I hope that helps! David -- David KAELBLING Silicon Graphics Computer Systems 1 Cabot Rd, suite 250; Hudson, MA 01749 781.839.2157, fax ...2357 From drk at sgi.com Sat Mar 16 07:08:16 2002 From: drk at sgi.com (David Kaelbling) Date: Fri, 15 Mar 2002 15:08:16 -0500 Subject: Optional symbols on IRIX Message-ID: <3C9254B0.5E570C61@sgi.com> A couple days ago I mailed in a patch to use _MIPS_SYMBOL_PRESENT to test at run-time whether jlimit_startjob() was present IRIX systems. I neglected to mention that the patch I sent in wasn't entirely complete: a _real_ fix would test '#include ' in configure, and also require either the MipsPRO 7.2.x or MipsPRO 7.3.1.3 or newer compiler. David -- David KAELBLING Silicon Graphics Computer Systems 1 Cabot Rd, suite 250; Hudson, MA 01749 781.839.2157, fax ...2357 From olm at csun.edu Sat Mar 16 10:15:21 2002 From: olm at csun.edu (Ovanes Manucharyan) Date: Fri, 15 Mar 2002 15:15:21 -0800 (PST) Subject: Problems compiling on Redhat Message-ID: Hello, I have a x86 Red Hat Linux release 7.0 (Guinness) box. OpenSSL 0.9.6b I downloaded the most recent version of OpenSSH (3.1p1). Attached is the result of ./configure and make. Thanks in advance -------------- next part -------------- # ./configure 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... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking whether byte ordering is bigendian... no checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD compatible install... /usr/bin/install -c checking for ar... /usr/bin/ar checking for perl5... no checking for perl... /usr/bin/perl checking for ent... no checking for filepriv... no checking for bash... /bin/bash checking for ksh... (cached) /bin/bash checking for sh... (cached) /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... /bin/login checking for gcc option to accept ANSI C... none needed checking for inline... inline checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking bstring.h usability... no checking bstring.h presence... no checking for bstring.h... no checking crypt.h usability... yes checking crypt.h presence... yes checking for crypt.h... yes checking endian.h usability... yes checking endian.h presence... yes checking for endian.h... yes checking floatingpoint.h usability... no checking floatingpoint.h presence... no checking for floatingpoint.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking glob.h usability... yes checking glob.h presence... yes checking for glob.h... yes checking lastlog.h usability... yes checking lastlog.h presence... yes checking for lastlog.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking login.h usability... no checking login.h presence... no checking for login.h... no checking login_cap.h usability... no checking login_cap.h presence... no checking for login_cap.h... no checking maillock.h usability... no checking maillock.h presence... no checking for maillock.h... no checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netgroup.h usability... no checking netgroup.h presence... no checking for netgroup.h... no checking netinet/in_systm.h usability... yes checking netinet/in_systm.h presence... yes checking for netinet/in_systm.h... yes checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pty.h usability... yes checking pty.h presence... yes checking for pty.h... yes checking security/pam_appl.h usability... yes checking security/pam_appl.h presence... yes checking for security/pam_appl.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdint.h... (cached) yes checking for strings.h... (cached) yes checking sys/bitypes.h usability... yes checking sys/bitypes.h presence... yes checking for sys/bitypes.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/queue.h usability... yes checking sys/queue.h presence... yes checking for sys/queue.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking sys/stropts.h usability... yes checking sys/stropts.h presence... yes checking for sys/stropts.h... yes checking sys/sysmacros.h usability... yes checking sys/sysmacros.h presence... yes checking for sys/sysmacros.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/ttcompat.h usability... no checking sys/ttcompat.h presence... no checking for sys/ttcompat.h... no checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking ttyent.h usability... yes checking ttyent.h presence... yes checking for ttyent.h... yes checking usersec.h usability... no checking usersec.h presence... no checking for usersec.h... no checking util.h usability... no checking util.h presence... no checking for util.h... no checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking utmpx.h usability... yes checking utmpx.h presence... yes checking for utmpx.h... yes checking for yp_match... no checking for yp_match in -lnsl... yes checking for setsockopt... yes checking for getspnam... yes checking for deflate in -lz... yes checking for strcasecmp... yes checking for utimes... yes checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking for library containing login... -lutil checking for logout... yes checking for updwtmp... yes checking for logwtmp... yes checking for strftime... yes checking for GLOB_ALTDIRFUNC support... yes checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... yes checking for arc4random... no checking for atexit... yes checking for b64_ntop... no checking for bcopy... yes checking for bindresvport_sa... no checking for clock... yes checking for fchmod... yes checking for fchown... yes checking for freeaddrinfo... yes checking for futimes... no checking for gai_strerror... yes checking for getaddrinfo... yes checking for getcwd... yes checking for getgrouplist... no checking for getnameinfo... yes checking for getopt... yes checking for getrlimit... yes checking for getrusage... yes checking for getttyent... yes checking for glob... yes checking for inet_aton... yes checking for inet_ntoa... yes checking for inet_ntop... yes checking for innetgr... yes checking for login_getcapbool... no checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... yes checking for on_exit... yes checking for openpty... yes checking for readpassphrase... no checking for realpath... yes checking for rresvport_af... yes checking for setdtablesize... no checking for setegid... yes checking for setenv... yes checking for seteuid... yes checking for setlogin... no checking for setproctitle... no checking for setresgid... yes checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for sigvec... yes checking for snprintf... yes checking for strerror... yes checking for strlcat... no checking for strlcpy... no checking for strmode... no checking for strsep... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for utimes... (cached) yes checking for vhangup... yes checking for vsnprintf... yes checking for waitpid... yes checking for __b64_ntop... no checking for _getpty... no checking for dirname... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking for gettimeofday... yes checking for time... yes checking for endutent... yes checking for getutent... yes checking for getutid... yes checking for getutline... yes checking for pututline... yes checking for setutent... yes checking for utmpname... yes checking for endutxent... yes checking for getutxent... yes checking for getutxid... yes checking for getutxline... yes checking for pututxline... yes checking for setutxent... yes checking for utmpxname... yes checking for getuserattr... no checking for getuserattr in -ls... no checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether getpgrp takes no argument... yes checking for OpenSSL directory... (system) checking for RSA support... yes checking whether OpenSSL's headers match the library... yes checking for crypt in -lcrypt... yes checking whether OpenSSL's PRNG is internally seeded... yes checking for ls... /bin/ls checking for netstat... /bin/netstat checking for arp... /sbin/arp checking for ifconfig... /sbin/ifconfig checking for jstat... no checking for ps... /bin/ps checking for sar... no checking for w... /usr/bin/w checking for who... /usr/bin/who checking for last... /usr/bin/last checking for lastlog... /usr/bin/lastlog checking for df... /bin/df checking for vmstat... /usr/bin/vmstat checking for uptime... /usr/bin/uptime checking for ipcs... /usr/bin/ipcs checking for tail... /usr/bin/tail checking for char... yes checking size of char... 1 checking for short int... yes checking size of short int... 2 checking for int... yes checking size of int... 4 checking for long int... yes checking size of long int... 4 checking for long long int... yes checking size of long long int... 8 checking for u_int type... yes checking for intXX_t types... yes checking for int64_t type... yes checking for u_intXX_t types... yes checking for u_int64_t types... yes checking for uintXX_t types in stdint.h... yes checking for u_char... yes checking for socklen_t... yes checking for sig_atomic_t... yes checking for size_t... yes checking for ssize_t... yes checking for clock_t... yes checking for sa_family_t... yes checking for pid_t... yes checking for mode_t... yes checking for struct sockaddr_storage... yes checking for struct sockaddr_in6... yes checking for struct in6_addr... yes checking for struct addrinfo... yes checking for struct timeval... yes checking for ut_host field in utmp.h... yes checking for ut_host field in utmpx.h... yes checking for syslen field in utmpx.h... no checking for ut_pid field in utmp.h... yes checking for ut_type field in utmp.h... yes checking for ut_type field in utmpx.h... yes checking for ut_tv field in utmp.h... yes checking for ut_id field in utmp.h... yes checking for ut_id field in utmpx.h... yes checking for ut_addr field in utmp.h... yes checking for ut_addr field in utmpx.h... yes checking for ut_addr_v6 field in utmp.h... yes checking for ut_addr_v6 field in utmpx.h... yes checking for ut_exit field in utmp.h... yes checking for ut_time field in utmp.h... no checking for ut_time field in utmpx.h... no checking for ut_tv field in utmpx.h... yes checking for struct stat.st_blksize... yes checking for ss_family field in struct sockaddr_storage... no checking for __ss_family field in struct sockaddr_storage... yes checking for pw_class field in struct passwd... no checking for pw_expire field in struct passwd... no checking for pw_change field in struct passwd... no checking if libc defines __progname... yes checking whether getopt has optreset support... no checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes checking for rsh... no checking for xauth... no checking for "/dev/ptc"... no checking for nroff... /usr/bin/nroff checking if the systems has expire shadow information... yes Adding /usr/local/bin to USER_PATH so scp will work checking if we need to convert IPv4 in IPv6-mapped addresses... yes (default) checking whether to install ssh as suid root... yes checking if your system defines LASTLOG_FILE... no checking if your system defines _PATH_LASTLOG... yes checking if your system defines UTMP_FILE... yes checking if your system defines WTMP_FILE... yes checking if your system defines UTMPX_FILE... no checking if your system defines WTMPX_FILE... no configure: creating ./config.status config.status: creating Makefile config.status: creating openbsd-compat/Makefile config.status: creating scard/Makefile config.status: creating ssh_prng_cmds config.status: creating config.h OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no KerberosIV support: no Smartcard support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: Linker flags: Libraries: -lutil -lz -lnsl -lcrypto -lcrypt # make conffile=`echo sshd_config.out | sed 's/.out$//'`; \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ./${conffile} > sshd_config.out conffile=`echo ssh_config.out | sed 's/.out$//'`; \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ./${conffile} > ssh_config.out conffile=`echo moduli.out | sed 's/.out$//'`; \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ./${conffile} > moduli.out if test "doc" = "cat"; then \ manpage=./`echo scp.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo scp.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > scp.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > scp.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo ssh-add.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo ssh-add.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > ssh-add.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > ssh-add.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo ssh-agent.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo ssh-agent.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > ssh-agent.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > ssh-agent.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo ssh-keygen.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo ssh-keygen.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > ssh-keygen.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > ssh-keygen.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo ssh-keyscan.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo ssh-keyscan.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > ssh-keyscan.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > ssh-keyscan.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo ssh.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo ssh.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > ssh.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > ssh.1.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo sshd.8.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo sshd.8.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > sshd.8.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > sshd.8.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo sftp-server.8.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo sftp-server.8.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > sftp-server.8.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > sftp-server.8.out; \ fi if test "doc" = "cat"; then \ manpage=./`echo sftp.1.out | sed 's/\.[1-9]\.out$/\.0/'`; \ else \ manpage=./`echo sftp.1.out | sed 's/\.out$//'`; \ fi; \ if test "doc" = "man"; then \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} | /usr/bin/perl ./mdoc2man.pl > sftp.1.out; \ else \ /usr/bin/perl ./fixpaths -D/etc/ssh/ssh_config=/usr/local/etc/ssh_config -D/etc/ssh/ssh_known_hosts=/usr/local/etc/ssh_known_hosts -D/etc/ssh/sshd_config=/usr/local/etc/sshd_config -D/usr/libexec=/usr/local/libexec -D/etc/shosts.equiv=/usr/local/etc/shosts.equiv -D/etc/ssh/ssh_host_key=/usr/local/etc/ssh_host_key -D/etc/ssh/ssh_host_dsa_key=/usr/local/etc/ssh_host_dsa_key -D/etc/ssh/ssh_host_rsa_key=/usr/local/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/var/run/sshd.pid -D/etc/ssh/moduli=/usr/local/etc/moduli -D/etc/ssh/sshrc=/usr/local/etc/sshrc -D/usr/X11R6/bin/xauth=undefined -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin ${manpage} > sftp.1.out; \ fi (cd openbsd-compat && make) make[1]: Entering directory `/usr/local/src/openssh/openssh-3.1p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-arc4random.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-cray.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-cygwin_util.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-misc.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-nextstep.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-snprintf.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-waitpid.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c fake-getaddrinfo.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c fake-getnameinfo.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c base64.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bindresvport.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c daemon.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c dirname.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c getcwd.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c getgrouplist.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c getopt.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c glob.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c inet_aton.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c inet_ntoa.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c inet_ntop.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c mktemp.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c readpassphrase.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c realpath.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c rresvport.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c setenv.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c setproctitle.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c sigact.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c strlcat.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c strlcpy.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c strmode.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c strsep.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c port-irix.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c port-aix.c /usr/bin/ar rv libopenbsd-compat.a bsd-arc4random.o bsd-cray.o bsd-cygwin_util.o bsd-misc.o bsd-nextstep.o bsd-snprintf.o bsd-waitpid.o fake-getaddrinfo.o fake-getnameinfo.o base64.o bindresvport.o daemon.o dirname.o getcwd.o getgrouplist.o getopt.o glob.o inet_aton.o inet_ntoa.o inet_ntop.o mktemp.o readpassphrase.o realpath.o rresvport.o setenv.o setproctitle.o sigact.o strlcat.o strlcpy.o strmode.o strsep.o port-irix.o port-aix.o a - bsd-arc4random.o a - bsd-cray.o a - bsd-cygwin_util.o a - bsd-misc.o a - bsd-nextstep.o a - bsd-snprintf.o a - bsd-waitpid.o a - fake-getaddrinfo.o a - fake-getnameinfo.o a - base64.o a - bindresvport.o a - daemon.o a - dirname.o a - getcwd.o a - getgrouplist.o a - getopt.o a - glob.o a - inet_aton.o a - inet_ntoa.o a - inet_ntop.o a - mktemp.o a - readpassphrase.o a - realpath.o a - rresvport.o a - setenv.o a - setproctitle.o a - sigact.o a - strlcat.o a - strlcpy.o a - strmode.o a - strsep.o a - port-irix.o a - port-aix.o ranlib libopenbsd-compat.a make[1]: Leaving directory `/usr/local/src/openssh/openssh-3.1p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c atomicio.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c authfd.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c authfile.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c bufaux.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c buffer.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c canohost.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c channels.c gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c: In function `cipher_init': cipher.c:200: void value not ignored as it ought to be cipher.c:206: warning: implicit declaration of function `EVP_CIPHER_CTX_set_key_length' cipher.c:210: void value not ignored as it ought to be cipher.c: In function `cipher_crypt': cipher.c:220: void value not ignored as it ought to be cipher.c: In function `cipher_cleanup': cipher.c:227: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_init': cipher.c:280: warning: assignment from incompatible pointer type cipher.c:299: void value not ignored as it ought to be cipher.c:300: void value not ignored as it ought to be cipher.c:301: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cbc': cipher.c:314: warning: assignment from incompatible pointer type cipher.c:318: void value not ignored as it ought to be cipher.c:319: void value not ignored as it ought to be cipher.c:320: void value not ignored as it ought to be cipher.c: In function `ssh1_3des_cleanup': cipher.c:329: warning: assignment from incompatible pointer type cipher.c: In function `evp_ssh1_3des': cipher.c:346: warning: assignment from incompatible pointer type cipher.c:347: warning: assignment from incompatible pointer type cipher.c:348: warning: assignment from incompatible pointer type cipher.c:349: structure has no member named `flags' cipher.c:349: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:349: (Each undeclared identifier is reported only once cipher.c:349: for each function it appears in.) cipher.c:349: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c: In function `evp_ssh1_bf': cipher.c:392: warning: assignment from incompatible pointer type cipher.c:394: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_init': cipher.c:413: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cbc': cipher.c:440: warning: assignment from incompatible pointer type cipher.c: In function `ssh_rijndael_cleanup': cipher.c:477: warning: assignment from incompatible pointer type cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 From pekkas at netcore.fi Sat Mar 16 19:11:17 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 16 Mar 2002 10:11:17 +0200 (EET) Subject: Problems compiling on Redhat In-Reply-To: Message-ID: On Fri, 15 Mar 2002, Ovanes Manucharyan wrote: > I have a x86 Red Hat Linux release 7.0 (Guinness) box. > > OpenSSL 0.9.6b > > I downloaded the most recent version of OpenSSH (3.1p1). > > Attached is the result of ./configure and make. Wrong; RHL7 had openssl 0.9.5a in as default, and 0.9.6 as an errata. I believe yours is still 0.9.5a, from the look of the errors. -- 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 olm at csun.edu Sat Mar 16 22:54:46 2002 From: olm at csun.edu (Ovanes Manucharyan) Date: Sat, 16 Mar 2002 03:54:46 -0800 (PST) Subject: Problems compiling on Redhat In-Reply-To: Message-ID: Well, I tried to configure it using --with-ssl-dir=/usr/local/ssl Anything else I can do? (I've confirmed the one in /usr/local/ssl is 0.9.6b) Ovanes On Sat, 16 Mar 2002, Pekka Savola wrote: > On Fri, 15 Mar 2002, Ovanes Manucharyan wrote: > > I have a x86 Red Hat Linux release 7.0 (Guinness) box. > > > > OpenSSL 0.9.6b > > > > I downloaded the most recent version of OpenSSH (3.1p1). > > > > Attached is the result of ./configure and make. > > Wrong; RHL7 had openssl 0.9.5a in as default, and 0.9.6 as an errata. > > I believe yours is still 0.9.5a, from the look of the errors. > > -- > 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 olm at csun.edu Sat Mar 16 23:08:17 2002 From: olm at csun.edu (Ovanes Manucharyan) Date: Sat, 16 Mar 2002 04:08:17 -0800 (PST) Subject: Problems compiling on Redhat In-Reply-To: Message-ID: I removed all my openssl 0.9.5a related files in /usr/ and symlinked them to the one in /usr/local/ssl I believe OpenSSH doesn't follow the --with-ssl-dir directive very well. On Sat, 16 Mar 2002, Pekka Savola wrote: > On Fri, 15 Mar 2002, Ovanes Manucharyan wrote: > > I have a x86 Red Hat Linux release 7.0 (Guinness) box. > > > > OpenSSL 0.9.6b > > > > I downloaded the most recent version of OpenSSH (3.1p1). > > > > Attached is the result of ./configure and make. > > Wrong; RHL7 had openssl 0.9.5a in as default, and 0.9.6 as an errata. > > I believe yours is still 0.9.5a, from the look of the errors. From bugzilla-daemon at mindrot.org Sun Mar 17 04:16:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:16:37 +1100 (EST) Subject: [Bug 169] New: make install fails on redhat 6.2 Message-ID: <20020316171637.B0D63E9CF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=169 Summary: make install fails on redhat 6.2 Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: wzeikat at gmx.de after running ./configure --prefix=/opt, make works, make install then fails with: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/opt -DSSHDIR=\"/opt/etc\" -D_PATH_SSH_PROGRAM=\"/opt/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/opt/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c dh.c cipher.c: In function `evp_rijndael': cipher.c:494: warning: assignment from incompatible pointer type cipher.c:495: warning: assignment from incompatible pointer type cipher.c:496: warning: assignment from incompatible pointer type cipher.c:497: structure has no member named `flags' cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 make: *** Waiting for unfinished jobs.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Sun Mar 17 04:11:08 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 16 Mar 2002 09:11:08 -0800 (PST) Subject: Problems compiling on Redhat In-Reply-To: Message-ID: On Sat, 16 Mar 2002, Ovanes Manucharyan wrote: > I removed all my openssl 0.9.5a related files in /usr/ and > symlinked them to the one in /usr/local/ssl > > I believe OpenSSH doesn't follow the --with-ssl-dir directive > very well. The --with-ssl-dir directive works fine here. What problems ar you seeing? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sun Mar 17 04:26:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:26:42 +1100 (EST) Subject: [Bug 169] make install fails on redhat 6.2 Message-ID: <20020316172642.8C425E9D8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=169 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From markus at openbsd.org 2002-03-17 04:26 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 04:26:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:26:48 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020316172648.9FE50E9DA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wzeikat at gmx.de ------- Additional Comments From markus at openbsd.org 2002-03-17 04:26 ------- *** Bug 169 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 04:31:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:31:15 +1100 (EST) Subject: [Bug 148] Key Exchange Guesses not supported Message-ID: <20020316173115.A16C4E9E1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=148 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|markus at openbsd.org Status|ASSIGNED |NEW ------- Additional Comments From markus at openbsd.org 2002-03-17 04:31 ------- todo: discard first packet after kexinit if first_kex_follows is set and peers first algorithms do not match selected althorithms. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 04:31:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:31:55 +1100 (EST) Subject: [Bug 165] Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020316173155.C2D5CE9E1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 ------- Additional Comments From markus at openbsd.org 2002-03-17 04:31 ------- never seen this. what does sshd -ddd say? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 04:45:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 04:45:38 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020316174538.14F3DE9D8@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From markus at openbsd.org 2002-03-17 04:45 ------- Created an attachment (id=45) this patch just affects the 'default keys' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 05:03:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 05:03:27 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020316180327.25A1EE9EC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From wzeikat at gmx.de 2002-03-17 05:03 ------- http://bugzilla.mindrot.org/showattachment.cgi?attach_id=37 - how do i apply that? if i simply replace cipher.c with it, i get this error: # make install (cd openbsd-compat && make) gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/opt -DSSHDIR=\"/opt/etc\" -D_PATH_SSH_PROGRAM=\"/opt/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DSSH_RAND_HELPER=\"/opt/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c cipher.c cipher.c:74: unterminated comment make: *** [cipher.o] Error 1 make: *** Waiting for unfinished jobs.... make[1]: Entering directory `/home/software/install/openssh-3.1p1/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/software/install/openssh-3.1p1/openbsd-compat' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 06:25:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 06:25:55 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020316192555.26094E93D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From wzeikat at gmx.de 2002-03-17 06:25 ------- thanks, that solved the problem with "make install" for me on RedHat 6.2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 17 06:29:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 06:29:34 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020316192934.7BD8CE9F1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 ------- Additional Comments From wzeikat at gmx.de 2002-03-17 06:29 ------- In the previous episode (16.03.2002, 13:47:51), Pat said: > > http://bugzilla.mindrot.org/showattachment.cgi?attach_id=37 - how do i > apply > > that? > > You use the "patch" utility. Something like this: > > cd /usr/local/src/openssh-3.1p1 > patch -p0 < ../patch.txt > > - Pat > thanks, that solved the problem with "make install" for me on RedHat 6.2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Sun Mar 17 14:21:36 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 17 Mar 2002 14:21:36 +1100 Subject: [patch] AIX package build fixes, please commit Message-ID: <3C940BC0.B48ABD0@zip.com.au> Hello All, This is a resend of a patch I posted nearly two weeks ago. As of a few minutes ago, it hasn't been committed and thus the AIX package builds from CVS fail. (I know because I now have a cron job that tells me :-) Could someone please review and commit the attached patch and chmod a+x contrib/aix/*.sh, or let me know what needs to be changed? It makes the following changes (relative to 3.1p1): * Gets version number from ssh -V as suggested by Tim Rice. * Does a better job of generating valid AIX package version numbers (fixes inutoc "format of the toc file is invalid" and "invalid level" errors reported by Mandar Mirashi). * Tests for "make install" failure and doesn't generate empty package in that case. * Generate file sizes in inventory file. Tested and resulting packages installed on AIX 4.2.1 and 4.3.3. Patch is also available here: http://www.zip.com.au/~dtucker/openssh-3.1p1-aixbff.patch -Daz. -------------- next part -------------- diff -c -r openssh-3.1p1/contrib/aix/buildbff.sh openssh-3.1p1-aix/contrib/aix/buildbff.sh *** openssh-3.1p1/contrib/aix/buildbff.sh Tue Mar 5 13:38:37 2002 --- openssh-3.1p1-aix/contrib/aix/buildbff.sh Sat Mar 9 11:43:36 2002 *************** *** 11,31 **** umask 022 PKGNAME=openssh ! PATH=$PATH:`pwd` # set path for external tools export PATH ! ## Extract common info requires for the 'info' part of the package. ! VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` ! BFFVERSION=`echo $VERSION | sed 's/p/./g'` ! ! echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" ! PKGDIR=package ! ! # Clean build directory and package file rm -rf $PKGDIR mkdir $PKGDIR - rm -f $PKGNAME-$VERSION.bff if [ ! -f ../../Makefile ] then --- 11,24 ---- umask 022 PKGNAME=openssh + PKGDIR=package ! PATH=`pwd`:$PATH # set path for external tools export PATH ! # Clean build directory rm -rf $PKGDIR mkdir $PKGDIR if [ ! -f ../../Makefile ] then *************** *** 40,45 **** --- 33,61 ---- cd ../.. make install-nokeys DESTDIR=$FAKE_ROOT + if [ $? -gt 0 ] + then + echo "Fake root install failed, stopping." + exit 1 + fi + + # + # Extract common info requires for the 'info' part of the package. + # AIX requires 4-part version numbers + # + VERSION=`./ssh -V 2>&1 | sed -e 's/,.*//' | cut -f 2 -d _` + MAJOR=`echo $VERSION | cut -f 1 -d p | cut -f 1 -d .` + MINOR=`echo $VERSION | cut -f 1 -d p | cut -f 2 -d .` + PATCH=`echo $VERSION | cut -f 1 -d p | cut -f 3 -d .` + PORTABLE=`echo $VERSION | cut -f 2 -d p` + if [ "$PATCH" = "" ] + then + PATCH=0 + fi + BFFVERSION=`printf "%d.%d.%d.%d" $MAJOR $MINOR $PATCH $PORTABLE` + + echo "Building BFF for $PKGNAME $VERSION (package version $BFFVERSION)" + # # Fill in some details, like prefix and sysconfdir # the eval also expands variables like sysconfdir=${prefix}/etc *************** *** 175,180 **** --- 191,197 ---- # file list on the fly and feed it to backup using -i # echo Creating $PKGNAME-$VERSION.bff with backup... + rm -f $PKGNAME-$VERSION.bff ( echo "./lpp_name" find . ! -name lpp_name -a ! -name . -print diff -c -r openssh-3.1p1/contrib/aix/inventory.sh openssh-3.1p1-aix/contrib/aix/inventory.sh *** openssh-3.1p1/contrib/aix/inventory.sh Tue Mar 5 13:38:37 2002 --- openssh-3.1p1-aix/contrib/aix/inventory.sh Sat Mar 9 11:04:45 2002 *************** *** 52,58 **** } elsif ( -f $_ ) { # Entry is File print "\ttype=FILE\n"; ! print "\tsize=VOLATILE\n"; print "\tchecksum=VOLATILE\n"; } elsif ( -d $_ ) { # Entry is Directory --- 52,58 ---- } elsif ( -f $_ ) { # Entry is File print "\ttype=FILE\n"; ! print "\tsize=$sz\n"; print "\tchecksum=VOLATILE\n"; } elsif ( -d $_ ) { # Entry is Directory From apronk at csi.co.nz Sun Mar 17 20:57:37 2002 From: apronk at csi.co.nz (Adrian Pronk) Date: Sun, 17 Mar 2002 21:57:37 +1200 Subject: [Bug 160] Race condition in clientloop.c? Message-ID: Not in 3.0.2p1? What about in the version I originally posted about, 3.1? >http://bugzilla.mindrot.org/show_bug.cgi?id=160 > >Nicolas.Williams at ubsw.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |FIXED > > > >------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-14 08:25 ------- >Aha! > >Yes, there is a race. It's there in 2.9p2, but apparently not in 3.0.2p1. > >Essentially the > >"if (compat20 && session_closed && !channel_still_open())" > >check at the top of the client loop is not close enough to the >call to select() in client_wait_until_can_do_something(). In fact, >client_wait_until_can_do_something() calls channel_prepare_select() >which calls channel_handler() which may well call chan_is_dead() >which may leave no channels open and yet >client_wait_until_can_do_something() will still go into the >select(). On Tue, Mar 12, 2002 at 11:27:19AM +1300, Adrian Pronk wrote: > I've just built openssh 3.1 for my Redhat 5.1 system (running on a 486 > DX-66) using the latest zlib and openssl libraries. > > Connecting to the machine with ssh seems to work fine (although it takes a > while to initiate a connection). > > But when I transfer a file to the machine with scp, it seems to work fine > and the scp completes, but an ssh sub-process remains behind on the client > and an sshd sub-process remains behind on the host. When I strace them, > the client is waiting on a socket and the host is waiting on three > different fd's (under 5.1, its hard to tell what they are without making an > effort :) ). > > I did not compile the system on the target machine (which is my firewall). > My old development machine was a RH 5.1 box. I bought a new box recently > and put RH 7.2 on it. I copied the development RH 5.1 file system on to it > (including /dev). I then chroot'ed to that directory , mounted a new /proc > and had my 5.1 development environment back. I compiled (make install) > openSSL, zlib, openSSH on this and copied the likely output files to the > target machine. I wouldn't think this development environment would break > anything. > > Does anyone know off the top of their heads what the problem might be? If > not, I'll get stuck in and have a look at the code and see if I can see > anything. -- Adrian From bugzilla-daemon at mindrot.org Sun Mar 17 23:41:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 17 Mar 2002 23:41:26 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020317124126.029B5E93F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |major Component|Documentation |Miscellaneous ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From friedrischm at yahoo.com Sun Mar 17 23:46:17 2002 From: friedrischm at yahoo.com (Friedrisch Muller) Date: Sun, 17 Mar 2002 04:46:17 -0800 (PST) Subject: logging of sftp transfers Message-ID: <20020317124617.1142.qmail@web21106.mail.yahoo.com> Hi, Would it be possible to add logging of sftp transfers in openssh? I've now tried openssh 3.1p1 on Linux 2.4.9 i686 and am running it with "LogLevel DEBUG3" but it still doesn't log any transfers (only lots of authentication messages). Would this be hard to add (please)? Regards / FM __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From markus at openbsd.org Mon Mar 18 07:06:38 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:06:38 +0100 Subject: 3.1p1 under Solaris x86 5.7 fails to compile ... In-Reply-To: <20020313112308.U308-100000@atelier.acadiau.ca>; from marc.fournier@acadiau.ca on Wed, Mar 13, 2002 at 11:23:49AM -0400 References: <20020313112308.U308-100000@atelier.acadiau.ca> Message-ID: <20020317210638.B15684@folly> http://bugzilla.mindrot.org/show_bug.cgi?id=138 From markus at openbsd.org Mon Mar 18 07:07:34 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:07:34 +0100 Subject: SCP or RCP standards In-Reply-To: ; from abhi@acc.com on Wed, Mar 13, 2002 at 07:02:49PM -0800 References: Message-ID: <20020317210734.C15684@folly> On Wed, Mar 13, 2002 at 07:02:49PM -0800, Abhijeet Thakare wrote: > I am looking for SCP or RCP standards. I searched on the web but I am not > able to find the standards. Please mail me the link where I can find the > standards for SCP or RCP. there is none. you have to check the scp/rcp source. it's free. From markus at openbsd.org Mon Mar 18 07:11:21 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:11:21 +0100 Subject: recovering SSH2 sessions while knowing the key and how to have it In-Reply-To: ; from anton@chuvakin.org on Thu, Mar 14, 2002 at 10:22:31AM -0500 References: Message-ID: <20020317211120.D15684@folly> On Thu, Mar 14, 2002 at 10:22:31AM -0500, Anton Chuvakin wrote: > I want to do a weird thing with my openssh daemon for the honeypot setup. > Namely, I want it to covertly broadcast the session key, so that, upon > sniffing the session, the contents can be recovered. for protocol 1 all you need is session_key[] from sshd.c for protocol 2 you have to check derive_key() from kex.c From bugzilla-daemon at mindrot.org Mon Mar 18 07:22:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 07:22:57 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020317202257.240BCE96F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From markus at openbsd.org 2002-03-18 07:22 ------- why not have the array static? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Mon Mar 18 07:15:51 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:15:51 +0100 Subject: Logging of client commands, possible? In-Reply-To: <013601c1cbb4$d00efec0$1701000a@effugas>; from dan@doxpara.com on Thu, Mar 14, 2002 at 04:03:18PM -0800 References: <013601c1cbb4$d00efec0$1701000a@effugas> Message-ID: <20020317211551.E15684@folly> On Thu, Mar 14, 2002 at 04:03:18PM -0800, Dan Kaminsky wrote: > Damnit, Damien, which of these do you wanna debug to figure out who broke > your production server? you wan't system call traces, of course. how do you debug? From markus at openbsd.org Mon Mar 18 07:16:28 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:16:28 +0100 Subject: scp 's problem In-Reply-To: <3C91508B.00000F.19348@mta2>; from macrosoft@263.net on Fri, Mar 15, 2002 at 09:38:19AM +0800 References: <3C91508B.00000F.19348@mta2> Message-ID: <20020317211628.F15684@folly> On Fri, Mar 15, 2002 at 09:38:19AM +0800, Simon Polar Bear wrote: > I have add an authentication method to openSSH, I call it ICCAuthentication, > much like RSAAuthentication, but the RSA private key is in the IC card. > I did not change any source code of scp. I mean scp.c. > I set all authentication methods to "no" in sshd_config but ICCAuthentication yes. it should not be related to scp. From markus at openbsd.org Mon Mar 18 07:18:16 2002 From: markus at openbsd.org (Markus Friedl) Date: Sun, 17 Mar 2002 21:18:16 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <20020315122047.A22509@dour.org>; from jason@dour.org on Fri, Mar 15, 2002 at 12:20:47PM -0500 References: <20020315122047.A22509@dour.org> Message-ID: <20020317211816.G15684@folly> On Fri, Mar 15, 2002 at 12:20:47PM -0500, Jason A. Dour wrote: > This is another take on logging for sftp-server. Given the number > of private email requests I've received for this patch, I assume > there is signifigant enough interest to request it be reviewed for > inclusion into the release. > you can make sftp-server log if you modify this define. #define TRACE debug From bugzilla-daemon at mindrot.org Mon Mar 18 08:58:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 08:58:47 +1100 (EST) Subject: [Bug 165] Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020317215847.F3289E962@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 ------- Additional Comments From mmahler at 141.com 2002-03-18 08:58 ------- sshd -ddd on openssh 3.1 debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Starting up PAM with username "sisyphus" debug3: Trying to reverse map address 127.0.0.1. debug1: PAM setting rhost to "localhost.localdomain" debug1: Attempting authentication for sisyphus. debug1: temporarily_use_uid: 500/500 (e=0) debug1: trying public RSA key file /home/sisyphus/.ssh/authorized_keys debug3: secure_filename: checking '/home/sisyphus/.ssh' debug3: secure_filename: checking '/home/sisyphus' debug3: secure_filename: terminating check at '/home/sisyphus' debug1: restore_uid Failed rsa for sisyphus from 127.0.0.1 port 38968 debug1: rcvd SSH_CMSG_AUTH_TIS Failed challenge-response for sisyphus from 127.0.0.1 port 38968 Connection closed by 127.0.0.1 sshd -ddd on openssh 3.0: debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH debug1: Local version string SSH-1.5-OpenSSH_3.0.2p1 debug1: Rhosts Authentication disabled, originating port 38971 not trusted. debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Starting up PAM with username "sisyphus" debug3: Trying to reverse map address 127.0.0.1. debug1: PAM setting rhost to "localhost.localdomain" debug1: Attempting authentication for sisyphus. debug1: temporarily_use_uid: 500/500 (e=0) debug1: trying public RSA key file /home/sisyphus/.ssh/authorized_keys debug3: secure_filename: checking '/home/sisyphus/.ssh' debug3: secure_filename: checking '/home/sisyphus' debug3: secure_filename: terminating check at '/home/sisyphus' debug1: restore_uid Accepted rsa for sisyphus from 127.0.0.1 port 38971 debug1: session_new: init debug1: session_new: session 0 This is really weird..... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 09:11:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 09:11:34 +1100 (EST) Subject: [Bug 165] Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020317221134.0ABFAE987@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 ------- Additional Comments From mmahler at 141.com 2002-03-18 09:11 ------- Sorry that last post I made a mistake and posted the wrong config file on it. It would appear that if in the sshd config file if you use ~ it looks for root's home, not the user trying to connect. RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile ~/.ssh/authorized_keys if that's your config you get this: debug1: match: OpenSSH_3.0 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Starting up PAM with username "sisyphus" debug3: Trying to reverse map address 128.138.39.14. debug1: PAM setting rhost to "strn39-14-dhcp.resnet.colorado.edu" debug1: Attempting authentication for sisyphus. debug1: temporarily_use_uid: 500/500 (e=0) debug1: trying public RSA key file /root/.ssh/authorized_keys debug1: restore_uid Failed rsa for sisyphus from 128.138.39.14 port 11065 debug1: temporarily_use_uid: 500/500 (e=0) debug1: trying public RSA key file /root/.ssh/authorized_keys debug1: restore_uid Failed rsa for sisyphus from 128.138.39.14 port 11065 debug1: rcvd SSH_CMSG_AUTH_TIS Failed challenge-response for sisyphus from 128.138.39.14 port 11065 if you change it to this : RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys it'll work right. but ~/.ssh/authorized_keys works fine in openssh3.0 sorry about that last mix up. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Mon Mar 18 09:42:49 2002 From: tim at multitalents.net (Tim Rice) Date: Sun, 17 Mar 2002 14:42:49 -0800 (PST) Subject: [patch] AIX package build fixes, please commit In-Reply-To: <3C940BC0.B48ABD0@zip.com.au> Message-ID: On Sun, 17 Mar 2002, Darren Tucker wrote: > Hello All, > This is a resend of a patch I posted nearly two weeks ago. As > of a few minutes ago, it hasn't been committed and thus the AIX package > builds from CVS fail. (I know because I now have a cron job that tells > me :-) Commited. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Mon Mar 18 10:31:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 10:31:48 +1100 (EST) Subject: [Bug 165] Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020317233148.88919E984@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 ------- Additional Comments From mouring at eviladmin.org 2002-03-18 10:31 ------- AuthorizedKeysFile %h/.ssh/authorized_keys or AuthorizedKeysFile .ssh/authorized_keys are the defaults (depending on the release). Not sure how ~/.ssh/authorized_keys ever worked since we call auth.c:expand_filename() which only honors %%, %h, %u. The same holds true for 3.0. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jason at dour.org Mon Mar 18 10:24:24 2002 From: jason at dour.org (Jason A. Dour) Date: Sun, 17 Mar 2002 18:24:24 -0500 Subject: PATCH: sftp-server logging. In-Reply-To: <20020317211816.G15684@folly> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> Message-ID: <20020317182424.A27407@dour.org> On Sun, Mar 17, 2002 at 09:18:16PM +0100, Markus Friedl wrote: > On Fri, Mar 15, 2002 at 12:20:47PM -0500, Jason A. Dour wrote: > > This is another take on logging for sftp-server. Given the number > > of private email requests I've received for this patch, I assume > > there is signifigant enough interest to request it be reviewed for > > inclusion into the release. > > > > you can make sftp-server log if you modify this define. > > #define TRACE debug Yes, you COULD do that. And the logging one would receive from doing that would be excessive, cryptic, and worst of all -- worthless. While the TRACE commands are useful for debugging, they are useless as a means of auditing your server. They provide no information as to the process chain, the userid of the user, or anything else one might want in an administrative setting, and they provide TOO MUCH useless information. Trying to use that tool to do anything other than debug a single instance of sftp-server for purposes of fixing a problem would be an exercise in madness and futility. OpenSSH is a wonderful product, but you're shooting yourself in the foot by not logging SFTP. Debugging and logging are two separate things, needed by two entirely different portions of your userbase. And given the repeated requests one sees for it on this and other forums, one would think this patch or ones like it would deserve more attention and discussion. Cheers, Jason # "Jason A. Dour" http://dour.org/ # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ From bugzilla-daemon at mindrot.org Mon Mar 18 11:53:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 11:53:11 +1100 (EST) Subject: [Bug 170] New: Double free() and heap corruption when krb4 auth fails Message-ID: <20020318005311.CC3E4E980@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=170 Summary: Double free() and heap corruption when krb4 auth fails Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: rbraun+ssh at andrew.cmu.edu After upgrading some machines to openssh 3.1p1 recently, I noticed some odd behavior when connecting to the 3.1p1 sshd. Specifically, if I used a kerberized client ssh, and I have a kerberos v4 tgt, but *not* in the kerb realm of the machine I'm ssh-ing to, the authorization should fail (since my .klogin doesn't specifically allow this), and it does. Then sshd abruptly closes the connection. No message (not even with the client in maximally verbose mode). When I try to run sshd in debug mode without the daemon (-d -d -d -D) and reproduce this problem, it is in fact segfaulting shortly after the point where the krb4 auth is failing. Some gdb traces show that this segfault is happening in malloc(). The cause of this is a free() in the auth_krb4 function (in auth-krb4.c) of a pointer, client_user, passed by reference (as *client) to that function. The do_authloop function in auth1.c, which calls auth_krb4, expects that this pointer is either valid or NULL on return, since it will free any non-NULL pointer later in the loop. One solution, represented by the attached patch, is to set the pointer to NULL after it is free'd; another solution is to not free the client_user string at all and let do_authloop deal 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 Mon Mar 18 11:55:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 11:55:16 +1100 (EST) Subject: [Bug 170] Double free() and heap corruption when krb4 auth fails Message-ID: <20020318005516.331AFE995@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=170 ------- Additional Comments From rbraun+ssh at andrew.cmu.edu 2002-03-18 11:55 ------- Created an attachment (id=46) patch to fix double free() when krb4 auth fails ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 12:54:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 12:54:12 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020318015412.9DA94E997@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mdev at idg.nl 2002-03-18 12:54 ------- Created an attachment (id=47) Workaround for fake-queue ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 13:03:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 13:03:19 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020318020319.A4C77E9A3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 ------- Additional Comments From mdev at idg.nl 2002-03-18 13:03 ------- The patch for fake-queue.h works, but just looks ugly. Since is the one , and the full path becomes: "includes.h" -> "config.h" -> "defines.h" -> I wasn't able to come up with a better solution. The #undef's are there to get rid of the 'redefinition' warnings. That it works on 4.1 is probably, because for some reason somewhere, KERNEL is defined on 4.2 before including while it isn't on 4.1. As for the static cmds[], that seemed to do the trick quite well. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From freedman at physics.cornell.edu Mon Mar 18 15:46:21 2002 From: freedman at physics.cornell.edu (Daniel Freedman) Date: Sun, 17 Mar 2002 23:46:21 -0500 Subject: Block ssh logins for specific hostnames (CNAMES) all bound to same IP ??? Message-ID: <20020318044621.GB6930@physics.cornell.edu> Hi, I'm interested in the ability to block ssh logins (or alternatively, not have sshd answer client requests) for certain hostnames that are DNS CNAME aliases to the canonical name for a given IP address. To tell you the truth, I don't think this is currently possible through this setup, and may look further to try to block it at the firewall, but that's a different discussion... :) Essentially, let's say I have: public.domain.com IN CNAME myserver.domain.com www.domain.com IN CNAME myserver.domain.com myserver.domain.com IN A 1.2.3.4 I don't want (for abstraction purposes, and ability to later change internal names) users to be able to 'ssh www.domain.com' or 'ssh myserver.domain.com', but instead require that they 'ssh public.domain.com'. I've searched the mail archives without much success, other than the following slightly orthogonal message: List: openssh-unix-dev Subject: Re: OpenSSH Key Storage From: Carson Gaspar Date: 2002-02-01 18:18:08 [Download message RAW] If you want to bind identity to a server, you have only 2 valid options: - Pass the server's identity in-band, and have the client use that when validating keys. This avoids a layering violation. - Have the client validate the key against the layer 3/4 info - i.e. the IP:PORT pair. Nothing else is sane. Servers on different ports are different servers, that may, or may not, have the same keys. Requiring config file gymnastics is bogus. Sadly, after reading the RFC, it looks like the server never sends its name during the key exchange, making the first (and better) option impossible. I hope I'm wrong and just mis-understood the documents. -- Carson I've also examined what I thought would do the trick: ListenAddress: Specifies the local addresses sshd should listen on. The following forms may be used: ListenAddress host|IPv4_addr|IPv6_addr ListenAddress host|IPv4_addr:port ListenAddress [host|IPv6_addr]:port If port is not specified, sshd will listen on the address and all prior Port options specified. The default is to listen on all local addresses. Multiple ListenAddress options are permitted. Additionally, any Port options must precede this option for non port qualified addresses. But it seemed to still pick up all connections to any CNAME, and probably for the following reason: I'm pretty sure that the ssh client contacts the server based upon the DNS resolution of the hostname to IP address, and the sshd server only sees an incoming client request, so I imagine that the only possibility that sshd would know what hostname the client requested were if the client passed this argument to the server. Finally, I'm obviously aware that I could simply register separate IP addresses for these hostnames, and either include multiple NIC's in the server or simply bind multiple distinct IP addresses to the same NIC, and then have sshd easily achieve the distinction between hostnames on IP addresses, but I'd still first prefer to see if I could achieve my goals as above. Anyway, thanks so much for producing such a fine tool, and thanks also for any suggestions. Take care, Daniel -- Daniel A. Freedman Laboratory for Atomic and Solid State Physics Department of Physics Cornell University From bugzilla-daemon at mindrot.org Mon Mar 18 17:04:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 17:04:43 +1100 (EST) Subject: [Bug 171] New: Banner /etc/issue.net (default) not displaying with Protocol 2 Message-ID: <20020318060443.138E0E930@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=171 Summary: Banner /etc/issue.net (default) not displaying with Protocol 2 Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: guhan777 at yahoo.com With a client (192.168.1.30) and server, both running v3.1p1, and set to use protocol 2 (in ssh_config on client, and sshd_config on server), Banner does not display. I am using the 2.4.x kernel on both machines. Attached it the output, with verbose mode (-v), from the client. OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Applying options for tigger2 debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 500 geteuid 0 anon 1 debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: temporarily_use_uid: 500/500 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 500/500 (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 /home/guhan/.ssh/identity type 0 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 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: 115/256 debug1: bits set: 1630/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.1.1' is known and matches the RSA host key. debug1: Found key in /home/guhan/.ssh/known_hosts2:1 debug1: bits set: 1642/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: 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 guhan at 192.168.1.1's password: Thanks, Wayne Guhan Iyer ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 18:45:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 18:45:46 +1100 (EST) Subject: [Bug 172] New: Add multiple AuthorizedKeyFiles options Message-ID: <20020318074546.ABC32E93B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=172 Summary: Add multiple AuthorizedKeyFiles options Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: alex.kiernan at thus.net 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). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 18:47:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 18:47:23 +1100 (EST) Subject: [Bug 172] Add multiple AuthorizedKeyFiles options Message-ID: <20020318074723.5D479E9A6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=172 ------- Additional Comments From alex.kiernan at thus.net 2002-03-18 18:47 ------- Created an attachment (id=48) Multiple AuthorizedKeyFile 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 Mon Mar 18 19:20:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 19:20:23 +1100 (EST) Subject: [Bug 171] Banner /etc/issue.net (default) not displaying with Protocol 2 Message-ID: <20020318082023.CCE68E9A7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=171 ------- Additional Comments From mouring at eviladmin.org 2002-03-18 19:20 ------- You must have Banner set. By default it is commented out. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Duncan.Ferguson at egg.com Mon Mar 18 20:08:32 2002 From: Duncan.Ferguson at egg.com (Ferguson, Duncan) Date: Mon, 18 Mar 2002 09:08:32 -0000 Subject: SSH and root access from limited hosts Message-ID: <67A87C4BBC46D4118451009027E506400761F522@pnnemp01.pn.egg.com> This is blanket access for root from any host with valid keys (and password) - I want to limit that access to 4 hosts no matter what keys or passwords are provided/used. I have looked at shosts.equiv but this doesn't stop other hosts being allowed. I have also looked at "AllowUsers root at host1 root at host2 ..." but this also means including every user we have for all other servers - of which there are 300+. What I would ideally like is "AllowRootUsersFrom host1 host2 host3" with no other user/service being affected. Duncan Ferguson IT Infrastructure Unix Systems Engineer Phone: 01384 264 060 Mobile: 07968 148 748 > -----Original Message----- > From: Anne Carasik [SMTP:gator at cacr.caltech.edu] > Sent: Friday, March 15, 2002 6:13 PM > To: Ferguson, Duncan > Cc: 'secureshell at securityfocus.com' > Subject: Re: SSH and root access from limited hosts > > Hi Duncan > > There should be something in the sshd_config (and sshd2_config for > SSH.com) > for PermitRootLogin. > > The options are yes, no, and nopwd (which means either hostbased or public > key authentication only). > > -Anne > > On Fri, Mar 15, 2002 at 01:08:31PM -0000, Ferguson, Duncan wrote: > > I have been looking around in the archive for this but not seen anyone > else > > discuss it (yet). > > > > We have approx. 200 machines, or which I want only 4 to be able to ssh > to > > all others as root. What is the easiest way to achieve this? At the > moment > > it is root access to/from all or nothing at all. > > > > Thanks. > > > > Duncs > > > > Duncan Ferguson > > IT Infrastructure Unix Systems Engineer > > > > Phone: 01384 264 060 > > Mobile: 07968 148 748 > > -- > > .-"".__."``". Anne Carasik, System Administrator > .-.--. _...' (/) (/) ``' gator at cacr.caltech.edu > (O/ O) \-' ` -="""=. ', Center for Advanced Computing Research > > ~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This private and confidential e-mail has been sent to you by Egg. The Egg group of companies comprises Prudential Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. All members of the Egg group are registered in England and Wales. Registered offices: 142 Holborn Bars, London EC1N 2NH If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From alicia at mail.asia-links.com Mon Mar 18 20:57:01 2002 From: alicia at mail.asia-links.com (alicia) Date: Mon, 18 Mar 2002 01:57:01 PST Subject: PATCH: sftp-server logging. Message-ID: <20020318015701.HM.100000000000rTq@mail.asia-links.com> > To enable logging, one must use compile time directives > (-DSFTP_LOGGING). I did that by setting the environement variable export CFLAGS="-DSFTP_LOGGING" before running $?patch -p0 < /tmp/sftp-server.withlogging.patch $ ./configure && make && make install But when restarting sshd with "LogLevel INFO" I do not see anything that looks like SFTP-logs in my logs... Anyone that have got this patch to work or know what I've done wrong (Linux ix86)? Thanks in advance! And thanks to Jason A. Dour for the sftp-logging in itiative, I really appreciate it! Alicia ================================================== Asia-Links Free Email: English, Japanese, Korean! http://www.asia-links.com From markus at openbsd.org Mon Mar 18 21:49:09 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 11:49:09 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <20020317182424.A27407@dour.org>; from jason@dour.org on Sun, Mar 17, 2002 at 06:24:24PM -0500 References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> Message-ID: <20020318114909.A27206@folly> On Sun, Mar 17, 2002 at 06:24:24PM -0500, Jason A. Dour wrote: > OpenSSH is a wonderful product, but you're shooting yourself in the > foot by not logging SFTP. Debugging and logging are two separate why should sftp log? does cat log? does ls log? From dan at doxpara.com Mon Mar 18 21:59:24 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 02:59:24 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> Message-ID: <007901c1ce6b$f72d2cc0$1701000a@effugas> > why should sftp log? does cat log? does ls log? does apache log? From markus at openbsd.org Mon Mar 18 22:08:32 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 12:08:32 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <007901c1ce6b$f72d2cc0$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> Message-ID: <20020318110832.GA28950@faui02> On Mon, Mar 18, 2002 at 02:59:24AM -0800, Dan Kaminsky wrote: > > > why should sftp log? does cat log? does ls log? > > does apache log? sshd does log. does ls log if executed by apachae? From bugzilla-daemon at mindrot.org Mon Mar 18 23:05:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 23:05:55 +1100 (EST) Subject: [Bug 155] OpenSSH 3.1p1 fails to compile on BSDi 4.0 Message-ID: <20020318120555.25738E998@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=155 mdev at idg.nl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From mdev at idg.nl 2002-03-18 23:05 ------- *** This bug has been marked as a duplicate of 146 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Mar 18 23:05:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 18 Mar 2002 23:05:59 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020318120559.C3698EA00@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 mdev at idg.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tansympp at singnet.com.sg ------- Additional Comments From mdev at idg.nl 2002-03-18 23:05 ------- *** Bug 155 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dan at doxpara.com Mon Mar 18 23:02:50 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 04:02:50 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318110832.GA28950@faui02> Message-ID: <00b701c1ce74$d3b817b0$1701000a@effugas> > sshd does log. > > does ls log if executed by apachae? 10.0.3.254 - - [17/Mar/2002:15:32:02 -0800] "GET /funny HTTP/1.1" 301 317 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)" looks like a listing to me :-) look. the logs useful to programmers are not the logs useful to sysadmins, and just as it'd be rather disrespectful to tell you, the developer, that you could do *your* job without knowing what the hell the system was doing, it's just as wrong for you to tell the administrator deploying your code that he should be able to do his job without a clear and concise view of who transferred what. there are of course issues in that users can execute their own sftp-server processes. if you push it, that's a really good reason for somebody to stand up and say "sftp is less secure than ftp". the solution is a sftp only ssh daemon with a locked build of sftp-server that logs to syslog(thus conveniently avoiding the user executed/root logged problem). i don't think you realize there's an entire class of users that I trust to get files from me but not to execute code on my server. sorry markus, i don't trust you to execute code on my web server :-) if we are ever to wipe the scourge of ftp off the face of the net, it's going to take a decent amount of awareness of what a useful server process requires. if you *must* have a security justification, fine. dos attacks are a little easier to see when you're not getting 3498573985 lines of debug a day anyway. --dan From dan at doxpara.com Mon Mar 18 23:29:37 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 04:29:37 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318110832.GA28950@faui02> <00b701c1ce74$d3b817b0$1701000a@effugas> Message-ID: <00d701c1ce78$91586010$1701000a@effugas> > i don't think you realize there's an entire class of users that I trust to > get files from me but not to execute code on my server. sorry markus, i > don't trust you to execute code on my web server :-) unless you count that root owned secure remote administration daemon... still, you know what I mean *laughs*. --dan From pin at math.chalmers.se Tue Mar 19 01:00:09 2002 From: pin at math.chalmers.se (Ivan Popov) Date: Mon, 18 Mar 2002 15:00:09 +0100 (MET) Subject: incomplete/insufficient logic for making access decisions Message-ID: Hello, There is a simple but sometimes important omission in access decision logic in OpenSSH. It checks against PAM for all authentication methods - it *is* good. But it provides no means to distinguish, in PAM configuration, which method has been used for the authentication. It is sometimes crucial to be able to distinguish between different ways of authentication, to make the right authorization (login access) decision. [e.g. to have allowed-accounts-lists per authentication type] We have been running openssh for a long time with our own patches to add different pam service names for different authentication modes, but it definitely should belong to the mainstream code. (no, our patches were against 2.*, of no use if I'd provide them) We were running with "ssh-rsa" and "ssh-dcegss" style service names along with "ssh", used for plain pam (i.e. password) authentication. I see it as an important omission, that fortunately is easy to fix - let it go different paths in pam account (authorization) management, corresponding to different authentication paths. Best regards, and thanks for the great software! -- Ivan From jason at dour.org Tue Mar 19 02:07:19 2002 From: jason at dour.org (Jason A. Dour) Date: Mon, 18 Mar 2002 10:07:19 -0500 Subject: PATCH: sftp-server logging. In-Reply-To: <00b701c1ce74$d3b817b0$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318110832.GA28950@faui02> <00b701c1ce74$d3b817b0$1701000a@effugas> Message-ID: <20020318100719.A28796@dour.org> On Mon, Mar 18, 2002 at 04:02:50AM -0800, Dan Kaminsky wrote: > look. the logs useful to programmers are not the logs useful to > sysadmins, and just as it'd be rather disrespectful to tell you, > the developer, that you could do *your* job without knowing what > the hell the system was doing, it's just as wrong for you to tell > the administrator deploying your code that he should be able to do > his job without a clear and concise view of who transferred what. This is exactly my point. Thank you, Dan. > there are of course issues in that users can execute their own > sftp-server processes. if you push it, that's a really good > reason for somebody to stand up and say "sftp is less secure than > ftp". the solution is a sftp only ssh daemon with a locked build > of sftp-server that logs to syslog(thus conveniently avoiding the > user executed/root logged problem). And this is where an overall picture comes into play, with usage of chroot, limited shells, authorized commands, removal of file-transfer other than sftp, et cetera. Ultimately it could be that Open-SSH could take the (current) stance that the bundled sftp-server is sufficient to meet the basic standards set forth in the RFCs, and thus it is not necessary to add anything such as logging. Doing so would eventually necessitate a forking of the code, however, and a separate project devoted to maintaining Open-SFTP, leading to increased likelihood of flaws and increasing confusion among the userbase. This is silly, since sftp-server could easily be extended while remaining integrated with the Open-SSH core, and would please a lot of current and potential Open-SSH admins. And this is not the only step to improving Open-SSH's design from an ADMINSITRATOR'S point of view. Technically, it is a great product, written by great developers. However, there are some things (such as SFTP/SCP logging, authentication/authorization being mish-mashed together, et cetera), that make it less than ideal. This is just the easiest to implement, and thus the first that I've tackled and submitted. > if you *must* have a security justification, fine. dos attacks > are a little easier to see when you're not getting 3498573985 > lines of debug a day anyway. And it is easier to track intrustion vectors when you can track new data that has been brought into your machine by utilities you manage. [XYZ]modem and FTP log...there's no reason sftp-server shouldn't log as well. Cheers, Jason # "Jason A. Dour" http://dour.org/ # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ From Nicolas.Williams at ubsw.com Tue Mar 19 02:11:32 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Mon, 18 Mar 2002 10:11:32 -0500 Subject: [Bug 160] Race condition in clientloop.c? In-Reply-To: ; from apronk@csi.co.nz on Sun, Mar 17, 2002 at 09:57:37PM +1200 References: Message-ID: <20020318101130.K27398@sm2p1386swk.wdr.com> I haven't tested it. Nico On Sun, Mar 17, 2002 at 09:57:37PM +1200, Adrian Pronk wrote: > Not in 3.0.2p1? What about in the version I originally posted about, 3.1? > > > >http://bugzilla.mindrot.org/show_bug.cgi?id=160 > > > >Nicolas.Williams at ubsw.com changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > > Status|NEW |RESOLVED > > Resolution| |FIXED > > > > > > > >------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-14 > 08:25 ------- > >Aha! > > > >Yes, there is a race. It's there in 2.9p2, but apparently not in 3.0.2p1. > > > >Essentially the > > > >"if (compat20 && session_closed && !channel_still_open())" > > > >check at the top of the client loop is not close enough to the > >call to select() in client_wait_until_can_do_something(). In fact, > >client_wait_until_can_do_something() calls channel_prepare_select() > >which calls channel_handler() which may well call chan_is_dead() > >which may leave no channels open and yet > >client_wait_until_can_do_something() will still go into the > >select(). > > On Tue, Mar 12, 2002 at 11:27:19AM +1300, Adrian Pronk wrote: > > I've just built openssh 3.1 for my Redhat 5.1 system (running on a 486 > > DX-66) using the latest zlib and openssl libraries. > > > > Connecting to the machine with ssh seems to work fine (although it takes > a > > while to initiate a connection). > > > > But when I transfer a file to the machine with scp, it seems to work fine > > and the scp completes, but an ssh sub-process remains behind on the > client > > and an sshd sub-process remains behind on the host. When I strace them, > > the client is waiting on a socket and the host is waiting on three > > different fd's (under 5.1, its hard to tell what they are without making > an > > effort :) ). > > > > I did not compile the system on the target machine (which is my > firewall). > > My old development machine was a RH 5.1 box. I bought a new box recently > > and put RH 7.2 on it. I copied the development RH 5.1 file system on to > it > > (including /dev). I then chroot'ed to that directory , mounted a new > /proc > > and had my 5.1 development environment back. I compiled (make install) > > openSSL, zlib, openSSH on this and copied the likely output files to the > > target machine. I wouldn't think this development environment would > break > > anything. > > > > Does anyone know off the top of their heads what the problem might be? > If > > not, I'll get stuck in and have a look at the code and see if I can see > > anything. > > > -- > Adrian > > _______________________________________________ > 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 jason at dour.org Tue Mar 19 02:16:53 2002 From: jason at dour.org (Jason A. Dour) Date: Mon, 18 Mar 2002 10:16:53 -0500 Subject: PATCH: sftp-server logging. In-Reply-To: <20020318015701.HM.100000000000rTq@mail.asia-links.com> References: <20020318015701.HM.100000000000rTq@mail.asia-links.com> Message-ID: <20020318101653.B28796@dour.org> On Mon, Mar 18, 2002 at 01:57:01AM -0800, alicia wrote: > > To enable logging, one must use compile time directives > > (-DSFTP_LOGGING). > > I did that by setting the environement variable > > export CFLAGS="-DSFTP_LOGGING" > > before running > > $ patch -p0 < /tmp/sftp-server.withlogging.patch > $ ./configure && make && make install > > But when restarting sshd with "LogLevel INFO" I do not see > anything that looks like SFTP-logs in my logs... Anyone that have > got this patch to work or know what I've done wrong (Linux ix86)? Hmm. I just did your exact steps on my install (x86 Linux), and it worked fine. Verify that your Makefile has -DSFTP_LOGGING in the CFLAGS. Perhaps your configure run didn't pickup the CFLAGS. If this was a prior installation directory, perhaps do make clean first? Cheers, Jason # "Jason A. Dour" http://dour.org/ # Founder / Executive Producer - PJ Harvey Online - http://pjh.org/ From markus at openbsd.org Tue Mar 19 02:31:26 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 16:31:26 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <007901c1ce6b$f72d2cc0$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> Message-ID: <20020318153126.GA23951@faui02> On Mon, Mar 18, 2002 at 02:59:24AM -0800, Dan Kaminsky wrote: > > > why should sftp log? does cat log? does ls log? > > does apache log? you don't get it. sshd is run by root, so you trust the logfiles. sftp-server is not run by root. so why should it log? it can tell you anything, it's a user process. From mcardenas at ya.com Tue Mar 19 02:34:51 2002 From: mcardenas at ya.com (Manuel =?iso-8859-1?Q?Carde=F1as?=) Date: Mon, 18 Mar 2002 16:34:51 +0100 Subject: Fwd: Problem with scp in Openssh3.1p1 Message-ID: <5.1.0.14.0.20020318163408.046629c0@pop.mailcorp.ya.com> > I'm having a problem with scp since I installed openssh 3.1p1. > > Server: Openssh 3.1p1 > Client: Openssh ANY_VERSION > >$ scp -v -v -v -v -v -p -C user at machine1:/etc/passwd ./machine1.passwd >Executing: program /usr/bin/ssh host machine1, user user, command scp -v >-p -f /etc/passwd >Sending file modes: C0644 473 passwd > > 473 bytes... it's ok > >$ scp -v -v -v -v -v -p -C user at machine2:/etc/passwd ./machine2.passwd >Executing: program /usr/bin/ssh host machine2, user user, command scp -v >-p -f /etc/passwd >Sending file modes: C0644 17592186044416 passwd > > 17592186044416 bytes... oh my god! > > The size of files on "machine2" always is "17592186044416" ?? > > ciao. nothing about the problem? :( ciao. From dan at doxpara.com Tue Mar 19 03:45:42 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 08:45:42 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> Message-ID: <011b01c1ce9c$57c62cf0$1701000a@effugas> > you don't get it. > > sshd is run by root, so you trust the logfiles. apache is run by NOBODY, Markus. file transfer != executable access, markus, any more than file viewing = code execution, unnamed macro virus supporting vendor. sftp-server is a system service that switches to user permissions for *safety* purposes, not for ownership purposes. it's still in the purview of the admin, at least in many sites. sftp ain't ready to be deployed as a replacement for ftp. this remains of the major reasons why. but until the code exists, it ain't worth bitching about. --dan From markus at openbsd.org Tue Mar 19 03:48:42 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 17:48:42 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <011b01c1ce9c$57c62cf0$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> <011b01c1ce9c$57c62cf0$1701000a@effugas> Message-ID: <20020318164842.GB23951@faui02> On Mon, Mar 18, 2002 at 08:45:42AM -0800, Dan Kaminsky wrote: > sftp-server is a system service this is a misconception. currenlty sftp-server is not a system service, it's just something like ls or at. From markus at openbsd.org Tue Mar 19 03:53:58 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 17:53:58 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <011b01c1ce9c$57c62cf0$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> <011b01c1ce9c$57c62cf0$1701000a@effugas> Message-ID: <20020318165358.GC23951@faui02> On Mon, Mar 18, 2002 at 08:45:42AM -0800, Dan Kaminsky wrote: > > you don't get it. > > > > sshd is run by root, so you trust the logfiles. > > apache is run by NOBODY, Markus. that's a bug. nothing should be run by user 'nobody'. From dan at doxpara.com Tue Mar 19 03:57:05 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 08:57:05 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> <011b01c1ce9c$57c62cf0$1701000a@effugas> <20020318164842.GB23951@faui02> Message-ID: <013501c1ce9d$eef86c90$1701000a@effugas> > > sftp-server is a system service > > this is a misconception. currenlty sftp-server is not > a system service, it's just something like ls or at. ftp is a system service sftp implies more secure than ftp, not less since ftp generally lacks process execution privs(exec usually disabled), while sftp presently requires it, ftp is more secure than sftp. the worst case scenario for an ftp password leak is file leakage; the worst case scenario for a sftp password leak is generally root compromise (most OS's can't withstand a local intruder with a shell, except openbsd). if you do not accept the above analysis, I've got a file for you to put in your web server's cgi-bin. don't worry, you trust me to download files, why not to execute code :) this is a problem. it will eventually need to get solved. no misconceptions, I understand exactly how sftp-server is presently implemented; that's why I didn't document it :-) not ready to replace anon/restricted ftp, which is a major domain of that protocol. apache is run by nobody all over the place; anyway, the point is it sure as hell ain't run as root :-) file transfer has slightly different rules, that's all i'm sayin. --dan From markus at openbsd.org Tue Mar 19 04:00:32 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Mar 2002 18:00:32 +0100 Subject: PATCH: sftp-server logging. In-Reply-To: <013501c1ce9d$eef86c90$1701000a@effugas> References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> <011b01c1ce9c$57c62cf0$1701000a@effugas> <20020318164842.GB23951@faui02> <013501c1ce9d$eef86c90$1701000a@effugas> Message-ID: <20020318170032.GD23951@faui02> On Mon, Mar 18, 2002 at 08:57:05AM -0800, Dan Kaminsky wrote: > > > sftp-server is a system service > > > > this is a misconception. currenlty sftp-server is not > > a system service, it's just something like ls or at. > > ftp is a system service > sftp implies more secure than ftp, not less but sftp-server is not a ftpd replacement. it could be, but it is not. if you expect all ftpd features in sftp, then write your own sftpd. sftp is just named sftp because ssh.com's sftp client is named in this way. From dan at doxpara.com Tue Mar 19 04:06:09 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 18 Mar 2002 09:06:09 -0800 Subject: PATCH: sftp-server logging. References: <20020315122047.A22509@dour.org> <20020317211816.G15684@folly> <20020317182424.A27407@dour.org> <20020318114909.A27206@folly> <007901c1ce6b$f72d2cc0$1701000a@effugas> <20020318153126.GA23951@faui02> <011b01c1ce9c$57c62cf0$1701000a@effugas> <20020318164842.GB23951@faui02> <013501c1ce9d$eef86c90$1701000a@effugas> <20020318170032.GD23951@faui02> Message-ID: <013f01c1ce9f$336fa040$1701000a@effugas> > if you expect all ftpd features in sftp, then write your > own sftpd. i expect the basics of any file transfer daemon. show me one that doesn't log (ok besides samba, but you have no idea how horrific that protocol is. there's a reason luke leighton scares everyone with his hex divining skills.) we're smart people, we know the difference between file transfer security and code execution security. some companies don't. they get hacked regularly. --dan From bugzilla-daemon at mindrot.org Tue Mar 19 04:49:02 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 04:49:02 +1100 (EST) Subject: [Bug 173] New: sshd does not listen on tcp-socket, though GatewayPorts yes Message-ID: <20020318174902.D74F2EA37@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=173 Summary: sshd does not listen on tcp-socket, though GatewayPorts yes Product: Portable OpenSSH Version: 3.1p1 Platform: UltraSparc OS/Version: SunOS Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: tdsc.af at infineon.com The summary says it all. The Changes file says: - (stevesk) OpenBSD CVS sync X11 localhost display - stevesk at cvs.openbsd.org 2001/11/29 14:10:51 [channels.h channels.c session.c] sshd X11 fake server will now listen on localhost by default: $ echo $DISPLAY localhost:12.0 $ netstat -an|grep 6012 tcp 0 0 127.0.0.1.6012 *.* LISTEN tcp6 0 0 ::1.6012 *.* LISTEN sshd_config gatewayports=yes can be used to revert back to the old behavior. will control this with another option later. ok markus@ but that's not true. I have configured GatewayPorts yes and X11Forwarding yes but: prompt# echo $DISPLAY localhost:10.0 prompt# netstat -an|grep 6010 127.0.0.1.6010 *.* 0 0 0 0 LISTEN WHY MUST EVERYTHING CONSTANTLY CHANGE ? ESPECIALLY THE WORKING THINGS ? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Tue Mar 19 04:01:07 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 18 Mar 2002 11:01:07 -0600 (CST) Subject: PATCH: sftp-server logging. In-Reply-To: <013501c1ce9d$eef86c90$1701000a@effugas> Message-ID: I personaly would not be against having logging in sftp-server if it mirrored how TRACE macro works. But I think the logging macro and TRACE() macros should complement. If that means moving some of the TRACE() to logging status instead of debugging status (little formating, but still keeping the SAME useful information). Then that would be the correct thing to do. Besides, I hate #ifdef.. I personally would reject it based on that myself. BTW.. I won't get into the 'HTTPD' as nobody argument.=) I reconfigure every apache server I manage to run as 'httpd' user. Or with Apache 2.0 in per-child mode I set it to whoever the owner of the vhost is. Since I could care less if they screw with their own httpds. =) - Ben On Mon, 18 Mar 2002, Dan Kaminsky wrote: > > > sftp-server is a system service > > > > this is a misconception. currenlty sftp-server is not > > a system service, it's just something like ls or at. > > ftp is a system service > sftp implies more secure than ftp, not less > > since ftp generally lacks process execution privs(exec usually disabled), > while sftp presently requires it, ftp is more secure than sftp. the worst > case scenario for an ftp password leak is file leakage; the worst case > scenario for a sftp password leak is generally root compromise (most OS's > can't withstand a local intruder with a shell, except openbsd). > > if you do not accept the above analysis, I've got a file for you to put in > your web server's cgi-bin. don't worry, you trust me to download files, why > not to execute code :) > > this is a problem. it will eventually need to get solved. no > misconceptions, I understand exactly how sftp-server is presently > implemented; that's why I didn't document it :-) not ready to replace > anon/restricted ftp, which is a major domain of that protocol. > > apache is run by nobody all over the place; anyway, the point is it sure as > hell ain't run as root :-) file transfer has slightly different rules, > that's all i'm sayin. > > --dan > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From anton at chuvakin.org Tue Mar 19 04:50:09 2002 From: anton at chuvakin.org (Anton Chuvakin) Date: Mon, 18 Mar 2002 12:50:09 -0500 (EST) Subject: recovering SSH2 sessions while knowing the key and how to have it In-Reply-To: <20020317211120.D15684@folly> Message-ID: Markus and other esteemed members of openssh-dev, Thanks a lot for the response. I am sorry that my question was a bit vague and open-ended (admittedly, not a good idea for such a mailing list). >>Namely, I want it to covertly broadcast the session key, so >>sniffing the session, the contents can be recovered. >for protocol 1 all you need is >for protocol 2 you have to check Thanks for the tip. But (as I even pointed out in my message), knowing the key will not get me very far, since I will end up with a bunch of traffic dumps and a key. Is there any way (that you can think of) to use ssh itself to recover the session from those files? It pains me to think that the only solution will be to write a code to do it from scratch using SSH2 protocol knowledge. ;-) BTW, I have tools to recover ssh1 sessions and my main interest is in ssh2. Best, -- Anton A. Chuvakin, Ph.D. http://www.chuvakin.org http://www.info-secure.org From lundberg at vr.net Tue Mar 19 05:19:58 2002 From: lundberg at vr.net (Gregory A Lundberg) Date: Mon, 18 Mar 2002 13:19:58 -0500 Subject: Encrypted file transfers References: Message-ID: <022401c1cea9$86fce4c0$0b0d85cd@vr.net> You'll want to try out the CVS snapshot of the prerelease 2.8.0 From bugzilla-daemon at mindrot.org Tue Mar 19 05:29:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 05:29:25 +1100 (EST) Subject: [Bug 165] Problem with SSH1 Keys on RedHat7.2 Message-ID: <20020318182925.D8E1CEA43@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=165 mmahler at 141.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From mmahler at 141.com 2002-03-19 05:29 ------- hmmm, not sure how it works eaither, but it does oddly work in 3.0... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 19 08:31:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 08:31:43 +1100 (EST) Subject: [Bug 173] sshd does not listen on tcp-socket, though GatewayPorts yes Message-ID: <20020318213143.5B33BEA48@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=173 ------- Additional Comments From stevesk at pobox.com 2002-03-19 08:31 ------- see sshd.8 X11UseLocalhost ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Maria.Wiese at McKesson.com Tue Mar 19 08:56:01 2002 From: Maria.Wiese at McKesson.com (Wiese, Maria) Date: Mon, 18 Mar 2002 13:56:01 -0800 Subject: Need help with buildpkg script Message-ID: <23ED36D4661BD51199E000D0B782508D014C80B3@ddce0051.mckesson.com> Ben, I am trying to create a package for Openssh.3-1p1, but the /contrib/solaris/buildpkg.sh script failes with the following errors: ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/b in mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/bin ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/s bin mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/sbin ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m an mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/s hare ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m an/man1 mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man/man1 ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m an/man8 mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man/man8 ./mkinstalldirs /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/l ibexec mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/libexec ./install-sh -c -m 4711 -s ssh /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pack age/usr/local/bin/ssh ./install-sh -c -m 0755 -s scp /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pack age/usr/local/bin/scp ./install-sh -c -m 0755 -s ssh-add /tools/OpenSSH/openssh-3.1p1/contrib/solaris/ package/usr/local/bin/ssh-add ./install-sh -c -m 0755 -s ssh-agent /tools/OpenSSH/openssh-3.1p1/contrib/solari s/package/usr/local/bin/ssh-agent ./install-sh -c -m 0755 -s ssh-keygen /tools/OpenSSH/openssh-3.1p1/contrib/solar is/package/usr/local/bin/ssh-keygen ./install-sh -c -m 0755 -s ssh-keyscan /tools/OpenSSH/openssh-3.1p1/contrib/sola ris/package/usr/local/bin/ssh-keyscan ./install-sh -c -m 0755 -s sshd /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pac kage/usr/local/sbin/sshd etc...etc.... ./install-sh -c -m 644 sshd_config.out /tools/OpenSSH/openssh-3.1p1/cont rib/solaris/package/usr/local/etc/sshd_config; \ else \ echo "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc /sshd_config already exists, install will not overwrite"; \ fi if [ -f ssh_prng_cmds -a ! -z "yes" ]; then \ /usr/bin/perl ./fixprogs ssh_prng_cmds ; \ if [ ! -f /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local /etc/ssh_prng_cmds ] ; then \ ./install-sh -c -m 644 ssh_prng_cmds.out /tools/OpenSSH/openssh- 3.1p1/contrib/solaris/package/usr/local/etc/ssh_prng_cmds; \ else \ echo "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/l ocal/etc/ssh_prng_cmds already exists, install will not overwrite"; \ fi ; \ fi if [ ! -f /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc/mod uli ]; then \ if [ -f /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/e tc/primes ]; then \ echo "moving /tools/OpenSSH/openssh-3.1p1/contrib/solaris/packag e/usr/local/etc/primes to /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/u sr/local/etc/moduli"; \ mv "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/loc al/etc/primes" "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/e tc/moduli"; \ else \ ./install-sh -c -m 644 moduli.out /tools/OpenSSH/openssh-3.1p1/c ontrib/solaris/package/usr/local/etc/moduli; \ fi ; \ else \ echo "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc /moduli already exists, install will not overwrite"; \ fi Building pkginfo file... Building prototype file... Building package.. ## Building pkgmap from package prototype file. ## Processing pkginfo file. pkgmk: ERROR: parameter cannot be null ## Packaging was not successful. pkgtrans: ERROR: unable to complete package transfer - no packages were selected from Message-ID: Grab the most recently snapshot from http://www.openssh.com/portable.html and use the buildpkg from there. Otherwise you need to change the VERSION= line from -1 to -2. - Ben On Mon, 18 Mar 2002, Wiese, Maria wrote: > Ben, > I am trying to create a package for Openssh.3-1p1, but the > /contrib/solaris/buildpkg.sh script failes with the following errors: > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/b > in > mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/bin > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/s > bin > mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/sbin > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m > an > mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/s > hare > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m > an/man1 > mkdir > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man/man1 > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/m > an/man8 > mkdir > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/man/man8 > ./mkinstalldirs > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/l > ibexec > mkdir /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/libexec > ./install-sh -c -m 4711 -s ssh > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pack > age/usr/local/bin/ssh > ./install-sh -c -m 0755 -s scp > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pack > age/usr/local/bin/scp > ./install-sh -c -m 0755 -s ssh-add > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/ > package/usr/local/bin/ssh-add > ./install-sh -c -m 0755 -s ssh-agent > /tools/OpenSSH/openssh-3.1p1/contrib/solari > s/package/usr/local/bin/ssh-agent > ./install-sh -c -m 0755 -s ssh-keygen > /tools/OpenSSH/openssh-3.1p1/contrib/solar > is/package/usr/local/bin/ssh-keygen > ./install-sh -c -m 0755 -s ssh-keyscan > /tools/OpenSSH/openssh-3.1p1/contrib/sola > ris/package/usr/local/bin/ssh-keyscan > ./install-sh -c -m 0755 -s sshd > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/pac > kage/usr/local/sbin/sshd > etc...etc.... > > ./install-sh -c -m 644 sshd_config.out > /tools/OpenSSH/openssh-3.1p1/cont > rib/solaris/package/usr/local/etc/sshd_config; \ > else \ > echo > "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc > /sshd_config already exists, install will not overwrite"; \ > fi > if [ -f ssh_prng_cmds -a ! -z "yes" ]; then \ > /usr/bin/perl ./fixprogs ssh_prng_cmds ; \ > if [ ! -f > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local > /etc/ssh_prng_cmds ] ; then \ > ./install-sh -c -m 644 ssh_prng_cmds.out > /tools/OpenSSH/openssh- > 3.1p1/contrib/solaris/package/usr/local/etc/ssh_prng_cmds; \ > else \ > echo > "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/l > ocal/etc/ssh_prng_cmds already exists, install will not overwrite"; \ > fi ; \ > fi > if [ ! -f > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc/mod > uli ]; then \ > if [ -f > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/e > tc/primes ]; then \ > echo "moving > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/packag > e/usr/local/etc/primes to > /tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/u > sr/local/etc/moduli"; \ > mv > "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/loc > al/etc/primes" > "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/e > tc/moduli"; \ > else \ > ./install-sh -c -m 644 moduli.out > /tools/OpenSSH/openssh-3.1p1/c > ontrib/solaris/package/usr/local/etc/moduli; \ > fi ; \ > else \ > echo > "/tools/OpenSSH/openssh-3.1p1/contrib/solaris/package/usr/local/etc > /moduli already exists, install will not overwrite"; \ > fi > Building pkginfo file... > Building prototype file... > Building package.. > ## Building pkgmap from package prototype file. > ## Processing pkginfo file. > pkgmk: ERROR: parameter cannot be null > ## Packaging was not successful. > pkgtrans: ERROR: unable to complete package transfer > - no packages were selected from > > The server had Openssh 2.9p2 installed, so I removed the package first, then > re-compiled Zlib, Openssl, openssh etc... > and try building the new pakage. > > I built all the 2.92P2 pakages with your script before with no problem. > Can you please help. > I need to upgrade ssh on over 100 servers with diffrent solaris versions and > platforms. Can't do it without a package. > Thank you > Maria Wiese > 916-636-8313. > > > > Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Tue Mar 19 12:01:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 12:01:56 +1100 (EST) Subject: [Bug 171] Banner /etc/issue.net (default) not displaying with Protocol 2 Message-ID: <20020319010156.427F8E92D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=171 guhan777 at yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From guhan777 at yahoo.com 2002-03-19 12:01 ------- Please ignore this bug, I was premature in posting this because later analysis showed my sshd was using the default sshd_config file, i.e. when you run configure with --with-etcdir instead of --sysconfdir, it just ignores the --with-etcdir flag with no warning. And as Ben pointed out, Banner is commented out by default. Hence this was not a bug at all, but rather my (stupid) mistake in running configure. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 19 14:40:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 14:40:09 +1100 (EST) Subject: [Bug 174] New: compile error on BSDi 4.0.1 Message-ID: <20020319034009.C6B03E917@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=174 Summary: compile error on BSDi 4.0.1 Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: BSDI Status: NEW Severity: normal Priority: P2 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: deven at netexplorer.org on BSD/OS 4.0.1, having problem compiling openssh 3.1p1. Configured with ./configure --with-ipv4-default make error: gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/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\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-agent.c ssh-agent.c: In function `lookup_identity': ssh-agent.c:135: warning: implicit declaration of function `TAILQ_FOREACH' ssh-agent.c:135: `next' undeclared (first use this function) ssh-agent.c:135: (Each undeclared identifier is reported only once ssh-agent.c:135: for each function it appears in.) ssh-agent.c:135: syntax error before `{' ssh-agent.c:138: warning: control reaches end of non-void function ssh-agent.c: At top level: ssh-agent.c:111: warning: `idtab_init' defined but not used ssh-agent.c:131: warning: `lookup_identity' defined but not used *** Error code 1 Stop. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Mar 19 15:53:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Mar 2002 15:53:46 +1100 (EST) Subject: [Bug 175] New: File size limit for SCP Message-ID: <20020319045346.85A39E917@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=175 Summary: File size limit for SCP Product: Portable OpenSSH Version: older versions Platform: Other OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: adamchiles at myrealbox.com What is the file size limit for scp. I assume it is something larger than 2.5Gband smaller than 3.0Gb ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Tue Mar 19 16:25:25 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 18 Mar 2002 21:25:25 -0800 Subject: incomplete/insufficient logic for making access decisions In-Reply-To: ; from pin@math.chalmers.se on Mon, Mar 18, 2002 at 03:00:09PM +0100 References: Message-ID: <20020318212524.C15467@google.com> On Mon, Mar 18, 2002 at 03:00:09PM +0100, Ivan Popov wrote: > [e.g. to have allowed-accounts-lists per authentication type] > > We have been running openssh for a long time with our own patches to add > different pam service names for different authentication modes, > but it definitely should belong to the mainstream code. > > (no, our patches were against 2.*, of no use if I'd provide them) > > We were running with "ssh-rsa" and "ssh-dcegss" style service names along > with "ssh", used for plain pam (i.e. password) authentication. I'd agree, this sounds like a reasonable (possibly even good) thing to do. You'd have to delay PAM startup until a non-PAM auth started (if you used PAM auth you'd have to end it and restart it -- ugly and not worthwhile). Something like # Account service to use for non-PAM authentication. When using # PAM auth, this is always "sshd". When using non-PAM auth (eg rsa) # the configured service name is used. Can contain %a which is # substituted with the auth type. Default is "sshd". PAMAcctService sshd seems good. /fc From markus at openbsd.org Tue Mar 19 19:40:56 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 19 Mar 2002 09:40:56 +0100 Subject: recovering SSH2 sessions while knowing the key and how to have it In-Reply-To: References: <20020317211120.D15684@folly> Message-ID: <20020319084056.GE23951@faui02> On Mon, Mar 18, 2002 at 12:50:09PM -0500, Anton Chuvakin wrote: > Thanks for the tip. But (as I even pointed out in my message), knowing the > key will not get me very far, since I will end up with a bunch of traffic > dumps and a key. Is there any way (that you can think of) to use ssh > itself to recover the session from those files? yes, just hack ssh. ssh-privsep (soon in openssh-portable) passes keystate between the unprivilegued processes. From oliver at tecq.org Tue Mar 19 21:02:53 2002 From: oliver at tecq.org (Oliver Wellnitz) Date: Tue, 19 Mar 2002 11:02:53 +0100 Subject: openssh 3.1p1: ToS trouble Message-ID: <20020319110252.A21480@angel.escape.de> Hi, I noticed that the Type of Service bit for minimize delay is set in client->server packets only. Is this OS-specific or is there another reason for this? Here is a tcpdump of an interactive connection: 217.225.98.212.22 > 134.169.34.19.45870: P 1:49(48) ack 48 win 12008 (DF) 134.169.34.19.45870 > 217.225.98.212.22: P 48:96(48) ack 49 win 25416 (DF) [tos 0x10] 217.225.98.212.22 > 134.169.34.19.45870: P 49:97(48) ack 96 win 12008 (DF) 134.169.34.19.45870 > 217.225.98.212.22: P 96:144(48) ack 49 win 25416 (DF) [tos 0x10] 217.225.98.212.22 > 134.169.34.19.45870: P 97:145(48) ack 144 win 12008 (DF) 134.169.34.19.45870 > 217.225.98.212.22: . 144:144(0) ack 145 win 25416 (DF) [tos 0x10] 134.169.34.19.45870 > 217.225.98.212.22: P 144:192(48) ack 145 win 25416 (DF) [tos 0x10] 217.225.98.212.22 > 134.169.34.19.45870: P 145:193(48) ack 192 win 12008 (DF) 134.169.34.19.45870 > 217.225.98.212.22: P 192:240(48) ack 193 win 25416 (DF) [tos 0x10] 217.225.98.212.22 > 134.169.34.19.45870: P 193:241(48) ack 240 win 12008 (DF) 134.169.34.19.45870 > 217.225.98.212.22: P 240:288(48) ack 241 win 25416 (DF) [tos 0x10] I'm using the ToS field for priority queuing, so this is a problem for me. oliver at stargate:~ > uname -rs ; ssh -V Linux 2.4.17-lvm OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f Oliver From markus at openbsd.org Tue Mar 19 21:11:12 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 19 Mar 2002 11:11:12 +0100 Subject: openssh 3.1p1: ToS trouble In-Reply-To: <20020319110252.A21480@angel.escape.de> References: <20020319110252.A21480@angel.escape.de> Message-ID: <20020319101112.GA18652@faui02> server version? From oliver at tecq.org Tue Mar 19 23:45:26 2002 From: oliver at tecq.org (Oliver Wellnitz) Date: Tue, 19 Mar 2002 13:45:26 +0100 Subject: openssh 3.1p1: ToS trouble In-Reply-To: <20020319101112.GA18652@faui02>; from markus@openbsd.org on Tue, Mar 19, 2002 at 11:11:12AM +0100 References: <20020319110252.A21480@angel.escape.de> <20020319101112.GA18652@faui02> Message-ID: <20020319134526.B21480@angel.escape.de> On Tue, Mar 19, 2002 at 11:11:12AM +0100, Markus Friedl wrote: > server version? Server (stargate.tecq.org) was the said OpenSSH 3.1p1 on Linux 2.4.17 Client (barolo.ibr.cs.tu-bs.de) was OpenSSH 3.0.2p1 on Solaris 8 I did some more test and here are the results: (YES means ToS bit set client->server only, NO means ToS bit set both ways) stargate -> tuborg YES tuborg -> stargate YES arvika -> stargate YES barolo -> stargate YES stargate -> arvika NO barolo -> arvika NO arvika -> barolo NO tuborg -> barolo NO stargate.tecq.org: OpenSSH 3.1p1/Linux 2.4.17, sshd -6, IPv6-enabled host tuborg.ibr.cs.tu-bs.de: OpenSSH 3.0.2p1/Linux 2.2.19, sshd -6, IPv6-enabled host arvika.lug-bs.de: OpenSSH 3.1p1/Linux 2.4.18, sshd, IPv6-enabled host barolo.ibr.cs.tu-bs.de: OpenSSH 3.0.2p1/Solaris 8, sshd, IPv6-enabled host It works fine if I start 'sshd -4' on stargate. Ah, I think I understand now. When sshd binds to an IPv6 socket, IPv4 connections are mapped into IPv6 adresses ::ffff:a.b.c.d (on Linux). So even if it's a v4 connection on the network, sshd thinks it is v6 and cannot set the ToS bit, because v6 does not use ToS (but Traffic classes). I don't know if it's possible to change IPv4-ToS with setsockopt(2) if you have an IPv4 connection over an IPv6 socket. Oliver From markus at openbsd.org Wed Mar 20 00:15:47 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 19 Mar 2002 14:15:47 +0100 Subject: openssh 3.1p1: ToS trouble In-Reply-To: <20020319134526.B21480@angel.escape.de> References: <20020319110252.A21480@angel.escape.de> <20020319101112.GA18652@faui02> <20020319134526.B21480@angel.escape.de> Message-ID: <20020319131547.GB18652@faui02> openssh sets TOS for packet_connection_is_ipv4() only From gert at greenie.muc.de Wed Mar 20 01:07:17 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 19 Mar 2002 15:07:17 +0100 Subject: SCO 3 / CVS version In-Reply-To: ; from Tim Rice on Thu, Mar 07, 2002 at 05:50:08PM -0800 References: <20020307233246.A24544@greenie.muc.de> Message-ID: <20020319150717.B18117@greenie.muc.de> Hi, On Thu, Mar 07, 2002 at 05:50:08PM -0800, Tim Rice wrote: > > [ OpenSSH_CVS on SCO 3] > > > Run-time testing tomorrow, but I do not expect nasty surprises. > > The sshd server will probably work fine As far as can see, yes, it does. > but the ssh client is broken > on SCO3. I haven't had time to fix it. It's been a while since I looked > at the problem but I think it had to with seteuid() not working as > documented on SCO. If the client is not suid-root, it will work fine (but of course without any kind of hostbased/rhosts authentication). With suid, it bombs when calling ssh-rand-helper. I will look into it these days. 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 bugzilla-daemon at mindrot.org Wed Mar 20 03:11:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 03:11:44 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020319161144.46F98EA73@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From wknox at mitre.org 2002-03-20 03:11 ------- Created an attachment (id=49) Previous patch is missing a semicolon ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 03:20:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 03:20:01 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020319162001.37C7AEA7A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 ------- Additional Comments From wknox at mitre.org 2002-03-20 03:19 ------- This patch works fine for me, and catches the additional error condition of not finding any default keys (looks like I got stuck enhancing my first pass at a patch instead of approaching it again). I'm using this one now. Thanks, Markus. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gert at greenie.muc.de Wed Mar 20 03:29:04 2002 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 19 Mar 2002 17:29:04 +0100 Subject: SCO 3 / CVS version In-Reply-To: <20020319150717.B18117@greenie.muc.de>; from Gert Doering on Tue, Mar 19, 2002 at 03:07:17PM +0100 References: <20020307233246.A24544@greenie.muc.de> <20020319150717.B18117@greenie.muc.de> Message-ID: <20020319172904.A26420@greenie.muc.de> Hi, On Tue, Mar 19, 2002 at 03:07:17PM +0100, Gert Doering wrote: > > but the ssh client is broken > > on SCO3. I haven't had time to fix it. It's been a while since I looked > > at the problem but I think it had to with seteuid() not working as > > documented on SCO. > > If the client is not suid-root, it will work fine (but of course without > any kind of hostbased/rhosts authentication). With suid, it bombs when > calling ssh-rand-helper. Weird. We end up at this point with: uid=0 euid=2 (uid 2 is the user that I'm testing with) (I don't know why - usually its the other way round). The setuid() man page actually states that "setuid(2)" won't work from this point, as it isn't one of the cases that are documented to work (euid=0, uid= would work, as would uid=2, euid=. The third case is saved-setuid, which might have been garbled further "up"). Interesting enough, if I do: seteuid(getuid()) (-> uid=0, euid=0) and *then* do setuid(original_uid) I end up with uid=2, euid=2, which is what is desired. So my patch for entropy.c looks like this: Index: entropy.c =================================================================== RCS file: /cvs/openssh_cvs/entropy.c,v retrieving revision 1.41 diff -u -w -r1.41 entropy.c --- entropy.c 11 Mar 2002 00:16:35 -0000 1.41 +++ entropy.c 19 Mar 2002 16:24:13 -0000 @@ -85,9 +85,10 @@ close(devnull); if (original_uid != original_euid && - setuid(original_uid) == -1) { - fprintf(stderr, "(rand child) setuid: %s\n", - strerror(errno)); + ( seteuid(getuid()) == -1 || + setuid(original_uid) == -1) ) { + fprintf(stderr, "(rand child) setuid(%d): %s\n", + original_uid, strerror(errno)); _exit(1); } I think this should be fine from a a security stand point - both uid and euid are non-root in the child (tested), so I'll keep it that way. 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 austin at coremetrics.com Wed Mar 20 04:29:25 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 19 Mar 2002 11:29:25 -0600 Subject: Status of KRB5 support? Message-ID: <1016558965.13215.20.camel@UberGeek> Just curious. I'd like to move up to 3.1px since there are security updates associated with it. Also, any pointers on implementing an kerberized external login server would be helpful. TIA -- 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 From Nicolas.Williams at ubsw.com Wed Mar 20 04:54:33 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 19 Mar 2002 12:54:33 -0500 Subject: Status of KRB5 support? In-Reply-To: <1016558965.13215.20.camel@UberGeek>; from austin@coremetrics.com on Tue, Mar 19, 2002 at 11:29:25AM -0600 References: <1016558965.13215.20.camel@UberGeek> Message-ID: <20020319125431.L27398@sm2p1386swk.wdr.com> For what it's worth, the security bug in channels.c is trivial to fix. See the alerts and the patch attached therein. Nico On Tue, Mar 19, 2002 at 11:29:25AM -0600, Austin Gonyou wrote: > Just curious. I'd like to move up to 3.1px since there are security > updates associated with it. > > Also, any pointers on implementing an kerberized external login server > would be helpful. > > TIA > -- > 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 > _______________________________________________ > 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 staatsvr at asc.hpc.mil Fri Mar 15 10:00:43 2002 From: staatsvr at asc.hpc.mil (Vern Staats) Date: Thu, 14 Mar 2002 18:00:43 -0500 Subject: Kerberos support for portable Message-ID: <20020314180043.D14578@sw4.asc.hpc.mil> My organization has a need to use protocol 2 + kerberos Real Soon Now, so I've gone ahead and applied Simon's KRB5 patch to openssh-3.1p1. I don't know how far along Simon is; for all I know he might have the definitive patch out tomorrow. So FWIW, here's what I have now. gunzip http://bugzilla.mindrot.org/show_bug.cgi?id=174 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From markus at openbsd.org 2002-03-20 07:21 ------- *** This bug has been marked as a duplicate of 146 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 07:21:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 07:21:18 +1100 (EST) Subject: [Bug 146] OpenSSH 3.1p1 will not build on BSD/OS 4.2/4.1/4.01 Message-ID: <20020319202118.ACEA4EA92@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=146 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |deven at netexplorer.org ------- Additional Comments From markus at openbsd.org 2002-03-20 07:21 ------- *** Bug 174 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 07:39:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 07:39:16 +1100 (EST) Subject: [Bug 55] [PATCH] Kerberos v5 support in portable Message-ID: <20020319203916.2BA77EA9F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=55 ------- Additional Comments From simon at sxw.org.uk 2002-03-20 07:39 ------- Created an attachment (id=50) Updated patch, with fixes from reviewers ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 07:44:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 07:44:00 +1100 (EST) Subject: [Bug 175] File size limit for SCP Message-ID: <20020319204400.5EA2BEA8C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=175 ------- Additional Comments From markus at openbsd.org 2002-03-20 07:43 ------- there is no limit, unless scp has a bug. what versions are you talking about? what systems? does the system have different APIs for 64bit offsets ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 07:48:01 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 07:48:01 +1100 (EST) Subject: [Bug 173] sshd does not listen on tcp-socket, though GatewayPorts yes Message-ID: <20020319204801.096D0EA97@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=173 ------- Additional Comments From markus at openbsd.org 2002-03-20 07:47 ------- no openssh release had GatewayPorts affect X11-forwarding. the X11 sockets are now bound to localhost for security reasons, if you don't like this, please check the annoucement or sshd(8) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 08:10:03 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 08:10:03 +1100 (EST) Subject: [Bug 170] Double free() and heap corruption when krb4 auth fails Message-ID: <20020319211003.256BBEA9F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=170 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-03-20 08:09 ------- patch applied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 20 23:18:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Mar 2002 23:18:33 +1100 (EST) Subject: [Bug 176] New: OpenSSH_3.1p1 gives X_ShmAttach error on forwarded X11 channel Message-ID: <20020320121833.0BC3EE919@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=176 Summary: OpenSSH_3.1p1 gives X_ShmAttach error on forwarded X11 channel Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Luca.Bonomi at fysik.dtu.dk Dear OpenSSH developers, We upgraded OpenSSH from 2.9 to 3.1p1 due to the recent security hole. Unfortunately, this upgrade creates a problem for a visualization tool that does X11 graphics over an SSH channel. The visualization code is the rasmol_16BIT code available from http://www.bernstein-plus-sons.com/software/RasMol_2.7.2.1/ The rasmol_16BIT code has NO problems in case: 1) the remote OpenSSH server is running OpenSSH_2.9p2. 2) the X11 is forwarded directly in stead of via an SSH channel. You should be able to reproduce the error by downloading the rasmol code and trying it out. Rasmol is the only failing application we've found so far. Note that the option "X11UseLocalhost no" would fix the problem, but if I manually set DISPLAY=`echo $DISPLAY | sed s/localhost/somehostname/` then Rasmol (and any other application too!) would not find a display at all. I enclose below a debug-listing which hopefully may point to the origin of the error (I have no understanding of the underlying mechanisms). Both the client and server systems are running Redhat 7.2, and have the openssh-3.1p1-2 RPM installed with default X11 configuration, but running "ssh protocol 1". # ssh -v mott OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: restore_uid debug1: ssh_connect: getuid 258 geteuid 0 anon 0 debug1: Connecting to mott [130.225.86.77] port 22. debug1: Allocated local port 1009. debug1: temporarily_use_uid: 258/250 (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 /home/camp/ohnielse/.ssh/identity type -1 debug1: identity file /home/camp/ohnielse/.ssh/id_rsa type -1 debug1: identity file /home/camp/ohnielse/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1 debug1: match: OpenSSH_3.1p1 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.1p1 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'mott' is known and matches the RSA1 host key. debug1: Found key in /home/camp/ohnielse/.ssh/known_hosts:28 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: cipher_init: set keylen (16 -> 32) debug1: cipher_init: set keylen (16 -> 32) debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying rhosts authentication. debug1: Remote: Accepted for tycho.fysik.dtu.dk [130.225.86.17] by /etc/hosts.equiv. debug1: Requesting pty. debug1: Requesting X11 forwarding with authentication spoofing. debug1: fd 3 setting TCP_NODELAY debug1: Requesting shell. debug1: Entering interactive session. Last login: Tue Mar 19 15:19:13 2002 from tycho.fysik.dtu.dk [ohnielse at mott ~]$ ./rasmol_16BIT debug1: Received X11 open request. debug1: fd 4 setting TCP_NODELAY debug1: fd 4 setting O_NONBLOCK debug1: channel 0: new [X11 connection from 127.0.0.1 port 38256] RasMol Molecular Renderer Roger Sayle, August 1995 Copyright (C) Roger Sayle 1992-1999 Version 2.7.1.1 January 2001 Copyright (C) Herbert J. Bernstein 1998-2001 *** See "help notice" for further notices *** [16-bit version] debug1: channel 0: rcvd ieof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: send oclose debug1: channel 0: output drain -> closed debug1: channel 0: FORCE input drain debug1: channel 0: ibuf empty debug1: channel 0: send ieof debug1: channel 0: input drain -> wait_oclose X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 147 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 215 Current serial number in output stream: 216 debug1: channel 0: rcvd oclose debug1: channel 0: input wait_oclose -> closed debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: X11 connection from 127.0.0.1 port 38256, nchannels 1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jonas.nordell at sema.se Thu Mar 21 00:27:01 2002 From: jonas.nordell at sema.se (jonas.nordell at sema.se) Date: Wed, 20 Mar 2002 14:27:01 +0100 Subject: openssh v3.1p1 Message-ID: Hi, I had some trobble building a pkg fpr solaris... It complaind that version couldnt be null so i made some investigation and found this the command for getting the version is something like "tail -1 ../../version.h blablabla" the problem i found out is that the version in version.h isnt at the last line its at the line above... when i did "tail -2 ../../version.h blablabla" it worked just fine... just thought you wanted to know :) take care +---------------------------------------------------------------------------+ Best Regards: Jonas Nordell, Unix technichian SchlumbergerSema, Sundsvall Phone +46 60-785 33 45 Mobile +46 708-51 33 45 Email jnordell at slb.com Uin 4511772 SchlumbergerSema -- Worldwide IT Partner for the Olympic Games From GerhardLausser at PREMIERE.DE Thu Mar 21 02:13:04 2002 From: GerhardLausser at PREMIERE.DE (GerhardLausser at PREMIERE.DE) Date: Wed, 20 Mar 2002 16:13:04 +0100 Subject: Solaris package build Message-ID: <63DBCC148985D51195F50002A53D0168070D35@kms-my-mxs1.df1.de> Hi, i just failed to build a package with contrib/solaris/buildpkg.sh due to an extra blank last line in version.h Greetings from Munich, Gerhard Lau?er IT-Betrieb M?nchen / Consultant KirchPayTV Medienallee 4 85774 Unterf?hring Tel. +49 89 / 9958 - 1348 Fax +49 89 / 0058 - 1359 mailto:gerhardlausser at premiereworld.de www.premiereworld.de From bugzilla-daemon at mindrot.org Thu Mar 21 05:16:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Mar 2002 05:16:41 +1100 (EST) Subject: [Bug 177] New: chroot tools for OpenSSH 3.1p1 Message-ID: <20020320181641.26747E91E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=177 Summary: chroot tools for OpenSSH 3.1p1 Product: Portable OpenSSH Version: -current Platform: Other URL: http://cag.lcs.mit.edu/~raoul/. OS/Version: other Status: NEW Severity: enhancement Priority: P3 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: nkadel at bellatlantic.net I've updated and modified some older OpenSSH chroot tools to work correctly with OpenSSH 3.1p1. I'd like to get them integrated into the code base, in strong preference to that ghods-awful "chroot" shell scripting done by ssh-3.x. The patch modifies OpenSSH to do a chroot to the part of any $HOMEDIR which contains the characters '/./', to the directory location preceeding that set of characters. The chroot tarball building tool is designed to grab the user-selected shell, ssh, and another other selected components along with the required dynamic libraries to allow those tools function. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dsa0000 at hotmail.com Thu Mar 21 07:44:44 2002 From: dsa0000 at hotmail.com (dsa main) Date: Wed, 20 Mar 2002 20:44:44 +0000 Subject: OpenSSH porting to VxWorks .. Message-ID: Hi, Anybody tried porting OpenSSH to vxworks ? What are the issues ? Thanks in Advance Regards DSA _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From friedman at splode.com Thu Mar 21 09:42:05 2002 From: friedman at splode.com (Noah Friedman) Date: Wed, 20 Mar 2002 14:42:05 -0800 (PST) Subject: openssh 3.1p1 linking problem Message-ID: <20020320144205.440914.FMU1100@piglet.prv.splode.com> It's recommended that recent versions of openssl be built only as static libraries because the ABIs are not yet stable (esp. the `engine' component). However, the library still uses dlopen. Linking openssh will therefore fail unless linking against -ldl explicitly along with -lcrypto. It should be harmless to do so when linking dynamically. Also, it would be useful if the configure script for openssh would check for the minimum version of openssl required. Version 0.9.5 did not define some functions that openssh wanted; I had to upgrade to 0.9.6. From stevesk at pobox.com Thu Mar 21 09:46:47 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 20 Mar 2002 14:46:47 -0800 (PST) Subject: privsep Message-ID: i think our strategy for privsep is to just keep portable sync'd closely with openbsd's tree, even though things will be broken wrt privsep for many platforms. then we just get primary one's working and work out issues as we go along. i'll start to work on sun and hp-ux again tomorrow. From pramod at aligo.com Thu Mar 21 11:00:12 2002 From: pramod at aligo.com (Pramod Immaneni) Date: 20 Mar 2002 17:00:12 -0700 Subject: background disable input Message-ID: <1016668812.2717.33.camel@tuxtreme> Hi, ssh has a -f option by which it puts itself into background after taking login and password. Apart from that it stops reading from stdin (or reads from /dev/null). Is there any way one can keep it connected to stdin or are there any plans for that to be added. The problem is I have another process which is connected to ssh via pipes. It pumps data to ssh and reads data from ssh. The other process is pppd and I do a vpn with these two. I wrote a small program which accomplishes this task. Currently, without -f it all works but I cant use the control terminal any more. Thanks, Pramod. From aab at aab.cc.purdue.edu Thu Mar 21 14:44:41 2002 From: aab at aab.cc.purdue.edu (Paul Townsend) Date: Wed, 20 Mar 2002 22:44:41 -0500 (EST) Subject: bug in ssh-keyscan.c -- Message-ID: <200203210344.WAA17242@aab.cc.purdue.edu> ===== Ladies/Gents, "ssh-keyscan.c" can't be linked statically against "libssh.a". You end up with `fatal()' being doubly defined. The patch below deletes the new "ssh-keyscan.c:fatal()" function and and restores the "ssh-keyscan.c:fatal_callback()" function with modifi- cations. The problem that both attempt to alleviate is the setting of the variable in the "log.c:fatal_cleanup()" function. In the current code, it can be called once only. The second time it's called, an immediate "exit(255)" is executed. Unfortunately, `ssh-keyscan' wants to ignore fatal errors encountered while accessing the server's keys so this is not good thing. My personal approach converts the internal static variable to a global variable and allows the user cleanup function (fatal_callback) to clear it if desired. Other than kludginess, it should not affect the other executables and it will work with both static and dynamic linking. -- Paul Townsend (aab at purdue.edu) p.s., The first part of the patch is fluff so that I can tell which key is currently being processed. PT =-=-=-=-=-= --- ssh-keyscan.c.orig Mon Mar 4 20:54:53 2002 +++ ssh-keyscan.c Wed Mar 20 21:35:08 2002 @@ -538,7 +538,11 @@ confree(s); return; } - fprintf(stderr, "# %s %s\n", c->c_name, chop(buf)); + n = c->c_keytype; + if (n < KT_RSA1 || n > KT_RSA || n == 3) + n = 6; /* paranoia ? */ + cp = "RSA1DSA RSA UNKN"; + fprintf(stderr, "# %4.4s %s %s\n", cp + (n / 2) * 4, c->c_name, chop(buf)); n = snprintf(buf, sizeof buf, "SSH-%d.%d-OpenSSH-keyscan\r\n", c->c_keytype == KT_RSA1? PROTOCOL_MAJOR_1 : PROTOCOL_MAJOR_2, c->c_keytype == KT_RSA1? PROTOCOL_MINOR_1 : PROTOCOL_MINOR_2); @@ -665,17 +669,14 @@ } } -void -fatal(const char *fmt,...) +extern int fatal_cleanup_called; +static void +fatal_callback(void *arg) { - va_list args; - va_start(args, fmt); - do_log(SYSLOG_LEVEL_FATAL, fmt, args); - va_end(args); - if (nonfatal_fatal) + if (nonfatal_fatal) { + fatal_cleanup_called = 0; longjmp(kexjmp, -1); - else - fatal_cleanup(); + } } static void @@ -777,6 +778,7 @@ usage(); log_init("ssh-keyscan", log_level, SYSLOG_FACILITY_USER, 1); + fatal_add_cleanup(fatal_callback, NULL); maxfd = fdlim_get(1); if (maxfd < 0) --- log.c.orig Tue Feb 26 12:52:15 2002 +++ log.c Wed Mar 20 21:13:04 2002 @@ -216,15 +216,16 @@ } /* Cleanup and exit */ +int fatal_cleanup_called = 0; void fatal_cleanup(void) { struct fatal_cleanup *cu, *next_cu; - static int called = 0; - if (called) + if (fatal_cleanup_called) exit(255); - called = 1; + fatal_cleanup_called = 1; + /* Call cleanup functions. */ for (cu = fatal_cleanups; cu; cu = next_cu) { next_cu = cu->next; From bugzilla-daemon at mindrot.org Thu Mar 21 19:18:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Mar 2002 19:18:57 +1100 (EST) Subject: [Bug 178] New: Content of /etc/nologin isn't shown to users, fix triggers probably AIX bug Message-ID: <20020321081857.EE02DE950@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=178 Summary: Content of /etc/nologin isn't shown to users, fix triggers probably AIX bug Product: Portable OpenSSH Version: 3.1p1 Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Ralf.Wenk at fh-karlsruhe.de If /etc/nologin is given, the loginrestrictions() function in auth.c will decline any non-root login. So the users will get some kind of wrong password message and do not see any content of /etc/nologin at all. The below fix will correct this behavior. Unfortunately it triggers another - possible AIX 4.3.3 only - bug which will cause the server process to hang forever. I have a somewhat ugly workaround and also the systemcall wich causes the server to hang. May be there is another way to fix this, but i don't know much enough about the internals of the openssh sourcecode. After inserting some extra debug statements i got the following debug-trace when the server will hang: # sshd -ddd [...] debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: exit session_input_channel_req debug1: server_input_channel_req: channel 0 request x11-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug1: fd 10 setting O_NONBLOCK debug2: fd 10 is O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug1: exit session_input_channel_req debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: calling session_shell_req debug1: calling packet_check_eom debug1: calling do_exec debug1: calling do_exec_pty setsid: Not owner debug1: Received SIGCHLD. debug1: parent+ debug1: parent++ ^rz192:~ # The "parent+" debug statements are in patch No 3. Index: auth.c =================================================================== RCS file: /usr/local/.cvs/auth/openssh/auth.c,v retrieving revision 1.1.1.5 diff -c -r1.1.1.5 auth.c *** auth.c 2002/03/08 07:55:38 1.1.1.5 --- auth.c 2002/03/15 12:54:01 *************** *** 177,183 **** } #ifdef WITH_AIXAUTHENTICATE ! if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { if (loginmsg && *loginmsg) { /* Remove embedded newlines (if any) */ char *p; --- 177,190 ---- } #ifdef WITH_AIXAUTHENTICATE ! /* ! * To let the user read a possible message in /etc/nologin we have to ! * accept him here. Otherwise the message will just be logged and the ! * user gets only a permission denied message. ! */ ! if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0 && ! (errno != EPERM || ! stat(_PATH_NOLOGIN, &st) != 0)) { if (loginmsg && *loginmsg) { /* Remove embedded newlines (if any) */ char *p; Index: session.c =================================================================== RCS file: /usr/local/.cvs/auth/openssh/session.c,v retrieving revision 1.1.1.7 diff -c -r1.1.1.7 session.c *** session.c 2002/03/08 07:55:51 1.1.1.7 --- session.c 2002/03/20 07:59:02 *************** *** 1094,1099 **** --- 1094,1107 ---- while (fgets(buf, sizeof(buf), f)) fputs(buf, stderr); fclose(f); + #ifdef _AIX + /* + * This is ugly, but otherwise AIX (at least 4.3.3ML8) + * will get stuck forever in the close(ttyfd) call of + * the parent process in do_exec_pty(). + */ + sleep(2); + #endif /* _AIX */ exit(254); } } Index: session.c =================================================================== RCS file: /usr/local/.cvs/auth/openssh/session.c,v retrieving revision 1.1.1.7 diff -c -r1.1.1.7 session.c *** session.c 2002/03/08 07:55:51 1.1.1.7 --- session.c 2002/03/19 15:17:52 *************** *** 572,590 **** --- 572,594 ---- if (is_winnt) cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); #endif + debug("parent+"); if (pid < 0) packet_disconnect("fork failed: %.100s", strerror(errno)); s->pid = pid; + debug("parent++"); /* Parent. Close the slave side of the pseudo tty. */ close(ttyfd); + debug("parent+++"); /* * Create another descriptor of the pty master side for use as the * standard input. We could use the original descriptor, but this * simplifies code in server_loop. The descriptor is bidirectional. */ fdout = dup(ptyfd); + debug("parent++++"); if (fdout < 0) packet_disconnect("dup #1 failed: %.100s", strerror(errno)); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 21 19:37:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Mar 2002 19:37:26 +1100 (EST) Subject: [Bug 178] Content of /etc/nologin isn't shown to users, fix triggers probably AIX bug Message-ID: <20020321083726.D1573E953@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=178 ------- Additional Comments From Ralf.Wenk at fh-karlsruhe.de 2002-03-21 19:37 ------- Created an attachment (id=51) patches as shown in the bug report, relavtive to local cvs repository ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From drm at bable.com.au Thu Mar 21 21:01:57 2002 From: drm at bable.com.au (David Moline) Date: Thu, 21 Mar 2002 21:01:57 +1100 Subject: BindAddress with Openssh Message-ID: <3C99AF95.7FD13B36@bable.com.au> Hi In a nutshell, the BindAddress functionality doesn't seem to work (at least on Solaris 7 when using the fake-gettaddrinfo module provided). I haven't been able to test on other OS versions or using an OS library provided getaddrinfo (such as OpenBSD), but the unless the functionality of getaddrinfo is majorly different, I think this problem would be similar everywhere. The code in question in sshconnect.c (lines 201 to 209) to first checks if the options.bindaddr is NULL, if it is not it sets the hints.ai_flag value to AI_PASSIVE. The effect of this seems to me to bind the outgoing connections to "anyaddr" not the address specified by options.bindaddr. If the AI_PASSIVE assignment at line 208 is removed, then the bind address for outgoing connections operates as expected. I'm not sure of the security implications of changing or removing this line of code, but your thoughts would be appreciated. Regards David Moline Bable Consulting Melbourne, Australia +61 (0) 418 599 933 From markus at openbsd.org Thu Mar 21 21:13:15 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Mar 2002 11:13:15 +0100 Subject: BindAddress with Openssh In-Reply-To: <3C99AF95.7FD13B36@bable.com.au> References: <3C99AF95.7FD13B36@bable.com.au> Message-ID: <20020321101315.GA13851@faui02> seems fake-getaddrinfo is broken. If the AI_PASSIVE bit is set in the ai_flags member of the hints struc- ture, then the caller plans to use the returned socket address structure in a call to bind() so AI_PASSIVE should be set for BindAddress. On Thu, Mar 21, 2002 at 09:01:57PM +1100, David Moline wrote: > Hi > > In a nutshell, the BindAddress functionality doesn't seem to work (at > least on Solaris 7 when using the fake-gettaddrinfo module provided). I > haven't been able to test on other OS versions or using an OS library > provided getaddrinfo (such as OpenBSD), but the unless the functionality > of getaddrinfo is majorly different, I think this problem would be > similar everywhere. > > The code in question in sshconnect.c (lines 201 to 209) to first checks > if the options.bindaddr is NULL, if it is not it sets the hints.ai_flag > value to AI_PASSIVE. The effect of this seems to me to bind the outgoing > connections to "anyaddr" not the address specified by options.bindaddr. > If the AI_PASSIVE assignment at line 208 is removed, then the bind > address for outgoing connections operates as expected. > > I'm not sure of the security implications of changing or removing this > line of code, but your thoughts would be appreciated. > > Regards > David Moline > Bable Consulting > Melbourne, Australia > +61 (0) 418 599 933 > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Thu Mar 21 21:32:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Mar 2002 21:32:42 +1100 (EST) Subject: [Bug 158] ssh-add trips up due to missing key types Message-ID: <20020321103242.A8D74E97D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=158 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-03-21 21:32 ------- applied patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From marc.bigler at day.com Thu Mar 21 23:03:41 2002 From: marc.bigler at day.com (marc.bigler at day.com) Date: Thu, 21 Mar 2002 13:03:41 +0100 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support Message-ID: Hello, I have a little question and this regarding the compilation of the latest release of OpenSSH on a Linux Slackware version 8 box. We are currently using Kerberos 5 for user authentification and I saw that in SSH there is only an option to configure called: --with-kerberos4, so my question is: what do I need to do to get Kerberos 5 support into OpenSSH ? I am using the MIT kerberos version 1.2.3. Thank you in advance for your feedback. Regards Marc From austin at coremetrics.com Fri Mar 22 03:56:36 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 21 Mar 2002 10:56:36 -0600 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: References: Message-ID: <1016729796.12753.4.camel@UberGeek> The openSSH team is waiting on a patch for (auth.c?) to make MIT compatibility work with that file. So far, I can only see that 3.0.2 is available. On Thu, 2002-03-21 at 06:03, marc.bigler at day.com wrote: > > Hello, > > I have a little question and this regarding the compilation of the > latest > release of OpenSSH on a Linux Slackware version 8 box. We are currently > using Kerberos 5 for user authentification and I saw that in SSH there > is > only an option to configure called: --with-kerberos4, so my question is: > what do I need to do to get Kerberos 5 support into OpenSSH ? > > I am using the MIT kerberos version 1.2.3. > > Thank you in advance for your feedback. > > Regards > Marc > > > _______________________________________________ > 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 From sxw at dcs.ed.ac.uk Fri Mar 22 04:38:05 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Thu, 21 Mar 2002 17:38:05 +0000 (GMT) Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: <1016729796.12753.4.camel@UberGeek> Message-ID: On 21 Mar 2002, Austin Gonyou wrote: > The openSSH team is waiting on a patch for (auth.c?) to make MIT > compatibility work with that file. So far, I can only see that 3.0.2 is > available. An up to date patch, against the latest CVS, is available from the OpenSSH bugzilla: Bug report: http://bugzilla.mindrot.org/show_bug.cgi?id=55 Latest patch: http://bugzilla.mindrot.org/showattachment.cgi?attach_id=50 This patch incorporates fixes from a number of code reviews, as detailed in previous mails to this list. Cheers, Simon. From austin at coremetrics.com Fri Mar 22 04:54:15 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 21 Mar 2002 11:54:15 -0600 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: References: Message-ID: <1016733255.13659.2.camel@UberGeek> Hot damn Simon! Thanks much! On Thu, 2002-03-21 at 11:38, Simon Wilkinson wrote: > On 21 Mar 2002, Austin Gonyou wrote: > > > The openSSH team is waiting on a patch for (auth.c?) to make MIT > > compatibility work with that file. So far, I can only see that 3.0.2 > is > > available. > > An up to date patch, against the latest CVS, is available from the > OpenSSH bugzilla: > > Bug report: http://bugzilla.mindrot.org/show_bug.cgi?id=55 > Latest patch: > http://bugzilla.mindrot.org/showattachment.cgi?attach_id=50 > > This patch incorporates fixes from a number of code reviews, as detailed > in previous mails to this list. > > Cheers, > > Simon. > > _______________________________________________ > 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 From f_mohr at yahoo.de Fri Mar 22 05:13:07 2002 From: f_mohr at yahoo.de (=?iso-8859-1?q?frank=20mohr?=) Date: Thu, 21 Mar 2002 19:13:07 +0100 (CET) Subject: StrictModes yes fails in some cases on AIX Message-ID: <20020321181307.92823.qmail@web20505.mail.yahoo.com> today I've got a strange error on a AIX 4.3 box (OpenSSH 3.1p1) secure_filename() fails with "realpath /users/fmohr/.ssh/authorized_keys failed: Permission denied" in a (realy special) case: - /users/fmohr/ is mounted by the automounter - the directory is exported via a dfs/nfs gateway - StrictModes is set to yes it works if the mounted directory is directly exported via nfs or StrictModes is set to no (no secure_filename check). the problem is caused by AIX realpath(), if I define BROKEN_REALPATH and use the realpath() function from openbsd-compat the authentication works fine. is this a known problem? is there any option to tell configure to set BROKEN_REALPATH (as far as i understand that part of the configure script, only the existence of the function is checked, but there is no way to skip a test and preset its result) frank __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Ihre E-Mail noch individueller? - http://domains.yahoo.de From marc.bigler at day.com Fri Mar 22 06:08:35 2002 From: marc.bigler at day.com (marc.bigler at day.com) Date: Thu, 21 Mar 2002 20:08:35 +0100 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support Message-ID: Thanks those two patches work perfectly, I don't understand why this isn't included by default into SSH, maybe law ?? Regards and thanks again Marc Simon Wilkinson To: Austin Gonyou , .uk> Subject: Re: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support 03/21/02 06:38 PM On 21 Mar 2002, Austin Gonyou wrote: > The openSSH team is waiting on a patch for (auth.c?) to make MIT > compatibility work with that file. So far, I can only see that 3.0.2 is > available. An up to date patch, against the latest CVS, is available from the OpenSSH bugzilla: Bug report: http://bugzilla.mindrot.org/show_bug.cgi?id=55 Latest patch: http://bugzilla.mindrot.org/showattachment.cgi?attach_id=50 This patch incorporates fixes from a number of code reviews, as detailed in previous mails to this list. Cheers, Simon. From mouring at etoh.eviladmin.org Fri Mar 22 05:30:24 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 21 Mar 2002 12:30:24 -0600 (CST) Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: Message-ID: This round of patches are VERY VERY recent.. Post 3.1.. The reason before was lack of auditing and verification. They will end up in the cvs tree when approved. - Ben On Thu, 21 Mar 2002 marc.bigler at day.com wrote: > > Thanks those two patches work perfectly, I don't understand why this isn't > included by default into SSH, maybe law ?? > > Regards and thanks again > > Marc > > > > > Simon > Wilkinson To: Austin Gonyou > , > .uk> Subject: Re: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support > > 03/21/02 06:38 > PM > > > > > > > On 21 Mar 2002, Austin Gonyou wrote: > > > The openSSH team is waiting on a patch for (auth.c?) to make MIT > > compatibility work with that file. So far, I can only see that 3.0.2 is > > available. > > An up to date patch, against the latest CVS, is available from the > OpenSSH bugzilla: > > Bug report: http://bugzilla.mindrot.org/show_bug.cgi?id=55 > Latest patch: http://bugzilla.mindrot.org/showattachment.cgi?attach_id=50 > > This patch incorporates fixes from a number of code reviews, as detailed > in previous mails to this list. > > Cheers, > > Simon. > > > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Fri Mar 22 08:07:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Mar 2002 08:07:11 +1100 (EST) Subject: [Bug 177] chroot tools for OpenSSH 3.1p1 Message-ID: <20020321210711.41CC2E9CB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=177 ------- Additional Comments From markus at openbsd.org 2002-03-22 08:07 ------- chroot would be nice to have, but having sshd chroot for /./ in $HOME is not a standard behaviour. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Fri Mar 22 07:59:49 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Mar 2002 21:59:49 +0100 Subject: openssh 3.1p1 linking problem In-Reply-To: <20020320144205.440914.FMU1100@piglet.prv.splode.com> References: <20020320144205.440914.FMU1100@piglet.prv.splode.com> Message-ID: <20020321205949.GB30773@folly> On Wed, Mar 20, 2002 at 02:42:05PM -0800, Noah Friedman wrote: > It's recommended that recent versions of openssl be built only as static > libraries because the ABIs are not yet stable (esp. the `engine' > component). However, the library still uses dlopen. this depends on how you configure openssl. From markus at openbsd.org Fri Mar 22 08:05:42 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Mar 2002 22:05:42 +0100 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: References: Message-ID: <20020321210542.GC30773@folly> On Thu, Mar 21, 2002 at 08:08:35PM +0100, marc.bigler at day.com wrote: > Thanks those two patches work perfectly, I don't understand why this isn't > included by default into SSH, maybe law ?? ??? did you check the time of the patch and the time of the OpenSSH 3.1 release? From friedman at splode.com Fri Mar 22 08:20:35 2002 From: friedman at splode.com (Noah Friedman) Date: Thu, 21 Mar 2002 13:20:35 -0800 (PST) Subject: openssh 3.1p1 linking problem In-Reply-To: <20020321205949.GB30773@folly> (markus@openbsd.org Thursday, 21 Mar 2002 21:59:49 +0100) References: <20020320144205.440914.FMU1100@piglet.prv.splode.com> <20020321205949.GB30773@folly> Message-ID: <20020321132035.965602.FMU1100@piglet.prv.splode.com> >On Wed, Mar 20, 2002 at 02:42:05PM -0800, Noah Friedman wrote: >> It's recommended that recent versions of openssl be built only as static >> libraries because the ABIs are not yet stable (esp. the `engine' >> component). However, the library still uses dlopen. > >this depends on how you configure openssl. Granted, but I think it would be worthwhile to check whether explicitly linking with -ldl is required in the given environment. I will write the autoconf test, if you are willing to consider it. From austin at coremetrics.com Fri Mar 22 08:22:35 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 21 Mar 2002 15:22:35 -0600 Subject: OpenSSH 3.1p1 on Linux Slackware 8 with KERBEROS v5 support In-Reply-To: <20020321210542.GC30773@folly> References: <20020321210542.GC30773@folly> Message-ID: <1016745755.14419.5.camel@UberGeek> Sorry..HAHAHAHAHAH..Thanks for the chuckle! :) On Thu, 2002-03-21 at 15:05, Markus Friedl wrote: > On Thu, Mar 21, 2002 at 08:08:35PM +0100, marc.bigler at day.com wrote: > > Thanks those two patches work perfectly, I don't understand why this > isn't > > included by default into SSH, maybe law ?? > > ??? > > did you check the time of the patch and > the time of the OpenSSH 3.1 release? > _______________________________________________ > 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 From markus at openbsd.org Fri Mar 22 08:07:42 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Mar 2002 22:07:42 +0100 Subject: bug in ssh-keyscan.c -- In-Reply-To: <200203210344.WAA17242@aab.cc.purdue.edu> References: <200203210344.WAA17242@aab.cc.purdue.edu> Message-ID: <20020321210742.GD30773@folly> On Wed, Mar 20, 2002 at 10:44:41PM -0500, Paul Townsend wrote: > "ssh-keyscan.c" can't be linked statically against "libssh.a". You end > up with `fatal()' being doubly defined. i don't think so. fatal() is defined in fatal.o, so linking ssh-keyscan statically will exclude fatal.o From bugzilla-daemon at mindrot.org Fri Mar 22 08:43:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Mar 2002 08:43:19 +1100 (EST) Subject: [Bug 177] chroot tools for OpenSSH 3.1p1 Message-ID: <20020321214319.0F438E9DC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=177 ------- Additional Comments From nkadel at bellatlantic.net 2002-03-22 08:43 ------- Well, it wasn't my original idea, I'm just trying to get it implemented cleanly. It's not "common behavior" for rather different chroot environments, such as the limited environment of ftpd. That works for anonymous ftpd logins because the ftpd remains present as the user's interactive shell, interpreting their commands. To do this for OpenSSH, sshd or something like it would have to be use some kind of restricted shell, maintained and forked off, and it would prohibit local user login. By using the "/./" as a flag for the local user, the chroot behavior remains under root control, the user can use any shell the admin is willing to install for them, and once can even created shared environments as follows. nkadel:*:1000:1000:Shared SSH chroot for Nico:/home/shared/./../nkadel:/bin/bash If I log in locally, or look for my email, I wind up in /home/nkadel. If I come in via SSH, I wind up in /home/shared. This as opposed to: nkadel2:*:1000:1000:chroot SSH for Nico:/home/nkadel/./:/bin/bash For this, I'd wind up in /home/nkadel in a chroot cage. Does this make sense? I'd welcome better ideas. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Fri Mar 22 09:19:39 2002 From: tim at multitalents.net (Tim Rice) Date: Thu, 21 Mar 2002 14:19:39 -0800 (PST) Subject: openssh 3.1p1 linking problem In-Reply-To: <20020320144205.440914.FMU1100@piglet.prv.splode.com> Message-ID: On Wed, 20 Mar 2002, Noah Friedman wrote: > It's recommended that recent versions of openssl be built only as static > libraries because the ABIs are not yet stable (esp. the `engine' > component). However, the library still uses dlopen. > > Linking openssh will therefore fail unless linking against -ldl explicitly > along with -lcrypto. It should be harmless to do so when linking > dynamically. What platform are you on? What errors do you get? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From sxw at dcs.ed.ac.uk Fri Mar 22 09:29:35 2002 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Thu, 21 Mar 2002 22:29:35 +0000 (GMT) Subject: GSSAPI/Kerberos support in OpenSSH 3.1p1 Message-ID: I've now completed updating my patches for GSSAPI in protocol v2 to OpenSSH 3.1p1 See http://www.sxw.org.uk/computing/patches/openssh.html As previously, you will need to apply the protocol v1 krb5 patch before the GSSAPI one, and run autoreconf from an autoconf later than 2.52 There are a number of improvements and minor bug fixes over previous patches. However, due to protocol changes this patch will not interoperate with my GSSAPI patches to 2.9p2 and earlier. This patch is conditionally compliant with draft-ietf-secsh-gsskeyex-03.txt. It does not currently implement GSSAPI secured host key exchange, or the optional GSSAPI error message passing Thanks to all those who have emailed me asking when this would be available, and to all those who have contributed patches and code reviews. The list on is on the web page! Cheers, Simon. From aab at aab.cc.purdue.edu Fri Mar 22 10:35:51 2002 From: aab at aab.cc.purdue.edu (Paul Townsend) Date: Thu, 21 Mar 2002 18:35:51 EST Subject: bug in ssh-keyscan.c -- In-Reply-To: Your message of "Wed, 20 Mar 2002 22:44:41 EST." <200203210344.WAA17242@aab.cc.purdue.edu> Message-ID: <200203212335.SAA20485@aab.cc.purdue.edu> Oops. I really should have looked and tested a little longer and I might've noticed that `fatal()' now has its own file, "fatal.c". My comments/patch apply to an attempt to backport ssh-keyscan-3.1p1 to 3.0.2p1 where `fatal()' resides in "log.c". -- I apologize for using the bandwidth, -- Paul Townsend (aab at purdue.edu) On Wed, 20 Mar 2002 22:44:41 -0500 (EST), Paul Townsend wrote: >===== >Ladies/Gents, > >"ssh-keyscan.c" can't be linked statically against "libssh.a". You end >up with `fatal()' being doubly defined. > . . . S N I P From shade at chemlab.org Fri Mar 22 10:54:34 2002 From: shade at chemlab.org (steve j. kondik) Date: 21 Mar 2002 18:54:34 -0500 Subject: openssh + pam on solaris Message-ID: <1016754874.30924.15.camel@eris> this is an interesting one.. i hope someone can help out. i've got some solaris 8 boxes set up with pam_ldap and nss_ldap using the iplanet ldap sdk. openssh works until i enable SSL on the ldap server. when i turn SSL on, the user auths, sees the lastlog message, sees the MOTD, then nothing. with an openssh snapshot, you see the lastlog message only. the weird thing is that you are actually in a shell at this point. if you type a bad command you'll see an error, but you won't see anything else. this setup works perfect with the commercial ssh software, just not with openssh. i can provide a box for debugging if any openssh expert would like to check this out. -- http://chemlab.org - email shade-pgpkey at chemlab.org for pgp public key chemlab radio! - drop out @ http://mp3.chemlab.org:8000 24-7-365 "i could build anything if i could just find my tools.." From bugzilla-daemon at mindrot.org Fri Mar 22 11:20:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Mar 2002 11:20:06 +1100 (EST) Subject: [Bug 179] New: sshd sends channel data after sending EOF Message-ID: <20020322002006.842B9E9F2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=179 Summary: sshd sends channel data after sending EOF Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 URL: http://www.denisbider.com OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bugzilla-mindrot-org at denisbider.com I think this problem has 'major' severity because it causes sshd to violate the SSH2 protocol specification in such a way that the connection will immediately be terminated by most clients. There appears to be a semi-deterministic bug in sshd 3.1p1 (tested on SuSE Linux) which in certain conditions usually causes sshd to send data on a channel after it has already sent EOF, but before it has sent a channel close packet. The bug has been observed as follows: (1) client connects and authenticates (2) client sends exec request for a program that does not exist (3) client sends EOF (4) server sends EOF (5) server sends extended data after EOF has already been sent An sshd debug log from one such attempt is as follows: Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. Connection from 10.1.1.2 port 2283 debug1: Client protocol version 2.0; client software version 1.22 sshlib: SshMultiExec 1.1 debug1: no match: 1.22 sshlib: SshMultiExec 1.1 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 debug1: list_hostkey_types: ssh-rsa,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-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc 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-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes256-cbc,twofish-cbc,blowfish-cbc,3des- cbc,arcfour,cast128-cbc debug2: kex_parse_kexinit: aes256-cbc,twofish-cbc,blowfish-cbc,3des- cbc,arcfour,cast128-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib,none debug2: kex_parse_kexinit: zlib,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-sha1 debug1: kex: client->server aes256-cbc hmac-sha1 zlib debug2: mac_init: found hmac-sha1 debug1: kex: server->client aes256-cbc hmac-sha1 zlib debug1: dh_gen_key: priv key bits set: 253/512 debug1: bits set: 510/1024 debug1: expecting SSH2_MSG_KEXDH_INIT debug1: bits set: 497/1024 debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: cipher_init: set keylen (16 -> 32) debug1: Enabling compression at level 6. debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: cipher_init: set keylen (16 -> 32) debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user dbider service ssh-connection method password debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for dbider debug2: input_userauth_request: try method password Accepted password for dbider from 10.1.1.2 port 2283 ssh2 debug1: Entering interactive session for SSH2. debug1: fd 3 setting O_NONBLOCK debug1: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 20480 max 20480 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request exec reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req exec debug1: fd 9 setting O_NONBLOCK debug2: fd 9 is O_NONBLOCK debug1: fd 11 setting O_NONBLOCK debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: Received SIGCHLD. debug1: session_by_pid: pid 25454 debug1: session_exit_message: session 0 channel 0 pid 25454 debug1: channel request 0: exit-status debug1: session_exit_message: release channel 0 debug1: session_close: session 0 pid 25454 debug1: channel 0: read<=0 rfd 9 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug2: channel 0: read 296 from efd 11 debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug2: channel 0: rwin 20480 elen 296 euse 1 debug2: channel 0: sent ext data 296 debug1: channel 0: send close debug2: notify_done: reading debug2: channel 0: read 0 from efd 11 debug2: channel 0: closing read-efd 11 debug3: channel 0: will not send data after close debug3: channel 0: will not send data after close Received disconnect from 10.1.1.2: 2: unexpected channel message 6 debug1: Calling cleanup 0x805c800(0x0) debug1: channel_free: channel 0: server-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd 9/9) debug3: channel_close_fds: channel 0: r 9 w 9 e -1 debug1: Calling cleanup 0x8067f40(0x0) debug1: compress outgoing: raw data 393, compressed 283, factor 0.72 debug1: compress incoming: raw data 183, compressed 171, factor 0.93 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From oliver at tecq.org Fri Mar 22 18:36:33 2002 From: oliver at tecq.org (Oliver Wellnitz) Date: Fri, 22 Mar 2002 08:36:33 +0100 Subject: openssh 3.1p1: ToS trouble Message-ID: <20020322083633.A8851@angel.escape.de> In article <20020319131547.GB18652 at faui02> you wrote: > openssh sets TOS for packet_connection_is_ipv4() only I made a patch which solves my ToS issue. However, I do not use Kerberos which also uses packet_connection_is_ipv4(), so if anyone can test it I would like to hear about it. --- openssh-3.1p1/packet.c Tue Mar 5 02:31:29 2002 +++ openssh-3.1p1-v4inv6-ToS/packet.c Thu Mar 21 13:43:01 2002 @@ -178,13 +178,24 @@ { struct sockaddr_storage to; socklen_t tolen = sizeof(to); + struct sockaddr_in6 *to6; memset(&to, 0, sizeof(to)); if (getsockname(connection_out, (struct sockaddr *)&to, &tolen) < 0) return 0; - if (to.ss_family != AF_INET) + switch (to.ss_family) { + case AF_INET: + return 1; +#ifdef IPV4_IN_IPV6 + case AF_INET6: + to6 = (struct sockaddr_in6 *)&to; + if (IN6_IS_ADDR_V4MAPPED(&to6->sin6_addr)) + return 1; return 0; - return 1; +#endif + default: + return 0; + } } /* Sets the connection into non-blocking mode. */ From perrin at spectratech.com Fri Mar 22 19:56:22 2002 From: perrin at spectratech.com (Perrin) Date: Fri, 22 Mar 2002 16:56:22 +0800 Subject: Install OpenSSH-3.1p1 Error ! Message-ID: Hi, There are some problem during installation openssh-3.1p1. I refer to the installation guide to configure firstly, but it display warning "Could not find working OpenSSL lib."! So I need to install the OpenSSL lib before run the configuration? where is the OpenSSL lib ? Would I download from the Internet ? Attached the config.log file Thanks Perrin [root at perrin openssh-3.1p1]# ./configure ..................... ..................... checking for getuserattr in -ls... no checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether getpgrp takes no argument... yes checking for OpenSSL directory... configure: error: Could not find working OpenSSL library, please install or check config.log -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 93978 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020322/4f04bfc9/attachment.obj From bugzilla-daemon at mindrot.org Fri Mar 22 22:37:09 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Mar 2002 22:37:09 +1100 (EST) Subject: [Bug 179] sshd sends channel data after sending EOF Message-ID: <20020322113709.EF80FE92E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=179 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From markus at openbsd.org 2002-03-22 22:37 ------- hm, sshd is not sending channel data after EOF, it's sending _extended_ channel data. does EOF affect both channel data and extended channel data? the draft says: 3.3 Closing a Channel When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_EOF uint32 recipient_channel ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Mar 22 22:56:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Mar 2002 22:56:07 +1100 (EST) Subject: [Bug 180] New: [PATCH] sshd sets no ToS bit on connections with IPv4-mapped IPv6 addresses Message-ID: <20020322115607.A6FE4EA2C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=180 Summary: [PATCH] sshd sets no ToS bit on connections with IPv4- mapped IPv6 addresses Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: openssh at misc.tecq.org sshd recognises IPv4-mapped IPv6 addresses as non-IPv4 connections and therefore does not set the ToS bit. The following patch solves this problem. Compatibility checks with kerberos-enabled systems may be needed. --- openssh-3.1p1/packet.c Tue Mar 5 02:31:29 2002 +++ openssh-3.1p1-v4inv6-ToS/packet.c Thu Mar 21 13:43:01 2002 @@ -178,13 +178,24 @@ { struct sockaddr_storage to; socklen_t tolen = sizeof(to); + struct sockaddr_in6 *to6; memset(&to, 0, sizeof(to)); if (getsockname(connection_out, (struct sockaddr *)&to, &tolen) < 0) return 0; - if (to.ss_family != AF_INET) + switch (to.ss_family) { + case AF_INET: + return 1; +#ifdef IPV4_IN_IPV6 + case AF_INET6: + to6 = (struct sockaddr_in6 *)&to; + if (IN6_IS_ADDR_V4MAPPED(&to6->sin6_addr)) + return 1; return 0; - return 1; +#endif + default: + return 0; + } } ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From galvarez at anayamultimedia.es Fri Mar 22 23:20:37 2002 From: galvarez at anayamultimedia.es (Gema Alvarez Zamorano) Date: Fri, 22 Mar 2002 13:20:37 +0100 Subject: OpenSSH's logo Message-ID: <3C9B2195.709B02D1@anaya.es> Dear Sirs, We, Anaya MUltimedia, are a Spanish publisher of computing and IT books.We have a catalogue of around 600 titles, growing at a rate of 120 new titles per year and all our titles are classified in different series, each one addressed to a different sector of the market. (IF you would like to take a look at our catalogue, you are very wellcome to visit our web site at the following address:www.anayamultimedia.es). We are writing you because we are planning to publish one book about "Open Source" and we would like to be able to reproduce the logo of your product "OpenSSH" and place it close to each part, where the book makes reference to this software. Therefore, we would appreciate it very much if you could, please, give us permission to do this. Thanking you in advance; We are looking forward to hearing from you. Best regards, GEma PS. Your quick reply would be very much appreciated. -- Gema ?lvarez Zamorano Foreign Rights Manager Anaya Multimedia Juan Ignacio Luca de Tena, 15 28027 - Madrid Tlfno. 913938962 Fax 913204419 galvarez at anaya.es http://www.AnayaMultimedia.es http://www.en-linea.net From bugzilla-daemon at mindrot.org Sat Mar 23 00:07:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Mar 2002 00:07:41 +1100 (EST) Subject: [Bug 179] sshd sends channel data after sending EOF Message-ID: <20020322130741.29D13E94E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=179 ------- Additional Comments From bugzilla-mindrot-org at denisbider.com 2002-03-23 00:07 ------- Much like a black man is still a man, and a brown cow is still a cow, I would think that extended data is still data - especially since data and extended data consume the same window. This should be no issue. However, I think the draft should be more clear about how EOF relates to channel requests. It doesn't say anything about whether requests and responses can be sent after EOF has been sent. I'll follow up your message about that on the sex-age - I mean, secsh mailing list. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Denis.Ducamp at hsc.fr Sat Mar 23 00:15:56 2002 From: Denis.Ducamp at hsc.fr (Denis Ducamp) Date: Fri, 22 Mar 2002 14:15:56 +0100 Subject: privsep In-Reply-To: ; from stevesk@pobox.com on Wed, Mar 20, 2002 at 02:46:47PM -0800 References: Message-ID: <20020322141556.B8971@hsc.fr> On Wed, Mar 20, 2002 at 02:46:47PM -0800, Kevin Steves wrote: > i think our strategy for privsep is to just keep portable sync'd closely > with openbsd's tree, even though things will be broken wrt privsep for > many platforms. then we just get primary one's working and work out > issues as we go along. i'll start to work on sun and hp-ux again > tomorrow. First of all thanks to Niels Provos, Markus Friedl and all others for that work. I successfully used privsep this morning on Linux Slackware 8.0 after applying the following patch and getting the tree.h file from http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.2&content-type=text/plain You have to activate it in sshd_config with UsePrivilegeSeparation yes and then you can verify that it works : term1$ ssh localhost => wait to enter your password term2# ps auwwx | grep sshd root 17403 0.2 0.9 3768 1240 ? S 14:04 0:00 /usr/local/sbin/sshd nobody 17404 1.1 0.9 3776 1256 ? S 14:04 0:00 /usr/local/sbin/sshd term2# lsof -p 17404 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 17404 root cwd DIR 3,6 4096 604111 /var/empty sshd 17404 root rtd DIR 3,6 4096 604111 /var/empty [...] => enter your password in term1 term2# ps auwwx | grep sshd root 17403 0.0 1.2 5568 1556 ? S 14:04 0:00 /usr/local/sbin/sshd ducamp 17411 0.6 1.1 5040 1384 ? S 14:06 0:00 /usr/local/sbin/sshd term2# lsof -p 17411 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME sshd 17411 root cwd DIR 3,6 4096 2 / sshd 17411 root rtd DIR 3,6 4096 2 / [...] ( why my lsof shows processes 17404 and 17411 as root is a mistery... ) Denis Ducamp. -- Denis.Ducamp at hsc.fr --- Herv? Schauer Consultants --- http://www.hsc.fr/ Owl/Openwall/snort/hping/dsniff en fran?ais http://www.groar.org/trad/ Owl en fran?ais http://www.openwall.com/Owl/fr/ Du bon usage de ... http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html -------------- next part -------------- diff -dur --new-file openssh/cipher.c openssh.new/cipher.c --- openssh/cipher.c Fri Mar 22 03:54:25 2002 +++ openssh.new/cipher.c Fri Mar 22 11:24:15 2002 @@ -507,6 +507,13 @@ for (i = blocks; i > 0; i--, cnow-=RIJNDAEL_BLOCKSIZE, plain-=RIJNDAEL_BLOCKSIZE) { rijndael_decrypt(&c->r_ctx, cnow, plain); + ivp = (i == 1) ? c->r_iv : cnow-RIJNDAEL_BLOCKSIZE; + for (j = 0; j < RIJNDAEL_BLOCKSIZE; j++) + plain[j] ^= ivp[j]; + } + memcpy(c->r_iv, buf, RIJNDAEL_BLOCKSIZE); + } + return (1); } /* @@ -675,13 +682,6 @@ plen = EVP_X_STATE_LEN(cc->evp); memcpy(EVP_X_STATE(cc->evp), dat, plen); } - ivp = (i == 1) ? c->r_iv : cnow-RIJNDAEL_BLOCKSIZE; - for (j = 0; j < RIJNDAEL_BLOCKSIZE; j++) - plain[j] ^= ivp[j]; - } - memcpy(c->r_iv, buf, RIJNDAEL_BLOCKSIZE); - } - return (1); } static int ssh_rijndael_cleanup(EVP_CIPHER_CTX *ctx) diff -dur --new-file openssh/monitor.c openssh.new/monitor.c --- openssh/monitor.c Fri Mar 22 03:30:43 2002 +++ openssh.new/monitor.c Fri Mar 22 11:38:00 2002 @@ -494,7 +494,9 @@ buffer_put_cstring(m, pwent->pw_name); buffer_put_cstring(m, "*"); buffer_put_cstring(m, pwent->pw_gecos); +#if defined(HAVE_PW_CLASS_IN_PASSWD) buffer_put_cstring(m, pwent->pw_class); +#endif buffer_put_cstring(m, pwent->pw_dir); buffer_put_cstring(m, pwent->pw_shell); diff -dur --new-file openssh/monitor_mm.h openssh.new/monitor_mm.h --- openssh/monitor_mm.h Fri Mar 22 03:30:43 2002 +++ openssh.new/monitor_mm.h Fri Mar 22 11:34:50 2002 @@ -25,7 +25,7 @@ #ifndef _MM_H_ #define _MM_H_ -#include +#include struct mm_share { RB_ENTRY(mm_share) next; diff -dur --new-file openssh/monitor_wrap.c openssh.new/monitor_wrap.c --- openssh/monitor_wrap.c Fri Mar 22 03:30:43 2002 +++ openssh.new/monitor_wrap.c Fri Mar 22 11:00:02 2002 @@ -197,7 +197,9 @@ pw->pw_name = buffer_get_string(&m, NULL); pw->pw_passwd = buffer_get_string(&m, NULL); pw->pw_gecos = buffer_get_string(&m, NULL); +#if defined(HAVE_PW_CLASS_IN_PASSWD) pw->pw_class = buffer_get_string(&m, NULL); +#endif pw->pw_dir = buffer_get_string(&m, NULL); pw->pw_shell = buffer_get_string(&m, NULL); buffer_free(&m); Binary files openssh/scard/Ssh.bin and openssh.new/scard/Ssh.bin differ From bugzilla-daemon at mindrot.org Sat Mar 23 01:05:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Mar 2002 01:05:56 +1100 (EST) Subject: [Bug 179] sshd sends channel data after sending EOF Message-ID: <20020322140556.0D5B2E947@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=179 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|markus at openbsd.org Severity|major |normal Status|ASSIGNED |NEW OS/Version|Linux |All Priority|P2 |P1 Platform|ix86 |All ------- Additional Comments From markus at openbsd.org 2002-03-23 01:05 ------- extended data handling is an ad hoc hack and very broken. should fix it.... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Nicolas.Williams at ubsw.com Sat Mar 23 02:49:57 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 22 Mar 2002 10:49:57 -0500 Subject: Auto-rekey? (was Re: GSSAPI/Kerberos support in OpenSSH 3.1p1) In-Reply-To: ; from sxw@dcs.ed.ac.uk on Thu, Mar 21, 2002 at 10:29:35PM +0000 References: Message-ID: <20020322104955.N27398@sm2p1386swk.wdr.com> A thought occurs: have the client attempt to automatically initiate re-keying when the GSS context is due to expire or, if expired, every few minutes. Let me be more specific. The way SSH gsskeyex works GSS context expiration is unimportant, but GSS context expiration is a clue on a tip as to when forwarded credentials expire. It would be useful if credentials were re-forwarded automatically when refreshed. The way one re-forwards GSS credentials with SSH gsskeyex is by re-keying the session. The client can find out from gss_init_sec_context() when the context and any forwarded credentials, will expire. The client can check, when the time comes, and periodically thereafter, if new credentials are available, and if so, re-key the SSH session. To make this happen would require a hook in the client loop (but NOT a select() timeout). This way one need only kinit in one place and tickets will eventually be re-forwarded automatically. Is there any interest in such a feature? Advice? Cheers, Nico On Thu, Mar 21, 2002 at 10:29:35PM +0000, Simon Wilkinson wrote: > > I've now completed updating my patches for GSSAPI in protocol v2 to > OpenSSH 3.1p1 > See http://www.sxw.org.uk/computing/patches/openssh.html > > Cheers, > > Simon. > > _______________________________________________ > 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 dwd at bell-labs.com Sat Mar 23 05:37:35 2002 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 22 Mar 2002 12:37:35 -0600 Subject: Is OpenSSH vulnerable to the ZLIB problem or isn't it? Message-ID: <20020322183735.GA21975@lucent.com> SSH.COM says their SSH2 is not vulnerable to the ZLIB problem even though they use the library (details below). Can OpenSSH say the same thing? In either case, it seems like there ought to be an openssh-unix-announce message about what the situation is. I may have missed it, but I don't believe there was one. Yes, openssh doesn't have its own copy of zlib source but it would still be helpful to have a statement, especially since it appears under protocol 2 that it's potentially exploitable before authentication. - Dave Dykstra ----- Forwarded message from Erik Parker ----- Mailing-List: contact secureshell-help at securityfocus.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list secureshell at securityfocus.com Delivered-To: moderator for secureshell at securityfocus.com Date: Wed, 20 Mar 2002 12:59:59 -0600 (CST) From: Erik Parker To: secureshell at securityfocus.com Subject: RE: ZLIB.. WHere is SSH.COM?! Part 2 (fwd) ---------- Forwarded message ---------- Date: Mon, 18 Mar 2002 08:08:41 -0800 From: Thi Le To: Erik Parker Subject: RE: ZLIB.. WHere is SSH.COM?! Dear Erik, We sincerely apologize for the delay in responding to your question and concerns. Below are the comments from our product management team: There has been a vulnerability in zlib compression library that is being used by SSH Secure Shell and numerous other applications and operating systems. SSH Secure Shell is NOT vulnerable to this thanks to our implementation style. Our software is using the vulnerable zlib library, but it can't be exploited. If someone tries to perform an exploit only that specific connection will crash. Not the server nor any other connections. We will upgrade the zlib library in our future releases. CERT and CERT-FI has been notified, no other reaction is necessary at this point. For further technical information, please see the technical explanation below. The problem works as follows: when a maliciously corrupted compressed data stream is decompressed, it can cause the function inflate_blocks() to enter a certain state and return FALSE. If called again in this state, this function can cause a heap corruption exploitable by the attacker. (More precisely, both the first and the second call will attempt to free the same pointer. This is layed out in more detail in the advisory.) We do not use the zlib directly. Instead, we use a wrapper library bufzip that is the only point in our code that is in directly contact to the zlib. The crucial point is this: if bufzip calls the misbehaving function in the zlib, it always checks whether the return value is TRUE. If not, it terminates the process with a message that the compressed data stream is corrupted. Consequently, every attempt to attack makes the connection collapse with a nasty error, which is exactly what we want if an attack is going on. No other effects are possible. I hope that answers your question & concerns. Please feel free to contact me if I can be of any further assistance. Sincerely, Thi Le Eastern Region Territory Manager SSH Communications Security ----- End forwarded message ----- From darrenm at eng.sun.com Sat Mar 23 05:41:12 2002 From: darrenm at eng.sun.com (Darren J Moffat) Date: Fri, 22 Mar 2002 10:41:12 -0800 (PST) Subject: incomplete/insufficient logic for making access decisions In-Reply-To: <20020318212524.C15467@google.com> Message-ID: On Mon, 18 Mar 2002, Frank Cusack wrote: > I'd agree, this sounds like a reasonable (possibly even good) thing to do. > You'd have to delay PAM startup until a non-PAM auth started (if you used > PAM auth you'd have to end it and restart it -- ugly and not worthwhile). > > Something like > > # Account service to use for non-PAM authentication. When using > # PAM auth, this is always "sshd". When using non-PAM auth (eg rsa) > # the configured service name is used. Can contain %a which is > # substituted with the auth type. Default is "sshd". > PAMAcctService sshd I very strongly disagree with this. As one of the "keepers" of PAM at Sun (the original author) this is the wrong thing to do. Doing this increases the complexity of the administration. There is a better mechanism for doing this in Solaris but it is not yet public - we are in the process of doing this just now. I believe it solves the issue. -- Darren J Moffat From bugzilla-daemon at mindrot.org Sat Mar 23 05:46:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Mar 2002 05:46:08 +1100 (EST) Subject: [Bug 179] sshd sends channel data after sending EOF Message-ID: <20020322184608.2584AEA68@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=179 ------- Additional Comments From markus at openbsd.org 2002-03-23 05:46 ------- Created an attachment (id=52) possible fix ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From homega at wanadoo.es Sat Mar 23 06:20:32 2002 From: homega at wanadoo.es (Horacio) Date: Fri, 22 Mar 2002 20:20:32 +0100 Subject: OpenSSH's logo In-Reply-To: <3C9B2195.709B02D1@anaya.es>; from galvarez@anayamultimedia.es on Fri, Mar 22, 2002 at 01:20:37PM +0100 References: <3C9B2195.709B02D1@anaya.es> Message-ID: <20020322202032.A23170@wanadoo.es> Dear Gema, AFAIK all OpenBSD and OpenSSH *official* logos are free for fair use, distribution and to reproduce (more so if they are going to be used for advertising or documenting OpenBSD or OpenSSH), unless otherwise stated. If in doubt, please check http://www.openbsd.org/es/policy.html Kind Regards, On Fri, Mar 22, 2002 at 01:20:37PM +0100, Gema Alvarez Zamorano wrote: > Dear Sirs, > > We, Anaya MUltimedia, are a Spanish publisher of computing and IT > books.We have a catalogue of around 600 titles, growing at a rate of 120 > new titles per year and all our titles are classified in different > series, each one addressed to a different sector of the market. (IF > you would like to take a look at our catalogue, you are very wellcome to > visit our web site at the following address:www.anayamultimedia.es). > > We are writing you because we are planning to publish one book about > "Open Source" and we would like to be able to reproduce the logo of your > product "OpenSSH" and place it close to each part, where the book makes > reference to this software. Therefore, we would appreciate it very much > if you could, please, give us permission to do this. > > > Thanking you in advance; We are looking forward to hearing from you. > Best regards, > GEma > > > PS. Your quick reply would be very much appreciated. > > > > -- > Gema ?lvarez Zamorano > Foreign Rights Manager > Anaya Multimedia > Juan Ignacio Luca de Tena, 15 > 28027 - Madrid > Tlfno. 913938962 > Fax 913204419 > galvarez at anaya.es > http://www.AnayaMultimedia.es > http://www.en-linea.net -- Horacio From pin at math.chalmers.se Sat Mar 23 07:18:37 2002 From: pin at math.chalmers.se (Ivan Popov) Date: Fri, 22 Mar 2002 21:18:37 +0100 (MET) Subject: incomplete/insufficient logic for making access decisions In-Reply-To: Message-ID: On Fri, 22 Mar 2002, Darren J Moffat wrote: > > # Account service to use for non-PAM authentication. When using > > # PAM auth, this is always "sshd". When using non-PAM auth (eg rsa) > > # the configured service name is used. Can contain %a which is > > # substituted with the auth type. Default is "sshd". > I very strongly disagree with this. As one of the "keepers" of PAM > at Sun (the original author) this is the wrong thing to do. Doing this > increases the complexity of the administration. > > There is a better mechanism for doing this in Solaris but it is not yet > public - we are in the process of doing this just now. I believe it > solves the issue. Hello Darren, thank you for making us aware of that development. I would appreciate if you could tell us more about it than just the fact it is going to exist. At least the time perspective (days, weeks, months) when more information will be available. Best regards, -- Ivan From bugzilla-daemon at mindrot.org Sat Mar 23 07:27:18 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Mar 2002 07:27:18 +1100 (EST) Subject: [Bug 181] New: Undocumented mget and mput in sftp Message-ID: <20020322202718.54DB4EAA4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=181 Summary: Undocumented mget and mput in sftp Product: Portable OpenSSH Version: 3.1p1 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Maldoror at worldnet.att.net Althgough 'mget' and 'mput' work under sftp, they are not documented in the sftp help menu. Also, are there plans to add the ftp equivalent 'hash' and 'prompt' commands? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Sat Mar 23 09:18:06 2002 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 22 Mar 2002 14:18:06 -0800 (PST) Subject: privsep In-Reply-To: <20020322141556.B8971@hsc.fr> Message-ID: On Fri, 22 Mar 2002, Denis Ducamp wrote: :I successfully used privsep this morning on Linux Slackware 8.0 after :applying the following patch and getting the tree.h file from :http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/sys/tree.h?rev=1.2&content-type=text/plain : :You have to activate it in sshd_config with : UsePrivilegeSeparation yes :and then you can verify that it works : cool. with several changes which should show up in tomorrow's snapshot, it's working for me on hp-ux 11 and solaris 8 (no PAM support yet). From bugzilla-daemon at mindrot.org Sat Mar 23 10:13:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Mar 2002 10:13:30 +1100 (EST) Subject: [Bug 182] New: ssh should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper Message-ID: <20020322231330.D06C3E968@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=182 Summary: ssh should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: All Status: NEW Severity: normal Priority: P3 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: solgato at us.ibm.com Programs that set a SIGCHLD handler before calling ssh wreak havoc on the waitpid() calls within entropy.c and ssh-rand-helper. Entropy.c should set the SIGCHLD handler to SIG_DFL before calling ssh-rand-helper to avoid SIGCHLD conflicts. This was noticed when our ssh version was upgraded to 3.1. Our local rsync processes were failing with the following output from SSH: Couldn't wait for child 'ls -alni /usr/adm' completion: No child processes Couldn't wait for child 'ls -alni /usr/mail' completion: No child processes Couldn't wait for child 'netstat -an' completion: No child processes Couldn't wait for child 'netstat -in' completion: No child processes Couldn't wait for child 'netstat -rn' completion: No child processes Couldn't wait for child 'netstat -ia' completion: No child processes Couldn't wait for child 'netstat -s' completion: No child processes Couldn't wait for child 'netstat -is' completion: No child processes Couldn't wait for child 'arp -a -n' completion: No child processes Couldn't wait for child 'ifconfig -a' completion: No child processes Couldn't wait for child 'ps -al' completion: No child processes Couldn't wait for child 'ps -efl' completion: No child processes Couldn't wait for child 'last' completion: No child processes Couldn't wait for child 'sar -d' completion: No child processes Couldn't wait for child 'uptime' completion: No child processes Couldn't wait for child 'ipcs -a' completion: No child processes Not enough entropy in RNG ssh-rand-helper child produced insufficient data unexpected EOF in read_timeout It was discovered that rsync had set SIGCHLD to SIG_IGN prior to calling ssh. Setting SIGCHLD to SIG_DFL prior to forking ssh-rand-helper (seed_rng() in entropy.c) solved this problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dcole at keysoftsys.com Sat Mar 23 10:27:31 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Fri, 22 Mar 2002 15:27:31 -0800 Subject: Trusted HP-UX 10.26 Message-ID: <024601c1d1f9$35d97470$9b78a8c0@oedserver> I haven't noticed any work on Trusted HP-UX 10.26 in the archives (then again maybe I missed it). I have made changes to get sshd working on trusted HP-UX, ssh already worked. I can supply a patch, but before I did I was wondering if it is best to send the patch to this list, or file it as a bug report? The patch is just around 6k, and includes changes to configure.ac and acconfig.h, allong with the code changes. The patch is against openssh-3.1p1. I also have some preliminary .psf files to create software depots (software packaging for hp-ux), though I have not integrated these into the build process yet. Darren Cole dcole at keysoftsys.com From mouring at etoh.eviladmin.org Sat Mar 23 10:46:01 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 22 Mar 2002 17:46:01 -0600 (CST) Subject: Trusted HP-UX 10.26 In-Reply-To: <024601c1d1f9$35d97470$9b78a8c0@oedserver> Message-ID: Depending on what the patch contains.. I'd rather seen a few small well defined "Fixed XYZ bug" patches in bugzilla then "Makes HP/UX works" large patch myself. It allows us to pick apart and decide what we will accept and what should be rewritten.. or what may be useful for upstream. - Ben On Fri, 22 Mar 2002, Darren Cole wrote: > > I haven't noticed any work on Trusted HP-UX 10.26 in the archives (then > again maybe I missed it). I have made changes to get sshd working on > trusted HP-UX, ssh already worked. I can supply a patch, but before I did I > was wondering if it is best to send the patch to this list, or file it as a > bug report? The patch is just around 6k, and includes changes to > configure.ac and acconfig.h, allong with the code changes. The patch is > against openssh-3.1p1. > > I also have some preliminary .psf files to create software depots (software > packaging for hp-ux), though I have not integrated these into the build > process yet. > > Darren Cole > dcole at keysoftsys.com > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim at multitalents.net Sat Mar 23 12:13:27 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 22 Mar 2002 17:13:27 -0800 (PST) Subject: Trusted HP-UX 10.26 In-Reply-To: Message-ID: On Fri, 22 Mar 2002, Ben Lindstrom wrote: > > Depending on what the patch contains.. I'd rather seen a few small well > defined "Fixed XYZ bug" patches in bugzilla then "Makes HP/UX works" large > patch myself. > > It allows us to pick apart and decide what we will accept and what should > be rewritten.. or what may be useful for upstream. I like to see the complete patch sent to the list too. I find that I look at patches sooner if they are sent to the list. But be sure to post to bugzilla too as Ben said. Anything that hangs out in ones mail box too long tends to get lost. :-) > > - Ben > > On Fri, 22 Mar 2002, Darren Cole wrote: > > > > > I haven't noticed any work on Trusted HP-UX 10.26 in the archives (then > > again maybe I missed it). I have made changes to get sshd working on > > trusted HP-UX, ssh already worked. I can supply a patch, but before I did I > > was wondering if it is best to send the patch to this list, or file it as a > > bug report? The patch is just around 6k, and includes changes to > > configure.ac and acconfig.h, allong with the code changes. The patch is > > against openssh-3.1p1. > > > > I also have some preliminary .psf files to create software depots (software > > packaging for hp-ux), though I have not integrated these into the build > > process yet. > > > > Darren Cole > > dcole at keysoftsys.com -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dcole at keysoftsys.com Sat Mar 23 12:20:05 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Fri, 22 Mar 2002 17:20:05 -0800 Subject: Trusted HP-UX 10.26 References: Message-ID: <02a201c1d208$efede080$9b78a8c0@oedserver> If it is preferred I can easily break it up to five patches, one file per patch. Either way I will post it to bugzilla also. Darren dcole at keysoftsys.com ----- Original Message ----- > > Depending on what the patch contains.. I'd rather seen a few small well > defined "Fixed XYZ bug" patches in bugzilla then "Makes HP/UX works" large > patch myself. > > It allows us to pick apart and decide what we will accept and what should > be rewritten.. or what may be useful for upstream. > > - Ben > From stevesk at pobox.com Sat Mar 23 12:30:38 2002 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 22 Mar 2002 17:30:38 -0800 (PST) Subject: Trusted HP-UX 10.26 In-Reply-To: <024601c1d1f9$35d97470$9b78a8c0@oedserver> Message-ID: On Fri, 22 Mar 2002, Darren Cole wrote: : I haven't noticed any work on Trusted HP-UX 10.26 in the archives (then :again maybe I missed it). I have made changes to get sshd working on :trusted HP-UX, ssh already worked. I can supply a patch, but before I did I :was wondering if it is best to send the patch to this list, or file it as a :bug report? The patch is just around 6k, and includes changes to :configure.ac and acconfig.h, allong with the code changes. The patch is :against openssh-3.1p1. I haven't heard of anyone using CMW in a few years. I can take a look at what you have. Have you seen Chris Dalton's work: http://www.hpl.hp.com/techreports/98/HPL-98-99R1.html From mouring at etoh.eviladmin.org Sat Mar 23 13:17:11 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 22 Mar 2002 20:17:11 -0600 (CST) Subject: Trusted HP-UX 10.26 In-Reply-To: <02a201c1d208$efede080$9b78a8c0@oedserver> Message-ID: I'd rather see it grouped around fixes.. not files. If a set of fixes spans two files..fine. Things like: Patch 1 - Fixed Trusted HP/UX missing function 'foo' Patch 2 - HP/UX header 'bar.h' is not compatible ..etc.. - Ben On Fri, 22 Mar 2002, Darren Cole wrote: > If it is preferred I can easily break it up to five patches, one file per > patch. > Either way I will post it to bugzilla also. > > Darren > dcole at keysoftsys.com > > ----- Original Message ----- > > > > Depending on what the patch contains.. I'd rather seen a few small well > > defined "Fixed XYZ bug" patches in bugzilla then "Makes HP/UX works" large > > patch myself. > > > > It allows us to pick apart and decide what we will accept and what should > > be rewritten.. or what may be useful for upstream. > > > > - Ben > > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From fcusack at fcusack.com Sun Mar 24 02:22:00 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sat, 23 Mar 2002 07:22:00 -0800 Subject: incomplete/insufficient logic for making access decisions In-Reply-To: ; from darrenm@eng.sun.com on Fri, Mar 22, 2002 at 10:41:12AM -0800 References: <20020318212524.C15467@google.com> Message-ID: <20020323072159.A1087@google.com> On Fri, Mar 22, 2002 at 10:41:12AM -0800, Darren J Moffat wrote: > On Mon, 18 Mar 2002, Frank Cusack wrote: > > > I'd agree, this sounds like a reasonable (possibly even good) thing to do. > > You'd have to delay PAM startup until a non-PAM auth started (if you used > > PAM auth you'd have to end it and restart it -- ugly and not worthwhile). > > > > Something like > > > > # Account service to use for non-PAM authentication. When using > > # PAM auth, this is always "sshd". When using non-PAM auth (eg rsa) > > # the configured service name is used. Can contain %a which is > > # substituted with the auth type. Default is "sshd". > > PAMAcctService sshd > > I very strongly disagree with this. As one of the "keepers" of PAM > at Sun (the original author) this is the wrong thing to do. Doing this > increases the complexity of the administration. > > There is a better mechanism for doing this in Solaris but it is not yet > public - we are in the process of doing this just now. I believe it > solves the issue. It may be the wrong thing, but PAM currently offers no other way to do it. I was actually thinking to suggest setting something in appdata but then every PAM module has to know about it. Of course if you can correct me here I would love to know how to do this some better way. The most portable mechanism is using a different service name. And it's not so unwieldy, I don't think. /fc From ANTIGEN_ABRA at wrq.com Sun Mar 24 04:15:55 2002 From: ANTIGEN_ABRA at wrq.com (ANTIGEN_ABRA) Date: Sat, 23 Mar 2002 09:15:55 -0800 Subject: Antigen Notification:Antigen found FILE FILTER= *.pif file Message-ID: <616772E97E38D31188FA00508B318ACA03FA418C@abra.wrq.com> Antigen for Exchange found Gizn.pif matching FILE FILTER= *.pif file filter. The file is currently Purged. The message, "Have a humour Lady Day", was sent from konkurs and was discovered in IMC Queues\Inbound located at WRQ/Seattle/ABRA. From teardrop at teardrop.ca Sun Mar 24 15:25:12 2002 From: teardrop at teardrop.ca (Paul-Andrew Joseph Miseiko) Date: Sat, 23 Mar 2002 23:25:12 -0500 Subject: FreeBSD 4.x Message-ID: <20020324042459.B42E02AAC0@teardrop.ca> On FreeBSD 4.x with HAVE_LOGIN_CAP defined the OpenSSH daemon doesn't properly follow standards. As stated in man 5 login.conf and the process followed by /usr/bin/login, "The ttys.allow and ttys.deny entries contain a comma-separated list of tty devices (without the /dev/ prefix) that a user in a class may use to access the system, and/or a list of ttygroups (See getttyent(3) and ttys(5) for information on ttygroups)." It appears that the OpenSSH Daemon (sshd) is sending the /dev/ to be verified along with the tty*. Quick fix, either add /dev/ to your login.conf ttys.* entries or make the sshd cut of the leading /dev/. Proposed idea, "sscanf(s->tty, "/dev/%s", s->parsed_tty);" I'm no fan of sscanf but I don't feel like pasting a while loop following be counter variables, etc, for parsing to a mailing list :) The splice of code is found in session.c #ifdef HAVE_LOGIN_CAP if (!auth_ttyok(lc, s->tty)) { (void)printf("Permission denied.\n"); log( "LOGIN %.200s REFUSED (TTY) FROM %.200s ON TTY %.200s", pw->pw_name, get_remote_name_or_ip(utmp_len, options.verify_reverse_mapping), s->tty); exit(254); } #endif /* HAVE_LOGIN_CAP */ From teardrop at teardrop.ca Sun Mar 24 16:00:00 2002 From: teardrop at teardrop.ca (Paul-Andrew Joseph Miseiko) Date: Sun, 24 Mar 2002 00:00:00 -0500 Subject: FreeBSD 4.x Message-ID: <20020324045947.767532AAC0@teardrop.ca> It would appear that the added functional HAVE_LOGIN_CAP came from a ports patch. Therefor I guess I better email the ports maintainer instead :). On Sat, 23 Mar 2002 23:25:12 -0500, Paul-Andrew Joseph Miseiko wrote: > On FreeBSD 4.x with HAVE_LOGIN_CAP defined the OpenSSH daemon doesn't properly follow standards. > >As stated in man 5 login.conf and the process followed by /usr/bin/login, >"The ttys.allow and ttys.deny entries contain a comma-separated list of > tty devices (without the /dev/ prefix) that a user in a class may use to > access the system, and/or a list of ttygroups (See getttyent(3) and > ttys(5) for information on ttygroups)." > >It appears that the OpenSSH Daemon (sshd) is sending the /dev/ to be verified along with the tty*. > >Quick fix, either add /dev/ to your login.conf ttys.* entries or make the sshd cut of the leading /dev/. > >Proposed idea, >"sscanf(s->tty, "/dev/%s", s->parsed_tty);" > >I'm no fan of sscanf but I don't feel like pasting a while loop following be counter variables, etc, for parsing to a mailing list :) > >The splice of code is found in session.c > >#ifdef HAVE_LOGIN_CAP > if (!auth_ttyok(lc, s->tty)) { > (void)printf("Permission denied.\n"); > log( > "LOGIN %.200s REFUSED (TTY) FROM %.200s ON TTY %.200s", > pw->pw_name, get_remote_name_or_ip(utmp_len, > options.verify_reverse_mapping), s->tty); > exit(254); > } >#endif /* HAVE_LOGIN_CAP */ > > From tomh at po.crl.go.jp Mon Mar 25 17:22:01 2002 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Mon, 25 Mar 2002 15:22:01 +0900 (JST) Subject: compile failure Message-ID: The latest snapshot (20020324) fails to compile here. Linux 2.4.18-rc1 Alpha The first messages are: monitor_wrap.c: In function `mm_request_receive': monitor_wrap.c:91: warning: int format, different type arg (arg 3) monitor_wrap.c:100: warning: int format, different type arg (arg 3) which have to do with fatal() calls and int not being the same as ssize_t... But the next one is the problem: monitor_mm.h:28:22: sys/tree.h: No such file or directory then all heck breaks loose. What's sys/tree.h supposed to be? Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ From bugzilla-daemon at mindrot.org Mon Mar 25 17:56:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 25 Mar 2002 17:56:34 +1100 (EST) Subject: [Bug 183] New: Compile failure of OpenSSH on Solaris 2.6 Message-ID: <20020325065634.B7985E906@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=183 Summary: Compile failure of OpenSSH on Solaris 2.6 Product: Portable OpenSSH Version: 3.1p1 Platform: UltraSparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: geoff.kozens at powersurfr.com This bug is what I believe is in some form a subset of bug 138. When compiling on SunOS 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-2... using the ./complile --with-afs --with-kerberos4 I receive the following error for openssh-3.1p1. I am using OpenSSL 0.9.6c and Zlib 1.1.4 I compliled this with gcc version 2.8.1 and received the following error From tomh at po.crl.go.jp Mon Mar 25 18:44:34 2002 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Mon, 25 Mar 2002 16:44:34 +0900 (JST) Subject: compile failure In-Reply-To: Message-ID: On Mon, 25 Mar 2002, Tom Holroyd wrote: > monitor_mm.h:28:22: sys/tree.h: No such file or directory OK, I got tree.h (thanks Denis), and there are a few additional warnings: auth-rsa.c: In function `auth_rsa_key_allowed': auth-rsa.c:168: warning: return makes integer from pointer without a cast auth-rsa.c:176: warning: return makes integer from pointer without a cast auth-rsa.c:184: warning: return makes integer from pointer without a cast auth_rsa_key_allowed() is returning NULL instead of 0. monitor_mm.c: In function `mm_make_entry': monitor_mm.c:60: warning: int format, different type arg (arg 5) monitor_mm.c: In function `mm_create': monitor_mm.c:88: warning: int format, different type arg (arg 2) monitor_mm.c: In function `mm_destroy': monitor_mm.c:127: warning: int format, different type arg (arg 3) monitor_mm.c: In function `mm_xmalloc': monitor_mm.c:141: warning: int format, different type arg (arg 3) monitor_mm.c: In function `mm_free': monitor_mm.c:227: warning: int format, different type arg (arg 3) monitor_mm.c:250: warning: int format, different type arg (arg 4) These are mostly sizeof(int) == 4, sizeof(long) == 8 bugs. Other than that it works fine now (+ SRP). From v_t_m at seznam.cz Tue Mar 26 01:53:34 2002 From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=) Date: Mon, 25 Mar 2002 15:53:34 +0100 (CET) Subject: =?iso-8859-2?Q?SecurID=20support=20for=20OpenSSH?= Message-ID: <2465.25954-15875-2085750552-1017068014@seznam.cz> Hello all, I have made integration of SecurID authentication into OpenSSH 3.1p1. In this solution, 3 types of authentication are prepared to support SecurID tokens: - password authentication (*) - keyboard interactive authentication (**) - securid-1 at ssh.com authentication (implemented especially by commercial clients) (**) (*) usable only when SecurID card is in "normal" state (not NewPIN or NextTokencode) (**) fully supports all SecurID states This patch is implemented only for SSH2 protocol, modifying only the server side. Clients remain unchanged, so you can use the client that you prefer. To properly configure and compile, you need ACE/Agent 3.x installed. I am working on conversion of this patch for ACE/Agent 5.x. This patch will be suitable for both agents then. Details (implementation, configuration, ...) are described in README.SecurID file located on distribution site. Patch and documentation available at: http://sweb.cz/v_t_m/ Vaclav Tomec ______________________________________________________________________ Budte GEnius. Mejte vsech pet pohromade. http://www.genius.cz From mouring at etoh.eviladmin.org Tue Mar 26 01:33:04 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 25 Mar 2002 08:33:04 -0600 (CST) Subject: compile failure In-Reply-To: Message-ID: The --current tree is in a sligh flux as we start to migrate platforms to support Privilage seperation. - Ben On Mon, 25 Mar 2002, Tom Holroyd wrote: > On Mon, 25 Mar 2002, Tom Holroyd wrote: > > > monitor_mm.h:28:22: sys/tree.h: No such file or directory > > OK, I got tree.h (thanks Denis), and there are a few additional > warnings: > > auth-rsa.c: In function `auth_rsa_key_allowed': > auth-rsa.c:168: warning: return makes integer from pointer without a cast > auth-rsa.c:176: warning: return makes integer from pointer without a cast > auth-rsa.c:184: warning: return makes integer from pointer without a cast > > auth_rsa_key_allowed() is returning NULL instead of 0. > > monitor_mm.c: In function `mm_make_entry': > monitor_mm.c:60: warning: int format, different type arg (arg 5) > monitor_mm.c: In function `mm_create': > monitor_mm.c:88: warning: int format, different type arg (arg 2) > monitor_mm.c: In function `mm_destroy': > monitor_mm.c:127: warning: int format, different type arg (arg 3) > monitor_mm.c: In function `mm_xmalloc': > monitor_mm.c:141: warning: int format, different type arg (arg 3) > monitor_mm.c: In function `mm_free': > monitor_mm.c:227: warning: int format, different type arg (arg 3) > monitor_mm.c:250: warning: int format, different type arg (arg 4) > > These are mostly sizeof(int) == 4, sizeof(long) == 8 bugs. > > Other than that it works fine now (+ SRP). > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From stevesk at pobox.com Tue Mar 26 02:33:16 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 25 Mar 2002 07:33:16 -0800 (PST) Subject: compile failure In-Reply-To: Message-ID: On Mon, 25 Mar 2002, Tom Holroyd wrote: :The latest snapshot (20020324) fails to compile here. : :Linux 2.4.18-rc1 Alpha : :The first messages are: : :monitor_wrap.c: In function `mm_request_receive': :monitor_wrap.c:91: warning: int format, different type arg (arg 3) :monitor_wrap.c:100: warning: int format, different type arg (arg 3) : :which have to do with fatal() calls and int not being the same as :ssize_t... But the next one is the problem: thanks, we noticed that over the weekend. :monitor_mm.h:28:22: sys/tree.h: No such file or directory : :then all heck breaks loose. What's sys/tree.h supposed to be? a local copy of tree.h should show up in openbsd-compat/ soon. From mcardenas at ya.com Tue Mar 26 03:58:22 2002 From: mcardenas at ya.com (Manuel =?iso-8859-1?Q?Carde=F1as?=) Date: Mon, 25 Mar 2002 17:58:22 +0100 Subject: scp problem... Message-ID: <5.1.0.14.0.20020325174309.03153778@pop.mailcorp.ya.com> Hello again... I'm having a problem with scp. My openssh is 3.1p1 version. host01 is ok and host02 is bad. from host01: scp user at host02:/tmp/file FAILED from host02: scp user at host01:/tmp/file OK Both machines has the same version and the same compilations parameters, botch machines has the same Red Hat 7.2 distribution and updates.(--prefix=/blah/blah ONLY) The error is that the file size doesn?t correct. Sending file modes: C0644 17592186044416 file ^^^^^^^^^^^^^^^^^^^ ciao. -- manu: mcardenas at ya.com -- From johnh at aproposretail.com Tue Mar 26 04:08:17 2002 From: johnh at aproposretail.com (John Hardin) Date: 25 Mar 2002 09:08:17 -0800 Subject: Viruses Message-ID: <1017076098.13869.2.camel@johnh.apropos.com> Can somebody install an attachment filter on the listserv? Please? -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 ----------------------------------------------------------------------- "Rather than form a federation with Microsoft and work with what we had already created, there was this notion that the world should be offered an alternative." - Craig Mundie, Microsoft CTO, puzzled by non-MS-owned .NET user data services ----------------------------------------------------------------------- 51 days until Star Wars episode II: Attack of the Clones From jmknoble at pobox.com Tue Mar 26 04:41:27 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 25 Mar 2002 12:41:27 -0500 Subject: Viruses In-Reply-To: <1017076098.13869.2.camel@johnh.apropos.com>; from johnh@aproposretail.com on Mon, Mar 25, 2002 at 09:08:17AM -0800 References: <1017076098.13869.2.camel@johnh.apropos.com> Message-ID: <20020325124127.C5370@zax.half.pint-stowp.cx> Circa 2002-Mar-25 09:08:17 -0800 dixit John Hardin: : Can somebody install an attachment filter on the listserv? Why? I'd think that filtering out the yutzes who send viruses to the list would work better. Survival of the fittest, where "fit" implies "not using virus propagation platforms like MS Outlook". : Please? Filtering out attachments also filters out: - Attached patches - Attached config.log files - Attached detached OpenPGP signatures All of which are rather useful here. You'd be better off finding a mail user agent that doesn't execute the content it receives (and joining the ranks of the "fit"). -- 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/20020325/d38c275f/attachment.bin From johnh at aproposretail.com Tue Mar 26 04:56:27 2002 From: johnh at aproposretail.com (John Hardin) Date: 25 Mar 2002 09:56:27 -0800 Subject: Viruses In-Reply-To: <20020325124127.C5370@zax.half.pint-stowp.cx> References: <1017076098.13869.2.camel@johnh.apropos.com> <20020325124127.C5370@zax.half.pint-stowp.cx> Message-ID: <1017078993.14815.30.camel@johnh.apropos.com> On Mon, 2002-03-25 at 09:41, Jim Knoble wrote: > Circa 2002-Mar-25 09:08:17 -0800 dixit John Hardin: > > : Can somebody install an attachment filter on the listserv? > > Why? I'd think that filtering out the yutzes who send viruses to the > list would work better. Survival of the fittest, where "fit" implies > "not using virus propagation platforms like MS Outlook". (evil grin) Put a filter on the listserv that rejects messages with Mailer: headers that contain the strings "Microsoft" or "Outlook"... > Filtering out attachments also filters out: > > - Attached patches > - Attached config.log files > - Attached detached OpenPGP signatures > > All of which are rather useful here. ...not if your attachment filter is configurable. We don't need .EXE, .PIF, .SCR etc. ad nauseum. I didn't have total attachment blocking in mind. > You'd be better off finding a mail user agent that doesn't execute the > content it receives (and joining the ranks of the "fit"). Who says I use a vulnerable MUA? And my server catches these attachments quite handily. I'm just annoyed by the flood of notices sent to the list by others' mail servers. I also lament the bandwidth wasted by the listserv forwarding X hundreds of copies of a worm or virus. It'd be nice to see the filtering moved one step closer to the source and avoid those problems. Just for consideration, I'll insert a plug for the package I wrote: http://www.impsec.org/email-tool/procmail-security.html -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 ----------------------------------------------------------------------- "Rather than form a federation with Microsoft and work with what we had already created, there was this notion that the world should be offered an alternative." - Craig Mundie, Microsoft CTO, puzzled by non-MS-owned .NET user data services ----------------------------------------------------------------------- 51 days until Star Wars episode II: Attack of the Clones From stevesk at pobox.com Tue Mar 26 07:14:54 2002 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 25 Mar 2002 12:14:54 -0800 (PST) Subject: compile failure In-Reply-To: Message-ID: On Mon, 25 Mar 2002, Tom Holroyd wrote: :> monitor_mm.h:28:22: sys/tree.h: No such file or directory : :OK, I got tree.h (thanks Denis), and there are a few additional :warnings: : :auth-rsa.c: In function `auth_rsa_key_allowed': :auth-rsa.c:168: warning: return makes integer from pointer without a cast :auth-rsa.c:176: warning: return makes integer from pointer without a cast :auth-rsa.c:184: warning: return makes integer from pointer without a cast : :auth_rsa_key_allowed() is returning NULL instead of 0. : :monitor_mm.c: In function `mm_make_entry': :monitor_mm.c:60: warning: int format, different type arg (arg 5) :monitor_mm.c: In function `mm_create': :monitor_mm.c:88: warning: int format, different type arg (arg 2) :monitor_mm.c: In function `mm_destroy': :monitor_mm.c:127: warning: int format, different type arg (arg 3) :monitor_mm.c: In function `mm_xmalloc': :monitor_mm.c:141: warning: int format, different type arg (arg 3) :monitor_mm.c: In function `mm_free': :monitor_mm.c:227: warning: int format, different type arg (arg 3) :monitor_mm.c:250: warning: int format, different type arg (arg 4) : :These are mostly sizeof(int) == 4, sizeof(long) == 8 bugs. : :Other than that it works fine now (+ SRP). did you try with sshd -oUsePrivilegeSeparation=yes? the following patch was commited: Index: monitor_mm.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_mm.c,v retrieving revision 1.3 diff -u -1 -0 -r1.3 monitor_mm.c --- monitor_mm.c 19 Mar 2002 10:41:32 -0000 1.3 +++ monitor_mm.c 25 Mar 2002 20:00:24 -0000 @@ -49,22 +49,22 @@ if (mm->mmalloc == NULL) tmp = xmalloc(sizeof(struct mm_share)); else tmp = mm_xmalloc(mm->mmalloc, sizeof(struct mm_share)); tmp->address = address; tmp->size = size; tmp2 = RB_INSERT(mmtree, head, tmp); if (tmp2 != NULL) - fatal("mm_make_entry(%p): double address %p->%p(%d)", - mm, tmp2, address, size); + fatal("mm_make_entry(%p): double address %p->%p(%lu)", + mm, tmp2, address, (u_long)size); return (tmp); } /* Creates a shared memory area of a certain size */ struct mm_master * mm_create(struct mm_master *mmalloc, size_t size) { void *address; @@ -78,21 +78,21 @@ /* * If the memory map has a mm_master it can be completely * shared including authentication between the child * and the client. */ mm->mmalloc = mmalloc; address = mmap(NULL, size, PROT_WRITE|PROT_READ, MAP_ANON|MAP_SHARED, -1, 0); if (address == MAP_FAILED) - fatal("mmap(%d)", size); + fatal("mmap(%lu)", (u_long)size); mm->address = address; mm->size = size; RB_INIT(&mm->rb_free); RB_INIT(&mm->rb_allocated); mm_make_entry(mm, &mm->rb_free, address, size); return (mm); @@ -117,35 +117,35 @@ /* Destroys a memory mapped area */ void mm_destroy(struct mm_master *mm) { mm_freelist(mm->mmalloc, &mm->rb_free); mm_freelist(mm->mmalloc, &mm->rb_allocated); if (munmap(mm->address, mm->size) == -1) - fatal("munmap(%p, %d)", mm->address, mm->size); + fatal("munmap(%p, %lu)", mm->address, (u_long)mm->size); if (mm->mmalloc == NULL) xfree(mm); else mm_free(mm->mmalloc, mm); } void * mm_xmalloc(struct mm_master *mm, size_t size) { void *address; address = mm_malloc(mm, size); if (address == NULL) - fatal("%s: mm_malloc(%d)", __FUNCTION__, size); + fatal("%s: mm_malloc(%lu)", __FUNCTION__, (u_long)size); return (address); } /* Allocates data from a memory mapped area */ void * mm_malloc(struct mm_master *mm, size_t size) { struct mm_share *mms, *tmp; @@ -216,22 +216,22 @@ else { while (RB_PARENT(prev, next) && (prev == RB_LEFT(RB_PARENT(prev, next), next))) prev = RB_PARENT(prev, next); prev = RB_PARENT(prev, next); } } /* Check if range does not overlap */ if (prev != NULL && MM_ADDRESS_END(prev) > address) - fatal("mm_free: memory corruption: %p(%d) > %p", - prev->address, prev->size, address); + fatal("mm_free: memory corruption: %p(%lu) > %p", + prev->address, (u_long)prev->size, address); /* See if we can merge backwards */ if (prev != NULL && MM_ADDRESS_END(prev) == address) { prev->size += mms->size; RB_REMOVE(mmtree, &mm->rb_free, mms); if (mm->mmalloc == NULL) xfree(mms); else mm_free(mm->mmalloc, mms); } else @@ -239,22 +239,22 @@ if (prev == NULL) return; /* Check if we can merge forwards */ mms = RB_NEXT(mmtree, &mm->rb_free, prev); if (mms == NULL) return; if (MM_ADDRESS_END(prev) > mms->address) - fatal("mm_free: memory corruption: %p < %p(%d)", - mms->address, prev->address, prev->size); + fatal("mm_free: memory corruption: %p < %p(%lu)", + mms->address, prev->address, (u_long)prev->size); if (MM_ADDRESS_END(prev) != mms->address) return; prev->size += mms->size; RB_REMOVE(mmtree, &mm->rb_free, mms); if (mm->mmalloc == NULL) xfree(mms); else mm_free(mm->mmalloc, mms); Index: monitor_wrap.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/monitor_wrap.c,v retrieving revision 1.4 diff -u -1 -0 -r1.4 monitor_wrap.c --- monitor_wrap.c 19 Mar 2002 14:27:39 -0000 1.4 +++ monitor_wrap.c 25 Mar 2002 20:00:27 -0000 @@ -81,30 +81,30 @@ u_char buf[4]; ssize_t res; u_int msg_len; debug3("%s entering", __FUNCTION__); res = atomicio(read, socket, buf, sizeof(buf)); if (res != sizeof(buf)) { if (res == 0) fatal_cleanup(); - fatal("%s: read: %d", __FUNCTION__, res); + fatal("%s: read: %ld", __FUNCTION__, (long)res); } msg_len = GET_32BIT(buf); if (msg_len > 256 * 1024) fatal("%s: read: bad msg_len %d", __FUNCTION__, msg_len); buffer_clear(m); buffer_append_space(m, msg_len); res = atomicio(read, socket, buffer_ptr(m), msg_len); if (res != msg_len) - fatal("%s: read: %d != msg_len", __FUNCTION__, res); + fatal("%s: read: %ld != msg_len", __FUNCTION__, (long)res); } void mm_request_receive_expect(int socket, enum monitor_reqtype type, Buffer *m) { u_char rtype; debug3("%s entering: type %d", __FUNCTION__, type); mm_request_receive(socket, m); From MPak at dotsconnect.com Tue Mar 26 08:04:28 2002 From: MPak at dotsconnect.com (MPak at dotsconnect.com) Date: Mon, 25 Mar 2002 16:04:28 -0500 Subject: buildpkg on solaris 8 OK BUT?.. Message-ID: Hello all, I was finally able to create the OpenSSH package for Solaris 8 10/01. The problem I have now is that I will still need to have entropy ready prior to openssh-3.1p1 package installation. Otherwise there is no entropy pool available (with the new servers) and key generation fails. With the previous versions of openssh, I used SUN's "makeOpenSSHPackage.ksh" script and was able to generate the keys by running /etc/init.d/openssh.server script, which is essentially functioning like /etc/init.d/opensshd. When I run the /etc/init.d/opensshd, I get the following errors: Installation of was successful. # cd /etc/init.d/ # ./opensshd start Couldn't connect to PRNGD socket "/var/run/egd-pool": No such file or directory Entropy collection failed ssh-rand-helper child produced insufficient data Couldn't connect to PRNGD socket "/var/run/egd-pool": No such file or directory Entropy collection failed ssh-rand-helper child produced insufficient data Couldn't connect to PRNGD socket "/var/run/egd-pool": No such file or directory Entropy collection failed ssh-rand-helper child produced insufficient data starting /opt/OBSDssh/sbin/sshd... Couldn't connect to PRNGD socket "/var/run/egd-pool": No such fi e or directory Entropy collection failed ssh-rand-helper child produced insufficient data ./opensshd: Error 255 starting /opt/OBSDssh/sbin/sshd... bailing. Below are the details: I configured the prngd as follows (essentially followed the instructions from sunblueprints): >> # make CC=gcc CFLAGS="-O3 -DSOLARIS" SYSLIBS="-lsocket -lnsl" >> # cp prngd /usr/local/sbin/prngd >> # cp contrib/Solaris-7/prngd.conf/solaris-7 /etc/prngd.conf >> # cat /var/log/syslog /var/adm/messages > /etc/prngd-seed Then to start entropy >> # /usr/local/sbin/prngd /var/run/egd-pool Below are the options I used configuring openssh-3.1p1 >> # ./configure --prefix=/opt/OBSDssh --with-pam --without-rsh --disable-suid-ssh --sysconfdir=/etc --with-prngd-socket=/var/run/egd-pool Then make >> # make Then I ran the buildpkg.sh successfully. And /etc/init.d/opensshd worked fine too on the system that I built the package. But when I tried the newly generated package on a new system that did not already have entropy collected , opensshd fails. Any ideas on how to overcome this? Thanks.. MesutPAK Network Analyst From Jason.Lacoss-Arnold at AGEDWARDS.com Tue Mar 26 08:06:38 2002 From: Jason.Lacoss-Arnold at AGEDWARDS.com (Lacoss-Arnold, Jason) Date: Mon, 25 Mar 2002 15:06:38 -0600 Subject: OpenSSH on SunOS 4 Message-ID: <6808DCE827EBD5119DFB0002A58EF4DA57E6F2@hqempn06.agedwards.com> I'm trying to update an ssh 1.2.27 to OpenSSH 3.0.2p1 and am running into a problem. I've successfully built zlib 1.1.4, OpenSSL 0.9.6c, and tcp_wrappers , but when I attempt to run configure, I get the error about the missing posix regex. So I attempted to download and use pcre (the Perl hack to expose perl regex to posix. But I can't build that since it calls strtoul() (string to unsigned long?) which doesn't exist on SunOS. Does anyone have a patch/workaround to avoid this? And no, I can't build glibc to snag its strtoul() since it doesn't have a SunOS port either. Thanks in advance, Jason Lacoss-Arnold TS/Unix Architecture 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. *************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020325/dcb9540a/attachment.html From bugzilla-daemon at mindrot.org Tue Mar 26 08:46:38 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 26 Mar 2002 08:46:38 +1100 (EST) Subject: [Bug 184] New: 3.1p1 openssh fails to build a working sshd on Trusted HP-UX 10.26 Message-ID: <20020325214638.9E925E9AB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=184 Summary: 3.1p1 openssh fails to build a working sshd on Trusted HP-UX 10.26 Product: Portable OpenSSH Version: -current Platform: HPPA OS/Version: HP-UX Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dcole at keysoftsys.com sshd fails work when trying to build on Trusted HP-UX 10.26 ----patch----- diff -cr openssh-3.1p1.orig/acconfig.h openssh-3.1p1/acconfig.h *** openssh-3.1p1.orig/acconfig.h Tue Feb 26 16:40:49 2002 --- openssh-3.1p1/acconfig.h Thu Mar 21 23:19:56 2002 *************** *** 222,227 **** --- 222,229 ---- /* Defined if in_systm.h needs to be included with netinet/ip.h (HPUX - ) */ #undef NEED_IN_SYSTM_H + /* Defined if on a Trusted HPUX system */ + #undef TRUSTED_HPUX /* Define if you have an old version of PAM which takes only one argument */ /* to pam_strerror */ diff -cr openssh-3.1p1.orig/auth2.c openssh-3.1p1/auth2.c *** openssh-3.1p1.orig/auth2.c Tue Feb 26 18:09:43 2002 --- openssh-3.1p1/auth2.c Fri Mar 22 22:39:22 2002 *************** *** 23,28 **** --- 23,32 ---- */ #include "includes.h" + #ifdef TRUSTED_HPUX + #include + #include + #endif RCSID("$OpenBSD: auth2.c,v 1.85 2002/02/24 19:14:59 markus Exp $"); #include *************** *** 183,190 **** --- 187,209 ---- if (authctxt->attempt++ == 0) { /* setup auth context */ + #ifdef TRUSTED_HPUX + struct pr_passwd *pr_pw = NULL; + #endif struct passwd *pw = NULL; pw = getpwnam(user); + + #ifdef TRUSTED_HPUX + //Trusted HP-UX passwords are stored differently + //you need to call getprpwnam to get the password for + //a user. + pr_pw = getprpwnam(pw->pw_name); + //This dies with a bus error, but isn't + //this a pointer that should be freed + //before we reassign? + //free(pw->pw_passwd); + pw->pw_passwd=pr_pw->ufld.fd_encrypt; + #endif if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { authctxt->pw = pwcopy(pw); authctxt->valid = 1; Common subdirectories: openssh-3.1p1.orig/autom4te.cache and openssh-3.1p1/autom4te.cache diff -cr openssh-3.1p1.orig/configure.ac openssh-3.1p1/configure.ac *** openssh-3.1p1.orig/configure.ac Wed Feb 27 06:12:35 2002 --- openssh-3.1p1/configure.ac Fri Mar 22 00:08:59 2002 *************** *** 80,85 **** --- 80,100 ---- *-*-darwin*) AC_DEFINE(BROKEN_GETADDRINFO) ;; + *-*-hpux10.26) + if test -z "$GCC"; then + CFLAGS="$CFLAGS -Ae" + fi + CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1" + IPADDR_IN_DISPLAY=yes + AC_DEFINE(USE_PIPES) + AC_DEFINE(TRUSTED_HPUX) + AC_DEFINE(LOGIN_NEEDS_UTMPX) + AC_DEFINE(DISABLE_SHADOW) + AC_DEFINE(DISABLE_UTMP) + AC_DEFINE(SPT_TYPE,SPT_PSTAT) + LIBS="$LIBS -lxnet -lsec -lsecpw" + disable_ptmx_check=yes + ;; *-*-hpux10*) if test -z "$GCC"; then CFLAGS="$CFLAGS -Ae" *************** *** 1769,1780 **** fi if test -z "$no_dev_ptmx" ; then ! AC_CHECK_FILE("/dev/ptmx", ! [ ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) ! have_dev_ptmx=1 ! ] ! ) fi AC_CHECK_FILE("/dev/ptc", [ --- 1784,1797 ---- fi if test -z "$no_dev_ptmx" ; then ! if test "x$disable_ptmx_check" != "xyes" ; then ! AC_CHECK_FILE("/dev/ptmx", ! [ ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) ! have_dev_ptmx=1 ! ] ! ) ! fi fi AC_CHECK_FILE("/dev/ptc", [ Common subdirectories: openssh-3.1p1.orig/contrib and openssh-3.1p1/contrib Common subdirectories: openssh-3.1p1.orig/openbsd-compat and openssh-3.1p1/openbsd-compat Common subdirectories: openssh-3.1p1.orig/scard and openssh-3.1p1/scard diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c *** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 --- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 *************** *** 1285,1291 **** --- 1285,1297 ---- #ifdef LOGIN_NEEDS_TERM (s->term ? s->term : "unknown"), #endif /* LOGIN_NEEDS_TERM */ + #ifdef TRUSTED_HPUX + // the "--" makes login hang on Trusted HP-UX + // 10.26 + "-p", "-f", pw->pw_name, (char *)NULL); + #else "-p", "-f", "--", pw->pw_name, (char *)NULL); + #endif /* Login couldn't be executed, die. */ *************** *** 1736,1741 **** --- 1742,1757 ---- */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + #ifdef TRUSTED_HPUX + //Took two lines from a patch at: + // + //by John C. Bowman + //There is some speculation that you could possibly + //see data loss from this on usenet. But without + //this sshd does not exit on logout. + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) + chan_read_failed(c); + #endif s->chanid = -1; } diff -cr openssh-3.1p1.orig/sshd.c openssh-3.1p1/sshd.c *** openssh-3.1p1.orig/sshd.c Tue Mar 5 01:31:30 2002 --- openssh-3.1p1/sshd.c Fri Mar 22 22:32:56 2002 *************** *** 45,50 **** --- 45,54 ---- #include #include #include + //Trusted HP-UX + #include + #include + //end Trusted HP-UX #include "ssh.h" #include "ssh1.h" *************** *** 596,601 **** --- 600,610 ---- int startups = 0; Key *key; int ret, key_used = 0; + #ifdef TRUSTED_HPUX + //This call is needed for getprpwnam in auth2.c + //to initialize the security system for Trusted HP-UX + set_auth_parameters(ac, av); + #endif __progname = get_progname(av[0]); init_rng(); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dcole at keysoftsys.com Tue Mar 26 09:03:16 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Mon, 25 Mar 2002 14:03:16 -0800 Subject: Trusted HP-UX 10.26 References: Message-ID: <00f001c1d448$f0ab8170$9b78a8c0@oedserver> Here the patch to make 3.1p1 openssh configure and build for Trusted HP-UX 10.26. What this patch does. First it adds support to correctly configure on Trusted HP-UX 10.26 In turn this enables sshd to run successfully (otherwise it wont work at all). Once logged in the user will have the right clearance and privilege sets. Note: This patch does not due privilege bracketting, nor does it make sshd multilevel aware (if you don't know what this means, don't worry about it) Some asked for seperate patches when they are large, but to keep them together if they are all for one fix. At only a 184 lines, I figured keeping the patch together was better than 4 or 5 different patches. ___patch follows___ diff -cr openssh-3.1p1.orig/acconfig.h openssh-3.1p1/acconfig.h *** openssh-3.1p1.orig/acconfig.h Tue Feb 26 16:40:49 2002 --- openssh-3.1p1/acconfig.h Thu Mar 21 23:19:56 2002 *************** *** 222,227 **** --- 222,229 ---- /* Defined if in_systm.h needs to be included with netinet/ip.h (HPUX - ) */ #undef NEED_IN_SYSTM_H + /* Defined if on a Trusted HPUX system */ + #undef TRUSTED_HPUX /* Define if you have an old version of PAM which takes only one argument */ /* to pam_strerror */ diff -cr openssh-3.1p1.orig/auth2.c openssh-3.1p1/auth2.c *** openssh-3.1p1.orig/auth2.c Tue Feb 26 18:09:43 2002 --- openssh-3.1p1/auth2.c Fri Mar 22 22:39:22 2002 *************** *** 23,28 **** --- 23,32 ---- */ #include "includes.h" + #ifdef TRUSTED_HPUX + #include + #include + #endif RCSID("$OpenBSD: auth2.c,v 1.85 2002/02/24 19:14:59 markus Exp $"); #include *************** *** 183,190 **** --- 187,209 ---- if (authctxt->attempt++ == 0) { /* setup auth context */ + #ifdef TRUSTED_HPUX + struct pr_passwd *pr_pw = NULL; + #endif struct passwd *pw = NULL; pw = getpwnam(user); + + #ifdef TRUSTED_HPUX + file://Trusted HP-UX passwords are stored differently + file://you need to call getprpwnam to get the password for + file://a user. + pr_pw = getprpwnam(pw->pw_name); + file://This dies with a bus error, but isn't + file://this a pointer that should be freed + file://before we reassign? + file://free(pw->pw_passwd); + pw->pw_passwd=pr_pw->ufld.fd_encrypt; + #endif if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { authctxt->pw = pwcopy(pw); authctxt->valid = 1; Common subdirectories: openssh-3.1p1.orig/autom4te.cache and openssh-3.1p1/autom4te.cache diff -cr openssh-3.1p1.orig/configure.ac openssh-3.1p1/configure.ac *** openssh-3.1p1.orig/configure.ac Wed Feb 27 06:12:35 2002 --- openssh-3.1p1/configure.ac Fri Mar 22 00:08:59 2002 *************** *** 80,85 **** --- 80,100 ---- *-*-darwin*) AC_DEFINE(BROKEN_GETADDRINFO) ;; + *-*-hpux10.26) + if test -z "$GCC"; then + CFLAGS="$CFLAGS -Ae" + fi + CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED= 1" + IPADDR_IN_DISPLAY=yes + AC_DEFINE(USE_PIPES) + AC_DEFINE(TRUSTED_HPUX) + AC_DEFINE(LOGIN_NEEDS_UTMPX) + AC_DEFINE(DISABLE_SHADOW) + AC_DEFINE(DISABLE_UTMP) + AC_DEFINE(SPT_TYPE,SPT_PSTAT) + LIBS="$LIBS -lxnet -lsec -lsecpw" + disable_ptmx_check=yes + ;; *-*-hpux10*) if test -z "$GCC"; then CFLAGS="$CFLAGS -Ae" *************** *** 1769,1780 **** fi if test -z "$no_dev_ptmx" ; then ! AC_CHECK_FILE("/dev/ptmx", ! [ ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) ! have_dev_ptmx=1 ! ] ! ) fi AC_CHECK_FILE("/dev/ptc", [ --- 1784,1797 ---- fi if test -z "$no_dev_ptmx" ; then ! if test "x$disable_ptmx_check" != "xyes" ; then ! AC_CHECK_FILE("/dev/ptmx", ! [ ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) ! have_dev_ptmx=1 ! ] ! ) ! fi fi AC_CHECK_FILE("/dev/ptc", [ Common subdirectories: openssh-3.1p1.orig/contrib and openssh-3.1p1/contrib Common subdirectories: openssh-3.1p1.orig/openbsd-compat and openssh-3.1p1/openbsd-compat Common subdirectories: openssh-3.1p1.orig/scard and openssh-3.1p1/scard diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c *** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 --- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 *************** *** 1285,1291 **** --- 1285,1297 ---- #ifdef LOGIN_NEEDS_TERM (s->term ? s->term : "unknown"), #endif /* LOGIN_NEEDS_TERM */ + #ifdef TRUSTED_HPUX + // the "--" makes login hang on Trusted HP-UX + // 10.26 + "-p", "-f", pw->pw_name, (char *)NULL); + #else "-p", "-f", "--", pw->pw_name, (char *)NULL); + #endif /* Login couldn't be executed, die. */ *************** *** 1736,1741 **** --- 1742,1757 ---- */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + #ifdef TRUSTED_HPUX + file://Took two lines from a patch at: + // + file://by John C. Bowman + file://There is some speculation that you could possibly + file://see data loss from this on usenet. But without + file://this sshd does not exit on logout. + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) + chan_read_failed(c); + #endif s->chanid = -1; } diff -cr openssh-3.1p1.orig/sshd.c openssh-3.1p1/sshd.c *** openssh-3.1p1.orig/sshd.c Tue Mar 5 01:31:30 2002 --- openssh-3.1p1/sshd.c Fri Mar 22 22:32:56 2002 *************** *** 45,50 **** --- 45,54 ---- #include #include #include + file://Trusted HP-UX + #include + #include + file://end Trusted HP-UX #include "ssh.h" #include "ssh1.h" *************** *** 596,601 **** --- 600,610 ---- int startups = 0; Key *key; int ret, key_used = 0; + #ifdef TRUSTED_HPUX + file://This call is needed for getprpwnam in auth2.c + file://to initialize the security system for Trusted HP-UX + set_auth_parameters(ac, av); + #endif __progname = get_progname(av[0]); init_rng(); From austin at coremetrics.com Tue Mar 26 09:58:31 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 25 Mar 2002 16:58:31 -0600 Subject: Using kerberized SSHD. Question. Message-ID: <1017097111.6001.43.camel@UberGeek> I have a kerberized SSHD installed on HOST-1, a login server for the outside world. How can I make it so users are still authenticated via kerberos, even though they haven't yet received a ticket? The main reason for this is that a user who is at home, no vpn, but has an ssh client could then login and be authenticated by kerberos using password authentication, get a ticket, then be allowed to ssh(at this point using a kerberized ssh client) to any kerberized sshd host, without entering a password. Is this possible? TIA -- 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 From ANTIGEN_ABRA at wrq.com Tue Mar 26 10:21:25 2002 From: ANTIGEN_ABRA at wrq.com (ANTIGEN_ABRA) Date: Mon, 25 Mar 2002 15:21:25 -0800 Subject: Antigen Notification:Antigen found FILE FILTER= *.pif file Message-ID: <616772E97E38D31188FA00508B318ACA03FA419D@abra.wrq.com> Antigen for Exchange found Hrnqa.pif matching FILE FILTER= *.pif file filter. The file is currently Purged. The message, "A very powful tool", was sent from Traxx and was discovered in IMC Queues\Inbound located at WRQ/Seattle/ABRA. From mjt at tls.msk.ru Tue Mar 26 11:07:48 2002 From: mjt at tls.msk.ru (Michael Tokarev) Date: Tue, 26 Mar 2002 03:07:48 +0300 Subject: Viruses References: <1017076098.13869.2.camel@johnh.apropos.com> <20020325124127.C5370@zax.half.pint-stowp.cx> <1017078993.14815.30.camel@johnh.apropos.com> Message-ID: <3C9FBBD4.913E0413@tls.msk.ru> John Hardin wrote: > > On Mon, 2002-03-25 at 09:41, Jim Knoble wrote: > > Circa 2002-Mar-25 09:08:17 -0800 dixit John Hardin: > > > > : Can somebody install an attachment filter on the listserv? > > > > Why? I'd think that filtering out the yutzes who send viruses to the > > list would work better. Survival of the fittest, where "fit" implies > > "not using virus propagation platforms like MS Outlook". > > (evil grin) Put a filter on the listserv that rejects messages with > Mailer: headers that contain the strings "Microsoft" or "Outlook"... Maybe also X-Mailer: microsoft* and windows* ? Note that all virus notifications that received here was sent incorrectly, and by some sort of windows-based crapo^Wsoftware. I too have a virusscanner for our local office, but this software does not mailbombs list-owners and list-recipients. Well, yes, if problem persists, some sort of attachment filter (*.exe etc) will be helpful. Regards, Michael. From djm at mindrot.org Tue Mar 26 11:24:24 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 Mar 2002 11:24:24 +1100 (EST) Subject: Viruses In-Reply-To: <1017078993.14815.30.camel@johnh.apropos.com> Message-ID: On 25 Mar 2002, John Hardin wrote: > Just for consideration, I'll insert a plug for the package I wrote: > > http://www.impsec.org/email-tool/procmail-security.html That URL doesn't seem to work. Have you looked at procmail's source? The horror... -d From djm at mindrot.org Tue Mar 26 11:25:16 2002 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 Mar 2002 11:25:16 +1100 (EST) Subject: Viruses In-Reply-To: <3C9FBBD4.913E0413@tls.msk.ru> Message-ID: On Tue, 26 Mar 2002, Michael Tokarev wrote: > Well, yes, if problem persists, some sort of attachment filter (*.exe > etc) will be helpful. If people could point me to one that works with mailman, it would be appreciated. I just don't have time to look at the moment. -d From mouring at etoh.eviladmin.org Tue Mar 26 11:27:24 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 25 Mar 2002 18:27:24 -0600 (CST) Subject: OpenSSH on SunOS 4 In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E6F2@hqempn06.agedwards.com> Message-ID: 3.1p1 no longer needs pcre or any regexp code. - Ben On Mon, 25 Mar 2002, Lacoss-Arnold, Jason wrote: > I'm trying to update an ssh 1.2.27 to OpenSSH 3.0.2p1 and am running into a > problem. > I've successfully built zlib 1.1.4, OpenSSL 0.9.6c, and tcp_wrappers , but > when I attempt to run configure, I get the error about the missing posix > regex. So I attempted to download and use pcre (the Perl hack to expose > perl regex to posix. But I can't build that since it calls strtoul() > (string to unsigned long?) which doesn't exist on SunOS. Does anyone have a > patch/workaround to avoid this? And no, I can't build glibc to snag its > strtoul() since it doesn't have a SunOS port either. > > Thanks in advance, > Jason Lacoss-Arnold > TS/Unix Architecture > 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 mouring at etoh.eviladmin.org Tue Mar 26 11:29:43 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 25 Mar 2002 18:29:43 -0600 (CST) Subject: Trusted HP-UX 10.26 In-Reply-To: <00f001c1d448$f0ab8170$9b78a8c0@oedserver> Message-ID: Please avoid C++ comments.. They are not accepted on very C compiler. - Ben On Mon, 25 Mar 2002, Darren Cole wrote: > Here the patch to make 3.1p1 openssh configure and build for Trusted HP-UX > 10.26. > What this patch does. > First it adds support to correctly configure on Trusted HP-UX 10.26 > In turn this enables sshd to run successfully (otherwise it wont work at > all). Once logged in the user will have the right clearance and privilege > sets. > > Note: This patch does not due privilege bracketting, nor does it make sshd > multilevel aware (if you don't know what this means, don't worry about it) > > Some asked for seperate patches when they are large, but to keep them > together if they are all for one fix. At only a 184 lines, I figured > keeping the patch together was better than 4 or 5 different patches. > > ___patch follows___ > diff -cr openssh-3.1p1.orig/acconfig.h openssh-3.1p1/acconfig.h > *** openssh-3.1p1.orig/acconfig.h Tue Feb 26 16:40:49 2002 > --- openssh-3.1p1/acconfig.h Thu Mar 21 23:19:56 2002 > *************** > *** 222,227 **** > --- 222,229 ---- > > /* Defined if in_systm.h needs to be included with netinet/ip.h (HPUX - > ) */ > #undef NEED_IN_SYSTM_H > + /* Defined if on a Trusted HPUX system */ > + #undef TRUSTED_HPUX > > /* Define if you have an old version of PAM which takes only one argument > */ > /* to pam_strerror */ > diff -cr openssh-3.1p1.orig/auth2.c openssh-3.1p1/auth2.c > *** openssh-3.1p1.orig/auth2.c Tue Feb 26 18:09:43 2002 > --- openssh-3.1p1/auth2.c Fri Mar 22 22:39:22 2002 > *************** > *** 23,28 **** > --- 23,32 ---- > */ > > #include "includes.h" > + #ifdef TRUSTED_HPUX > + #include > + #include > + #endif > RCSID("$OpenBSD: auth2.c,v 1.85 2002/02/24 19:14:59 markus Exp $"); > > #include > *************** > *** 183,190 **** > --- 187,209 ---- > > if (authctxt->attempt++ == 0) { > /* setup auth context */ > + #ifdef TRUSTED_HPUX > + struct pr_passwd *pr_pw = NULL; > + #endif > struct passwd *pw = NULL; > pw = getpwnam(user); > + > + #ifdef TRUSTED_HPUX > + file://Trusted HP-UX passwords are stored differently > + file://you need to call getprpwnam to get the password for > + file://a user. > + pr_pw = getprpwnam(pw->pw_name); > + file://This dies with a bus error, but isn't > + file://this a pointer that should be freed > + file://before we reassign? > + file://free(pw->pw_passwd); > + pw->pw_passwd=pr_pw->ufld.fd_encrypt; > + #endif > if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { > authctxt->pw = pwcopy(pw); > authctxt->valid = 1; > Common subdirectories: openssh-3.1p1.orig/autom4te.cache and > openssh-3.1p1/autom4te.cache > diff -cr openssh-3.1p1.orig/configure.ac openssh-3.1p1/configure.ac > *** openssh-3.1p1.orig/configure.ac Wed Feb 27 06:12:35 2002 > --- openssh-3.1p1/configure.ac Fri Mar 22 00:08:59 2002 > *************** > *** 80,85 **** > --- 80,100 ---- > *-*-darwin*) > AC_DEFINE(BROKEN_GETADDRINFO) > ;; > + *-*-hpux10.26) > + if test -z "$GCC"; then > + CFLAGS="$CFLAGS -Ae" > + fi > + > > CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED= > 1" > + IPADDR_IN_DISPLAY=yes > + AC_DEFINE(USE_PIPES) > + AC_DEFINE(TRUSTED_HPUX) > + AC_DEFINE(LOGIN_NEEDS_UTMPX) > + AC_DEFINE(DISABLE_SHADOW) > + AC_DEFINE(DISABLE_UTMP) > + AC_DEFINE(SPT_TYPE,SPT_PSTAT) > + LIBS="$LIBS -lxnet -lsec -lsecpw" > + disable_ptmx_check=yes > + ;; > *-*-hpux10*) > if test -z "$GCC"; then > CFLAGS="$CFLAGS -Ae" > *************** > *** 1769,1780 **** > fi > > if test -z "$no_dev_ptmx" ; then > ! AC_CHECK_FILE("/dev/ptmx", > ! [ > ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) > ! have_dev_ptmx=1 > ! ] > ! ) > fi > AC_CHECK_FILE("/dev/ptc", > [ > --- 1784,1797 ---- > fi > > if test -z "$no_dev_ptmx" ; then > ! if test "x$disable_ptmx_check" != "xyes" ; then > ! AC_CHECK_FILE("/dev/ptmx", > ! [ > ! AC_DEFINE_UNQUOTED(HAVE_DEV_PTMX) > ! have_dev_ptmx=1 > ! ] > ! ) > ! fi > fi > AC_CHECK_FILE("/dev/ptc", > [ > Common subdirectories: openssh-3.1p1.orig/contrib and openssh-3.1p1/contrib > Common subdirectories: openssh-3.1p1.orig/openbsd-compat and > openssh-3.1p1/openbsd-compat > Common subdirectories: openssh-3.1p1.orig/scard and openssh-3.1p1/scard > diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c > *** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 > --- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 > *************** > *** 1285,1291 **** > --- 1285,1297 ---- > #ifdef LOGIN_NEEDS_TERM > (s->term ? s->term : "unknown"), > #endif /* LOGIN_NEEDS_TERM */ > + #ifdef TRUSTED_HPUX > + // the "--" makes login hang on Trusted HP-UX > + // 10.26 > + "-p", "-f", pw->pw_name, (char *)NULL); > + #else > "-p", "-f", "--", pw->pw_name, (char *)NULL); > + #endif > > /* Login couldn't be executed, die. */ > > *************** > *** 1736,1741 **** > --- 1742,1757 ---- > */ > if (c->ostate != CHAN_OUTPUT_CLOSED) > chan_write_failed(c); > + #ifdef TRUSTED_HPUX > + file://Took two lines from a patch at: > + // > + file://by John C. Bowman > + file://There is some speculation that you could possibly > + file://see data loss from this on usenet. But without > + file://this sshd does not exit on logout. > + if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) > + chan_read_failed(c); > + #endif > s->chanid = -1; > } > > diff -cr openssh-3.1p1.orig/sshd.c openssh-3.1p1/sshd.c > *** openssh-3.1p1.orig/sshd.c Tue Mar 5 01:31:30 2002 > --- openssh-3.1p1/sshd.c Fri Mar 22 22:32:56 2002 > *************** > *** 45,50 **** > --- 45,54 ---- > #include > #include > #include > + file://Trusted HP-UX > + #include > + #include > + file://end Trusted HP-UX > > #include "ssh.h" > #include "ssh1.h" > *************** > *** 596,601 **** > --- 600,610 ---- > int startups = 0; > Key *key; > int ret, key_used = 0; > + #ifdef TRUSTED_HPUX > + file://This call is needed for getprpwnam in auth2.c > + file://to initialize the security system for Trusted HP-UX > + set_auth_parameters(ac, av); > + #endif > > __progname = get_progname(av[0]); > init_rng(); > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jim at ic.uva.nl Tue Mar 26 12:30:41 2002 From: jim at ic.uva.nl (Jim Mintha) Date: Tue, 26 Mar 2002 02:30:41 +0100 Subject: OpenSSH on SunOS 4 In-Reply-To: <6808DCE827EBD5119DFB0002A58EF4DA57E6F2@hqempn06.agedwards.com> References: <6808DCE827EBD5119DFB0002A58EF4DA57E6F2@hqempn06.agedwards.com> Message-ID: <20020326013041.GD26762@ic.uva.nl> On Mon, Mar 25, 2002 at 03:06:38PM -0600, Lacoss-Arnold, Jason wrote: > > I'm trying to update an ssh 1.2.27 to OpenSSH 3.0.2p1 and am running > into a problem. > I've successfully built zlib 1.1.4, OpenSSL 0.9.6c, and tcp_wrappers , > but when I attempt to run configure, I get the error about the missing > posix regex. So I attempted to download and use pcre (the Perl hack > to expose perl regex to posix. But I can't build that since it calls > strtoul() (string to unsigned long?) which doesn't exist on SunOS. > Does anyone have a patch/workaround to avoid this? And no, I can't > build glibc to snag its strtoul() since it doesn't have a SunOS port > either. It was a few months ago that I build it, but it seems that it only uses strtoul in the file pcretest.c (which is only for testing) so I just changed it to strtol and it build fine. (and works with openssh) Jim -- Jim Mintha Email: j.t.mintha at uva.nl System Administrator Work: +31 20 525-4919 Informatiseringscentrum Home: +31 20 662-3892 University of Amsterdam Debian GNU/Linux: jmintha at debian.org _There are always Possibilities_ http://jim.ultralinux.org From dcole at keysoftsys.com Tue Mar 26 12:29:08 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Mon, 25 Mar 2002 17:29:08 -0800 Subject: Trusted HP-UX 10.26 References: Message-ID: <01b501c1d465$b1e89640$9b78a8c0@oedserver> Good point Ben. (It even says this in the style guide, so my fault for not fixing it before submitting the patch.) Fixing right now. I'll repost my patch after I give people a chance to comment somemore. Probably tomorrow sometime. Darren Cole dcole at keysoftsys.com ----- Original Message ----- From: "Ben Lindstrom" To: "Darren Cole" Cc: Sent: Monday, March 25, 2002 4:29 PM Subject: Re: Trusted HP-UX 10.26 > > Please avoid C++ comments.. They are not accepted on very C compiler. > > - Ben From gem at rellim.com Tue Mar 26 13:10:43 2002 From: gem at rellim.com (Gary E. Miller) Date: Mon, 25 Mar 2002 18:10:43 -0800 (PST) Subject: Viruses In-Reply-To: Message-ID: Yo Damien! I use stripmime with mailman. Only failed me once. http://www.linux.org/apps/AppId_627.html Here is what I put in my /etc/mail/aliases test: "|/usr/local/sbin/stripmime-wrapper post test" here is the wrapper code: cat stripmime-wrapper #!/bin/sh /usr/local/sbin/stripmime | /usr/local/mailman/mail/mailman $@ > /tmp/wrap.log 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 Tue, 26 Mar 2002, Damien Miller wrote: > On Tue, 26 Mar 2002, Michael Tokarev wrote: > > > Well, yes, if problem persists, some sort of attachment filter (*.exe > > etc) will be helpful. > > If people could point me to one that works with mailman, it would be > appreciated. I just don't have time to look at the moment. From kevin at atomicgears.com Tue Mar 26 13:04:15 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Mon, 25 Mar 2002 18:04:15 -0800 (PST) Subject: Trusted HP-UX 10.26 In-Reply-To: <00f001c1d448$f0ab8170$9b78a8c0@oedserver> Message-ID: On Mon, 25 Mar 2002, Darren Cole wrote: :Note: This patch does not due privilege bracketting, nor does it make sshd :multilevel aware (if you don't know what this means, don't worry about it) ah, ok. you can also upgrade to 10.20--why are you using 10.26 then? :Some asked for seperate patches when they are large, but to keep them :together if they are all for one fix. At only a 184 lines, I figured :keeping the patch together was better than 4 or 5 different patches. : :___patch follows___ :*************** :*** 183,190 **** :--- 187,209 ---- : : if (authctxt->attempt++ == 0) { : /* setup auth context */ :+ #ifdef TRUSTED_HPUX :+ struct pr_passwd *pr_pw = NULL; :+ #endif : struct passwd *pw = NULL; : pw = getpwnam(user); :+ :+ #ifdef TRUSTED_HPUX :+ file://Trusted HP-UX passwords are stored differently :+ file://you need to call getprpwnam to get the password for :+ file://a user. :+ pr_pw = getprpwnam(pw->pw_name); :+ file://This dies with a bus error, but isn't :+ file://this a pointer that should be freed :+ file://before we reassign? :+ file://free(pw->pw_passwd); :+ pw->pw_passwd=pr_pw->ufld.fd_encrypt; :+ #endif : if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { : authctxt->pw = pwcopy(pw); : authctxt->valid = 1; i don't understand this. why do you need the hashed password here? openssh works today with hp-ux commercial security--why is CMW different? see auth-passwd.c. also, why did you change only auth2.c and not auth1.c? :diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c :*** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 :--- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 :*************** :*** 1285,1291 **** :--- 1285,1297 ---- : #ifdef LOGIN_NEEDS_TERM : (s->term ? s->term : "unknown"), : #endif /* LOGIN_NEEDS_TERM */ :+ #ifdef TRUSTED_HPUX :+ // the "--" makes login hang on Trusted HP-UX :+ // 10.26 :+ "-p", "-f", pw->pw_name, (char *)NULL); :+ #else : "-p", "-f", "--", pw->pw_name, (char *)NULL); :+ #endif : : /* Login couldn't be executed, die. */ do you require UseLogin yes? : if (c->ostate != CHAN_OUTPUT_CLOSED) : chan_write_failed(c); :+ #ifdef TRUSTED_HPUX :+ file://Took two lines from a patch at: :+ // :+ file://by John C. Bowman :+ file://There is some speculation that you could possibly :+ file://see data loss from this on usenet. But without :+ file://this sshd does not exit on logout. :+ if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) :+ chan_read_failed(c); :+ #endif : s->chanid = -1; this has been discussed and is wrong. i don't understand the file:// stuff. From jmknoble at pobox.com Tue Mar 26 14:20:01 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 25 Mar 2002 22:20:01 -0500 Subject: Trusted HP-UX 10.26 In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Mar 25, 2002 at 06:29:43PM -0600 References: <00f001c1d448$f0ab8170$9b78a8c0@oedserver> Message-ID: <20020325222001.A1723@zax.half.pint-stowp.cx> Circa 2002-Mar-25 18:29:43 -0600 dixit Ben Lindstrom: : : Please avoid C++ comments.. They are not accepted on very C compiler. Not only that, but C++-style comments like these: : > + #ifdef TRUSTED_HPUX : > + file://Trusted HP-UX passwords are stored differently : > + file://you need to call getprpwnam to get the password for : > + file://a user. : > + pr_pw = getprpwnam(pw->pw_name); : > + file://This dies with a bus error, but isn't : > + file://this a pointer that should be freed : > + file://before we reassign? : > + file://free(pw->pw_passwd); will break even a laid-back C compiler, due to the duplicate 'file:' labels. Global search-and-replace seems to have done something naughty.... -- 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/20020325/40dbb0b3/attachment.bin From abartlet at samba.org Tue Mar 26 15:29:14 2002 From: abartlet at samba.org (abartlet at samba.org) Date: Mon, 25 Mar 2002 20:29:14 -0800 Subject: Using kerberized SSHD. Question. In-Reply-To: <1017097111.6001.43.camel@UberGeek>; from austin@coremetrics.com on Mon, Mar 25, 2002 at 04:58:31PM -0600 References: <1017097111.6001.43.camel@UberGeek> Message-ID: <20020325202914.A10005@va.samba.org> On Mon, Mar 25, 2002 at 04:58:31PM -0600, Austin Gonyou wrote: > I have a kerberized SSHD installed on HOST-1, a login server for the > outside world. > > How can I make it so users are still authenticated via kerberos, even > though they haven't yet received a ticket? > > The main reason for this is that a user who is at home, no vpn, but has > an ssh client could then login and be authenticated by kerberos using > password authentication, get a ticket, then be allowed to ssh(at this > point using a kerberized ssh client) to any kerberized sshd host, > without entering a password. > > Is this possible? TIA Depending on your platform, you may be able to use PAM and pam_krb5 to achive this effect. Andrew Bartlett From tim at multitalents.net Tue Mar 26 15:48:22 2002 From: tim at multitalents.net (Tim Rice) Date: Mon, 25 Mar 2002 20:48:22 -0800 (PST) Subject: Trusted HP-UX 10.26 In-Reply-To: <00f001c1d448$f0ab8170$9b78a8c0@oedserver> Message-ID: On Mon, 25 Mar 2002, Darren Cole wrote: > Here the patch to make 3.1p1 openssh configure and build for Trusted HP-UX > 10.26. > + #ifdef TRUSTED_HPUX > + // the "--" makes login hang on Trusted HP-UX > + // 10.26 > + "-p", "-f", pw->pw_name, (char *)NULL); > + #else Please do not use C++ comments in C source files. Many C compilers do not recognize them as comments. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Tue Mar 26 17:45:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 26 Mar 2002 17:45:08 +1100 (EST) Subject: [Bug 183] Compile failure of OpenSSH on Solaris 2.6 Message-ID: <20020326064508.EBD06EA21@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=183 geoff.kozens at powersurfr.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From geoff.kozens at powersurfr.com 2002-03-26 17:45 ------- Mistake make with the pathing. :( Was pointing to an older version of OpenSSL. Still can't get it to compile past sshconnect1.c get an error with #error replaces . but working on it :) I apologize for the mispost. Geoff ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Jennifer at amnet.com.sg Tue Mar 26 18:42:38 2002 From: Jennifer at amnet.com.sg (Jennifer Anthony) Date: Tue, 26 Mar 2002 15:42:38 +0800 Subject: features Message-ID: <31D6076E3E15D4118AF200805F8558493AB062@amnet.com.sg> Dear Sir, Would you be able to advise OpenSSH can support PKCS #11 & Microsoft Crypto API (MSCAPI). Rdgs Jennifer From omic at fys.ku.dk Tue Mar 26 22:17:30 2002 From: omic at fys.ku.dk (Ole Michaelsen) Date: Tue, 26 Mar 2002 12:17:30 +0100 Subject: openssh-3.1p1, buildpkg.sh on Solaris 8 Message-ID: <20020326111730.GA5540@johansen.fys.ku.dk> Hello. First I would like to thank you for making building the OpenSSH package so easy on Solaris 8. I wish it was so easy with all open source software. For your information, I just build and packaged OpenSSH-3.1p1 on my Ultra 5 workstation with the following packages: system SUNWadmr System & Network Administration Root system SUNWarc Archive Libraries system SUNWbtool CCS tools bundled with SunOS system SUNWcar Core Architecture, (Root) system SUNWcarx Core Architecture, (Root) (64-bit) system SUNWcsd Core Solaris Devices system SUNWcsl Core Solaris, (Shared Libs) system SUNWcslx Core Solaris Libraries (64-bit) system SUNWcsr Core Solaris, (Root) system SUNWcsu Core Solaris, (Usr) system SUNWcsxu Core Solaris (Usr) (64-bit) system SUNWdoc Documentation Tools system SUNWesu Extended System Utilities system SUNWfcp Sun FCP SCSI Device Driver system SUNWfcpx Sun FCP SCSI Device Driver (64-bit) system SUNWfctl Sun Fibre Channel Transport layer system SUNWfctlx Sun Fibre Channel Transport layer (64-bit) system SUNWftpr FTP Server, (Root) system SUNWftpu FTP Server, (Usr) system SUNWgzip The GNU Zip (gzip) compression utility system SUNWhea SunOS Header Files system SUNWhmd SunSwift SBus Adapter Drivers system SUNWhmdx SunSwift SBus Adapter Drivers (64-bit) system SUNWkvm Core Architecture, (Kvm) system SUNWkvmx Core Architecture (Kvm) (64-bit) system SUNWless The GNU pager (less) system SUNWlibC Sun Workshop Compilers Bundled libC system SUNWlibCx Sun WorkShop Bundled 64-bit libC system SUNWlibm Sun WorkShop Bundled libm system SUNWlibms Sun WorkShop Bundled shared libm system SUNWlmsx Sun WorkShop Bundled 64-bit shared libm system SUNWloc System Localization system SUNWlocx System Localization (64-bit) system SUNWluxdx Sun Enterprise Network Array sf Device Driver (64-bit ) system SUNWluxop Sun Enterprise Network Array firmware and utilities system SUNWluxox Sun Enterprise Network Array libraries (64-bit) system SUNWman On-Line Manual Pages system SUNWnamos Northern America OS Support system SUNWnamow Northern America OW Support system SUNWntpr NTP, (Root) system SUNWntpu NTP, (Usr) system SUNWpd PCI Drivers system SUNWpdx PCI Drivers (64-bit) system SUNWpl5u Perl 5.005_03 system SUNWrmodu Realmode Modules, (Usr) system SUNWscpr Source Compatibility, (Root) system SUNWscpu Source Compatibility, (Usr) system SUNWses SCSI Enclosure Services Device Driver system SUNWsesx SCSI Enclosure Services Device Driver (64-bit) system SUNWsndmr Sendmail root system SUNWsndmu Sendmail user system SUNWsolnm Solaris Naming Enabler system SUNWsprot Solaris Bundled tools system SUNWssad SPARCstorage Array Drivers system SUNWssadx SPARCstorage Array Drivers (64-bit) system SUNWswmt Install and Patch Utilities system SUNWtoo Programming Tools system SUNWxcu4 XCU4 Utilities system SUNWzlib The Zip compression library and additionally from SunFreeware: $ pkginfo|grep -v SUNW application SMCbinut binutils application SMCgcc3 gcc application SMClsof lsof application SMCmake make application SMCnmap namp application SMCosslc openssl application SMCsudo sudo $ My path during the build was: $ echo $PATH /lhome/cs71/omichael/bin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin $ and with no special LD_LIBRARY_PATH or LD_RUN_PATH. Now, the only problem I had was, that the buildpkg.sh scripts does a ## Extract common info requires for the 'info' part of the package. VERSION=`tail -1 ../../version.h | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` but since there is a blank line at the end of version.h the variable VERSION is empty and the package will not build! I changed this to ## Extract common info requires for the 'info' part of the package. VERSION=`tail -1 ../../version.h | head -1 | sed -e 's/.*_\([0-9]\)/\1/g' | sed 's/\"$//'` and things went smooth. You should probably fix this or write a note about it (if you haven't already - though I didn't see it). Again, thanks for a (otherwise) great job done. -- Ole Michaelsen, Darmstadt, Germany http://www.fys.ku.dk/~omic omic at fys.ku.dk -------------- 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/20020326/f0ad280f/attachment.bin From bugzilla-daemon at mindrot.org Tue Mar 26 23:52:19 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 26 Mar 2002 23:52:19 +1100 (EST) Subject: [Bug 185] New: --with-ipv4-default breaks X11-forwarding on HP-UX 10.20 Message-ID: <20020326125219.E6E45E963@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=185 Summary: --with-ipv4-default breaks X11-forwarding on HP-UX 10.20 Product: Portable OpenSSH Version: 3.1p1 Platform: HPPA OS/Version: HP-UX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: koenig at science-computing.de compiling sshd on HP-UX 10.20 with configure --with-ipv4-default breaks X11-forwarding when sshd binary is run on HP-UX 10.20 (running the _same_ binary on 11.00 doesn't show the problem!). OS or ssh-version on the client side doesn't matter. here is the ssh -d output when trying to start xclock: c3po koenig > xclock debug1: Received X11 open request. debug1: fd 4 setting TCP_NODELAY debug1: fd 4 setting O_NONBLOCK debug1: channel 0: new [X11 connection from 127.0.0.1 port 2686] debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug1: X11 rejected 0 i0/o0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send ieof debug1: channel 0: input drain -> wait_oclose debug1: X11 closed 0 i2/o0 debug1: channel 0: rcvd oclose debug1: channel 0: input wait_oclose -> closed debug1: channel 0: rcvd ieof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: send oclose debug1: channel 0: output drain -> closed debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: X11 connection from 127.0.0.1 port 2686, nchannels 1 X connection to localhost:13.0 broken (explicit kill or server shutdown). if sshd is built with --with-ipv4-default there are two obvious changes: - $DISPLAY is set to localhost:10 instead of hostname:10 - only one xauth cookie is set for hostname/unix:10 (not localhost:10!), but there is no cookie in "xauth list" for tcp socket hostname:10 as in the "working" case without --with-ipv4-default,. Harald ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 27 01:28:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 01:28:15 +1100 (EST) Subject: [Bug 185] --with-ipv4-default breaks X11-forwarding on HP-UX 10.20 Message-ID: <20020326142815.44AD2E975@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=185 ------- Additional Comments From koenig at science-computing.de 2002-03-27 01:28 ------- I found a possible workaround for my problem: adding X11UseLocalhost no in sshd_conf for HP-UX 10.20 avoids the X11-forwarding 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 Wed Mar 27 03:47:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 03:47:17 +1100 (EST) Subject: [Bug 147] ssh dies if it gets SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Message-ID: <20020326164717.DDFCCE988@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=147 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-03-27 03:47 ------- fixed in -current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 27 04:53:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 04:53:54 +1100 (EST) Subject: [Bug 186] New: Build failure against openssl-0.9.5a Message-ID: <20020326175354.52F80E973@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=186 Summary: Build failure against openssl-0.9.5a Product: Portable OpenSSH Version: 3.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: malcolm.locke at rivalsdm.com The INSTALL file in the source of 3.1p1 contains the following: You will need working installations of Zlib and OpenSSL. Zlib: http://www.gzip.org/zlib/ OpenSSL 0.9.5a or greater: http://www.openssl.org/ However, the source will not build against openssl-0.9.5a. The build fails with: cipher.c:497: `EVP_CIPH_CBC_MODE' undeclared (first use in this function) cipher.c:497: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function) cipher.c:498: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function) make: *** [cipher.o] Error 1 There is no reference to these anywhere in the source of openssl-0.9.5a, however they are present in openssl-0.9.6c, so it looks like the INSTALL file should be updated. $ find openssl-0.9.5a/ -type f | xargs grep -l EVP_CIPH_CBC_MODE $ find openssl-0.9.6c/ -type f | xargs grep -l EVP_CIPH_CBC_MODE openssl-0.9.6c/crypto/evp/e_rc2.c openssl-0.9.6c/crypto/evp/evp_enc.c openssl-0.9.6c/crypto/evp/evp.h openssl-0.9.6c/crypto/evp/evp_locl.h openssl-0.9.6c/crypto/evp/e_xcbc_d.c openssl-0.9.6c/doc/crypto/EVP_EncryptInit.pod ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ewheeler at kaico.com Wed Mar 27 04:58:24 2002 From: ewheeler at kaico.com (ewheeler at kaico.com) Date: Tue, 26 Mar 2002 09:58:24 -0800 (PST) Subject: Viruses and Virus Scan at MTA In-Reply-To: Message-ID: Everyone should look into www.amavis.org! Setup postfix/qm/sendmail/... with virus scanning to drop virii at the MTA. That's how I knew about the viruses. The other great protection is to upgrade from outlook or outlook express to pine or Evolution. --Eric On Tue, 26 Mar 2002, Damien Miller wrote: > On Tue, 26 Mar 2002, Michael Tokarev wrote: > > > Well, yes, if problem persists, some sort of attachment filter (*.exe > > etc) will be helpful. > > If people could point me to one that works with mailman, it would be > appreciated. I just don't have time to look at the moment. > > -d > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Eric Wheeler Network Administrator KAICO 20417 SW 70th Ave. Tualatin, OR 97062 www.kaico.com Voice: 503.692.5268 From johnh at aproposretail.com Wed Mar 27 06:23:48 2002 From: johnh at aproposretail.com (John Hardin) Date: 26 Mar 2002 11:23:48 -0800 Subject: Viruses In-Reply-To: References: Message-ID: <1017170630.20299.0.camel@johnh.apropos.com> On Mon, 2002-03-25 at 16:24, Damien Miller wrote: > On 25 Mar 2002, John Hardin wrote: > > > Just for consideration, I'll insert a plug for the package I wrote: > > > > http://www.impsec.org/email-tool/procmail-security.html > > That URL doesn't seem to work. D'oh! Try: http://www.impsec.org/email-tools/procmail-security.html -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 ----------------------------------------------------------------------- "Rather than form a federation with Microsoft and work with what we had already created, there was this notion that the world should be offered an alternative." - Craig Mundie, Microsoft CTO, puzzled by non-MS-owned .NET user data services ----------------------------------------------------------------------- 50 days until Star Wars episode II: Attack of the Clones From raji at sgi.com Wed Mar 27 06:23:36 2002 From: raji at sgi.com (Rajeswari Raghunath) Date: Tue, 26 Mar 2002 11:23:36 -0800 Subject: openssh3.1p1 -- 'ssh' connection gets terminated Message-ID: <3CA0CAB8.AF9B0525@sgi.com> Hi, Compiled openssh3.1p1 by adding '-DINET6' flag to compile line to enable it to be installed on our ipv6 systems. No other code change was done to openssh. Installed it on two ipv6 systems and two ipv4 systems. Whenerer the server is an ipv4 system, ssh client seems to establish connection but it terminates immediately after printing motd message. Here is the typical failure scenario: ======================================================== vsx0 at system1 ~ 51 % ssh vsx0 at system2 vsx0 at system2's password: Last login: Tue Mar 26 09:53:05 2002 from system3.engr.sgi.com Connection to system2 closed. ========================================================== Has anyone seen a similar problem before? If so, can anyone help me out on this? Tried adding -DPACKET_DEBUG flag to compile line to check the packets. And this was what i found: Looks like the function 'client_loop' receives a message type of 'SSH2_MSG_CHANNEL_EOF' (packet type 96) from the function 'packet_read_poll2' before receiving the 'motd' message and hence subsequently the client terminates. (Wonder why server should be sending 'eof' here.) Any help would be useful here. Thanks, Raji. From bugzilla-daemon at mindrot.org Wed Mar 27 07:04:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 07:04:27 +1100 (EST) Subject: [Bug 55] [PATCH] Kerberos v5 support in portable Message-ID: <20020326200427.F40CBE9AC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=55 ------- Additional Comments From simon at sxw.org.uk 2002-03-27 07:04 ------- Created an attachment (id=54) Patch with fixes to password handling, as a unified diff ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dcole at keysoftsys.com Wed Mar 27 06:51:16 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Tue, 26 Mar 2002 11:51:16 -0800 Subject: Trusted HP-UX 10.26 References: Message-ID: <030701c1d4ff$a9b25430$9b78a8c0@oedserver> ----- Original Message ----- From: "Kevin Steves" To: "Darren Cole" Cc: Sent: Monday, March 25, 2002 6:04 PM Subject: Re: Trusted HP-UX 10.26 > On Mon, 25 Mar 2002, Darren Cole wrote: > :Note: This patch does not due privilege bracketting, nor does it make sshd > :multilevel aware (if you don't know what this means, don't worry about it) > > ah, ok. you can also upgrade to 10.20--why are you using 10.26 then? The product I am working on requires CMW functionality. Basicly openssh running on our development systems is a convience. Initially we just want openssh working. Later if needed we (probably me) will add multilevel awareness, and privilege bracketting. > :Some asked for seperate patches when they are large, but to keep them > :together if they are all for one fix. At only a 184 lines, I figured > :keeping the patch together was better than 4 or 5 different patches. > : > :___patch follows___ > :*************** > :*** 183,190 **** > :--- 187,209 ---- > : > : if (authctxt->attempt++ == 0) { > : /* setup auth context */ > :+ #ifdef TRUSTED_HPUX > :+ struct pr_passwd *pr_pw = NULL; > :+ #endif > : struct passwd *pw = NULL; > : pw = getpwnam(user); > :+ > :+ #ifdef TRUSTED_HPUX > :+ file://Trusted HP-UX passwords are stored differently > :+ file://you need to call getprpwnam to get the password for > :+ file://a user. > :+ pr_pw = getprpwnam(pw->pw_name); > :+ file://This dies with a bus error, but isn't > :+ file://this a pointer that should be freed > :+ file://before we reassign? > :+ file://free(pw->pw_passwd); > :+ pw->pw_passwd=pr_pw->ufld.fd_encrypt; > :+ #endif > : if (pw && allowed_user(pw) && strcmp(service, "ssh-connection")==0) { > : authctxt->pw = pwcopy(pw); > : authctxt->valid = 1; > > i don't understand this. why do you need the hashed password here? > openssh works today with hp-ux commercial security--why is CMW different? > see auth-passwd.c. also, why did you change only auth2.c and not auth1.c? I need the password here because I found that sshd would fail otherwise. The normal getpwnam does not get the password. Further down (not shown in the patch) there is a line: authenticated = m->userauth(authtxt); authtxt now has the password information. Without the getprpwnam call, authtxt wont get the encrypted password. Hmm... Now that I know a bit more about autoconf, I see how I could make HAVE_SCO_PROTECTED_PW be defined on trusted hp-ux. Then I could move this functionality to auth-passwd.c. Thanks, I will try that before I post my next try at the patch. I didn't look at auth1.c because it didn't fail in my testing. (though it probably would have if I had tested using ssh1 protocal). > :diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c > :*** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 > :--- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 > :*************** > :*** 1285,1291 **** > :--- 1285,1297 ---- > : #ifdef LOGIN_NEEDS_TERM > : (s->term ? s->term : "unknown"), > : #endif /* LOGIN_NEEDS_TERM */ > :+ #ifdef TRUSTED_HPUX > :+ // the "--" makes login hang on Trusted HP-UX > :+ // 10.26 > :+ "-p", "-f", pw->pw_name, (char *)NULL); > :+ #else > : "-p", "-f", "--", pw->pw_name, (char *)NULL); > :+ #endif > : > : /* Login couldn't be executed, die. */ > > do you require UseLogin yes? Yes. It seems much easier to let login taking care of checking and setting all that needs to be done on a CMW, instead of duplicating all of that work and code. > : if (c->ostate != CHAN_OUTPUT_CLOSED) > : chan_write_failed(c); > :+ #ifdef TRUSTED_HPUX > :+ file://Took two lines from a patch at: > :+ // > :+ file://by John C. Bowman > :+ file://There is some speculation that you could possibly > :+ file://see data loss from this on usenet. But without > :+ file://this sshd does not exit on logout. > :+ if (s->ttyfd != -1 && c->istate == CHAN_INPUT_OPEN) > :+ chan_read_failed(c); > :+ #endif > : s->chanid = -1; > > this has been discussed and is wrong. Okay. How can I fix the problem? I can login, then imediately logout, and will hang every time. That it happens everytime without any background proccess is a problem. If there is a better solution, please let me know. > i don't understand the file:// stuff. Yeah, got munched. I will attach the patch next time. As many pointed out comments like this should not be used. I have fixed this, so the stupid file:// stuff shouldn't happen again. Darren Cole dcole at keysoftsys.com From mouring at etoh.eviladmin.org Tue Mar 26 19:24:55 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 26 Mar 2002 02:24:55 -0600 (CST) Subject: Trusted HP-UX 10.26 In-Reply-To: <030701c1d4ff$a9b25430$9b78a8c0@oedserver> Message-ID: On Tue, 26 Mar 2002, Darren Cole wrote: [..] > > :diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c > > :*** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 > > :--- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 > > :*************** > > :*** 1285,1291 **** > > :--- 1285,1297 ---- > > : #ifdef LOGIN_NEEDS_TERM > > : (s->term ? s->term : "unknown"), > > : #endif /* LOGIN_NEEDS_TERM */ > > :+ #ifdef TRUSTED_HPUX > > :+ // the "--" makes login hang on Trusted HP-UX > > :+ // 10.26 > > :+ "-p", "-f", pw->pw_name, (char *)NULL); > > :+ #else > > : "-p", "-f", "--", pw->pw_name, (char *)NULL); > > :+ #endif > > : > > : /* Login couldn't be executed, die. */ > > > > do you require UseLogin yes? > > Yes. It seems much easier to let login taking care of checking and setting > all that needs to be done on a CMW, instead of duplicating all of that work > and code. > Reason is consistancy. if you do X11 forwarding or 'ssh site command' it does not use /bin/login and therefor any security that may be defined in /bin/login is effectly by-passed. UseLogin is a last ditch effort, not something to use by default. - Ben From bugzilla-daemon at mindrot.org Wed Mar 27 08:07:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 08:07:36 +1100 (EST) Subject: [Bug 187] New: ssh-keygen not converting from and to SECSH standard correctly Message-ID: <20020326210736.ED1AAE955@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=187 Summary: ssh-keygen not converting from and to SECSH standard correctly Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: ssh-keygen AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gcmccone at west.raytheon.com Instance 1) generate OpenSSH keys with "ssh-keygen -t rsa" with empty passphrase These keys successfully worked when connecting from an OpenSSH to OpenSSH converted private key to SECSH format with "ssh-keygen -e -f id_rsa >> ../.ssh2/a_secure_key" configured new SECSH private key to be used by F-SECURE 2.0.12 ssh client. when connecting from F-SECURE to OpenSSH public/private key used but is asking for a passphrase. Since the keys were generated with no passphrase, the converted key should have an empty passphrase as well. Note: Tried with a none empty passphrase as well and authentication failed when I entered the passphrase. Passphrase is corrupted. INSTANCE 2) generated RSA public/private key pair using F-SECURE ssh-keygen v 2.0.12 converted the SECSH keys to OpenSSH format using OpenSSH ssh-keygen as follows "ssh-keygen -i -f a_secure_key >> ../.ssh/id_rsa" tried connecting using from OpenSSH client with "ssh -v host" and received the following" host1% ssh -v host2 OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 6005 geteuid 6005 anon 1 debug1: Connecting to host2 [xxx.xxx.xxx.xxx] port 22. debug1: temporarily_use_uid: 6005/6005 (e=6005) debug1: restore_uid debug1: temporarily_use_uid: 6005/6005 (e=6005) debug1: restore_uid debug1: Connection established. debug1: identity file /home/user1/.ssh/identity type -1 debug1: identity file /home/user1/.ssh/id_rsa type -1 debug1: identity file /home/user1/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version 2.0.12 F-SECURE SSH debug1: match: 2.0.12 F-SECURE SSH pat 2.0.11*,2.0.12* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client 3des-cbc hmac-md5 none debug1: kex: client->server 3des-cbc hmac-md5 none debug1: dh_gen_key: priv key bits set: 203/384 debug1: bits set: 533/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'host2' is known and matches the DSA host key. debug1: Found key in /home/user1/.ssh/known_hosts:38 debug1: bits set: 508/1024 debug1: ssh_dss_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: buggy server: service_accept w/o service debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug1: next auth method to try is publickey debug1: try privkey: /home/user1/.ssh/identity debug1: try privkey: /home/user1/.ssh/id_rsa debug1: read PEM private key done: type RSA ssh_rsa_sign: SSH_BUG_SIGBLOB not supported resulting in a failure to use the private key and dropped into password authentication INSTANCE 3) generated DSA public/private key pair using F-SECURE ssh-keygen v 2.0.12 converted the SECSH keys to OpenSSH format using OpenSSH ssh-keygen as follows "ssh-keygen -i -f a_secure_key >> ../.ssh/id_dsa" and received the following from ssh-keygen ssh_dss_sign: sign failed xrealloc: out of memory ( new_size 4026548080 bytes ) BIG NOTE: this does not occur with the ssh-keygen with v3.0p1 The Following is a copy of the Makefile used to compile OpenSSH ------------------------------------------------------------------ # $Id: Makefile.in,v 1.197 2002/02/26 19:24:22 mouring Exp $ prefix=/usr/local exec_prefix=${prefix} bindir=${exec_prefix}/bin sbindir=${exec_prefix}/sbin libexecdir=${exec_prefix}/libexec datadir=${prefix}/share mandir=${prefix}/man mansubdir=man sysconfdir=/usr/local/etc piddir=/usr/local/etc srcdir=. top_srcdir=. DESTDIR= SSH_PROGRAM=${exec_prefix}/bin/ssh ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass SFTP_SERVER=$(libexecdir)/sftp-server PATHS= -DSSHDIR=\"$(sysconfdir)\" \ -D_PATH_SSH_PROGRAM=\"$(SSH_PROGRAM)\" \ -D_PATH_SSH_ASKPASS_DEFAULT=\"$(ASKPASS_PROGRAM)\" \ -D_PATH_SFTP_SERVER=\"$(SFTP_SERVER)\" \ -D_PATH_SSH_PIDDIR=\"$(piddir)\" \ -DSSH_RAND_HELPER=\"$(libexecdir)/ssh-rand-helper\" CC=gcc LD=gcc CFLAGS=-g -O2 -Wall -Wpointer-arith -Wno-uninitialized CPPFLAGS=-I. -I$(srcdir) -I/home/gmccone/installs/openssl-0.9.6c/include - I/home/gmccone/installs/zlib-1.1.4 -I/usr/local/include $(PATHS) - DHAVE_CONFIG_H LIBS=-lz -lsocket -lnsl -lcrypto LIBPAM=-lpam -ldl LIBWRAP= AR=/usr/xpg4/bin/ar RANLIB=ranlib INSTALL=./install-sh -c PERL=/home/gmccone/local/bin/perl ENT= XAUTH_PATH=/usr/openwin/bin/xauth LDFLAGS=-L. -Lopenbsd-compat/ -R/home/gmccone/installs/openssl-0.9.6c - L/home/gmccone/installs/openssl-0.9.6c -L/home/gmccone/installs/zlib-1.1.4 - R/home/gmccone/installs/zlib-1.1.4 -L/usr/local/lib -R/usr/local/lib EXEEXT= SSH_MODE= 0711 INSTALL_SSH_PRNG_CMDS= INSTALL_SSH_RAND_HELPER=yes SFTP_PROGS=sftp-server$(EXEEXT) sftp$(EXEEXT) TARGETS=ssh$(EXEEXT) sshd$(EXEEXT) ssh-add$(EXEEXT) ssh-keygen$(EXEEXT) ssh- keyscan${EXEEXT} ssh-agent$(EXEEXT) scp$(EXEEXT) ssh-rand-helper${EXEEXT} $(SFTP_PROGS) LIBSSH_OBJS=atomicio.o authfd.o authfile.o bufaux.o buffer.o canohost.o channels.o cipher.o compat.o compress.o crc32.o deattack.o dh.o dispatch.o fatal.o mac.o hostfile.o key.o kex.o kexdh.o kexgex.o log.o match.o misc.o mpaux.o nchan.o packet.o radix.o rijndael.o entropy.o readpass.o rsa.o scard.o ssh-dss.o ssh-rsa.o tildexpand.o ttymodes.o uidswap.o uuencode.o xmalloc.o 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 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 MANTYPE = man CONFIGFILES=sshd_config.out ssh_config.out moduli.out CONFIGFILES_IN=sshd_config ssh_config moduli PATHSUBS = \ -D/etc/ssh/ssh_config=$(sysconfdir)/ssh_config \ -D/etc/ssh/ssh_known_hosts=$(sysconfdir)/ssh_known_hosts \ -D/etc/ssh/sshd_config=$(sysconfdir)/sshd_config \ -D/usr/libexec=$(libexecdir) \ -D/etc/shosts.equiv=$(sysconfdir)/shosts.equiv \ -D/etc/ssh/ssh_host_key=$(sysconfdir)/ssh_host_key \ -D/etc/ssh/ssh_host_dsa_key=$(sysconfdir)/ssh_host_dsa_key \ -D/etc/ssh/ssh_host_rsa_key=$(sysconfdir)/ssh_host_rsa_key \ -D/var/run/sshd.pid=$(piddir)/sshd.pid \ -D/etc/ssh/moduli=$(sysconfdir)/moduli \ -D/etc/ssh/sshrc=$(sysconfdir)/sshrc \ -D/usr/X11R6/bin/xauth=$(XAUTH_PATH) \ - D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin FIXPATHSCMD = $(PERL) $(srcdir)/fixpaths $(PATHSUBS) all: $(CONFIGFILES) $(MANPAGES) $(TARGETS) $(LIBSSH_OBJS): config.h $(SSHOBJS): config.h $(SSHDOBJS): config.h .c.o: $(CC) $(CFLAGS) $(CPPFLAGS) -c $< LIBCOMPAT=openbsd-compat/libopenbsd-compat.a $(LIBCOMPAT): always (cd openbsd-compat && $(MAKE)) always: libssh.a: $(LIBSSH_OBJS) $(AR) rv $@ $(LIBSSH_OBJS) $(RANLIB) $@ ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS) $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBS) scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o $(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o $(LD) -o $@ ssh-agent.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o $(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o $(LD) -o $@ ssh-keyscan.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS) sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o $(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) -lssh -lopenbsd- compat $(LIBS) sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp- common.o sftp-glob.o $(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-rand-helper${EXEEXT}: $(LIBCOMPAT) libssh.a ssh-rand-helper.o $(LD) -o $@ ssh-rand-helper.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) # test driver for the loginrec code - not built by default logintest: logintest.o $(LIBCOMPAT) libssh.a loginrec.o $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS) $(MANPAGES): $(MANPAGES_IN) if test "$(MANTYPE)" = "cat"; then \ manpage=$(srcdir)/`echo $@ | sed 's/\.[1-9]\.out$$/\.0/'`; \ else \ manpage=$(srcdir)/`echo $@ | sed 's/\.out$$//'`; \ fi; \ if test "$(MANTYPE)" = "man"; then \ $(FIXPATHSCMD) $${manpage} | $(PERL) $(srcdir)/mdoc2man.pl > $@; \ else \ $(FIXPATHSCMD) $${manpage} > $@; \ fi $(CONFIGFILES): $(CONFIGFILES_IN) conffile=`echo $@ | sed 's/.out$$//'`; \ $(FIXPATHSCMD) $(srcdir)/$${conffile} > $@ clean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core (cd openbsd-compat && $(MAKE) clean) distclean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core rm -f Makefile config.h config.status ssh_prng_cmds *~ rm -rf autom4te.cache (cd openbsd-compat && $(MAKE) distclean) (cd scard && $(MAKE) distclean) veryclean: rm -f configure config.h.in *.0 rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core rm -f Makefile config.h config.status ssh_prng_cmds *~ (cd openbsd-compat && $(MAKE) distclean) (cd scard && $(MAKE) distclean) mrproper: distclean catman-do: @for f in $(MANPAGES_IN) ; do \ base=`echo $$f | sed 's/\..*$$//'` ; \ echo "$$f -> $$base.0" ; \ nroff -mandoc $$f | cat -v | sed -e 's/.\^H//g' \ >$$base.0 ; \ done distprep: catman-do autoreconf (cd scard && $(MAKE) -f Makefile.in distprep) install: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files host-key install-nokeys: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files scard-install: (cd scard && $(MAKE) DESTDIR=$(DESTDIR) install) install-files: scard-install $(srcdir)/mkinstalldirs $(DESTDIR)$(bindir) $(srcdir)/mkinstalldirs $(DESTDIR)$(sbindir) $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir) $(srcdir)/mkinstalldirs $(DESTDIR)$(datadir) $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)1 $(srcdir)/mkinstalldirs $(DESTDIR)$(mandir)/$(mansubdir)8 $(srcdir)/mkinstalldirs $(DESTDIR)$(libexecdir) $(INSTALL) -m $(SSH_MODE) -s ssh $(DESTDIR)$(bindir)/ssh $(INSTALL) -m 0755 -s scp $(DESTDIR)$(bindir)/scp $(INSTALL) -m 0755 -s ssh-add $(DESTDIR)$(bindir)/ssh-add $(INSTALL) -m 0755 -s ssh-agent $(DESTDIR)$(bindir)/ssh-agent $(INSTALL) -m 0755 -s ssh-keygen $(DESTDIR)$(bindir)/ssh-keygen $(INSTALL) -m 0755 -s ssh-keyscan $(DESTDIR)$(bindir)/ssh-keyscan $(INSTALL) -m 0755 -s sshd $(DESTDIR)$(sbindir)/sshd if test ! -z "$(INSTALL_SSH_RAND_HELPER)" ; then \ $(INSTALL) -m 0755 -s ssh-rand-helper $(DESTDIR) $(libexecdir)/ssh-rand-helper ; \ fi $(INSTALL) -m 0755 -s sftp $(DESTDIR)$(bindir)/sftp $(INSTALL) -m 0755 -s sftp-server $(DESTDIR)$(SFTP_SERVER) $(INSTALL) -m 644 ssh.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1 $(INSTALL) -m 644 scp.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1 $(INSTALL) -m 644 ssh-add.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh- add.1 $(INSTALL) -m 644 ssh-agent.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/ssh- agent.1 $(INSTALL) -m 644 ssh-keygen.1.out $(DESTDIR)$(mandir)/$(mansubdir) 1/ssh-keygen.1 $(INSTALL) -m 644 ssh-keyscan.1.out $(DESTDIR)$(mandir)/$(mansubdir) 1/ssh-keyscan.1 $(INSTALL) -m 644 sshd.8.out $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8 $(INSTALL) -m 644 sftp.1.out $(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1 $(INSTALL) -m 644 sftp-server.8.out $(DESTDIR)$(mandir)/$(mansubdir) 8/sftp-server.8 -rm -f $(DESTDIR)$(bindir)/slogin ln -s ssh$(EXEEXT) $(DESTDIR)$(bindir)/slogin -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 ln -s ssh.1 $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 if [ ! -d $(DESTDIR)$(sysconfdir) ]; then \ $(srcdir)/mkinstalldirs $(DESTDIR)$(sysconfdir); \ fi if [ ! -f $(DESTDIR)$(sysconfdir)/ssh_config ]; then \ $(INSTALL) -m 644 ssh_config.out $(DESTDIR) $(sysconfdir)/ssh_config; \ else \ echo "$(DESTDIR)$(sysconfdir)/ssh_config already exists, install will not overwrite"; \ fi if [ ! -f $(DESTDIR)$(sysconfdir)/sshd_config ]; then \ $(INSTALL) -m 644 sshd_config.out $(DESTDIR) $(sysconfdir)/sshd_config; \ else \ echo "$(DESTDIR)$(sysconfdir)/sshd_config already exists, install will not overwrite"; \ fi if [ -f ssh_prng_cmds -a ! -z "$(INSTALL_SSH_PRNG_CMDS)" ]; then \ $(PERL) $(srcdir)/fixprogs ssh_prng_cmds $(ENT); \ if [ ! -f $(DESTDIR)$(sysconfdir)/ssh_prng_cmds ] ; then \ $(INSTALL) -m 644 ssh_prng_cmds.out $(DESTDIR) $(sysconfdir)/ssh_prng_cmds; \ else \ echo "$(DESTDIR)$(sysconfdir)/ssh_prng_cmds already exists, install will not overwrite"; \ fi ; \ fi if [ ! -f $(DESTDIR)$(sysconfdir)/moduli ]; then \ if [ -f $(DESTDIR)$(sysconfdir)/primes ]; then \ echo "moving $(DESTDIR)$(sysconfdir)/primes to $(DESTDIR)$(sysconfdir)/moduli"; \ mv "$(DESTDIR)$(sysconfdir)/primes" "$(DESTDIR) $(sysconfdir)/moduli"; \ else \ $(INSTALL) -m 644 moduli.out $(DESTDIR) $(sysconfdir)/moduli; \ fi ; \ else \ echo "$(DESTDIR)$(sysconfdir)/moduli already exists, install will not overwrite"; \ fi host-key: ssh-keygen$(EXEEXT) if [ -z "$(DESTDIR)" ] ; then \ if [ -f "$(DESTDIR)$(sysconfdir)/ssh_host_key" ] ; then \ echo "$(DESTDIR)$(sysconfdir)/ssh_host_key already exists, skipping." ; \ else \ ./ssh-keygen -t rsa1 -f $(DESTDIR) $(sysconfdir)/ssh_host_key -N "" ; \ fi ; \ if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key ] ; then \ echo "$(DESTDIR)$(sysconfdir)/ssh_host_dsa_key already exists, skipping." ; \ else \ ./ssh-keygen -t dsa -f $(DESTDIR) $(sysconfdir)/ssh_host_dsa_key -N "" ; \ fi ; \ if [ -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key ] ; then \ echo "$(DESTDIR)$(sysconfdir)/ssh_host_rsa_key already exists, skipping." ; \ else \ ./ssh-keygen -t rsa -f $(DESTDIR) $(sysconfdir)/ssh_host_rsa_key -N "" ; \ fi ; \ fi ; host-key-force: ssh-keygen$(EXEEXT) ./ssh-keygen -t rsa1 -f $(DESTDIR)$(sysconfdir)/ssh_host_key -N "" ./ssh-keygen -t dsa -f $(DESTDIR)$(sysconfdir)/ssh_host_dsa_key -N "" ./ssh-keygen -t rsa -f $(DESTDIR)$(sysconfdir)/ssh_host_rsa_key -N "" uninstallall: uninstall -rm -f $(DESTDIR)$(sysconfdir)/ssh_config -rm -f $(DESTDIR)$(sysconfdir)/sshd_config -rm -f $(DESTDIR)$(sysconfdir)/ssh_prng_cmds -rmdir $(DESTDIR)$(sysconfdir) -rmdir $(DESTDIR)$(bindir) -rmdir $(DESTDIR)$(sbindir) -rmdir $(DESTDIR)$(mandir)/$(mansubdir)1 -rmdir $(DESTDIR)$(mandir)/$(mansubdir)8 -rmdir $(DESTDIR)$(mandir) -rmdir $(DESTDIR)$(libexecdir) uninstall: -rm -f $(DESTDIR)$(bindir)/slogin -rm -f $(DESTDIR)$(bindir)/ssh$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/scp$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/ssh-add$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/ssh-agent$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/ssh-keygen$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT) -rm -f $(DESTDIR)$(bindir)/sftp$(EXEEXT) -rm -f $(DESTDIR)$(sbindir)/sshd$(EXEEXT) -rm -r $(DESTDIR)$(SFTP_SERVER)$(EXEEXT) -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/scp.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-add.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-agent.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keygen.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/sftp.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/ssh-keyscan.1 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sshd.8 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)8/sftp-server.8 -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From peter at ifm.liu.se Wed Mar 27 08:21:31 2002 From: peter at ifm.liu.se (Peter Eriksson) Date: Tue, 26 Mar 2002 22:21:31 +0100 (MET) Subject: Two patches for OpenSSH 3.1p1 Message-ID: Please find enclosed two patches for OpenSSH 3.1p1. The first patch solves a problem where sessions will be left "hanging" when you normally exit from a ssh shell (for example by logging out from the remote host via "exit" or "logout"). The problem seems to be that sshd (and some other parts of OpenSSH) doesn't check the return code and errno from waitpid() for errno == EINTR and thus fails to collect the started subprocess correctly. This problem occurs atleast on Solaris 2 and UNICOS systems but it should probably exist on all other SysV based systems... (It doesn't occur all the time so it can be quite hard to test for). The other patch adds a "-I" command line option to allow sshd to be correctly started (and automatically restarted) by "init" (via the /etc/inittab file) on systems with a SysV-style "init". It is *not* sufficent to just use the "-D" (no daemon) flag since that doesn't correctly handle log file output, closing of stdin/stdout/stderr or the setsid() call to drop the controlling TTY. Trying to start sshd via inittab and using "-D" will cause sshd to terminate if the Console connection (for example if using a serial terminal) gets dropped... -- Peter Eriksson Phone: +46 13 28 2786 Computer Systems Manager/BOFH Cell/GSM: +46 705 18 2786 Physics Department, Link?ping University Room: Building F, F203 SE-581 83 Link?ping, Sweden http://www.ifm.liu.se/~peter -------------- next part -------------- diff -r -c openssh-3.1p1/entropy.c openssh-3.1p1-peter/entropy.c *** openssh-3.1p1/entropy.c Tue Jan 22 11:57:54 2002 --- openssh-3.1p1-peter/entropy.c Mon Mar 18 22:00:10 2002 *************** *** 110,118 **** close(p[0]); ! if (waitpid(pid, &ret, 0) == -1) ! fatal("Couldn't wait for ssh-rand-helper completion: %s", strerror(errno)); /* We don't mind if the child exits upon a SIGPIPE */ if (!WIFEXITED(ret) && --- 110,124 ---- close(p[0]); ! { ! int code; ! ! while ((code = waitpid(pid, &ret, 0)) == -1 && errno == EINTR) ! ; ! if (code < 0) ! fatal("Couldn't wait for ssh-rand-helper completion: %s", strerror(errno)); + } /* We don't mind if the child exits upon a SIGPIPE */ if (!WIFEXITED(ret) && Only in openssh-3.1p1/scard: Ssh.bin diff -r -c openssh-3.1p1/serverloop.c openssh-3.1p1-peter/serverloop.c *** openssh-3.1p1/serverloop.c Fri Feb 8 12:07:17 2002 --- openssh-3.1p1-peter/serverloop.c Mon Mar 18 22:01:02 2002 *************** *** 673,679 **** /* We no longer want our SIGCHLD handler to be called. */ mysignal(SIGCHLD, SIG_DFL); ! wait_pid = waitpid(-1, &wait_status, 0); if (wait_pid == -1) packet_disconnect("wait: %.100s", strerror(errno)); else if (wait_pid != pid) --- 673,681 ---- /* We no longer want our SIGCHLD handler to be called. */ mysignal(SIGCHLD, SIG_DFL); ! while ((wait_pid = waitpid(-1, &wait_status, 0)) < 0 && errno == EINTR) ! ; ! if (wait_pid == -1) packet_disconnect("wait: %.100s", strerror(errno)); else if (wait_pid != pid) diff -r -c openssh-3.1p1/sftp-int.c openssh-3.1p1-peter/sftp-int.c *** openssh-3.1p1/sftp-int.c Wed Feb 13 04:10:33 2002 --- openssh-3.1p1-peter/sftp-int.c Mon Mar 18 22:02:38 2002 *************** *** 176,183 **** strerror(errno)); _exit(1); } ! if (waitpid(pid, &status, 0) == -1) fatal("Couldn't wait for child: %s", strerror(errno)); if (!WIFEXITED(status)) error("Shell exited abormally"); else if (WEXITSTATUS(status)) --- 176,192 ---- strerror(errno)); _exit(1); } ! { ! int code; ! ! ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) fatal("Couldn't wait for child: %s", strerror(errno)); + } + if (!WIFEXITED(status)) error("Shell exited abormally"); else if (WEXITSTATUS(status)) diff -r -c openssh-3.1p1/sftp.c openssh-3.1p1-peter/sftp.c *** openssh-3.1p1/sftp.c Wed Feb 13 04:03:57 2002 --- openssh-3.1p1-peter/sftp.c Mon Mar 18 22:01:49 2002 *************** *** 246,253 **** if (infile != stdin) fclose(infile); ! if (waitpid(sshpid, NULL, 0) == -1) fatal("Couldn't wait for ssh process: %s", strerror(errno)); exit(0); } --- 246,261 ---- if (infile != stdin) fclose(infile); ! { ! int code; ! ! ! while ((code = waitpid(sshpid, NULL, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) fatal("Couldn't wait for ssh process: %s", strerror(errno)); + } exit(0); } diff -r -c openssh-3.1p1/ssh-rand-helper.c openssh-3.1p1-peter/ssh-rand-helper.c *** openssh-3.1p1/ssh-rand-helper.c Sun Feb 10 08:32:30 2002 --- openssh-3.1p1-peter/ssh-rand-helper.c Mon Mar 18 22:04:34 2002 *************** *** 389,398 **** debug3("Time elapsed: %d msec", msec_elapsed); ! if (waitpid(pid, &status, 0) == -1) { error("Couldn't wait for child '%s' completion: %s", src->cmdstring, strerror(errno)); return 0.0; } RAND_add(&status, sizeof(&status), 0.0); --- 389,406 ---- debug3("Time elapsed: %d msec", msec_elapsed); ! { ! int code; ! ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) ! { error("Couldn't wait for child '%s' completion: %s", src->cmdstring, strerror(errno)); return 0.0; + } } RAND_add(&status, sizeof(&status), 0.0); diff -r -c openssh-3.1p1/sshd.c openssh-3.1p1-peter/sshd.c *** openssh-3.1p1/sshd.c Tue Mar 5 02:31:30 2002 --- openssh-3.1p1-peter/sshd.c Mon Mar 18 22:03:37 2002 *************** *** 264,273 **** main_sigchld_handler(int sig) { int save_errno = errno; ! int status; ! while (waitpid(-1, &status, WNOHANG) > 0) ! ; signal(SIGCHLD, main_sigchld_handler); errno = save_errno; --- 264,274 ---- main_sigchld_handler(int sig) { int save_errno = errno; ! int status, code; ! ! while ((code = waitpid(-1, &status, WNOHANG)) < 0 && errno == EINTR || code > 0) ! ; signal(SIGCHLD, main_sigchld_handler); errno = save_errno; -------------- next part -------------- diff -r -c openssh-3.1p1/sshd.c openssh-3.1p1-peter/sshd.c *** openssh-3.1p1/sshd.c Tue Mar 5 02:31:30 2002 --- openssh-3.1p1-peter/sshd.c Tue Mar 26 20:59:06 2002 *************** *** 120,125 **** --- 120,128 ---- /* Flag indicating that the daemon is being started from inetd. */ int inetd_flag = 0; + /* Flag indicating that the daemon is being started from init (/etc/inittab). */ + int init_flag = 0; + /* Flag indicating that sshd should not detach and become a daemon. */ int no_daemon_flag = 0; *************** *** 608,614 **** initialize_server_options(&options); /* Parse command-line arguments. */ ! while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:o:dDeiqtQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; --- 612,618 ---- initialize_server_options(&options); /* Parse command-line arguments. */ ! while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:o:dDeiIqtQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; *************** *** 636,641 **** --- 640,648 ---- case 'e': log_stderr = 1; break; + case 'I': + init_flag = 1; + break; case 'i': inetd_flag = 1; break; *************** *** 706,719 **** /* * Force logging to stderr until we have loaded the private host ! * key (unless started from inetd) */ log_init(__progname, options.log_level == SYSLOG_LEVEL_NOT_SET ? SYSLOG_LEVEL_INFO : options.log_level, options.log_facility == SYSLOG_FACILITY_NOT_SET ? SYSLOG_FACILITY_AUTH : options.log_facility, ! !inetd_flag); #ifdef _CRAY /* Cray can define user privs drop all prives now! --- 713,726 ---- /* * Force logging to stderr until we have loaded the private host ! * key (unless started from inetd or init) */ log_init(__progname, options.log_level == SYSLOG_LEVEL_NOT_SET ? SYSLOG_LEVEL_INFO : options.log_level, options.log_facility == SYSLOG_FACILITY_NOT_SET ? SYSLOG_FACILITY_AUTH : options.log_facility, ! !inetd_flag && !init_flag); #ifdef _CRAY /* Cray can define user privs drop all prives now! *************** *** 814,820 **** #endif /* Initialize the log (it is reinitialized below in case we forked). */ ! if (debug_flag && !inetd_flag) log_stderr = 1; log_init(__progname, options.log_level, options.log_facility, log_stderr); --- 821,827 ---- #endif /* Initialize the log (it is reinitialized below in case we forked). */ ! if (debug_flag && !inetd_flag && !init_flag) log_stderr = 1; log_init(__progname, options.log_level, options.log_facility, log_stderr); *************** *** 827,834 **** #ifdef TIOCNOTTY int fd; #endif /* TIOCNOTTY */ ! if (daemon(0, 0) < 0) fatal("daemon() failed: %.200s", strerror(errno)); /* Disconnect from the controlling tty. */ #ifdef TIOCNOTTY --- 834,862 ---- #ifdef TIOCNOTTY int fd; #endif /* TIOCNOTTY */ ! ! if (!init_flag) ! { ! if (daemon(0, 0) < 0) fatal("daemon() failed: %.200s", strerror(errno)); + } + else + { + signal(SIGTTOU, SIG_IGN); + signal(SIGTTIN, SIG_IGN); + + (void) setsid(); + (void) chdir("/"); + + if ((fd = open(_PATH_DEVNULL, O_RDWR, 0)) != -1) + { + (void)dup2(fd, STDIN_FILENO); + (void)dup2(fd, STDOUT_FILENO); + (void)dup2(fd, STDERR_FILENO); + if (fd > 2) + (void)close (fd); + } + } /* Disconnect from the controlling tty. */ #ifdef TIOCNOTTY From Nicolas.Williams at ubsw.com Wed Mar 27 08:34:18 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 26 Mar 2002 16:34:18 -0500 Subject: SSH / PAM / Kerberos / password aging Message-ID: <20020326163416.Q27398@sm2p1386swk.wdr.com> Ok, so, things are complicated. The PAM standard insists on password aging being done after account authorization, which comes after user authentication. Kerberos can't authenticate users whose passwords are expired. So PAM_KRB5 implementations tend to return PAM_SUCCESS from pam_krb5:pam_sm_authenticate() and arrange for pam_krb5:pam_sm_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user can't be said to be authenticated at that point. The problem with this is that by the time pam_acct_mgmt() is called in OpenSSH userauth has been completed, so kbd-interactive is not used for the password changing and instead the work is relegated till the TTY session is setup. By then the login process has begun and the user even has a UTMP entry. To make matters worse, OpenSSH calls pam_setcred() before pam_chauthtok(). Clearly that is wrong. Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it to do the password aging prompting in pam_krb5:pam_sm_authenticate(). Using this option with the "sshd" PAM service causes password aging to be performed over the kbd-interactive protocol. Good? Bad? I say "good." 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 josb at cncdsl.com Wed Mar 27 08:52:16 2002 From: josb at cncdsl.com (Jos Backus) Date: Tue, 26 Mar 2002 13:52:16 -0800 Subject: Two patches for OpenSSH 3.1p1 In-Reply-To: References: Message-ID: <20020326215238.GB69341@lizzy.bugworks.com> On Tue, Mar 26, 2002 at 10:21:31PM +0100, Peter Eriksson wrote: > It is *not* sufficent to just use the "-D" (no daemon) flag since that > doesn't correctly handle log file output, closing of stdin/stdout/stderr > or the setsid() call to drop the controlling TTY. Note that when running sshd under a process controller such as AIX's SRC or djb's daemontools you don't want any of these to happen, so the use of the word ``correctly'' is not entirely appropriate here. ``-D'' does fullfil its intended purpose. -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From austin at coremetrics.com Wed Mar 27 09:01:41 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 26 Mar 2002 16:01:41 -0600 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326163416.Q27398@sm2p1386swk.wdr.com> References: <20020326163416.Q27398@sm2p1386swk.wdr.com> Message-ID: <1017180101.11943.34.camel@UberGeek> Yow..that is a problem isn't it. Hmm..It's a hard call, but I'd have to vote good there too. On Tue, 2002-03-26 at 15:34, Nicolas Williams wrote: > Ok, so, things are complicated. > > The PAM standard insists on password aging being done after account > authorization, which comes after user authentication. Kerberos can't > authenticate users whose passwords are expired. > > So PAM_KRB5 implementations tend to return PAM_SUCCESS from > pam_krb5:pam_sm_authenticate() and arrange for > pam_krb5:pam_sm_acct_mgmt() > to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user > can't be said to be authenticated at that point. > > The problem with this is that by the time pam_acct_mgmt() is called in > OpenSSH userauth has been completed, so kbd-interactive is not used for > the password changing and instead the work is relegated till the TTY > session is setup. By then the login process has begun and the user even > has a UTMP entry. > > To make matters worse, OpenSSH calls pam_setcred() before > pam_chauthtok(). Clearly that is wrong. > > Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it > to do the password aging prompting in pam_krb5:pam_sm_authenticate(). > Using this option with the "sshd" PAM service causes password aging to > be performed over the kbd-interactive protocol. Good? Bad? I say "good." > > 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 -- 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 From fcusack at fcusack.com Wed Mar 27 09:13:26 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 26 Mar 2002 14:13:26 -0800 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326163416.Q27398@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Mar 26, 2002 at 04:34:18PM -0500 References: <20020326163416.Q27398@sm2p1386swk.wdr.com> Message-ID: <20020326141326.D22417@google.com> On Tue, Mar 26, 2002 at 04:34:18PM -0500, Nicolas Williams wrote: > Ok, so, things are complicated. > > The PAM standard insists on password aging being done after account > authorization, which comes after user authentication. Kerberos can't > authenticate users whose passwords are expired. > > So PAM_KRB5 implementations tend to return PAM_SUCCESS from > pam_krb5:pam_sm_authenticate() and arrange for pam_krb5:pam_sm_acct_mgmt() > to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user > can't be said to be authenticated at that point. > > The problem with this is that by the time pam_acct_mgmt() is called in > OpenSSH userauth has been completed, so kbd-interactive is not used for > the password changing and instead the work is relegated till the TTY > session is setup. By then the login process has begun and the user even > has a UTMP entry. > > To make matters worse, OpenSSH calls pam_setcred() before > pam_chauthtok(). Clearly that is wrong. > > Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it > to do the password aging prompting in pam_krb5:pam_sm_authenticate(). > Using this option with the "sshd" PAM service causes password aging to > be performed over the kbd-interactive protocol. Good? Bad? I say "good." Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint et al complete? Your solution requires a rewrite of all PAM modules. /fc From bugzilla-daemon at mindrot.org Wed Mar 27 09:24:43 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 09:24:43 +1100 (EST) Subject: [Bug 188] New: pam_chauthtok() is called too late Message-ID: <20020326222443.05C12EA40@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=188 Summary: pam_chauthtok() is called too late Product: Portable OpenSSH Version: 3.1p1 Platform: Other OS/Version: All Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams at ubsw.com When pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD pam_chauthtok() must be the next PAM function called. That is, pam_chauthtok() MUST be called before pam_open_session() and before pam_setcred(PAM_ESTABLISH_CRED). The point is: if the user's password is expired then the login process cannot proceed too far before password changing is attempted. This bug applies, or should apply, to any implementation of PAM. Thus I selected "All" for the OS to which this bug applies. Cheers, Nico ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 27 09:35:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 09:35:20 +1100 (EST) Subject: [Bug 189] New: pam_setcred() failures should not be treated as fatal Message-ID: <20020326223520.B1645EA4F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=189 Summary: pam_setcred() failures should not be treated as fatal Product: Portable OpenSSH Version: 3.1p1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Nicolas.Williams at ubsw.com pam_setcred() failures should not be treated as fatal; at least there should be an option so pam_setcred() failures are not treated as fatal(). But users should be warned loudly when pam_setcred(PAM_ESTABLISH_CRED) fails and sshd proceeds. Cheers, Nico ------- 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 Mar 27 09:26:10 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 26 Mar 2002 17:26:10 -0500 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326141326.D22417@google.com>; from fcusack@fcusack.com on Tue, Mar 26, 2002 at 02:13:26PM -0800 References: <20020326163416.Q27398@sm2p1386swk.wdr.com> <20020326141326.D22417@google.com> Message-ID: <20020326172608.R27398@sm2p1386swk.wdr.com> On Tue, Mar 26, 2002 at 02:13:26PM -0800, Frank Cusack wrote: > Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint > et al complete? Your solution requires a rewrite of all PAM modules. Indeed. Fine. So move pam_acct_mgmt() into do_pam_authenticate() and also pam_chauthtok(). Fine idea. I like it. > /fc 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 Wed Mar 27 09:44:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 09:44:25 +1100 (EST) Subject: [Bug 187] ssh-keygen not converting from and to SECSH standard correctly Message-ID: <20020326224425.93327E9DB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=187 ------- Additional Comments From markus at openbsd.org 2002-03-27 09:44 ------- (1) exporting openssh private keys is not supported (2) rsa bugs from ssh.com 2.0.12 are not supported (3) this is probably another 2.0.12 bug. ------- 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 Mar 27 09:39:11 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 26 Mar 2002 17:39:11 -0500 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326172608.R27398@sm2p1386swk.wdr.com>; from willian on Tue, Mar 26, 2002 at 05:26:09PM -0500 References: <20020326163416.Q27398@sm2p1386swk.wdr.com> <20020326141326.D22417@google.com> <20020326172608.R27398@sm2p1386swk.wdr.com> Message-ID: <20020326173908.S27268@sm2p1386swk.wdr.com> On Tue, Mar 26, 2002 at 05:26:09PM -0500, Nicolas Williams wrote: > On Tue, Mar 26, 2002 at 02:13:26PM -0800, Frank Cusack wrote: > > Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint > > et al complete? Your solution requires a rewrite of all PAM modules. > > Indeed. Fine. So move pam_acct_mgmt() into do_pam_authenticate() and > also pam_chauthtok(). > > Fine idea. I like it. > > > /fc I'll post a patch tomorrow. 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 Wed Mar 27 10:00:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 10:00:12 +1100 (EST) Subject: [Bug 187] ssh-keygen not converting from and to SECSH standard correctly Message-ID: <20020326230012.E4AF1E9E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=187 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From markus at openbsd.org 2002-03-27 09:59 ------- the SECSH standard does not talk about private key formats and your examples are about private keys only. for private keys we support importing keys only. for using RSA keys against older implemenations, not all bugs from the old implemenations are supported ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From austin at coremetrics.com Wed Mar 27 10:06:21 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 26 Mar 2002 17:06:21 -0600 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326173908.S27268@sm2p1386swk.wdr.com> References: <20020326173908.S27268@sm2p1386swk.wdr.com> Message-ID: <1017183981.11921.38.camel@UberGeek> Great show! On Tue, 2002-03-26 at 16:39, Nicolas Williams wrote: > On Tue, Mar 26, 2002 at 05:26:09PM -0500, Nicolas Williams wrote: > > On Tue, Mar 26, 2002 at 02:13:26PM -0800, Frank Cusack wrote: > > > Qualified good. Wouldn't it be better to do pam_acct_mgmt() before > kbdint > > > et al complete? Your solution requires a rewrite of all PAM > modules. > > > > Indeed. Fine. So move pam_acct_mgmt() into do_pam_authenticate() and > > also pam_chauthtok(). > > > > Fine idea. I like it. > > > > > /fc > > I'll post a patch tomorrow. > > 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 -- 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 From bugzilla-daemon at mindrot.org Wed Mar 27 10:28:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 10:28:25 +1100 (EST) Subject: [Bug 186] Build failure against openssl-0.9.5a Message-ID: <20020326232825.B06E8EA5A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=186 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From markus at openbsd.org 2002-03-27 10:28 ------- *** This bug has been marked as a duplicate of 138 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Mar 27 10:28:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Mar 2002 10:28:30 +1100 (EST) Subject: [Bug 138] Incorrect OpenSSL version requirment? Message-ID: <20020326232830.71AF7EA5D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=138 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |malcolm.locke at rivalsdm.com ------- Additional Comments From markus at openbsd.org 2002-03-27 10:28 ------- *** Bug 186 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 01:00:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 01:00:25 +1100 (EST) Subject: [Bug 190] New: ssh locks while waiting for output of df Message-ID: <20020327140025.93C1BE916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=190 Summary: ssh locks while waiting for output of df Product: Portable OpenSSH Version: 2.9.9p2 Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jesch at us.ibm.com $ssh jesch at ciao -v -v -v ... debug3: Reading output from 'df' debug3: Time elapsed: 2 msec At this point ssh waits forever (in this case, because of a bug in df). Some wrap around code can be useful in some cases. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 01:14:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 01:14:36 +1100 (EST) Subject: [Bug 191] New: compilation faills in auth1.c:392 `pw' undeclared when USE_PAM is on Message-ID: <20020327141436.8AE1CE916@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=191 Summary: compilation faills in auth1.c:392 `pw' undeclared when USE_PAM is on Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kent at lysator.liu.se auth1.c: In function `do_authentication': auth1.c:392: `pw' undeclared (first use in this function) auth1.c:392: (Each undeclared identifier is reported only once auth1.c:392: for each function it appears in.) Perhaps "pw" should be "authctxt->pw"? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 02:05:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 02:05:50 +1100 (EST) Subject: [Bug 191] compilation faills in auth1.c:392 `pw' undeclared when USE_PAM is on Message-ID: <20020327150550.61BD8E956@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=191 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From mouring at eviladmin.org 2002-03-28 02:05 ------- I'm using the CVS source and it works fine for me under Redhat 7.0 The area of code you are refering to has the 'pw' defined at the start of the do_authentification(void). - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 02:43:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 02:43:29 +1100 (EST) Subject: [Bug 188] pam_chauthtok() is called too late Message-ID: <20020327154329.AFCF0E956@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=188 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-28 02:43 ------- Created an attachment (id=55) Patch to do pw aging in kbd-interactive ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 02:50:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 02:50:25 +1100 (EST) Subject: [Bug 188] pam_chauthtok() is called too late Message-ID: <20020327155025.059F2E9F2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=188 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-28 02:50 ------- Attached patch. This patch does the following: - adds a boolean argument to do_pam_authenticate(), "can_age_pw_here" - do_pam_authenticate() always calls pam_acct_mgmt() and saves the result - do_pam_authenticate() calls pam_chauthtok() IFF (can_age_pw_here && pam_acct_mgmt() == PAM_NEW_AUTHTOK_REQD) - auth2_pam() calls do_pam_authenticate(0, 1) to allow password aging during keyboard-interactive authentication Cheers, Nico ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 03:13:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 03:13:25 +1100 (EST) Subject: [Bug 191] compilation faills in auth1.c:392 `pw' undeclared when USE_PAM is on Message-ID: <20020327161325.1196FE9F6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=191 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | ------- Additional Comments From markus at openbsd.org 2002-03-28 03:13 ------- Index: auth1.c =================================================================== RCS file: /cvs/openssh_cvs/auth1.c,v retrieving revision 1.64 diff -u -r1.64 auth1.c --- auth1.c 22 Mar 2002 03:04:11 -0000 1.64 +++ auth1.c 27 Mar 2002 15:58:51 -0000 @@ -389,7 +389,7 @@ use_privsep ? " [net]" : ""); #ifdef USE_PAM - start_pam(pw == NULL ? "NOUSER" : user); + start_pam(authctxt->pw == NULL ? "NOUSER" : user); #endif /* ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 03:35:58 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 03:35:58 +1100 (EST) Subject: [Bug 192] New: monitor.c:545: undefined reference to `auth_password with USE_PAM on Message-ID: <20020327163558.C2515E9FC@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=192 Summary: monitor.c:545: undefined reference to `auth_password with USE_PAM on Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kent at lysator.liu.se gcc -o sshd 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 monitor_mm.o monitor.o -L. -Lopenbsd-compat/ -L/local/pkg/openssl/lib -lssh -lopenbsd-compat -lwrap -lpam -ldl -lutil -lz -lnsl -lcrypto monitor.o: In function `mm_answer_authpassword': /local/pkg/openssh/src/openssh/monitor.c:545: undefined reference to `auth_password' But auth_password is defined in auth-passwd.c, and the whole file is surrounded by #if !defined(USE_PAM) && !defined(HAVE_OSF_SIA) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 03:51:44 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 03:51:44 +1100 (EST) Subject: [Bug 191] compilation faills in auth1.c:392 `pw' undeclared when USE_PAM is on Message-ID: <20020327165144.BC1A9EA34@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=191 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2002-03-28 03:51 ------- I had an odd version checked out on this test machine. Just committed fix. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 04:04:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 04:04:16 +1100 (EST) Subject: [Bug 192] monitor.c:545: undefined reference to `auth_password with USE_PAM on Message-ID: <20020327170416.6CCBAE947@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=192 ------- Additional Comments From mouring at eviladmin.org 2002-03-28 04:04 ------- If I understand the PAM code (none of the PRIVSEP code has been made to work with it right now) one should never called auth_password() they should be calling auth_pam_password().. So in mm_answer_authpassword() function it should look something like this (untested, and unsure if any other PAM tweaks are needed), but I won't commit anything until someone says ya or na for it being correct. passwd = buffer_get_string(m, &plen); /* Only authenticate if the context is valid */ +#ifdef USE_PAM + /* Do PAM auth with password */ + authenticated = authctxt->valid && auth_pam_password + (authctxt>pw,passwd); +#else authenticated = authctxt->valid && auth_password(authctxt, passwd); +#endif memset(passwd, 0, strlen(passwd)); xfree(passwd); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 04:11:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 04:11:37 +1100 (EST) Subject: [Bug 192] monitor.c:545: undefined reference to `auth_password with USE_PAM on Message-ID: <20020327171137.D9DB9EA52@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=192 ------- Additional Comments From mouring at eviladmin.org 2002-03-28 04:11 ------- Now I know why I don't cut and past into the comments normally. the correct line is: authenticated = authctxt->valid && auth_pam_password(authctxt->pw,passwd); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Mar 28 05:00:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 05:00:17 +1100 (EST) Subject: [Bug 188] pam_chauthtok() is called too late Message-ID: <20020327180017.D5C1FEA64@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=188 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-28 05:00 ------- The patch I attached earlier fixes the pbug wfor keyboard-interactive userauth. For password userauth I think OpenSSH should either support SSH_MSG_USERAUTH_PASSWD_CHANGEREQ or not even try password aging over the TTY session as it does now. Implementing password aging over the tty session is a *security bug* if the underlying password validation mechanism is Kerberos (e.g., via PAM_KRB5) because Kerberos cannot authenticate a user whose password is expired, yet by the time the TTY session is setup the server considers the user to be authenticated and then client is free to open any channels it wants. Cheers, Nico ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From f_mohr at yahoo.de Thu Mar 28 05:04:14 2002 From: f_mohr at yahoo.de (=?iso-8859-1?q?frank=20mohr?=) Date: Wed, 27 Mar 2002 19:04:14 +0100 (CET) Subject: (Patch) AIX SRC Support Message-ID: <20020327180414.66199.qmail@web20504.mail.yahoo.com> I've added System Resource Controller Support with Socket Communications to Openssh. We are using this code since 2.9.9p2 on AIX 4.2 and 4.3 without problems. I've also tested the patched OpenSSH 3.1p1 on AIX 5.1. It's mainly based on examples from the IBM Redbook "Writing Reliable AIX Daemons". The SRC request handler supports START, STOP, REFRESH and STATUS requests (the status part might still need some extensions, i've added it mainly for version checks) to register the sshd as a subsystem use: mkssys -s sshd -G tcpip -p /sshd -u 0 -K -R Frank __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Ihre E-Mail noch individueller? - http://domains.yahoo.de -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_3.1p1-SRC Type: application/x-unknown Size: 11425 bytes Desc: patch_3.1p1-SRC Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020327/07f6f79b/attachment.bin From mouring at etoh.eviladmin.org Wed Mar 27 17:23:00 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 27 Mar 2002 00:23:00 -0600 (CST) Subject: (Patch) AIX SRC Support In-Reply-To: <20020327180414.66199.qmail@web20504.mail.yahoo.com> Message-ID: Assuming the patch is accepted. I would perfer to see all AIX-only function calls migrated to openbsd-compat/port-aix.[ch] otherwise it makes my life extremely hard when I go to sync the source trees. However, I personally dislike the idea of embeding SysV startup concepts within any application. It seems extremely unclean. - Ben On Wed, 27 Mar 2002, [iso-8859-1] frank mohr wrote: > I've added System Resource Controller Support with > Socket Communications to Openssh. > > We are using this code since 2.9.9p2 on AIX 4.2 and 4.3 without > problems. I've also tested the patched OpenSSH 3.1p1 on AIX 5.1. > > It's mainly based on examples from the IBM Redbook > "Writing Reliable AIX Daemons". > > The SRC request handler supports START, STOP, REFRESH and STATUS > requests (the status part might still need some extensions, i've > added it mainly for version checks) > > to register the sshd as a subsystem use: > mkssys -s sshd -G tcpip -p /sshd -u 0 -K -R > > Frank > > > > > __________________________________________________________________ > > Gesendet von Yahoo! Mail - http://mail.yahoo.de > Ihre E-Mail noch individueller? - http://domains.yahoo.de From louie_lei at transcanada.com Thu Mar 28 06:00:33 2002 From: louie_lei at transcanada.com (Louie Lei) Date: Wed, 27 Mar 2002 12:00:33 -0700 Subject: Problem with ssh-keygen Message-ID: <3CA216D1.AA836096@transcanada.com> Dear Developer, I'm having problem running ssh_keygen on my solaris 7 box. Can you please tell me as to why I'm getting this error as described below? I don't have that problem with solaris 8 that runs SMCossh 3.0.2p1 Thanks in advance. Louie # /usr/local/bin/ssh-keygen ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open failed: No such file or directory Killed # pkginfo |grep -i smc application SMCegd egd application SMCossh openssh application SMCprl561 perl application SMCprngd prngd application SMCzlib zlib # pkginfo -l SMCegd SMCossh SMCprl561 SMCprngd SMCzlib PKGINST: SMCegd NAME: egd CATEGORY: application ARCH: sparc VERSION: 0.8 BASEDIR: /usr/local VENDOR: Brian Warner PSTAMP: Steve Christensen INSTDATE: Mar 26 2002 18:15 EMAIL: steve at smc.vnet.net STATUS: completely installed FILES: 25 installed pathnames 2 shared pathnames 4 directories 4 executables 247 blocks used (approx) PKGINST: SMCossh NAME: openssh CATEGORY: application ARCH: sparc VERSION: 3.1p1 BASEDIR: /usr/local VENDOR: The OpenSSH Group PSTAMP: Steve Christensen INSTDATE: Mar 26 2002 18:30 EMAIL: steve at smc.vnet.net STATUS: completely installed FILES: 45 installed pathnames 5 shared pathnames 10 directories 10 executables 3135 blocks used (approx) PKGINST: SMCprl561 NAME: perl CATEGORY: application ARCH: sparc VERSION: 5.6.1 BASEDIR: /usr/local VENDOR: Larry Wall et al PSTAMP: Steve Christensen INSTDATE: Mar 26 2002 18:16 EMAIL: steve at smc.vnet.net STATUS: completely installed FILES: 1349 installed pathnames 6 shared pathnames 2 linked files 85 directories 52 executables 51343 blocks used (approx) PKGINST: SMCprngd NAME: prngd CATEGORY: application ARCH: sparc VERSION: 0.9.23 BASEDIR: /usr/local VENDOR: Lutz Jaenicke PSTAMP: Steve Christensen INSTDATE: Mar 26 2002 18:16 EMAIL: steve at smc.vnet.net STATUS: completely installed FILES: 56 installed pathnames 3 shared pathnames 24 directories 3 executables 302 blocks used (approx) PKGINST: SMCzlib NAME: zlib CATEGORY: application ARCH: sparc VERSION: 1.1.4 BASEDIR: /usr/local VENDOR: Jean-loup Gailly and Mark Adler PSTAMP: Steve Christensen INSTDATE: Mar 26 2002 18:15 EMAIL: steve at smc.vnet.net STATUS: completely installed FILES: 76 installed pathnames 5 shared pathnames 17 directories 3 executables 1120 blocks used (approx) # -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020327/51634220/attachment.html From mouring at etoh.eviladmin.org Wed Mar 27 18:10:05 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 27 Mar 2002 01:10:05 -0600 (CST) Subject: Problem with ssh-keygen In-Reply-To: <3CA216D1.AA836096@transcanada.com> Message-ID: Do you have OpenSSL installed? On Wed, 27 Mar 2002, Louie Lei wrote: > Dear Developer, > > I'm having problem running ssh_keygen on my solaris 7 box. Can you > please tell me as to why I'm getting this error as described below? I > don't have that problem with solaris 8 that runs SMCossh 3.0.2p1 > > Thanks in advance. > > Louie > > # /usr/local/bin/ssh-keygen > ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open > failed: No such file or directory > Killed > > # pkginfo |grep -i smc > application SMCegd egd > application SMCossh openssh > application SMCprl561 perl > application SMCprngd prngd > application SMCzlib zlib > > # pkginfo -l SMCegd SMCossh SMCprl561 SMCprngd SMCzlib > PKGINST: SMCegd > NAME: egd > CATEGORY: application > ARCH: sparc > VERSION: 0.8 > BASEDIR: /usr/local > VENDOR: Brian Warner > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:15 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 25 installed pathnames > 2 shared pathnames > 4 directories > 4 executables > 247 blocks used (approx) > > PKGINST: SMCossh > NAME: openssh > CATEGORY: application > ARCH: sparc > VERSION: 3.1p1 > BASEDIR: /usr/local > VENDOR: The OpenSSH Group > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:30 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 45 installed pathnames > 5 shared pathnames > 10 directories > 10 executables > 3135 blocks used (approx) > > PKGINST: SMCprl561 > NAME: perl > CATEGORY: application > ARCH: sparc > VERSION: 5.6.1 > BASEDIR: /usr/local > VENDOR: Larry Wall et al > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:16 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 1349 installed pathnames > 6 shared pathnames > 2 linked files > 85 directories > 52 executables > 51343 blocks used (approx) > > PKGINST: SMCprngd > NAME: prngd > CATEGORY: application > ARCH: sparc > VERSION: 0.9.23 > BASEDIR: /usr/local > VENDOR: Lutz Jaenicke > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:16 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 56 installed pathnames > 3 shared pathnames > 24 directories > 3 executables > 302 blocks used (approx) > > PKGINST: SMCzlib > NAME: zlib > CATEGORY: application > ARCH: sparc > VERSION: 1.1.4 > BASEDIR: /usr/local > VENDOR: Jean-loup Gailly and Mark Adler > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:15 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 76 installed pathnames > 5 shared pathnames > 17 directories > 3 executables > 1120 blocks used (approx) > > # > > From mjs at ams.org Thu Mar 28 06:25:27 2002 From: mjs at ams.org (Matt Studley) Date: Wed, 27 Mar 2002 14:25:27 -0500 (EST) Subject: Problem with ssh-keygen In-Reply-To: <3CA216D1.AA836096@transcanada.com> Message-ID: what does the command: ldd /usr/local/bin/ssh-keygen return as output? Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Wed, 27 Mar 2002, Louie Lei wrote: > Dear Developer, > > I'm having problem running ssh_keygen on my solaris 7 box. Can you > please tell me as to why I'm getting this error as described below? I > don't have that problem with solaris 8 that runs SMCossh 3.0.2p1 > > Thanks in advance. > > Louie > > # /usr/local/bin/ssh-keygen > ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open > failed: No such file or directory > Killed > > # pkginfo |grep -i smc > application SMCegd egd > application SMCossh openssh > application SMCprl561 perl > application SMCprngd prngd > application SMCzlib zlib > > # pkginfo -l SMCegd SMCossh SMCprl561 SMCprngd SMCzlib > PKGINST: SMCegd > NAME: egd > CATEGORY: application > ARCH: sparc > VERSION: 0.8 > BASEDIR: /usr/local > VENDOR: Brian Warner > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:15 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 25 installed pathnames > 2 shared pathnames > 4 directories > 4 executables > 247 blocks used (approx) > > PKGINST: SMCossh > NAME: openssh > CATEGORY: application > ARCH: sparc > VERSION: 3.1p1 > BASEDIR: /usr/local > VENDOR: The OpenSSH Group > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:30 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 45 installed pathnames > 5 shared pathnames > 10 directories > 10 executables > 3135 blocks used (approx) > > PKGINST: SMCprl561 > NAME: perl > CATEGORY: application > ARCH: sparc > VERSION: 5.6.1 > BASEDIR: /usr/local > VENDOR: Larry Wall et al > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:16 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 1349 installed pathnames > 6 shared pathnames > 2 linked files > 85 directories > 52 executables > 51343 blocks used (approx) > > PKGINST: SMCprngd > NAME: prngd > CATEGORY: application > ARCH: sparc > VERSION: 0.9.23 > BASEDIR: /usr/local > VENDOR: Lutz Jaenicke > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:16 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 56 installed pathnames > 3 shared pathnames > 24 directories > 3 executables > 302 blocks used (approx) > > PKGINST: SMCzlib > NAME: zlib > CATEGORY: application > ARCH: sparc > VERSION: 1.1.4 > BASEDIR: /usr/local > VENDOR: Jean-loup Gailly and Mark Adler > PSTAMP: Steve Christensen > INSTDATE: Mar 26 2002 18:15 > EMAIL: steve at smc.vnet.net > STATUS: completely installed > FILES: 76 installed pathnames > 5 shared pathnames > 17 directories > 3 executables > 1120 blocks used (approx) > > # > > From louie_lei at transcanada.com Thu Mar 28 06:57:24 2002 From: louie_lei at transcanada.com (Louie Lei) Date: Wed, 27 Mar 2002 12:57:24 -0700 Subject: Problem with ssh-keygen References: Message-ID: <3CA22424.2B1B41D@transcanada.com> Yes it is. I guess the : is just a field separator. Thanks, Louie # uname -a SunOS cal-eslog1 5.7 Generic_106541-18 sun4u sparc SUNW,Ultra-5_10 # /usr/local/bin/ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N "" ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open failed: No such file or directory Killed # Matt Studley wrote: > what does the command: > > ldd /usr/local/bin/ssh-keygen > > return as output? > > Matt Studley > American Mathematical Society > UNIX Sys Admin "Quantum Mechanics - > mjs at ams.org The dreams that stuff is made of" > > On Wed, 27 Mar 2002, Louie Lei wrote: > > > Dear Developer, > > > > I'm having problem running ssh_keygen on my solaris 7 box. Can you > > please tell me as to why I'm getting this error as described below? I > > don't have that problem with solaris 8 that runs SMCossh 3.0.2p1 > > > > Thanks in advance. > > > > Louie > > > > # /usr/local/bin/ssh-keygen > > ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open > > failed: No such file or directory > > Killed > > > > # pkginfo |grep -i smc > > application SMCegd egd > > application SMCossh openssh > > application SMCprl561 perl > > application SMCprngd prngd > > application SMCzlib zlib > > > > # pkginfo -l SMCegd SMCossh SMCprl561 SMCprngd SMCzlib > > PKGINST: SMCegd > > NAME: egd > > CATEGORY: application > > ARCH: sparc > > VERSION: 0.8 > > BASEDIR: /usr/local > > VENDOR: Brian Warner > > PSTAMP: Steve Christensen > > INSTDATE: Mar 26 2002 18:15 > > EMAIL: steve at smc.vnet.net > > STATUS: completely installed > > FILES: 25 installed pathnames > > 2 shared pathnames > > 4 directories > > 4 executables > > 247 blocks used (approx) > > > > PKGINST: SMCossh > > NAME: openssh > > CATEGORY: application > > ARCH: sparc > > VERSION: 3.1p1 > > BASEDIR: /usr/local > > VENDOR: The OpenSSH Group > > PSTAMP: Steve Christensen > > INSTDATE: Mar 26 2002 18:30 > > EMAIL: steve at smc.vnet.net > > STATUS: completely installed > > FILES: 45 installed pathnames > > 5 shared pathnames > > 10 directories > > 10 executables > > 3135 blocks used (approx) > > > > PKGINST: SMCprl561 > > NAME: perl > > CATEGORY: application > > ARCH: sparc > > VERSION: 5.6.1 > > BASEDIR: /usr/local > > VENDOR: Larry Wall et al > > PSTAMP: Steve Christensen > > INSTDATE: Mar 26 2002 18:16 > > EMAIL: steve at smc.vnet.net > > STATUS: completely installed > > FILES: 1349 installed pathnames > > 6 shared pathnames > > 2 linked files > > 85 directories > > 52 executables > > 51343 blocks used (approx) > > > > PKGINST: SMCprngd > > NAME: prngd > > CATEGORY: application > > ARCH: sparc > > VERSION: 0.9.23 > > BASEDIR: /usr/local > > VENDOR: Lutz Jaenicke > > PSTAMP: Steve Christensen > > INSTDATE: Mar 26 2002 18:16 > > EMAIL: steve at smc.vnet.net > > STATUS: completely installed > > FILES: 56 installed pathnames > > 3 shared pathnames > > 24 directories > > 3 executables > > 302 blocks used (approx) > > > > PKGINST: SMCzlib > > NAME: zlib > > CATEGORY: application > > ARCH: sparc > > VERSION: 1.1.4 > > BASEDIR: /usr/local > > VENDOR: Jean-loup Gailly and Mark Adler > > PSTAMP: Steve Christensen > > INSTDATE: Mar 26 2002 18:15 > > EMAIL: steve at smc.vnet.net > > STATUS: completely installed > > FILES: 76 installed pathnames > > 5 shared pathnames > > 17 directories > > 3 executables > > 1120 blocks used (approx) > > > > # > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020327/dd1e23cf/attachment.html From bugzilla-daemon at mindrot.org Thu Mar 28 07:07:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 07:07:32 +1100 (EST) Subject: [Bug 193] New: sshd: error: select: Bad file number Message-ID: <20020327200732.91634EA84@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=193 Summary: sshd: error: select: Bad file number Product: Portable OpenSSH Version: 3.1p1 Platform: Sparc OS/Version: SunOS Status: NEW Severity: minor Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: f_mohr at yahoo.de On SunOS the sshd sends "select: Bad file number" messages to syslog. This happens in 2 places: in sshd.c/line 997 (Openssh 3.1p1 release) after generating a new RSA Key: Mar 26 17:53:05 csfauth2 sshd[1474]: Generating new 768 bit RSA key. Mar 26 17:53:06 csfauth2 sshd[1474]: RSA key generation complete. Mar 26 17:53:06 csfauth2 sshd[1474]: error: select: Bad file number in the serverloop.c - wait_until_can_do_something() most of the time some messages just after session start, some during the session, and most of the time after closing the sessin Mar 26 15:44:17 csfauth2 sshd[824]: Accepted publickey for root from 10.70.79.92 port 3427 ssh2 Mar 26 15:45:59 csfauth2 sshd[824]: debug3: serverloop.c 329 select -> -1 Mar 26 15:45:59 csfauth2 sshd[824]: error: select: Bad file number Mar 26 15:46:01 csfauth2 sshd[824]: debug3: serverloop.c 329 select -> -1 Mar 26 15:46:01 csfauth2 sshd[824]: error: select: Bad file number Mar 26 15:46:26 csfauth2 sshd[824]: debug3: serverloop.c 329 select -> 1 Mar 26 15:46:31 csfauth2 last message repeated 50 times ... Mar 26 18:58:09 csfauth2 sshd[1476]: debug1: Received SIGCHLD. Mar 26 18:58:09 csfauth2 sshd[1476]: debug3: serverloop.c 329 select -> -1 Mar 26 18:58:09 csfauth2 sshd[1476]: error: select: Bad file number Mar 26 18:58:09 csfauth2 sshd[1476]: debug1: session_by_pid: pid 1478 Mar 26 18:58:09 csfauth2 sshd[1476]: debug1: session_exit_message: session 0 channel 0 pid 1478 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mjs at ams.org Thu Mar 28 06:57:51 2002 From: mjs at ams.org (Matt Studley) Date: Wed, 27 Mar 2002 14:57:51 -0500 (EST) Subject: Problem with ssh-keygen In-Reply-To: <3CA22424.2B1B41D@transcanada.com> Message-ID: I guess what I was asking is could you send me the output from the following command: ldd /usr/local/bin/ssh-keygen Thanks. Matt Studley American Mathematical Society UNIX Sys Admin "Quantum Mechanics - mjs at ams.org The dreams that stuff is made of" On Wed, 27 Mar 2002, Louie Lei wrote: > Yes it is. I guess the : is just a field separator. > > Thanks, > Louie > > # uname -a > SunOS cal-eslog1 5.7 Generic_106541-18 sun4u sparc SUNW,Ultra-5_10 > # /usr/local/bin/ssh-keygen -t rsa1 -f /usr/local/etc/ssh_host_key -N "" > ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open failed: > No such file or directory > Killed > # > > Matt Studley wrote: > > > what does the command: > > > > ldd /usr/local/bin/ssh-keygen > > > > return as output? > > > > Matt Studley > > American Mathematical Society > > UNIX Sys Admin "Quantum Mechanics - > > mjs at ams.org The dreams that stuff is made of" > > > > On Wed, 27 Mar 2002, Louie Lei wrote: > > > > > Dear Developer, > > > > > > I'm having problem running ssh_keygen on my solaris 7 box. Can you > > > please tell me as to why I'm getting this error as described below? I > > > don't have that problem with solaris 8 that runs SMCossh 3.0.2p1 > > > > > > Thanks in advance. > > > > > > Louie > > > > > > # /usr/local/bin/ssh-keygen > > > ld.so.1: /usr/local/bin/ssh-keygen: fatal: libcrypto.so.0.9.6: open > > > failed: No such file or directory > > > Killed > > > > > > # pkginfo |grep -i smc > > > application SMCegd egd > > > application SMCossh openssh > > > application SMCprl561 perl > > > application SMCprngd prngd > > > application SMCzlib zlib > > > > > > # pkginfo -l SMCegd SMCossh SMCprl561 SMCprngd SMCzlib > > > PKGINST: SMCegd > > > NAME: egd > > > CATEGORY: application > > > ARCH: sparc > > > VERSION: 0.8 > > > BASEDIR: /usr/local > > > VENDOR: Brian Warner > > > PSTAMP: Steve Christensen > > > INSTDATE: Mar 26 2002 18:15 > > > EMAIL: steve at smc.vnet.net > > > STATUS: completely installed > > > FILES: 25 installed pathnames > > > 2 shared pathnames > > > 4 directories > > > 4 executables > > > 247 blocks used (approx) > > > > > > PKGINST: SMCossh > > > NAME: openssh > > > CATEGORY: application > > > ARCH: sparc > > > VERSION: 3.1p1 > > > BASEDIR: /usr/local > > > VENDOR: The OpenSSH Group > > > PSTAMP: Steve Christensen > > > INSTDATE: Mar 26 2002 18:30 > > > EMAIL: steve at smc.vnet.net > > > STATUS: completely installed > > > FILES: 45 installed pathnames > > > 5 shared pathnames > > > 10 directories > > > 10 executables > > > 3135 blocks used (approx) > > > > > > PKGINST: SMCprl561 > > > NAME: perl > > > CATEGORY: application > > > ARCH: sparc > > > VERSION: 5.6.1 > > > BASEDIR: /usr/local > > > VENDOR: Larry Wall et al > > > PSTAMP: Steve Christensen > > > INSTDATE: Mar 26 2002 18:16 > > > EMAIL: steve at smc.vnet.net > > > STATUS: completely installed > > > FILES: 1349 installed pathnames > > > 6 shared pathnames > > > 2 linked files > > > 85 directories > > > 52 executables > > > 51343 blocks used (approx) > > > > > > PKGINST: SMCprngd > > > NAME: prngd > > > CATEGORY: application > > > ARCH: sparc > > > VERSION: 0.9.23 > > > BASEDIR: /usr/local > > > VENDOR: Lutz Jaenicke > > > PSTAMP: Steve Christensen > > > INSTDATE: Mar 26 2002 18:16 > > > EMAIL: steve at smc.vnet.net > > > STATUS: completely installed > > > FILES: 56 installed pathnames > > > 3 shared pathnames > > > 24 directories > > > 3 executables > > > 302 blocks used (approx) > > > > > > PKGINST: SMCzlib > > > NAME: zlib > > > CATEGORY: application > > > ARCH: sparc > > > VERSION: 1.1.4 > > > BASEDIR: /usr/local > > > VENDOR: Jean-loup Gailly and Mark Adler > > > PSTAMP: Steve Christensen > > > INSTDATE: Mar 26 2002 18:15 > > > EMAIL: steve at smc.vnet.net > > > STATUS: completely installed > > > FILES: 76 installed pathnames > > > 5 shared pathnames > > > 17 directories > > > 3 executables > > > 1120 blocks used (approx) > > > > > > # > > > > > > > From bugzilla-daemon at mindrot.org Thu Mar 28 07:27:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 07:27:48 +1100 (EST) Subject: [Bug 188] pam_chauthtok() is called too late Message-ID: <20020327202748.EB9DAEA82@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=188 ------- Additional Comments From Nicolas.Williams at ubsw.com 2002-03-28 07:27 ------- Created an attachment (id=56) Second version of previous patch - also disables password aging in password userauth ------- 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 Mar 28 07:23:41 2002 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 27 Mar 2002 15:23:41 -0500 Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020326173908.S27268@sm2p1386swk.wdr.com>; from willian on Tue, Mar 26, 2002 at 05:39:09PM -0500 References: <20020326163416.Q27398@sm2p1386swk.wdr.com> <20020326141326.D22417@google.com> <20020326172608.R27398@sm2p1386swk.wdr.com> <20020326173908.S27268@sm2p1386swk.wdr.com> Message-ID: <20020327152339.T27268@sm2p1386swk.wdr.com> On Tue, Mar 26, 2002 at 05:39:09PM -0500, Nicolas Williams wrote: > On Tue, Mar 26, 2002 at 05:26:09PM -0500, Nicolas Williams wrote: > > On Tue, Mar 26, 2002 at 02:13:26PM -0800, Frank Cusack wrote: > > > Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint > > > et al complete? Your solution requires a rewrite of all PAM modules. > > > > Indeed. Fine. So move pam_acct_mgmt() into do_pam_authenticate() and > > also pam_chauthtok(). > > > > Fine idea. I like it. > > > > > /fc > > I'll post a patch tomorrow. As you can see from my latest attachement to bug 188 the patch is a bit more intricate than I'd hoped for. It's very simple for kbd-interactive userauth, and not so simple for password userauth. For password userauth support for SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ must be added or password aging support (in password userauth) must be dropped altogether. My patch disables password aging in password userauth. There's more code in session.c and auth-pam.c worth ripping out if tty-based password aging is removed. At this point the OpenSSH maintainers need to weigh in and I exit stage left. On a different, but related, note, is it possible for SSHD to reject passord userauth altogether if keyboard-interactive userauth was tried and failed? It's kind of silly to allow the client two different go's at ultimately the same userauth just because there's two different ways to do it in the SSHv2 protocol. 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 Mar 28 08:31:03 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 27 Mar 2002 15:31:03 -0600 (CST) Subject: SSH / PAM / Kerberos / password aging In-Reply-To: <20020327152339.T27268@sm2p1386swk.wdr.com> Message-ID: On Wed, 27 Mar 2002, Nicolas Williams wrote: > On Tue, Mar 26, 2002 at 05:39:09PM -0500, Nicolas Williams wrote: > > On Tue, Mar 26, 2002 at 05:26:09PM -0500, Nicolas Williams wrote: > > > On Tue, Mar 26, 2002 at 02:13:26PM -0800, Frank Cusack wrote: > > > > Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint > > > > et al complete? Your solution requires a rewrite of all PAM modules. > > > > > > Indeed. Fine. So move pam_acct_mgmt() into do_pam_authenticate() and > > > also pam_chauthtok(). > > > > > > Fine idea. I like it. > > > > > > > /fc > > > > I'll post a patch tomorrow. > > As you can see from my latest attachement to bug 188 the patch is a bit > more intricate than I'd hoped for. It's very simple for kbd-interactive > userauth, and not so simple for password userauth. > > For password userauth support for SSH2_MSG_USERAUTH_PASSWD_CHANGEREQ > must be added or password aging support (in password userauth) must be > dropped altogether. My patch disables password aging in password > userauth. There's more code in session.c and auth-pam.c worth ripping > out if tty-based password aging is removed. > I believe if you checked out the CVS tree both server and client support should have been commited for PASSWD_CHANGEREQ. Or I remember the converstation and the commiting some patches for this in --head. - Ben From bugzilla-daemon at mindrot.org Thu Mar 28 15:26:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 15:26:57 +1100 (EST) Subject: [Bug 181] Undocumented mget and mput in sftp Message-ID: <20020328042657.07B7DE8FF@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=181 ------- Additional Comments From jason at rndpkt.org 2002-03-28 15:26 ------- mget and mput are just "aliased" commands to get and put, I'm assuming for some kind of compatability. mget and mput expect the get and put parameters and DO NOT function like FTP-based mget and mput (i.e. mget file1 file2.. file#). I'd be happy to submit a patch for this, but not sure it's really useful. There's been work on a status-bar by Ben, but I'm not sure the state of it. Don't know about prompt. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From shamrock at cypherpunks.to Sun Mar 24 12:38:02 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Sat, 23 Mar 2002 17:38:02 -0800 Subject: 1024-bit RSA keys in danger of compromise Message-ID: <00cc01c1d2d4$ad3bc640$c33a080a@LUCKYVAIO> As those of you who have discussed RSA keys size requirements with me over the years will attest to, I always held that 1024-bit RSA keys could not be factored by anyone, including the NSA, unless the opponent had devised novel improvements to the theory of factoring large composites unknown in the open literature. I considered this to be possible, but highly unlikely. In short, I believed that users' desires for keys larger than 1024-bits were mostly driven by a vague feeling that "larger must be better" in some cases, and by downright paranoia in other cases. I was mistaken. Based upon requests voiced by a number of attendees to this year's Financial Cryptography conference , I assembled and moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The panel explored the implications of Bernstein's widely discussed "Circuits for Integer Factorization: a Proposal". http://cr.yp.to/papers.html#nfscircuit Although the full implications of the proposal were not necessarily immediately apparent in the first few days following Bernstein's publication, the incremental improvements to parts of NFS outlined in the proposal turn out to carry significant practical security implications impacting the overwhelming majority of deployed systems utilizing RSA or DH as the public key algorithms. Coincidentally, the day before the panel, Nicko van Someren announced at the FC02 rump session that his team had built software which can factor 512-bit RSA keys in 6 weeks using only hardware they already had in the office. A very interesting result, indeed. (While 512-bit keys had been broken before, the feasibility of factoring 512-bit keys on just the computers sitting around an office was news at least to me). The panel, consisting of Ian Goldberg and Nicko van Someren, put forth the following rough first estimates: While the interconnections required by Bernstein's proposed architecture add a non-trivial level of complexity, as Bruce Schneier correctly pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA factoring device can likely be built using only commercially available technology for a price range of several hundred million dollars to about 1 billion dollars. Costs may well drop lower if one has the use of a chip fab. It is a matter of public record that the NSA as well as the Chinese, Russian, French, and many other intelligence agencies all operate their own fabs. Some may consider a price tag potentially reaching $1B prohibitive. One should keep in mind that the NRO regularly launches SIGINT satellites costing close to $2B each. Would the NSA have built a device at less than half the cost of one of their satellites to be able to decipher the interception data obtained via many such satellites? The NSA would have to be derelict of duty to not have done so. Bernstein's machine, once built, will have power requirements in the MW to operate, but in return will be able to break a 1024-bit RSA or DH key in seconds to minutes. Even under the most optimistic estimates for present-day PKI adoption, the inescapable conclusion is that the NSA, its major foreign intelligence counterparts, and any foreign commercial competitors provided with commercial intelligence by their national intelligence services have the ability to break on demand any and all 1024-bit public keys. The security implications of a practical breakability of 1024-bit RSA and DH keys are staggering, since of the following systems as currently deployed tend to utilize keys larger than 1024-bits: - HTTPS - SSH - IPSec - S/MIME - PGP An opponent capable of breaking all of the above will have access to virtually any corporate or private communications and services that are connected to the Internet. The most sensible recommendation in response to these findings at this time is to upgraded your security infrastructure to utilize 2048-bit user keys at the next convenient opportunity. Certificate Authorities may wish to investigate larger keys as appropriate. Some CA's, such as those used to protect digital satellite content in Europe, have already moved to 4096-bit root keys. Undoubtedly, many vendors and their captive security consultants will rush to publish countless "reasons" why nobody is able to build such a device, would ever want to build such a device, could never obtain a sufficient number of chips for such a device, or simply should use that vendor's "unbreakable virtual onetime pad" technology instead. While the latter doesn't warrant comment, one question to ask spokespersons pitching the former is "what key size is the majority of your customers using with your security product"? Having worked in this industry for over a decade, I can state without qualification that anybody other than perhaps some of the HSM vendors would be misinformed if they claimed that the majority - or even a sizable minority - of their customers have deployed key sizes larger than 1024-bits through their organization. Which is not surprising, since many vendor offerings fail to support larger keys. In light of the above, I reluctantly revoked all my personal 1024-bit PGP keys and the large web-of-trust that these keys have acquired over time. The keys should be considered compromised. The revoked keys and my new keys are attached below. --Lucky Green -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP 7.1 Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x! mQGiBDQ1KMERBADzEw3bXeWGt7u7VcYPYtiXmOsEkgN48BB2DbC4+I0oepSNl6wb jt2J1294sFa4HOpxoHp1n+xCcP5SpXPWW94C/+v3eKljmj+n1amWnskmXIUcpshF Tzn3bgyvJFku+kmIZAlVo7qvCKb8AvsjzeshKlUEImATznM8ii2gRFO3dwCg/7de lcMz5OmUi9jMQEUFCZfDQvMD/jD+81uiZghp1C1WRpupswE23MLIGmFfyHBzlzlm d3ID8P6wV5v1pqK3ElGizFGbFIBdroBc2mu0px7oMUwDeVpLxw9UYgMka0LTXZEJ BJGFkT8zhcG7nlZGDPO44uIGyr8ruS4T6TkgINyp/Ov73fWbACdRTx7srvKsq69J elrHBADZeR9OvU4MctvqpVwpjw4Qc0eXxIbS/SbFGcoHuye0TXOACcuI9yOKz2gz gWJHmf3MWrQ5p8vVdjNhw86lp4EJwnUj7H25rLfYatcD7+VL9U5BvbiYZgi6xSpx vbAAyhvCKIaYCeh3hiXvsJXjmDSsmz8pSGzp+ti+VRa3XGeF0YkAPwMFIDydCmH1 1D08N1rZJBECe5gAn26wiRQO+uM1208FjQLL+xQNue/JAJ46zNHyIaExnFCrQtt/ VFZUSdWpIrQlTHVja3kgR3JlZW4gPHNoYW1yb2NrQGN5cGhlcnB1bmtzLnRvPokA SwQQEQIACwUCNDUowQQLAwECAAoJEPXUPTw3WtkkBX8AoL3HaY0zqwks6U6NFzFp 2v8GwTDpAJ9FMkH0SriG1BJFNPOVC6d1cboVbIkAlQMFEDQ1paYEkJHpt/K8BQEB WIED/2fSfucLhqk0fV7h4zBwRWE3MYlFdGx72QRcZ6Mfp3CSqgEEhs72ZUxPnlvf hs+aGpa1ff4el4H8WtwfQUhCNm594sUgcl2lBQhkQeoSp1SVF/iOepUKPMpIRPbG ZRdiX/HE6z1W1jCuojVQbVyr9oLWKSHyLVHliZz30o5tMvR8iQA/AwUQNDWl0olx n6e2Y7D9EQJFqgCfRDP3JCxfKcPSRh8u55f5rMibjQ4An1V5P9AogyZBAjWC+HKC vMn0rzajiQEVAwUQNEHnt/37pMWUJFlhAQGc9wf/TlPS4e1F2lVsA0Xl+SEzTz2X 3VEG38xQReJxqogMSCt68WvsHYs81k7+HYxO9evVvIEeAQQWsQzEIG803VIrR4ql pTKoijwYVofKhE3QOK00kolP8xEWRbFA/GkvPI1WgTE7Fz+bLuahnUoX6xBNEWcO 0Z8tn/i9FFHf0UFPY7qMEi8cw9qN+P4rLUQ9Bs3oVV/fros2BD6UBQe2lM+Jv2Nm IgdlSTn1CAluY1uLDQhFLlqLAwptJ9pdGg+p6xci3nsjLT7MkjqI6YoT5hgwJeBh j3dD4ypG539wsSEBsVrs+ytivg91cdn6NlUeLVTxX8n8/7w707n1gRXUofA3iYkA RgQQEQIABgUCNOBbcQAKCRCGehnt5gKpc2dJAJwLjr50wBS6ocrl0YFsTgzhrZzr /gCgpUkTTeYPYPHHbBtOc7TypRZSOl6JARUDBRA0wty8XprN4cSo7vEBAcpyB/4h tKK8E6qyWMpZwIZV8wosUr+lMhGqqpI8VNfISFsAu4l24khY1U8aBxYlPe/ImLdH xkOQMSUTsjxDaZWkGWYzPyJcrBS2usmTp3JIQ9qBoQsrRnHQWKp52D1KtgAA4dd6 7WhmmZrQhZQA2mRy385H0u6sT5at+EeviTVPH+g02z7ZY8GlxEvJczCnRpwbA6Lx x+GxBav2sftUZCH9iluh5T8VLKOWoqWdk720036818IZPKvO0Yfrg8lJeIfgF0m1 PKcfuQrUHwYOeODKVO8rpZB5n4sezlwFqXhuBZtKdPzFLbccgbyFDfLuR1Z4QqjQ w9DHfSib118BBN2dv63oiQBGBBARAgAGBQI0xQS6AAoJEGFbaB8sVMj6PXcAn0lZ Ldr3FSl7tT9eah94624IWAPSAJ92wIgrXxhFTJDeGSge9fAcm/mpk4kAPwMFEDT1 +xTWYCk/x74/YhECsrcAnie2TblGja4jtg2RPHeEUGYa7y8jAJ42zXrsBE42JLEf 5OcDnGootPcTgokAPwMFEDVftauue4Ib+69eRBECGpEAn1rR4CSOp+K8vOBfklAi Btgn4OPEAJ0RPACzo8N6Xjjwhg/MtIjpg6EebYkARgQQEQIABgUCNRuhHgAKCRAp 8VB1RpFAZrAvAKDRDCuyfwEDX/hw5j5ioRYlBknAxQCfSwhtJhuuGujC9JRGlqvS okMLspKJAD8DBRA1Y0wlkDMY9wUOyroRAvDGAKD2B/c3lnzfj1aV9huaqqF474TL YgCfcQINLij356NxHq0OU8cXayEwD52JAD8DBRA2EbdDmSJEz0fGxfIRApqRAKDd r6BiqhpZx7+vh/15ClpqboXs5gCZAdzptsQAeHRj9AXVYboBx1QJIbeJAEYEEBEC AAYFAjYGicUACgkQOIzbrnpVcCs19ACgjb0l85Y6RnJImZBJEoge2USBKK8AoJEi 9THemQUsJ9232updxqxwd//DiQBGBBARAgAGBQI2yjkzAAoJEK4MVGrDPt/e/1UA oLA8CTyTSE3T1zXqvB+MS1V0oGJOAJ42jnAYzerUu6f+jvO4XxFuTLjWlIkARgQQ EQIABgUCNso45AAKCRDsTU6t8w7FhYyMAJ4+BYgbjKdrUttYVdHpuGwytjWpAQCf fraiFg4BkzhbL7loY6QV5XixgnaJAD8DBRA2yjkxUBC7hzYSSRERAlkvAJ9iLEzd yPN3NK75IIvMPbgkrxny/ACgr3diRwaFSzdVb0wfmgOQDQ6yrzWJAEYEEBECAAYF AjbKOksACgkQzzXiXv7LrOU3BQCg8tCANqzZZgF2mNZS3iUWfq4CNnIAn1XC9FgT YfyoWdUy9W8KMnJIX7+5iQBGBBARAgAGBQI2yjsUAAoJEMxx1GBG2NPI5roAn2rx ir0baADJuidtj78J4tGs2u+vAJ99h7uQttdoZhkZgqyU612a/zZ6qIkARgQQEQIA BgUCNujeXwAKCRCFB8S80NSux0UDAKCNcl2wY39t+e+Ru9W9jXwI1zOHMwCg9CUk uK8s9N+H2ANkfoCxqkHweUWJARUDBRA26N6D01ThYrym29EBARv/B/4sTLmY3ZCq IWzW+3ghraqeobKcsSsPfC21jUyo99ia/sBQ28uSC5HJHcNonPbDLvjYcV3Evehp in9Rj+HGnug955Lu19PR62viQVqOkljbdIDIaI/ccxSNoEGQRk2lOBapDsqnla6A rcPjiNuCpOM7GHr/vGXlwCktpumFPUGWVZ8SPS9dX2VhNEwmhgpjNcAph2gwz82r U1vvJd2T5wmiGzzDNMpR+7bqcx7KSXGUcT90m22UXmRg0MG6q4ruuOYl3wQtFMY2 P4uHeq/qKAzwIH60drJ0enUo/uyc87cC61znqrKY6/cQnKdBXoqPR69atH6o+UGi 9c7OloyC/LejiQBGBBARAgAGBQI26FWWAAoJEOa/zS8QgaN8omMAoIOBsS3N7Ffp 4p1KkdtPMt1xnPCnAJ9bBqHH21Ibn4/4gaMe96i7eR+f5YkAlQMFEDbpKeGkUJAs CdPmTQEBkVYD/R/f29x2zgFkjnZhlHBzFZko14BA92RlNBHZhSUXMEaNnFeETkK9 XXNOv18kRo37Jj58+lHEFLuaoxFqcmnbKLcG4SzWT2ODOq2GRr/GFoh3AIU8frli vXwsiMxoaDItSpPt+P8ugc1OqL6WTjJ4PSmZ+9jO0Q7AQE74lDxVWtUEiQCVAwUQ NukqAvLlZUzmDiptAQFoBgP7BexRJFpnxYjlDTTPCq5yksQEaY+rtCDzWrR8UyYO BntBjuUVLdaTFqOoxGANoVeFaOyqeswMAs8OsOaXZPGKdlyc4DoF686AJGVuxaDE BnzgNQbdNzSFwrXTsB5V+p0zjTONKH1kvgpVDsTTZFbPSAA1DNKzISNV0ZLrY2JA hi6JAJUDBRA26W5jsLFxg026EJEBAZRzA/94bfWO8ssa0IEXVsCV+3T2p2mtB2mn tmBSMwj2LporcgCjzMgHVGXu67mDvwq39L+OipyDxD26ZnriGMSuQFHp8+qVp85T anNDDV/fjel+KPBdlNKVSQrUPE3qt37b4rAjheb7AjzIAWnpXfmRqG/HQs156aKw jhrH4q6zOJaXMYkARgQQEQIABgUCNwl7AQAKCRA+KCIzXT7WF6g/AKD+sUQk15WT YzXvJYvLaPvvTA18iQCg0/x6ccyEefE9bJGg+MxqEAgjcG6JAEYEEBECAAYFAjdv IVwACgkQz7+ehp5P1tkrlgCffrtHn9POJgk7DBIuyxnigAwNOfwAoINEWxH+idpP FwuKbcvFcWkUut+IiQBGBBARAgAGBQI3ziltAAoJEFIOUY03oJw44fMAn0gJE/a7 Cq/UYUabUvyvTdi888PgAKCML3I9TLXeXw+2hj0ZKt9vnDvMbokARgQQEQIABgUC OI9gUQAKCRCI5rIBP1q1aTaLAKCEavRDo3bNVuA2W9KKQa+8+EX+CQCeOmt7jGhA Xao6hfY5ZsUazWhv4f2JARwEEAEBAAYFAjmOF10ACgkQDXoNi1DA/qfJoAf+NN8/ a2cdSARGg8u0B3V+Vygc/a8t0u8kj9Vg9Ua1qScL2BtQlkHqjh751BQXWofatjAj /KL24w93KLBozOw8LzbCYSLm7+y878U/MH9T6GIlirpMFVvtlQOFDze4hCc788Xn zHzVVGHgrPzGa7BWaAjpvdzGTOoM3mIniQ+5mcaNTFqXUMvk0C6X676MUs+uxS1m m/ulW0TwBCbVo1i1YGohPavWl6PvQrW7VsJ0WLXbJ15/NwTjVEUjZPIJU+D5GmOC EttWv+rUTL5vnp9ZyI6ReBwToru1edQ1OP9Ppk0RFncCQJOYPWGv7uM3yfO+W7g8 ccRB9Dw73WueIxPCe4kARgQQEQIABgUCOY4XeAAKCRAeZBx+BnV9LUShAKCIF7On ikLfyDGhHLu/2/kgf+gVdQCgq7Viwfsk4q31mOyOVOwOhkZpuDqJAEYEEBECAAYF Ajih4FUACgkQ9SFBcfl3M1dpfQCfYHK+h9/YZsefF2QJGvKLNaVPOn8AnR6bxPNg ynpRHUHigyB13mu9E3F5iQBGBBARAgAGBQI4dDh/AAoJEP4m2aXOG0HnYcUAoMmR rF2/HItr1+Kka+6lbrNG2r5JAJ4vQsSuZE3E+xRimB1xr6qmVVcFbYkARgQQEQIA BgUCOOFZfwAKCRCu76+X9zEu/egHAKDeavas1NMuX1APJsH7jGh17YCWggCgqgRS ida/ktYJfxlwsl23chL7/yqJAEYEEBECAAYFAjjhjL0ACgkQWsSxj45E2cPjVgCg yJBzCGUZrFnH1GhuCPF6RFCVOq0AoL25jkVXTyc/EdLRUG7lDeK2293qiQBGBBAR AgAGBQI44ZwAAAoJEPSwcvgraImv7bUAoJnm0XnOOrHmweu8N0dHah7Nllt6AKCr v1WVifQmCGzKiQd455kYTsbNlYkASgQQEQIACgUCOOMDywMGPAAACgkQPYrxsgms Cmrf6gCgtMlCFtNtIs6fsj68EiLj642ZZhYAmgKIbrOTvdidyhsq+eV4a3eMEM50 iQEgBBABAQAKBQI5jth8AwUBeAAKCRDFAhsMZlnB4W0yB/4idRQK30JjleEcPyX5 rgxJTY46Zfawyg7iC2A/k8qBcaJo81cH5lwqJ3iuRDFzXLgohNGNICR2rLrlfCw7 KWJB8yVNgvos+wpQn+juh9NVYcGYBANz8fvJvCFMGCgacb+hulDr4F0Pl2NCsbyS pVSZd/l9hpRTk0iqHhIFGVc2OKY3btblNwsKwYWWy2oEFlnUrSETXO6pjkSSOagU pvuzaIDleTX7A12YZeHK/k948pu3u0meh9+jCUcwjjos7MdyEMaQtNKkCIM3Jn76 EgzHuol5xi2udy6K8SpOdYvDlCPrFXnJh21a+9IiZ2GKl7BPbdWJlVEX0wvsPc/F MuReiQBGBBARAgAGBQI5qVS5AAoJEPlK/7n/lNxvvvoAoNNYUWuz3Fao8aW0yT2P zBsXYrrjAKCFIH2iPDclbCwW3tV0Ox0aDHp9uIkBHAQQAQEABgUCOalU2QAKCRCI HBX3yeGy8aUDB/9nH6D2YqZ6Jt1muO+/APfMxda48A0sa79N6j0yT2SIQfmVYtqR vVbf68LfdRe6mkTBHqwT1+NV+eXW33Yg1+QiGhfLWzJ9AINr19H9qvgYDogsRrEK oBiacUlS2LybQ2CgQNa9gzWWPuAZwimVkR6I90DlyED4DpvTeNc105biOXVv00OL zOEIMuaG3FgjJYRui9+L5UeJckvCZCNlUkwe/B+lxU1KCEKUua0yPs4wNIGkCZjg kRfsVPoItJfqMGiHvnjaK8R3qJ1sQSyI0jQSXHkP+9IhAimB9ZukCY0k0aJKIxx5 IFivX578aC9ZMU+LLsm0oMDjdiXFeFuv0Z/RiEYEEBECAAYFAjui4y4ACgkQZwJH zybkSIykBgCfYZSLvCXsxNGk05eMiNs21H0b5tkAoJEbjspZG73GGimnG/uKjmrK a4LLiEYEEBECAAYFAjrb16wACgkQil7s0484MKWQbgCfdqbPLMBdsRKxpb7w6GYR dNVhE+MAoK83feX5ew+XiYeh9oKPEZbAgjg5iEYEKBECAAYFAjmOHrEACgkQ9dQ9 PDda2SRqrQCgurjcbkQhzbUA9jwJX4oEkdMpnkIAoMKUWUUH9K+OgrWw+ks84Xh/ vJeZiQBGBBARAgAGBQI8HciEAAoJEC2bUW7S8rtMxQ8AnR3EUqsAl8w5j5KrTfxR LeV2yxRmAKCmM8p3qcj+1jzmU3za3ZHtz2E9H4kARgQQEQIABgUCPB3LhwAKCRDS UouClLFScB9AAKDnLan0gSoMIkmDnsp/dQlstxutegCePnfMYDIORSvEQgzPWl8L lKbAawWJAEYEEBECAAYFAjw0d2MACgkQVOJabgRZ/N7L0ACguYpDmdew4IoEITxU Zh6X9i4WfrQAoKWSYMrAYhoSp5WTEhgp317UUjbIiQEVAwUQPHLmPHxdxabQEF4d AQH5jgf/WhJjYvlboWaIRFgw8zlfV9uUNtSE+tvrJ6KQ2ooFFtYGEfT+Nrp5u66K 2hwQmPgIMJ8PDS0JNr38CqnxysipUoHbKWSZKCcw2EBm/eYlp/nHfhfiTx3OTMP9 r2CH9V8gNrqPibeMyxvSF8e6WnYyPI6775SVO9aLmKvsif+vNqKd+mYQp8LtaR2Q GZEmsSUOmRdik75VbZ7baHQrX5jrDNt0WU8+jqvbx6ijhyp8LiLV+y6WrG2qDAM5 MBie3GsoutF2irVCJxhFd3c2q6FeleEMTnTr0OeK/RRei9b4E5Xn9SpyscxDC7lC 7O05qrVgKWxAHVfwjLPAaOVEfg+b+YhGBBARAgAGBQI8deunAAoJEMhTz3PoZU6X PbAAniyIEWAxx0USDvcJJxVfAQH8zlvRAKCh1fj6tEGKMCUtrexJlnLiyB1gVtHM 6/8AAA2mARAAAQEAAAAAAAAAAAAAAAD/2P/gABBKRklGAAEBAAABAAEAAP/bAEMA CgcHCAcGCggICAsKCgsOGBAODQ0OHRUWERgjHyUkIh8iISYrNy8mKTQpISIwQTE0 OTs+Pj4lLkRJQzxINz0+O//bAEMBCgsLDg0OHBAQHDsoIig7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7O//AABEIAJAAeAMB IgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAAC AQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQz YnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpz dHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH yMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEG EkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6 Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeY mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery 8/T19vf4+fr/2gAMAwEAAhEDEQA/AN+iiityDgde+TxwjdP30B/Ra76uC8VKyeLY CB80nlFPfnH8xXe96mO7GwoooqxBSU1polba0ihvQkA1H9stxj96uD3HIqbodmT0 lIkiPnawbHXBp1NMVgooooAKSlopgJRS0UALWfJrukxTGGTUIFkU4I3dDWhXI6j4 ftNM12HWTCZbPfulixnYx6N9M4P1qWxoo+LL62l1qxureZJo4lUsYzuxhya7SyvI dQs47uAkxSgldwweuP6V5l4oaF/EN3JDIDE+xwU6H5Frr/CWuRak81nb6etpBAoZ Qrk9T0OahPUbR0tU9RvUtYiu/DsOPartc14guVWSQBC4CEMy9V7f40VJWQ4K7Ma9 1aUviLG3PJA6UiazGsIR5nlxzgDGP8+1bWl6JaXCkmNlUgAA8VdXwTZ7g29R7kZr ic7nfGi7XMiyu1uWllVmVVOVCr0/OtXTtTwwjlkZ0c4DN1B96q6roEtpF5li4Z+6 4C596x/MuILloLhT5jD5R2Y9c/pVQqa6GVWk1ud3RUFhP9psope5XDfUdasV3p3R xMSilooASilooAKzfEUksXh6+eGMuwhPAOCB3P4DJrToHXmkxnhzGWQ72J55xXaf DkFrq/dfuhEB+uTj+RrnJFZbiVU34BP3BxXRfD1wup3kZwC8W4c5PBH+NZx3Kex3 pIAJPaubjuLLEks4QEndK7ngYrfu8/Y58dfLbGPoa8rv2naA3DoREH2pn19xU1Vf Q0paO51U/jqwtpStrC90/di2xf6n9KWD4gzPIqvZxxxk4LDLEfqK85SV0kZsZJrp PCemNrd5MJ5JEgijydhwSew/nWXJCKN1Vqzdkbl943lgmCvFbXaNzmEshHtyTTYf Eun3kokCmNwD8kg598GuJv1ntL2W3cnKMRzTLZWlmVN2C5Ap+zja6JdWfwyPWvDs vnafI3H+ubGOh6H+tatcz4FMq6bcwyH7k3H4j/61dNXTHY5ZbhRS0VRIlFFFAC0o 6iiikM8dvQo1CcNs4dvv7j39q1/AzlPEihRxJG6lgDg8A4/T9azNQLJq90AWH71x 8smzuateEpQniy0yxJZmU5bPVGHWsluW9j0+4j822ljyRvRlyO2RiuLn01Slxpsi k7SDGZD1OOv867isHVbOSJxcbSY4+C5bPBPAx+NTWT3Rvh5Rs0zCsvCWnAM14WJ/ uxH+pFWFml8MMsdvaAJIpbzG757fgK14HSWQOACQOnbNMu7ea7geO9vIo8n7qRF8 enOR/KuPmbep6CguhjWmm2mvF7m9tirKdpKNjPU56VBc+GrezczW/KxnPznkVtWc E1tiKK4jmgUYPylWz+tVb2fO6EZLSPhR601J3siZxjbUu+D1H2O6cDhpzz74roqo aPp76bZGGV1dy5ZivToB/Sr9ehBWieVUd5NoKKRnVBycU1GBOM81VyLD6KDRQAtF FBOBk8AdaAPI9WGNbvOn+vf+Hf8AxGm6DMYfEdgckL9pQHjA5OOn41P4k2L4kvfs sgCGTdkNnJPJ6e5NHhS3NzrLq8RkYQSGNlBwj7TtJ/z1xWXUt7Hq1MnhS5geGT7s i7TSW1wl3axXMfKTIHX6EZqWtSUcRY6qlvIIrhsFTjNdHFe6Y6iSRkbA45rh9at3 h1G4RhgeYxU+2TWUwlJwH4+tec6ep6kZtI9AvtWsIYyYtvPTBrO0Py9S1pXYfLED IB6kdP1NciqS5AZuK6fwe6pq+wnlomA+vB/pVU4LmRFWTcWdzTHfbih5AoIzz2qv JKXHIHFdrZ56Qu4SkggN357U6FgZG+bP9Krbwjb1O7vipI51YsWAUVmpa6lWLJfP A4HrRVMzEMAM46g0Ue0Qcpo1zfjCQ/8AEptmP7me/jWVezrnofbmukrk/HEnlzaK fS8DfkV/xrVkHIeMbSK18T3UFugjjYK4VRgDKgnA+pNULDUptNvYri1YxvE4LKv3 Xx2I79/zrf8AGdqJ/GLoX2Brffn6If8A4muTfAncDkZ61m9yuh3nh/xd9ltobSS2 U28bNmQSfMqkk4C45xnHWtmfxrpkakxrNIfTAUfnmvOLDYysDGWOeoLf0q0AoJxC o+v/ANelzsdi7rWvHUMlYEUGQtnkkZ7ZqK5sJLSQbmDIwyrjowqncZeIhnx6Cte3 uLTUtIhhkuY4540wQ7Y6cA8+1ZPQ66MruzKCrz60+4e501La8RzE+7fH68d/pzRN LZWkW1JvtU+fuxj5B9T3/D86z7qae8fzLiTc5x9AB0AHanFa3HVnG1keiad4psNR tFllnjtpQv7yN2xg+2eoqc6nYSMqpfwOzNjaJQSx7YrzDIA+lVPtMomVkdlIYEFT jBrTc4z2KQeWQQSc1Wnmz90j61wcOu6pC25byZv99tw/XNX7PxNJ522+UFG/jRcE H6Vi4yNFY6yCVnXaeWxxRVeB0aFLmOQMjnAYdKKjbcZ0y8jmuL+IzmI6U/ZZHb9U rbj1pApQxuoHO89DXH+NrqbUHtEVvMwG2Bfw/wAK2Va7sS6dlcj8fkSeIkdeAbdc +3LCqdzpNunhWDVUUmXeRIGPysNxAxjn071n6vfz6ldmWVsbudo7e34f411xs0k+ FikIS6qX49pM5/KlJtWKpxTucNbXaxMSVJB7A4q2b0bd3lYH+01UFhLMPLy5IyQB yPWnXlvKkyoTuBGRjtV6EWdrlkXbzg7The4UYpjHy1JZeB6mqccrQPggYzzUlzKH ChTkdaLCuPF+qdIzj60ovA55Xb+tUsUqg59faqsK5f8AOicYL02NEeXcg+Vf1NRx JFKQgDK3fNXEQJhVHAFIpagzYwKGbnmkONx9hTT98D2pDNPR9RmtpvIaUrbykBlP Qe49KKzS2HoqXG40z0F5MtsEe4dMk1zXiidBLDHCR5oVt+0dM4x/Ktu7nW0tmlfo Bke57CuIvZpJneZ2y7EkmuainJ8xpN2VhjRSwSZlxkR7uoOeOK9J8BKup+FBaP8A MuXjcH0PX9DXmUaFrOUx5baAD6/54rufh1rdtZ2r2czBCZd2e3IH+FbVfhFQfvnW eHvD0Hh60MUIWXUJhh58Y4/oP51R8TeGbDU42SJljvo13ebHFkH/AHgO3vXQpq1l INqyjc44K8frWb4m1xNB0YPb229pX2Kx4Xce5PesE22djjFRt0PFLyOa3uJLadAs kbEMMdDTViMijb1rZ1/UJNUnS8nECXCrtYxj7wHSse3lKvt7E12Jux5zSuPSzOMu 2PYVZijVeQBxxTutOQYWi40kLtGckcik75p3amEgDNIY0dCfXNR59+1SKCVFRNxk expiGpwAB6CikH3j7ACigR0viG9Lstqp+VPmb3Pb9P51z7AOCPUVbuJGnmeV+rsS aqv8jA9qiEeWNipO7KpHlyB0HDdqfb3j2t2sqjA/iUdxTJSdw9M0iwGVuOMHmrau Sm09D0rRLuO5tgo2gnB9zVnxlAL7w+CH3NARIBnpjr+mawvDWlXn9nrdDGwEiPnJ I/pzmn61eyw2c0cx2fKQRnrXGlaWh3XvDU4mc7pdnvj6VG8TI4A5z0piud+7qa0E +4Cw5xzXZscG44cKM9eK2rfUdPihhU2qu6IQ+6EddwOc55+XcOemRWKelFrPAsjL ch24OFTgk4ODn64/DNKxR0SeJLdBkWKxuQQTDhBy2enPGBj8TUEuvQ3cwW7gzFgk 4QNlyQT36fr9axWJx3qN5Y/KCBQJA33snJH8sD+tFgZvyy6J9lIhRQ5hccoSQ27K 4/D+v0POXODLxwACahkkljbiQkGkkZt6f7Q5p2ESqOD9aKQckKPqaKAP/9mJAEsE EBECAAsFAjmOEv4ECwMBAgAKCRD11D08N1rZJDLwAJ47iss4Ddf0eJp9ubL9MkAW VHpvUACePJ9pIlrdVaZpCIbFw30japQQ3dKJAEYEEBECAAYFAjmOEzQACgkQhQfE vNDUrscFGACfanFPmIwy6GgrUYjRgBVXBmbhZlwAoI44nH6+do3m7BcbV6XRzLuk NfUGiQBGBBARAgAGBQI5jha0AAoJED2K8bIJrApqVYkAoLfbgfWyhX/sJZhYxN3a VTnhvJqNAJ48NMav1AANBpwIXK5oaaSvQhVykYkARgQQEQIABgUCOY47bQAKCRCx N51Zk4PeBpXBAKDaXABCd16mt5yFEkIuK+Uy3/LwKwCfTzHU1jdLNBd4j1RqTndi AgbTwECJARwEEAEBAAYFAjmOl0QACgkQdBl3GAtrPb1CbQf5AV/PgOO1Osy2ffBG RtiW3psSOljVytmFO+0BzP7funKpCSd+3sJn1fdZdUvlsN0tB56OA/Mtx+OHFLeT DakJLGZpTlYX3PiUnbE2DCiEXq3JNCRTc0Ll8+XrYMD6ymohsGlLfBWoK5/GBHif r0xnwrMu07lPZQiaEWcPUWEA3QJtUvhHtW+vQWlA09BxuXJ09rUHuBgHQt3jWAb2 0VZ4ay2IOTT09jFSc6VWeqvr2bl7Hth+8UZd7G+L1QR0+bWmphvYpgnJDaZKbB3t 9dsjjMBji8N7lYcgt5ond4uXm+3BXHI83ewhs3rrCNdl7tg1Pb9yrBq9u5+3tRs/ ey7UtokARgQQEQIABgUCOY4pWQAKCRCI5rIBP1q1aY6mAKCJMIcPrmwrwbtiuNw6 KweTr/h3KACg6s9+cyWJoNiBRMGmUXsi+QwQdTuJARwEEAECAAYFAjujhowACgkQ xQIbDGZZweFB4wgAoFPxTdpqpnoeguRMvoUW8TyT2DFw7dc77ubl4R4FWv3P+zSK fkHPv/DgyPJuL6IRxt2zcdPMYBkGw59bTNRSUAShhDXujMjzzN/2vMJv7r8ACTFU 2ER0gNiH1n/dYz2LL1olnM4e7qNbbTJ/VIj2JREmVjwW4M+uOVDFO0N/z8Tkaw5y NhJIiaV65capYNIObnPGrsjffeNF3D471clKG2acQQFH+jV9O891Q/gL2AuIf4lh /SuuFmf0f1uEf+6X6vws5e8ScllIVmF4GhJEO6Pg5Tw5Fu2fp3Ffq8Ms5yBdX2pV O3gWhwAh2mJk5ZtuzC7IOmAvgLvBMUPi56B5wYkBHAQQAQIABgUCO6MItgAKCRCI HBX3yeGy8Th3B/9F4RjVWvGP5oI4t6+O9VUikJRQHyqQJUmeVDTHjvetrIf5nKlK nk3a12hW6PxYmxfyauJHLbg55oXuNQMA8guAzrH9Xeat/RhpFdBAWyZoATw2OgHC hte8WdTkQ/j6FKQ8un+2N2OLhNIwJUVTMGvr8FpK3CiTQPNXJzdwBaZ55HOh5pje NS1NE+kWDrjsJb8PX525fg73zw6JV1xWn3VTtWQsWVtvYJ+qh9OYMTUnCpvUDG2X R2EX10pM7czvhs43N4BrxYtfrY/mHQeNKoRhOEkx6wKARktX4AN/9WWrTCYG5wY/ tDyY+AbyRo+tbcjiprX1bGWvWy8SGWgd0YIoiQEWBBABAgAGBQI7owjeAAoJEJoq G0bwRSuqQOUHz0mqIndUoImErQkilcHWBYdsbtsLZThqBxh+Ago2GB/zrVk9nqec QqSExd1VCRjiMt30thmmGyoI06+FLgP8eRhlrJK1vfpS++jFBrQoYTm2/ROhiqaM HSaAvNTTbQJ8PiEBxSGNvT/WTKFDu7KVEzLvxzdzxfGpUXRrsHykC4jXoYyFz/z1 BKRyTovSUN8MLsl6PbUZ3YuErUXS64qnYBcHRPrM3K70Tb3rFVYuRQ5oBLZ8kYiK wzim/tGzQAQcKj+Md3r3l5GeJvdJASefN98JHpSROQpdL/UdXwpMF2eLljNNGO5u e2cCeazekN/UdIDaehz41toAH1yJAHwEEAECAAYFAjujCQQACgkQ37fQKGvIT0XE AwL7BwQfXan6pKSIGT+QjzwLodVundOHzvWhOlzB+tliZ3VaRRByfKR5To85QQxw eVcCdhLLm50NwG45at98XAlGCxrLfXXS4Q1nWcYWzGcToe9rxnoBkGAgOLhdbZMF ZIJTiQBGBBARAgAGBQI7ouOYAAoJEGcCR88m5EiM++MAnjR2TSSXYnhknMQ4YYvw pgErQYz7AJ9E8SPgG1Scddg6MzY86uopAuIWYokBHAQQAQEABgUCOb6B5wAKCRD9 +6TFlCRZYTMVB/43IHrec5B9kJs7HyxnUneyWMplFLoCJdmOEaQUK04My8olTFB0 Y5hWj6JRc+N+Vqm+eLyms/zlhjXa2iLfpYAiDEPgorzMMRDHPFHLxYgSNO0GkSWG VieCt/xe5+ve5p0Kq8wkJGwjSG/kto1wxQj34m04ZzGQMNbShFWeT59TFo5YOOPV iZzMiBgTRPmjaYR2SomlaE4BsFqSrb2/fUc2is43jqDAxBKoB2Ja232fsrq2LAny p8uv8cscwnfshkAFNwXryi37EkIzoJMfecK2kFbIDXWJXGGs7wyqNklttWIniMV7 4VnABkBMZlMbUS0YLkaaBqMGVLH/ZZKoH8IBiQBGBBARAgAGBQI629ciAAoJEIpe 7NOPODClgfMAoOL7nXzK1pVByI33aBWdOP1BRynvAJ95NFT9umfxjol87BK5zduw DybB34kARgQQEQIABgUCOtvXVwAKCRANtdlcEzkPuL39AJ9E1bV3xFTNsdp4BX6c pO8Gv8RHmACfaHUf7/ex/XRcyrCWMNbxE0Ca0PG5AQ0ENDUpZxAEAPA9wzX5e35T Le0ZYBJSidn0zLAPUhM9cTT/slT7ljMKpA9t1P+rsqaM3G1EiIk4oJIn4fB+2i2/ ZW214yzBS2Zof/UkDexEE0o4DmLKOKbukOsMKmqJeWzyMMBm9jy3Tu0brQiAz+q5 x1PeLi4LyGOZBkrQWcMbttmdkawoIMXlAAICA/0XhUrrUx9uv085SHMsvm2WzpD4 M7piDIhvJyd9hb8CBes0xfGf2hkE9slwfXbqpAjjJyUewYvbrv/CTvrrJz0t6oml ZxTtmHUZM+DSDB/VGb7OxS7xcLj6A/FN5nC0zWJTYQc7rjBAwklCKYEk5riqezs0 Hzs5ZgaD9+B4K4IBzIkAPwMFGDQ1KWf11D08N1rZJBECjXUAoIFv7hcaoFk6yVj5 2nDDtOEDkUUMAJwPVU1gwFjE/dr9fvm7rXW+muNgJ4kARgQoEQIABgUCOY4esQAK CRD11D08N1rZJGqtAKC6uNxuRCHNtQD2PAlfigSR0ymeQgCgwpRZRQf0r46CtbD6 SzzheH+8l5m5Ag0EOY0M8BAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/iYlR859jj5v qIJBPceA7cf/Qmfcms90l5vbnWvJ//LM+w7dRmCKcDW4zF0NcobhaGHmkm8hia9O GiOYN/oBWnnxOS0xRodT4AeGqYNqHQxXxq8GlsnF4Gn8Oph8OPiWGYoWbdAocuIc /1h2uwGz8gVMmhLN5/bWJCIEVBo86Cr3bHCh4J5BakHnXZnh/nTT8WYSUD1KeEW5 uA8tnIR3EEocBTcNI2NBT7s0gPQVuIZ8UVQeBV6EtNnGk2t7v5Jd3k2066Twp2Ib GI8qL7a+yrVA3xeuZze8wN7vKtBmK9iFUHoe4mopXkw0A71DQlP1wDOLF2FXHptQ zOzJnHEOZzeJAEYEGBECAAYFAjmOHp0ACgkQ9dQ9PDda2SRfcACdGk867sHTVpbI WpEm3Td/rDcm59YAnjuwOWK3RrU8AhWpAbUVK8Z7jg6YuQINBDmPr/AQCAD2Qle3 CH8IF3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSG SfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJ Zv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgN RR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv88 4bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsi GSa6q6Jew1XpMgs7AAICCACa1fNUPevfIpEwGq76+jvzofKx48/HLLmio0+biAfL iEm84g3DFtTJ+89TO/fvPq+711bet9II/4TMVu6ELQvRu1REkR89usbK/3sASrUA n01EiBH9QJRzG6NMt1F3vo0+juHIxKelAKV55KigGlb6WCwf+2Q5yTihPXUtWUOd VspBF/AEbd+5KnN15K65H7+OTm5vgPswGuwNHA/thBQ/dIBUzwy8GS7uiuDKO3pJ FmWOCD/9zHA+hbaSBHy0rMJG/M2u7D24wbvPaUbk/g/fHCV8meojkfngi4DINynI 6xmmNSR8XcZrjZVJKjTaM66lVbo4YXCd3eT2J5sTswUBiQBMBBgRAgAMBQI5j7We BQkB4TOAAAoJEPXUPTw3Wtkkud0AoJP819YEQ2XJueIjcqZFv7iNDcGrAKDiafXG Sid4T9Kx/HUHgnclV1e5NbkCDQQ7cONwEAgA9kJXtwh/CBdyorrWqULzBej5UxE5 T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHTUPj1WV/c dlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq01uejaCl cjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O9vPJI8BD 8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcKctaGxAMZ yAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TILOwACAgf/ Zg1EHGeCkWta0i9LgQGdGF/L/RpMtyMcF+K6REzsUy+fWXZ7yTOsC9PGkk9mjZSZ 79ioZpsP0Dhd8K2lq48mtpg/1IPr67TuoG9tDDA0ecUCs+IFnj6bgf1/S9nQfOsE jaKzijWwVEY/RiJ6BxkD4XEHGhg641OClEsaCjre0xoYqHo1DJNuuME8NZ5dcPOi 9wZ7OcfW8Kykp3yg4F2v/w2V7nCURK9/1OgNB1SaN/xUw53wlcu+XmwvgaDp7WOK 0XyGlzdz8oX9vFsmoPixWLayQ9glCL+Zl/PVGye+X7JEcGS1k4qB4ZESy+s8lTwi YBY4vp+fTgrvcpLse+CgL4kATAQYEQIADAUCOY+1xQUJAeEzgAAKCRD11D08N1rZ JAnJAJwLiOgybuFBpChsmNL1811OA7PbVwCfR/k0uEpBwOh7HIeHzaM2j7P53Di5 Ag0EPDOQ8BAIANKRLYV2aPaaPULsb1e/vbysTVMhcsZGPDIIsY4RkwXyLqJUstxB /uYBoHJuj4+8TiqDqUn5QPC1r/t07A23zlWe7yG8ko01jEGxpT0PQw5iWGXADWr5 HTMnnumbIF1Em5qfMPj5A0MFwwzGnaQe5Go1jpEGi+kz9qVdppdJ6zlUARgpT4Dq NPo+SpaQjRjoYvWDj5oEUqY9poi4bNJyjTk1D3Sf2KYdwemQHQBB0DgUBn4AzN91 pVqSqlKwDubwOdKdM+dRwlhhQ05tLwzQPZiTUECQaPw9wg1hry51vz0NRXU7M9uW +/eVn+SE+qY7TYtx/WUwmRyzXyYTHsuMxV8AAgIIAKCFfnoritTW85IdG10V1BJI 5TlhoTkMotN9VsacshjiMDkUhqF58vSQwmQIa/e0uIqlM9yXQFoyn6ZFC1QJhJG6 5ubtdNuOtYJBfnt5dsKZOWn9gd8YbQJIofvzWjMDLSGdWhFgKuE8e4e0vwjExwyJ 5541RbnYBdTEbkp++vJMS7UcSyXE61vUYlwVnQCxs9IcYqArFUkOBmq8JtQJPPO6 JCCOwoFLVK598117QkbsBzZt/q1PbTxXuoVm7Mupr3QDHpzNMBpyNPshCEUIizs1 pukGjy1wxuQj7LDCmcawKrpusEz8tslLK8v/R7bDA4vICh6/6rhSLqyvFiEBKRCJ AFIEGBECABIFAjw0g0gFCQL/SQAFGwwAAAAACgkQ9dQ9PDda2SQZEwCg7ws3YMZl xxpu2jR60OfRcwvvGZYAoKOZNe3FQlqqYw8mtsrpxqBLV+6umQCPAitWLv4AAAEE AJQxaXRGZ5tPk2b4JcXJjLJ02B3B/F77vIIg6MITwHX3VzXmWy4jHcpc1EUwA08S Hnd8Lio8E+1UFTTDSA2d6Y9wRODy+z1KxQ1PF1rCyZQbHbPhM60pSB+5WzkxxLq3 Eac+bUGUNw7pdRADqdSWeUrriPFUGv3aGQSQkem38rwFABEBAAGJAJUDBSA251hO BJCR6bfyvAUBAYb7A/98LlrYO4r5mFo7NWJ4/d6OY/GHZKvAViJBog6whRgwVxWj COBCA9u7xOlaM7p/+nbv1xLWK6OcpiPil1kNHp2T0SLXTj3ioVS0Bbda7641r/vE j9zOKwpkk1ImcSxFu0ikp7SzoYqV6vYyY+resbmLInlIYjaCg8Jx5aqyRBfU/rQh THVja3kgR3JlZW4gPHNoYW1yb2NrQG5ldGNvbS5jb20+iQCVAgUQLi+9zwSQkem3 8rwFAQGLEAQAi7oJiEktkqqIT0UczN4jqyyRX9l7AdH01tMH1KHiNTAm/M8NDdss nu1rCuwIFOQFJYJUTQxHKykTxFi9qAZszTnsrBJMEaY+slXfwjsBt+xM+Ll9gcDA A0dwDQUWmUBq7iBpxs3GFmGmscJCSOYzS5joEIAgHy+88iS9VtexNzuJAJUDBRAy bN11t2tvHcaqkuUBAWTYA/oCLXU9nj1WLxuWMwh3mKmBlR7BfFWCOJmDrgmHWSCd L7PO/Jx25SEvydITCx1RgIbeQGNOJa9uP+DbJzhYi9c4Dt+FmzcBtvwYW35aC98k PNOZNKVFXDcHOjxoqS877ip49Qn1DzREM8I3CE6hl27SaMJgoK+X60Rh/hvJAEJz uIkAWwMFEDG7ThwSwC+KjFpLZQEBx2ACKwSydvLWxLDYDNhjVNdkAGM7e9rJHa1q Z6faOObzyBYQSm3SZ+XsNLh3wpgTXn6aVTNvVPxwlzAdNlvylIGPSkTo6WTxt3CJ AJUDBRAxvHve8wXb6sBT5R0BASFLA/9HH15JuOpgy3MKnUh4KDuQOF6itWKFjJC6 hf2zcKDLmXAGL8z3hHt3IM25nztihF5tYkLE/BXG2HGzvP85l6abiMdMw/QyIMMW mrdm8wUpNVMfQOsnXVxzcDxKp4hDmMeZKwHBxTVOcqjiicWBVhKpv9aqSqfQrw+C QnGw4L5rJokAlQMFEDF6ceH1mUpZYXxtuQEBZosEALl9GvWeSTpsA4zrarPeC7Vc RCvtJL+Yc05MG72voWMZzNPuRiZoM3HBce5EoD6D/TaCy25lWdEY5OmMSYoyLUis n4GaJ0/jhj2eazB0geBzlQxZlciVdqhsKsnoUjuPM4dkcODy60kgVDS+mQOago2U CERZ0UTqxFh+ARbTS603iQB1AwUQMXpxnUjbHy8sKZitAQH4GAL/Thjl19k/kBqK FBIM9KWaFi3XzXryFfIkLjxLbl7d/4ci04pQbBOLDIEm0eZ6DiQKAT4QLKfyrAxS 11iJ4MRc8DRvg3KrS6fMjtHjEiMAuquMarmMYiR61PQbDY7hH4AFiQBVAgUQLw/b 17UPMZ11+Ju9AQEp9QIAsmpI+cBEEZorXYC4VnvUHYvNPuDqTvUUM/GCQTJB0Rbu FfCuarosQEauUS+h9yo6bbyzjEKjcLBQe1DLg+I/ZokAlQMFEC8Ib+lxzuIYxqwX oQEBZokD/RC8U4UI13w4itqgpRbZf4OZeQjiQxO5bQJxZsJlo9yagU9CFyrbXNSv zLb3hFnhFBh6J4YA4Agq8xKfODWf1R3Vsu5kGH6FHmSe1ZwicsUvwBvMjS8dkxgu IV+mZWL4hb+udVNvJ8svafnGmknAlQVnsBhrjxw46k81fPxB4B4XiQCVAwUQM2q9 N6HBOF9KrwDlAQHrsAP/SzNtSR9i3Kj4OMe4gbAnqmFOaMdyFY3AcKh4xXNMTkvO Jf6Iht10D+s6i5K/nlgsJRw/AZCdzKbQZiyrxi6JTHnMsB0lM+WVFumrjSnx0CWH 779ZS2dG3Tf2HCoHR98yPbkkNPYJ9Wdb3MH99KsNx1MERVC/rM3c/o8ECNS6/QOJ ARUDBRAyklgOCyZML+fkkMUBAeCkB/9HK/xJhdmKVxfegCmQXefOKYJXpqxhKViI uumKyCyVfvIn/0aKmnBL0g5DVKbetyV9bE2YZ+w3163bfYcXzS6ocdM1tGma8yXp HhziA3e7YFLFJ5x6ysklaqVV99h/f64e7bislsnJyfSSkuFg9FzB/FpiE3r1zu9a l1sFSOtszqQJbYSOXRS5kAf0xaYABdXs7dy7mzZs5d7Bk6pWfHoZ7fhZDSlB0d+B GyrPYjEeO9YVdk3k0IGqBOa0rWFjVOx9lS2hfCRAKM9PjD7aHjpWA0s00WM/m1Al lxl9bty18/hMT4VJmLaRowj+bctXcuduPdtAuhlOaw19Rk4XBb4LiQCVAwUQM93c ZR7EGV/WGT3FAQFIlwQArN6ZnzGQiWEdn8wBABe06P24y+YNL/tcOikBw5Is6M8K zdC9Y/Pc8AtKokUwXW6LQAzjFgSSCedpjcDV8So+/jibhzyuD0wVZM0exewFB0ia eIjVVMAVqLlZrnGw4JX48EIsIlzunbr4xdXh0QSjTlHB7yF2UOA8AhrAPCIdK0SJ AJUDBRAy/lUaL9/L6+SozE0BAbpQBACeB5X6kt5NPj9ZZfdsnHmCEhUPLmmT14C1 mTrQ9f7oGYC/Tt1HSgl172kuhuY/3sLqFYBf9sYPK/s9fpO6ztPSGchyzFSjtYou 2uVG+/DFCoMLRFt94AK75rWLywWHiRTOD0bq0UMh8osHixK75jaVEytsi+OBxHY3 PvRFoKchRYkAlQMFEDKLaYY7zI5sVceLDQEB5kEEALPzR926o0MxtbIReK3ICjww l0NMIDO8VKiCMqu29IDs/Jka09PYfRPoQHbX5ZD7qsTUIuRgoetBl1zEWk+KGf+o POMd9uUAN5/czxHUSjxIiCsVHyh9aAo5KoQwjXK6rnrLG+A9gHqPZmhAic4NUm2C zuEhVJV1QYC7BsavRM3AiQCVAwUQMtLTwEZRiTErSPb1AQHB7QP9GiuwBrdbs1JW uktsolD3dDzC8DNI0Lqa6E2pAyDDD2LmMwXRRegbvmMdYIZSEtUZhle6C9MF+TX8 It3TwsBKafH7AAn2MKfeFA6fZQdZ+iMoUzo1axvQXaOShB20pt9RoDMNOAGYPyuS vhyhmvrWTolQNs75nHCkIMOgasugRu2JAJUCBRAwdC8bUjvM1mAGTLEBAQFUBAC0 IIdUsirhqwdWwoDHVpwYCpdqcKgrszBA8fxWf1VgICmAElPvRjaXMPqny01Oe1E+ 1aXGM0DDuQj6FiMMZ52HiKogOt9S8o64uUXFHKnqq1/ohRPtSB6kCFfKPotNUX38 OTqMck0MKfNryYpLtxsSzQ3zDJiqQYIP36v+cI+TZokAlQMFEDQOxyRY3z5u/PIL fQEBGF4EAJ4lMQxjrIlTV/68cVVI+dEDgU0wpSzNPBxIq7WOK5BUvlJjbZU/hpVs G89Ot27LFR41BCO2SABjnJeWHkjVixMwGa4w99QqULd3GGaISHSGTZEY9IaRfBLC ZeYlGHd/9m7Ck3pCBwkBSVB43bCrAine7eGP2SErlfZdps0+WouUiQCVAwUQM/sE OHDIWC4O4jotAQGzCAP+Kb0R+42ZDW3Vci1i5BRlVL1v+ZrhBFUF6rQAL11RID/N nWbIso4QyjO+zJ69owGmtaMXRKL/TMswh6jk5Mgi1L8C+iwzmxMH1QhCPFv9OA9E AedmMb87RyupnuWwc1t8+mhu1Pqptkh5mzlChJriSho7mjRD71D7ZO+B/Ou87byJ AJUDBRAzwoLjhHIe+GLFgQEBAQKZA/9GCSqsen7GOn8OTljfiTu5B6VIQJlqqa3u WS7BHTb6u7fIoOxcqqOjAaeSxg2zvWHtyJ5H0D5O2HmvogxCKWNvFdUx+VifRXJZ 79phT++NmJVMQF6LfK2bsZa/XgjUjx15G+eRwg9tm2RXbt3kEDbieW82dEEwz1dp j1R3xobax4kAoQMFEzP1hZCRXk4s2wiTCQEBzcYEX0Ve3GGeXJkzG4i60yQO45Cv KVHJVTCKkVsFUGk/5iu75rTj3OGNVy0mpBHTyfW4fm5g5ZLHV1+BIlDeYKxPCm1f s6NtvFiyIMJUhicH/me0+EwD7r9F22tSEn/otOumYUUsMfpv51xK15uMDJ5FgBiI /DgwfQWDvzm0ecg2NgN1XG+7tLuRLfy749R3iQA/AwUQM/sDY+SNryotlGHxEQKZ dACg8tebCrRjam7q8qEiO6bEEAg1QoYAn0hgKF+flQ9Mc+bDrYg6YHpWATSviQBG BBARAgAGBQI04FuDAAoJEIZ6Ge3mAqlzaXoAn2TNiAUXylYo7UzkXLCATFfYrypA AJ0bRnd2QeBqG4IHye9DpNiavKrBtokAlQIFEDQeJaPIqTCI6nN7TQEBRvYEAI62 JartYK5VXWRY/+x0dbBRZ/yOYPVVIYbqpOogbQaYUL9V5eilAG+cS/BnTqc4hCxE HtWhdWiXpyziBS+RfhxZpboF3AkqxX4jW/Q6xsiQraQFhIu5Pyrjv+6dv2FcipL0 Rhw5tDZoo5ho07dZSpQTTcUSpTT7bDj7G6vcOpPfiQBGBBARAgAGBQI0ha/FAAoJ EGFbaB8sVMj6+kEAn242DS2/0B/y3HaNWWKjGHrtMdSaAJ92MzUI73Rz8v5WFt4i /oB6L/5xhYkAlQMFEDRscVqfE3lNvMBCsQEBQ2QD/0XXQj0PNwX7UphxMPijzfMj 3rjNQN7E7g9/EnOWRIIITTRzRf4w93xnhx2Fqm6ZonDoCZQoQuzMdGZglgn0oUp2 KI/BLBuRRF29ZYKOlgHgUy0iJXpuTs5jav/oRJFUZL8EXJUwcBedqT1F8VevCXFF Z8dV7wocDRCiBHQnFDlqiQEVAwUQNME8Ol6azeHEqO7xAQFKrAf/Su5nbiSyo7Iy SgvEe4AUaNFZE6mNHyGRbX/ROnpsgaZqbTw6vHcsMH1mqjTb9uAilwgDLTDo/r3d upRGgTe6rRm9SPQEvk81toue93HWXpNKSbWxDdPKxhF4//6Y3EM9o1MoeBhvZsN5 7rDZYpV13eAjzbqudPkrz4gntjMVBlLwzgWr59g7GHY2l3/LI4OWi4tCxwU3PJws v1unua2sOI0M14kYu3A1KozyDmk1pB/Jv3/bb998nzLTlubekIEHCOVX8XxVrdar rBRwVjMTpm1hPB8zEzak+V+dpOrX4RNazw7Zg12+q7CRcF4Lp2kVM2jzAwbxFVdM 6BJxuqkanYkAlQMFEDVftc1A4GfJTFZJ0wEBmLMEAJUY3AopjwoTOzvLBjzlI2e9 wHk/t26C0lpZStTj9IOrUxuUcJlWuMbUHaD6ELaU6fqewcKR+OMJRWViLSRTQSP7 Dxs3a97c7C2cE8Xz0RUYhkEYcjD9rrIBtuMDg5+EyQZyvG6dNXCpFYfyZNN+3aom sUyYRPigH4R+O99opqggiQBGBBARAgAGBQI1x+eXAAoJEIuia4DFOWVXMSwAn2Lt JDOp6dekG5WehZe5UQZi+n1XAKDfZ0dO3H0pXrwk34Ht8CX7UrvJg4kAPwMFEDVj TKaQMxj3BQ7KuhEC72kAnAyCgKXkc8odOkN8of2tL/T93A+OAJ0UxPWaTtdgeekr cxZ96Q3L9vWSPIkARgQQEQIABgUCNcfnzQAKCRCjwtEStjzoUXznAKDdNS+SQFzJ alvm76rn6cpbq7nURQCcDy/iq3jD2P2bKGB4b25xMyzDanuJAEYEEBECAAYFAjXH 5/YACgkQrNjAGYLybBPJZwCgnnhJ6v+gsKyE034KP2mzHfbsVi0AoPvrS5mDGsQ+ lKD1B6fitwKM1mp1iQEVAwUQNRuhax5YtoXW2EOVAQG9lAf/XSWL8usstSBCaHmx X6bI5WwOCKd0XfRz0S/4ZgfKon6ZqU/gnW4y2ssBoRFJcCv/KD4an7290pE2bRIQ BcuKXYYXsjU3WXVGmWniPbUdpuylMVMFCH5XPUA0yLqyZqjee6XnS9pFY25c9cKH l2ZBwCszM/Z7RvIJbjKf4iGwLTJwnsn3DF5xfFdQh719mDsSCdBSgkXfqCeY4/tE jYBFyoFwIw4GS4LxmUQreb6nypZGSrl/c5xaoz5Im5NUiSbmE0acJ6UWLIntAZDv /uJrYdnIFhRaiQRKwIt8ki9L4J38QZZzLVNw8wtZmstz+QjCnARBgRZKhMKzTGg/ aQz25okBFQMFEDP8Arw9+gcbCnuE5wEBYjMIAIhXAMy0BRZ0GcasIqmY3PjrzXC3 X4p2I0CoBQQAgVvfOgcMXAGMLD4FjqqBQnZusNHCzZItWTF54xyl+Hp19whCp+S9 0QrFG+PN7/NChn/YQxatSUo+09nkF+wybF/x2RHU4/kDcmyFhlsaLA6fmUEr+ET0 NB65J9wkUho0nYKZ9VBol8soHlGUeX6G5/tkU6d6JDjOG/xFsrW8bda2VVDyranV SxvoKzQUmwQN7YiQj31IcAtLx063NMuKrBBwOXJR0tkzM2mNKhndtx4rknDYpBbN WVucYtn2tZsGzQpy+IqSUWWEBWXJKJw+Lq2Ps0AJ/D2mDVTZp6Dl9037PbOJAEYE EBECAAYFAjXH52MACgkQZTmJBIzotpMwygCglL5Svr5kE+siMGaZaiasS+okaV4A n22d6A4hDXu9m4LIeLH2jiqRyA11iQEVAwUQNq/XaO21/PkonOMJAQGHKwf+I/SU ih9UKvMsO4sUaIy49LUlz752n9ws4BxFA0mqfd1f/XPvneWax+7YkqswwufQs9a1 khmZD2AksuwNIIHZeKwsVqSFwEUjUdJokXa88Ma9+n/o/sNJ/prtG05hY8mUnLdG fEBPFBMpesv5iMvdeb5RMYTSBcfnI6DoHbBtrKsltULjAlTDLCO9MHUfnRW1c40J PXBnwxkppfIueCDaPJSYocHFDJC/Tje2Qbm9DqztggHC99ireOFlWR62+o2SHnLE md6x1siHxp+/PDsTLDbiEd5sp3HxrzH1lzwslf6Upbtftv9ioWtk2syPqnYmR8hR cwpCwFLrI4wJV9qQ9ZkBogQzn5+5EQQA388nq8GOM+n5gnoYOpHc8RMRawp/YDDn YehSen8DsuyxMnv4rDB73jWDa6DQYow/fAkbkYg5Q+NCX8HPxeLjE/Jq/+VX9uit FHw2yaH4C9nxeI+TNlD3yZMw7boieok0QhfJ3eMNfLlsPs7CFTBEuGpLhX+ZcJuF p50DvLdQ+fUAoP/qCACNKiakbSDED69NzuM6OvdLA/4rBbfrLf5Gh39E2gAAz2Mn WJiEe5GS4cOYc3mmpVvohhpe+d/PCh2VbPVmuKaAu8X+LwHjT+oBJMEav8AxuL92 PALr+v46Nz/FUcbU3UCmbGFY82Sr0vvUchK7tMbqwhsrbM4tajO+AUiRPZkbAq3v JQFmWdmuOnAmhS36P0DukgP/asECrn6iLEfRz1W3iEvtEnyzdbQjj8F+AvhdtnUp 7sEfIMS7OEB0GDkRXz1YzAE+YC32/QZwUJ9+1gPxRe1TzQsjzIC1QB/6ok/fO+in KXpOIUsU+2nPnFrkCyHlNmJGutn6+AV13pd+zc2iVVWCp1TMmapFPyQvfl8QKiho aMuJAD8DBSA251hyiXGfp7ZjsP0RAvzyAJ41AyyMuIECYrNfpiBjUKe6NnZIvgCc DphlbtcNZXqp6pln3Ni2BHSkzfq0IUx1Y2t5IEdyZWVuIDxzaGFtcm9ja0BuZXRj b20uY29tPokASwQQEQIACwUCM5+fuQQLAwECAAoJEIlxn6e2Y7D9EcoAoIMRH38b YbAwgwshloi6hadsbxwGAKC77GwSr9/Ood2M4+3eDYdA+52GXokAlQMFEDOfn9QE kJHpt/K8BQEBmIwEAIS3SjlYEt/BXgGaR+jGnmwZjINYIHTlqCqhhV+U2QOcBmBE QPfj4qsNRJNtHUE3ohtkU3BsV2z8BbqHOQgee2eOKUfrvXpqwnSOMR8r/XudZDfa 9pXShBmpMG7gDF5+FYeVVph7+FFfJ3xMvaVrlg5Thft4XuNO94USHmLx4Px0iQCV AwUQM6K6My/fy+vkqMxNAQGX1AQArN+Uj5Yv4PBJzgireDb9zGhoLq6xku0EWgcJ HKNmR8NDltllOo92H9nrTF8IP8RNT0Y/DBTiQgQ+s1vBd22jAR6f9QTS4ANKsJH/ vR1yf1XUOY4KrGcZDvLtMrp9Oxw+ofi7//bHwkXvjg1C2j/z8LENhZN9asWIsJL8 xg8dfkGJAJUDBRAz+wQhcMhYLg7iOi0BAWzvA/9epfXM6qSdfCcLi2HU+fPdjzwu uveAMoV4BD7PE3TbxA7sQMlP7pUtAxw//RqNonv9hu1tM1coJYxucs6wEpAirp9X eKqsvTm/M7dYJeAPmaMijmeutOrg3c7wmUwwJtZ/nyGnT9EREsnNC9Qm5h6MGn1b wp6Il0CVqt2ri2Kz/4kAPwMFEDPd3HTbmAIeHVEqPxEC4WAAn0KcoPChnFa5Da+v aPywZ2lM83shAJ0XyIspQwvsg+vhNfj/V5qDshNZ1okAPwMFEDP7A4Hkja8qLZRh 8RECDkoAniF+oz1Y7z671BX8npuk5Z789YXhAKDgnwQSZWeilgQWMgF7Y1KK9+Lz bYkAPwMFEDOiuk7qOuX21ac3ExECPEQAn3+d1c+PXYAIoFZ1qmNGxy+9eEJqAJwN 9sGGzHjfMCkVIhgi4xXja2RwGIkAUAQQEQIAEAUCNhDUjAUDBh+HgAMFAXgACgkQ 8z64dbyKxFgBHQCgw51mZVIUlV/HC/SPZsYRABWKN/UAoPSZVH9brxBYi5Fo8o4t yqlonBYUiQEmBBABAQAQBQI2ENSiBQMGH4eAAwUBeAAKCRCjzyHdpXwH4aj1B/4w /P6rpkba8GhX14w5Yk+0sb97FZiupaC85dOxPmjpZO9XjckMwT9wA5kaSpOPzaAN kVz5OQMcUhGMVQ2BITGSfUMjDpILZsDb/c39EFOQ90/CAX8rEExf6zloheR3e4z+ aoLbzbZ9e1luVEPPPEel1DoorQ8kVgIdqPXgJS3bApTG79z+6QNqy1Pjs3xYO/6N qUC6ODcIjwh9a8Bwq4TOKq7hsKWCqn1pvoLRRE4nZEaCa04bjvOpKZHf7E9zorFL Fvc7zJTkDZCFSUQwtJCLIDTYstxLue6BM8wFlnB/b08GMtQ77jK2oz/GqCB4b6Uc +Q+eN8EGRMTN36o3ry4SiQBQBBARAgAQBQI2ENTXBQMCW88AAwUBeAAKCRCQTf6j KMAprwgKAJsH5egt/IkyJ39jxf8b5VwMByX7VwCgnM4tdyAxZ5G++F9QbzMSqabx XnGJAD8DBRAz+tQSecO8NWHAJf8RAk2iAJ9K1aUcyrcsMpjFHgTcBBspn0agngCg gDF+ZEPerXX1yKO31xYTqdgy4uuJAD8DBRAzy/q2PAK5NSZ7LAYRAk/5AJ9TuEvo rdtj4f9ePY8yscMEXCCHlgCgpelyxSBUzcu4hWCgSwgcOv+i1sKJAD8DBRA0Smje FiW/bhy4UHgRAnYlAKDbjcDwfdbOIYKpLWIk/euXPFCklQCfR0tUO3eaUV9OgvyE v88iNfh0lqSJAD8DBRA0RyG7VCQTEqNZfccRAiXoAKC+Fx6lWIMdwzm2TK6qq6dW /OvGYQCffLeH/06fmwGKg2LqEEVValjXEraJAD8DBRA0EqGBen4IqadeW9cRAr1W AJ9mvJe/NwmWKO3sOtxDR2lDRzqnTACgrel+HCi2dOsRAJZrhRc+7LP3f0mJARUD BRA0QeeH/fukxZQkWWEBAaWcB/0f3ZzhXBrmX3GsWi0pEqCdYEA7gAPR0PP1jdM7 zV+Fx3zgCzyCxND69IpFfDnhlm158Dm8KX6aTVDrqqI/MZb6QNZmq5M1xzSHM2WI XuSnRrNt9kcbN1sDKSxeFglwspLrzSvfUYUmDOEJSwznb6NnDu1sv2bxbEIvwjZ1 tyKHaBGeflP00XuKeDmYgnzeRHPTTY1RdX7FK4ovP6V7IJQvlF6pWtXTyrTHcbdt 5t3QHGdMTqia/dRmHhjv9JKKU+1ZLaPyyY5hV/DkEPYtaEbSwJwo8LLXT1z9hCc0 iiuuUkMUZ9CoSNgVWenGjozC/nJotD0VD8A27KrxiX4naC9jiQBGBBARAgAGBQI1 0ISCAAoJEEeeVUtkwAqT1wAAoNBrKCbAx55kXW4UEUpoKAWCEjBbAJ9HSyCQLaDT hbOZBmrcwCkuCd/Nv4kARgQQEQIABgUCNcfnYwAKCRBlOYkEjOi2k/nXAKDDfRNL /MKK2OO5Ln+Qbp8gautL7gCfasT4oi2NnZPVXh63IA+qHttEcg6JAEYEEBECAAYF AjXH55cACgkQi6JrgMU5ZVdtXACgoKtObAscfBiVMv5YYG0UBm4eKmIAn19/XCoc tmZcJXyW0pi3bJ/s5SSmiQBGBBARAgAGBQI1x+fNAAoJEKPC0RK2POhR6R8AoNF4 w8v3wJwaop5QufrIYjXa81Y8AJ9EUoyeVMDveInPGSW92hHq1AC6eokARgQQEQIA BgUCNcfn9gAKCRCs2MAZgvJsE4uLAJ47OfihoBkuSHDtQKQXfVtgq+nT6wCfXijY +V3PB4YWFj2NA8pmRaT+lqqJAEYEEBECAAYFAjXbUa8ACgkQYVtoHyxUyPp5PgCg yL2W25zJ9QJsly36JBfKHCZPj8UAn1VICqQxAltsM9C8uBoaIDfsmxDBiQBGBBAR AgAGBQI2BonFAAoJEDiM2656VXArmfYAoMv3g0wbLUrFIoUd5S62C+KaiiS0AJ93 Pgb3LGFsSujnig+2on9gQIPQz4kARgQQEQIABgUCNj7cngAKCRA5miDG9cmJmVwF AKD+0ZUVhQ0PzH5raEpfzKIsWufdbACg9pMYXDPk3TBU4+/Z/NXUT+IUHLa0JUx1 Y2t5IEdyZWVuIDxzaGFtcm9ja0BjeXBoZXJwdW5rcy50bz6JAEsEEBECAAsFAjQn KOEECwMBAgAKCRCJcZ+ntmOw/VXGAKCVzFQ3koz+6Ceb9zG/UzYTZXzopgCfUQI0 bpH0sCI1xCmLUtPutgzG8kC5Ag0EM5+fuhAIAPZCV7cIfwgXcqK61qlC8wXo+VMR OU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf 3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2g pXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPA Q/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQD GcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH /R4Ap4zZKW7+woJqPvWBeDukKqcRSI8dnXBnk0Sjb9YW/lkvxosPQo7b3wtOd3iH HWW0l2IByrgS1H0EibHTGQwMtSNhTLd14Zo6sP4ZW6Kj6Hw/cYKakPqFYznejNbC pIr6LLyrAookWw1vRHHTcvy8XH4+IZR/5Gj2+vpmOpLUimvCSuxhnvu5QgxdT1bc mBXTco2+E1uRrSpBS+01mnpPIa2U8K/6cjkfpF8YCF/98yPYOasyqHd/BnhnllsM 1qNikdia9YibjrO43XyLhgEzUpohNgOtkFupsuUNdS56Ze7Q/vNo5IE1euin/0KK VMcUX3w1JpYSDig2h4/rTfuJAD8DBRgzn5+6iXGfp7ZjsP0RAnZbAKDgGg0o3T7X 0ps9PZWOGpykn8ic2QCgx4hI0ki5z3tOc4zx87GA3SL23uOZAaIENlt9GxEEAPr6 wc3ErBpfCY7A9KtlPjr/5e8qYsbkIe7F5554Y2LyBE1h5UhGZ1TbcKEYcLzFkGjh eZn1d9mTO0typ80JaGx7LqRWxjR5QbmZrXvyBTDhHz9dy0dDWCINaPKhXUqSvpFQ +E+cZJAhmhArXyk+fc/RX2hfiuO7UbPaUE017s5RAKD/p8180InjTAomDy6IhYC7 K8XuWQQA7K780nSo1E4Msuyi3GtbAiSHXGnkD5gMAXqDsGDW4HK4AXo8UQ747clN dTIe6VoxDO7vg/vG1n6rCogiyVJJvDm+/QhSkNQmj5iaoNwcDk2zNtrR2hxVN89b eXLwcxsKzYpr0nZB2Vfytylov+j+DpD2zF9O82U37/UjINnuNjgEAPWH/TJ8WnqY jy2Y7i753H7Do9nSeNcJOJZD0Fut0mE8lOAIXE3UMDanyQBXPworfrxhiTCKG0Xh Ao9LxU3DH3YooY6fc73vZHgCN/MuWsB2pxOY74uJDAOjOfdX/UC3Qp9720Htg73C U5Mk30GVkawvkywktKG3ygIIW+OuSQjEiQA/AwUgOY4gC4UHxLzQ1K7HEQKaPACc CkyGuIv5yswC86g6H+/IHKzA5v0AnA052dYFhAdUPWXtR3xX8j0JB8qGtCFMdWNr eSBHcmVlbiA8c2hhbXJvY2tAbmV0Y29tLmNvbT6JAFEEEBECABEFAjZbfRsFCQP0 gAAECwIDAQAKCRCFB8S80NSuxxDyAJ4gyngesLvwyunbUKtG2QgCMScXqgCcCmlv iLUdi0EjCoJZqEF0HuKql/OJAEYEEBECAAYFAjav1o0ACgkQ9SFBcfl3M1eL9wCc C76H6kQWtciMDyawh1armcfMNIEAmwQSYAH2/l3sRmcPxawVO9rNglsFiQBGBBAR AgAGBQI2yjhNAAoJEK4MVGrDPt/eiDsAn1gI+jJjLUlfifH2O5p8+zRgevCpAKDh USxTKC5/8OfEOZCDjw/mBOO34okARgQQEQIABgUCNso4WgAKCRDsTU6t8w7FhSxt AKCVaG6Eb2mz8qVAWF/GllLjlNbLuACfZ1eQGlyAKXVQz0LwWuzv33iSlFiJAD8D BRA2yjicUBC7hzYSSRERAl3FAKC88gT0fDbc5YvwraQMkYuArdZ9RwCgi/M88fSE /xS33D9SHIfkpdl+kViJAEYEEBECAAYFAjbmxMwACgkQOgCSKcyiDz8VFACfVLzB w2yESZ/38iNcKkyJoFUk78kAn2EzYNIMwBC0cz14xWxiCMQVo0bSiQBGBBARAgAG BQI2yjo0AAoJEM814l7+y6zlxWoAoOGmXkQFRbaivBOTMWgmJEHTyI6xAJ4mjyUt 1c0HPh/C5v8rzmvXAXmarYkARgQQEQIABgUCNso7EwAKCRDMcdRgRtjTyPE7AKCC At1a9/WrhixrnLbjSGhNDT8OlgCeK8MRoIdXMvg5p4EAUQZ2+1mzUJaJARUDBRA2 6N4d01ThYrym29EBASgsCACh3Hz63zQUCeB0Jq+Pq9kzxyq3gJIW5CbJwwvrJcti DT8yh8Wo/CxN2wrwUNX6QkMExQ4sEaZMO9kuLYsZKbh3ePD4toxyYF852ZXe6MYC IC+7k7c0XSZeb+uUbKVThBAZWUIu3m8ogtD1ga/LuMIp4EC2+R5tihzllDJjLlvO l2dFX/LhUhul+9yV2EzmVWKe3gZWaioDTB+jBS4APwHKucDxSyKt6f7l25S6zw2U WdVEFbBYgkSefKfz7YM3JHY7fMSgWoGuqnGra4PuuQhYvIIUR59PjoZ/cpccBOE+ ACrrFENuxnFTp6PVQD1mcGMWMbfh0H9Hc2kkGf8mxwUjiQBGBBARAgAGBQI26N48 AAoJEPXUPTw3WtkkeiQAoLfdfznCmlYd5FNefWlhcjMXYnclAJ9OEll0wwzLjdx7 ehwWftTNUNd7NIkARgQQEQIABgUCNvVDygAKCRAHrb4H0uAwH8RWAKCVnxwfE524 KmSGHVLKB0mmhsqTZgCfQi+pmpScDvho3LOdX/9yBNdQi3OJAEYEEBECAAYFAjbo VZYACgkQ5r/NLxCBo3wyVQCg+4tohbfAWEFVEVOTdDINu3YXxK8AoOV49SrjS9Ay szquDLk3tXom1iGhiQCVAwUQNukp4aRQkCwJ0+ZNAQG22QP/fiAbccB1KhUhU/j4 nxzI1T6MkTRo8WYfybxC/alWb3spSObUpelCuNOQFOU5kojz7Bba0cPzgGThjGzC T1WYKyRJkMK2R+jWCnIQ7gMvbTgJkRJR18Xox7BJE+otbfGkePs1Ybo2ahG0gtOs WLpIJGo+k9IsspaTIs5C2BdhjpyJAJUDBRA26SoB8uVlTOYOKm0BAYDeA/sEGiZn G2B0/YwKHbUHxVsRg0ZWo+lqROOhH6/k1znWnpBuzZxDfDDvzrj0H+DS+8D510GF 0MRYkPbYRXLobCvZRL+wsTHgn/Iod/gXRjnN1E6YFqrU3C9Zh9xDL1z9agQAmTCF D7kRl5xIFxJcsVwRHrHdot7KOpSUIkHgphwTR4kAlQMFEDbpbmOwsXGDTboQkQEB taUD+wdAP+XF7mRReDXnobyBQxF+alAKPVJqe/NaoS4KgIm/vZScKpnUjMthesjh VbKxisUW4933Bs4j2Ibs3OP1YoCaE6tX7fds91/GCh2b0maUd+NUfLGzktyBMsug B8A870oxCsrRR23Ha9DovqnbA2AVtaXkelbkcUsBvKX7dXRViQBGBBARAgAGBQI3 Fmd9AAoJEIZ6Ge3mAqlzIAsAnR3DxME+HJxgEJhqIen+raVqEs0LAKCwgros1Y41 TzQwQ/DwBuZer31tz7kDDQQ2fIRQEAwAwsbia43bONyqN60hQVZHIvPqO8Jg77Yu VgMcO45NIqAWBEfddya1R2E13Pz9U2CY4L2PHiNzO7/tdu+uY+nx7XVHVZshIrGs cwQJX+GFuRk9UFy/rCOQzqGaKB/1wMCKvuYiGW4xRFfflpRnyoccr+0T/QjeLlfz /+qCVNXQNXBlL9HlRdw3KnWaHxK39QMV74PN2/oS6h9hR//CWqg0ILq4+31cG1cb jZdFNkh3dXS5By/kkA2GHMFjwqK8FIiPYTvAfHh0+GJkxCWZARp68K+7rMpjGHry AmhVos1OIZbATORdYGubwHHYKMkJ9x5Mp3FMUnbOJWavLHnJ3OTzh3Ub/jwzBtyA FVzL/ZJ3yYDZsRrpDUjBtMnpiEBZefrhblqxNu6h3k8LSv9Kq6kqYbz/96fgsTcr FPxbZVe3aiS8Ns0Qrvv8JU73xlIFhFx3UFg1NJgT1hUIbd8bNQPetPB7kwvYMAT0 lKbDdBkT1caPvOZ0YoCT3Ag8zLmQeGl9AAICC/0ct9ANW9xEaUQqojIebV4KrfA8 bxEoHqjSvk7OiXbd5+Tl8uG7bjicgEE54q7EeLfQoDZaWbSgtTMF3Dnqv1+k6I6I 7lfgO4RIg93i61RNNAB6HM6oga1FmTxtreFa5Yo7qlxrFA6B1DpX0AFRWPDiOQA2 yMbgNX10h9ptPTMZ1rzuEDMB9kI9EbyHSEmcodfvyN3RsZT1M5erjMRmtYBrgWOC AbtOAkB8zLpgylZXQnEUzXuwGMsSdrx9sGC1RQkg9RthGZhYhBQP7ZeRCqyJ0oaE DhTZ0imRYulNFpOP9eYNaeEIBZl39nWvrCBio0VC5gwkTVdbODHEUK9ru4/mIa9B MvDILatBVAsuPeGYtn2GPWnQRHCA+EAsImsZ5kIXY4iwOgE+nenrUqHQwp89zPql PPBoMg1XYj7+KZ3enPHdgFxFcEYuVHNav9vnmLrZafPMPXARAfvbrQf7opqzKkUc edUtTFrearg3klvTsTwDdvWbZgZn2tmimAO93hWJAEwEGBECAAwFAjZ9sZcFCQHv tAAACgkQhQfEvNDUrsf8NgCdGXXGiKEqYtI+iDpCqsHS1beHnd4AnR5QUA7tGutF hKXFGT7uqg5/RZ5buQMNBDhtidAQDAD2YRdzV1jK5Z2eAmh8IQE7mB1japJle71N hX3sBLYOHP8E1843aFxRw1Ldl3sVb5B10ZTt1vzc4xqirTuWwQKKd6qFg7bxOHtb 7xfhO5ei11EeP9NqgpjxjJCJ5LW9pMpwVJ/lNs5h9w71qx4VIPTUbHnOC+rvoVQo QZjM7c2/Nd3ML+JxmNMlXAAToGQx19oVpcilpJ6nWH6bFtbLi/uV779j4MxTDx59 FYphJ7mXjbhEMHL6W50ofGucb+GqtvbFXK4BU/5fa39EE/ZRhN8SGuFGjbf+UUNF BaO5QVTCjoKLVd4qr7gRAyDEQ12IGhWRqp3I3cR10V6Wt20R/pfq7j4e7d6Wj4dj Ps7Dlg0WStaoEvEGluMvQ8jSh6b+KJ7Yt+KcC4Ac3kLpdwWKrfVf73EBU4NACGud aL2YP+jIsHVTvxLLTOL/3zkXDJWz39QgVf/Tzf+DPjhDrUpRxqB+v0W2Dm7X7om6 mkWQYRlyc9Ja0r4ipJpNrubQX5fUGxUAAgIL/RpROa+vnJx84J0k4aVN8z2DBgaY kt0E5bZyGwec/zCISdzFTIB6UPxdbqyJnmUAXLWIeq7psCiaZynkyh4W72UVxfNx oBIuosMH8fN+Abq2mdZ2FTlDlIXOrteLRf4c6x0Ebqx+R2ONbaGbQtnlQGC3QDxZ UmM9pCuH9JqWlk+QlgnawLg+kfs0iTwSnyKXbZAOBIMLKQEl96BweTM33mEYmmej 1U/aivwJk3PvX0pbsiEmTD/ASbZYQ/n6dOK+z61cr4iKkZy7mO7mgQF1XD/m/8mH wRZYh9iJZElhtee2Om1EUA8GYeoF99kGR1zECT4U4NJomclavsftY0BTseX5Jm3L oH1/tY41G6YK3xShEaGWQlKi/ya49D9WHETAP/5w6xSk1SnCsaUd6uQnPwFEvToF D32H/P1rmcUg7ud+djv5FS+nePjxtCS9avx6f8n64VK+jOUelCQh7BAovSTPxPwZ nVxyQsvIJmpW8NqCFhsHtwEOZO4L5Lk4TlW7pYkATAQYEQIADAUCNn22KgUJAeEz gAAKCRCFB8S80NSuxxo6AKDEzH9c1jzNqz5uqTml+o4assXr6wCfVab70zEQTXL9 0b3jg/clTv1/jkyZAQ0DNudcEAVwAQgAzqz9hv+7e1w7GJuso2HIKw5rVUdCz+rz WCvKDvrW1WpMg78lrSp2TF7YDe7aHC/XO8I81hVu8WBitzzNRyi4La+VtzceHW22 H2Xd2QAWY0Ei6SOSvluD/H2g1SCuFQK6BTGzZKNlXpyTMi0xfT06QU8ykenseMk0 S8jnuWtk7UQBACDO6t6epMnEl3heYkuKaivtY4YH1CNUDLOCCpSp+QKhptSElF/c 0q3P/f/IPwML10Qnp8Fr/WHYYRtNjrAIzfEkgw7yMuDOk7i9ZCP/UZ6jnaTo7dT9 SiSEx1YK5c6uvZSE4e95WFmRde8IPtOZB3MExemT+EvTVOFivKbb0QAFEYkBFQMF IDmOICjTVOFivKbb0QEBdu0H/RPiRBGWFhlepO1UtxLDYD3ZLosgdQM0sODX/4HT u33vstaPAl3NBorqXKJsThpomlLPaKN/SDqTzpm2CXBvBekpkyih9rhFrDzf3Qvc C5H9Zo+Nz3KTd76C50yoFd1J58CuacMMdLAqcaP9Q4xsp6qHAxiTJ0IX0JOhKLCK lZe3rg/EI9Uf5HEmWN0tffnI59Y5XZFqWpVnH0SezgkqOW/Fi9zv3vXIKcEALALQ RNVyLKQnrOWTGIr9cV52CyE5N2KuRkur/bmtlMQ7DFyyxAtNijwmlNZ7Sa4FQ9Gc n0y681CvJPPoGVrogS8ncSktogBa+D0zq6HTD9MyiOzcdCu0IUx1Y2t5IEdyZWVu IDxzaGFtcm9ja0BuZXRjb20uY29tPokBFQMFEDbnXBDTVOFivKbb0QEBBT4H/1Ui ECh4LrBhhq1VaTjvt9JbHHjZ32oba/HY+BMUmZSaye6dUmfcJFbgrkaKEEjyC8Te 08r9fmvCqyL7WLUYXzlC8hZgeLsU9J/fq6cpHgknocEVaMdRwIOYUVe8R1llxXj8 56EyIfl4Cqt8DedA8kVPsET/G3H1iLI5jJMLTGWn74mblE/7XoB6ZbtJzfr4TZ1S qFP9UwOrpuIXqObVOpTmTyCWjfTWocaq69SKZo1vP/Ljz1vD+jENsC1vT2eg+BQB 0UoECe7rHsOLqzvdd2qlvdtdzrXRAwJ09SYJnzmPpgEYpinu63s/U6dBWMar7ByO 6hCrGzwqR7Eygssd9+uJAEYEEBECAAYFAjbnXEkACgkQhQfEvNDUrse+AACgzSob 20OCEMvKi1jWa74dbnTr0X8AoIzZde8sRxL3OHG6xJdbZ8bkRjYAiQBGBBARAgAG BQI251xrAAoJEPXUPTw3WtkkTwkAnjgM2sTc6wcDJVK9WZfd5p6sKsaBAJwJUnuG 86bKRaqL/XNVtVLfwet3T4kAlQMFEDbpKeCkUJAsCdPmTQEBhrUD/iMgzNg0mSxY x6wP4Dhf0cESQ6TE6TMpC2qN7Zxn9rcYa2XBXzvR3Ao8a80z1ulnCUaPhXd6Wml8 s65Buuk3sLqz9PYyvrmn8lgLDOeDwkh05+VlivVUD2gtP2jehHLQors1IaML1U+L Bu82M3RjbpG7EIE29p+C9peTjHH97AfqiQCVAwUQNukqAfLlZUzmDiptAQFOVAP7 B3daff+2NWeJ8yBBtMJes7bDOPzE99M+r3jJgvb8m+XyyrCEYZK3CMd49LjfKwGc lD8mxbkABTNrXNe9paYC77hw1KCmYC+bIoxSdmJvHTvxBWcmy0L6UPrGRNrMTC6o BoyZpq9zwy/JrzFLZlddWuBicBebxXF9RjlQ3/ogZaKJAJUDBRA26W5isLFxg026 EJEBAcwLA/4h8SOQMiHE3xo2gYFP47d+Kn5HMDvh0ol4dhmbS6oh5831To+oJ7Db 0lqvCfJ27FNWIq86zJ9r6BoRqiXcUqivfLDaKwtL0ULprZVRwjEhRkUMpEs/lGlw 2c0nECTzzTDvj7lfU25+2wWR9zI/ge7ql07vDn9JC5g4aaz+clE2/4kAlQMFEDcW Z6IVBbtr4vVmaQEBeJ8EAMsSBi1auDhXTiev20fXxYpKUsKbW570LFGVjBL9XWpE SSfNHRUDwoSRS9DPiBDk3gFUIlzPUprkDPx4OtGhqQkAq+Lf/byvwNdwQsHNbsgU sEW8MgqOuPr4b4NiVZA5qKsvWfqzjfUQJEBKxYmKRlHgldzYRfnPCrQnQz+F7w60 mQENAzlD3GcAAAEIAPJ10sQfvurMDvBWtyZGALGSWVIj/J2fg2IlbstOdI9vxQ1f WXbMKGWDYJZAJFl8LxvJeamoupFo/36JKH9HPZQjJd75743rd7TYRFBAEgV74XAD lnkVdsJ4pO0I9x1dcVGkgLvnOX00/RKNei5dorYApRvbsXf16oylovgrBB18G2VN d5Tt9+fry67+MsS4cYT0pjqEfCwSQuCSC/24qX4xm2xJf5XbcFBVIrBeKNJqZFhV l1vBAvN4Ii7pdPWOvbRihPEysIa91uenASVZed2s3IBlaVFNsHn81XXPWTY01VG1 xw5lliuSyLD2pib3tNg+cFrTuR2zBpR3CO7oz/MABRGJARUDBSA8nQqFBpR3CO7o z/MBARBaB/95TZ+0dUKDdz3AOikEoFEruTSGw62zsZjrpGdlxlB2YIweY2BsP/nH QI9NxYCVHzktXpTcEO/RhBJXpTiXqL3KF2uxsypTYNNolvR4LZvNoaU12w2YaC79 IYDdMWNLdBduzO9FrmIyOX9aSxPMyVMcbC9memzkf70WjCUZneqxOzjJwWpcFmkb G5dssVDHPX6Yzrlm4PkiLIwjVLDm4ndUVEiBBcZsOJN4JTOmgmsyeoF2DY02IqNU s0AUJEoT8HlnETA/WR6xWLSWADFWjuLf4wahG5nAOMLrHB12vEcXntUu7kun/OJF 3sPeBC/0j10/uEZvy/mEiVDappMZ5L8KtCVMdWNreSBHcmVlbiA8c2hhbXJvY2tA Y3lwaGVycHVua3MudG8+iQEVAwUQOUPcZwaUdwju6M/zAQEA8Af+IU5ePXMJ8lj0 P/dRganw+XNkYFD7u4E4kWg8R0PxMXiUVz+ReRCnOGuki3iv4+zKD4SkWYa8rQFZ maN2zK4uxdytovU3qvaMoK8W9q9TtsOLhJde0LthFbaEic6VQj6RMwHNe1bW5U91 HPVMrvTSsrr5Ig5qVrctFeMrBoMkUhcRbRcCKU/t4D/wZZX8W56fatgN7cCfwxbR JoZaGADl/BXwE4h2g+nZdkXrgVT4JMBBX1lAFXzLuZQYvFSxrrE/HULmZLcMg/GS WHhMPxHo+8+JkB67CV0FYroN40yraO1lLxLhKdFK16BpDxCmts6iynNDSQsRsM2m +KIollfiv4kARgQQEQIABgUCOUPclwAKCRD11D08N1rZJEvkAKC4ENgjsZmCYzQ0 XFA+BlNWYo6elACg7AiF6IrrLxNfhMSM5x1cvTCH4ZOJAEUEEBECAAYFAjlD3PYA CgkQhQfEvNDUrseLPQCePSrdL0cZAMk0n1p9uhptVgVcSJQAmOGVb5Z7+pT6XJZL PFRDiCva/22JARUDBRA5jjwjDXoNi1DA/qcBAVdUB/4zAjE51NIOqFeWuDM2CcST +f7zyhr6k/+MIVqlbEBCGMRbPAA35JPp+iz9zLkqHk2CjSVtmkImBg0SUgIJTslJ B0R7TZiTCmBtQArOBZR5cJwkxeAKvVbuhhbDIEZjYpqhOUe9PuirfBYR59l7u9Xb V8ZhuhEijTBOIMbiuKGeMvrGs5kAvrBR8mEyUifdrJW+Kfki5UM18b3YzjI+rasY Yrg6IJCXeGI7pHhRsdYH+Mq1/QGSOmR4v9Ndh/foTGb1p0LvjiThl2F6oWCUXEji BAWaO5Q0Uz9Mf125CUYDUt3Rjc6b9WRjVmH/+GHcdiE8MpLDkIIVQ62bV613ebkC iEYEEBECAAYFAjxwq24ACgkQiOayAT9atWnUfwCfYL5wVLdoogrNkeKNUkNDuPQM vFQAoOYTT+HhXjkbeN5EHAFlJtlyitZRiQEVAwUQPHLnrXxdxabQEF4dAQHIlAf6 A0H2C56EhIcDBXp71jpIuyUaj5cRMENT1slaBkMaBlFBTpra8HgB1m30Z0LMFFv4 6fP6G5I9cZ7AdnnjRCvKeYdNWh42yzGa0SMvRyRNtZC1HljIA9KMnqXdVpA+48jn 1auSJy+DbfAUogEs8MyWbe/aJpJj21/aQH27vIgEXLLJ8MfB93kHL1mTFm48AC84 AtlHwdaY2ckwVomGv/vShnYq/jHAZWE4hJgNq21dFBzUx6aa5bg9C5u1ToZzNOaj Gk5DKRq/QJp0JVxqGtYXS6snexCOf2HnGaBlgtROnVIk6mlgyvK9BPnyZnSIJk/b yryYUwPPUaK7sVVoC+x/ApkBogQ1kIgYEQQAycC5ULZCLbCsrmpr6qMcjwDb4pAt Z7exJNlsYjVjaa+p0UuzraqHQ7u6PnYaui7yVpy/6KS4paY7EjD5gbgCK2z1fCT0 vldhPgW1X5Tt1ZR/0KNyxEZM7VXEiKid0KC7DwnmGC43OWRVxzmpftjDMEjup8HN /PstqJ9bdE1osmkAoP8gND8bGrvM/kqa2tkUUpzkfVYrA/4wxqs7lYjWO3Jj7eCn o1dJ9TRTG2k1L+4tuqzDji6qEZ7neTNGXDwJvEUwYR73RWix5ugG6cwoEA3g/fal jIwcGIVHK3pYesPfZ1Ur4Y6UkE/pvBIi89NK0d1B/JEakPYqRCOxBFtRQDtaXopb LOSXtpFKukzKwUmKRmwP9q8LqwQAx+kSRoxzOSsDApCErWFUTmE4S8iXEJAKRhl5 BTFCLMupWHT6d9TuyeLkjG1M9JgUG/f4K3MAKvem28otSVMO1iUZ98WhhneMb0ws VRIlHbt8TMaS/iX+pZEFvk9w0HgegKLy0iajkL/qnJFf6l+nlq0j/XWPCwRW42Qq sFo2e3+JAEYEIBECAAYFAjWQjJsACgkQJAedkxEyGeFTkgCgmFAMGCaVPPTUb724 IZxMglsN8IoAoJPRPQtez860lfVsB3Nah+QUIqzztCFMdWNreSBHcmVlbiA8c2hh bXJvY2tAbmV0Y29tLmNvbT6JAFAEEBECABAFAjWQiBgFCQD7zoADCwIBAAoJECQH nZMRMhnhWgUAoM2cu0r8bqcysyuQd9hJmQSjTRZ+AKD9OrwB9+jgXhgh+0FmZNoT 19Y1QYkARgQQEQIABgUCNZCJ0gAKCRCJcZ+ntmOw/UvxAJ9qQSL2CzzHoidfKb/O RKIZ8EdLOwCgmXCzPOtbkYrD+AcYDtUxvL/jj725Ag0ENZCJHBAIANN6/iJKt2pD lkTVWlS6x1dPCxP0GFA1omhtEiw8percEiXu2uosVYtB63HD/XYw42x4kGxZ55tt qD/3ha9xTMqbfSnX/LIPLejyCj/HAGBjjcfXpHXDbqKRpvw2oNHyx0aaz+LsA7MX 1196P5b0/cLqnl8ELpUqD05To3FoZj9Xw2w+aM+7XlnCo4FCPxpZBzWjbmbSJHfH F7AZ9fem+sXcnQgncwNsM6oOGVZE+weCefyCRogkg+b6pOqMlB9v1+tPJ9MmE5Am 7+hWQUdCTDiF/z6izEvVRqmjQc61oNOcUIE6+KGljx/n/lXKZFo5q6YxC/sPnuD3 z7TrJf15shMAAgIIANHHEYB3by11Ir6xs92PzF/2PrTCAIGuSGvRWkQ4GG9fH5IP rQVpb+WaJaVDqDHegsCbDoQ8hPYR9/s8FUiQEE5Ov7R0c6Ijb6wi3dPqdLwS2l0K dry91bndMk5RvF6/y5QJAUgO87YWMtaVKUpiyQiYy0QR+KP0Q/2jWlV9zcsS+HCB B0PiC9LjlBoCfHGN5kF1PU2i/Y1U+dWnl2N4GjYB+PBEBtR2WJ93uNHntkIXz70Q xh7yfGqEVDJcPpZRcPe0MZlzbmsPHvALltSAS+uWFHYdC2/lx2oI9xUeroCpYWDC Zx/01cKU+1xory8/1EUNYMdnYzDxXzrz52oiiauJAEwEGBECAAwFAjWQiRwFCQD7 zoAACgkQJAedkxEyGeEUXACeMphR03h4JPFwUFM0s9MDMQURiOkAoLU/WWKzNJHs ehW/XnZ5Z69Dm7MtmQINBDx8uBMBEADL5p8s35Ha9htctTVRHAzOWSopc7TGW24K H7Mtefww8DA0DIGLJFZ1Jpyz56zhBPNNUcEGu6InzUrM50o6V8t/mTGHXrv8Y9/l SVAUgRPsyYJW6+QIAW5iUV5ZASR7Q7n+3mUdzHmUmo/DBqZcWGkiOPrDwtedCMop RK95WCxMdEgKSiGu0NL/PYw7+CeI7YR8uZpRNcK2PSDyE0vN6JdNIFZxAjB9GlcB /+IITXU3S84gLO0ja9zNrOIpVH77eeuWE/IK6nNx89PH9yW+0NambK3e+grNDOoM ThHPb6hIWp7S4fvbdHziY+hRivQFzk2GfPzBhwhYJQjxa7/UaNWM9IiDjpIlay5V 05uneTBVYHzDG+0sAoi4oUxaJMq8sf30OAlVP4NL1VomT8SEI/XIjIEQtxg45AX4 1yAwTdJkckmv9/kTca+i8ckReAdvrCGXFLGihSk+vEoqu2UMffGhd+wwA8ne2sTo uw3sP7GkMvNXIAZOhhZUXcvtdcgZakjviqa0XPxdNMIf1WgKoqPHEd+uz+fbqXvS gcsxHdKs5916UCeYxoQNzHiAaQT26KkhONa3AxVH9C3QXX1i/IcCSVxQh9ZJ5EhK KlaS/6pcuGbha1fnETNDAmp92X9bHaxU356usrRBGbPN5pVzrPZUz0m5nQsNJ/j0 eXZAyfEgqQARAQABtCVMdWNreSBHcmVlbiA8c2hhbXJvY2tAY3lwaGVycHVua3Mu dG8+iQIuBBABAgAYBQI8fLgTCAsJCAcDAgEKAhkBBRsDAAAAAAoJEARVjUj9NCi0 DaYQALvDYVnecz7ncb6dtj3Kd0T6xwjTLtDGBth6UZRAm69TJxzDiSjwcDfmdp4J vlq0QN8M/goaaymMEknx67Coxi7kBUZj7AnAT90Ci+i8cFUOWDG5whhAQCrb9Cyx 9WoVDi3Uk72Uch8SBC0iivMWdSwVK92hYjNhz07syNbul04ejTdvfvDSJD9HTo51 s/ggCFvz9gSPeueI+SkevA7xcGaUg92m5BD7QVkza4c2Ep0tBjb3G5D7GzPTjTP1 aOVwJHyxlfU8p4YViunauyve4RpOOzsIzgZOXQabe4ojfMVypSvvEXSbF5WcGtb0 KQnL+nw1Dyqz4mHvMYZ1d8E6sJhN+KvrhSzb9dFgNLREJmG0xI9q/cqHEx+Wd0bx u7MTWQRJcY49JLmXv1XVO5N8EeSIIOA+/ZDlSvISiujnQtRmn5EGFGA5cfWepFSX eW0MwQtsYqGeKg2j96pbQkGTlWAfOf/OggUntXrywp5Nbg+8PqQQSCaNBIyEutlf RCUD6SLTRwEJeuV2ZWD2JH+ZD+whjyjERJ4bIZ6Lix9WHbsfocuIBnTV5WjnqweD OI/yAzd4KBgR+YCrliZSlwcYmhxJwN1Y1bZg/p9laghsysPUydfxdc2k19svPERO mkYBEQkJFU8V8KZXlf2j9TiLxwOEFaT6/Kt1CkUJRkoR8TYTiQBGBBARAgAGBQI8 fLg+AAoJEPXUPTw3WtkkVOAAn2lqzbWUwm3ugkV9YYOeElXmi2xbAJ4sfR/DbwI1 eMXTgO9GS2hSJrfesYkBFQMFEDx8uGMGlHcI7ujP8wEBfEYH/0y4di8Q5uTgqTTJ CSy49JRlYeZxGX94qgjkZgGpl7N+OFCjBUjJftrKn+yR52pgJA32XBhYLloOpHHU KoZLyLTHWZqih/pkLz13v8RocuMgqvgbR4mV8PwItk6nafjRf1AN/TGlEw8vSBrm ynXHjYndefFPWyNkRoxKhYl5i8/hNOnJfvBZiTPRR3xgCfi6CElpk9E7JJgzxKmw Fi1uY2LhHwjoEmd1V8QpsoOreZtVUxriwIX2tqITe/vJIczbQJB5ntr7Je6ViL0F Bo58WDPn5Sh8rH4nbaK1W+6j6aW+p1/BatbrMiADYYgkz9AdASCZ0zcdZYtC7rIP jdcS2WCIRgQQEQIABgUCPJVzzgAKCRAeZBx+BnV9LZxDAKDwaIEOfPRGrh+KBLjy Ra0nFU1bNwCgi+5fN0x7JT53aDjbrGyagbUafBWJARUDBRA8lXY5DXoNi1DA/qcB AcMEB/wI3oz97xwI67pFtJjhbjZW1rcPJ5S23lrMSizAekNmfazBz33/Q7uHfCUE 0mK9GWsrNXF5jhqsULsHJ3HdtLpBeASSVkw9tUI8TQCFPRAdERAaU8B4bGtT2SWT piEKvwWw/NI9BqJj5KTo41vxLb2S1athFrxz2S16UvxXLUSAUUZGUUg4W+Yt3TSW jwSNgmk3f43XdCHDpfA3v7sSMnPCfSx3eun/RTj63+VWHG9v73SK6TWg4Nx7AcDL LM54oCnrbSbm6GQCrScu5l3QxYUnDlKVjn8PAklhGcluQo5ZGUl5QVxL+KM1AA5o PKO5D5r75uPiB1nOXYlmYLM2/2LruQINBDx8uBwBEADPkrCPsnoMH7NK4oCcalMR x8NQpaLnjwDR8ktX3fHWYjHc2gWrvVl34R1JntnSMGeY2wMBdsuDXG+CtjFJ8bb0 w5PlUq5s1UWXYnVgry5/CPI2Zl94LuYpvAxd+Rm0nzSRJCkpBq2W5WNX0xWzJmmB b/Z1NpfuKDxso/DFJFvoO7zWPEPjCK6vDH7QyutadxuHR5xFMXyVk7O2u5LOjTh3 DUEhZaW1/8Hh4hwDZ4t+tyweLp/J2XAdgnREBqBNlJa2W1RYH7VSaNwpDOtljpWu RSxPONCNoWzIDnNYJ8guVkhlMWrVuoElitAL0Zd93CyP1boEd+DHdvnoRj/15niz UEdb68HvelSJX4xpCYoNxGobSbCMqttf/XGIyq9sza4ImDN+GXpe2f4dQYko/Z1M 8EfdRNk+4pWsk1Ul3E+uyJ16DdmXSjv23j5QdIh+QzT8HtUHESLSbKt2i7puBvZX ZU5Skj7iJVNPswmjw6ib1bEyXDhTmnPX+4fXLyN8Z/sXTvVbkYh1i3E3NBtCDLqS wa3aNTPJzcQ0aP1EebN2fleXeNMtI4fWD9ReHEDH3ezqSeFq9/aoEq+ZzqMANkCF YwV/33osb9tjZEYqUc1k6srpWutmhIdXMO/7b9RRo2c+6GjAWuQU5UmNAAj0bmTU pe+tOdEDwVX6NyglUCrrfQARAQABiQIiBBgBAgAMBQI8fLgcBRsMAAAAAAoJEARV jUj9NCi0YekP/3CIdTG+ieA3c5jAh+6fXEBD07DUcflwUhQlHPYHlVMsYxtz33jB eHoo3njt0b9fMvnkQWshLDGTzP1LPJzBbXuwyrgIqVqqy8ZKV0LiRmb2o+8c3fKK M7SF1Z8GBK5DzcYH6TgQPEBIwZ+hS2I2qqPkOSKkS6EvKv15hy5dj0dG2e2nHKLO 4Q+ScQgJpXWK5RSmoksTxwFFSjE8yKXyr3uc966hQ57cYuBFMB4wZQBqppIn8K8+ 1BDpbKXwUTtHL2bMAqAfWPifoJaz5UzLZcNfV+olE2vJJ3h5W0KAjvlxtPbRCMV5 ZQBrNdzBp3iHLC5+YA4Iia7doVjbvAFk0iEVhOHe6dSJW5S7kppzU1iKj58s49Rh g2ky5dM2RbIm4XwuKmqdIaG7bXqUKUbpy0rmInnzCT65WdVRnlQWjCNbutag85pW SuPSE4AoPxyCZGSerZPfx1N93oESnK/auTvbxsBDTA0CbRnfxb5dyHCt/tT94PEb yt/+RpC8iybs7WPuaC7gBMgVha8z3pg6lUA8c0YzL1tB6CWYUxb7v1MR14kQH4LT iqttvmdtMQbnwh17KmhvJkUr9ozvYb0uLiBJcHSZIuKwT9L10JL1tPFbHRRsMLOz YSkGuUX+w+pgpUKDSZ8Tr8Fp8Qz5l59jE0E+LWZRPT+PRnobEsxRY09y =GmB8 -----END PGP PUBLIC KEY BLOCK----- From djm at mindrot.org Thu Mar 28 17:36:02 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Mar 2002 17:36:02 +1100 (EST) Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: <00cc01c1d2d4$ad3bc640$c33a080a@LUCKYVAIO> Message-ID: On Sat, 23 Mar 2002, Lucky Green wrote: > Although the full implications of the proposal were not necessarily > immediately apparent in the first few days following Bernstein's > publication, the incremental improvements to parts of NFS outlined in > the proposal turn out to carry significant practical security > implications impacting the overwhelming majority of deployed systems > utilizing RSA or DH as the public key algorithms. What incremental improvements? Bernstein is the first to point out that his improvement is asymptotic to key length. Can you offer evidence to the contrary? > Coincidentally, the day before the panel, Nicko van Someren announced at > the FC02 rump session that his team had built software which can factor > 512-bit RSA keys in 6 weeks using only hardware they already had in the > office. DES-56 can be cracked in less than a day, which does little to diminish 3DES' standing as a good, conservative cipher. > The panel, consisting of Ian Goldberg and Nicko van Someren, put forth > the following rough first estimates: > > While the interconnections required by Bernstein's proposed architecture > add a non-trivial level of complexity, as Bruce Schneier correctly > pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA > factoring device can likely be built using only commercially available > technology for a price range of several hundred million dollars to about > 1 billion dollars. Can you offer any analysis to back up this hyperbole? Furthermore, your paragraph could easily be misinterpreted to read that Schneier was stating that a 1024 bit RSA cracker is feasible. In fact, he states pretty much the opposite - that Bernstein's result has little effect on keysizes in regular use. [snip] > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: PGP 7.1 > Comment: Problems decrypting this email? Upgrade from PGP 1.x/2.x! ... Please don't abuse our mailing list to distribute your new key. -d From shamrock at cypherpunks.to Thu Mar 28 18:18:05 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Wed, 27 Mar 2002 23:18:05 -0800 Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: Message-ID: <000101c1d628$b613a060$c33a080a@LUCKYVAIO> Damien wrote: > On Sat, 23 Mar 2002, Lucky Green wrote: > > > Although the full implications of the proposal were not necessarily > > immediately apparent in the first few days following Bernstein's > > publication, the incremental improvements to parts of NFS > outlined in > > the proposal turn out to carry significant practical security > > implications impacting the overwhelming majority of > deployed systems > > utilizing RSA or DH as the public key algorithms. > > What incremental improvements? Bernstein is the first to > point out that his improvement is asymptotic to key length. > Can you offer evidence to the contrary? Are you disputing that Bernstein's paper offered improvements to the state-of-the-art in NFS-based factoring or are you disputing that the improvements are incremental? Either way, you would be wrong: - Improvements over the previously known state-of-the art: as you point out, Bernstein states that he found improvements to NFS that *asymptotically* may go as high as a factor of 3. If you knew about this improvement prior to Bernstein's publication, you are to be congratulated. Too bad you failed to publish. As for the remainder of the cryptographic community, I have not met a single person that had known about these improvements prior to Bernstein pointing them out. - Why the improvements are incremental, rather than revolutionary to the prior state-of-the-art in factoring: Bernstein did not propose a new approach to factoring, such as the move from the Quadratic Sieve to the General Number Field Sieve. Hence the improvements are incremental. > > Coincidentally, the day before the panel, Nicko van Someren > announced > > at the FC02 rump session that his team had built software which can > > factor 512-bit RSA keys in 6 weeks using only hardware they already > > had in the office. > > DES-56 can be cracked in less than a day, which does little to > diminish 3DES' standing as a good, conservative cipher. You point being? All that the paragraph you are quoting stated was that I had been unaware that 512-bit RSA keys can be factored using the hardware found in an office, with the most "specialized box", btw, being an Itanium with 1GB of RAM. Not exactly special-purpose equipment that's hard to come by. If you were attempting to imply that the paragraph was meant as supporting evidence for the 1024-bit factoring issues mentioned later in my post, I would encourage you to look up the word "coincidentally" in a dictionary. > > The panel, consisting of Ian Goldberg and Nicko van > Someren, put forth > > the following rough first estimates: > > > > While the interconnections required by Bernstein's proposed > > architecture add a non-trivial level of complexity, as > Bruce Schneier > > correctly pointed out in his latest CRYPTOGRAM newsletter, > a 1024-bit > > RSA factoring device can likely be built using only commercially > > available technology for a price range of several hundred million > > dollars to about 1 billion dollars. > > Can you offer any analysis to back up this hyperbole? Hyperbole. Hmm, we are moving on to big words now. Are you sure you are ready to use such words when you don't even know what coincidentally means? My post made it clear to those versed in the English language that I was simply reporting on the analyses presented by a panel that I happened to moderate. Which, in case the reader is unfamiliar with what the word moderate means, equates to ensuring that the panelists all get chance to speak and don't stray too far off topic. The results reported are not the results of my research. I therefore will leave it to the researchers to post the details of the analysis once they are written up in the customary form. (Which is not to say that such details had not been provided, I simply don't believe it is my role or right to publish the details of others' research). > Furthermore, your paragraph could easily be misinterpreted to > read that > Schneier was stating that a 1024 bit RSA cracker is feasible. > In fact, he states pretty much the opposite - that > Bernstein's result has little effect on keysizes in regular use. English language hint #3: note the two commas used in the sentence to which you are referring. Then find a book on elementary English grammar to determine what their purpose might have been. As a general note, you might find that future comments directed at me and others stand a good chance of leading to more fruitful discussion that in turn will be more pleasing to you if your inquiries were to take a less a hostile and accusatory tone. --Lucky From mupitt at yahoo.com Thu Mar 28 19:13:49 2002 From: mupitt at yahoo.com (Mark Pitt) Date: Thu, 28 Mar 2002 00:13:49 -0800 (PST) Subject: DISPLAY=unix:10.0 and localhost blues Message-ID: <20020328081349.42155.qmail@web10104.mail.yahoo.com> I have just finished battling with this and noticed it has been reported on HP systems too. Problem ist, if you have an sshrc file with: XKEY=`cat -` -n "$DISPLAY" && $XAUTH add $DISPLAY $XKEY then with SSH 3.1 this mysteriously fails, as the DISPLAY is now localhost:10.0 instead of $HOST:10.0 I imagine the reasoning behind the change is to accomodate hosts that have no reachable hostname interfaces - and that certainly helps us, but it DOES require some docu ! I have two bugs/features I would like to submit as diff - what do I have to do with diff ? thanks __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards? http://movies.yahoo.com/ From tomh at po.crl.go.jp Thu Mar 28 19:51:39 2002 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Thu, 28 Mar 2002 17:51:39 +0900 (JST) Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: <000101c1d628$b613a060$c33a080a@LUCKYVAIO> Message-ID: You know, Lucky, most of the people here have been around the block a few times, and your previous post is just classic Usenet whinage. Complaining about puncuation indeed. Spare us, please. Look, we've all read the background. The improvement is a function f(n) which for large n may approach 3. What is f(1024)? I don't know, do you? Your original post might have merit if f(1024) is also close to 3 or more, but it may be very much less. Here's a real question: if you could build a special purpose machine to do 1024 bit RSA keys (that is, factor a 1024 bit number), how much would that help with discrete logs in a safe prime field? Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ From bordewijk at fox-it.com Thu Mar 28 19:55:49 2002 From: bordewijk at fox-it.com (Lourens Bordewijk) Date: Thu, 28 Mar 2002 09:55:49 +0100 Subject: Openssh + challenge-response Message-ID: Hello, I was searching the internet for an challenge-response system to authenticate an Openssh session with an hardware token. Now i found this, its very old, so i want to now how's the situation today. I couldn't find much documentation. Re: SSH with SecureID > Is there any documentation I'm missing on how to integrate the two? > We'd love to go with 2-factor authentication, but we want to make > sure our traffic remains encrypted. Any solutions? > >We are doing exactly such thing. I did not want to make mistake of most challenge responce systems which run in clear-text on insecure solaris machines (god knows I seen many of > those). We are using Cryptocard from -- the challenge response system is working over ssh using TIS Authentication. All windows people have to use >SecureCRT since F-Secure windows client does not do TIS. Unix does it by default (just -o 'TISAuthenticaion yes'). So you get: 63-jkb(nautilus)% ssh proxy Challenge: 05293424 >Enter Response: We are running the system on FreeBSD and use radius -- so sshd in fact becomes radius client when it needs to authenticate. So far everything seem to work just >great. Feel free to ask me in private if you need more details/info. Thanks, I read that it worked with openssh (that there are patches for it), If it's posible , what's the safest hardware token that i can/should i use? Activcard One? Cryptocard ? Is there a document that explains exactly the situation i want to use or how i can implement it ? Thanx in advance, Lourens bordewijk From daniel.mayoss at nokia.com Thu Mar 28 19:03:16 2002 From: daniel.mayoss at nokia.com (Daniel Mayoss) Date: Thu, 28 Mar 2002 10:03:16 +0200 Subject: redhat 6.1 and openssh 3.1p1 Message-ID: <3CA2CE42.AAD455B@nokia.com> Hi, I *really* hope this hasn't been fixed before, but I have a problem which appears to be a bug in openSSH 3.1p1 Basically, it doesn't work... sshd runs fine, root can log in fine, but a normal user cannot. The error given to the user is simply 'permission denied' I'm running a plain vanilla redhat 6.1 (a bit old, I know) with openSSL as the SSL implementation. I installed a different ssh implementation (from ftp.ssh.fi - I compiled both, actually) and that works fine with all users. Here is the debug output from sshd: debug2: input_userauth_request: setting up authctxt for daniel debug2: input_userauth_request: try method none Failed none for daniel from 172.21.97.161 port 2418 ssh2 debug1: userauth-request for user daniel service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs Failed keyboard-interactive for daniel from 172.21.97.161 port 2418 ssh2 debug1: userauth-request for user daniel service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Failed password for daniel from 172.21.97.161 port 2418 ssh2 debug1: userauth-request for user daniel service ssh-connection method password debug1: attempt 3 failures 3 debug2: input_userauth_request: try method password Failed password for daniel from 172.21.97.161 port 2418 ssh2 debug1: userauth-request for user daniel service ssh-connection method password debug1: attempt 4 failures 4 debug2: input_userauth_request: try method password Failed password for daniel from 172.21.97.161 port 2418 ssh2 Connection closed by 172.21.97.161 debug1: Calling cleanup 0x806397c(0x0) From bugzilla-daemon at mindrot.org Thu Mar 28 21:06:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 21:06:32 +1100 (EST) Subject: [Bug 181] Undocumented mget and mput in sftp Message-ID: <20020328100632.4A242EA95@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=181 ------- Additional Comments From markus at openbsd.org 2002-03-28 21:06 ------- i don't like to see mget and mput in sftp. it's such an ugly user interface ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From hin at stacken.kth.se Thu Mar 28 21:30:44 2002 From: hin at stacken.kth.se (Hans Insulander) Date: 28 Mar 2002 11:30:44 +0100 Subject: Using kerberized SSHD. Question. In-Reply-To: Austin Gonyou's message of "25 Mar 2002 16:58:31 -0600" References: <1017097111.6001.43.camel@UberGeek> Message-ID: <86n0wt2dd7.fsf@hink.hin.nu> Austin Gonyou writes: > I have a kerberized SSHD installed on HOST-1, a login server for the > outside world. > > How can I make it so users are still authenticated via kerberos, even > though they haven't yet received a ticket? > > The main reason for this is that a user who is at home, no vpn, but has > an ssh client could then login and be authenticated by kerberos using > password authentication, get a ticket, then be allowed to ssh(at this > point using a kerberized ssh client) to any kerberized sshd host, > without entering a password. > > Is this possible? TIA This should work out of the box. At least it does for me, on a daily basis, exactly as you describe it. -- --- Hans Insulander , SM0UTY ----------------------- If I've had a dollar for every promise of help from people who've read [ my list of tricky things to fix in OpenBSD ] I would have ... well, at least a few beers. -- Artur Grabowski From bugzilla-daemon at mindrot.org Thu Mar 28 22:48:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Mar 2002 22:48:51 +1100 (EST) Subject: [Bug 194] New: still problems with libutil Message-ID: <20020328114851.5BA6DEAA9@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=194 Summary: still problems with libutil Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dh at onclick.org Sorry that I don't get it but I can't compile the portable OpenSSH since 3.0 up to the SNAP of 27.03.2002 (about a year now, am really in trouble!). I always stumble over libutil not being able to reference atexit. You now offer the option: --disable-libutil but it does not help. At the end of the configure process the list shows up: Libraries: -lutil -lz -lnsl -lcrypto -lcrypt This may be the reason for that: checking for libutil.h... no checking for library containing login... -lutil I don't really get through that. This is ahead of my knowledge. But I am really wondering why it happens because on my system atexit is defined in either stdlib.h or stdio.h (this one, I think). I used atexit and it works fine for me. Because both headers are standards they must be included in your product at all, so why libutil can't find atexit? Is it a problem of autoconf? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Thu Mar 28 23:02:39 2002 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Mar 2002 23:02:39 +1100 (EST) Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: <000101c1d628$b613a060$c33a080a@LUCKYVAIO> Message-ID: On Wed, 27 Mar 2002, Lucky Green wrote: > > What incremental improvements? Bernstein is the first to > > point out that his improvement is asymptotic to key length. > > Can you offer evidence to the contrary? > > Are you disputing that Bernstein's paper offered improvements to the > state-of-the-art in NFS-based factoring or are you disputing that the > improvements are incremental? I am disputing that the improvements as presented are practically relevant. Since you saw fit to cross-post to openssh-unix-dev@, which is a list concerned with code (not polemic), that is the context in which I chose to frame my reply. > > > Coincidentally, the day before the panel, Nicko van Someren > > announced > > > at the FC02 rump session that his team had built software which can > > > factor 512-bit RSA keys in 6 weeks using only hardware they already > > > had in the office. > > > > DES-56 can be cracked in less than a day, which does little to > > diminish 3DES' standing as a good, conservative cipher. > > You point being? All that the paragraph you are quoting stated was that > I had been unaware that 512-bit RSA keys can be factored using the > hardware found in an office, with the most "specialized box", btw, being > an Itanium with 1GB of RAM. Not exactly special-purpose equipment that's > hard to come by. If you were attempting to imply that the paragraph was > meant as supporting evidence for the 1024-bit factoring issues mentioned > later in my post, I would encourage you to look up the word > "coincidentally" in a dictionary. You offer this aside in the context of an argument against the insufficiency of 1024 bit RSA keys. Surely you don't expect people to believe that you weren't including it to bolster your argument? > > > The panel, consisting of Ian Goldberg and Nicko van > > Someren, put forth > > > the following rough first estimates: > > > > > > While the interconnections required by Bernstein's proposed > > > architecture add a non-trivial level of complexity, as > > Bruce Schneier > > > correctly pointed out in his latest CRYPTOGRAM newsletter, > > a 1024-bit > > > RSA factoring device can likely be built using only commercially > > > available technology for a price range of several hundred million > > > dollars to about 1 billion dollars. > > > > Can you offer any analysis to back up this hyperbole? > > Hyperbole. Hmm, we are moving on to big words now. Are you sure you are > ready to use such words when you don't even know what coincidentally > means? Wow, you go from poorly-supported rant to ad-hominem in no time. No doubt you will retort by labeling me as one of those "captive security consultants" that you included in your little dissent-squashing preemptive. You post is hyperbole because it is very long on verbiage and very short on justification. Large claims require a good amount of proof: If you expect everyone to switch to 2048 bit keys on the basis of your rant alone, you may be disappointed. > My post made it clear to those versed in the English language that I was > simply reporting on the analyses presented by a panel that I happened to > moderate. Which, in case the reader is unfamiliar with what the word > moderate means, equates to ensuring that the panelists all get chance to > speak and don't stray too far off topic. The results reported are not > the results of my research. I therefore will leave it to the researchers > to post the details of the analysis once they are written up in the > customary form. (Which is not to say that such details had not been > provided, I simply don't believe it is my role or right to publish the > details of others' research). Please get back to us when such research is published. Until then, I'll treat you argument with the credence that it deserves. > > Furthermore, your paragraph could easily be misinterpreted to > > read that > > Schneier was stating that a 1024 bit RSA cracker is feasible. > > In fact, he states pretty much the opposite - that > > Bernstein's result has little effect on keysizes in regular use. > > English language hint #3: note the two commas used in the sentence to > which you are referring. Then find a book on elementary English grammar > to determine what their purpose might have been. The irony is amusing: you write a five line mess of ambiguity and then accuse me of a lack of grammar skills. > As a general note, you might find that future comments directed at me > and others stand a good chance of leading to more fruitful discussion > that in turn will be more pleasing to you if your inquiries were to take > a less a hostile and accusatory tone. As a general note, you find that people are willing to give much more attention to your arguments when they are backed up with facts or solid analysis (rather than carefully constructed rhetoric) and don't come with 50kb of crap on the end. -d From return at trafficmagnet.net Fri Mar 29 01:18:50 2002 From: return at trafficmagnet.net (Christine Hall) Date: Thu, 28 Mar 2002 22:18:50 +0800 (CST) Subject: http://www.openssh.org Message-ID: <45CR1000045201@emaserver.trafficmagnet.net> Hi I visited http://www.openssh.org, and noticed that you're not listed on some search engines! I think we can offer you a service which can help you increase traffic and the number of visitors to your website. I would like to introduce you to TrafficMagnet.net. We offer a unique technology that will submit your website to over 300,000 search engines and directories every month. You'll be surprised by the low cost, and by how effective this website promotion method can be. To find out more about TrafficMagnet and the cost for submitting your website to over 300,000 search engines and directories, visit www.TrafficMagnet.net. I would love to hear from you. Best Regards, Christine Hall Sales and Marketing E-mail: christine at trafficmagnet.net http://www.TrafficMagnet.net This email was sent to openssh-unix-dev at mindrot.org. I understand that you may NOT wish to receive information from me by email. To be removed from this and other offers, simply go to the link below: http://emaserver.trafficmagnet.net/trafficmagnet/www/optoutredirect?UC=Lead&UI=350892 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020328/bbb0d5c8/attachment.html From reskusic at uiuc.edu Fri Mar 29 03:59:49 2002 From: reskusic at uiuc.edu (Raymond M. Reskusich) Date: Thu, 28 Mar 2002 10:59:49 -0600 Subject: [PATCH] Feature addition: user access control per auth method Message-ID: <20020328165947.GA27290@hume.cso.uiuc.edu> I added a few features to openssh for my local use that I think would be more broadly useful. I basically added access control lists to control who would be allowed public key authentication. I added four config file entries for the server: PubkeyAllowUsers PubkeyDenyUsers PubkeyAllowGroups PubkeyDenyGroups These follow the same sematics as the already existing entries for allowing logins. So far I have this implemented for SSH2 pubkey auth, but I coded it to make adding corresponding entries for any auth method easy. I'd be happy to do so if this was desired. I'm not sure if there is any interest this functionality, but I've been wanting it for a while. In particular, it's helpful to allow pubkey auth for trusted users and trusted system, while not allowing the other 10000 users to make it into another .rhosts. Below I've attached a patch for this feature off of V_3_1_P1. I'd appreciate any feedback. Raymond M. Reskusich reskusic at uiuc.edu Index: auth.c =================================================================== RCS file: /cvs/openssh/auth.c,v retrieving revision 1.45 diff -u -r1.45 auth.c --- auth.c 5 Mar 2002 01:42:43 -0000 1.45 +++ auth.c 28 Mar 2002 16:44:29 -0000 @@ -197,6 +197,80 @@ return 1; } +/* + * Check if the user is allowed to login with a given method. + * If the user is in DenyUsers or his group is in DenyGroups, + * return false. + * If AllowUsers is non-empty, and doesn't contain the user, return + * false. + * If AllowGroups is non-empty, and doesn't contain the user's group + * return false. + * Otherwise, return true. + */ +int auth_allowed_user(struct passwd *pw, Authaccess access) +{ + const char *hostname = NULL, *ipaddr = NULL; + int i; + + if (!pw || !pw->pw_name) + return 0; + + if (access.num_deny_users > 0 || access.num_allow_users > 0) { + hostname = get_canonical_hostname(options.verify_reverse_mapping); + ipaddr = get_remote_ipaddr(); + } + + /* Return false if user is listed in DenyUsers */ + if (access.num_deny_users > 0) { + for (i = 0; i < access.num_deny_users; i++) + if (match_user(pw->pw_name, hostname, ipaddr, + access.deny_users[i])) + return 0; + } + + /* Return false if AllowUsers is non-empty, and user is not listed */ + if (access.num_allow_users > 0) { + for (i = 0; i < access.num_allow_users; i++) + if (match_user(pw->pw_name, hostname, ipaddr, + access.allow_users[i])) + break; + /* i < access.num_allow_users iff we break for loop */ + if ( i >= access.num_allow_users) + return 0; + } + + if (access.num_allow_groups > 0 || access.num_deny_groups > 0) { + /* load up the user's group list */ + if (ga_init(pw->pw_name, pw->pw_gid) == 0) + return 0; + + /* return false if the user is in a denied group */ + if (access.num_deny_groups > 0) + if (ga_match(access.deny_groups, + access.num_deny_groups)) { + ga_free(); + return 0; + } + + /* + * Return false if the allowed groups are specified and the + * user is not in one + */ + if (access.num_allow_groups > 0) + if (!ga_match(access.allow_groups, + access.num_allow_groups)) { + ga_free(); + return 0; + } + + ga_free(); + } + + /* We have no reason to deny the user authentication */ + return 1; + +} + Authctxt * authctxt_new(void) { Index: auth.h =================================================================== RCS file: /cvs/openssh/auth.h,v retrieving revision 1.30 diff -u -r1.30 auth.h --- auth.h 5 Mar 2002 01:53:04 -0000 1.30 +++ auth.h 28 Mar 2002 16:44:29 -0000 @@ -43,6 +43,7 @@ #endif typedef struct Authctxt Authctxt; +typedef struct Authaccess Authaccess; typedef struct KbdintDevice KbdintDevice; struct Authctxt { @@ -71,6 +72,19 @@ #endif }; +/* holds the access lists for a given auth method */ +struct Authaccess { + int num_allow_users; + char **allow_users; + int num_deny_users; + char **deny_users; + int num_allow_groups; + char **allow_groups; + int num_deny_groups; + char **deny_groups; +}; + + /* * Keyboard interactive device: * init_ctx returns: non NULL upon success @@ -133,6 +147,7 @@ void auth2_challenge_stop(Authctxt *); int allowed_user(struct passwd *); +int auth_allowed_user(struct passwd *, Authaccess); char *get_challenge(Authctxt *); int verify_response(Authctxt *, const char *); Index: auth2.c =================================================================== RCS file: /cvs/openssh/auth2.c,v retrieving revision 1.91 diff -u -r1.91 auth2.c --- auth2.c 26 Feb 2002 18:09:43 -0000 1.91 +++ auth2.c 28 Mar 2002 16:44:29 -0000 @@ -51,6 +51,7 @@ #include "hostfile.h" #include "canohost.h" #include "match.h" +#include "groupaccess.h" /* import */ extern ServerOptions options; @@ -85,6 +86,7 @@ static int userauth_pubkey(Authctxt *); static int userauth_hostbased(Authctxt *); static int userauth_kbdint(Authctxt *); +static int pubkey_allowed_user(struct passwd *); Authmethod authmethods[] = { {"none", @@ -408,6 +410,13 @@ debug2("userauth_pubkey: disabled because of invalid user"); return 0; } + + /* check to see if the user is allowed to use pubkey authentication */ + if (!pubkey_allowed_user(authctxt->pw)) { + debug2("userauth_pubkey: user not allowed pubkey auth"); + return 0; + } + have_sig = packet_get_char(); if (datafellows & SSH_BUG_PKAUTH) { debug2("userauth_pubkey: SSH_BUG_PKAUTH"); @@ -796,3 +805,24 @@ return (host_status == HOST_OK); } + + +/* + * Check if the user is allowed to log in with public key authentication. + */ +static int pubkey_allowed_user(struct passwd *pw) +{ + Authaccess access; + + access.num_allow_users = options.num_pkey_allow_users; + access.allow_users = options.pkey_allow_users; + access.num_deny_users = options.num_pkey_deny_users; + access.deny_users = options.pkey_deny_users; + access.num_allow_groups = options.num_pkey_allow_groups; + access.allow_groups = options.pkey_allow_groups; + access.num_deny_groups = options.num_pkey_deny_groups; + access.deny_groups = options.pkey_deny_groups; + + return auth_allowed_user(pw, access); +} + Index: servconf.c =================================================================== RCS file: /cvs/openssh/servconf.c,v retrieving revision 1.77 diff -u -r1.77 servconf.c --- servconf.c 5 Feb 2002 01:26:35 -0000 1.77 +++ servconf.c 28 Mar 2002 16:44:29 -0000 @@ -96,6 +96,10 @@ options->num_deny_users = 0; options->num_allow_groups = 0; options->num_deny_groups = 0; + options->num_pkey_allow_users = 0; + options->num_pkey_deny_users = 0; + options->num_pkey_allow_groups = 0; + options->num_pkey_deny_groups = 0; options->ciphers = NULL; options->macs = NULL; options->protocol = SSH_PROTO_UNKNOWN; @@ -267,7 +271,8 @@ sBanner, sVerifyReverseMapping, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, - sDeprecated + sDeprecated, sPubkeyAllowUsers, sPubkeyDenyUsers, + sPubkeyAllowGroups, sPubkeyDenyGroups } ServerOpCodes; /* Textual representation of the tokens. */ @@ -342,6 +347,10 @@ { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "pubkeyallowusers", sPubkeyAllowUsers }, + { "pubkeydenyusers", sPubkeyDenyUsers }, + { "pubkeyallowgroups", sPubkeyAllowGroups }, + { "pubkeydenygroups", sPubkeyDenyGroups }, { NULL, sBadOption } }; @@ -751,6 +760,43 @@ fatal("%s line %d: too many deny groups.", filename, linenum); options->deny_groups[options->num_deny_groups++] = xstrdup(arg); + } + break; + + + case sPubkeyAllowUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_pkey_allow_users >= MAX_ALLOW_USERS) + fatal("%s line %d: too many public key allow users.", + filename, linenum); + options->pkey_allow_users[options->num_pkey_allow_users++] = xstrdup(arg); + } + break; + + case sPubkeyDenyUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_pkey_deny_users >= MAX_DENY_USERS) + fatal( "%s line %d: too many public key deny users.", + filename, linenum); + options->pkey_deny_users[options->num_pkey_deny_users++] = xstrdup(arg); + } + break; + + case sPubkeyAllowGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_pkey_allow_groups >= MAX_ALLOW_GROUPS) + fatal("%s line %d: too many public key allow groups.", + filename, linenum); + options->pkey_allow_groups[options->num_pkey_allow_groups++] = xstrdup(arg); + } + break; + + case sPubkeyDenyGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_pkey_deny_groups >= MAX_DENY_GROUPS) + fatal("%s line %d: too many public key deny groups.", + filename, linenum); + options->pkey_deny_groups[options->num_pkey_deny_groups++] = xstrdup(arg); } break; Index: servconf.h =================================================================== RCS file: /cvs/openssh/servconf.h,v retrieving revision 1.45 diff -u -r1.45 servconf.h --- servconf.h 5 Mar 2002 01:53:05 -0000 1.45 +++ servconf.h 28 Mar 2002 16:44:29 -0000 @@ -107,6 +107,14 @@ char *allow_groups[MAX_ALLOW_GROUPS]; u_int num_deny_groups; char *deny_groups[MAX_DENY_GROUPS]; + u_int num_pkey_allow_users; + char *pkey_allow_users[MAX_ALLOW_USERS]; + u_int num_pkey_deny_users; + char *pkey_deny_users[MAX_DENY_USERS]; + u_int num_pkey_allow_groups; + char *pkey_allow_groups[MAX_ALLOW_GROUPS]; + u_int num_pkey_deny_groups; + char *pkey_deny_groups[MAX_DENY_GROUPS]; u_int num_subsystems; char *subsystem_name[MAX_SUBSYSTEMS]; From fcusack at fcusack.com Fri Mar 29 06:13:33 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 28 Mar 2002 11:13:33 -0800 Subject: [PATCH] Feature addition: user access control per auth method In-Reply-To: <20020328165947.GA27290@hume.cso.uiuc.edu>; from reskusic@uiuc.edu on Thu, Mar 28, 2002 at 10:59:49AM -0600 References: <20020328165947.GA27290@hume.cso.uiuc.edu> Message-ID: <20020328111333.R31359@google.com> On Thu, Mar 28, 2002 at 10:59:49AM -0600, Raymond M. Reskusich wrote: > I added a few features to openssh for my local use that I think would > be more broadly useful. I basically added access control lists to > control who would be allowed public key authentication. I added four > config file entries for the server: > > PubkeyAllowUsers > PubkeyDenyUsers > PubkeyAllowGroups > PubkeyDenyGroups [...] IMHO, this is better done with the PAMAcctService proposal from a week ago. Of course, yours is better in that there's actual code. :-) /fc From fcusack at fcusack.com Fri Mar 29 06:21:56 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 28 Mar 2002 11:21:56 -0800 Subject: Openssh + challenge-response In-Reply-To: ; from bordewijk@fox-it.com on Thu, Mar 28, 2002 at 09:55:49AM +0100 References: Message-ID: <20020328112155.S31359@google.com> On Thu, Mar 28, 2002 at 09:55:49AM +0100, Lourens Bordewijk wrote: > Hello, > > I was searching the internet for an challenge-response system to > authenticate an Openssh session with an hardware token. Now i found this, > its very old, so i want to now how's the situation today. I couldn't find > much documentation. [...] > I read that it worked with openssh (that there are patches for it), If it's > posible , what's the safest hardware token that i can/should i use? > Activcard One? Cryptocard ? Is there a document that explains exactly the > situation i want to use or how i can implement it ? Your question is off topic for openssh, but that said, there probably are folks here with good experience with those cards. SecurID is probably the easiest (for you and your users). Cryptocard is probably the cheapest. Activcard is probably the hardest to implement. I'd say they are all within the realm of "good". Don't use challenge response mode with cryptocard if you wish to protect against an attacker that can break DES. Your users won't like challenge/response mode anyway. Funny thing, cryptocard can store 3 keys and so could do 3DES if they wanted, or they could do a 2-key scheme which is unbreakable with any computing power. Oh well. I think I'll patent that and license it back to them. :-\ /fc From kevin at atomicgears.com Fri Mar 29 06:24:13 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Thu, 28 Mar 2002 11:24:13 -0800 (PST) Subject: DISPLAY=unix:10.0 and localhost blues In-Reply-To: <20020328081349.42155.qmail@web10104.mail.yahoo.com> Message-ID: On Thu, 28 Mar 2002, Mark Pitt wrote: :I have just finished battling with this and noticed it :has been reported on HP systems too. : :Problem ist, if you have an sshrc file with: : :XKEY=`cat -` : :-n "$DISPLAY" && $XAUTH add $DISPLAY $XKEY : :then with SSH 3.1 this mysteriously fails, as the :DISPLAY is now localhost:10.0 instead of $HOST:10.0 : :I imagine the reasoning behind the change is to :accomodate hosts that have no reachable hostname :interfaces - and that certainly helps us, but it DOES :require some docu ! the 3.1 release notes covered the change. see sshd X11UseLocalhost. i will try to add something to the sshrc example. do you have some suggestions? :I have two bugs/features I would like to submit as :diff - what do I have to do with diff ? you can send them to the list, or if you don't want them lost/forgotten use bugzilla.mindrot.org. From shamrock at cypherpunks.to Fri Mar 29 07:57:26 2002 From: shamrock at cypherpunks.to (Lucky Green) Date: Thu, 28 Mar 2002 12:57:26 -0800 Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: Message-ID: <002601c1d69b$2acb3540$c33a080a@LUCKYVAIO> [OK, let me try this again, since we clearly got off on the wrong foot here. My apologies for overreacting to Damien's post; I have been receiving dozens of emails from the far corners of the Net over the last few days that alternatively claimed that I was a stooge of the NSA because everybody knows that 8k RSA keys can be factored in real-time or that 512-bit RSA keys were untouchable since nobody could perform even perform an exhaustive search of a 128-bit key space...] Damien wrote: > I am disputing that the improvements as presented are > practically relevant. Since you saw fit to cross-post to > openssh-unix-dev@, which is a list concerned with code (not > polemic), that is the context in which I chose to frame my reply. My post reported on what was announced at an academic cryptographic conference by a cryptographer that has written peer-reviewed papers on the design of large-scale cryptographic processing machines in the past. (I.e. how one would in practice build one of Rivest's MicroMint machines). I believe my relaying these claims was responsible given the potentially massive security implications to a good part of the infrastructure. In addition, a reporter for the Financial Times was present at the same event who announced his intent to write about it as well. Nowhere in the post did I make, or intent to make, claims of my own as to the impact of Bernstein's paper on factoring. I did report on my reaction to the claims which I witnessed and on which I therefore reported. My reaction to those claims was to create larger keys. Other may choose to react differently. Furthermore, I provided those concerned with the new claims with what I believe are sound recommendations how to counter the potential thread. Which was to increase the key size. [On Nicko's rump session talk that they factored 512-bit keys on the hardware in their office]. > You offer this aside in the context of an argument against > the insufficiency of 1024 bit RSA keys. Surely you don't > expect people to believe that you weren't including it to > bolster your argument? To be perfectly honest, the thought that somebody on a mailing list related to cryptographic software would consider my reporting on the news that somebody factored 512-bit keys on the computers in their office would believe I meant to imply this to have any bearing on a potential ability to factor 1024-bit keys on purpose-built hardware never even occurred to me. I really, really meant coincidentally when I wrote coincidentally. The two news came within a day of each other, so while reporting on one of the news, I thought I'd make mention of the other news as well. That's all. Well, on second thought I suppose there actually is an, albeit removed, connection between the two: many sites still use 512-bit keys; even if one is unconcerned about 1024-bit keys being breakable, hopefully those with 512-bit keys will take the fact that 512-bit keys can be broken by some office hardware as a reason to upgrade key sizes. [...] > You post is hyperbole because it is very long on verbiage and > very short on justification. Large claims require a good > amount of proof: If you expect everyone to switch to 2048 bit > keys on the basis of your rant alone, you may be disappointed. I don't really personally care what key sizes others use. For all I care, others are welcome to employ 4-bit RSA keys, as long as they don't use those keys to authenticate themselves to any of the machines under my control. Which brings me to an issue that I hope may be on-topic to this mailing list: I would like to be able to enforce that the keys my users can use to authenticate themselves to my sshd to be of a minimum size. Is there a config option to sshd that will reject user keys below a minimum size? I didn't see anything in the man pages or my first go through the code. Thanks in advance, --Lucky From kevin at atomicgears.com Fri Mar 29 08:25:43 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Thu, 28 Mar 2002 13:25:43 -0800 (PST) Subject: Trusted HP-UX 10.26 In-Reply-To: <030701c1d4ff$a9b25430$9b78a8c0@oedserver> Message-ID: On Tue, 26 Mar 2002, Darren Cole wrote: :> i don't understand this. why do you need the hashed password here? :> openssh works today with hp-ux commercial security--why is CMW different? :> see auth-passwd.c. also, why did you change only auth2.c and not auth1.c? : :I need the password here because I found that sshd would fail otherwise. :The normal getpwnam does not get the password. Further down (not shown in :the patch) there is a line: authenticated = m->userauth(authtxt); :authtxt now has the password information. Without the getprpwnam call, :authtxt wont get the encrypted password. you should look at auth_password(); there is already hp-ux code there doing most of what you need. auth2 should not be changed. :Hmm... Now that I know a bit more about autoconf, I see how I could make :HAVE_SCO_PROTECTED_PW be defined on trusted hp-ux. Then I could move this :functionality to auth-passwd.c. Thanks, I will try that before I post my :next try at the patch. :I didn't look at auth1.c because it didn't fail in my testing. (though it :probably would have if I had tested using ssh1 protocal). : :> :diff -cr openssh-3.1p1.orig/session.c openssh-3.1p1/session.c :> :*** openssh-3.1p1.orig/session.c Mon Feb 25 15:48:03 2002 :> :--- openssh-3.1p1/session.c Fri Mar 22 22:56:30 2002 :> :*************** :> :*** 1285,1291 **** :> :--- 1285,1297 ---- :> : #ifdef LOGIN_NEEDS_TERM :> : (s->term ? s->term : "unknown"), :> : #endif /* LOGIN_NEEDS_TERM */ :> :+ #ifdef TRUSTED_HPUX :> :+ // the "--" makes login hang on Trusted HP-UX :> :+ // 10.26 :> :+ "-p", "-f", pw->pw_name, (char *)NULL); :> :+ #else :> : "-p", "-f", "--", pw->pw_name, (char *)NULL); :> :+ #endif :> : :> : /* Login couldn't be executed, die. */ :> :> do you require UseLogin yes? : :Yes. It seems much easier to let login taking care of checking and setting :all that needs to be done on a CMW, instead of duplicating all of that work :and code. login doesn't use getopt()? From amoustafa at pobox.com Fri Mar 29 08:53:15 2002 From: amoustafa at pobox.com (Ahmed Moustafa) Date: Thu, 28 Mar 2002 13:53:15 -0800 Subject: Trigger a program after sftp Message-ID: <000501c1d6a2$f71d67b0$5846d10a@annd.ca.kp.org> How can I hack OpenSSH to make it trigger a program after a file transmission is completed via sftp? --Ahmed Moustafa From kevin at atomicgears.com Fri Mar 29 09:04:23 2002 From: kevin at atomicgears.com (Kevin Steves) Date: Thu, 28 Mar 2002 14:04:23 -0800 (PST) Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: <002601c1d69b$2acb3540$c33a080a@LUCKYVAIO> Message-ID: On Thu, 28 Mar 2002, Lucky Green wrote: :Which brings me to an issue that I hope may be on-topic to this mailing :list: I would like to be able to enforce that the keys my users can use :to authenticate themselves to my sshd to be of a minimum size. Is there :a config option to sshd that will reject user keys below a minimum size? :I didn't see anything in the man pages or my first go through the code. no config option, but this change will be in the next release: RCS file: /usr/OpenBSD/cvs/src/usr.bin/ssh/auth-rsa.c,v retrieving revision 1.53 retrieving revision 1.54 diff -u -r1.53 -r1.54 --- src/usr.bin/ssh/auth-rsa.c 2002/03/25 09:21:13 1.53 +++ src/usr.bin/ssh/auth-rsa.c 2002/03/26 23:13:03 1.54 @@ -14,7 +14,7 @@ */ #include "includes.h" -RCSID("$OpenBSD: auth-rsa.c,v 1.53 2002/03/25 09:21:13 markus Exp $"); +RCSID("$OpenBSD: auth-rsa.c,v 1.54 2002/03/26 23:13:03 markus Exp $"); #include #include @@ -77,6 +77,13 @@ u_char buf[32], mdbuf[16]; MD5_CTX md; int len; + + /* don't allow short keys */ + if (BN_num_bits(key->rsa->n) < 768) { + error("auth_rsa_verify_response: n too small: %d bits", + BN_num_bits(key->rsa->n)); + return (0); + } /* The response is MD5 of decrypted challenge plus session id. */ len = BN_num_bytes(challenge); From djm at mindrot.org Fri Mar 29 11:11:53 2002 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Mar 2002 11:11:53 +1100 (EST) Subject: 1024-bit RSA keys in danger of compromise In-Reply-To: <002601c1d69b$2acb3540$c33a080a@LUCKYVAIO> Message-ID: On Thu, 28 Mar 2002, Lucky Green wrote: > [OK, let me try this again, since we clearly got off on the wrong foot > here. My apologies for overreacting to Damien's post; I have been > receiving dozens of emails from the far corners of the Net over the last > few days that alternatively claimed that I was a stooge of the NSA > because everybody knows that 8k RSA keys can be factored in real-time or > that 512-bit RSA keys were untouchable since nobody could perform even > perform an exhaustive search of a 128-bit key space...] Likewise, my apologies for being so irritable. You post arrived at the end of a very bad week... > Damien wrote: > > I am disputing that the improvements as presented are > > practically relevant. Since you saw fit to cross-post to > > openssh-unix-dev@, which is a list concerned with code (not > > polemic), that is the context in which I chose to frame my reply. > > My post reported on what was announced at an academic cryptographic > conference by a cryptographer that has written peer-reviewed papers on > the design of large-scale cryptographic processing machines in the past. > (I.e. how one would in practice build one of Rivest's MicroMint > machines). I believe my relaying these claims was responsible given the > potentially massive security implications to a good part of the > infrastructure. In addition, a reporter for the Financial Times was > present at the same event who announced his intent to write about it as > well. > > Nowhere in the post did I make, or intent to make, claims of my own as > to the impact of Bernstein's paper on factoring. I did report on my > reaction to the claims which I witnessed and on which I therefore > reported. My reaction to those claims was to create larger keys. Other > may choose to react differently. Furthermore, I provided those concerned > with the new claims with what I believe are sound recommendations how to > counter the potential thread. Which was to increase the key size. Your arguments would have been better received if you referred to a published or forthcoming paper which included the supporting cost estimates. It is frustrating to hear news that XXX may be insecure without the necessary information to allow oneself to form an opinion. We get this all the time - usually it is skript kiddies who have some supposed sshd exploit :) > Which brings me to an issue that I hope may be on-topic to this mailing > list: I would like to be able to enforce that the keys my users can use > to authenticate themselves to my sshd to be of a minimum size. Is there > a config option to sshd that will reject user keys below a minimum size? > I didn't see anything in the man pages or my first go through the code. As Kevin mentioned, the next release places a lower bound of 768 bits on the size of RSA keys we will accept. We have a natural aversion to adding more config options (more options == more bugs), but I'm sure if evidence came out that key sizes < x bits were insecure we would either up the limit, or make an option. -d From dcole at keysoftsys.com Fri Mar 29 11:07:39 2002 From: dcole at keysoftsys.com (Darren Cole) Date: Thu, 28 Mar 2002 16:07:39 -0800 Subject: Trusted HP-UX 10.26 References: Message-ID: <016501c1d6b5$d162eaf0$9b78a8c0@oedserver> comments below ----- Original Message ----- From: "Kevin Steves" To: "Darren Cole" Cc: "Kevin Steves" ; Sent: Thursday, March 28, 2002 1:25 PM Subject: Re: Trusted HP-UX 10.26 > On Tue, 26 Mar 2002, Darren Cole wrote: > :> i don't understand this. why do you need the hashed password here? [..] > :authtxt now has the password information. Without the getprpwnam call, > :authtxt wont get the encrypted password. > > you should look at auth_password(); there is already hp-ux code there > doing most of what you need. auth2 should not be changed. I am. And once I get through my next patch it will use this instead. > :Hmm... Now that I know a bit more about autoconf, I see how I could make > :HAVE_SCO_PROTECTED_PW be defined on trusted hp-ux. Then I could move this > :functionality to auth-passwd.c. Thanks, I will try that before I post my [..] > :> :+ // the "--" makes login hang on Trusted HP-UX > :> :+ // 10.26 > :> :+ "-p", "-f", pw->pw_name, (char *)NULL); > :> :+ #else > :> : "-p", "-f", "--", pw->pw_name, (char *)NULL); > :> :+ #endif > :> : > :> : /* Login couldn't be executed, die. */ > :> > :> do you require UseLogin yes? > : > :Yes. It seems much easier to let login taking care of checking and setting > :all that needs to be done on a CMW, instead of duplicating all of that work > :and code. > > login doesn't use getopt()? I don't think so, though I would have to look through the source to be sure. Login on these CMW systems is pretty darn hacked up. If the "--" is there it hangs and you eventually times out. Why exactly I don't know, but it does. It might be one of the "security" features of login (just like it has to be a descendent of init or it wont log you in). Darren From tuc at ttsg.com Fri Mar 29 12:37:05 2002 From: tuc at ttsg.com (Tuc) Date: Thu, 28 Mar 2002 20:37:05 -0500 (EST) Subject: scp : Problems with pathing Message-ID: <200203290137.UAA00655@heimdall.ttsg.com> Hi, I'm sure I'll get a few "RTFM", but I hope I'll allay those feelings. I'm getting the "scp: command not found". I've read the FAQ. I've read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. At a minimum, defines.h has : #ifdef USER_PATH # ifdef _PATH_STDPATH # undef _PATH_STDPATH # endif # define _PATH_STDPATH USER_PATH #endif #ifndef _PATH_STDPATH # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" #endif So, if scp is in 1 of those 4, it should be found. Its currently in /usr/local/bin/scp. So : I copy it to /usr/bin, and try... It works. I copy it to /bin, and try... It works. I copy it to /usr/sbin, and try... It doesn't work. At this point, I already feel stumped, but I press on. I copy it to /sbin, and try... It doesn't work. Ok, so then maybe USER_PATH is set, so I check config.h and then I find : #define USER_PATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/contrib/bin:/usr/old/bin:/usr/local/bin" Ok, so lets go down the list. /usr/bin and /bin work, ok. /usr/sbin and /sbin don't work.... Maybe I should stop here. /usr/contrib/bin ... works. ODD. /usr/old/bin, and then where it REALLY resided, /usr/local/bin don't work. Ok, so, maybe its taking the users path.... MACHINE# su - USER MACHINE:/usr/home/USER $ echo $PATH /usr/home/./USER/bin:/bin:/usr/bin:/usr/X11/bin:/usr/contrib/bin:/usr/contrib/mh/bin:/usr/games:/usr/local/bin MACHINE:/usr/home/USER $ which scp /usr/local/bin/scp That would mean to me that it should be able to find it, since it was in /usr/local/bin the entire time. Am I missing something somewhere? Thanks, Tuc/TTSG Internet Services, Inc. From markus at openbsd.org Sat Mar 30 00:24:50 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 29 Mar 2002 14:24:50 +0100 Subject: Openssh + challenge-response In-Reply-To: References: Message-ID: <20020329132450.GD30327@folly> On Thu, Mar 28, 2002 at 09:55:49AM +0100, Lourens Bordewijk wrote: > I read that it worked with openssh (that there are patches for it), If it's > posible , what's the safest hardware token that i can/should i use? > Activcard One? Cryptocard ? Is there a document that explains exactly the > situation i want to use or how i can implement it ? I use cryptocard w/ OpenSSH on OpenBSD with protocol 1's TIS message and keyboardinteractiv in protocol 2. Supporting cryptocard on other platforms is not hard and would be simple if you port the token handling from BSD_AUTH. From austin at coremetrics.com Sat Mar 30 04:01:38 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 29 Mar 2002 11:01:38 -0600 Subject: Announce: Unofficial OpenSSH 3.1p1 RPMS with kerberos patches Message-ID: <1017421298.10965.1.camel@UberGeek> Thanks to Simon Wilkinson for getting Kerberos working in OpenSSH. Changes: *openssh.spec file has been updated to use the kerberos patches based on the existence of krb5-devel rpm *added sshd-krb5.pam to contrib/redhat. This file enables the sshd to accept password auth, and check the password against the KDC. *Bumped the OpenSSH rpm build version to 3. *added sshd-krb5.pam install to openssh.spec if krb5 is enabled during the build.(to ensure that password auth will work against the KDC) The binary RPMs, were built using GCC 3.0.4 on glibc 2.2.5, under RH 7.2. Use at you're own risk. You can use rebuild the SRPM if you prefer as well. All are available from : http://www.digitalroadkill.net/public/openssh/ I hope you find them useful. -- 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 From jberry02 at yahoo.com Sat Mar 30 04:39:53 2002 From: jberry02 at yahoo.com (Joe Berry) Date: Fri, 29 Mar 2002 09:39:53 -0800 (PST) Subject: Non-interactive root access via hostbased using shosts.equiv Message-ID: <20020329173953.26058.qmail@web11301.mail.yahoo.com> Hello all! I'm looking for a solution to the following problem - I need to be able to use OpenSSH from root on one system to perform work on several dozen other systems using some automation. The restrictions that have to be met to keep the business happy are that no cleartext passwords or unencrypted private keys can be stored on disk. Since this is within an automated environment, there is no opportunity for human intervention to type in passwords or passphrases. The original intent was to use host-based authentication via the shosts.equiv file. This is essentially a drop-in replacement for what is already being done, just replacing rsh with OpenSSH. However, OpenSSH is hard-coded to *not* check hosts.equiv/shosts.equiv if the target uid is 0. It is possible to get around this by setting "IgnoreRhosts" to no, and putting a .shosts file in the root directory, but this has the highly undesired side-effect of allowing users to create their own .rhosts/.shosts files as well. I modified the source to provide a new option "PermitRootViaHostBased" that would permit the desired behavior, while leaving the default behavior as-is. But there is apparently some reluctance to add these changes to the official source tree. I've also suggested making the change conditional via #ifdef blocks, but this has also met with resistance. As things stand, I'll be forced to make this modification locally each and every time we desire to upgrade OpenSSH, which seems to be counter to what open source is all about. So it was suggested that I present the problem to this list for any other suggestions or comments. Any and all comments appreciated! Joe __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From mouring at etoh.eviladmin.org Sat Mar 30 05:26:32 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 29 Mar 2002 12:26:32 -0600 (CST) Subject: Two patches for OpenSSH 3.1p1 (fwd) Message-ID: Can I get people from other platforms to test the waitpid.patch to see if it solves hang-on-exit on their platform? I can confirm Solaris at this moment (but I've not done heavy testing at this moment) that is works like a charm (Solaris 7). It handles 'sleep 90&' vs 'nohup sleep 90&' correctly (killed, vs left). thanks. - Ben ---------- Forwarded message ---------- Date: Tue, 26 Mar 2002 22:21:31 +0100 (MET) From: Peter Eriksson To: openssh-unix-dev at mindrot.org Subject: Two patches for OpenSSH 3.1p1 Please find enclosed two patches for OpenSSH 3.1p1. The first patch solves a problem where sessions will be left "hanging" when you normally exit from a ssh shell (for example by logging out from the remote host via "exit" or "logout"). The problem seems to be that sshd (and some other parts of OpenSSH) doesn't check the return code and errno from waitpid() for errno == EINTR and thus fails to collect the started subprocess correctly. This problem occurs atleast on Solaris 2 and UNICOS systems but it should probably exist on all other SysV based systems... (It doesn't occur all the time so it can be quite hard to test for). The other patch adds a "-I" command line option to allow sshd to be correctly started (and automatically restarted) by "init" (via the /etc/inittab file) on systems with a SysV-style "init". It is *not* sufficent to just use the "-D" (no daemon) flag since that doesn't correctly handle log file output, closing of stdin/stdout/stderr or the setsid() call to drop the controlling TTY. Trying to start sshd via inittab and using "-D" will cause sshd to terminate if the Console connection (for example if using a serial terminal) gets dropped... -- Peter Eriksson Phone: +46 13 28 2786 Computer Systems Manager/BOFH Cell/GSM: +46 705 18 2786 Physics Department, Link?ping University Room: Building F, F203 SE-581 83 Link?ping, Sweden http://www.ifm.liu.se/~peter -------------- next part -------------- diff -r -c openssh-3.1p1/entropy.c openssh-3.1p1-peter/entropy.c *** openssh-3.1p1/entropy.c Tue Jan 22 11:57:54 2002 --- openssh-3.1p1-peter/entropy.c Mon Mar 18 22:00:10 2002 *************** *** 110,118 **** close(p[0]); ! if (waitpid(pid, &ret, 0) == -1) ! fatal("Couldn't wait for ssh-rand-helper completion: %s", strerror(errno)); /* We don't mind if the child exits upon a SIGPIPE */ if (!WIFEXITED(ret) && --- 110,124 ---- close(p[0]); ! { ! int code; ! ! while ((code = waitpid(pid, &ret, 0)) == -1 && errno == EINTR) ! ; ! if (code < 0) ! fatal("Couldn't wait for ssh-rand-helper completion: %s", strerror(errno)); + } /* We don't mind if the child exits upon a SIGPIPE */ if (!WIFEXITED(ret) && Only in openssh-3.1p1/scard: Ssh.bin diff -r -c openssh-3.1p1/serverloop.c openssh-3.1p1-peter/serverloop.c *** openssh-3.1p1/serverloop.c Fri Feb 8 12:07:17 2002 --- openssh-3.1p1-peter/serverloop.c Mon Mar 18 22:01:02 2002 *************** *** 673,679 **** /* We no longer want our SIGCHLD handler to be called. */ mysignal(SIGCHLD, SIG_DFL); ! wait_pid = waitpid(-1, &wait_status, 0); if (wait_pid == -1) packet_disconnect("wait: %.100s", strerror(errno)); else if (wait_pid != pid) --- 673,681 ---- /* We no longer want our SIGCHLD handler to be called. */ mysignal(SIGCHLD, SIG_DFL); ! while ((wait_pid = waitpid(-1, &wait_status, 0)) < 0 && errno == EINTR) ! ; ! if (wait_pid == -1) packet_disconnect("wait: %.100s", strerror(errno)); else if (wait_pid != pid) diff -r -c openssh-3.1p1/sftp-int.c openssh-3.1p1-peter/sftp-int.c *** openssh-3.1p1/sftp-int.c Wed Feb 13 04:10:33 2002 --- openssh-3.1p1-peter/sftp-int.c Mon Mar 18 22:02:38 2002 *************** *** 176,183 **** strerror(errno)); _exit(1); } ! if (waitpid(pid, &status, 0) == -1) fatal("Couldn't wait for child: %s", strerror(errno)); if (!WIFEXITED(status)) error("Shell exited abormally"); else if (WEXITSTATUS(status)) --- 176,192 ---- strerror(errno)); _exit(1); } ! { ! int code; ! ! ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) fatal("Couldn't wait for child: %s", strerror(errno)); + } + if (!WIFEXITED(status)) error("Shell exited abormally"); else if (WEXITSTATUS(status)) diff -r -c openssh-3.1p1/sftp.c openssh-3.1p1-peter/sftp.c *** openssh-3.1p1/sftp.c Wed Feb 13 04:03:57 2002 --- openssh-3.1p1-peter/sftp.c Mon Mar 18 22:01:49 2002 *************** *** 246,253 **** if (infile != stdin) fclose(infile); ! if (waitpid(sshpid, NULL, 0) == -1) fatal("Couldn't wait for ssh process: %s", strerror(errno)); exit(0); } --- 246,261 ---- if (infile != stdin) fclose(infile); ! { ! int code; ! ! ! while ((code = waitpid(sshpid, NULL, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) fatal("Couldn't wait for ssh process: %s", strerror(errno)); + } exit(0); } diff -r -c openssh-3.1p1/ssh-rand-helper.c openssh-3.1p1-peter/ssh-rand-helper.c *** openssh-3.1p1/ssh-rand-helper.c Sun Feb 10 08:32:30 2002 --- openssh-3.1p1-peter/ssh-rand-helper.c Mon Mar 18 22:04:34 2002 *************** *** 389,398 **** debug3("Time elapsed: %d msec", msec_elapsed); ! if (waitpid(pid, &status, 0) == -1) { error("Couldn't wait for child '%s' completion: %s", src->cmdstring, strerror(errno)); return 0.0; } RAND_add(&status, sizeof(&status), 0.0); --- 389,406 ---- debug3("Time elapsed: %d msec", msec_elapsed); ! { ! int code; ! ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) ! ; ! ! if (code < 0) ! { error("Couldn't wait for child '%s' completion: %s", src->cmdstring, strerror(errno)); return 0.0; + } } RAND_add(&status, sizeof(&status), 0.0); diff -r -c openssh-3.1p1/sshd.c openssh-3.1p1-peter/sshd.c *** openssh-3.1p1/sshd.c Tue Mar 5 02:31:30 2002 --- openssh-3.1p1-peter/sshd.c Mon Mar 18 22:03:37 2002 *************** *** 264,273 **** main_sigchld_handler(int sig) { int save_errno = errno; ! int status; ! while (waitpid(-1, &status, WNOHANG) > 0) ! ; signal(SIGCHLD, main_sigchld_handler); errno = save_errno; --- 264,274 ---- main_sigchld_handler(int sig) { int save_errno = errno; ! int status, code; ! ! while ((code = waitpid(-1, &status, WNOHANG)) < 0 && errno == EINTR || code > 0) ! ; signal(SIGCHLD, main_sigchld_handler); errno = save_errno; From wknox at mitre.org Sat Mar 30 05:30:15 2002 From: wknox at mitre.org (William R. Knox) Date: Fri, 29 Mar 2002 13:30:15 -0500 (EST) Subject: Non-interactive root access via hostbased using shosts.equiv In-Reply-To: <20020329173953.26058.qmail@web11301.mail.yahoo.com> Message-ID: You can set up an ssh-agent, add your key(s), and then reference that agent in any process that needs to make the connection. The only problem is that if your server gets rebooted, the agent needs to be restarted (and your passphrase must be entered) before any automated processing can happen. Here's how you do that: ssh-agent > /path/to/store/agent_info_file . /path/to/store/agent_info_file ssh-add (add keys) Now, any process owned by the user (or, of course, root) who runs the agent_info_file (which merely sets two environment variables which reference the socket created by ssh-agent) can access any machine that is accessible by the keys added. This is, therefore, not all that much more secure than what you had specified with regards to setting up an shosts.equiv, except only one user can use the authorization set up in this manner. And just to comment on your statement about the enhancement not being accepted being "... counter to what open source is all about", I would disagree, in that you are actually doing something which is EXACTLY what open source is all about - you are modifying the source code to perform a function that is missing in the original product. The open source notion does not specify that any and all patches to a product have to be accepted. If this solution doesn't work for you, you will just have to, as you pointed out, maintain a patch that you apply to every upgrade. Welcome to a little piece of the world that the folks who create the portable version live in all the time (bless them, the poor souls). Good luck, and let me know if you need better instructions than the lousy ones I provided above. Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation On Fri, 29 Mar 2002, Joe Berry wrote: > Date: Fri, 29 Mar 2002 09:39:53 -0800 (PST) > From: Joe Berry > To: openssh-unix-dev at mindrot.org > Subject: Non-interactive root access via hostbased using shosts.equiv > > Hello all! > > I'm looking for a solution to the following problem - > I need to be able to use OpenSSH from root on one > system to perform work on several dozen other systems > using some automation. The restrictions that have to > be met to keep the business happy are that no > cleartext passwords or unencrypted private keys can be > stored on disk. Since this is within an automated > environment, there is no opportunity for human > intervention to type in passwords or passphrases. > > The original intent was to use host-based > authentication via the shosts.equiv file. This is > essentially a drop-in replacement for what is already > being done, just replacing rsh with OpenSSH. However, > OpenSSH is hard-coded to *not* check > hosts.equiv/shosts.equiv if the target uid is 0. It > is possible to get around this by setting > "IgnoreRhosts" to no, and putting a .shosts file in > the root directory, but this has the highly undesired > side-effect of allowing users to create their own > .rhosts/.shosts files as well. > > I modified the source to provide a new option > "PermitRootViaHostBased" that would permit the desired > behavior, while leaving the default behavior as-is. > But there is apparently some reluctance to add these > changes to the official source tree. > > I've also suggested making the change conditional via > #ifdef blocks, but this has also met with resistance. > > As things stand, I'll be forced to make this > modification locally each and every time we desire to > upgrade OpenSSH, which seems to be counter to what > open source is all about. > > So it was suggested that I present the problem to this > list for any other suggestions or comments. Any and > all comments appreciated! > > Joe > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Greetings - send holiday greetings for Easter, Passover > http://greetings.yahoo.com/ > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jmknoble at pobox.com Sat Mar 30 06:59:21 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 29 Mar 2002 14:59:21 -0500 Subject: scp : Problems with pathing In-Reply-To: <200203290137.UAA00655@heimdall.ttsg.com>; from tuc@ttsg.com on Thu, Mar 28, 2002 at 08:37:05PM -0500 References: <200203290137.UAA00655@heimdall.ttsg.com> Message-ID: <20020329145920.H1723@zax.half.pint-stowp.cx> Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: : I'm getting the "scp: command not found". I've read the FAQ. I've : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. Are you certain the the sshd that is running on the remote system is the one you compiled with that USER_PATH? -- 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/20020329/b8ae8da0/attachment.bin From austin at coremetrics.com Sat Mar 30 07:05:51 2002 From: austin at coremetrics.com (Austin Gonyou) Date: 29 Mar 2002 14:05:51 -0600 Subject: Two patches for OpenSSH 3.1p1 (fwd) In-Reply-To: References: Message-ID: <1017432351.14261.1.camel@kerberos-ws4> I will try the patch later today. What version does this apply to? On Fri, 2002-03-29 at 12:26, Ben Lindstrom wrote: > > > Can I get people from other platforms to test the waitpid.patch to see > if it solves hang-on-exit on their platform? > > I can confirm Solaris at this moment (but I've not done heavy testing at > this moment) that is works like a charm (Solaris 7). It handles 'sleep > 90&' vs 'nohup sleep 90&' correctly (killed, vs left). > > thanks. > > - Ben > > ---------- Forwarded message ---------- > Date: Tue, 26 Mar 2002 22:21:31 +0100 (MET) > From: Peter Eriksson > To: openssh-unix-dev at mindrot.org > Subject: Two patches for OpenSSH 3.1p1 > > Please find enclosed two patches for OpenSSH 3.1p1. > > The first patch solves a problem where sessions will be left "hanging" > when you normally exit from a ssh shell (for example by logging out from > the remote host via "exit" or "logout"). The problem seems to be that > sshd > (and some other parts of OpenSSH) doesn't check the return code and > errno > from waitpid() for errno == EINTR and thus fails to collect the started > subprocess correctly. This problem occurs atleast on Solaris 2 and > UNICOS > systems but it should probably exist on all other SysV based systems... > (It doesn't occur all the time so it can be quite hard to test for). > > The other patch adds a "-I" command line option to allow sshd to be > correctly started (and automatically restarted) by "init" (via the > /etc/inittab file) on systems with a SysV-style "init". > > It is *not* sufficent to just use the "-D" (no daemon) flag since that > doesn't correctly handle log file output, closing of stdin/stdout/stderr > or the setsid() call to drop the controlling TTY. > > Trying to start sshd via inittab and using "-D" will cause sshd to > terminate if the Console connection (for example if using a serial > terminal) gets dropped... > > -- > Peter Eriksson Phone: +46 13 28 2786 > Computer Systems Manager/BOFH Cell/GSM: +46 705 18 2786 > Physics Department, Link?ping University Room: Building F, F203 > SE-581 83 Link?ping, Sweden > http://www.ifm.liu.se/~peter > > ---- > > diff -r -c openssh-3.1p1/entropy.c openssh-3.1p1-peter/entropy.c > *** openssh-3.1p1/entropy.c Tue Jan 22 11:57:54 2002 > --- openssh-3.1p1-peter/entropy.c Mon Mar 18 22:00:10 2002 > *************** > *** 110,118 **** > > close(p[0]); > > ! if (waitpid(pid, &ret, 0) == -1) > ! fatal("Couldn't wait for ssh-rand-helper completion: %s", > strerror(errno)); > > /* We don't mind if the child exits upon a SIGPIPE */ > if (!WIFEXITED(ret) && > --- 110,124 ---- > > close(p[0]); > > ! { > ! int code; > ! > ! while ((code = waitpid(pid, &ret, 0)) == -1 && errno == EINTR) > ! ; > ! if (code < 0) > ! fatal("Couldn't wait for ssh-rand-helper completion: %s", > strerror(errno)); > + } > > /* We don't mind if the child exits upon a SIGPIPE */ > if (!WIFEXITED(ret) && > Only in openssh-3.1p1/scard: Ssh.bin > diff -r -c openssh-3.1p1/serverloop.c openssh-3.1p1-peter/serverloop.c > *** openssh-3.1p1/serverloop.c Fri Feb 8 12:07:17 2002 > --- openssh-3.1p1-peter/serverloop.c Mon Mar 18 22:01:02 2002 > *************** > *** 673,679 **** > /* We no longer want our SIGCHLD handler to be called. */ > mysignal(SIGCHLD, SIG_DFL); > > ! wait_pid = waitpid(-1, &wait_status, 0); > if (wait_pid == -1) > packet_disconnect("wait: %.100s", strerror(errno)); > else if (wait_pid != pid) > --- 673,681 ---- > /* We no longer want our SIGCHLD handler to be called. */ > mysignal(SIGCHLD, SIG_DFL); > > ! while ((wait_pid = waitpid(-1, &wait_status, 0)) < 0 && errno == EINTR) > ! ; > ! > if (wait_pid == -1) > packet_disconnect("wait: %.100s", strerror(errno)); > else if (wait_pid != pid) > diff -r -c openssh-3.1p1/sftp-int.c openssh-3.1p1-peter/sftp-int.c > *** openssh-3.1p1/sftp-int.c Wed Feb 13 04:10:33 2002 > --- openssh-3.1p1-peter/sftp-int.c Mon Mar 18 22:02:38 2002 > *************** > *** 176,183 **** > strerror(errno)); > _exit(1); > } > ! if (waitpid(pid, &status, 0) == -1) > fatal("Couldn't wait for child: %s", strerror(errno)); > if (!WIFEXITED(status)) > error("Shell exited abormally"); > else if (WEXITSTATUS(status)) > --- 176,192 ---- > strerror(errno)); > _exit(1); > } > ! { > ! int code; > ! > ! > ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) > ! ; > ! > ! if (code < 0) > fatal("Couldn't wait for child: %s", strerror(errno)); > + } > + > if (!WIFEXITED(status)) > error("Shell exited abormally"); > else if (WEXITSTATUS(status)) > diff -r -c openssh-3.1p1/sftp.c openssh-3.1p1-peter/sftp.c > *** openssh-3.1p1/sftp.c Wed Feb 13 04:03:57 2002 > --- openssh-3.1p1-peter/sftp.c Mon Mar 18 22:01:49 2002 > *************** > *** 246,253 **** > if (infile != stdin) > fclose(infile); > > ! if (waitpid(sshpid, NULL, 0) == -1) > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > > exit(0); > } > --- 246,261 ---- > if (infile != stdin) > fclose(infile); > > ! { > ! int code; > ! > ! > ! while ((code = waitpid(sshpid, NULL, 0)) == -1 && errno == EINTR) > ! ; > ! > ! if (code < 0) > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > + } > > exit(0); > } > diff -r -c openssh-3.1p1/ssh-rand-helper.c openssh-3.1p1-peter/ssh-rand-helper.c > *** openssh-3.1p1/ssh-rand-helper.c Sun Feb 10 08:32:30 2002 > --- openssh-3.1p1-peter/ssh-rand-helper.c Mon Mar 18 22:04:34 2002 > *************** > *** 389,398 **** > > debug3("Time elapsed: %d msec", msec_elapsed); > > ! if (waitpid(pid, &status, 0) == -1) { > error("Couldn't wait for child '%s' completion: %s", > src->cmdstring, strerror(errno)); > return 0.0; > } > > RAND_add(&status, sizeof(&status), 0.0); > --- 389,406 ---- > > debug3("Time elapsed: %d msec", msec_elapsed); > > ! { > ! int code; > ! > ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) > ! ; > ! > ! if (code < 0) > ! { > error("Couldn't wait for child '%s' completion: %s", > src->cmdstring, strerror(errno)); > return 0.0; > + } > } > > RAND_add(&status, sizeof(&status), 0.0); > diff -r -c openssh-3.1p1/sshd.c openssh-3.1p1-peter/sshd.c > *** openssh-3.1p1/sshd.c Tue Mar 5 02:31:30 2002 > --- openssh-3.1p1-peter/sshd.c Mon Mar 18 22:03:37 2002 > *************** > *** 264,273 **** > main_sigchld_handler(int sig) > { > int save_errno = errno; > ! int status; > > ! while (waitpid(-1, &status, WNOHANG) > 0) > ! ; > > signal(SIGCHLD, main_sigchld_handler); > errno = save_errno; > --- 264,274 ---- > main_sigchld_handler(int sig) > { > int save_errno = errno; > ! int status, code; > > ! > ! while ((code = waitpid(-1, &status, WNOHANG)) < 0 && errno == EINTR || code > 0) > ! ; > > signal(SIGCHLD, main_sigchld_handler); > errno = save_errno; -- 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 From mouring at etoh.eviladmin.org Sat Mar 30 07:09:57 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 29 Mar 2002 14:09:57 -0600 (CST) Subject: Two patches for OpenSSH 3.1p1 (fwd) In-Reply-To: <1017432351.14261.1.camel@kerberos-ws4> Message-ID: 3.1p1, but the main part is in serverloop.c which should apply to any decently recent release. - Ben On 29 Mar 2002, Austin Gonyou wrote: > I will try the patch later today. What version does this apply to? > > On Fri, 2002-03-29 at 12:26, Ben Lindstrom wrote: > > > > > > Can I get people from other platforms to test the waitpid.patch to see > > if it solves hang-on-exit on their platform? > > > > I can confirm Solaris at this moment (but I've not done heavy testing at > > this moment) that is works like a charm (Solaris 7). It handles 'sleep > > 90&' vs 'nohup sleep 90&' correctly (killed, vs left). > > > > thanks. > > > > - Ben > > > > ---------- Forwarded message ---------- > > Date: Tue, 26 Mar 2002 22:21:31 +0100 (MET) > > From: Peter Eriksson > > To: openssh-unix-dev at mindrot.org > > Subject: Two patches for OpenSSH 3.1p1 > > > > Please find enclosed two patches for OpenSSH 3.1p1. > > > > The first patch solves a problem where sessions will be left "hanging" > > when you normally exit from a ssh shell (for example by logging out from > > the remote host via "exit" or "logout"). The problem seems to be that > > sshd > > (and some other parts of OpenSSH) doesn't check the return code and > > errno > > from waitpid() for errno == EINTR and thus fails to collect the started > > subprocess correctly. This problem occurs atleast on Solaris 2 and > > UNICOS > > systems but it should probably exist on all other SysV based systems... > > (It doesn't occur all the time so it can be quite hard to test for). > > > > The other patch adds a "-I" command line option to allow sshd to be > > correctly started (and automatically restarted) by "init" (via the > > /etc/inittab file) on systems with a SysV-style "init". > > > > It is *not* sufficent to just use the "-D" (no daemon) flag since that > > doesn't correctly handle log file output, closing of stdin/stdout/stderr > > or the setsid() call to drop the controlling TTY. > > > > Trying to start sshd via inittab and using "-D" will cause sshd to > > terminate if the Console connection (for example if using a serial > > terminal) gets dropped... > > > > -- > > Peter Eriksson Phone: +46 13 28 2786 > > Computer Systems Manager/BOFH Cell/GSM: +46 705 18 2786 > > Physics Department, Link?ping University Room: Building F, F203 > > SE-581 83 Link?ping, Sweden > > http://www.ifm.liu.se/~peter > > > > ---- > > > > > diff -r -c openssh-3.1p1/entropy.c openssh-3.1p1-peter/entropy.c > > *** openssh-3.1p1/entropy.c Tue Jan 22 11:57:54 2002 > > --- openssh-3.1p1-peter/entropy.c Mon Mar 18 22:00:10 2002 > > *************** > > *** 110,118 **** > > > > close(p[0]); > > > > ! if (waitpid(pid, &ret, 0) == -1) > > ! fatal("Couldn't wait for ssh-rand-helper completion: %s", > > strerror(errno)); > > > > /* We don't mind if the child exits upon a SIGPIPE */ > > if (!WIFEXITED(ret) && > > --- 110,124 ---- > > > > close(p[0]); > > > > ! { > > ! int code; > > ! > > ! while ((code = waitpid(pid, &ret, 0)) == -1 && errno == EINTR) > > ! ; > > ! if (code < 0) > > ! fatal("Couldn't wait for ssh-rand-helper completion: %s", > > strerror(errno)); > > + } > > > > /* We don't mind if the child exits upon a SIGPIPE */ > > if (!WIFEXITED(ret) && > > Only in openssh-3.1p1/scard: Ssh.bin > > diff -r -c openssh-3.1p1/serverloop.c openssh-3.1p1-peter/serverloop.c > > *** openssh-3.1p1/serverloop.c Fri Feb 8 12:07:17 2002 > > --- openssh-3.1p1-peter/serverloop.c Mon Mar 18 22:01:02 2002 > > *************** > > *** 673,679 **** > > /* We no longer want our SIGCHLD handler to be called. */ > > mysignal(SIGCHLD, SIG_DFL); > > > > ! wait_pid = waitpid(-1, &wait_status, 0); > > if (wait_pid == -1) > > packet_disconnect("wait: %.100s", strerror(errno)); > > else if (wait_pid != pid) > > --- 673,681 ---- > > /* We no longer want our SIGCHLD handler to be called. */ > > mysignal(SIGCHLD, SIG_DFL); > > > > ! while ((wait_pid = waitpid(-1, &wait_status, 0)) < 0 && errno == EINTR) > > ! ; > > ! > > if (wait_pid == -1) > > packet_disconnect("wait: %.100s", strerror(errno)); > > else if (wait_pid != pid) > > diff -r -c openssh-3.1p1/sftp-int.c openssh-3.1p1-peter/sftp-int.c > > *** openssh-3.1p1/sftp-int.c Wed Feb 13 04:10:33 2002 > > --- openssh-3.1p1-peter/sftp-int.c Mon Mar 18 22:02:38 2002 > > *************** > > *** 176,183 **** > > strerror(errno)); > > _exit(1); > > } > > ! if (waitpid(pid, &status, 0) == -1) > > fatal("Couldn't wait for child: %s", strerror(errno)); > > if (!WIFEXITED(status)) > > error("Shell exited abormally"); > > else if (WEXITSTATUS(status)) > > --- 176,192 ---- > > strerror(errno)); > > _exit(1); > > } > > ! { > > ! int code; > > ! > > ! > > ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) > > ! ; > > ! > > ! if (code < 0) > > fatal("Couldn't wait for child: %s", strerror(errno)); > > + } > > + > > if (!WIFEXITED(status)) > > error("Shell exited abormally"); > > else if (WEXITSTATUS(status)) > > diff -r -c openssh-3.1p1/sftp.c openssh-3.1p1-peter/sftp.c > > *** openssh-3.1p1/sftp.c Wed Feb 13 04:03:57 2002 > > --- openssh-3.1p1-peter/sftp.c Mon Mar 18 22:01:49 2002 > > *************** > > *** 246,253 **** > > if (infile != stdin) > > fclose(infile); > > > > ! if (waitpid(sshpid, NULL, 0) == -1) > > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > > > > exit(0); > > } > > --- 246,261 ---- > > if (infile != stdin) > > fclose(infile); > > > > ! { > > ! int code; > > ! > > ! > > ! while ((code = waitpid(sshpid, NULL, 0)) == -1 && errno == EINTR) > > ! ; > > ! > > ! if (code < 0) > > fatal("Couldn't wait for ssh process: %s", strerror(errno)); > > + } > > > > exit(0); > > } > > diff -r -c openssh-3.1p1/ssh-rand-helper.c openssh-3.1p1-peter/ssh-rand-helper.c > > *** openssh-3.1p1/ssh-rand-helper.c Sun Feb 10 08:32:30 2002 > > --- openssh-3.1p1-peter/ssh-rand-helper.c Mon Mar 18 22:04:34 2002 > > *************** > > *** 389,398 **** > > > > debug3("Time elapsed: %d msec", msec_elapsed); > > > > ! if (waitpid(pid, &status, 0) == -1) { > > error("Couldn't wait for child '%s' completion: %s", > > src->cmdstring, strerror(errno)); > > return 0.0; > > } > > > > RAND_add(&status, sizeof(&status), 0.0); > > --- 389,406 ---- > > > > debug3("Time elapsed: %d msec", msec_elapsed); > > > > ! { > > ! int code; > > ! > > ! while ((code = waitpid(pid, &status, 0)) == -1 && errno == EINTR) > > ! ; > > ! > > ! if (code < 0) > > ! { > > error("Couldn't wait for child '%s' completion: %s", > > src->cmdstring, strerror(errno)); > > return 0.0; > > + } > > } > > > > RAND_add(&status, sizeof(&status), 0.0); > > diff -r -c openssh-3.1p1/sshd.c openssh-3.1p1-peter/sshd.c > > *** openssh-3.1p1/sshd.c Tue Mar 5 02:31:30 2002 > > --- openssh-3.1p1-peter/sshd.c Mon Mar 18 22:03:37 2002 > > *************** > > *** 264,273 **** > > main_sigchld_handler(int sig) > > { > > int save_errno = errno; > > ! int status; > > > > ! while (waitpid(-1, &status, WNOHANG) > 0) > > ! ; > > > > signal(SIGCHLD, main_sigchld_handler); > > errno = save_errno; > > --- 264,274 ---- > > main_sigchld_handler(int sig) > > { > > int save_errno = errno; > > ! int status, code; > > > > ! > > ! while ((code = waitpid(-1, &status, WNOHANG)) < 0 && errno == EINTR || code > 0) > > ! ; > > > > signal(SIGCHLD, main_sigchld_handler); > > errno = save_errno; > -- > 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 > From tuc at ttsg.com Sat Mar 30 07:17:23 2002 From: tuc at ttsg.com (Tuc) Date: Fri, 29 Mar 2002 15:17:23 -0500 (EST) Subject: scp : Problems with pathing In-Reply-To: <20020329145920.H1723@zax.half.pint-stowp.cx> from "Jim Knoble" at Mar 29, 2002 02:59:21 PM Message-ID: <200203292017.PAA03701@heimdall.ttsg.com> > Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: > > : I'm getting the "scp: command not found". I've read the FAQ. I've > : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. > > Are you certain the the sshd that is running on the remote system is > the one you compiled with that USER_PATH? > Quite sure. Tuc/TTSG Internet Services, Inc. From jberry02 at yahoo.com Sat Mar 30 08:02:50 2002 From: jberry02 at yahoo.com (Joe Berry) Date: Fri, 29 Mar 2002 13:02:50 -0800 (PST) Subject: Non-interactive root access via hostbased using shosts.equiv In-Reply-To: Message-ID: <20020329210250.9184.qmail@web11308.mail.yahoo.com> Hello all! --- "William R. Knox" wrote: > You can set up an ssh-agent, add your key(s), and > then reference that > agent in any process that needs to make the > connection. Thanks for the suggestion. Unfortunately I do not believe it is practical due to the large number of systems involved. Automated processes would break because a box had been rebooted and no-one had reset the agent to know about the key[s]. If we could centralize everything so that it was driven from one or two boxes, it might be workable. Also, it seems like a bit of trouble compared to a secure host-based access set-up. I'll keep it in mind as something we might want to work towards. Joe __________________________________________________ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ From jason at shalott.net Sat Mar 30 11:01:46 2002 From: jason at shalott.net (Jason Stone) Date: Fri, 29 Mar 2002 16:01:46 -0800 (PST) Subject: Non-interactive root access via hostbased using shosts.equiv In-Reply-To: <20020329173953.26058.qmail@web11301.mail.yahoo.com> Message-ID: <20020329155443.F2704-100000@walter> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm looking for a solution to the following problem - > I need to be able to use OpenSSH from root on one > system to perform work on several dozen other systems > using some automation. The restrictions that have to > be met to keep the business happy are that no > cleartext passwords or unencrypted private keys can be > stored on disk. Since this is within an automated > environment, there is no opportunity for human > intervention to type in passwords or passphrases. Uh, basically you can't do this. You have to have _some_ sort of authentication token, and eventually it has to be provided in cleartext to the processes that use it, either by a human providing or decrypting the token, or by the token being already available to the system in plain text. > The original intent was to use host-based > authentication via the shosts.equiv file. Note that the key, the client machine's private host key, is the key you are using to authenticate, and it is sitting on the disk in plaintext. This is no different from giving root a regular, per-user (ie, /root/.ssh/authorized_keys), un-encrypted key, but at least with the per-user key, you can add restrictions to the key on the server side only allowing logins from the main client machine, only allowing one or a small, well-defined set of commands to be run with that key, etc. -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 iD8DBQE8pQBtswXMWWtptckRApA1AJ9tj2h62nRhKOQcUUHLFTBj1kDaQQCfaq/r BG/AjfOSfE6aBxuA1TvL2lY= =aXSI -----END PGP SIGNATURE----- From tim at multitalents.net Sat Mar 30 12:57:19 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 29 Mar 2002 17:57:19 -0800 (PST) Subject: scp : Problems with pathing In-Reply-To: <200203292017.PAA03701@heimdall.ttsg.com> Message-ID: On Fri, 29 Mar 2002, Tuc wrote: > > Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: > > > > : I'm getting the "scp: command not found". I've read the FAQ. I've > > : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. > > > > Are you certain the the sshd that is running on the remote system is > > the one you compiled with that USER_PATH? > > > Quite sure. What does "strings sshd | grep bin" say? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tuc at ttsg.com Sat Mar 30 13:49:07 2002 From: tuc at ttsg.com (Tuc) Date: Fri, 29 Mar 2002 21:49:07 -0500 (EST) Subject: scp : Problems with pathing In-Reply-To: from "Tim Rice" at Mar 29, 2002 05:57:19 PM Message-ID: <200203300249.VAA01463@heimdall.ttsg.com> > > On Fri, 29 Mar 2002, Tuc wrote: > > > > Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: > > > > > > : I'm getting the "scp: command not found". I've read the FAQ. I've > > > : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. > > > > > > Are you certain the the sshd that is running on the remote system is > > > the one you compiled with that USER_PATH? > > > > > Quite sure. > > What does "strings sshd | grep bin" say? > gna# strings sshd | grep bin bind Cannot bind any address. /bin/sh /usr/X11R6/bin/xauth /bin/sh /bin/sh /usr/local/etc/sshrc /usr/bin/login buffer_put_bignum: BN_bn2bin() failed: oi %d != bin_size %d bind: %.100s bind port %d: %.100s /bin/sh twist_option: /bin/sh: %m /bin/sh execl /bin/sh: %m bind Tuc/TTSG Internet Services, Inc. From tim at multitalents.net Sat Mar 30 16:42:06 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 29 Mar 2002 21:42:06 -0800 (PST) Subject: scp : Problems with pathing In-Reply-To: <200203300249.VAA01463@heimdall.ttsg.com> Message-ID: On Fri, 29 Mar 2002, Tuc wrote: > > > > On Fri, 29 Mar 2002, Tuc wrote: > > > > > > Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: > > > > > > > > : I'm getting the "scp: command not found". I've read the FAQ. I've > > > > : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. > > > > > > > > Are you certain the the sshd that is running on the remote system is > > > > the one you compiled with that USER_PATH? > > > > > > > Quite sure. > > > > What does "strings sshd | grep bin" say? > > > gna# strings sshd | grep bin > bind > Cannot bind any address. > /bin/sh > /usr/X11R6/bin/xauth > /bin/sh > /bin/sh /usr/local/etc/sshrc > /usr/bin/login > buffer_put_bignum: BN_bn2bin() failed: oi %d != bin_size %d > bind: %.100s > bind port %d: %.100s > /bin/sh > twist_option: /bin/sh: %m > /bin/sh > execl /bin/sh: %m > bind Hmm, doesn't look like a PATH in there anywhere. Mine has /usr/bin:/bin:/usr/sbin:/sbin right above the /bin/sh /usr/local/etc/sshrc line. Something is going wrong with your build. E-mail me privately your config.h, config.log and the configure command line you used. And what platform is this again? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sun Mar 31 02:55:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 02:55:20 +1000 (EST) Subject: [Bug 153] NULL pointer passed to xfree() during client connection Message-ID: <20020330165520.3D936E902@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=153 ------- Additional Comments From stevesk at pobox.com 2002-03-31 02:55 ------- can you provide sshd -ddd output and additional information such as linux distribution, etc? also "Cannot bind any address." appears to be from a different sshd invocation. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 03:54:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 03:54:42 +1000 (EST) Subject: [Bug 167] WARNING: sys/ttcompat.h: present but cannot be compiled. Message-ID: <20020330175442.7BF91E919@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=167 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From stevesk at pobox.com 2002-03-31 03:54 ------- - (stevesk) [configure.ac] remove header check for sys/ttcompat.h bug 167 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 04:09:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 04:09:21 +1000 (EST) Subject: [Bug 173] sshd does not listen on tcp-socket, though GatewayPorts yes Message-ID: <20020330180921.F2E0BE927@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=173 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stevesk at pobox.com 2002-03-31 04:09 ------- 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 Sun Mar 31 04:16:06 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 04:16:06 +1000 (EST) Subject: [Bug 175] File size limit for SCP Message-ID: <20020330181606.66CB6E948@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=175 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stevesk at pobox.com 2002-03-31 04:16 ------- in portable we support large files via autoconf AC_SYS_LARGEFILE http://www.gnu.org/manual/autoconf-2.52/html_node/autoconf_64.html#SEC64 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 04:25:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 04:25:32 +1000 (EST) Subject: [Bug 176] OpenSSH_3.1p1 gives X_ShmAttach error on forwarded X11 channel Message-ID: <20020330182532.364D5E97B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=176 ------- Additional Comments From stevesk at pobox.com 2002-03-31 04:25 ------- X11UseLocalHost=no is the way to revert to prior behaviour. from debug output your Xlib looks like it's trying to use a shared memory transport, which won't work with ssh X11 forwarding. if the client uses X11 R6 libs, it will usually work with X11UseLocalhost=yes. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 04:36:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 04:36:07 +1000 (EST) Subject: [Bug 185] --with-ipv4-default breaks X11-forwarding on HP-UX 10.20 Message-ID: <20020330183607.50C0FE992@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=185 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stevesk at pobox.com 2002-03-31 04:36 ------- see sshd.8 X11UseLocalhost ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tim at multitalents.net Sun Mar 31 04:33:05 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 30 Mar 2002 10:33:05 -0800 (PST) Subject: scp : Problems with pathing In-Reply-To: <200203301319.IAA05013@heimdall.ttsg.com> Message-ID: > > > > > > Circa 2002-Mar-28 20:37:05 -0500 dixit Tuc: > > > > > > > > > > > > : I'm getting the "scp: command not found". I've read the FAQ. I've > > > > > > : read bugs 42 and 82 in bugzilla. Hopefully, I didn't overlook something. > > > > > > > > > > > > Are you certain the the sshd that is running on the remote system is > > > > > > the one you compiled with that USER_PATH? > > > > > > > > > > > Quite sure. > > > > > > > > What does "strings sshd | grep bin" say? [snip] > > > > Hmm, doesn't look like a PATH in there anywhere. Mine has > > /usr/bin:/bin:/usr/sbin:/sbin right above the /bin/sh /usr/local/etc/sshrc > > line. Something is going wrong with your build. > > > > E-mail me privately your config.h, config.log and the configure > > command line you used. And what platform is this again? > > > BSD/OS, 4.0.1 and 4.1 Here is what's going on. Your config.h has #define HAVE_LOGIN_CAP_H 1 #define HAVE_LOGIN_GETCAPBOOL 1 --------< defines.h >------- #if defined(HAVE_LOGIN_GETCAPBOOL) && defined(HAVE_LOGIN_CAP_H) # define HAVE_LOGIN_CAP #endif ---------------------------- -----< session.c >----- (edited) #ifdef HAVE_LOGIN_CAP (void) setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH); child_set_env(&env, &envsize, "PATH", getenv("PATH")); #else /* HAVE_LOGIN_CAP */ child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); #endif /* HAVE_LOGIN_CAP */ --------------------------- So the path you want, "_PATH_STDPATH" will not be used. I'm not sure what to do about it. I have no BSD here. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Sun Mar 31 04:42:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 04:42:35 +1000 (EST) Subject: [Bug 190] ssh locks while waiting for output of df Message-ID: <20020330184235.3FE19E99C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=190 ------- Additional Comments From stevesk at pobox.com 2002-03-31 04:42 ------- what is the df bug that causes this? we should timeout for no output cases. can you also try 3.1p1? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From tuc at ttsg.com Sun Mar 31 04:48:30 2002 From: tuc at ttsg.com (Tuc) Date: Sat, 30 Mar 2002 13:48:30 -0500 (EST) Subject: scp : Problems with pathing In-Reply-To: from "Tim Rice" at Mar 30, 2002 10:33:05 AM Message-ID: <200203301848.NAA07588@heimdall.ttsg.com> > > > E-mail me privately your config.h, config.log and the configure > > > command line you used. And what platform is this again? > > > > > BSD/OS, 4.0.1 and 4.1 > > Here is what's going on. > Your config.h has > #define HAVE_LOGIN_CAP_H 1 > #define HAVE_LOGIN_GETCAPBOOL 1 > --------< defines.h >------- > #if defined(HAVE_LOGIN_GETCAPBOOL) && defined(HAVE_LOGIN_CAP_H) > # define HAVE_LOGIN_CAP > #endif > ---------------------------- > -----< session.c >----- (edited) > #ifdef HAVE_LOGIN_CAP > (void) setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH); > child_set_env(&env, &envsize, "PATH", getenv("PATH")); > #else /* HAVE_LOGIN_CAP */ > child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); > #endif /* HAVE_LOGIN_CAP */ > --------------------------- > > So the path you want, "_PATH_STDPATH" will not be used. > I'm not sure what to do about it. I have no BSD here. > Ok. So, then if I have HAVE_LOGIN_CAP_H, then it must be picking up the getenv("PATH") of the user. When I log on as the user, I get : MACHINE# su - USER MACHINE:/usr/home/USER $ echo $PATH /usr/home/./USER/bin:/bin:/usr/bin:/usr/X11/bin:/usr/contrib/bin:/usr/contrib/mh /bin:/usr/games:/usr/local/bin MACHINE:/usr/home/USER $ which scp /usr/local/bin/scp Hrm, but I just realized, maybe there is .XXXrc fiddling with that. Let me check what an ID with none of that has... MACHINE# su - scptest su-2.02$ echo $PATH /bin:/usr/bin:/usr/contrib/bin:/usr/X11/bin Looks awfully familiar! I never tried the /usr/X11/bin, but something tells me its fine. As for what to do about it, which would be better for it to do? Abide by users path, or the compiled in path? On BSD/OS, it seems to take it from the /etc/login.conf before it gets modified by .XXXrc's. # # The default values # To alter the default authentication types change the line: # :tc=auth-bsdi-defaults:\ # to be read something like: (enables passwd, "myauth", and activ) # :auth=passwd,myauth,activ:\ # Any value changed in the daemon class should be reset in default # class. # default:\ :path=/bin /usr/bin /usr/contrib/bin /usr/X11/bin:\ :datasize-cur=16M:\ :maxproc-max=128:\ :maxproc-cur=64:\ :radius-challenge-styles=activ,crypto,skey,snk,token:\ :tc=auth-bsdi-defaults:\ :tc=auth-ftp-bsdi-defaults: Thanks for the help, atleast we know whats happening! Thanks, Tuc/TTSG Internet Services, Inc. From bugzilla-daemon at mindrot.org Sun Mar 31 05:02:07 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:02:07 +1000 (EST) Subject: [Bug 108] Enable continuation with '\' (backslash) in /etc/ssh/sshd_config (feature request) Message-ID: <20020330190207.7316BEA88@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=108 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:02 ------- i don't know if this should be wontfix or future. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:06:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:06:26 +1000 (EST) Subject: [Bug 109] sftp hangs when a tcsh user types quit or exit Message-ID: <20020330190626.91E6BEA94@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=109 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:06 ------- i'm not sure. can someone dup and debug this? can you still dup with 3.1p1? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:13:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:13:30 +1000 (EST) Subject: [Bug 111] sshd syslogs raw untrusted data Message-ID: <20020330191330.595CFEA9A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=111 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:13 ------- we should perhaps vis(3) wrap log calls. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:22:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:22:59 +1000 (EST) Subject: [Bug 119] Occassionally, SSH failed to connect and timeout after 2 hrs! Message-ID: <20020330192259.08907EAA0@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=119 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:22 ------- what is the timeout issue? timeouts can be caused by filters that maintain connection state and have timeouts; or TCP keepalives or ??? this should probably be "invalid" ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:37:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:37:10 +1000 (EST) Subject: [Bug 126] ssh-keyscan hangs or crashes accessing Sun ssh host Message-ID: <20020330193710.55442EABD@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=126 ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:37 ------- can someone help to dup and debug 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 Sun Mar 31 05:44:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:44:17 +1000 (EST) Subject: [Bug 129] PAM with ssh authentication fails treat PAM_NEW_AUTHTOK_REQD properly Message-ID: <20020330194417.5E39DEAC3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=129 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:44 ------- i will look at 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 Sun Mar 31 05:46:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:46:52 +1000 (EST) Subject: [Bug 132] connects to 1.2.2? vintage sshd sometimes gets "Server lies" about host key size off by 1 bit Message-ID: <20020330194652.019B5EAC6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=132 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|markus at openbsd.org ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:46 ------- assign to markus ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:50:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:50:25 +1000 (EST) Subject: [Bug 134] PAM headers not found during configure Message-ID: <20020330195025.526D7EAC7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=134 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:50 ------- no additional details provided. please reopen if needed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 05:53:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 05:53:10 +1000 (EST) Subject: [Bug 135] Sudden freeze of SSH2 on clients from masqueraded subnet (behind firewall) Message-ID: <20020330195310.068FFEAC7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=135 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From stevesk at pobox.com 2002-03-31 05:53 ------- appears to be a masquerade problem. please reopen if otherwise. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 06:02:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 06:02:11 +1000 (EST) Subject: [Bug 140] Solaris 8 cannot create pkg in OpenSSH 3.1p1 Message-ID: <20020330200211.A8312EAD2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=140 ------- Additional Comments From stevesk at pobox.com 2002-03-31 06:02 ------- blank like at end of version.h. fixed. this script should grep for SSH_VERSION. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 06:37:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 06:37:16 +1000 (EST) Subject: [Bug 133] hard-coded umask(022) in ssh.c:main() too inflexible Message-ID: <20020330203716.54780EAD7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=133 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com ------- Additional Comments From stevesk at pobox.com 2002-03-31 06:37 ------- need to think about this. there are other permission issues such as pid file created with 666 perms by sshd. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 06:38:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 06:38:29 +1000 (EST) Subject: [Bug 136] setgid() deemed to fail for non-suid ssh client on linux if using other than primary group Message-ID: <20020330203829.73FDAEAD7@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=136 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|openssh-unix-dev at mindrot.org|stevesk at pobox.com ------- Additional Comments From stevesk at pobox.com 2002-03-31 06:38 ------- i will look at 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 Sun Mar 31 06:47:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 06:47:47 +1000 (EST) Subject: [Bug 192] monitor.c:545: undefined reference to `auth_password with USE_PAM on Message-ID: <20020330204747.6DEA8EAE0@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=192 ------- Additional Comments From stevesk at pobox.com 2002-03-31 06:47 ------- i will look at this. privsep needs PAM integration, but first let's get --with-pam working with no privsep in use. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Mar 31 14:23:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 31 Mar 2002 14:23:15 +1000 (EST) Subject: [Bug 109] sftp hangs when a tcsh user types quit or exit Message-ID: <20020331042315.69F13E915@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=109 ------- Additional Comments From raj at cerias.purdue.edu 2002-03-31 14:23 ------- I've been unable to dup this problem, client quits immediately in all tests. Tested configurations below. Client SSH versions - 2.9.9p2 - 3.0.2p1 - 3.1p1 Server SSH versions - 3.0.2p1 - 3.1p1 tcsh versions - tcsh 6.10.00 (Astron) 2000-11-19 (sparc-sun-solaris) options 8b,nls,dl,al,rh,color - tcsh 6.11.00 (Astron) 2001-09-02 (sparc-sun-solaris) options 8b,nls,dl,al,rh,color Solaris 7, latest kernel - SunOS basm 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-Enterprise ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.