From bbraun at synack.net Mon Jul 2 15:12:02 2001 From: bbraun at synack.net (Rob Braun) Date: Sun, 01 Jul 2001 23:12:02 -0600 Subject: rijndael byteswapping Message-ID: <200107020512.f625C2N28515@gw.synack.net> The byteorder detection macro for the rijndael algorithm doesn't work for systems that are building for multiple architectures, such as Darwin. This was the change that was needed to rijndael.c to get the macros building properly in such a situation. It seems to be a little more reliable than the existing system. Rob --- openssh_cvs/rijndael.c Tue Feb 27 13:14:22 2001 +++ /Users/rbraun/OpenSSH/openssh/rijndael.c Mon Jun 25 18:00:24 2001 @@ -58,7 +58,8 @@ #define byte(x,n) ((u1byte)((x) >> (8 * n))) -#ifdef WORDS_BIGENDIAN +/* We can't trust WORDS_BIGENDIAN when building for multiple architectures at the same time */ +#if (defined(BYTE_ORDER) && defined(BIG_ENDIAN) && (BYTE_ORDER == BIG_ENDIAN)) || defined(WORDS_BIGENDIAN) #define BYTE_SWAP #endif From dankamin at cisco.com Tue Jul 3 00:19:32 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Mon, 2 Jul 2001 07:19:32 -0700 Subject: Apparent SSH-1.2.27 Rootkit References: <3B37AA1E.DF877BAC@tgivan.com> Message-ID: <014e01c10302$03b165a0$6b00040a@na.cisco.com> > I found this lurking around the web, and thought people who are > running SSH-1.2.27 might be interested. This is a genuine rootkit, i.e. it adds a global password to a *modified* build of SSHD, rather than creating a "magic SSH client" that can force its way into any existing build of 1.2.27. It's trivial to modify almost any authentication system to allow an arbitrary client full access. It's when the unmodified authentication systems allow that client entry that we get concerned :-) Just mentioning this publically in case someone pokes through the archives and looks for a reply. --Dan From tori at unhappy.mine.nu Tue Jul 3 03:28:10 2001 From: tori at unhappy.mine.nu (Tobias Ringstrom) Date: Mon, 2 Jul 2001 19:28:10 +0200 (CEST) Subject: Forwarding race resulting in lost data in openssh-2.9p2 Message-ID: When a TCP connection is established through a tunnel (e.g. using -L 2000:www.openssh.org:80), all data sent by the local TCP client is silently dropped until the sshd has opened the connection to the remote (www.openssh.org). This is very visible when forwarding to a remote host that is far away (i.e. has high ping time) from the sshd. I have attached a sample program that shows the problem. To reproduce the problem, run the following: [server] sshd [client window 1] slogin -L 2000:www.openssh.org:80 server [client window 2] gcc get.c -o get [client window 2] ./get 5 (no problem, takes time) [client window 2] ./get (hangs forever) After the attached patch, which may or may not be correct, the problem goes away. Even if the patch is not correct, it clearly illustrates what the problem is, namely that sshd silently drops data when in the CONNECTING state (and other states too, possibly). (I'm not on the list, so please CC any replies to me.) /Tobias -------------- next part -------------- #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct sockaddr_in remoteAddr; int sock, delay = 0, n; char buf[1024]; if (argc > 1) delay = atoi(argv[1]); memset(&remoteAddr, 0, sizeof(&remoteAddr)); remoteAddr.sin_family = AF_INET; remoteAddr.sin_addr.s_addr = htonl(INADDR_LOOPBACK); remoteAddr.sin_port = htons(8000); sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) abort(); if (connect(sock, (struct sockaddr*)&remoteAddr, sizeof(remoteAddr)) == -1) abort(); if (delay) sleep(delay); write(sock, "GET /\n\n", 7); while ((n = read(sock, buf, sizeof(buf))) > 0) write(1, buf, n); close(sock); return 0; } -------------- next part -------------- --- channels.c.orig Wed Jun 13 21:18:05 2001 +++ channels.c Mon Jul 2 19:00:09 2001 @@ -1302,7 +1302,8 @@ /* Ignore any data for non-open channels (might happen on close) */ if (c->type != SSH_CHANNEL_OPEN && - c->type != SSH_CHANNEL_X11_OPEN) + c->type != SSH_CHANNEL_X11_OPEN && + c->type != SSH_CHANNEL_CONNECTING) return; /* same for protocol 1.5 if output end is no longer open */ From markus.friedl at informatik.uni-erlangen.de Tue Jul 3 06:33:03 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 2 Jul 2001 22:33:03 +0200 Subject: Forwarding race resulting in lost data in openssh-2.9p2 In-Reply-To: ; from tori@unhappy.mine.nu on Mon, Jul 02, 2001 at 07:28:10PM +0200 References: Message-ID: <20010702223303.A19573@folly> thanks, this is fixed in a different way in the current tree. -m From jrippas at mizuhocap.com Tue Jul 3 07:00:55 2001 From: jrippas at mizuhocap.com (James Rippas) Date: Mon, 02 Jul 2001 17:00:55 -0400 Subject: 2.9p2 -- ForwardX11 fails -- X11 connection uses different authentication protocol Message-ID: <3B40E107.1C17B794@mizuhocap.com> Hi, I just grabed the 2.9p2 and can't forward X11 connections. This worked fine for me under 2.9p1 but with 2.9p2 it seems that $XAUTHORITY isn't getting set and when I try and set it manually connections to the Xserver still fail with: debug1: X11 connection uses different authentication protocol. debug1: X11 rejected 1 i1/o16 Verbose debugs below. client: OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug1: Reading configuration data /home/jrippas/.ssh/config debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1676 geteuid 0 anon 1 debug1: Connecting to ratbert [192.168.90.30] port 22. debug1: temporarily_use_uid: 1676/121 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 1676/121 (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/jrippas/.ssh/identity type 0 debug3: No RSA1 key file /home/jrippas/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: no key found debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/jrippas/.ssh/id_rsa type 1 debug1: identity file /home/jrippas/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gup1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndaelbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfouaes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndaelbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at opssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at opssh.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-gup1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfouaes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndaelbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfouaes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndaelbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at opssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at opssh.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: 132/256 debug1: bits set: 1007/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/jrippas/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 39 debug3: check_host_in_hostfile: filename /home/jrippas/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 39 debug1: Host 'ratbert' is known and matches the RSA host key. debug1: Found key in /home/jrippas/.ssh/known_hosts2:39 debug1: bits set: 1020/2049 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-interacve,hostbased debug3: start over, passed a different list publickey,password,keyboard-interaive,hostbased debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try pubkey: /home/jrippas/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 142f48 hint 1 debug2: input_userauth_pk_ok: fp fc:0c:ec:64:78:de:f2:ec:98:c6:89:7e:74:e3:83: debug3: sign_and_send_pubkey debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/jrippas/.ssh/id_rsa': debug1: read PEM private key done: type RSA debug2: ssh_rsa_sign: done debug1: ssh-userauth2 successful: method publickey debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug2: tty_make_modes: ospeed 9600 debug2: tty_make_modes: ispeed 0 debug2: tty_make_modes: 1 3 debug2: tty_make_modes: 2 28 debug2: tty_make_modes: 3 127 debug2: tty_make_modes: 4 21 debug2: tty_make_modes: 5 4 debug2: tty_make_modes: 6 0 debug2: tty_make_modes: 7 0 debug2: tty_make_modes: 8 17 debug2: tty_make_modes: 9 19 debug2: tty_make_modes: 10 26 debug2: tty_make_modes: 11 25 debug2: tty_make_modes: 12 18 debug2: tty_make_modes: 13 23 debug2: tty_make_modes: 14 22 debug2: tty_make_modes: 16 0 debug2: tty_make_modes: 18 15 debug2: tty_make_modes: 30 0 debug2: tty_make_modes: 31 0 debug2: tty_make_modes: 32 0 debug2: tty_make_modes: 33 0 debug2: tty_make_modes: 34 0 debug2: tty_make_modes: 35 0 debug2: tty_make_modes: 36 1 debug2: tty_make_modes: 37 0 debug2: tty_make_modes: 38 1 debug2: tty_make_modes: 39 0 debug2: tty_make_modes: 40 0 debug2: tty_make_modes: 41 0 debug2: tty_make_modes: 50 1 debug2: tty_make_modes: 51 1 debug2: tty_make_modes: 52 0 debug2: tty_make_modes: 53 1 debug2: tty_make_modes: 54 1 debug2: tty_make_modes: 55 1 debug2: tty_make_modes: 56 0 debug2: tty_make_modes: 57 0 debug2: tty_make_modes: 58 0 debug2: tty_make_modes: 59 1 debug2: tty_make_modes: 60 1 debug2: tty_make_modes: 61 1 debug2: tty_make_modes: 62 0 debug2: tty_make_modes: 70 1 debug2: tty_make_modes: 71 0 debug2: tty_make_modes: 72 1 debug2: tty_make_modes: 73 0 debug2: tty_make_modes: 74 0 debug2: tty_make_modes: 75 0 debug2: tty_make_modes: 90 1 debug2: tty_make_modes: 91 1 debug2: tty_make_modes: 92 1 debug2: tty_make_modes: 93 0 debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: shell debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 Environment: TZ=US/Eastern SSH_CLIENT=192.168.91.91 41852 22 SSH_TTY=/dev/pts/1 TERM=xterm DISPLAY=ratbert:11.0 Last login: Mon Jul 2 15:48:26 from l7 Sun Microsystems Inc. SunOS 5.8 Generic February 2000 1 ratbert(jrippas) % xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 4096 max 2048 debug1: client_request_x11: request from 192.168.90.30 47841 debug1: fd 9 setting O_NONBLOCK debug1: fd 9 IS O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: X11 connection uses different authentication protocol. debug1: X11 rejected 1 i1/o16 debug1: channel 1: read failed debug1: channel 1: input open -> drain debug1: channel 1: close_read debug1: channel 1: input: no drain shortcut debug1: channel 1: ibuf empty debug1: channel 1: input drain -> closed debug1: channel 1: send eof debug1: channel 1: write failed debug1: channel 1: output open -> closed debug1: channel 1: close_write debug1: X11 closed 1 i8/o128 debug1: channel 1: send close debug1: channel 1: rcvd close debug1: channel 1: is dead debug1: channel_free: channel 1: status: The following connections are open: #0 client-session (t4 r0 i1/0 o16/0 fd 6/7) #1 x11 (t7 r3 i8/0 o128/0 fd 9/9) X connection to ratbert:11.0 broken (explicit kill or server shutdown). Server: debug1: Seeding random number generator debug1: sshd version OpenSSH_2.9p2 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: read PEM private key done: type RSA debug1: private host key: #2 type 1 RSA debug1: Bind to port 22 on ::. Server listening on :: port 22. 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.91.91 port 41852 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p1 debug1: match: OpenSSH_2.9p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-dss,ssh-rsa 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: 122/256 debug1: bits set: 1020/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1007/2049 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user jrippas service ssh-connection method none debug1: attempt 0 failures 0 Failed none for jrippas from 192.168.91.91 port 41852 ssh2 debug1: userauth-request for user jrippas service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 1676/121 (e=0) debug1: matching key found: file /home/jrippas/.ssh/authorized_keys2, line 1 debug1: restore_uid Postponed publickey for jrippas from 192.168.91.91 port 41852 ssh2 debug1: userauth-request for user jrippas service ssh-connection method publickey debug1: attempt 2 failures 1 debug1: temporarily_use_uid: 1676/121 (e=0) debug1: matching key found: file /home/jrippas/.ssh/authorized_keys2, line 1 debug1: restore_uid debug1: ssh_rsa_verify: signature correct Accepted publickey for jrippas from 192.168.91.91 port 41852 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 32768 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: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 debug1: session_pty_req: session 0 alloc /dev/pts/1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0 debug1: Received request for X11 forwarding with auth spoofing. debug1: bind port 6010: Address already in use debug1: fd 10 setting O_NONBLOCK debug1: fd 10 IS O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug1: fd 11 setting O_NONBLOCK debug1: fd 11 IS O_NONBLOCK debug1: channel 2: new [X11 inet listener] debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 debug1: fd 9 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug1: X11 connection requested. debug1: fd 13 IS O_NONBLOCK debug1: fd 13 IS O_NONBLOCK debug1: channel 3: new [X11 connection from 192.168.90.30 port 47841] debug1: channel 3: open confirm rwindow 32768 rmax 2048 debug1: channel 3: rcvd eof debug1: channel 3: output open -> drain debug1: channel 3: rcvd close debug1: channel 3: input open -> closed debug1: channel 3: close_read debug1: channel 3: obuf empty debug1: channel 3: output drain -> closed debug1: channel 3: close_write debug1: channel 3: send close debug1: channel 3: is dead debug1: channel_free: channel 3: status: The following connections are open: #0 server-session (t4 r0 i1/0 o16/0 fd 9/8) #3 X11 connection from 192.168.90.30 47841 (t4 r1 i8/0 o128/0 fd 13/13) debug1: channel 0: read<=0 rfd 9 len 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: channel 0: input: no drain shortcut debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug1: Received SIGCHLD. debug1: session_by_pid: pid 17966 debug1: session_exit_message: session 0 channel 0 pid 17966 debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: output open -> closed debug1: channel 0: close_write debug1: session_pty_cleanup: session 0 release /dev/pts/1 debug1: session_free: session 0 pid 17966 debug1: channel 0: send close debug1: channel 0: rcvd close debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd -1/-1) Connection closed by remote host. debug1: channel_free: channel 1: status: The following connections are open: debug1: channel_free: channel 2: status: The following connections are open: -------------- next part -------------- --------------------------------------------------------- This e-mail contains information some or all of which may be confidential, proprietary and/or legally privileged. If an addressing or transmission error has misdirected this e-mail, please notify the sender by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. --------------------------------------------------------- From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jul 4 01:46:09 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 3 Jul 2001 17:46:09 +0200 Subject: 2.9p?: connection hangs with agent forwarding Message-ID: <20010703174609.A24341@serv01.aet.tu-cottbus.de> Hi! when using agent forwarding, the connection hangs on exit, if the agent has been accessed. Symptoms: - On the client side, when the agent is accessed, the following output is being logged: debug1: channel 1: new [authentication agent connection] debug1: confirm auth-agent at openssh.com debug1: channel 1: rcvd eof debug1: channel 1: output open -> drain debug1: channel 1: obuf empty debug1: channel 1: output drain -> closed debug1: channel 1: close_write - On the server side, the following steps are logged: debug1: channel 3: new [accepted auth socket] debug1: channel 3: open confirm rwindow 4096 rmax 32768 debug1: channel 3: read<=0 rfd 11 len 0 debug1: channel 3: read failed debug1: channel 3: input open -> drain debug1: channel 3: close_read debug1: channel 3: ibuf empty debug1: channel 3: input drain -> closed debug1: channel 3: send eof This seems to be consistent by itself, however the channel doesn't seem to be closed. When the session is shutdown (type "exit" in shell), it is hanging: - Server: ... debug1: channel 0: is dead debug1: channel_free: channel 0: server-session, nchannels 4 - Client: debug1: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) #1 authentication agent connection (t4 r3 i1/0 o128/0 fd 7/7) debug1: channel_free: channel 0: dettaching channel user ^CKilled by signal 2. debug1: Calling cleanup 0x4000f70a(0x0) debug1: Calling cleanup 0x4000f892(0x0) Only when the client is shutdown with ^C, the connection will be closed as seen. Server: Connection closed by remote host. debug1: channel_free: channel 1: X11 inet listener, nchannels 3 debug1: channel_free: channel 2: auth socket, nchannels 2 debug1: channel_free: channel 3: accepted auth socket, nchannels 1 debug1: session_have_children: no more children debug1: temporarily_use_uid: 11019/11000 (e=0) debug1: restore_uid Closing connection to 127.0.0.1 The platform is HP-UX 10.20 (hanging on "sleep 20 &" test, maybe this is related!?). This is true with 2.9p1 (and older versions, if memory serves me right) up to the latest portable-CVS. I can fire up the debugger to help track it down, but by digging through the source I didn't find, who should close the channel (server or client). Shooting into the dark: HP-UX 10.20 needs USE_PIPES and must call close(), as shutdown() in just one direction does seem to work as on other platforms (see serverloop.c). Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From movits at bloomberg.com Wed Jul 4 02:12:07 2001 From: movits at bloomberg.com (Mordechai Ovits) Date: Tue, 3 Jul 2001 12:12:07 -0400 Subject: turning on none cipher for v1 and v2 server Message-ID: <01070312120700.19682@movitslinux.bloomberg.com> Hi all, Is there a straightforward way to enable the none cipher for v1 and v2 in the server? Please include my email address in your reply, as I'm not subscribed to this list. Thanks! Mordy -- Mordy Ovits Network Engineer Bloomberg L.P. From pekkas at netcore.fi Wed Jul 4 02:23:02 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 3 Jul 2001 19:23:02 +0300 (EEST) Subject: turning on none cipher for v1 and v2 server In-Reply-To: <01070312120700.19682@movitslinux.bloomberg.com> Message-ID: On Tue, 3 Jul 2001, Mordechai Ovits wrote: > Hi all, > Is there a straightforward way to enable the none cipher for v1 and v2 in the > server? No. It has been made difficult on purpose, for obvious reasons. -- 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 movits at bloomberg.com Wed Jul 4 02:20:57 2001 From: movits at bloomberg.com (Mordechai Ovits) Date: Tue, 3 Jul 2001 12:20:57 -0400 Subject: turning on none cipher for v1 and v2 server In-Reply-To: References: Message-ID: <0107031220570N.31826@movitslinux.bloomberg.com> On Tuesday 03 July 2001 12:23, Pekka Savola wrote: > On Tue, 3 Jul 2001, Mordechai Ovits wrote: > > Hi all, > > Is there a straightforward way to enable the none cipher for v1 and v2 in > > the server? > > No. It has been made difficult on purpose, for obvious reasons. Well, they're not obvious to me. I have a requirement for secure authentication, but cleartext traffic. Why make this so hard to do? It ought to be compiled out by default, to prevent accidents, but a ./configure option should be available. Mordy -- Mordy Ovits Network Engineer Bloomberg L.P. From pekkas at netcore.fi Wed Jul 4 02:39:04 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 3 Jul 2001 19:39:04 +0300 (EEST) Subject: turning on none cipher for v1 and v2 server In-Reply-To: <0107031220570N.31826@movitslinux.bloomberg.com> Message-ID: On Tue, 3 Jul 2001, Mordechai Ovits wrote: > On Tuesday 03 July 2001 12:23, Pekka Savola wrote: > > On Tue, 3 Jul 2001, Mordechai Ovits wrote: > > > Hi all, > > > Is there a straightforward way to enable the none cipher for v1 and v2 in > > > the server? > > > > No. It has been made difficult on purpose, for obvious reasons. > > Well, they're not obvious to me. I have a requirement for secure > authentication, but cleartext traffic. Why make this so hard to do? It > ought to be compiled out by default, to prevent accidents, but a ./configure > option should be available. When people use SSH, they expect to feel safe. Supporting DES encryption, no encryption etc. undermines this expectation. Sending cleartext traffic also makes you more vulnerable to spying, etc. "None" encryption does not encrypt the authentication phase. This issue has come up before too; you might want to check archives if interested, e.g.: Date: Fri, 13 Oct 2000 13:35:27 +0100 (BST) From: Edward Avis To: openssh-unix-dev at mindrot.org Subject: Cipher 'none' -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mouring at etoh.eviladmin.org Wed Jul 4 02:34:52 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 3 Jul 2001 11:34:52 -0500 (CDT) Subject: turning on none cipher for v1 and v2 server In-Reply-To: <0107031220570N.31826@movitslinux.bloomberg.com> Message-ID: On Tue, 3 Jul 2001, Mordechai Ovits wrote: > On Tuesday 03 July 2001 12:23, Pekka Savola wrote: > > On Tue, 3 Jul 2001, Mordechai Ovits wrote: > > > Hi all, > > > Is there a straightforward way to enable the none cipher for v1 and v2 in > > > the server? > > > > No. It has been made difficult on purpose, for obvious reasons. > > Well, they're not obvious to me. I have a requirement for secure > authentication, but cleartext traffic. Why make this so hard to do? It > ought to be compiled out by default, to prevent accidents, but a ./configure > option should be available. > Put it simplity.. using 'none' cipher can result in man-in-the-middle attacks against you. And since ssh was designed to protect against that and against information leakage it would break the integerity of protocol to support such a thing. I have seen people hack 'none' into the ssh client. However, we will not support such things. - Ben From movits at bloomberg.com Wed Jul 4 02:55:15 2001 From: movits at bloomberg.com (Mordechai Ovits) Date: Tue, 3 Jul 2001 12:55:15 -0400 Subject: turning on none cipher for v1 and v2 server In-Reply-To: References: Message-ID: <0107031255150P.31826@movitslinux.bloomberg.com> On Tuesday 03 July 2001 12:34, mouring at etoh.eviladmin.org wrote: > On Tue, 3 Jul 2001, Mordechai Ovits wrote: > > On Tuesday 03 July 2001 12:23, Pekka Savola wrote: > > > On Tue, 3 Jul 2001, Mordechai Ovits wrote: > > > > Hi all, > > > > Is there a straightforward way to enable the none cipher for v1 and > > > > v2 in the server? > > > > > > No. It has been made difficult on purpose, for obvious reasons. > > > > Well, they're not obvious to me. I have a requirement for secure > > authentication, but cleartext traffic. Why make this so hard to do? It > > ought to be compiled out by default, to prevent accidents, but a > > ./configure option should be available. > > Put it simplity.. > > using 'none' cipher can result in man-in-the-middle attacks against you. > And since ssh was designed to protect against that and against information > leakage it would break the integerity of protocol to support such a thing. > > I have seen people hack 'none' into the ssh client. However, we will not > support such things. > > - Ben Well, I need it for business reasons. Can you point me to the people that hacked the support in? Thanks, Mordy -- Mordy Ovits Network Engineer Bloomberg L.P. From stevev at darkwing.uoregon.edu Wed Jul 4 03:31:33 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Tue, 3 Jul 2001 10:31:33 -0700 Subject: turning on none cipher for v1 and v2 server In-Reply-To: <0107031255150P.31826@movitslinux.bloomberg.com> References: <0107031255150P.31826@movitslinux.bloomberg.com> Message-ID: <15170.373.829806.524856@darkwing.uoregon.edu> Mordechai Ovits writes: > Well, I need it for business reasons. Can you point me to the people that > hacked the support in? The only reason I've ever seen people give for wanting to have "none" encryption is that they think the encryption is slowing down transfers or consuming too much CPU time. Generally neither of those things happen, especially if you use the Blowfish or AES/Rijndael ciphers which are very efficient. Unless you're copying very large files you'll actually consume much more CPU time doing authentication (RSA isn't cheap, and DSA is worse). From movits at bloomberg.com Wed Jul 4 03:29:23 2001 From: movits at bloomberg.com (Mordechai Ovits) Date: Tue, 3 Jul 2001 13:29:23 -0400 Subject: turning on none cipher for v1 and v2 server In-Reply-To: <15170.373.829806.524856@darkwing.uoregon.edu> References: <0107031255150P.31826@movitslinux.bloomberg.com> <15170.373.829806.524856@darkwing.uoregon.edu> Message-ID: <0107031329230Q.31826@movitslinux.bloomberg.com> On Tuesday 03 July 2001 01:31, Steve VanDevender wrote: > Mordechai Ovits writes: > > Well, I need it for business reasons. Can you point me to the people > > that hacked the support in? > > The only reason I've ever seen people give for wanting to have "none" > encryption is that they think the encryption is slowing down transfers > or consuming too much CPU time. Generally neither of those things > happen, especially if you use the Blowfish or AES/Rijndael ciphers which > are very efficient. Unless you're copying very large files you'll > actually consume much more CPU time doing authentication (RSA isn't > cheap, and DSA is worse). We need it for business reasons. We have a requirement for a no-encryption zone. A tiny little one-off subnet, but I still need it. Mordy -- Mordy Ovits Network Engineer Bloomberg L.P. From ms at speakeasy.net Wed Jul 4 03:38:55 2001 From: ms at speakeasy.net (Michael Salmon) Date: Tue, 3 Jul 2001 10:38:55 -0700 Subject: turning on none cipher for v1 and v2 server In-Reply-To: <0107031329230Q.31826@movitslinux.bloomberg.com>; from movits@bloomberg.com on Tue, Jul 03, 2001 at 01:29:23PM -0400 References: <0107031255150P.31826@movitslinux.bloomberg.com> <15170.373.829806.524856@darkwing.uoregon.edu> <0107031329230Q.31826@movitslinux.bloomberg.com> Message-ID: <20010703103855.A12817@speakeasy.net> On Tue, Jul 03, 2001 at 01:29:23PM -0400, Mordechai Ovits wrote: > On Tuesday 03 July 2001 01:31, Steve VanDevender wrote: > > Mordechai Ovits writes: > > > Well, I need it for business reasons. Can you point me to the people > > > that hacked the support in? > > > > The only reason I've ever seen people give for wanting to have "none" > > encryption is that they think the encryption is slowing down transfers > > or consuming too much CPU time. Generally neither of those things > > happen, especially if you use the Blowfish or AES/Rijndael ciphers which > > are very efficient. Unless you're copying very large files you'll > > actually consume much more CPU time doing authentication (RSA isn't > > cheap, and DSA is worse). > > We need it for business reasons. We have a requirement for a no-encryption > zone. A tiny little one-off subnet, but I still need it. Then spend some of that "business money" and get crackin, but apparently no one is going to do it for you. > Mordy > -- > Mordy Ovits > Network Engineer > Bloomberg L.P. ms- From movits at bloomberg.com Wed Jul 4 03:41:14 2001 From: movits at bloomberg.com (Mordechai Ovits) Date: Tue, 3 Jul 2001 13:41:14 -0400 Subject: turning on none cipher for v1 and v2 server In-Reply-To: <20010703103855.A12817@speakeasy.net> References: <0107031329230Q.31826@movitslinux.bloomberg.com> <20010703103855.A12817@speakeasy.net> Message-ID: <0107031341140R.31826@movitslinux.bloomberg.com> On Tuesday 03 July 2001 01:38, Michael Salmon wrote: > On Tue, Jul 03, 2001 at 01:29:23PM -0400, Mordechai Ovits wrote: > > On Tuesday 03 July 2001 01:31, Steve VanDevender wrote: > > > Mordechai Ovits writes: > > > > Well, I need it for business reasons. Can you point me to the > > > > people that hacked the support in? > > > > > > The only reason I've ever seen people give for wanting to have "none" > > > encryption is that they think the encryption is slowing down transfers > > > or consuming too much CPU time. Generally neither of those things > > > happen, especially if you use the Blowfish or AES/Rijndael ciphers > > > which are very efficient. Unless you're copying very large files > > > you'll actually consume much more CPU time doing authentication (RSA > > > isn't cheap, and DSA is worse). > > > > We need it for business reasons. We have a requirement for a > > no-encryption zone. A tiny little one-off subnet, but I still need it. > > Then spend some of that "business money" and get crackin, but > apparently no one is going to do it for you. > I was simply asking for some help in figuring out what was necessary to get none cipher. Perhaps someone else is willing to help? Thanks, Mordy -- Mordy Ovits Network Engineer Bloomberg L.P. From wendyp at cray.com Wed Jul 4 04:01:04 2001 From: wendyp at cray.com (Wendy Palm) Date: Tue, 03 Jul 2001 13:01:04 -0500 Subject: turning on none cipher for v1 and v2 server References: <0107031329230Q.31826@movitslinux.bloomberg.com> <20010703103855.A12817@speakeasy.net> <0107031341140R.31826@movitslinux.bloomberg.com> Message-ID: <3B420860.A8CD606@cray.com> Mordechai Ovits wrote: > > On Tuesday 03 July 2001 01:38, Michael Salmon wrote: > > On Tue, Jul 03, 2001 at 01:29:23PM -0400, Mordechai Ovits wrote: > > > On Tuesday 03 July 2001 01:31, Steve VanDevender wrote: > > > > Mordechai Ovits writes: > > > > > Well, I need it for business reasons. Can you point me to the > > > > > people that hacked the support in? > > I was simply asking for some help in figuring out what was necessary to get > none cipher. Perhaps someone else is willing to help? > > Thanks, > Mordy > -- > Mordy Ovits > Network Engineer > Bloomberg L.P. i'm afraid i don't know either. i vaguely remember reading discussions about it. check the mail list archives & that would be your best bet to find a starting point. sorry, wendy -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From stevev at darkwing.uoregon.edu Wed Jul 4 04:06:36 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Tue, 3 Jul 2001 11:06:36 -0700 Subject: turning on none cipher for v1 and v2 server In-Reply-To: <3B420860.A8CD606@cray.com> References: <0107031329230Q.31826@movitslinux.bloomberg.com> <20010703103855.A12817@speakeasy.net> <0107031341140R.31826@movitslinux.bloomberg.com> <3B420860.A8CD606@cray.com> Message-ID: <15170.2476.70330.537778@darkwing.uoregon.edu> Wendy Palm writes: > i'm afraid i don't know either. i vaguely remember reading discussions about it. > check the mail list archives & that would be your best bet to find a starting point. The source code is available. "find | xargs grep" is your friend. I'm sorry I even replied, if only because apparently nobody but me is capable of editing the addresses in their replies and I'm getting two of every message that's a followup to the one I posted. From Nicolas.Williams at ubsw.com Wed Jul 4 04:57:39 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 3 Jul 2001 14:57:39 -0400 Subject: Feature patch: key name/patterns in authorized_keys2 [e.g., Kerberos principal names] (was Re: Adding 'name' key types) In-Reply-To: <20010629180904.J6936@sm2p1386swk.wdr.com>; from willian on Fri, Jun 29, 2001 at 06:09:05PM -0400 References: <20010628165713.L9416@sm2p1386swk.wdr.com> <20010629180904.J6936@sm2p1386swk.wdr.com> Message-ID: <20010703145737.M6936@sm2p1386swk.wdr.com> Ok, to follow up to myself, here's a much more featureful, complete and tested patch. This patch (to OpenSSH 2.9p2) adds: - ssh-ext-named key entry type for authorized_keys2 files - ssh-ext-name-pat key entry type for authorized_keys2 files - deny-access option for authorized_keys2 files - SSH_AUTH_EXT_NAME environment variable added by sshd when - SSH_AUTH_EXT_NAME_TYPE similar Now you can have entries like this in you authorized_keys2 files: ssh-ext-named:krb5 someuser at SOMEREALM deny-access ssh-ext-named:krb5 joe/superroot at SOMEREALM ssh-ext-name-pat:krb5 */superroot at SOMERALM Double quotes can be used when key names contain whitespace. So far I have only modified simon at sxw.org.uk's GSS-API patches for OpenSSH to support the use of 'krb5' key names in authorized_keys2 files. I really hope that this feature or a variation thereof will find its way into OpenSSH. In conjunction with Kerberos (IV or V) it can be extremely useful: - key management is simplified: key management is done at the KDC and there is no need to edit authorized_keys2 files all over to revoke keys! - authorized_keys2 is much more featureful than .klogin and .k5login are, regardless of Kerberos implementation source (KTH, Heimdal, MIT, SEAM, all implement pretty much the same all-or-nothing .klogin/.k5login functionality). A similar patch of gss-serv.c:ssh_gssapi_gsi_userok() to support the use of 'gsi' key names in authorized_keys2 would be trivial. A similar patch to auth-krb4.c:auth_krb4() to support the use of 'krb4' key names would be trivial, but I could not test such a patch. A question, in my mind, is whether the krb4/gss:krb5/gss:gsi ssh_*userok() code should require both, authorized_keys2 check *and* the underlying mechanism userok() check to pass, or either, or what. My patch to gss-serv.c:ssh_gssapi_krb5_userok() requires either check to pass. Below you should find two versions of this patch, one against OpenSSH 2.9p2, the other against 2.9p2 + simon at sxw.org.uk's GSS-API patches. NOTE: I did not strive too hard to keep to the code style of OpenSSH. Point me a the description of the OpenSSH code style and I'll modify my patch accordingly. Files modified: - key.h - added KEY_NAME key type - added KEY_NAME_PAT key type - added name, name_len and name_type fields to the Key struct - added prototype for key_match() - key.c - added initialization/finalization of new Key fields to key_new()/key_free() - added named/pattern key type support to a variety of functions, including key_read() and key_write(), among others - added key_match() implementation - auth-options.h - added void auth_set_key_env(Key *) prototype - auth-options.c - added auth_set_key_env() implementation - modified auth_parse_options() to return (-1) when new deny-access option is encountered - auth-rsa.c - modified auth_parse_options() return value check according to the change made to auth_parse_options() - auth2.c - modified user_key_allowed() to: - try key_match() if key_equal() fails - check the result of auth_parse_options() for negative, 0, or positive values. - modified userauth_pubkey() to check for positive return value of user_key_allowed() - sshd.8 - added documentation - gss-serv.c - modified ssh_gssapi_krb5_userok() to build a Key struct and call user_key_allowed() 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.- ******************************************************************************** Index: 2_9_p2.1/sshd.8 --- 2_9_p2.1/sshd.8 Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/h/28_sshd.8 1.1 644) +++ 2_9_p2_w_named_keys.2/sshd.8 Tue, 03 Jul 2001 14:20:28 -0400 willian (OpenSSH/h/28_sshd.8 1.1.1.1 644) @@ -852,7 +852,8 @@ .Pa $HOME/.ssh/authorized_keys2 file lists the DSA and RSA keys that are permitted for public key authentication (PubkeyAuthentication) -in protocol version 2. +in protocol version 2. It can also list key names or key patterns +for external authentication systems, such as krb4, krb5, gsi, etc... .Pp Each line of the file contains one key (empty lines and lines starting with a @@ -873,7 +874,19 @@ For protocol version 2 the keytype is .Dq ssh-dss or -.Dq ssh-rsa . +.Dq ssh-rsa +or +.Dq ssh-ext-named: +or +.Dq ssh-ext-name-pat: . +.Pp +Named keys and key name patterns follow the latter two, in double +quotes if they contain whitespace. Named key types may include: +.Dq krb4 , +.Dq krb5 +and/or +.Dq gsi , +depending on what features are compiled in to OpenSSH. .Pp Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). @@ -930,6 +943,10 @@ Environment variables set this way override other default environment values. Multiple options of this type are permitted. +.It Cm deny-access +This option ends authorized_keys2 processing if the key matches. This +option is only really useful with named key and named key pattern +entries. .It Cm no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. Index: 2_9_p2.1/key.h --- 2_9_p2.1/key.h Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/7_key.h 1.1 644) +++ 2_9_p2_w_named_keys.2/key.h Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/j/7_key.h 1.1.1.1 644) @@ -34,7 +34,9 @@ KEY_RSA1, KEY_RSA, KEY_DSA, - KEY_UNSPEC + KEY_UNSPEC, + KEY_NAME, + KEY_NAME_PAT }; enum fp_type { SSH_FP_SHA1, @@ -48,12 +50,16 @@ int type; RSA *rsa; DSA *dsa; + u_char *name; + u_int name_len; + char *name_type; }; Key *key_new(int type); Key *key_new_private(int type); void key_free(Key *k); int key_equal(Key *a, Key *b); +int key_match(Key *a, Key *b); char *key_fingerprint(Key *k, enum fp_type dgst_type, enum fp_rep dgst_rep); char *key_type(Key *k); int key_write(Key *key, FILE *f); Index: 2_9_p2.1/key.c --- 2_9_p2.1/key.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/8_key.c 1.1 644) +++ 2_9_p2_w_named_keys.2/key.c Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/j/8_key.c 1.1.1.1 644) @@ -56,6 +56,9 @@ k->type = type; k->dsa = NULL; k->rsa = NULL; + k->name = NULL; + k->name_len = 0; + k->name_type = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -72,6 +75,8 @@ dsa->pub_key = BN_new(); k->dsa = dsa; break; + case KEY_NAME: + case KEY_NAME_PAT: case KEY_UNSPEC: break; default: @@ -119,6 +124,14 @@ DSA_free(k->dsa); k->dsa = NULL; break; + case KEY_NAME: + case KEY_NAME_PAT: + if (k->name != NULL) + xfree(k->name); + k->name_len = 0; + if (k->name_type != NULL) + xfree(k->name_type); + break; case KEY_UNSPEC: break; default: @@ -130,8 +143,9 @@ int key_equal(Key *a, Key *b) { - if (a == NULL || b == NULL || a->type != b->type) + if (a == NULL || b == NULL || a->type != b->type) { return 0; + } switch (a->type) { case KEY_RSA1: case KEY_RSA: @@ -146,12 +160,67 @@ BN_cmp(a->dsa->g, b->dsa->g) == 0 && BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; break; + case KEY_NAME: + if ((a->name_type == NULL && b->name_type == NULL) || + (a->name_type == b->name_type)) + return (a->name_len == b->name_len) && + (memcmp(a->name, b->name, a->name_len) == 0); + if (a->name_type == NULL || b->name_type == NULL) + return 0; + if (strcmp(a->name_type, b->name_type) == 0) + return (a->name_len == b->name_len) && + (memcmp(a->name, b->name, a->name_len) == 0); + break; + case KEY_NAME_PAT: + return 0; + break; default: fatal("key_equal: bad key type %d", a->type); break; } return 0; } +int +key_match(Key *a, Key *b) +{ + debug3("key_match: trying to match %x and %x", a, b); + if (a == NULL || b == NULL) + return 0; + + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); + /* One key must be a name pattern, the other must be a name */ + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) + return 0; + + /* Both keys must have name types, or both must not */ + /* or one key must have '*' as its name type */ + if ((a->name_type == NULL && b->name_type != NULL) || + (b->name_type == NULL && a->name_type != NULL)) { + + debug3("key_match: foo"); + if (a->name_type != NULL && *(a->name_type) != '*') + return 0; + if (b->name_type != NULL && *(b->name_type) != '*') + return 0; + } + + /* Name type "*" matches any name type */ + /* Otherwise name types must match */ + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && + (*(a->name_type) != '*' || *(b->name_type) != '*')) { + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); + return 0; + } + + debug3("key_match: trying to match %s WITH %s", a->name, b->name); + if (a->type == KEY_NAME_PAT) + return match_pattern(b->name, a->name); + else + return match_pattern(a->name, b->name); +} + u_char* key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) @@ -160,7 +229,7 @@ EVP_MD_CTX ctx; u_char *blob = NULL; u_char *retval = NULL; - int len = 0; + u_int len = 0; int nlen, elen; *dgst_raw_length = 0; @@ -363,11 +432,12 @@ { Key *k; int success = -1; - char *cp, *space; + char *cp, *space, *name_type; int len, n, type; u_int bits; - u_char *blob; + u_char *blob = NULL; + name_type = NULL; cp = *cpp; switch(ret->type) { @@ -390,6 +460,8 @@ case KEY_UNSPEC: case KEY_RSA: case KEY_DSA: + case KEY_NAME: + case KEY_NAME_PAT: space = strchr(cp, ' '); if (space == NULL) { debug3("key_read: no space"); @@ -397,6 +469,17 @@ } *space = '\0'; type = key_type_from_name(cp); + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { + char * colon = NULL; + + colon = strchr(cp, ':'); + + debug3("key_read: handling named key or pattern (%d), %s, colon at %x", type, cp, colon); + if (colon != NULL && *(++colon) != '\0') { + name_type = xstrdup(colon); + } else + name_type == NULL; + } *space = ' '; if (type == KEY_UNSPEC) { debug3("key_read: no key found"); @@ -410,30 +493,80 @@ if (ret->type == KEY_UNSPEC) { ret->type = type; } else if (ret->type != type) { - /* is a key, but different type */ - debug3("key_read: type mismatch"); - return 0; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + /* is a key, but different type */ + debug3("key_read: type mismatch"); + return 0; + } + ret->type = type; } - len = 2*strlen(cp); - blob = xmalloc(len); - n = uudecode(cp, blob, len); - if (n < 0) { - error("key_read: uudecode %s failed", cp); - return -1; + debug3("key_read: here -- ret->type == %d", ret->type); + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + char *quote, *newline; + debug3("key_read: reading named key %s", cp); + if (cp == NULL || *cp == '\0') + return 0; + if (*cp == '"') { + quote = strchr(++cp, '"'); + if (quote == NULL) { + debug3("key_read: missing quote"); + return 0; + } + *quote = '\0'; + } + newline = strchr(cp, '\n'); + if (newline != NULL) + *newline = '\0'; + debug3("key_read: reading named key %s", cp); + k = key_new(ret->type); + k->name = (unsigned char *) xstrdup(cp); + k->name_len = strlen(cp); + k->name_type = name_type; + if (newline !=NULL) + *newline = '\n'; + if (quote !=NULL) + *quote = '"'; + debug3("key_read: read named key %s", k->name_type); + } else { + len = 2*strlen(cp); + blob = xmalloc(len); + n = uudecode(cp, blob, len); + if (n < 0) { + error("key_read: uudecode %s failed", cp); + return -1; + } + debug3("key_read: reading uuencoded key %s", blob); + k = key_from_blob(blob, n); } - k = key_from_blob(blob, n); if (k == NULL) { error("key_read: key_from_blob %s failed", cp); return -1; } - xfree(blob); + if (blob != NULL) + xfree(blob); if (k->type != type) { - error("key_read: type mismatch: encoding error"); - key_free(k); - return -1; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + error("key_read: type mismatch: encoding error"); + key_free(k); + return -1; + } } /*XXXX*/ - if (ret->type == KEY_RSA) { + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + /* + if (ret->name != NULL) + xfree(ret->name); + */ + ret->name = k->name; + ret->name_len = k->name_len; + ret->name_type = k->name_type; + k->name = NULL; + k->name_type = NULL; + k->name_len = 0; + success = 1; + } else if (ret->type == KEY_RSA) { if (ret->rsa != NULL) RSA_free(ret->rsa); ret->rsa = k->rsa; @@ -487,7 +620,7 @@ } } else if ((key->type == KEY_DSA && key->dsa != NULL) || (key->type == KEY_RSA && key->rsa != NULL)) { - int len, n; + u_int len, n; u_char *blob, *uu; key_to_blob(key, &blob, &len); uu = xmalloc(2*len); @@ -498,6 +631,14 @@ } xfree(blob); xfree(uu); + } else if (key->type == KEY_NAME && key->name != NULL && + key->name_len) { + + fprintf(f, "%s ", key_ssh_name(key)); + if (key->name_type != NULL) + fprintf(f, ":%s", key->name_type); + else + fprintf(f, " \"%.*s\"", key->name, key->name_len); } return success; } @@ -514,6 +655,12 @@ case KEY_DSA: return "DSA"; break; + case KEY_NAME: + return "Named"; + break; + case KEY_NAME_PAT: + return "Name_Pattern"; + break; } return "unknown"; } @@ -527,6 +674,12 @@ case KEY_DSA: return "ssh-dss"; break; + case KEY_NAME: + return "ssh-ext-named"; + break; + case KEY_NAME_PAT: + return "ssh-ext-name-pat"; + break; } return "ssh-unknown"; } @@ -604,6 +757,16 @@ BN_copy(n->rsa->n, k->rsa->n); BN_copy(n->rsa->e, k->rsa->e); break; + case KEY_NAME: + case KEY_NAME_PAT: + n = key_new(k->type); + n->name_len = k->name_len; + n->name = xmalloc(k->name_len); + memcpy(n->name, k->name, n->name_len); + if (k->name_type) { + n->name_type = xstrdup(k->name_type); + } + break; default: fatal("key_from_private: unknown type %d", k->type); break; @@ -624,7 +787,16 @@ return KEY_RSA; } else if (strcmp(name, "ssh-dss") == 0){ return KEY_DSA; + } else if (strcmp(name, "ssh-ext-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-ext-named:", strlen("ssh-ext-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-ext-name-pat:", strlen("ssh-ext-name-pat:")) == 0){ + return KEY_NAME_PAT; } + debug2("key_type_from_name: unknown key type '%s'", name); return KEY_UNSPEC; } Index: 2_9_p2.1/auth2.c --- 2_9_p2.1/auth2.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/6_auth2.c 1.1 644) +++ 2_9_p2_w_named_keys.2/auth2.c Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/k/6_auth2.c 1.1.1.1 644) @@ -491,7 +491,7 @@ buffer_dump(&b); #endif /* test for correct signature */ - if (user_key_allowed(authctxt->pw, key) && + if (user_key_allowed(authctxt->pw, key) > 0 && key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) authenticated = 1; buffer_clear(&b); @@ -508,7 +508,7 @@ * if a user is not allowed to login. is this an * issue? -markus */ - if (user_key_allowed(authctxt->pw, key)) { + if (user_key_allowed(authctxt->pw, key) > 0) { packet_start(SSH2_MSG_USERAUTH_PK_OK); packet_put_string(pkalg, alen); packet_put_string(pkblob, blen); @@ -768,19 +768,36 @@ continue; } } - if (key_equal(found, key) && - auth_parse_options(pw, options, file, linenum) == 1) { - found_key = 1; - debug("matching key found: file %s, line %ld", - file, linenum); + if (key_equal(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key == 0) + continue; + break; + } + if (key_match(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key == 0) + continue; + /* Special treatment for key name patterns belongs here */ break; } } + +done: restore_uid(); fclose(f); key_free(found); - if (!found_key) + if (found_key > 0) { + debug("matching key found: file %s, line %ld", + file, linenum); + auth_set_key_env(key); + } + if (found_key == 0) debug2("key not found"); + if (found_key < 0) { + debug("user_key_allowed: matching deny key found: " + "file %s, line %ld", file, linenum); + } return found_key; } Index: 2_9_p2.1/auth-rsa.c --- 2_9_p2.1/auth-rsa.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/15_auth-rsa.c 1.1 644) +++ 2_9_p2_w_named_keys.2/auth-rsa.c Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/k/15_auth-rsa.c 1.1.1.1 644) @@ -259,7 +259,7 @@ * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (auth_parse_options(pw, options, file, linenum) < 1) continue; /* Perform the challenge-response dialog for this key. */ Index: 2_9_p2.1/auth-options.h --- 2_9_p2.1/auth-options.h Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/21_auth-optio 1.1 644) +++ 2_9_p2_w_named_keys.2/auth-options.h Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/k/21_auth-optio 1.1.1.1 644) @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -37,6 +39,9 @@ int auth_parse_options(struct passwd *pw, char *options, char *file, u_long linenum); + +void +auth_set_key_env(Key *k); /* reset options flags */ void auth_clear_options(void); Index: 2_9_p2.1/auth-options.c --- 2_9_p2.1/auth-options.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/22_auth-optio 1.1 644) +++ 2_9_p2_w_named_keys.2/auth-options.c Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/k/22_auth-optio 1.1.1.1 644) @@ -55,8 +55,43 @@ channel_clear_permitted_opens(); } +void auth_set_key_env(Key *k) +{ + struct envstring *new_env; + char *s; + int len; + + if (k->type != KEY_NAME) + return; + + len = strlen("SSH_AUTH_EXT_NAME="); + len += k->name_len + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_EXT_NAME=%.*s", k->name_len, k->name); + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + if (k->name_type == NULL) + return; + + len = strlen("SSH_AUTH_EXT_NAME_TYPE="); + len += strlen(k->name_type) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_EXT_NAME_TYPE=%s", k->name_type); + + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + return; +} + /* - * return 1 if access is granted, 0 if not. + * return 1 if access is granted, 0 if not, -1 if access explicitly denied * side effect: sets key option flags */ int @@ -72,6 +107,12 @@ return 1; while (*opts && *opts != ' ' && *opts != '\t') { + cp = "deny-access"; + if (strncasecmp(opts, cp, strlen(cp)) == 0) { + log("Authentication successful, but authorization denied"); + packet_send_debug("Permission denied"); + return -1; + } cp = "no-port-forwarding"; if (strncasecmp(opts, cp, strlen(cp)) == 0) { packet_send_debug("Port forwarding disabled."); ******************************************************************************** Index: 2_9_p2_w_gss_and_krb5.4/sshd.8 --- 2_9_p2_w_gss_and_krb5.4/sshd.8 Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/h/28_sshd.8 1.2 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/sshd.8 Tue, 03 Jul 2001 14:20:01 -0400 willian (OpenSSH/h/28_sshd.8 1.3 644) @@ -871,7 +871,8 @@ .Pa $HOME/.ssh/authorized_keys2 file lists the DSA and RSA keys that are permitted for public key authentication (PubkeyAuthentication) -in protocol version 2. +in protocol version 2. It can also list key names or key patterns +for external authentication systems, such as krb4, krb5, gsi, etc... .Pp Each line of the file contains one key (empty lines and lines starting with a @@ -892,7 +893,19 @@ For protocol version 2 the keytype is .Dq ssh-dss or -.Dq ssh-rsa . +.Dq ssh-rsa +or +.Dq ssh-ext-named: +or +.Dq ssh-ext-name-pat: . +.Pp +Named keys and key name patterns follow the latter two, in double +quotes if they contain whitespace. Named key types may include: +.Dq krb4 , +.Dq krb5 +and/or +.Dq gsi , +depending on what features are compiled in to OpenSSH. .Pp Note that lines in this file are usually several hundred bytes long (because of the size of the RSA key modulus). @@ -949,6 +962,10 @@ Environment variables set this way override other default environment values. Multiple options of this type are permitted. +.It Cm deny-access +This option ends authorized_keys2 processing if the key matches. This +option is only really useful with named key and named key pattern +entries. .It Cm no-port-forwarding Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. Index: 2_9_p2_w_gss_and_krb5.4/key.h --- 2_9_p2_w_gss_and_krb5.4/key.h Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/j/7_key.h 1.2 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/key.h Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/j/7_key.h 1.4 644) @@ -35,7 +35,9 @@ KEY_RSA, KEY_DSA, KEY_NULL, - KEY_UNSPEC + KEY_UNSPEC, + KEY_NAME, + KEY_NAME_PAT }; enum fp_type { SSH_FP_SHA1, @@ -49,12 +51,16 @@ int type; RSA *rsa; DSA *dsa; + u_char *name; + u_int name_len; + char *name_type; }; Key *key_new(int type); Key *key_new_private(int type); void key_free(Key *k); int key_equal(Key *a, Key *b); +int key_match(Key *a, Key *b); char *key_fingerprint(Key *k, enum fp_type dgst_type, enum fp_rep dgst_rep); char *key_type(Key *k); int key_write(Key *key, FILE *f); Index: 2_9_p2_w_gss_and_krb5.4/key.c --- 2_9_p2_w_gss_and_krb5.4/key.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/j/8_key.c 1.2 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/key.c Tue, 03 Jul 2001 14:23:39 -0400 willian (OpenSSH/j/8_key.c 1.6 644) @@ -56,6 +56,9 @@ k->type = type; k->dsa = NULL; k->rsa = NULL; + k->name = NULL; + k->name_len = 0; + k->name_type = NULL; switch (k->type) { case KEY_RSA1: case KEY_RSA: @@ -72,6 +75,8 @@ dsa->pub_key = BN_new(); k->dsa = dsa; break; + case KEY_NAME: + case KEY_NAME_PAT: case KEY_UNSPEC: break; default: @@ -119,6 +124,14 @@ DSA_free(k->dsa); k->dsa = NULL; break; + case KEY_NAME: + case KEY_NAME_PAT: + if (k->name != NULL) + xfree(k->name); + k->name_len = 0; + if (k->name_type != NULL) + xfree(k->name_type); + break; case KEY_UNSPEC: break; default: @@ -130,8 +143,9 @@ int key_equal(Key *a, Key *b) { - if (a == NULL || b == NULL || a->type != b->type) + if (a == NULL || b == NULL || a->type != b->type) { return 0; + } switch (a->type) { case KEY_RSA1: case KEY_RSA: @@ -146,12 +160,67 @@ BN_cmp(a->dsa->g, b->dsa->g) == 0 && BN_cmp(a->dsa->pub_key, b->dsa->pub_key) == 0; break; + case KEY_NAME: + if ((a->name_type == NULL && b->name_type == NULL) || + (a->name_type == b->name_type)) + return (a->name_len == b->name_len) && + (memcmp(a->name, b->name, a->name_len) == 0); + if (a->name_type == NULL || b->name_type == NULL) + return 0; + if (strcmp(a->name_type, b->name_type) == 0) + return (a->name_len == b->name_len) && + (memcmp(a->name, b->name, a->name_len) == 0); + break; + case KEY_NAME_PAT: + return 0; + break; default: fatal("key_equal: bad key type %d", a->type); break; } return 0; } +int +key_match(Key *a, Key *b) +{ + debug3("key_match: trying to match %x and %x", a, b); + if (a == NULL || b == NULL) + return 0; + + debug3("key_match: trying to match key types %d and %d -- KEY_NAME_PAT == %d", a->type, b->type, KEY_NAME_PAT); + /* One key must be a name pattern, the other must be a name */ + if (!(a->type == KEY_NAME_PAT && b->type == KEY_NAME) && + !(b->type == KEY_NAME_PAT && a->type == KEY_NAME)) + return 0; + + /* Both keys must have name types, or both must not */ + /* or one key must have '*' as its name type */ + if ((a->name_type == NULL && b->name_type != NULL) || + (b->name_type == NULL && a->name_type != NULL)) { + + debug3("key_match: foo"); + if (a->name_type != NULL && *(a->name_type) != '*') + return 0; + if (b->name_type != NULL && *(b->name_type) != '*') + return 0; + } + + /* Name type "*" matches any name type */ + /* Otherwise name types must match */ + if ((a->name_type != NULL && strcmp(a->name_type, b->name_type) != 0) && + (*(a->name_type) != '*' || *(b->name_type) != '*')) { + debug3("key_match: a->name_type == %s", a->name_type ? a->name_type : ""); + debug3("key_match: b->name_type == %s", b->name_type ? b->name_type : ""); + return 0; + } + + debug3("key_match: trying to match %s WITH %s", a->name, b->name); + if (a->type == KEY_NAME_PAT) + return match_pattern(b->name, a->name); + else + return match_pattern(a->name, b->name); +} + u_char* key_fingerprint_raw(Key *k, enum fp_type dgst_type, size_t *dgst_raw_length) @@ -160,7 +229,7 @@ EVP_MD_CTX ctx; u_char *blob = NULL; u_char *retval = NULL; - int len = 0; + u_int len = 0; int nlen, elen; *dgst_raw_length = 0; @@ -363,11 +432,12 @@ { Key *k; int success = -1; - char *cp, *space; + char *cp, *space, *name_type; int len, n, type; u_int bits; - u_char *blob; + u_char *blob = NULL; + name_type = NULL; cp = *cpp; switch(ret->type) { @@ -390,6 +460,8 @@ case KEY_UNSPEC: case KEY_RSA: case KEY_DSA: + case KEY_NAME: + case KEY_NAME_PAT: space = strchr(cp, ' '); if (space == NULL) { debug3("key_read: no space"); @@ -397,6 +469,17 @@ } *space = '\0'; type = key_type_from_name(cp); + if ((type == KEY_NAME) || (type == KEY_NAME_PAT)) { + char * colon = NULL; + + colon = strchr(cp, ':'); + + debug3("key_read: handling named key or pattern (%d), %s, colon at %x", type, cp, colon); + if (colon != NULL && *(++colon) != '\0') { + name_type = xstrdup(colon); + } else + name_type == NULL; + } *space = ' '; if (type == KEY_UNSPEC) { debug3("key_read: no key found"); @@ -410,30 +493,80 @@ if (ret->type == KEY_UNSPEC) { ret->type = type; } else if (ret->type != type) { - /* is a key, but different type */ - debug3("key_read: type mismatch"); - return 0; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + /* is a key, but different type */ + debug3("key_read: type mismatch"); + return 0; + } + ret->type = type; } - len = 2*strlen(cp); - blob = xmalloc(len); - n = uudecode(cp, blob, len); - if (n < 0) { - error("key_read: uudecode %s failed", cp); - return -1; + debug3("key_read: here -- ret->type == %d", ret->type); + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + char *quote, *newline; + debug3("key_read: reading named key %s", cp); + if (cp == NULL || *cp == '\0') + return 0; + if (*cp == '"') { + quote = strchr(++cp, '"'); + if (quote == NULL) { + debug3("key_read: missing quote"); + return 0; + } + *quote = '\0'; + } + newline = strchr(cp, '\n'); + if (newline != NULL) + *newline = '\0'; + debug3("key_read: reading named key %s", cp); + k = key_new(ret->type); + k->name = (unsigned char *) xstrdup(cp); + k->name_len = strlen(cp); + k->name_type = name_type; + if (newline !=NULL) + *newline = '\n'; + if (quote !=NULL) + *quote = '"'; + debug3("key_read: read named key %s", k->name_type); + } else { + len = 2*strlen(cp); + blob = xmalloc(len); + n = uudecode(cp, blob, len); + if (n < 0) { + error("key_read: uudecode %s failed", cp); + return -1; + } + debug3("key_read: reading uuencoded key %s", blob); + k = key_from_blob(blob, n); } - k = key_from_blob(blob, n); if (k == NULL) { error("key_read: key_from_blob %s failed", cp); return -1; } - xfree(blob); + if (blob != NULL) + xfree(blob); if (k->type != type) { - error("key_read: type mismatch: encoding error"); - key_free(k); - return -1; + if (! ((ret->type == KEY_NAME) && + type == KEY_NAME_PAT)) { + error("key_read: type mismatch: encoding error"); + key_free(k); + return -1; + } } /*XXXX*/ - if (ret->type == KEY_RSA) { + if ((ret->type == KEY_NAME) || (ret->type == KEY_NAME_PAT)) { + /* + if (ret->name != NULL) + xfree(ret->name); + */ + ret->name = k->name; + ret->name_len = k->name_len; + ret->name_type = k->name_type; + k->name = NULL; + k->name_type = NULL; + k->name_len = 0; + success = 1; + } else if (ret->type == KEY_RSA) { if (ret->rsa != NULL) RSA_free(ret->rsa); ret->rsa = k->rsa; @@ -487,7 +620,7 @@ } } else if ((key->type == KEY_DSA && key->dsa != NULL) || (key->type == KEY_RSA && key->rsa != NULL)) { - int len, n; + u_int len, n; u_char *blob, *uu; key_to_blob(key, &blob, &len); uu = xmalloc(2*len); @@ -498,6 +631,14 @@ } xfree(blob); xfree(uu); + } else if (key->type == KEY_NAME && key->name != NULL && + key->name_len) { + + fprintf(f, "%s ", key_ssh_name(key)); + if (key->name_type != NULL) + fprintf(f, ":%s", key->name_type); + else + fprintf(f, " \"%.*s\"", key->name, key->name_len); } return success; } @@ -514,6 +655,12 @@ case KEY_DSA: return "DSA"; break; + case KEY_NAME: + return "Named"; + break; + case KEY_NAME_PAT: + return "Name_Pattern"; + break; } return "unknown"; } @@ -527,6 +674,12 @@ case KEY_DSA: return "ssh-dss"; break; + case KEY_NAME: + return "ssh-ext-named"; + break; + case KEY_NAME_PAT: + return "ssh-ext-name-pat"; + break; } return "ssh-unknown"; } @@ -604,6 +757,16 @@ BN_copy(n->rsa->n, k->rsa->n); BN_copy(n->rsa->e, k->rsa->e); break; + case KEY_NAME: + case KEY_NAME_PAT: + n = key_new(k->type); + n->name_len = k->name_len; + n->name = xmalloc(k->name_len); + memcpy(n->name, k->name, n->name_len); + if (k->name_type) { + n->name_type = xstrdup(k->name_type); + } + break; default: fatal("key_from_private: unknown type %d", k->type); break; @@ -624,6 +787,14 @@ return KEY_RSA; } else if (strcmp(name, "ssh-dss") == 0){ return KEY_DSA; + } else if (strcmp(name, "ssh-ext-named") == 0){ + return KEY_NAME; + } else if (strncmp(name, "ssh-ext-named:", strlen("ssh-ext-named:")) == 0){ + return KEY_NAME; + } else if (strcmp(name, "ssh-ext-name-pat") == 0){ + return KEY_NAME_PAT; + } else if (strncmp(name, "ssh-ext-name-pat:", strlen("ssh-ext-name-pat:")) == 0){ + return KEY_NAME_PAT; } else if (strcmp(name, "null") == 0){ return KEY_NULL; } Index: 2_9_p2_w_gss_and_krb5.4/auth2.c --- 2_9_p2_w_gss_and_krb5.4/auth2.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/k/6_auth2.c 1.2 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/auth2.c Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/k/6_auth2.c 1.3 644) @@ -514,7 +514,7 @@ buffer_dump(&b); #endif /* test for correct signature */ - if (user_key_allowed(authctxt->pw, key) && + if (user_key_allowed(authctxt->pw, key) > 0 && key_verify(key, sig, slen, buffer_ptr(&b), buffer_len(&b)) == 1) authenticated = 1; buffer_clear(&b); @@ -531,7 +531,7 @@ * if a user is not allowed to login. is this an * issue? -markus */ - if (user_key_allowed(authctxt->pw, key)) { + if (user_key_allowed(authctxt->pw, key) > 0) { packet_start(SSH2_MSG_USERAUTH_PK_OK); packet_put_string(pkalg, alen); packet_put_string(pkblob, blen); @@ -791,19 +791,36 @@ continue; } } - if (key_equal(found, key) && - auth_parse_options(pw, options, file, linenum) == 1) { - found_key = 1; - debug("matching key found: file %s, line %ld", - file, linenum); + if (key_equal(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key == 0) + continue; + break; + } + if (key_match(found, key)) { + found_key = auth_parse_options(pw, options, file, linenum); + if (found_key == 0) + continue; + /* Special treatment for key name patterns belongs here */ break; } } + +done: restore_uid(); fclose(f); key_free(found); - if (!found_key) + if (found_key > 0) { + debug("matching key found: file %s, line %ld", + file, linenum); + auth_set_key_env(key); + } + if (found_key == 0) debug2("key not found"); + if (found_key < 0) { + debug("user_key_allowed: matching deny key found: " + "file %s, line %ld", file, linenum); + } return found_key; } Index: 2_9_p2_w_gss_and_krb5.4/auth-rsa.c --- 2_9_p2_w_gss_and_krb5.4/auth-rsa.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/15_auth-rsa.c 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/auth-rsa.c Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/k/15_auth-rsa.c 1.2 644) @@ -259,7 +259,7 @@ * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (auth_parse_options(pw, options, file, linenum) < 1) continue; /* Perform the challenge-response dialog for this key. */ Index: 2_9_p2_w_gss_and_krb5.4/auth-options.h --- 2_9_p2_w_gss_and_krb5.4/auth-options.h Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/21_auth-optio 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/auth-options.h Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/k/21_auth-optio 1.2 644) @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -37,6 +39,9 @@ int auth_parse_options(struct passwd *pw, char *options, char *file, u_long linenum); + +void +auth_set_key_env(Key *k); /* reset options flags */ void auth_clear_options(void); Index: 2_9_p2_w_gss_and_krb5.4/auth-options.c --- 2_9_p2_w_gss_and_krb5.4/auth-options.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/k/22_auth-optio 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/auth-options.c Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/k/22_auth-optio 1.2 644) @@ -55,8 +55,43 @@ channel_clear_permitted_opens(); } +void auth_set_key_env(Key *k) +{ + struct envstring *new_env; + char *s; + int len; + + if (k->type != KEY_NAME) + return; + + len = strlen("SSH_AUTH_EXT_NAME="); + len += k->name_len + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_EXT_NAME=%.*s", k->name_len, k->name); + debug3("auth_set_key_env: Adding to the environment: %.*s", len, s); + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + if (k->name_type == NULL) + return; + + len = strlen("SSH_AUTH_EXT_NAME_TYPE="); + len += strlen(k->name_type) + 1; + s = xmalloc(len); + snprintf(s, len, "SSH_AUTH_EXT_NAME_TYPE=%s", k->name_type); + + new_env = xmalloc(sizeof(struct envstring)); + new_env->s = s; + new_env->next = custom_environment; + custom_environment = new_env; + + return; +} + /* - * return 1 if access is granted, 0 if not. + * return 1 if access is granted, 0 if not, -1 if access explicitly denied * side effect: sets key option flags */ int @@ -72,6 +107,12 @@ return 1; while (*opts && *opts != ' ' && *opts != '\t') { + cp = "deny-access"; + if (strncasecmp(opts, cp, strlen(cp)) == 0) { + log("Authentication successful, but authorization denied"); + packet_send_debug("Permission denied"); + return -1; + } cp = "no-port-forwarding"; if (strncasecmp(opts, cp, strlen(cp)) == 0) { packet_send_debug("Port forwarding disabled."); Index: 2_9_p2_w_gss_and_krb5.4/gss-serv.c --- 2_9_p2_w_gss_and_krb5.4/gss-serv.c Tue, 26 Jun 2001 16:27:13 -0400 willian (OpenSSH/l/25_gss-serv.c 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.5/gss-serv.c Tue, 03 Jul 2001 13:14:57 -0400 willian (OpenSSH/l/25_gss-serv.c 1.4 644) @@ -127,24 +127,38 @@ int ssh_gssapi_krb5_userok(char *name) { krb5_principal princ; - int retval; + int retval, retval2; + Key k; if (ssh_gssapi_krb5_init() == 0) return 0; + k.type = KEY_NAME; + k.name = gssapi_client_name.value; + k.name_len = strlen(gssapi_client_name.value); + k.name_type = "krb5"; + + debug3("ssh_gssapi_krb5_userok:"); + debug3("ssh_gssapi_krb5_userok: %s", k.name_type); + if ((retval=krb5_parse_name(krb_context, gssapi_client_name.value, &princ))) { log("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context,retval)); return 0; } + + retval2 = user_key_allowed(getpwnam(name), &k); + if (retval2 < 0) + return 0; + if (krb5_kuserok(krb_context, princ, name)) retval = 1; else retval = 0; krb5_free_principal(krb_context, princ); - return retval; + return retval | retval2; } /* Make sure that this is called _after_ we've setuid to the user */ 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 shalott.net Wed Jul 4 06:31:15 2001 From: jason at shalott.net (Jason Stone) Date: Tue, 3 Jul 2001 13:31:15 -0700 (PDT) Subject: turning on none cipher for v1 and v2 server In-Reply-To: <0107031255150P.31826@movitslinux.bloomberg.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Well, I need it for business reasons. Can you point me to the people > that hacked the support in? Someone was doing speed trials several months ago and posted this bit of patch to cipher.c. The none_* functions already exist, so you should be able to just add in this bit of code and go. ----------------------------------------------- Date: Wed, 10 Jan 2001 12:24:07 -0500 (EST) From: Rob Hagopian Cc: openssh-unix-dev at mindrot.org Subject: Re: ssh speed [...] I did "hack the source" (hehehe) to add none: rijndael_setkey, rijndael_setiv, rijndael_cbc_encrypt, rijndael_cbc_decrypt }, + { "none2", + SSH_CIPHER_SSH2, 8, 0, + none_setkey, none_setiv, + none_crypt, none_crypt }, { NULL, SSH_CIPHER_ILLEGAL, 0, 0, NULL, NULL, NULL, NULL } }; (it's none2 to avoid name collision with the ssh1 none) ----------------------------------------------- -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 iD8DBQE7QiuYswXMWWtptckRAiCJAKD4FMZFQIZU7wbxuuzOa6HSPau6lwCfZNVc kmCEdKKUSggO/KIZj7rn7Ek= =a4M4 -----END PGP SIGNATURE----- From levan at epix.net Wed Jul 4 11:56:22 2001 From: levan at epix.net (Philippe Levan) Date: Tue, 3 Jul 2001 21:56:22 -0400 (EDT) Subject: remote forwarding in 2.9p2 Message-ID: Hi, It looks like remote forwarding with SSH v2 is not working on my Solaris machines (and from what I understand from the source, it may not work elsewhere either). When looking at channel_post_port_listener() in channels.c, I found that nextstate was defined as : nextstate = (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : SSH_CHANNEL_OPENING; And later comes the call : if (nextstate != SSH_CHANNEL_DYNAMIC) port_open_helper(nc, rtype); It turns out that on the server-side, for a channel type of SSH_CHANNEL_RPORT_LISTENER, c->host_port is 0 and therefore, per the above code, nextstate == SSH_CHANNEL_DYNAMIC and port_open_helper() is not called. I am not sure what the function of SSH_CHANNEL_DYNAMIC is but it looks like it has something to do with socks4 (from looking at channel_pre_dynamic()) and probably doesn't apply to the SSH_CHANNEL_RPORT_LISTENER case. I suspect that nextstate should be SSH_CHANNEL_OPENING in order to call port_open_helper(). I tried to make the change : nextstate = (c->type == SSH_CHANNEL_RPORT_LISTENER) ? SSH_CHANNEL_OPENING : (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : SSH_CHANNEL_OPENING; And that seems to work. Anyone care to check and confirm the fix or point me in the right direction ? Thanks. Philippe. --- Philippe Levan | Systems Engineering levan at epix.net | epix Internet Services From dankamin at cisco.com Wed Jul 4 14:18:20 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Tue, 3 Jul 2001 21:18:20 -0700 Subject: turning on none cipher for v1 and v2 server References: Message-ID: <050d01c10440$5cd18ea0$6b00040a@na.cisco.com> > Put it simplity.. > > using 'none' cipher can result in man-in-the-middle attacks against you. > And since ssh was designed to protect against that and against information > leakage it would break the integerity of protocol to support such a thing. > > I have seen people hack 'none' into the ssh client. However, we will not > support such things. > > - Ben You're correct in terms of SSH1. SSH1 uses its encryption function for integrity verification, so the lack of a cipher means anyone can inject arbitrary packets. (Essentially, the system presumes that the only two entities who share the symmetric key are the client and the server, meaning all messages that weren't sent from one side and decrypt correctly had to have been legitimately sent from the other.) SSH2, by contrast, separates the cipher from the integrity verifier, using a distinct HMAC for each message being exchanged between the client and the server. This HMAC is entirely functional even when encryption is disabled entirely--any man in the middle will indeed be able to view the datastream in its entirety, but it won't be able to change a thing. This isn't an accident. Beyond the fact that separating integrity killed lots and lots of packet injection attacks dead, there's a good deal of theoretical justification for the separate and independent emphasis. Some messages are presumed to be private, many are assumed to be public, but *all* messages are assumed to be intact, whether or not we have a good reason to believe so. Integrity verifiers exist to give us that reason, but when you read an article from http://www.nytimes.com or http://www.cnn.com, you still *think* you're reading from an authenticated source--the pixels tell you so. Even I believed http://www.pacland.cc/pics/zoomzoom.jpg . The web needs to be mass-authenticated long before it needs to be mass-encrypted(though the masking noise would be helpful). Unfortunately, most of the development energy is going into systems for making it easier to swipe your mother's maiden name every time you click on a stupid link...*sigh* If a user wants to safely send public-readable messages, not only is it not dangerous, it's not surprising. There's a highly legitimate need for messages that are simply not changeable in transit--read only, not read-write. Given the weakness that's becoming apparent in web security, we can't really deny what others have been painfully blind to. Anyway. Enough preaching: This works: $ ssh -2 -m hmac-sha1 -c arcfour user at host This should work, but instead uses AES. Now *that's* incorrect behavior! We need to break if we don't recognize a cipher. $ ssh -2 -m hmac-sha1 -c none user at host This must fail--it doesn't(uses 3DES), and that's a problem. $ ssh -1 -c none user at host Since SSH2 apparently refuses to work with a null HMAC, are there any other objections you have to might have to allowing SSH2 to exist cipherless? And is there any objection to making unknown ciphers fail like unknown HMACs? Yours Truly, Dan Kaminsky, CISSP http://www.doxpara.com From carl at bl.echidna.id.au Wed Jul 4 14:47:25 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Wed, 4 Jul 2001 14:47:25 +1000 (EST) Subject: connection attempt timeout - possible feature? Message-ID: <200107040447.f644lPV3015887@rollcage.bl.echidna.id.au> I'm writing a network monitoring script, that has to traverse a bunch of firewalls (joy ...) and so for connectivity tests, I'm using ssh (OpenSSH 2.x). I'm being lazy, and trying to avoid parallel tasks/threading, so I'm interested in reducing the amount of time OpenSSH will wait to connect to something before giving up. I've already set the ConnectionAttempts flag to 1, but am interested in reducing the amount of time it uses initially. From our boxes, the timeout seems to be abuot 60 seconds, but I haven't timed it yet, or groveled through the code enough to know for sure. Before I embark on a coding spree and hack at OpenSSH to do this, am I looking in the right place? Is this behaviour controlled by the application or the OS? My copy of Stevens is at home, and I'm not, so my usual reference isn't available right now. If it is an application specific, would the OpenSSH team be interested in a patch if I write one? Carl From mouring at etoh.eviladmin.org Wed Jul 4 14:42:42 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 3 Jul 2001 23:42:42 -0500 (CDT) Subject: connection attempt timeout - possible feature? In-Reply-To: <200107040447.f644lPV3015887@rollcage.bl.echidna.id.au> Message-ID: This was talked about on efnet #unixhelp about a week ago while talking about why ssh takes such a long time to timeout. It's a feature of the OS and the connect() function call in question, IIRC. So in theory one could wrap the call in sshconnect.c (both places) with a timer to interrupt connect(). Not sure if there is a cleaner way off hand. - Ben On Wed, 4 Jul 2001 carl at bl.echidna.id.au wrote: > > I'm writing a network monitoring script, that has to traverse > a bunch of firewalls (joy ...) and so for connectivity tests, > I'm using ssh (OpenSSH 2.x). > > I'm being lazy, and trying to avoid parallel tasks/threading, > so I'm interested in reducing the amount of time OpenSSH will wait > to connect to something before giving up. I've already set the > ConnectionAttempts flag to 1, but am interested in reducing the amount of > time it uses initially. From our boxes, the timeout seems to be abuot 60 seconds, > but I haven't timed it yet, or groveled through the code enough > to know for sure. > > > Before I embark on a coding spree and hack at OpenSSH to > do this, am I looking in the right place? Is this behaviour > controlled by the application or the OS? My copy of Stevens is > at home, and I'm not, so my usual reference isn't available right now. > > If it is an application specific, would the OpenSSH team be interested in > a patch if I write one? > > Carl > > From dankamin at cisco.com Wed Jul 4 15:09:18 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Tue, 3 Jul 2001 22:09:18 -0700 Subject: connection attempt timeout - possible feature? References: Message-ID: <056101c10447$7b3a6c20$6b00040a@na.cisco.com> > This was talked about on efnet #unixhelp about a week ago while talking > about why ssh takes such a long time to timeout. It's a feature of the OS > and the connect() function call in question, IIRC. > > So in theory one could wrap the call in sshconnect.c (both places) with a > timer to interrupt connect(). Not sure if there is a cleaner way off > hand. This is/was a problem with the dynamic forwarding code -- port forwards were blocking the entire server process when the user connected to a down port -- could code be shared from there? --Dan From mouring at etoh.eviladmin.org Wed Jul 4 15:37:28 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 4 Jul 2001 00:37:28 -0500 (CDT) Subject: Sneek peak at what was commited. Message-ID: For those following the portable CVS tree.. I'd suggest holding off for a day or so unless you really want to get dirty. I just commited 32 patches from the OpenBSD tree, but have not worked out all the issues (due to Linux brain damage ). The two things that need to be finished integrated in the configure.in is KRB5 and Cryptocard stuff. I will not assure it will compile on any platform in its' current form. =) 20010704 - OpenBSD CVS Sync - markus at cvs.openbsd.org 2001/06/25 08:25:41 [channels.c channels.h cipher.c clientloop.c compat.c compat.h hostfile.c kex.c kex.h key.c key.h nchan.c packet.c serverloop.c session.c session.h sftp-server.c ssh-add.c ssh-agent.c uuencode.h] update copyright for 2001 - markus at cvs.openbsd.org 2001/06/25 17:18:27 [ssh-keygen.1] sshd(8) will never read the private keys, but ssh(1) does; hugh at mimosa.com - provos at cvs.openbsd.org 2001/06/25 17:54:47 [auth.c auth.h auth-rsa.c] terminate secure_filename checking after checking homedir. that way it works on AFS. okay markus@ - stevesk at cvs.openbsd.org 2001/06/25 20:26:37 [auth2.c sshconnect2.c] prototype cleanup; ok markus@ - markus at cvs.openbsd.org 2001/06/26 02:47:07 [ssh-keygen.c] allow loading a private RSA key to a cyberflex card. - markus at cvs.openbsd.org 2001/06/26 04:07:06 [ssh-agent.1 ssh-agent.c] add debug flag - markus at cvs.openbsd.org 2001/06/26 04:59:59 [authfd.c authfd.h ssh-add.c] initial support for smartcards in the agent - markus at cvs.openbsd.org 2001/06/26 05:07:43 [ssh-agent.c] update usage - markus at cvs.openbsd.org 2001/06/26 05:33:34 [ssh-agent.c] more smartcard support. - mpech at cvs.openbsd.org 2001/06/26 05:48:07 [sshd.8] remove unnecessary .Pp between .It; millert@ ok - markus at cvs.openbsd.org 2001/06/26 05:50:11 [auth2.c] new interface for secure_filename() - itojun at cvs.openbsd.org 2001/06/26 06:32:58 [atomicio.h authfd.h authfile.h auth.h auth-options.h bufaux.h buffer.h canohost.h channels.h cipher.h clientloop.h compat.h compress.h crc32.h deattack.h dh.h dispatch.h groupaccess.h hostfile.h kex.h key.h log.h mac.h match.h misc.h mpaux.h packet.h radix.h readconf.h readpass.h rsa.h] prototype pedant. not very creative... - () -> (void) - no variable names - itojun at cvs.openbsd.org 2001/06/26 06:33:07 [servconf.h serverloop.h session.h sftp-client.h sftp-common.h sftp-glob.h sftp-int.h sshconnect.h ssh-dss.h sshlogin.h sshpty.h ssh-rsa.h tildexpand.h uidswap.h uuencode.h xmalloc.h] prototype pedant. not very creative... - () -> (void) - no variable names - dugsong at cvs.openbsd.org 2001/06/26 16:15:25 [auth1.c auth.h auth-krb4.c auth-passwd.c readconf.c readconf.h servconf.c servconf.h session.c sshconnect1.c sshd.c] Kerberos v5 support for SSH1, mostly from Assar Westerlund and Bjorn Gronvall . markus@ ok - markus at cvs.openbsd.org 2001/06/26 17:25:34 [ssh.1] document SSH_ASKPASS; fubob at MIT.EDU - markus at cvs.openbsd.org 2001/06/26 17:27:25 [authfd.h authfile.h auth.h auth-options.h bufaux.h buffer.h canohost.h channels.h cipher.h clientloop.h compat.h compress.h crc32.h deattack.h dh.h dispatch.h groupaccess.c groupaccess.h hostfile.h kex.h key.h log.c log.h mac.h misc.c misc.h mpaux.h packet.h radix.h readconf.h readpass.h rsa.h servconf.h serverloop.h session.h sftp-common.c sftp-common.h sftp-glob.h sftp-int.h sshconnect.h ssh-dss.h sshlogin.h sshpty.h ssh-rsa.h sshtty.h tildexpand.h uidswap.h uuencode.h xmalloc.h] remove comments from .h, since they are cut&paste from the .c files and out of sync - dugsong at cvs.openbsd.org 2001/06/26 17:41:49 [servconf.c] #include - markus at cvs.openbsd.org 2001/06/26 20:14:11 [key.c key.h ssh.c sshconnect1.c sshconnect2.c] add smartcard support to the client, too (now you can use both the agent and the client). - markus at cvs.openbsd.org 2001/06/27 02:12:54 [serverloop.c serverloop.h session.c session.h] quick hack to make ssh2 work again. - markus at cvs.openbsd.org 2001/06/27 04:48:53 [auth.c match.c sshd.8] tridge at samba.org - markus at cvs.openbsd.org 2001/06/27 05:35:42 [ssh-keygen.c] use cyberflex_inq_class to inquire class. - markus at cvs.openbsd.org 2001/06/27 05:42:25 [rsa.c rsa.h ssh-agent.c ssh-keygen.c] s/generate_additional_parameters/rsa_generate_additional_parameters/ http://www.humppa.com/ - markus at cvs.openbsd.org 2001/06/27 06:26:36 [ssh-add.c] convert to getopt(3) - stevesk at cvs.openbsd.org 2001/06/28 19:57:35 [ssh-keygen.c] '\0' terminated data[] is ok; ok markus@ - markus at cvs.openbsd.org 2001/06/29 07:06:34 [ssh-keygen.c] new error handling for cyberflex_* - markus at cvs.openbsd.org 2001/06/29 07:11:01 [ssh-keygen.c] initialize early - stevesk at cvs.openbsd.org 2001/06/29 18:38:44 [clientloop.c] sync function definition with declaration; ok markus@ - stevesk at cvs.openbsd.org 2001/06/29 18:40:28 [channels.c] use socklen_t for getsockopt arg #5; ok markus@ - stevesk at cvs.openbsd.org 2001/06/30 18:08:40 [channels.c channels.h clientloop.c] adress -> address; ok markus@ - markus at cvs.openbsd.org 2001/07/02 13:59:15 [serverloop.c session.c session.h] wait until !session_have_children(); bugreport from Lutz.Jaenicke at aet.TU-Cottbus.DE - markus at cvs.openbsd.org 2001/07/02 22:29:20 [readpass.c] do not return NULL, use "" instead. - markus at cvs.openbsd.org 2001/07/02 22:40:18 [ssh-keygen.c] update for sectok.h interface changes. - markus at cvs.openbsd.org 2001/07/02 22:52:57 [channels.c channels.h serverloop.c] improve cleanup/exit logic in ssh2: stop listening to channels, detach channel users (e.g. sessions). wait for children (i.e. dying sessions), send exit messages, cleanup all channels. - (bal) forget a few new files in sync up. - (bal) Makefile fix up requires scard.c - Ben Sleep calls, and I must listen.. Have a happy 4th of July for all you Americans out there. From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jul 4 23:20:55 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 4 Jul 2001 15:20:55 +0200 Subject: 2.9p?: connection hangs with agent forwarding In-Reply-To: <20010703174609.A24341@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Jul 03, 2001 at 05:46:09PM +0200 References: <20010703174609.A24341@serv01.aet.tu-cottbus.de> Message-ID: <20010704152054.A6874@ws01.aet.tu-cottbus.de> On Tue, Jul 03, 2001 at 05:46:09PM +0200, Lutz Jaenicke wrote: > when using agent forwarding, the connection hangs on exit, if the agent has > been accessed. ... Following up to myself. I have spent some more hours^H^H^H^H^Htime with debugger and source and think that I finally nailed down the reason for this problem. > Symptoms: > - On the server side, the following steps are logged: > debug1: channel 3: new [accepted auth socket] > debug1: channel 3: open confirm rwindow 4096 rmax 32768 > debug1: channel 3: read<=0 rfd 11 len 0 > debug1: channel 3: read failed > debug1: channel 3: input open -> drain > debug1: channel 3: close_read > debug1: channel 3: ibuf empty > debug1: channel 3: input drain -> closed > debug1: channel 3: send eof At this point, the side accessing the agent remotely has finished its access and closes the connection. The sshd now closes the channel for the read direction: the remote process has closed the connection and hence the "select on read from remote process" was triggered and failed. Therefore the read connection is being closed. ["*" Please bear in mind, that the process accessing the agent remotely has completely closed the connection, so "select for write" would also fail, but as no data is available to be written, this is not noted.] > - On the client side, when the agent is accessed, the following output > is being logged: > debug1: channel 1: new [authentication agent connection] > debug1: confirm auth-agent at openssh.com > debug1: channel 1: rcvd eof > debug1: channel 1: output open -> drain > debug1: channel 1: obuf empty > debug1: channel 1: output drain -> closed > debug1: channel 1: close_write The ssh process started with "-A" now receives the "close read channel" from the sshd process (its seeing it as writing side). When the close_write is logged, the ssh process uses "shutdown(sock, WR)" to shut down the connection to the actual agent process. At this point the problem appears: the agent process is in select() for read and the "shutdown(sock, WR)" does not trigger select(). Therefore ssh-agent never notes, that the connection was actually closed. [Coming back to "*": at this point normally ssh-agent would close() the connection to ssh, ssh would therefore also initiate the closing of the other direction of the channel and the channel would be completely closed. As this does not happen, the channel stays open for one direction.] {As ssh-agent does not note the close, the slot for the connection is never freed and ssh-agent will run out of resources. This has been reported quite some time ago but at that time I did not see the relation to the "hanging" agent connection problem.} > The platform is HP-UX 10.20 (hanging on "sleep 20 &" test, maybe this is > related!?). > This is true with 2.9p1 (and older versions, if memory serves me right) > up to the latest portable-CVS. > I can fire up the debugger to help track it down, but by digging through > the source I didn't find, who should close the channel (server or client). > Shooting into the dark: HP-UX 10.20 needs USE_PIPES and must call close(), > as shutdown() in just one direction does seem to work as on other > platforms (see serverloop.c). This shutdown() problem is the precise reason, why USE_PIPES is already needed for other connections on HP-UX. It may therefore be possible to reproduce this problem on other platforms requiring USE_PIPES (cygwin, hpux, NeXT, SunOS4, SNI, SYSV*, SCO*). I am not sure on what solution to recommend. I have not yet checked out, whether select() would trigger on the errorfd (recent reports for prngd have indicated, that errorfd (in some documentations also referred to as exception_fd) behaves different between platforms). As its use is not prepared in e.g. clientloop.c and quite some changes would be needed, I have not yet touched it. On the other hand, if sshd would react on the complete close of its local agent connection and would itself initiate the bi-directional shutdown (the accessing process actually has closed both sides), the problem would also not appear. So much for now, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From Markus.Friedl at informatik.uni-erlangen.de Wed Jul 4 23:42:33 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 4 Jul 2001 15:42:33 +0200 Subject: 2.9p?: connection hangs with agent forwarding In-Reply-To: <20010704152054.A6874@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Wed, Jul 04, 2001 at 03:20:55PM +0200 References: <20010703174609.A24341@serv01.aet.tu-cottbus.de> <20010704152054.A6874@ws01.aet.tu-cottbus.de> Message-ID: <20010704154233.A16767@faui02.informatik.uni-erlangen.de> On Wed, Jul 04, 2001 at 03:20:55PM +0200, Lutz Jaenicke wrote: > On the other hand, if sshd would react on the complete close of its local > agent connection and would itself initiate the bi-directional shutdown > (the accessing process actually has closed both sides), the problem would > also not appear. some time ago i recevied a patch that tried to do this: mark a 'forwarded channel' as special if it's a agent connection. force a close for the send-half if the received half is closed however, the patch modified the protocol (this was not acceptiple). are you talking about a shutdown of a socket or of a 'forwarded' channel? From t0pper at hotmail.com Thu Jul 5 02:42:31 2001 From: t0pper at hotmail.com (_t0pper _) Date: Wed, 04 Jul 2001 11:42:31 -0500 Subject: OpenSSH 2 - can't get pubkeys to authenticate Message-ID: The System: RedHat 7.0 OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f Client: PuTTY The Problem: I've installed the newest version of OpenSSH on RedHat 7.0 and can get most things to work, except when I want to use Public Keys with version 2.0. If I use straight password authentication, I can get PuTTY to connect using either SSH 1 or SSH 2. If I RSA authentication for SSH1, it also works, no matter if I create the key on the client and transport the public key to the server or if I create the keys on the server and get the private key to the client. Both ways are successful. (Yes, I use authorized_keys in the $HOME/.ssh directory). The problem I'm running into is getting public key authentication to work with SSH2. I create the keys on the server, put the public key into the authorized_keys2 file and transport the private key to the client. When I try to connect to the server, it prompts me for a username, I put that in, but then it asks for my password.... This shouldn't happen. I have password authentication turned off (so of course, if I enter in a password, it fails). The following is the logon as it occurred: login as: xxxxxx password: Access denied login as: password: I've include my sshd_config file and some debugging information, if anyone can help me, I'd really appreciate it. I've read about all the FAQs and READMEs that exist and keep hitting my head against a wall. El Manual isn't helping me out here. Thanks, t0p <---Begin /etc/ssh/sshd_config---> Port 22 Protocol 2,1 ListenAddress 0.0.0.0 HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no IgnoreRhosts yes IgnoreUserKnownHosts yes StrictModes yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes KeepAlive yes SyslogFacility AUTH LogLevel INFO RhostsAuthentication no RhostsRSAAuthentication no HostbasedAuthentication no RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no Subsystem sftp /usr/libexec/openssh/sftp-server <---END /etc/ssh/sshd_config---> <---DEBUG CODE---> debug1: Seeding random number generator debug1: sshd version OpenSSH_2.9p2 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 1.2.3.4 port 2267 debug1: Client protocol version 2.0; client software version PuTTY debug1: no match: PuTTY Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server 3des-cbc hmac-sha1 none debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: dh_gen_key: priv key bits set: 192/384 debug1: bits set: 516/1024 debug1: expecting SSH2_MSG_KEXDH_INIT debug1: bits set: 494/1024 debug1: sig size 20 20 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 xxxxxx service ssh-connection method password debug1: attempt 0 failures 0 debug1: Starting up PAM with username "xxxxxx" debug1: PAM setting rhost to "machine.domain.com" Failed password for xxxxxx from 1.2.3.4 port 2267 ssh2 debug1: userauth-request for user xxxxxx service ssh-connection method password debug1: attempt 1 failures 1 Failed password for xxxxxx from 1.2.3.4 port 2267 ssh2 Read from socket failed: Connection reset by peer debug1: Calling cleanup 0x8051950(0x0) debug1: Calling cleanup 0x8066eb0(0x0) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From kevin at tgivan.com Thu Jul 5 04:44:33 2001 From: kevin at tgivan.com (Kevin Sindhu) Date: Wed, 04 Jul 2001 11:44:33 -0700 Subject: IPv6 and sshd Message-ID: <3B436411.CFAD442@tgivan.com> Hello, I am having a some problems getting SSHD to run on the Ipv6 interface. Interface/Ipv6 Address: ipv6.open-systems.org [kevin at satan kevin/xp-0.0.15] 536 $ping6 ipv6.open-systems.org PING6(56=40+8+8 bytes) 3ffe:1200:3028:ff01::cab --> 3ffe:1200:3028:ff01::caa 16 bytes from 3ffe:1200:3028:ff01::caa, icmp_seq=0 hlim=64 time=73.96 ms sshd_config: ListenAddress [3ffe:1200:3028:ff01::caa] ListenAddress [3ffe:1200:3028:8655::1] [Note: I also tried using the address's without the brackets with no results.] sshd version : sshd version OpenSSH_2.9 ssh client connection details: [kevin at athena kevin]$ ssh -v -6 ipv6.open-systems.org -l kevin OpenSSH_2.5.0, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /etc/ssh_config debug: ssh_connect: getuid 1001 geteuid 0 anon 0 debug: Connecting to ipv6.open-systems.org [3ffe:1200:3028:ff01::caa] port 22. debug: Allocated local port 845. debug: connect: Connection refused debug: Trying again... debug: Connecting to ipv6.open-systems.org [3ffe:1200:3028:ff01::caa] port 22. debug: Allocated local port 744. debug: connect: Connection refused What I am doing wrong and why is the sshd not accepting connections? Regards -- Kevin Sindhu Systems Engineer TGI Technologies Inc. Tel: (604) 872-6676 Ext 321 107 E 3rd Avenue Fax: (604) 872-6601 Vancouver,BC V5T 1C7 Canada. From jmknoble at pobox.com Thu Jul 5 04:46:00 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 4 Jul 2001 13:46:00 -0500 Subject: connection attempt timeout - possible feature? In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Jul 03, 2001 at 11:42:42PM -0500 References: <200107040447.f644lPV3015887@rollcage.bl.echidna.id.au> Message-ID: <20010704134600.K16032@zax.half.pint-stowp.cx> Circa 2001-Jul-03 23:42:42 -0500 dixit mouring at etoh.eviladmin.org: : This was talked about on efnet #unixhelp about a week ago while talking : about why ssh takes such a long time to timeout. It's a feature of the OS : and the connect() function call in question, IIRC. : : So in theory one could wrap the call in sshconnect.c (both places) with a : timer to interrupt connect(). Not sure if there is a cleaner way off : hand. You could also do a non-blocking connect(), together with a select() with timeout. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ | 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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010704/577c95a6/attachment.bin From kevin at tgivan.com Thu Jul 5 05:14:22 2001 From: kevin at tgivan.com (Kevin Sindhu) Date: Wed, 04 Jul 2001 12:14:22 -0700 Subject: IPv6 and sshd (Solved?) References: <3B436411.CFAD442@tgivan.com> Message-ID: <3B436B0E.CD0FEF1E@tgivan.com> Update to my post, I have one interface working, one not;-). I get this in the error logs: Jul 4 11:12:14 satan sshd[31246]: error: Bind to port 22 on 3ffe:1200:3028:ff01::caa failed: Can't assign requested address. Jul 4 11:13:49 satan sshd[7797]: error: Bind to port 22 on 3ffe:1200:3028:ff01::caa failed: Can't assign requested address. Now this may be something I did not look at before. My tunnel broker gave me a /64 network address which is bound to my "internal" Network Interface which works through NAT/route6d. However if I try connecting to the interface given by my tunnel broken it fails. Any reason why this doesn't work? For now, I can just change the IPv6 address in DNS to the /64 address and it should work;-) ---------------Details-------------------------------- xl1 : Internal Interface xl1: flags=8843 mtu 1500 media: Ethernet autoselect (100baseTX) status: active inet 192.168.33.1 netmask 0xffffff00 broadcast 192.168.33.255 inet6 fe80::250:daff:feb8:62f9%xl1 prefixlen 64 scopeid 0x3 inet6 3ffe:1200:3028:8655::1 prefixlen 64 xl0 : Public interface xl0: flags=8843 mtu 1500 media: Ethernet autoselect (10baseT) status: active inet6 fe80::201:2ff:fe42:94ee%xl0 prefixlen 64 scopeid 0x2 inet 24.76.251.101 netmask 0xffffff00 broadcast 24.76.251.255 gif0: Ipv6 Tunnel gif0: flags=8051 mtu 1280 physical address inet 24.76.251.101 --> 64.71.128.26 inet6 fe80::280:c6ff:feef:c508%gif0 -> :: prefixlen 64 scopeid 0x10 inet6 3ffe:1200:3028:ff01::cab -> 3ffe:1200:3028:ff01::caa prefixlen 127 Connection to xl1: [kevin at athena kevin]$ ssh -v -6 3ffe:1200:3028:8655::1 -l kevin OpenSSH_2.5.0, SSH protocols 1.5/2.0, OpenSSL 0x0090600f debug: Reading configuration data /etc/ssh_config debug: ssh_connect: getuid 1001 geteuid 0 anon 0 debug: Connecting to 3ffe:1200:3028:8655::1 [3ffe:1200:3028:8655::1] port 22. debug: Allocated local port 682. debug: Connection established. debug: identity file /home/kevin/.ssh/identity type 3 debug: identity file /home/kevin/.ssh/id_dsa type 3 debug: Remote protocol version 1.99, remote software version OpenSSH_2.9 debug: match: OpenSSH_2.9 pat ^OpenSSH debug: Local version string SSH-1.5-OpenSSH_2.5.0 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). The authenticity of host '3ffe:1200:3028:8655::1 (3ffe:1200:3028:8655::1)' can't be established. RSA1 key fingerprint is c2:60:be:fe:82:80:f7:fd:ff:1e:f8:4e:12:c4:c3:67. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '3ffe:1200:3028:8655::1' (RSA1) to the list of known hosts. debug: Encryption type: 3des debug: Sent encrypted session key. debug: Installing crc compensation attack detector. debug: Received encrypted confirmation. debug: Doing password authentication. kevin at 3ffe:1200:3028:8655::1's password: ----------------------------------------------- -- Kevin Sindhu Systems Engineer TGI Technologies Inc. Tel: (604) 872-6676 Ext 321 107 E 3rd Avenue Fax: (604) 872-6601 Vancouver,BC V5T 1C7 Canada. From carl at bl.echidna.id.au Thu Jul 5 08:26:38 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Thu, 5 Jul 2001 08:26:38 +1000 (EST) Subject: IPv6 and sshd Message-ID: <200107042226.f64MQcgj029821@rollcage.bl.echidna.id.au> > From: Kevin Sindhu > > Hello, > > I am having a some problems getting SSHD to run on the Ipv6 interface. > > Interface/Ipv6 Address: ipv6.open-systems.org > > [kevin at satan kevin/xp-0.0.15] 536 $ping6 ipv6.open-systems.org > PING6(56=40+8+8 bytes) 3ffe:1200:3028:ff01::cab --> > 3ffe:1200:3028:ff01::caa > 16 bytes from 3ffe:1200:3028:ff01::caa, icmp_seq=0 hlim=64 time=73.96 > ms > > sshd_config: > > ListenAddress [3ffe:1200:3028:ff01::caa] > ListenAddress [3ffe:1200:3028:8655::1] > > [Note: I also tried using the address's without the brackets with no > results.] > > sshd version : sshd version OpenSSH_2.9 > > ssh client connection details: > > [kevin at athena kevin]$ ssh -v -6 ipv6.open-systems.org -l kevin > OpenSSH_2.5.0, SSH protocols 1.5/2.0, OpenSSL 0x0090600f > debug: Reading configuration data /etc/ssh_config > debug: ssh_connect: getuid 1001 geteuid 0 anon 0 > debug: Connecting to ipv6.open-systems.org [3ffe:1200:3028:ff01::caa] > port 22. > debug: Allocated local port 845. > debug: connect: Connection refused > debug: Trying again... > debug: Connecting to ipv6.open-systems.org [3ffe:1200:3028:ff01::caa] > port 22. > debug: Allocated local port 744. > debug: connect: Connection refused > > What I am doing wrong and why is the sshd not accepting connections? My OpenBSD 2.9 (as did 2.7 and 2.8) machines "just work" with # ListenAddress 0.0.0.0 # ListenAddress :: And my Solaris 8 machines work with : ListenAddress 0.0.0.0 ListenAddress :: DIfficult to help more without knowing how you compiled OpenSSH, or what you installed it on. From pekkas at netcore.fi Thu Jul 5 08:35:19 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 5 Jul 2001 01:35:19 +0300 (EEST) Subject: IPv6 and sshd (Solved?) In-Reply-To: <3B436B0E.CD0FEF1E@tgivan.com> Message-ID: On Wed, 4 Jul 2001, Kevin Sindhu wrote: > Update to my post, I have one interface working, one not;-). I get > this in the error logs: > > Jul 4 11:12:14 satan sshd[31246]: error: Bind to port 22 on > 3ffe:1200:3028:ff01::caa failed: Can't assign requested address. > Jul 4 11:13:49 satan sshd[7797]: error: Bind to port 22 on > 3ffe:1200:3028:ff01::caa failed: Can't assign requested address. [snip] > gif0: flags=8051 mtu 1280 > physical address inet 24.76.251.101 --> 64.71.128.26 > inet6 fe80::280:c6ff:feef:c508%gif0 -> :: prefixlen 64 scopeid > 0x10 > inet6 3ffe:1200:3028:ff01::cab -> 3ffe:1200:3028:ff01::caa > prefixlen 127 You're trying to bind to your tunnel brokers endpoint of virtual tunnel which isn't local. Use cab not caa. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus.friedl at informatik.uni-erlangen.de Thu Jul 5 09:58:33 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 5 Jul 2001 01:58:33 +0200 Subject: remote forwarding in 2.9p2 In-Reply-To: ; from levan@epix.net on Tue, Jul 03, 2001 at 09:56:22PM -0400 References: Message-ID: <20010705015833.B23365@folly> openssh-current has nextstate = (c->host_port == 0 && c->type != SSH_CHANNEL_RPORT_LISTENER) ? SSH_CHANNEL_DYNAMIC : SSH_CHANNEL_OPENING; On Tue, Jul 03, 2001 at 09:56:22PM -0400, Philippe Levan wrote: > Hi, > > It looks like remote forwarding with SSH v2 is not working > on my Solaris machines (and from what I understand from the > source, it may not work elsewhere either). > > When looking at channel_post_port_listener() in channels.c, > I found that nextstate was defined as : > > nextstate = (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : > SSH_CHANNEL_OPENING; > > And later comes the call : > > if (nextstate != SSH_CHANNEL_DYNAMIC) > port_open_helper(nc, rtype); > > It turns out that on the server-side, for a channel type > of SSH_CHANNEL_RPORT_LISTENER, c->host_port is 0 and therefore, > per the above code, nextstate == SSH_CHANNEL_DYNAMIC and > port_open_helper() is not called. > > I am not sure what the function of SSH_CHANNEL_DYNAMIC is but > it looks like it has something to do with socks4 (from looking > at channel_pre_dynamic()) and probably doesn't apply to the > SSH_CHANNEL_RPORT_LISTENER case. I suspect that nextstate should > be SSH_CHANNEL_OPENING in order to call port_open_helper(). > > I tried to make the change : > > nextstate = (c->type == SSH_CHANNEL_RPORT_LISTENER) ? > SSH_CHANNEL_OPENING : > (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : > SSH_CHANNEL_OPENING; > > And that seems to work. > > Anyone care to check and confirm the fix or point me in the > right direction ? > > Thanks. > > Philippe. > > --- > Philippe Levan | Systems Engineering > levan at epix.net | epix Internet Services > From kevin at tgivan.com Thu Jul 5 11:09:41 2001 From: kevin at tgivan.com (Kevin Sindhu) Date: Wed, 04 Jul 2001 18:09:41 -0700 Subject: IPv6 and sshd (Solved?) References: Message-ID: <3B43BE55.BCCFBF3C@tgivan.com> Hi, Yup, doh! umm...double doh!! Thanks a million;-) -Kevin Pekka Savola wrote: > > You're trying to bind to your tunnel brokers endpoint of virtual tunnel > which isn't local. Use cab not caa. From dwd at bell-labs.com Fri Jul 6 01:59:25 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 5 Jul 2001 10:59:25 -0500 Subject: Patch to workaround host key size mismatch bug in old SSH sshd Message-ID: <20010705105925.A10910@lucent.com> Below is a patch against the current OpenBSD OpenSSH CVS to workaround a behavior I have observed when converting from SSH 1.2.27 to OpenSSH while using the same old RSA1 host key for protocol 1. In several cases I saw that old SSH sshd reported a host key size of 1024 bits when OpenSSH saw it as 1023 bits. Without the patch, when OpenSSH's ssh client connects to an old SSH sshd it warns that the server lies about the size, and when an old SSH ssh client connects to an OpenSSH sshd it reports the dreaded "WARNING: HOST IDENTIFICATION HAS CHANGED! IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" An OpenSSH ssh client conveniently ignores the key size in ~/.ssh/authorized_keys (in a kind of convoluted way, I might add) so it doesn't care that the key size reported by OpenSSH sshd is 1023 even if authorized_keys says it's 1024. A pleasant side effect of this patch is that compat.c no longer prints the disconcerting debug message "no match" when communicating with SSH 1.2.23 through 1.2.31. - Dave Dykstra --- compat.h.O Thu Jul 5 10:49:47 2001 +++ compat.h Thu Jul 5 10:50:04 2001 @@ -50,6 +50,7 @@ #define SSH_BUG_HBSERVICE 0x00010000 #define SSH_BUG_OPENFAILURE 0x00020000 #define SSH_BUG_DERIVEKEY 0x00040000 +#define SSH_BUG_SERVERLIESSIZE 0x00080000 void enable_compat13(void); void enable_compat20(void); --- compat.c.O Thu Jul 5 10:49:21 2001 +++ compat.c Thu Jul 5 10:49:27 2001 @@ -105,6 +105,8 @@ { "^1\\.7 SecureFX", SSH_OLD_SESSIONID }, { "^1\\.2\\.1[89]", SSH_BUG_IGNOREMSG }, { "^1\\.2\\.2[012]", SSH_BUG_IGNOREMSG }, + { "^1\\.2\\.2[3-9]", SSH_BUG_SERVERLIESSIZE }, + { "^1\\.2\\.3[0-1]", SSH_BUG_SERVERLIESSIZE }, { "^1\\.3\\.2", SSH_BUG_IGNOREMSG }, /* f-secure */ { "^SSH Compatible Server", /* Netscreen */ SSH_BUG_PASSWORDPAD }, --- sshconnect1.c.O Thu Jul 5 10:49:13 2001 +++ sshconnect1.c Thu Jul 5 10:49:28 2001 @@ -37,6 +37,7 @@ #include "packet.h" #include "mpaux.h" #include "uidswap.h" +#include "compat.h" #include "log.h" #include "readconf.h" #include "key.h" @@ -960,7 +961,8 @@ sum_len += clen; rbits = BN_num_bits(host_key->n); - if (bits != rbits) { + if (bits != rbits && + !((datafellows & SSH_BUG_SERVERLIESSIZE) && (rbits + 1 == bits))) { log("Warning: Server lies about size of server host key: " "actual size is %d bits vs. announced %d.", rbits, bits); log("Warning: This may be due to an old implementation of ssh."); --- sshd.c.O Thu Jul 5 10:49:10 2001 +++ sshd.c Thu Jul 5 10:49:27 2001 @@ -1217,7 +1217,12 @@ packet_put_bignum(sensitive_data.server_key->rsa->n); /* Store our public host RSA key. */ - packet_put_int(BN_num_bits(sensitive_data.ssh1_host_key->rsa->n)); + len = BN_num_bits(sensitive_data.ssh1_host_key->rsa->n); + if ((datafellows & SSH_BUG_SERVERLIESSIZE) && (len & 1)) { + /* old ssh client expects even number for host key */ + len += 1; + } + packet_put_int(len); packet_put_bignum(sensitive_data.ssh1_host_key->rsa->e); packet_put_bignum(sensitive_data.ssh1_host_key->rsa->n); From syssys at math.umd.edu Fri Jul 6 09:07:48 2001 From: syssys at math.umd.edu (Tim Strobell) Date: Thu, 5 Jul 2001 19:07:48 -0400 Subject: askpass fails -> fatal()? Message-ID: <20010705190747.C10764@laplace.math.umd.edu> Could someone please explain why use of ssh-askpass is mandatory? Specifically, if the fork() to ssh-askpass fails, why does ssh not fall back to asking for the password itself? It appears that use of ssh-askpass was configurable at one point - would you be willing to accept a patch if I generated one? Thanks, Tim -- Tim Strobell, Assistant Systems Administrator syssys at math.umd.edu Department of Mathematics, University of Maryland Tel (301)405-8175 Mail: 1301 Math Bldg, College Park, MD 20742-4015 Fax (301)314-0827 From jon at rupture.net Fri Jul 6 02:07:10 2001 From: jon at rupture.net (Jon Nathan) Date: Thu, 5 Jul 2001 12:07:10 -0400 (EDT) Subject: password expiry/changing Message-ID: hi, does openssh have support for letting the user change his expired password? we are using password aging on solaris 6. our current build of openssh 2.5.2p2 asks for the password 3 times, then disconnects the user without allowing him to log in or change it. if not, are there any workarounds (other than root resetting the user's password manually). thanks, -jon -- Jon Nathan jon at rupture.net http://www.rupture.net/~jon/ From Nicolas.Williams at ubsw.com Fri Jul 6 08:50:48 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 5 Jul 2001 18:50:48 -0400 Subject: OpenSSH Logging Madness Message-ID: <20010705185047.P6936@sm2p1386swk.wdr.com> Feature request: - Please add a new LogLevel corresponding to the LOG_NOTICE syslog level. - Then modify OpenSSH to log to LOG_NOTICE only these events: - login failures - login successes Specifically, please: - add a new element to the LogLevel enum, say, 'SYSLOG_LEVEL_NOTICE', between 'SYSLOG_LEVEL_INFO' and 'SYSLOG_LEVEL_ERROR', in log.h - add a new logging function to log.c called notice(), much like log(), verbose() and friends, but logging to SYSLOG_LEVEL_NOTICE. - modify log.c:do_log() to map SYSLOG_LEVEL_NOTICE to LOG_NOTICE. - modify auth.c:/auth_log() to use notice() instead of log(). - make any other log()->notice() changes that seem appropriate. Below is a patch that implements just these changes. The patch is against OpenSSH 2.9p2 + simon at sxw.org.uk's GSS-API patches + my named key / key pattern patches (posted to openssh-unix-dev at mindrot.org). I do hope that LOG_NOTICE is available on all platforms -- where it isn't it could be mapped to LOG_INFO. Cheers, Nico ******************************************************************************** Index: 2_9_p2_w_gss_krb5_named_keys.6/log.h --- 2_9_p2_w_gss_krb5_named_keys.6/log.h Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/5_log.h 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.6(w)/log.h Thu, 05 Jul 2001 18:41:32 -0400 willian (OpenSSH/j/5_log.h 1.1 644) @@ -39,6 +39,7 @@ SYSLOG_LEVEL_QUIET, SYSLOG_LEVEL_FATAL, SYSLOG_LEVEL_ERROR, + SYSLOG_LEVEL_NOTICE, SYSLOG_LEVEL_INFO, SYSLOG_LEVEL_VERBOSE, SYSLOG_LEVEL_DEBUG1, @@ -58,6 +59,7 @@ /* Output a message to syslog or stderr */ void fatal(const char *fmt,...) __attribute__((format(printf, 1, 2))); void error(const char *fmt,...) __attribute__((format(printf, 1, 2))); +void notice(const char *fmt,...) __attribute__((format(printf, 1, 2))); void log(const char *fmt,...) __attribute__((format(printf, 1, 2))); void verbose(const char *fmt,...) __attribute__((format(printf, 1, 2))); void debug(const char *fmt,...) __attribute__((format(printf, 1, 2))); Index: 2_9_p2_w_gss_krb5_named_keys.6/log.c --- 2_9_p2_w_gss_krb5_named_keys.6/log.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/6_log.c 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.6(w)/log.c Thu, 05 Jul 2001 18:44:07 -0400 willian (OpenSSH/j/6_log.c 1.1 644) @@ -135,6 +135,17 @@ /* Log this message (information that usually should go to the log). */ void +notice(const char *fmt,...) +{ + va_list args; + va_start(args, fmt); + do_log(SYSLOG_LEVEL_NOTICE, fmt, args); + va_end(args); +} + +/* Log this message (information that usually should go to the log). */ + +void log(const char *fmt,...) { va_list args; @@ -347,6 +358,9 @@ if (!log_on_stderr) txt = "error"; pri = LOG_ERR; + break; + case SYSLOG_LEVEL_NOTICE: + pri = LOG_NOTICE; break; case SYSLOG_LEVEL_INFO: pri = LOG_INFO; ******************************************************************************** -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- . Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Fri Jul 6 08:55:41 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 5 Jul 2001 18:55:41 -0400 Subject: OpenSSH Logging Madness In-Reply-To: <20010705185047.P6936@sm2p1386swk.wdr.com>; from willian on Thu, Jul 05, 2001 at 06:50:48PM -0400 References: <20010705185047.P6936@sm2p1386swk.wdr.com> Message-ID: <20010705185539.Q6936@sm2p1386swk.wdr.com> Ugh, missed something in my patch. Here it is again: Index: 2_9_p2_w_gss_krb5_named_keys.6/log.h --- 2_9_p2_w_gss_krb5_named_keys.6/log.h Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/5_log.h 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.6(w)/log.h Thu, 05 Jul 2001 18:41:32 -0400 willian (OpenSSH/j/5_log.h 1.1 644) @@ -39,6 +39,7 @@ SYSLOG_LEVEL_QUIET, SYSLOG_LEVEL_FATAL, SYSLOG_LEVEL_ERROR, + SYSLOG_LEVEL_NOTICE, SYSLOG_LEVEL_INFO, SYSLOG_LEVEL_VERBOSE, SYSLOG_LEVEL_DEBUG1, @@ -58,6 +59,7 @@ /* Output a message to syslog or stderr */ void fatal(const char *fmt,...) __attribute__((format(printf, 1, 2))); void error(const char *fmt,...) __attribute__((format(printf, 1, 2))); +void notice(const char *fmt,...) __attribute__((format(printf, 1, 2))); void log(const char *fmt,...) __attribute__((format(printf, 1, 2))); void verbose(const char *fmt,...) __attribute__((format(printf, 1, 2))); void debug(const char *fmt,...) __attribute__((format(printf, 1, 2))); Index: 2_9_p2_w_gss_krb5_named_keys.6/log.c --- 2_9_p2_w_gss_krb5_named_keys.6/log.c Thu, 03 May 2001 16:12:13 -0400 jd (OpenSSH/j/6_log.c 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.6(w)/log.c Thu, 05 Jul 2001 18:52:36 -0400 willian (OpenSSH/j/6_log.c 1.1 644) @@ -79,6 +79,7 @@ { "QUIET", SYSLOG_LEVEL_QUIET }, { "FATAL", SYSLOG_LEVEL_FATAL }, { "ERROR", SYSLOG_LEVEL_ERROR }, + { "NOTICE", SYSLOG_LEVEL_NOTICE }, { "INFO", SYSLOG_LEVEL_INFO }, { "VERBOSE", SYSLOG_LEVEL_VERBOSE }, { "DEBUG", SYSLOG_LEVEL_DEBUG1 }, @@ -135,6 +136,17 @@ /* Log this message (information that usually should go to the log). */ void +notice(const char *fmt,...) +{ + va_list args; + va_start(args, fmt); + do_log(SYSLOG_LEVEL_NOTICE, fmt, args); + va_end(args); +} + +/* Log this message (information that usually should go to the log). */ + +void log(const char *fmt,...) { va_list args; @@ -260,6 +272,7 @@ case SYSLOG_LEVEL_QUIET: case SYSLOG_LEVEL_FATAL: case SYSLOG_LEVEL_ERROR: + case SYSLOG_LEVEL_NOTICE: case SYSLOG_LEVEL_INFO: case SYSLOG_LEVEL_VERBOSE: case SYSLOG_LEVEL_DEBUG1: @@ -347,6 +360,9 @@ if (!log_on_stderr) txt = "error"; pri = LOG_ERR; + break; + case SYSLOG_LEVEL_NOTICE: + pri = LOG_NOTICE; break; case SYSLOG_LEVEL_INFO: pri = LOG_INFO; On Thu, Jul 05, 2001 at 06:50:48PM -0400, Nicolas Williams wrote: > > Feature request: > > - Please add a new LogLevel corresponding to the LOG_NOTICE syslog level. > > - Then modify OpenSSH to log to LOG_NOTICE only these events: > > - login failures > - login successes > > Specifically, please: > > - add a new element to the LogLevel enum, say, 'SYSLOG_LEVEL_NOTICE', > between 'SYSLOG_LEVEL_INFO' and 'SYSLOG_LEVEL_ERROR', in log.h > > - add a new logging function to log.c called notice(), much like log(), > verbose() and friends, but logging to SYSLOG_LEVEL_NOTICE. > > - modify log.c:do_log() to map SYSLOG_LEVEL_NOTICE to LOG_NOTICE. > > - modify auth.c:/auth_log() to use notice() instead of log(). > > - make any other log()->notice() changes that seem appropriate. > > Below is a patch that implements just these changes. The patch is > against OpenSSH 2.9p2 + simon at sxw.org.uk's GSS-API patches + my named > key / key pattern patches (posted to openssh-unix-dev at mindrot.org). > > I do hope that LOG_NOTICE is available on all platforms -- where it > isn't it could be mapped to LOG_INFO. > > 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 Fri Jul 6 16:34:56 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 6 Jul 2001 09:34:56 +0300 (EEST) Subject: Xauthority location: only per-user setting possible Message-ID: Hello all, $XAUTHORITY location has moved from under /tmp to ~/.Xauthority in 2.9p2. The commit message was: --- remove xauth-cookie-in-tmp handling. use default $XAUTHORITY, since we do already trust $HOME/.ssh you can use .ssh/sshrc and .ssh/environment if you want to customize the location of the xauth cookies --- The latter is true, but can only be enabled in per-user basis as far as I see. To make it work for one user, you need to do like: .ssh/environment: XAUTHORITY=/tmp/some/where .ssh/rc or /etc/ssh/rc: if read proto cookie; then echo add $DISPLAY $proto $cookie | /usr/X11R6/bin/xauth -q - fi However, .ssh/environment handling does not parse environment variables (good thing; they might not even be known at this point) or provide much flexibility. To provide xauthority in /tmp for _everyone_, everyone has to pick one $XAUTHORITY location and put it in .ssh/environment. This does not seem too scalable. One other application of this is an SSH gateway where users _don't_ even have a writable home directory. There are probably more. I can't figure out how this could be done in a flexible manner today. Any thoughts would be greatly appreciated. -- 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 pavgrig at mail.ru Sat Jul 7 01:50:54 2001 From: pavgrig at mail.ru (pavgrig at mail.ru) Date: Fri, 6 Jul 2001 17:50:54 +0200 Subject: Ñåìèíàðû Message-ID: <200107061943.f66Jh0Z20442@Mail-In.Net> -------------- next part -------------- A non-text attachment was scrubbed... Name: Rass10.doc Type: application/octet-stream Size: 37888 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010706/a06f6ba4/attachment.obj From johnh at aproposretail.com Sat Jul 7 07:34:34 2001 From: johnh at aproposretail.com (John Hardin) Date: Fri, 06 Jul 2001 14:34:34 -0700 Subject: [Fwd: SECURITY WARNING - possible email attack] Message-ID: <3B462EEA.21773636@aproposretail.com> WARNING TO ALL - I just got what appears to be an infected Word document attachment via the list. The apparently forged headers look suspicious, too. Procmail Security daemon wrote: > > REPORT: Trapped poisoned Microsoft attachment > REPORT: Macro Scanner score: 129 > STATUS: Message quarantined in /var/spool/mail/security, not delivered to recipient. > > Headers from message: > > > From owner-openssh-unix-dev at mindrot.org Fri Jul 6 14:13:46 2001 > > Return-Path: > > Received: from shitei.mindrot.org (IDENT:j3mtrjbl8n05a3tc2t11 at intern12.lnk.telstra.net [139.130.53.38]) > > by boundary.aproposretail.com (8.9.3/8.8.7) with ESMTP id OAA14550 > > for ; Fri, 6 Jul 2001 14:09:33 -0700 > > Received: by shitei.mindrot.org (Postfix) > > id 251892DF34; Sat, 7 Jul 2001 07:08:11 +1000 (EST) > > Delivered-To: openssh-unix-dev-list-93873 at shitei.mindrot.org > > Received: by shitei.mindrot.org (Postfix, from userid 1000) > > id BEA1B2DF13; Sat, 7 Jul 2001 07:08:10 +1000 (EST) > > Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) > > by shitei.mindrot.org (Postfix) with ESMTP > > id 9AD6A2DF0F; Sat, 7 Jul 2001 07:07:14 +1000 (EST) > > Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) > > by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f66L7bC26071; > > Sat, 7 Jul 2001 00:07:37 +0300 (EEST) > > (envelope-from pavgrig at mail.ru) > > Received: from QRJATYDI ([212.35.189.164]) > > by Mail-In.Net (8.11.3/8.H.Z) with SMTP id f66Jh0Z20442; > > Fri, 6 Jul 2001 22:43:04 +0300 (EEST) > > Message-Id: <200107061943.f66Jh0Z20442 at Mail-In.Net> > > From: > > To: User at Mail-In.Net > > Subject: ???????? > > X-Priority: 3 > > X-MSMail-Priority: Normal > > X-Mailer: Mega-Mailer > > Date: Fri, 6 Jul 2001 17:50:54 +0200 > > Mime-Version: 1.0 > > X-Security: MIME headers sanitized on boundary.aproposretail.com > > See http://www.impsec.org/email-tools/procmail-security.html > > for details. $Revision: 1.129 $Date: 2001-04-14 20:20:43-07 > > Content-Type: multipart/mixed; > > boundary="=_NextPart_30434667226640806467" > > Sender: owner-openssh-unix-dev at mindrot.org > > Precedence: bulk > > -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 ----------------------------------------------------------------------- 12 days until Forum 2001 From jgrove at wvu.edu Sat Jul 7 13:28:04 2001 From: jgrove at wvu.edu (Jason Grove) Date: Fri, 06 Jul 2001 23:28:04 -0400 Subject: AIX 4.3.3 and password expiration/change bug? Message-ID: <3B4681C4.3C0ED39B@wvu.edu> Hello All, I have looked through the archives on MARC, and saw some people submit patches but did not see if they were actually applied to the source. I am having a problem with Password expiration and ADMCHG flags being set on the user. I.e. if root changes the password of the user the /etc/security/passwd gets updated and the user gets: flags = ADMCHG If this flag is set I can log in to the box (with ssh) and it never prompts me to change the password. However, if I log in with telnet it prompts me immediatly to change it. I have looked through the source but it has been a while since I done programming and I could not find anything relavent to this. Can any one tell me where I might look to find this or if this is actually already done. I am using OpenSSH 2.9p2 on AIX 4.3.3 ML8. Thanks Jason -- Jason Grove | Quantum materiae materietur Systems Administrator | marmota monax si marmota West Virginia University | monax materiam possit Information Systems & Networks | materiari? jgrove at wvu.edu | From djm at mindrot.org Sat Jul 7 18:49:54 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 7 Jul 2001 18:49:54 +1000 (EST) Subject: OpenSSH 2 - can't get pubkeys to authenticate In-Reply-To: Message-ID: On Wed, 4 Jul 2001, _t0pper _ wrote: > The System: > RedHat 7.0 > OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > > Client: > PuTTY > > The Problem: > > I've installed the newest version of OpenSSH on RedHat 7.0 and can get > most things to work, except when I want to use Public Keys with > version 2.0. > > If I use straight password authentication, I can get PuTTY to connect > using either SSH 1 or SSH 2. > > If I RSA authentication for SSH1, it also works, no matter if I create > the key on the client and transport the public key to the server or if > I create the keys on the server and get the private key to the client. > Both ways are successful. (Yes, I use authorized_keys in the > $HOME/.ssh directory). > > The problem I'm running into is getting public key authentication to > work with SSH2. I create the keys on the server, put the public key > into the authorized_keys2 file and transport the private key to the > client. Are you using the CVS Putty or the latest release? The latest release doesn't do SSH protocol 2 pubkey auth, the CVS will do pubkey auth, but you need to use RSA keys (DSA is not supported by PuTTY). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sat Jul 7 18:52:01 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 7 Jul 2001 18:52:01 +1000 (EST) Subject: password expiry/changing In-Reply-To: Message-ID: On Thu, 5 Jul 2001, Jon Nathan wrote: > hi, > > does openssh have support for letting the user change his expired > password? we are using password aging on solaris 6. our current > build of openssh 2.5.2p2 asks for the password 3 times, then > disconnects the user without allowing him to log in or change it. if > not, are there any workarounds (other than root resetting the user's > password manually). There is code to change the password through PAM. You need to configure with --with-pam -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From herrold at owlriver.com Sun Jul 8 05:05:58 2001 From: herrold at owlriver.com (R P Herrold) Date: Sat, 7 Jul 2001 15:05:58 -0400 (EDT) Subject: client side options -- KeyRegenerationInterval In-Reply-To: <3B462EEA.21773636@aproposretail.com> Message-ID: I was tinkering with ssh_config (the client side) configuration file ... and added: KeyRegenerationInterval 540 >From a review of the man page, I had not seen the option, but thought it might be present but undocumented. Nope. The thought would be that a given user may be more paranoid, and call for a more frequent (or a non-thoughtful user a longer) interval, in their local .config -- or as another reason for this approach, set it shorter to act as another form of a 'keep-alive' with the timeout duration under user control -=- (This latter is my actual goal -- the re-exchange of keys will constitute traffic, and would [should?] keep a given NATting session alive through gateway firewall's [not under my control] too short timeouts.) It looks as though a patch to readconf.c, an alarm loop test as in sshd.c, and an option eater in sshconnect.c, along with a man page addition would be neded, but are reasonably straightforward. But it does increase the 'complexity' of the client. ... Thoughts? -- Russ Herrold From Gary.Sakimoto at PACCAR.com Sun Jul 8 11:47:30 2001 From: Gary.Sakimoto at PACCAR.com (Gary Sakimoto) Date: Sat, 7 Jul 2001 18:47:30 -0700 Subject: No subject Message-ID: <43BB266C4D14D311A1670090275D1DDA1C2088@misrenmxc3.misrenton.paccar.com> > Good Morning, > When trying to run configure for openssh (2.5.1p1 or 2.5.1p2 or > 2.5.2p1 or 2.9p2), it fails and tells me that I need to install ZLIB. > Zlib has been configured, made, made tested and made installed into > /opt/zlib (default) and IS already installed. I am running hpux 11.00, > have zlib 1.1.3 , openssl 0.9.6 , perl 5.005_03 and am running HP ansi C > for 11.00. Is OpenSSH configure looking for the ZLib to be in a directory > other than /opt ??? Any suggestions will be GREATLY appreciated !!!!! > Thank you for your time.......... From gem at rellim.com Sun Jul 8 12:42:31 2001 From: gem at rellim.com (Gary E. Miller) Date: Sat, 7 Jul 2001 19:42:31 -0700 (PDT) Subject: your mail In-Reply-To: <43BB266C4D14D311A1670090275D1DDA1C2088@misrenmxc3.misrenton.paccar.com> Message-ID: Yo Gary! Hmm, I just checked the source for zlib 1.1.3 and the default is /usr/local. So you must be using an rpm or some other munged version of zlib. You need to tell ./configure where to find it. Not sure what you have under /opt/zlib, but try something like this: ./configure --with-cppflags="-I/opt/zlib/include" \ --with-libs="-L/opt/zlib/lib" RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 On Sat, 7 Jul 2001, Gary Sakimoto wrote: > > When trying to run configure for openssh (2.5.1p1 or 2.5.1p2 or > > 2.5.2p1 or 2.9p2), it fails and tells me that I need to install ZLIB. > > Zlib has been configured, made, made tested and made installed into > > /opt/zlib (default) and IS already installed. I am running hpux 11.00, > > have zlib 1.1.3 , openssl 0.9.6 , perl 5.005_03 and am running HP ansi C > > for 11.00. Is OpenSSH configure looking for the ZLib to be in a directory > > other than /opt ??? Any suggestions will be GREATLY appreciated !!!!! From djm at mindrot.org Sun Jul 8 15:10:32 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 8 Jul 2001 15:10:32 +1000 (EST) Subject: your mail In-Reply-To: <43BB266C4D14D311A1670090275D1DDA1C2088@misrenmxc3.misrenton.paccar.com> Message-ID: On Sat, 7 Jul 2001, Gary Sakimoto wrote: > > > > > Good Morning, > > When trying to run configure for openssh (2.5.1p1 or 2.5.1p2 > > or 2.5.2p1 or 2.9p2), it fails and tells me that I need to install > > ZLIB. Zlib has been configured, made, made tested and made > > installed into /opt/zlib (default) and IS already installed. I > > am running hpux 11.00, have zlib 1.1.3 , openssl 0.9.6 , perl > > 5.005_03 and am running HP ansi C for 11.00. Is OpenSSH configure > > looking for the ZLib to be in a directory other than /opt ??? You might need something like: CPPFLAGS="-I/path/to/zlib/includes" LDFLAGS="-L/path/to/zlib/lib" \ ./configure [options] Otherwise have a look in config.log to see what went wrong. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From nospam at mega-nerd.com Sun Jul 8 15:52:09 2001 From: nospam at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 08 Jul 2001 15:52:09 +1000 Subject: Changes 2.5.2p2 -> 2.9p2 Message-ID: <3B47F509.A23C2F93@mega-nerd.com> Hi, Appologies for a possibly inexact bug report but I've noticed a change in behaviour from openssh version 2.5.2p2 to 2.9p2. One of my many uses for openssh is setting up a secure tunnel from my home machine to an external mail server and using fetchmail over said tunnel. When done in this manner fetchmail actually starts up openssh. When I moved from 2.5.2p2 -> 2.9p2 (both compiled form source) the previously working process started failing. No config files were changed at the time. Fetchmail had this to say: fetchmail: 5.3.3 querying imap.xxxxxx.xxx (protocol IMAP) at Sat, 07 Jul 2001 15:33:01 +1000 (EST) ssh_askpass: exec(/usr/local/libexec/ssh-askpass): No such file or directory fetchmail: pre-connection command failed with status 13 fetchmail: Query status=5 (SYNTAX) fetchmail: terminated with signal 15 Reverting back to 2.5.2p2 and fetchmail worked again. I understand that this is one of the many common uses of openssh and wouldn't like to see it permanently broken. Cheers, Erik PS: I'm not subscribed to this list so email me directly for more info. -- ----------------------------------------------------------------- Erik de Castro Lopo nospam at mega-nerd.com (Yes its valid) ----------------------------------------------------------------- J. Headley: "God, root, what is difference ?" G. Haverland: "God can change the byte order on the CPU, root can't." From djm at mindrot.org Mon Jul 9 00:17:06 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Jul 2001 00:17:06 +1000 (EST) Subject: Changes 2.5.2p2 -> 2.9p2 In-Reply-To: <3B47F509.A23C2F93@mega-nerd.com> Message-ID: On Sun, 8 Jul 2001, Erik de Castro Lopo wrote: > Hi, > > Appologies for a possibly inexact bug report but I've noticed a change > in behaviour from openssh version 2.5.2p2 to 2.9p2. > > One of my many uses for openssh is setting up a secure tunnel from > my home machine to an external mail server and using fetchmail over > said tunnel. When done in this manner fetchmail actually starts up > openssh. > > When I moved from 2.5.2p2 -> 2.9p2 (both compiled form source) the > previously working process started failing. No config files were > changed at the time. > > Fetchmail had this to say: > > fetchmail: 5.3.3 querying imap.xxxxxx.xxx (protocol IMAP) at Sat, 07 Jul 2001 15:33:01 +1000 (EST) > ssh_askpass: exec(/usr/local/libexec/ssh-askpass): No such file or directory It looks like ssh is needing a passphrase to a public key here. You should either add your public key to the agent or use a key with not passphrase and a forced command on the imap server. This following is what I use for exactly this scenario. .fetchmailrc --- poll mail.xxxx.xxx protocol IMAP plugin "ssh -i /home/djm/.ssh/id_rsa_fetchmail %h /usr/local/libexec/imapd" password whatever mail.xxxx.xxx:~/.ssh/authorized_keys2 --- command="/usr/local/libexec/imapd",no-port-forwarding,no-x11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3Nza..[my pubkey]..cjjk= djm at mindrot.org fetchmail key ----------------------------- -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From nospam at mega-nerd.com Mon Jul 9 07:35:15 2001 From: nospam at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 09 Jul 2001 07:35:15 +1000 Subject: Changes 2.5.2p2 -> 2.9p2 References: Message-ID: <3B48D213.15C13C1C@mega-nerd.com> Damien Miller wrote: > > On Sun, 8 Jul 2001, Erik de Castro Lopo wrote: > > > Hi, > > > > Appologies for a possibly inexact bug report but I've noticed a change > > in behaviour from openssh version 2.5.2p2 to 2.9p2. > > > > One of my many uses for openssh is setting up a secure tunnel from > > my home machine to an external mail server and using fetchmail over > > said tunnel. When done in this manner fetchmail actually starts up > > openssh. > > > > When I moved from 2.5.2p2 -> 2.9p2 (both compiled form source) the > > previously working process started failing. No config files were > > changed at the time. > > > > Fetchmail had this to say: > > > > fetchmail: 5.3.3 querying imap.xxxxxx.xxx (protocol IMAP) at Sat, 07 Jul 2001 15:33:01 +1000 (EST) > > ssh_askpass: exec(/usr/local/libexec/ssh-askpass): No such file or directory > > It looks like ssh is needing a passphrase to a public key here. You > should either add your public key to the agent or use a key with not > passphrase and a forced command on the imap server. Simplified question: Was the behaviour supposed to change between 2.5.2p2 and 2.9p2? Erik -- ----------------------------------------------------------------- Erik de Castro Lopo nospam at mega-nerd.com (Yes its valid) ----------------------------------------------------------------- UNIX *is* user-friendly, just picky about who it chooses for friends! From Lutz.Jaenicke at aet.TU-Cottbus.DE Mon Jul 9 19:29:10 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Mon, 9 Jul 2001 11:29:10 +0200 Subject: Changes 2.5.2p2 -> 2.9p2 In-Reply-To: <3B48D213.15C13C1C@mega-nerd.com>; from nospam@mega-nerd.com on Mon, Jul 09, 2001 at 07:35:15AM +1000 References: <3B48D213.15C13C1C@mega-nerd.com> Message-ID: <20010709112910.B4314@serv01.aet.tu-cottbus.de> On Mon, Jul 09, 2001 at 07:35:15AM +1000, Erik de Castro Lopo wrote: > Damien Miller wrote: > > On Sun, 8 Jul 2001, Erik de Castro Lopo wrote: > > > When I moved from 2.5.2p2 -> 2.9p2 (both compiled form source) the > > > previously working process started failing. No config files were > > > changed at the time. > > > > > > fetchmail: 5.3.3 querying imap.xxxxxx.xxx (protocol IMAP) at Sat, 07 Jul 2001 15:33:01 +1000 (EST) > > > ssh_askpass: exec(/usr/local/libexec/ssh-askpass): No such file or directory > > > > It looks like ssh is needing a passphrase to a public key here. You > > should either add your public key to the agent or use a key with not > > passphrase and a forced command on the imap server. > > Simplified question: Was the behaviour supposed to change between 2.5.2p2 and > 2.9p2? The default protocol changed from protocol 1 to protocol 2. As the public keys are different for both protocols you may need to adjust your key handling. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From Tor.Lillqvist at tellabs.com Mon Jul 9 20:18:28 2001 From: Tor.Lillqvist at tellabs.com (Tor Lillqvist) Date: Mon, 09 Jul 2001 13:18:28 +0300 Subject: sshd problem on Solaris 7: Control-C hangs shell Message-ID: <3B4984F4.ABF962DA@tellabs.com> I have a strange problem with sshd (from openssh-2.9p2) on Solaris 7. My shell is bash. When I open an ssh session , and type a Control-C to bash's prompt, the shell hangs. (But, if I for instance run "sleep 10" (during which time the pty is in cooked mode) and press Control-C, the sleep command is interrupted quite normally, and the bash prompt returns.) Adding some debugging printfs tell me that the read(fdout,...) in serverloop.c:process_input() returns zero when I type the Control-C?! Some Solaris quirk in pty behaviour related to interrupts in raw mode? Following this read returning 0, sshd thinks it got an EOF, closes its side of the pty, but the shell still thinks everything is OK, but of course can't get any input. So, my next try is to comment out the fdout_eof assignment. But then again, exiting from the ssh session causes the sshd to loop (printing tvp!=NULL kid 1 milli 100), and if I then press Control-C to the ssh client (where I already have exited the shell in the ssh session), sshd loops tighter, getting 0 all the time from the read(fdout). Hmm, more hacking... A horrible hack that seems to "fix" my problem is: --- /tmp/openssh-2.9p2/serverloop.c Sat Apr 14 02:28:03 2001 +++ serverloop.c Mon Jul 9 13:02:27 2001 @@ -74,4 +74,5 @@ static int stdin_eof = 0; /* EOF message received from client. */ static int fdout_eof = 0; /* EOF encountered reading from fdout. */ +static int fdout_maybe_eof = 0; static int fderr_eof = 0; /* EOF encountered readung from fderr. */ static int fdin_is_tty = 0; /* fdin points to a tty. */ @@ -107,6 +108,9 @@ wait_pid, child_pid); if (WIFEXITED(child_wait_status) || - WIFSIGNALED(child_wait_status)) + WIFSIGNALED(child_wait_status)) { child_terminated = 1; + if (fdout_maybe_eof) + fdout_eof = 1; + } } signal(SIGCHLD, sigchld_handler); @@ -338,10 +342,14 @@ /* Read and buffer any available stdout data from the program. */ - if (!fdout_eof && FD_ISSET(fdout, readset)) { + if (!fdout_eof && (child_terminated || FD_ISSET(fdout, readset))) { len = read(fdout, buf, sizeof(buf)); if (len < 0 && (errno == EINTR || errno == EAGAIN)) { /* do nothing */ } else if (len <= 0) { - fdout_eof = 1; + verbose ("read from fdout returns zero?"); + if (child_terminated) + fdout_eof = 1; + else + fdout_maybe_eof = 1; } else { buffer_append(&stdout_buffer, buf, len); But no doubt it would be much better if somebody who understands how ptys work in Solaris 7 could figure out the *right* way to fix this. I don't recommend adding that hack to the code. With the old Yl?nen ssh 1.2.26, the behaviour is a bit different: A Control-C to bash's prompt kills the shell completely, with SIGHUP eventually. BTW, with Solaris 2.5.1, I didn't notice any of these problems. --tml From carson at taltos.org Mon Jul 9 20:54:50 2001 From: carson at taltos.org (Carson Gaspar) Date: Mon, 09 Jul 2001 03:54:50 -0700 Subject: sshd problem on Solaris 7: Control-C hangs shell In-Reply-To: <3B4984F4.ABF962DA@tellabs.com> References: <3B4984F4.ABF962DA@tellabs.com> Message-ID: <1342967578.994650889@athyra> --On Monday, July 09, 2001 1:18 PM +0300 Tor Lillqvist wrote: > Adding some debugging printfs tell me that the read(fdout,...) in > serverloop.c:process_input() returns zero when I type the Control-C?! > Some Solaris quirk in pty behaviour related to interrupts in raw mode? > Following this read returning 0, sshd thinks it got an EOF, closes its > side of the pty, but the shell still thinks everything is OK, but of > course can't get any input. >From the solaris read() man page: When attempting to read a file associated with a terminal that has no data currently available: o If O_NDELAY is set, read() returns 0. o If O_NONBLOCK is set, read() returns -1 and sets errno to EAGAIN. o If O_NDELAY and O_NONBLOCK are clear, read() blocks until data become available. My guess is that: - O_NDELAY is set - ^C is causing select to wake up somehow I'll have to look at the code to see what's going on, and it's too late here for me to try and understand the OpenSSH I/O loop. I suspect that setting O_NONBLOCK instead of O_NDELAY (or in addition to??) may be a work-around. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From jso at europay.com Mon Jul 9 21:33:43 2001 From: jso at europay.com (=?iso-8859-1?Q?Jo=EBl_Soete?=) Date: Mon, 9 Jul 2001 13:33:43 +0200 Subject: scp problem (openssh-2.9p2) Message-ID: Hello all, scp does not preserve links (neither soft neither hard) It is a problem with recursive option (-r) when you met some links like Openssh -> . In 2.3.0p1 it failled because of too long argument. Also I upgrade (my client an HPUX-11.0 and my server an redhat-6,2 x86) openssh to the last release 2.9p2. But this release create in a loop (i presume until fs full) subdirectories Openssh/Openssh/Openssh... with its content. I consult marc.theaimsgroup.com archive mailing list but do not found any recent report about this problem. Thanks in advance for help, Joel ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From dankamin at cisco.com Tue Jul 10 00:02:13 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Mon, 9 Jul 2001 07:02:13 -0700 Subject: scp problem (openssh-2.9p2) References: Message-ID: <002001c1087f$c68ad2a0$3000010a@na.cisco.com> > scp does not preserve links (neither soft neither hard) Joel-- Play around with the following command: tar -cf - | ssh user at host 'tar -C destination_path -xvf -' I've begun to completely abandon SCP proper. --Dan From jso at europay.com Tue Jul 10 00:45:24 2001 From: jso at europay.com (=?iso-8859-1?Q?Jo=EBl_Soete?=) Date: Mon, 9 Jul 2001 16:45:24 +0200 Subject: scp problem (openssh-2.9p2) Message-ID: Dan, Thanks (I just forgot). Nice. Joel Dan Kaminsky Soete/BRU/MASTERCARD at MASTERCARD cc: 09-07-01 Subject: Re: scp problem (openssh-2.9p2) 04:02 PM > scp does not preserve links (neither soft neither hard) Joel-- Play around with the following command: tar -cf - | ssh user at host 'tar -C destination_path -xvf -' I've begun to completely abandon SCP proper. --Dan ********************************************************************** This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. Thank you for your co-operation. ********************************************************************** From wgriffin at tislabs.com Tue Jul 10 01:32:46 2001 From: wgriffin at tislabs.com (Wesley Griffin) Date: Mon, 9 Jul 2001 11:32:46 -0400 Subject: [patch] SSH host keys in DNS Message-ID: <20010709113243.D985@tislabs.com> I've made some changes to the 2.9p2 release code to add support for using DNSSEC lookups to check host keys. I've also made the changes to the OPENBSD_2_9 tree. Both patches are available at ftp://ftp.tislabs.com/pub/fmeshd/ as openssh.[portable,openbsd].patch.20010709 I'm really looking for testers at this time. Right now the lookups are done using a getrrsetbyname() function that is part of the BIND9 lwres API. I'm in the process of writing a similar standalone function for the OpenBSD tree. There is a README.DNSSEC file in the directory that has more details. -- Wesley Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From jmknoble at pobox.com Tue Jul 10 01:47:27 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 9 Jul 2001 10:47:27 -0500 Subject: scp problem (openssh-2.9p2) In-Reply-To: <002001c1087f$c68ad2a0$3000010a@na.cisco.com>; from dankamin@cisco.com on Mon, Jul 09, 2001 at 07:02:13AM -0700 References: <002001c1087f$c68ad2a0$3000010a@na.cisco.com> Message-ID: <20010709104727.B14354@zax.half.pint-stowp.cx> Circa 2001-Jul-09 07:02:13 -0700 dixit Dan Kaminsky: : > scp does not preserve links (neither soft neither hard) : : Play around with the following command: : : tar -cf - | ssh user at host 'tar -C : destination_path -xvf -' Or use rsync: http://freshmeat.net/projects/rsync/ 'rsync -a' copies recursively and preserves symlinks, times, and permissions, and ownership too if you're privileged. -- jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ | 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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010709/990e01ee/attachment.bin From dhaag at pico.apple.com Tue Jul 10 02:41:10 2001 From: dhaag at pico.apple.com (Dennis Haag) Date: Mon, 09 Jul 2001 09:41:10 -0700 Subject: OpenSSH cipher problems between 2.9p1 and 2.9p2 References: <002001c1087f$c68ad2a0$3000010a@na.cisco.com> <20010709104727.B14354@zax.half.pint-stowp.cx> Message-ID: <3B49DEA6.662B3E53@pico.apple.com> I recently upgraded OpenSSH on our Suns (Solaris 2.6 and Solaris 7) to 2.9p2 and ran into a problem with the OpenSSH 2.9p1 that is part of Mac OS X (10.0.4). b071 f5b5 d870 6558 c7dc c966 d089 7d65 Disconnecting: Bad packet length -1334708811. It appears that the default of having the aes128-cbc cipher first is the source of the problem. If I force another cipher with the -c command line option or put aes128-cbc later in the Ciphers list it works. I don't know what the OpenSSL (0.9.5a) or OpenSSH (2.9p1) configure/compile options were used by Apple when building this. I have both the client and server side debug information which I will attach. Has anyone else seen this problem between 2.9p1 and 2.9p2 on any other platform? I don't see the problem between 2.9p1 and 2.9p2 on Solaris. Thanks in advance. -- Dennis Haag Engineering Computer Services haag at apple.com unix-support at apple.com 408-974-6630 ECS Hotline: 408-974-4747 -------------- next part -------------- # This is ssh client systemwide configuration file. This file provides # defaults for users, and the values can be changed in per-user configuration # files or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for various options # All options have been included alphabetically in the file, even though # most are set to the default. This protects against changes in defaults # in future versions and provides a complete list or configurable options. Host * BatchMode no CheckHostIP yes ChallengeResponseAuthentication no # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc Compression no CompressionLevel 6 ConnectionAttempts 4 EscapeChar ~ FallBackToRsh no ForwardAgent no ForwardX11 yes GatewayPorts no GlobalKnownHostsFile /etc/ssh/ssh_known_hosts GlobalKnownHostsFile2 /etc/ssh/ssh_known_hosts2 HostbasedAuthentication yes HostKeyAlgorithms ssh-rsa,ssh-dss # HostKeyAlias no global default # HostName no global default IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_dsa IdentityFile ~/.ssh/id_rsa KeepAlive yes # LocalForward no global defaults LogLevel INFO Macs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 NumberOfPasswordPrompts 3 PasswordAuthentication yes PreferredAuthentications publickey,password,keyboard-interactive Port 22 Protocol 2,1 # ProxyCommand no global default PubkeyAuthentication yes # RemoteForward no global default RhostsAuthentication no RhostsRSAAuthentication yes RSAAuthentication yes StrictHostKeyChecking ask UsePrivilegedPort no # User no global default UserKnownHostsFile ~/.ssh/known_hosts UserKnownHostsFile2 ~/.ssh/known_hosts2 UseRsh no XAuthLocation /usr/openwin/bin/xauth -------------- next part -------------- # This is ssh server systemwide configuration file. # # All options have been included alphabetically in the file, even though # most are set to the default. This protects against changes in defaults # in future versions and provides a complete list or configurable options. #AllowGroups * AllowTcpForwarding yes #AllowUsers * #Banner /etc/ssh/issue ChallengeResponseAuthentication no #Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour CheckMail no ClientAliveInterval 0 ClientAliveCountMax 3 #DenyGroups nogroup #DenyUsers nobody GatewayPorts no HostbasedAuthentication no HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key IgnoreRhosts yes IgnoreUserKnownHosts no KeepAlive yes KeyRegenerationInterval 3600 #Port parameter must preceed ListenAddress Port 22 ListenAddress 0.0.0.0 LoginGraceTime 600 LogLevel INFO Macs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 MaxStartups 10:30:60 PAMAuthenticationViaKbdInt no PasswordAuthentication yes PermitEmptyPasswords no PermitRootLogin yes PidFile /etc/ssh/ssh.pid PrintLastLog yes PrintMotd no Protocol 2,1 PubkeyAuthentication yes ReverseMappingCheck no RhostsAuthentication no RhostsRSAAuthentication yes RSAAuthentication yes ServerKeyBits 768 StrictModes yes Subsystem sftp /local/solaris_2.6/openssh2.9p2/libexec/sftp-server SyslogFacility AUTH UseLogin no X11DisplayOffset 10 X11Forwarding yes XAuthLocation /usr/openwin/bin/xauth -------------- next part -------------- OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: key names ok: [ssh-rsa,ssh-dss] debug2: mac_init: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 at openssh.com debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 25 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log' debug3: Reading output from 'ls -alni /var/mail' debug3: Time elapsed: 20 msec debug3: Got 0.34 bytes of entropy from 'ls -alni /var/mail' debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 28 msec debug3: Got 0.13 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /var/tmp' debug3: Time elapsed: 21 msec debug3: Got 0.82 bytes of entropy from 'ls -alni /var/tmp' debug3: Reading output from 'ls -alTi /var/log' debug3: Time elapsed: 41 msec debug3: Got 2.00 bytes of entropy from 'ls -alTi /var/log' debug3: Reading output from 'ls -alTi /var/mail' debug3: Time elapsed: 38 msec debug3: Got 0.42 bytes of entropy from 'ls -alTi /var/mail' debug3: Reading output from 'ls -alTi /tmp' debug3: Time elapsed: 36 msec debug3: Got 0.15 bytes of entropy from 'ls -alTi /tmp' debug3: Reading output from 'ls -alTi /var/tmp' debug3: Time elapsed: 46 msec debug3: Got 1.00 bytes of entropy from 'ls -alTi /var/tmp' debug3: Reading output from 'netstat -an' debug3: Time elapsed: 31 msec debug3: Got 2.00 bytes of entropy from 'netstat -an' debug3: Reading output from 'netstat -s' debug3: Time elapsed: 24 msec debug3: Got 2.00 bytes of entropy from 'netstat -s' debug3: Reading output from 'arp -a -n' debug3: Time elapsed: 81 msec debug3: Got 0.67 bytes of entropy from 'arp -a -n' debug3: Reading output from 'ifconfig -a' debug3: Time elapsed: 21 msec debug3: Got 0.89 bytes of entropy from 'ifconfig -a' debug3: Reading output from 'ps laxww' debug3: Time elapsed: 64 msec debug3: Got 2.00 bytes of entropy from 'ps laxww' debug3: Reading output from 'ps -al' debug3: Time elapsed: 51 msec debug3: Got 1.20 bytes of entropy from 'ps -al' debug3: Reading output from 'w' debug3: Time elapsed: 22 msec debug3: Got 0.99 bytes of entropy from 'w' debug3: Reading output from 'last' debug3: Time elapsed: 57 msec debug3: Got 2.00 bytes of entropy from 'last' debug3: Reading output from 'df -l' debug3: Time elapsed: 19 msec debug3: Got 0.24 bytes of entropy from 'df -l' debug3: Reading output from 'df -il' debug3: Time elapsed: 18 msec debug3: Got 0.33 bytes of entropy from 'df -il' debug3: Reading output from 'uptime' debug3: Time elapsed: 23 msec debug3: Got 0.06 bytes of entropy from 'uptime' debug3: Reading output from 'tail -200 /var/log/mail.log' debug3: Time elapsed: 29 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/mail.log' debug1: Seeded RNG with 27 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1037 geteuid 1037 anon 1 debug1: Connecting to waltst2 [xxx.xxx.xxx.xxx] port 22. debug1: restore_uid debug1: restore_uid debug1: Connection established. debug1: identity file /Users/username/.ssh/identity type 0 debug3: No RSA1 key file /Users/username/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /Users/username/.ssh/id_dsa type 2 debug3: No RSA1 key file /Users/username/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /Users/username/.ssh/id_rsa type 1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p1 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: 3des-cbc debug2: kex_parse_kexinit: 3des-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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour 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 3des-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server 3des-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: 189/384 debug1: bits set: 491/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 1 debug1: Host 'waltst2' is known and matches the RSA host key. debug1: Found key in /Users/username/.ssh/known_hosts2:1 debug1: bits set: 514/1024 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 debug3: start over, passed a different list publickey,password debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try pubkey: /Users/username/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0xadce0 hint 1 debug2: input_userauth_pk_ok: fp 84:0e:61:63:43:13:01:09:fd:e4:20:a0:7b:80:a5:b0 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: sig size 20 20 debug1: ssh-userauth2 successful: method publickey debug1: fd 7 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug2: tty_make_modes: ospeed 9600 debug2: tty_make_modes: ispeed 9600 debug2: tty_make_modes: 1 3 debug2: tty_make_modes: 2 28 debug2: tty_make_modes: 3 127 debug2: tty_make_modes: 4 21 debug2: tty_make_modes: 5 4 debug2: tty_make_modes: 6 255 debug2: tty_make_modes: 7 255 debug2: tty_make_modes: 8 17 debug2: tty_make_modes: 9 19 debug2: tty_make_modes: 10 26 debug2: tty_make_modes: 11 25 debug2: tty_make_modes: 12 18 debug2: tty_make_modes: 13 23 debug2: tty_make_modes: 14 22 debug2: tty_make_modes: 17 255 debug2: tty_make_modes: 18 15 debug2: tty_make_modes: 30 0 debug2: tty_make_modes: 31 0 debug2: tty_make_modes: 32 0 debug2: tty_make_modes: 33 0 debug2: tty_make_modes: 34 0 debug2: tty_make_modes: 35 0 debug2: tty_make_modes: 36 1 debug2: tty_make_modes: 38 1 debug2: tty_make_modes: 39 1 debug2: tty_make_modes: 40 0 debug2: tty_make_modes: 41 1 debug2: tty_make_modes: 50 1 debug2: tty_make_modes: 51 1 debug2: tty_make_modes: 53 1 debug2: tty_make_modes: 54 1 debug2: tty_make_modes: 55 0 debug2: tty_make_modes: 56 0 debug2: tty_make_modes: 57 0 debug2: tty_make_modes: 58 0 debug2: tty_make_modes: 59 1 debug2: tty_make_modes: 60 1 debug2: tty_make_modes: 61 1 debug2: tty_make_modes: 62 1 debug2: tty_make_modes: 70 1 debug2: tty_make_modes: 72 1 debug2: tty_make_modes: 90 1 debug2: tty_make_modes: 91 1 debug2: tty_make_modes: 92 0 debug2: tty_make_modes: 93 0 debug1: channel request 0: shell debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 debug3: Trying to reverse map address xxx.xxx.xxx.xxx. Last login: Fri Jun 29 09:45:28 2001 from gom-jabbar.appl Environment: USER=username LOGNAME=username HOME=/home/username PATH=/usr/bin:/bin:/usr/sbin:/sbin:/local/solaris_2.6/openssh2.9p2/bin MAIL=/var/mail//username SHELL=/bin/tcsh TZ=US/Pacific SSH_CLIENT=xxx.xxx.xxx.xxx 49250 22 SSH_TTY=/dev/pts/0 TERM=vt100 Sun Microsystems Inc. SunOS 5.6 Generic August 1997 username at waltst2> exit logout debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read debug2: channel 0: no data after CLOSE debug1: channel 0: send close debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug1: channel_free: channel 0: dettaching channel user Connection to waltst2 closed. debug1: Transferred: stdin 0, stdout 0, stderr 31 bytes in 14.5 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.1 debug1: Exit status 0 debug1: writing PRNG seed to file /Users/username/.ssh/prng_seed -------------- next part -------------- debug1: Seeding random number generator debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug2: mac_init: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 at openssh.com debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug1: sshd version OpenSSH_2.9p2 debug1: private host key: #0 type 0 RSA1 debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #2 type 1 RSA 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 xxx.xxx.xxx.xxx port 49250 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p1 debug1: match: OpenSSH_2.9p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-dss,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour 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: 3des-cbc debug2: kex_parse_kexinit: 3des-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 3des-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client 3des-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received WARNING: /etc/ssh/primes does not exist, using old prime debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 182/384 debug1: bits set: 514/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 491/1024 debug2: ssh_rsa_sign: done 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 username service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for username debug2: input_userauth_request: try method none Failed none for username from 17.205.33.22 port 49250 ssh2 debug1: userauth-request for user username service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 1037/10 (e=0) debug3: key_read: type mismatch debug3: key_read: type mismatch debug1: matching key found: file /home/username/.ssh/authorized_keys2, line 4 debug1: restore_uid debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss Postponed publickey for username from 17.205.33.22 port 49250 ssh2 debug1: userauth-request for user username service ssh-connection method publickey debug1: attempt 2 failures 1 debug2: input_userauth_request: try method publickey debug1: temporarily_use_uid: 1037/10 (e=0) debug3: key_read: type mismatch debug3: key_read: type mismatch debug1: matching key found: file /home/username/.ssh/authorized_keys2, line 4 debug1: restore_uid debug1: len 55 datafellows 0 debug1: ssh_dss_verify: signature correct debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss Accepted publickey for username from 17.205.33.22 port 49250 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 32768 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 debug2: callback start debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 debug1: session_pty_req: session 0 alloc /dev/pts/0 debug2: tty_parse_modes: SSH2 n_bytes 236 debug2: tty_parse_modes: ospeed 9600 debug2: tty_parse_modes: ispeed 9600 debug2: tty_parse_modes: 1 3 debug2: tty_parse_modes: 2 28 debug2: tty_parse_modes: 3 127 debug2: tty_parse_modes: 4 21 debug2: tty_parse_modes: 5 4 debug2: tty_parse_modes: 6 255 debug2: tty_parse_modes: 7 255 debug2: tty_parse_modes: 8 17 debug2: tty_parse_modes: 9 19 debug2: tty_parse_modes: 10 26 debug2: tty_parse_modes: 11 25 debug2: tty_parse_modes: 12 18 debug2: tty_parse_modes: 13 23 debug2: tty_parse_modes: 14 22 debug1: Ignoring unsupported tty mode opcode 17 (0x11) debug2: tty_parse_modes: 18 15 debug2: tty_parse_modes: 30 0 debug2: tty_parse_modes: 31 0 debug2: tty_parse_modes: 32 0 debug2: tty_parse_modes: 33 0 debug2: tty_parse_modes: 34 0 debug2: tty_parse_modes: 35 0 debug2: tty_parse_modes: 36 1 debug2: tty_parse_modes: 38 1 debug2: tty_parse_modes: 39 1 debug2: tty_parse_modes: 40 0 debug2: tty_parse_modes: 41 1 debug2: tty_parse_modes: 50 1 debug2: tty_parse_modes: 51 1 debug2: tty_parse_modes: 53 1 debug2: tty_parse_modes: 54 1 debug2: tty_parse_modes: 55 0 debug2: tty_parse_modes: 56 0 debug2: tty_parse_modes: 57 0 debug2: tty_parse_modes: 58 0 debug2: tty_parse_modes: 59 1 debug2: tty_parse_modes: 60 1 debug2: tty_parse_modes: 61 1 debug2: tty_parse_modes: 62 1 debug2: tty_parse_modes: 70 1 debug2: tty_parse_modes: 72 1 debug2: tty_parse_modes: 90 1 debug2: tty_parse_modes: 91 1 debug2: tty_parse_modes: 92 0 debug2: tty_parse_modes: 93 0 debug2: callback done debug2: callback start debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 debug1: fd 9 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug2: callback done debug1: channel 0: read<=0 rfd 9 len 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: channel 0: input: no drain shortcut debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug1: Received SIGCHLD. debug3: tvp!=NULL kid 1 mili 100 debug1: session_by_pid: pid 8318 debug1: session_exit_message: session 0 channel 0 pid 8318 debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: output open -> closed debug1: channel 0: close_write debug1: session_pty_cleanup: session 0 release /dev/pts/0 debug1: session_free: session 0 pid 8318 debug1: channel 0: send close debug2: channel 0: no data after CLOSE debug2: channel 0: no data after CLOSE debug1: channel 0: rcvd close debug2: channel 0: no data after CLOSE debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open: #0 server-session (t4 r0 i8/0 o128/0 fd -1/-1) Connection closed by remote host. Closing connection to 17.205.33.22 -------------- next part -------------- debug1: Seeding random number generator debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] debug2: mac_init: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 at openssh.com debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug1: sshd version OpenSSH_2.9p2 debug1: private host key: #0 type 0 RSA1 debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #2 type 1 RSA 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 xxx.xxx.xxx.xxx port 49249 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p1 debug1: match: OpenSSH_2.9p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-dss,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour 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 WARNING: /etc/ssh/primes does not exist, using old prime debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 129/256 debug1: bits set: 504/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 504/1024 debug2: ssh_rsa_sign: done 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 44b0 0f2f 6e24 1109 43b4 3dbc 6016 14fd Disconnecting: Bad packet length 1152388911. debug1: Calling cleanup 0x55abc(0x0) -------------- next part -------------- OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug1: Reading configuration data /etc/ssh_config debug1: Applying options for * debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: key names ok: [ssh-rsa,ssh-dss] debug2: mac_init: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-ripemd160 at openssh.com debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug2: mac_init: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 26 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log' debug3: Reading output from 'ls -alni /var/mail' debug3: Time elapsed: 20 msec debug3: Got 0.34 bytes of entropy from 'ls -alni /var/mail' debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 19 msec debug3: Got 0.13 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /var/tmp' debug3: Time elapsed: 21 msec debug3: Got 0.82 bytes of entropy from 'ls -alni /var/tmp' debug3: Reading output from 'ls -alTi /var/log' debug3: Time elapsed: 50 msec debug3: Got 2.00 bytes of entropy from 'ls -alTi /var/log' debug3: Reading output from 'ls -alTi /var/mail' debug3: Time elapsed: 46 msec debug3: Got 0.42 bytes of entropy from 'ls -alTi /var/mail' debug3: Reading output from 'ls -alTi /tmp' debug3: Time elapsed: 38 msec debug3: Got 0.15 bytes of entropy from 'ls -alTi /tmp' debug3: Reading output from 'ls -alTi /var/tmp' debug3: Time elapsed: 38 msec debug3: Got 1.00 bytes of entropy from 'ls -alTi /var/tmp' debug3: Reading output from 'netstat -an' debug3: Time elapsed: 35 msec debug3: Got 2.00 bytes of entropy from 'netstat -an' debug3: Reading output from 'netstat -s' debug3: Time elapsed: 26 msec debug3: Got 2.00 bytes of entropy from 'netstat -s' debug3: Reading output from 'arp -a -n' debug3: Time elapsed: 88 msec debug3: Got 0.67 bytes of entropy from 'arp -a -n' debug3: Reading output from 'ifconfig -a' debug3: Time elapsed: 33 msec debug3: Got 0.89 bytes of entropy from 'ifconfig -a' debug3: Reading output from 'ps laxww' debug3: Time elapsed: 65 msec debug3: Got 2.00 bytes of entropy from 'ps laxww' debug3: Reading output from 'ps -al' debug3: Time elapsed: 47 msec debug3: Got 1.20 bytes of entropy from 'ps -al' debug3: Reading output from 'w' debug3: Time elapsed: 21 msec debug3: Got 0.99 bytes of entropy from 'w' debug3: Reading output from 'last' debug3: Time elapsed: 68 msec debug3: Got 2.00 bytes of entropy from 'last' debug3: Reading output from 'df -l' debug3: Time elapsed: 18 msec debug3: Got 0.24 bytes of entropy from 'df -l' debug3: Reading output from 'df -il' debug3: Time elapsed: 18 msec debug3: Got 0.33 bytes of entropy from 'df -il' debug3: Reading output from 'uptime' debug3: Time elapsed: 19 msec debug3: Got 0.06 bytes of entropy from 'uptime' debug3: Reading output from 'tail -200 /var/log/mail.log' debug3: Time elapsed: 20 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/mail.log' debug1: Seeded RNG with 27 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1037 geteuid 1037 anon 1 debug1: Connecting to waltst2 [xxx.xxx.xxx.xxx] port 22. debug1: restore_uid debug1: restore_uid debug1: Connection established. debug1: identity file /Users/username/.ssh/identity type 0 debug3: No RSA1 key file /Users/username/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /Users/username/.ssh/id_dsa type 2 debug3: No RSA1 key file /Users/username/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /Users/username/.ssh/id_rsa type 1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p1 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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour 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: 128/256 debug1: bits set: 504/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 1 debug1: Host 'waltst2' is known and matches the RSA host key. debug1: Found key in /Users/username/.ssh/known_hosts2:1 debug1: bits set: 504/1024 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 c3d1 40e3 72fe 1038 891d c922 c2c0 0fe1 Disconnecting: Bad packet length -1009696541. debug1: Calling cleanup 0x17d1c(0x0) debug1: Calling cleanup 0x14c70(0x0) debug1: writing PRNG seed to file /Users/username/.ssh/prng_seed From jmates at sial.org Tue Jul 10 05:26:39 2001 From: jmates at sial.org (Jeremy A. Mates) Date: Mon, 9 Jul 2001 12:26:39 -0700 (PDT) Subject: OpenSSH cipher problems between 2.9p1 and 2.9p2 In-Reply-To: <3B49DEA6.662B3E53@pico.apple.com> Message-ID: I saw the same problem when I applied the 10.0.4 update from Apple, which installed the "bad packet length" OpenSSH 2.9p1 over my previously working OpenSSH 2.9p2. The solution was to reinstall OpenSSH from the stepwise folks: http://www.stepwise.com/Articles/Workbench/2001-05-02.03.html -- Jeremy Mates http://www.sial.org/ "You cannot control, only catch." -- Tsung Tsai From mouring at etoh.eviladmin.org Tue Jul 10 05:41:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 9 Jul 2001 14:41:07 -0500 (CDT) Subject: [patch] SSH host keys in DNS In-Reply-To: <20010709113243.D985@tislabs.com> Message-ID: I've not looked at the patches yet, but are you basing this off any RFC? I know on the IETF list they talked about this, but I don't remember any drafts unless they occured on the DNS mailinglist. - Ben On Mon, 9 Jul 2001, Wesley Griffin wrote: > I've made some changes to the 2.9p2 release code to add support for > using DNSSEC lookups to check host keys. I've also made the changes to > the OPENBSD_2_9 tree. Both patches are available at > ftp://ftp.tislabs.com/pub/fmeshd/ as > openssh.[portable,openbsd].patch.20010709 > > I'm really looking for testers at this time. Right now the lookups are > done using a getrrsetbyname() function that is part of the BIND9 lwres > API. I'm in the process of writing a similar standalone function for the > OpenBSD tree. > > There is a README.DNSSEC file in the directory that has more details. > > -- > Wesley Griffin NAI Labs > wgriffin at tislabs.com 443.259.2388 > From wgriffin at tislabs.com Tue Jul 10 06:08:10 2001 From: wgriffin at tislabs.com (Wesley Griffin) Date: Mon, 9 Jul 2001 16:08:10 -0400 Subject: [patch] SSH host keys in DNS In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Jul 09, 2001 at 02:41:07PM -0500 References: <20010709113243.D985@tislabs.com> Message-ID: <20010709160807.E985@tislabs.com> * mouring at etoh.eviladmin.org [07/09/01 15:55]: > > I've not looked at the patches yet, but are you basing this off any RFC? > I know on the IETF list they talked about this, but I don't remember any > drafts unless they occured on the DNS mailinglist. I'm the author of the secsh draft on store host keys in DNS :) There are no other RFCs about this, either in the secsh or dnsext working groups. I've been asked to write an implementation draft for the secsh working group, and I'm thinking it through, now that I have some experience implementing this... > On Mon, 9 Jul 2001, Wesley Griffin wrote: > > > I've made some changes to the 2.9p2 release code to add support for > > using DNSSEC lookups to check host keys. I've also made the changes to > > the OPENBSD_2_9 tree. Both patches are available at > > ftp://ftp.tislabs.com/pub/fmeshd/ as > > openssh.[portable,openbsd].patch.20010709 > > > > I'm really looking for testers at this time. Right now the lookups are > > done using a getrrsetbyname() function that is part of the BIND9 lwres > > API. I'm in the process of writing a similar standalone function for the > > OpenBSD tree. > > > > There is a README.DNSSEC file in the directory that has more details. -- Wesley Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From qralston+ml.openssh-unix-dev at andrew.cmu.edu Tue Jul 10 07:08:50 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Mon, 9 Jul 2001 17:08:50 -0400 (EDT) Subject: Xauthority location: only per-user setting possible In-Reply-To: Message-ID: On Fri, 6 Jul 2001, Pekka Savola wrote: > Hello all, > > $XAUTHORITY location has moved from under /tmp to ~/.Xauthority in > 2.9p2. > > The commit message was: > --- > remove xauth-cookie-in-tmp handling. use default $XAUTHORITY, since > we do already trust $HOME/.ssh > you can use .ssh/sshrc and .ssh/environment if you want to customize > the location of the xauth cookies > --- > > [...] > > To provide xauthority in /tmp for _everyone_, everyone has to pick > one $XAUTHORITY location and put it in .ssh/environment. > > This does not seem too scalable. Yes, this is a problem. In a nutshell, removing the xauth-cookie-in-tmp handling makes it so that there is no way to securely change the location of the Xauthority file to a subdirectory of /tmp (or any other globally-shared temporary directory). You can define XAUTHORITY in $HOME/.ssh/environment (e.g., to /tmp/username-Xauthority), but there is no way to create the file securely. So, this option is unacceptable. You can use mktemp(1) in $HOME/.ssh/rc to securely create a Xauthority file, but there is no way to propagate the XAUTHORITY environment variable back up to sshd. So, this option won't work. The quickest solution is to simply add back in the xauth-cookie-in-tmp handling stuff, and make sure that xauthfile_cleanup_proc uses temporarily_use_uid(). I've come up with a patch against 2.9p2 to do exactly that, although I haven't tested it. I think a better solution (and one more in tune with the desires of the OpenSSH maintainers) would be to have OpenSSH capture the stdout of $HOME/.ssh/rc and process it in exactly the same way as $HOME/.ssh/environment. That would permit one to construct a $HOME/.ssh/rc like the following: #! /bin/sh read proto cookie [ "x${proto}x" = xx ] && exit 1 [ "x${cookie}x" = xx ] && exit 1 XAUTHORITY="`mktemp /tmp/username-ssh-cookie-XXXXXX`" || exit 1 # If "echo" isn't a builtin, this exposes your cookie to ps(1)! echo add ${DISPLAY} ${proto} ${cookie} | xauth -q - || exit 1 echo XAUTHORITY=${XAUTHORITY} exit 0 In short, let the user solve the Xauthority file problem (and any other initialization problems he might happen to have), and communicate the necessary environment variables back to sshd. This gets OpenSSH out of the business of doing things that should be handled by the user in the first place. Thoughts? -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From jmknoble at pobox.com Tue Jul 10 08:18:51 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 9 Jul 2001 17:18:51 -0500 Subject: Xauthority location: only per-user setting possible In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Mon, Jul 09, 2001 at 05:08:50PM -0400 References: Message-ID: <20010709171851.B18595@zax.half.pint-stowp.cx> Circa 2001-Jul-09 17:08:50 -0400 dixit James Ralston: : I think a better solution (and one more in tune with the desires of : the OpenSSH maintainers) would be to have OpenSSH capture the stdout : of $HOME/.ssh/rc and process it in exactly the same way as : $HOME/.ssh/environment. That would permit one to construct a : $HOME/.ssh/rc like the following: : : #! /bin/sh : read proto cookie : [ "x${proto}x" = xx ] && exit 1 : [ "x${cookie}x" = xx ] && exit 1 : XAUTHORITY="`mktemp /tmp/username-ssh-cookie-XXXXXX`" || exit 1 : # If "echo" isn't a builtin, this exposes your cookie to ps(1)! : echo add ${DISPLAY} ${proto} ${cookie} | xauth -q - || exit 1 This would probably work better: xauth -q -f "${XAUTHORITY}" - < Or use rsync -ae ssh dir/file host:dir > -----Original Message----- > From: Dan Kaminsky [mailto:dankamin at cisco.com] > Sent: Monday, July 09, 2001 4:02 PM > To: openssh-unix-dev at mindrot.org; Jo?l Soete > Subject: Re: scp problem (openssh-2.9p2) > > > > scp does not preserve links (neither soft neither hard) > > Joel-- > > Play around with the following command: > > tar -cf - | ssh user at host 'tar -C > destination_path -xvf -' > > I've begun to completely abandon SCP proper. > > --Dan > > From markus.friedl at informatik.uni-erlangen.de Wed Jul 11 05:42:00 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 10 Jul 2001 21:42:00 +0200 Subject: OpenSSH cipher problems between 2.9p1 and 2.9p2 In-Reply-To: <3B49DEA6.662B3E53@pico.apple.com>; from dhaag@pico.apple.com on Mon, Jul 09, 2001 at 09:41:10AM -0700 References: <002001c1087f$c68ad2a0$3000010a@na.cisco.com> <20010709104727.B14354@zax.half.pint-stowp.cx> <3B49DEA6.662B3E53@pico.apple.com> Message-ID: <20010710214200.B29229@folly> it seems that your OpenSSH running on MacOS is not compiled with the correct endian definition in rijndael.h On Mon, Jul 09, 2001 at 09:41:10AM -0700, Dennis Haag wrote: > I recently upgraded OpenSSH on our Suns (Solaris 2.6 and Solaris 7) to > 2.9p2 and ran into a problem with the OpenSSH 2.9p1 that is part of Mac OS > X (10.0.4). > > b071 f5b5 d870 6558 c7dc c966 d089 7d65 > > Disconnecting: Bad packet length -1334708811. > > It appears that the default of having the aes128-cbc cipher first is the > source of the problem. If I force another cipher with the -c command line > option or put aes128-cbc later in the Ciphers list it works. I don't know > what the OpenSSL (0.9.5a) or OpenSSH (2.9p1) configure/compile options were > used by Apple when building this. I have both the client and server side > debug information which I will attach. Has anyone else seen this problem > between 2.9p1 and 2.9p2 on any other platform? I don't see the problem > between 2.9p1 and 2.9p2 on Solaris. > > Thanks in advance. > > -- > Dennis Haag Engineering Computer Services > haag at apple.com unix-support at apple.com > 408-974-6630 ECS Hotline: 408-974-4747 > # This is ssh client systemwide configuration file. This file provides > # defaults for users, and the values can be changed in per-user configuration > # files or on the command line. > > # Configuration data is parsed as follows: > # 1. command line options > # 2. user-specific file > # 3. system-wide file > # Any configuration value is only changed the first time it is set. > # Thus, host-specific definitions should be at the beginning of the > # configuration file, and defaults at the end. > > # Site-wide defaults for various options > > # All options have been included alphabetically in the file, even though > # most are set to the default. This protects against changes in defaults > # in future versions and provides a complete list or configurable options. > > Host * > BatchMode no > CheckHostIP yes > ChallengeResponseAuthentication no > # Cipher 3des > # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc > Compression no > CompressionLevel 6 > ConnectionAttempts 4 > EscapeChar ~ > FallBackToRsh no > ForwardAgent no > ForwardX11 yes > GatewayPorts no > GlobalKnownHostsFile /etc/ssh/ssh_known_hosts > GlobalKnownHostsFile2 /etc/ssh/ssh_known_hosts2 > HostbasedAuthentication yes > HostKeyAlgorithms ssh-rsa,ssh-dss > # HostKeyAlias no global default > # HostName no global default > IdentityFile ~/.ssh/identity > IdentityFile ~/.ssh/id_dsa > IdentityFile ~/.ssh/id_rsa > KeepAlive yes > # LocalForward no global defaults > LogLevel INFO > Macs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > NumberOfPasswordPrompts 3 > PasswordAuthentication yes > PreferredAuthentications publickey,password,keyboard-interactive > Port 22 > Protocol 2,1 > # ProxyCommand no global default > PubkeyAuthentication yes > # RemoteForward no global default > RhostsAuthentication no > RhostsRSAAuthentication yes > RSAAuthentication yes > StrictHostKeyChecking ask > UsePrivilegedPort no > # User no global default > UserKnownHostsFile ~/.ssh/known_hosts > UserKnownHostsFile2 ~/.ssh/known_hosts2 > UseRsh no > XAuthLocation /usr/openwin/bin/xauth > # This is ssh server systemwide configuration file. > # > # All options have been included alphabetically in the file, even though > # most are set to the default. This protects against changes in defaults > # in future versions and provides a complete list or configurable options. > > > #AllowGroups * > AllowTcpForwarding yes > #AllowUsers * > #Banner /etc/ssh/issue > ChallengeResponseAuthentication no > #Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > CheckMail no > ClientAliveInterval 0 > ClientAliveCountMax 3 > #DenyGroups nogroup > #DenyUsers nobody > GatewayPorts no > HostbasedAuthentication no > HostKey /etc/ssh/ssh_host_key > HostKey /etc/ssh/ssh_host_dsa_key > HostKey /etc/ssh/ssh_host_rsa_key > IgnoreRhosts yes > IgnoreUserKnownHosts no > KeepAlive yes > KeyRegenerationInterval 3600 > #Port parameter must preceed ListenAddress > Port 22 > ListenAddress 0.0.0.0 > LoginGraceTime 600 > LogLevel INFO > Macs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > MaxStartups 10:30:60 > PAMAuthenticationViaKbdInt no > PasswordAuthentication yes > PermitEmptyPasswords no > PermitRootLogin yes > PidFile /etc/ssh/ssh.pid > PrintLastLog yes > PrintMotd no > Protocol 2,1 > PubkeyAuthentication yes > ReverseMappingCheck no > RhostsAuthentication no > RhostsRSAAuthentication yes > RSAAuthentication yes > ServerKeyBits 768 > StrictModes yes > Subsystem sftp /local/solaris_2.6/openssh2.9p2/libexec/sftp-server > SyslogFacility AUTH > UseLogin no > X11DisplayOffset 10 > X11Forwarding yes > XAuthLocation /usr/openwin/bin/xauth > OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > debug1: Reading configuration data /etc/ssh_config > debug1: Applying options for * > debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: key names ok: [ssh-rsa,ssh-dss] > debug2: mac_init: found hmac-md5 > debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1 > debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 > debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 at openssh.com > debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1-96 > debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-md5-96 > debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: Reading output from 'ls -alni /var/log' > debug3: Time elapsed: 25 msec > debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log' > debug3: Reading output from 'ls -alni /var/mail' > debug3: Time elapsed: 20 msec > debug3: Got 0.34 bytes of entropy from 'ls -alni /var/mail' > debug3: Reading output from 'ls -alni /tmp' > debug3: Time elapsed: 28 msec > debug3: Got 0.13 bytes of entropy from 'ls -alni /tmp' > debug3: Reading output from 'ls -alni /var/tmp' > debug3: Time elapsed: 21 msec > debug3: Got 0.82 bytes of entropy from 'ls -alni /var/tmp' > debug3: Reading output from 'ls -alTi /var/log' > debug3: Time elapsed: 41 msec > debug3: Got 2.00 bytes of entropy from 'ls -alTi /var/log' > debug3: Reading output from 'ls -alTi /var/mail' > debug3: Time elapsed: 38 msec > debug3: Got 0.42 bytes of entropy from 'ls -alTi /var/mail' > debug3: Reading output from 'ls -alTi /tmp' > debug3: Time elapsed: 36 msec > debug3: Got 0.15 bytes of entropy from 'ls -alTi /tmp' > debug3: Reading output from 'ls -alTi /var/tmp' > debug3: Time elapsed: 46 msec > debug3: Got 1.00 bytes of entropy from 'ls -alTi /var/tmp' > debug3: Reading output from 'netstat -an' > debug3: Time elapsed: 31 msec > debug3: Got 2.00 bytes of entropy from 'netstat -an' > debug3: Reading output from 'netstat -s' > debug3: Time elapsed: 24 msec > debug3: Got 2.00 bytes of entropy from 'netstat -s' > debug3: Reading output from 'arp -a -n' > debug3: Time elapsed: 81 msec > debug3: Got 0.67 bytes of entropy from 'arp -a -n' > debug3: Reading output from 'ifconfig -a' > debug3: Time elapsed: 21 msec > debug3: Got 0.89 bytes of entropy from 'ifconfig -a' > debug3: Reading output from 'ps laxww' > debug3: Time elapsed: 64 msec > debug3: Got 2.00 bytes of entropy from 'ps laxww' > debug3: Reading output from 'ps -al' > debug3: Time elapsed: 51 msec > debug3: Got 1.20 bytes of entropy from 'ps -al' > debug3: Reading output from 'w' > debug3: Time elapsed: 22 msec > debug3: Got 0.99 bytes of entropy from 'w' > debug3: Reading output from 'last' > debug3: Time elapsed: 57 msec > debug3: Got 2.00 bytes of entropy from 'last' > debug3: Reading output from 'df -l' > debug3: Time elapsed: 19 msec > debug3: Got 0.24 bytes of entropy from 'df -l' > debug3: Reading output from 'df -il' > debug3: Time elapsed: 18 msec > debug3: Got 0.33 bytes of entropy from 'df -il' > debug3: Reading output from 'uptime' > debug3: Time elapsed: 23 msec > debug3: Got 0.06 bytes of entropy from 'uptime' > debug3: Reading output from 'tail -200 /var/log/mail.log' > debug3: Time elapsed: 29 msec > debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/mail.log' > debug1: Seeded RNG with 27 bytes from programs > debug1: Seeded RNG with 3 bytes from system calls > debug1: Rhosts Authentication disabled, originating port will not be trusted. > debug1: restore_uid > debug1: ssh_connect: getuid 1037 geteuid 1037 anon 1 > debug1: Connecting to waltst2 [xxx.xxx.xxx.xxx] port 22. > debug1: restore_uid > debug1: restore_uid > debug1: Connection established. > debug1: identity file /Users/username/.ssh/identity type 0 > debug3: No RSA1 key file /Users/username/.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: no key found > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: no key found > debug1: identity file /Users/username/.ssh/id_dsa type 2 > debug3: No RSA1 key file /Users/username/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: no key found > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: no key found > debug1: identity file /Users/username/.ssh/id_rsa type 1 > debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 > debug1: match: OpenSSH_2.9p2 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_2.9p1 > 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: 3des-cbc > debug2: kex_parse_kexinit: 3des-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-dss,ssh-rsa > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > 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 3des-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: client->server 3des-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: 189/384 > debug1: bits set: 491/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 > debug3: check_host_in_hostfile: match line 1 > debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 > debug3: check_host_in_hostfile: match line 1 > debug1: Host 'waltst2' is known and matches the RSA host key. > debug1: Found key in /Users/username/.ssh/known_hosts2:1 > debug1: bits set: 514/1024 > 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 > debug3: start over, passed a different list publickey,password > debug3: preferred publickey,password,keyboard-interactive > debug3: authmethod_lookup publickey > debug3: remaining preferred: password,keyboard-interactive > debug3: authmethod_is_enabled publickey > debug1: next auth method to try is publickey > debug1: try pubkey: /Users/username/.ssh/id_dsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0xadce0 hint 1 > debug2: input_userauth_pk_ok: fp 84:0e:61:63:43:13:01:09:fd:e4:20:a0:7b:80:a5:b0 > debug3: sign_and_send_pubkey > debug1: read PEM private key done: type DSA > debug1: sig size 20 20 > debug1: ssh-userauth2 successful: method publickey > debug1: fd 7 setting O_NONBLOCK > debug1: fd 8 IS O_NONBLOCK > debug1: channel 0: new [client-session] > debug1: channel_new: 0 > debug1: send channel open 0 > debug1: Entering interactive session. > debug2: callback start > debug1: client_init id 0 arg 0 > debug2: tty_make_modes: ospeed 9600 > debug2: tty_make_modes: ispeed 9600 > debug2: tty_make_modes: 1 3 > debug2: tty_make_modes: 2 28 > debug2: tty_make_modes: 3 127 > debug2: tty_make_modes: 4 21 > debug2: tty_make_modes: 5 4 > debug2: tty_make_modes: 6 255 > debug2: tty_make_modes: 7 255 > debug2: tty_make_modes: 8 17 > debug2: tty_make_modes: 9 19 > debug2: tty_make_modes: 10 26 > debug2: tty_make_modes: 11 25 > debug2: tty_make_modes: 12 18 > debug2: tty_make_modes: 13 23 > debug2: tty_make_modes: 14 22 > debug2: tty_make_modes: 17 255 > debug2: tty_make_modes: 18 15 > debug2: tty_make_modes: 30 0 > debug2: tty_make_modes: 31 0 > debug2: tty_make_modes: 32 0 > debug2: tty_make_modes: 33 0 > debug2: tty_make_modes: 34 0 > debug2: tty_make_modes: 35 0 > debug2: tty_make_modes: 36 1 > debug2: tty_make_modes: 38 1 > debug2: tty_make_modes: 39 1 > debug2: tty_make_modes: 40 0 > debug2: tty_make_modes: 41 1 > debug2: tty_make_modes: 50 1 > debug2: tty_make_modes: 51 1 > debug2: tty_make_modes: 53 1 > debug2: tty_make_modes: 54 1 > debug2: tty_make_modes: 55 0 > debug2: tty_make_modes: 56 0 > debug2: tty_make_modes: 57 0 > debug2: tty_make_modes: 58 0 > debug2: tty_make_modes: 59 1 > debug2: tty_make_modes: 60 1 > debug2: tty_make_modes: 61 1 > debug2: tty_make_modes: 62 1 > debug2: tty_make_modes: 70 1 > debug2: tty_make_modes: 72 1 > debug2: tty_make_modes: 90 1 > debug2: tty_make_modes: 91 1 > debug2: tty_make_modes: 92 0 > debug2: tty_make_modes: 93 0 > debug1: channel request 0: shell > debug2: callback done > debug1: channel 0: open confirm rwindow 0 rmax 16384 > debug2: channel 0: rcvd adjust 32768 > debug3: Trying to reverse map address xxx.xxx.xxx.xxx. > > Last login: Fri Jun 29 09:45:28 2001 from gom-jabbar.appl > > Environment: > USER=username > LOGNAME=username > HOME=/home/username > PATH=/usr/bin:/bin:/usr/sbin:/sbin:/local/solaris_2.6/openssh2.9p2/bin > MAIL=/var/mail//username > SHELL=/bin/tcsh > TZ=US/Pacific > SSH_CLIENT=xxx.xxx.xxx.xxx 49250 22 > SSH_TTY=/dev/pts/0 > TERM=vt100 > Sun Microsystems Inc. SunOS 5.6 Generic August 1997 > > username at waltst2> exit > > logout > debug1: channel 0: rcvd eof > debug1: channel 0: output open -> drain > debug1: channel 0: obuf empty > debug1: channel 0: output drain -> closed > debug1: channel 0: close_write > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug1: channel 0: rcvd close > debug1: channel 0: input open -> closed > debug1: channel 0: close_read > debug2: channel 0: no data after CLOSE > debug1: channel 0: send close > debug1: channel 0: is dead > debug1: channel_free: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) > > debug1: channel_free: channel 0: dettaching channel user > Connection to waltst2 closed. > debug1: Transferred: stdin 0, stdout 0, stderr 31 bytes in 14.5 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.1 > debug1: Exit status 0 > debug1: writing PRNG seed to file /Users/username/.ssh/prng_seed > debug1: Seeding random number generator > debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug2: mac_init: found hmac-md5 > debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1 > debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 > debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 at openssh.com > debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1-96 > debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-md5-96 > debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug1: sshd version OpenSSH_2.9p2 > debug1: private host key: #0 type 0 RSA1 > debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #2 type 1 RSA > 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 xxx.xxx.xxx.xxx port 49250 > debug1: Client protocol version 2.0; client software version OpenSSH_2.9p1 > debug1: match: OpenSSH_2.9p1 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.9p2 > debug1: Rhosts Authentication disabled, originating port not trusted. > debug1: list_hostkey_types: ssh-dss,ssh-rsa > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss,ssh-rsa > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > 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: 3des-cbc > debug2: kex_parse_kexinit: 3des-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 3des-cbc hmac-md5 none > debug2: mac_init: found hmac-md5 > debug1: kex: server->client 3des-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > WARNING: /etc/ssh/primes does not exist, using old prime > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 182/384 > debug1: bits set: 514/1024 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 491/1024 > debug2: ssh_rsa_sign: done > 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 username service ssh-connection method none > debug1: attempt 0 failures 0 > debug2: input_userauth_request: setting up authctxt for username > debug2: input_userauth_request: try method none > Failed none for username from 17.205.33.22 port 49250 ssh2 > debug1: userauth-request for user username service ssh-connection method publickey > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method publickey > debug1: test whether pkalg/pkblob are acceptable > debug1: temporarily_use_uid: 1037/10 (e=0) > debug3: key_read: type mismatch > debug3: key_read: type mismatch > debug1: matching key found: file /home/username/.ssh/authorized_keys2, line 4 > debug1: restore_uid > debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss > Postponed publickey for username from 17.205.33.22 port 49250 ssh2 > debug1: userauth-request for user username service ssh-connection method publickey > debug1: attempt 2 failures 1 > debug2: input_userauth_request: try method publickey > debug1: temporarily_use_uid: 1037/10 (e=0) > debug3: key_read: type mismatch > debug3: key_read: type mismatch > debug1: matching key found: file /home/username/.ssh/authorized_keys2, line 4 > debug1: restore_uid > debug1: len 55 datafellows 0 > debug1: ssh_dss_verify: signature correct > debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss > Accepted publickey for username from 17.205.33.22 port 49250 ssh2 > debug1: Entering interactive session for SSH2. > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 32768 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 > debug2: callback start > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0 > debug1: session_pty_req: session 0 alloc /dev/pts/0 > debug2: tty_parse_modes: SSH2 n_bytes 236 > debug2: tty_parse_modes: ospeed 9600 > debug2: tty_parse_modes: ispeed 9600 > debug2: tty_parse_modes: 1 3 > debug2: tty_parse_modes: 2 28 > debug2: tty_parse_modes: 3 127 > debug2: tty_parse_modes: 4 21 > debug2: tty_parse_modes: 5 4 > debug2: tty_parse_modes: 6 255 > debug2: tty_parse_modes: 7 255 > debug2: tty_parse_modes: 8 17 > debug2: tty_parse_modes: 9 19 > debug2: tty_parse_modes: 10 26 > debug2: tty_parse_modes: 11 25 > debug2: tty_parse_modes: 12 18 > debug2: tty_parse_modes: 13 23 > debug2: tty_parse_modes: 14 22 > debug1: Ignoring unsupported tty mode opcode 17 (0x11) > debug2: tty_parse_modes: 18 15 > debug2: tty_parse_modes: 30 0 > debug2: tty_parse_modes: 31 0 > debug2: tty_parse_modes: 32 0 > debug2: tty_parse_modes: 33 0 > debug2: tty_parse_modes: 34 0 > debug2: tty_parse_modes: 35 0 > debug2: tty_parse_modes: 36 1 > debug2: tty_parse_modes: 38 1 > debug2: tty_parse_modes: 39 1 > debug2: tty_parse_modes: 40 0 > debug2: tty_parse_modes: 41 1 > debug2: tty_parse_modes: 50 1 > debug2: tty_parse_modes: 51 1 > debug2: tty_parse_modes: 53 1 > debug2: tty_parse_modes: 54 1 > debug2: tty_parse_modes: 55 0 > debug2: tty_parse_modes: 56 0 > debug2: tty_parse_modes: 57 0 > debug2: tty_parse_modes: 58 0 > debug2: tty_parse_modes: 59 1 > debug2: tty_parse_modes: 60 1 > debug2: tty_parse_modes: 61 1 > debug2: tty_parse_modes: 62 1 > debug2: tty_parse_modes: 70 1 > debug2: tty_parse_modes: 72 1 > debug2: tty_parse_modes: 90 1 > debug2: tty_parse_modes: 91 1 > debug2: tty_parse_modes: 92 0 > debug2: tty_parse_modes: 93 0 > debug2: callback done > debug2: callback start > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request shell reply 0 > debug1: fd 9 setting O_NONBLOCK > debug1: fd 8 IS O_NONBLOCK > debug2: callback done > debug1: channel 0: read<=0 rfd 9 len 0 > debug1: channel 0: read failed > debug1: channel 0: input open -> drain > debug1: channel 0: close_read > debug1: channel 0: input: no drain shortcut > debug1: channel 0: ibuf empty > debug1: channel 0: input drain -> closed > debug1: channel 0: send eof > debug1: Received SIGCHLD. > debug3: tvp!=NULL kid 1 mili 100 > debug1: session_by_pid: pid 8318 > debug1: session_exit_message: session 0 channel 0 pid 8318 > debug1: session_exit_message: release channel 0 > debug1: channel 0: write failed > debug1: channel 0: output open -> closed > debug1: channel 0: close_write > debug1: session_pty_cleanup: session 0 release /dev/pts/0 > debug1: session_free: session 0 pid 8318 > debug1: channel 0: send close > debug2: channel 0: no data after CLOSE > debug2: channel 0: no data after CLOSE > debug1: channel 0: rcvd close > debug2: channel 0: no data after CLOSE > debug1: channel 0: is dead > debug1: channel_free: channel 0: status: The following connections are open: > #0 server-session (t4 r0 i8/0 o128/0 fd -1/-1) > > Connection closed by remote host. > Closing connection to 17.205.33.22 > debug1: Seeding random number generator > debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour] > debug2: mac_init: found hmac-md5 > debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1 > debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 > debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 at openssh.com > debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1-96 > debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-md5-96 > debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug1: sshd version OpenSSH_2.9p2 > debug1: private host key: #0 type 0 RSA1 > debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key. > debug1: read PEM private key done: type DSA > debug1: private host key: #1 type 2 DSA > debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key. > debug1: read PEM private key done: type RSA > debug1: private host key: #2 type 1 RSA > 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 xxx.xxx.xxx.xxx port 49249 > debug1: Client protocol version 2.0; client software version OpenSSH_2.9p1 > debug1: match: OpenSSH_2.9p1 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.9p2 > debug1: Rhosts Authentication disabled, originating port not trusted. > debug1: list_hostkey_types: ssh-dss,ssh-rsa > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss,ssh-rsa > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > 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 > WARNING: /etc/ssh/primes does not exist, using old prime > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 129/256 > debug1: bits set: 504/1024 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 504/1024 > debug2: ssh_rsa_sign: done > 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 > 44b0 0f2f 6e24 1109 43b4 3dbc 6016 14fd > > Disconnecting: Bad packet length 1152388911. > debug1: Calling cleanup 0x55abc(0x0) > OpenSSH_2.9p1, SSH protocols 1.5/2.0, OpenSSL 0x0090581f > debug1: Reading configuration data /etc/ssh_config > debug1: Applying options for * > debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] > debug3: key names ok: [ssh-rsa,ssh-dss] > debug2: mac_init: found hmac-md5 > debug3: mac ok: hmac-md5 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1 > debug3: mac ok: hmac-sha1 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 > debug3: mac ok: hmac-ripemd160 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-ripemd160 at openssh.com > debug3: mac ok: hmac-ripemd160 at openssh.com [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-sha1-96 > debug3: mac ok: hmac-sha1-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug2: mac_init: found hmac-md5-96 > debug3: mac ok: hmac-md5-96 [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: macs ok: [hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96] > debug3: Reading output from 'ls -alni /var/log' > debug3: Time elapsed: 26 msec > debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log' > debug3: Reading output from 'ls -alni /var/mail' > debug3: Time elapsed: 20 msec > debug3: Got 0.34 bytes of entropy from 'ls -alni /var/mail' > debug3: Reading output from 'ls -alni /tmp' > debug3: Time elapsed: 19 msec > debug3: Got 0.13 bytes of entropy from 'ls -alni /tmp' > debug3: Reading output from 'ls -alni /var/tmp' > debug3: Time elapsed: 21 msec > debug3: Got 0.82 bytes of entropy from 'ls -alni /var/tmp' > debug3: Reading output from 'ls -alTi /var/log' > debug3: Time elapsed: 50 msec > debug3: Got 2.00 bytes of entropy from 'ls -alTi /var/log' > debug3: Reading output from 'ls -alTi /var/mail' > debug3: Time elapsed: 46 msec > debug3: Got 0.42 bytes of entropy from 'ls -alTi /var/mail' > debug3: Reading output from 'ls -alTi /tmp' > debug3: Time elapsed: 38 msec > debug3: Got 0.15 bytes of entropy from 'ls -alTi /tmp' > debug3: Reading output from 'ls -alTi /var/tmp' > debug3: Time elapsed: 38 msec > debug3: Got 1.00 bytes of entropy from 'ls -alTi /var/tmp' > debug3: Reading output from 'netstat -an' > debug3: Time elapsed: 35 msec > debug3: Got 2.00 bytes of entropy from 'netstat -an' > debug3: Reading output from 'netstat -s' > debug3: Time elapsed: 26 msec > debug3: Got 2.00 bytes of entropy from 'netstat -s' > debug3: Reading output from 'arp -a -n' > debug3: Time elapsed: 88 msec > debug3: Got 0.67 bytes of entropy from 'arp -a -n' > debug3: Reading output from 'ifconfig -a' > debug3: Time elapsed: 33 msec > debug3: Got 0.89 bytes of entropy from 'ifconfig -a' > debug3: Reading output from 'ps laxww' > debug3: Time elapsed: 65 msec > debug3: Got 2.00 bytes of entropy from 'ps laxww' > debug3: Reading output from 'ps -al' > debug3: Time elapsed: 47 msec > debug3: Got 1.20 bytes of entropy from 'ps -al' > debug3: Reading output from 'w' > debug3: Time elapsed: 21 msec > debug3: Got 0.99 bytes of entropy from 'w' > debug3: Reading output from 'last' > debug3: Time elapsed: 68 msec > debug3: Got 2.00 bytes of entropy from 'last' > debug3: Reading output from 'df -l' > debug3: Time elapsed: 18 msec > debug3: Got 0.24 bytes of entropy from 'df -l' > debug3: Reading output from 'df -il' > debug3: Time elapsed: 18 msec > debug3: Got 0.33 bytes of entropy from 'df -il' > debug3: Reading output from 'uptime' > debug3: Time elapsed: 19 msec > debug3: Got 0.06 bytes of entropy from 'uptime' > debug3: Reading output from 'tail -200 /var/log/mail.log' > debug3: Time elapsed: 20 msec > debug3: Got 2.00 bytes of entropy from 'tail -200 /var/log/mail.log' > debug1: Seeded RNG with 27 bytes from programs > debug1: Seeded RNG with 3 bytes from system calls > debug1: Rhosts Authentication disabled, originating port will not be trusted. > debug1: restore_uid > debug1: ssh_connect: getuid 1037 geteuid 1037 anon 1 > debug1: Connecting to waltst2 [xxx.xxx.xxx.xxx] port 22. > debug1: restore_uid > debug1: restore_uid > debug1: Connection established. > debug1: identity file /Users/username/.ssh/identity type 0 > debug3: No RSA1 key file /Users/username/.ssh/id_dsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: no key found > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: no key found > debug1: identity file /Users/username/.ssh/id_dsa type 2 > debug3: No RSA1 key file /Users/username/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: no key found > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug3: key_read: no space > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: no key found > debug1: identity file /Users/username/.ssh/id_rsa type 1 > debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 > debug1: match: OpenSSH_2.9p2 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_2.9p1 > 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-dss,ssh-rsa > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour > 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: 128/256 > debug1: bits set: 504/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 > debug3: check_host_in_hostfile: match line 1 > debug3: check_host_in_hostfile: filename /Users/username/.ssh/known_hosts2 > debug3: check_host_in_hostfile: match line 1 > debug1: Host 'waltst2' is known and matches the RSA host key. > debug1: Found key in /Users/username/.ssh/known_hosts2:1 > debug1: bits set: 504/1024 > 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 > c3d1 40e3 72fe 1038 891d c922 c2c0 0fe1 > > Disconnecting: Bad packet length -1009696541. > debug1: Calling cleanup 0x17d1c(0x0) > debug1: Calling cleanup 0x14c70(0x0) > debug1: writing PRNG seed to file /Users/username/.ssh/prng_seed From dwd at bell-labs.com Wed Jul 11 06:14:51 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 10 Jul 2001 15:14:51 -0500 Subject: password expiry/changing In-Reply-To: ; from djm@mindrot.org on Sat, Jul 07, 2001 at 06:52:01PM +1000 References: Message-ID: <20010710151451.A7162@lucent.com> On Sat, Jul 07, 2001 at 06:52:01PM +1000, Damien Miller wrote: > On Thu, 5 Jul 2001, Jon Nathan wrote: > > > hi, > > > > does openssh have support for letting the user change his expired > > password? we are using password aging on solaris 6. our current > > build of openssh 2.5.2p2 asks for the password 3 times, then > > disconnects the user without allowing him to log in or change it. if > > not, are there any workarounds (other than root resetting the user's > > password manually). > > There is code to change the password through PAM. You need to configure > with --with-pam Or see my patch against 2.9p2 and the current CVS in the thread starting http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99289862107575&w=2 - Dave Dykstra From jtlayton at bigfoot.com Wed Jul 11 22:35:44 2001 From: jtlayton at bigfoot.com (Jeff Layton) Date: Wed, 11 Jul 2001 08:35:44 -0400 (EDT) Subject: strange scp error on HPUX 11 Message-ID: Hi, I recently built openssh 2.9p2 on HP-UX 11 using GCC-3.0. ssh seems to work fine, but scp gives the following error whenever I try to use it (some names changed to protect the guilty). It seems to treat the first argument as a hostname no matter whether it is or not. Any perfectly legal scp invocation gives the same error (with the first argument as the offending hostname). Anyone else seeing this problem? dilly at gauss:~/src$ scp -v bison-1.28.tar.gz hoohoo at foo.bar.baz:/tmp OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /opt/openssh/etc/ssh_config debug1: Applying options for * debug1: Seeded RNG with 24 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 501 geteuid 501 anon 1 scp: bison-1.28.tar.gz: no address associated with hostname. debug1: Calling cleanup 0x4000b102(0x0) debug1: writing PRNG seed to file /home/dilly/.ssh/prng_seed dilly at gauss:~/src$ -- Jeff Layton (jtlayton at bigfoot.com) "Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs." -- Larry Wall From djm at mindrot.org Wed Jul 11 22:44:01 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Jul 2001 22:44:01 +1000 (EST) Subject: strange scp error on HPUX 11 In-Reply-To: Message-ID: On Wed, 11 Jul 2001, Jeff Layton wrote: > Hi, > I recently built openssh 2.9p2 on HP-UX 11 using GCC-3.0. ssh seems to > work fine, but scp gives the following error whenever I try to use it > (some names changed to protect the guilty). It seems to treat the first > argument as a hostname no matter whether it is or not. Any > perfectly legal scp invocation gives the same error (with the > first argument as the offending hostname). Anyone else seeing this > problem? Bizarre - can you try instumenting the colon() function in misc.c with printfs to see if, where and why it is returning a non-zero value? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From luijten at ipst.umd.edu Wed Jul 11 22:49:23 2001 From: luijten at ipst.umd.edu (Erik Luijten) Date: Wed, 11 Jul 2001 08:49:23 -0400 (EDT) Subject: Regarding hanging of ssh upon exit Message-ID: Hi, I would like to briefly comment on a problem mentioned in the file "TODO" and also in the OpenSSH FAQ (question 3.10), namely the hanging of an ssh connection (on Linux) if there are active processes. It is stated that this has to do with the fact that children of the shell are not killed upon exiting the shell. However, the problem also occurs if a process is started with 'nohup'. This is very annoying, because it is not uncommon to connect to a remote machine, start a lengthy computation with 'nohup' and then exit. My point now is the following: a) the workaround in the FAQ seems useless: after all one doesn't want the new process to be killed. b) the "TODO" file states "All current solutions break scp or leave processes hanging around after the ssh connection has ended." But the latter is exactly what one wants in the case of a nohup process. So wouldn't it be possible to implement one of these "current solutions" for this situation? Many thanks (comments welcome!), Erik Luijten Erik Luijten | Institute for Physical Science & Technology luijten at ipst.umd.edu | University of Maryland Tel: +1-301-405-4821 | College Park, MD 20742-2431, U.S.A. Fax: +1-301-314-9404 | http://pallas.umd.edu/~luijten * After August 17, 2001: MSE/Urbana-Champaign - luijten at uiuc.edu * From jtlayton at bigfoot.com Wed Jul 11 23:16:34 2001 From: jtlayton at bigfoot.com (Jeff Layton) Date: Wed, 11 Jul 2001 09:16:34 -0400 (EDT) Subject: strange scp error on HPUX 11 In-Reply-To: Message-ID: Oops -- my bad...I had accidentally symlinked scp to ssh instead which was generating the error. Sorry for the false alarm! -- Jeff Layton (jtlayton at bigfoot.com) "Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs." -- Larry Wall On Wed, 11 Jul 2001, Damien Miller wrote: > On Wed, 11 Jul 2001, Jeff Layton wrote: > > > Hi, > > I recently built openssh 2.9p2 on HP-UX 11 using GCC-3.0. ssh seems to > > work fine, but scp gives the following error whenever I try to use it > > (some names changed to protect the guilty). It seems to treat the first > > argument as a hostname no matter whether it is or not. Any > > perfectly legal scp invocation gives the same error (with the > > first argument as the offending hostname). Anyone else seeing this > > problem? > > Bizarre - can you try instumenting the colon() function in misc.c with > printfs to see if, where and why it is returning a non-zero value? > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > > From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jul 12 01:22:12 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 11 Jul 2001 17:22:12 +0200 Subject: Regarding hanging of ssh upon exit In-Reply-To: ; from luijten@ipst.umd.edu on Wed, Jul 11, 2001 at 08:49:23AM -0400 References: Message-ID: <20010711172212.B2912@ws01.aet.tu-cottbus.de> On Wed, Jul 11, 2001 at 08:49:23AM -0400, Erik Luijten wrote: > It is stated that this has to do with the fact that children of the shell > are not killed upon exiting the shell. However, the problem also occurs if > a process is started with 'nohup'. This is very annoying, because it is > not uncommon to connect to a remote machine, start a lengthy > computation with 'nohup' and then exit. My point now is the following: Based on someone else's statement and verified by my own observations (HP-UX): the hanging ssh connection is not caused by the child processes, but by the child processes still having file descriptors open. I have since then solved the problem by redirecting the file descriptors command > /dev/null 2>&1 etc etc Of course you may consider something different than /dev/null in order to catch the output... Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From eedalf at eed.ericsson.se Thu Jul 12 02:14:08 2001 From: eedalf at eed.ericsson.se (Alexander Farber (EED)) Date: Wed, 11 Jul 2001 18:14:08 +0200 Subject: Solaris 2.6: Undefined symbol seed_rng Message-ID: <3B4C7B50.31033292@eed.ericsson.se> Hi, I hope I'm not asking some FAQ, but I can't compile openssh-2.9p2 on maas34:openssh-2.9p2 {173} uname -a SunOS maas34 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-5_10 using: maas34:openssh-2.9p2 {174} gcc -v Reading specs from /opt/local/gcc-2.95.2/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs gcc version 2.95.2 19991024 (release) I get: maas34:openssh-2.9p2 {172} make gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto Undefined first referenced symbol in file seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) ld: fatal: Symbol referencing errors. No output written to ssh-keyscan collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `ssh-keyscan' I'm actually trying to compile a ssh for using with our SOCKS5-firewall. For that purpose I've compiled dante-1.1.10 and openssl-0.9.6a which both installed fine into my home-dir /home/eedalf. Thank you for any hints! Alex PS: Here's the full output: maas34:openssh-2.9p2 {167} make clean (cd openbsd-compat; /all/gnu/bin/make clean) rm -f *.o *.a core rm -f *.o *.a ssh sshd ssh-add ssh-keygen ssh-keyscan ssh-agent scp sftp-server sftp logintest config.cache config.log rm -f *.out core maas34:openssh-2.9p2 {168} env LDFLAGS="-L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib" CFLAGS=-I/opt/local/zlib-1.1.2/include ./configure --prefix=/home/eedalf --disable-suid-ssh creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc -I/opt/local/zlib-1.1.2/include -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib) works... yes checking whether the C compiler (gcc -I/opt/local/zlib-1.1.2/include -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking host system type... sparc-sun-solaris2.6 checking whether byte ordering is bigendian... yes checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD compatible install... ./install-sh -c checking for ar... /usr/ccs/bin/ar checking for perl5... /opt/local/bin/perl5 checking for ent... no checking for filepriv... no checking for bash... /opt/local/bin/bash checking for ksh... (cached) /opt/local/bin/bash checking for sh... (cached) /opt/local/bin/bash checking for login... /usr/bin/login checking for inline... inline checking for obsolete utmp and wtmp in solaris2.x... no checking for yp_match in -lnsl... yes checking for main in -lsocket... yes checking for innetgr in -lrpc... no checking for getspnam in -lgen... yes checking for deflate in -lz... yes checking for login in -lutil... no checking for regcomp... yes checking for strcasecmp... yes checking for utimes... yes checking for strftime... yes checking for bstring.h... no checking for crypt.h... yes checking for endian.h... no checking for floatingpoint.h... yes checking for getopt.h... no checking for glob.h... yes checking for lastlog.h... yes checking for limits.h... yes checking for login.h... no checking for login_cap.h... no checking for maillock.h... yes checking for netdb.h... yes checking for netgroup.h... no checking for netinet/in_systm.h... yes checking for paths.h... no checking for poll.h... yes checking for pty.h... no checking for regex.h... yes checking for shadow.h... yes checking for security/pam_appl.h... yes checking for sys/bitypes.h... no checking for sys/bsdtty.h... no checking for sys/cdefs.h... no checking for sys/poll.h... yes checking for sys/queue.h... no checking for sys/select.h... yes checking for sys/stat.h... yes checking for sys/stropts.h... yes checking for sys/sysmacros.h... yes checking for sys/time.h... yes checking for sys/ttcompat.h... yes checking for sys/un.h... yes checking for stddef.h... yes checking for time.h... yes checking for ttyent.h... no checking for usersec.h... no checking for util.h... no checking for utime.h... yes checking for utmp.h... yes checking for utmpx.h... yes checking for vis.h... no checking for GLOB_ALTDIRFUNC support... no checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... no 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 fchown... yes checking for fchmod... yes checking for freeaddrinfo... no checking for futimes... no checking for gai_strerror... no checking for getcwd... yes checking for getaddrinfo... no checking for getgrouplist... no checking for getnameinfo... no checking for getrlimit... yes checking for getrusage... yes checking for getttyent... no checking for getusershell... yes checking for glob... yes checking for inet_aton... no checking for inet_ntoa... yes checking for inet_ntop... no checking for innetgr... yes checking for login_getcapbool... no checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... no checking for on_exit... no checking for openpty... no checking for realpath... yes checking for rresvport_af... no checking for setdtablesize... no checking for setenv... no checking for setegid... yes checking for seteuid... yes checking for setlogin... no checking for setproctitle... yes checking for setresgid... no checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for sigvec... no checking for snprintf... yes checking for strerror... yes checking for strlcat... no checking for strlcpy... no checking for strmode... no checking for strsep... no checking for strtok_r... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for utimes... (cached) yes checking for vsnprintf... yes checking for vhangup... yes checking for vis... yes checking for waitpid... yes checking for _getpty... no checking for __b64_ntop... no checking for gettimeofday... yes checking for time... yes checking for libutil.h... no checking for login... no checking for logout... no checking for updwtmp... yes checking for logwtmp... no 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 login... (cached) no checking for login in -lbsd... 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... /home/eedalf checking for RSA support... yes checking size of char... 1 checking size of short int... 2 checking size of int... 4 checking size of long int... 4 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... no checking for u_int64_t types... no checking for uintXX_t types... yes checking for socklen_t... no 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... no checking for struct sockaddr_in6... no checking for struct in6_addr... no checking for struct addrinfo... no checking for struct timeval... yes checking for ut_host field in utmp.h... no checking for ut_host field in utmpx.h... yes checking for syslen field in utmpx.h... yes 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... no 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... no checking for ut_addr field in utmpx.h... no checking for ut_addr_v6 field in utmp.h... no checking for ut_addr_v6 field in utmpx.h... no checking for ut_exit field in utmp.h... yes checking for ut_time field in utmp.h... yes checking for ut_time field in utmpx.h... yes checking for ut_tv field in utmpx.h... yes checking for st_blksize in struct stat... yes checking for sun_len field in struct sockaddr_un... no checking for ss_family field in struct sockaddr_storage... no checking for __ss_family field in struct sockaddr_storage... no checking for pw_class field in struct passwd... no checking if libc defines __progname... yes checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes checking for rsh... /usr/ucb/rsh checking for xauth... /usr/openwin/bin/xauth checking for /dev/ptmx... yes checking for /dev/ptc... no checking for /dev/urandom... no checking for PRNGD/EGD socket... not found checking for ls... /usr/ucb/ls checking for netstat... /usr/ucb/netstat checking for arp... /usr/sbin/arp checking for ifconfig... /usr/sbin/ifconfig checking for ps... /usr/ucb/ps checking for w... /usr/ucb/w checking for who... /usr/bin/who checking for last... /usr/bin/last checking for lastlog... no checking for df... /usr/ucb/df checking for vmstat... /usr/ucb/vmstat checking for uptime... /usr/ucb/uptime checking for ipcs... /usr/bin/ipcs checking for tail... /usr/ucb/tail checking for nroff... /usr/bin/nroff checking if the systems has expire shadow information... yes Adding /home/eedalf/bin to USER_PATH so scp will work checking if we need to convert IPv4 in IPv6-mapped addresses... no (default) checking whether to install ssh as suid root... no checking if your system defines LASTLOG_FILE... no checking if your system defines _PATH_LASTLOG... no checking if your system defines UTMP_FILE... yes checking if your system defines WTMP_FILE... yes checking if your system defines UTMPX_FILE... yes checking if your system defines WTMPX_FILE... yes checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no updating cache ./config.cache creating ./config.status creating Makefile creating openbsd-compat/Makefile creating ssh_prng_cmds creating config.h config.h is unchanged OpenSSH has been configured with the following options: User binaries: /home/eedalf/bin System binaries: /home/eedalf/sbin Configuration files: /home/eedalf/etc Askpass program: /home/eedalf/libexec/ssh-askpass Manual pages: /home/eedalf/man/manX PID file: /home/eedalf/etc sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/home/eedalf/bin Random number collection: Builtin (timeout 200) Manpage format: man PAM support: no KerberosIV 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 Host: sparc-sun-solaris2.6 Compiler: gcc Compiler flags: -I/opt/local/zlib-1.1.2/include -Wall Preprocessor flags: -I/home/eedalf/include -I/usr/local/include Linker flags: -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib Libraries: -lz -lsocket -lnsl -lgen -lcrypto WARNING: you are using the builtin random number collection service. Please read WARNING.RNG and request that your OS vendor includes /dev/random in future versions of their OS. maas34:openssh-2.9p2 {169} make conffile=`echo sshd_config.out | sed 's/.out$//'`; \ /opt/local/bin/perl5 ./fixpaths -D/etc/ssh_config=/home/eedalf/etc/ssh_config -D/etc/ssh_known_hosts=/home/eedalf/etc/ssh_known_hosts -D/etc/sshd_config=/home/eedalf/etc/sshd_config -D/usr/libexec=/home/eedalf/libexec -D/etc/shosts.equiv=/home/eedalf/etc/shosts.equiv -D/etc/ssh_host_key=/home/eedalf/etc/ssh_host_key -D/etc/ssh_host_dsa_key=/home/eedalf/etc/ssh_host_dsa_key -D/etc/ssh_host_rsa_key=/home/eedalf/etc/ssh_host_rsa_key -D/var/run/sshd.pid=/home/eedalf/etc/sshd.pid -D/etc/primes=/home/eedalf/etc/primes -D/etc/sshrc=/home/eedalf/etc/sshrc -D/usr/X11R6/bin/xauth=/usr/openwin/bin/xauth -D/usr/bin:/bin:/usr/sbin:/sbin=/usr/bin:/bin:/usr/sbin:/sbin:/home/eedalf/bin ./${conffile} > sshd_config.out [...skipped...] gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c serverloop.c serverloop.c: In function `sigchld_handler': serverloop.c:107: warning: int format, pid_t arg (arg 2) serverloop.c:107: warning: int format, pid_t arg (arg 3) serverloop.c: In function `server_loop': serverloop.c:653: warning: int format, pid_t arg (arg 2) serverloop.c:653: warning: int format, pid_t arg (arg 3) gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c md5crypt.c gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c session.c session.c: In function `session_dump': session.c:1568: warning: int format, pid_t arg (arg 6) session.c: In function `session_by_pid': session.c:1609: warning: int format, pid_t arg (arg 2) session.c:1615: warning: int format, pid_t arg (arg 2) session.c: In function `session_exit_message': session.c:1896: warning: int format, pid_t arg (arg 4) session.c: In function `session_free': session.c:1937: warning: int format, pid_t arg (arg 3) session.c: In function `session_close_by_pid': session.c:1962: warning: int format, pid_t arg (arg 2) session.c: In function `session_close_by_channel': session.c:1986: warning: int format, pid_t arg (arg 3) session.c:1994: warning: int format, pid_t arg (arg 2) session.c: In function `session_proctitle': session.c:2023: warning: implicit declaration of function `setproctitle' gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c groupaccess.c 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 -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c ssh-add.c gcc -o ssh-add ssh-add.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c ssh-keygen.c gcc -o ssh-keygen ssh-keygen.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto gcc -I/opt/local/zlib-1.1.2/include -Wall -I. -I. -I/home/eedalf/include -I/usr/local/include -DETCDIR=\"/home/eedalf/etc\" -D_PATH_SSH_PROGRAM=\"/home/eedalf/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/eedalf/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/eedalf/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/home/eedalf/etc\" -DHAVE_CONFIG_H -c ssh-keyscan.c gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto Undefined first referenced symbol in file seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) ld: fatal: Symbol referencing errors. No output written to ssh-keyscan collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `ssh-keyscan' From J.S.Peatfield at damtp.cam.ac.uk Thu Jul 12 03:29:50 2001 From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk) Date: Wed, 11 Jul 2001 18:29:50 +0100 Subject: OpenSSL PRNG Message-ID: <200107111729.SAA22872.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Just for peace of mind, can someone who knows the openssh code better than I do, confirm that openssh doesn't use (in any circumstances) the openssl prng (since the code in versions prior to 0.9.6b is rather weak). My understanding is that it doesn't (using either /dev/random, egd, prngd or the builtin code), but I may have missed some other use of the openssl prng elsewhere... -- Jon From vinschen at redhat.com Thu Jul 12 03:50:12 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 11 Jul 2001 19:50:12 +0200 Subject: RFD: uid of privileged user not fixed to 0 Message-ID: <20010711195012.H29127@cygbert.vinschen.de> Hi, I don't know if other systems are concerned as well but it's at least a problem for Cygwin that the uid of the privileged user is fixed to the constant 0 in the OpenSSH sources. A month ago I ported Paul Vixie's cron to Cygwin and he's using at least a define for that: #define ROOT_UID 0 which simplified the porting vastly. May I propose to change the usage of uid 0 in the sources to become substituted by a define as above which would allow to configure that for different systems which doesn't neccessarily have the uid 0 and a root user at all? Instead of constant (and badly portable) comparisons like if (st.st_uid == 0) we could use something like if (is_root(st.st_uid)) which would allow macros like the following on Unices: #define ROOT_UID 0 #define is_root(x) ((x) == ROOT_UID) and other definitions on other systems: #define ROOT_UID 18 /* "SYSTEM" account on NT/W2K */ and even functions: #define is_root(x) wierd_system_is_root(x) extern int wierd_system_is_root(uid_t); Is there any problem to do so? Since that change isn't messing anything up (IMO) it should be no problem to apply that already to the OpenBSD base sources of OpenSSH. Any comments (besides flaming on Windows)? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From Darren.Moffat at eng.sun.com Thu Jul 12 04:35:18 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 11 Jul 2001 11:35:18 -0700 (PDT) Subject: RFD: uid of privileged user not fixed to 0 Message-ID: <200107111836.f6BIaAN449395@jurassic.eng.sun.com> I support the idea in general. >I don't know if other systems are concerned as well but it's at least >a problem for Cygwin that the uid of the privileged user is fixed to >the constant 0 in the OpenSSH sources. Other systems I can think of are systems that use fine grained privileges rather than uid 0 to determine access - but those systems are likely to have their own additional source modifications as well. (I'm thinking of things like Trusted {Solaris, BSD}, DEC MLS). >we could use something like > > if (is_root(st.st_uid)) What about using suser() which is what is used in many kernels to do the uid 0 check ? suser() on Solaris only exists in kernel space (and is actualy a function since it has auditing and accounting side effects) but the macro you would use in userland is just as you described for is_root(). -- Darren J Moffat From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jul 12 05:59:08 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 11 Jul 2001 21:59:08 +0200 Subject: OpenSSL PRNG In-Reply-To: <200107111729.SAA22872.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>; from J.S.Peatfield@damtp.cam.ac.uk on Wed, Jul 11, 2001 at 06:29:50PM +0100 References: <200107111729.SAA22872.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Message-ID: <20010711215908.B6454@serv01.aet.tu-cottbus.de> On Wed, Jul 11, 2001 at 06:29:50PM +0100, J.S.Peatfield at damtp.cam.ac.uk wrote: > Just for peace of mind, can someone who knows the openssh code better than > I do, confirm that openssh doesn't use (in any circumstances) the openssl > prng (since the code in versions prior to 0.9.6b is rather weak). > > My understanding is that it doesn't (using either /dev/random, egd, prngd or > the builtin code), but I may have missed some other use of the openssl prng > elsewhere... Nobody of the OpenSSH team did speak up until know. Probably they are busy checking things out :-) OpenSSH does use the cryptographic routines of OpenSSL so it also uses the OpenSSL PRNG. /dev/random etc are used as sources to seed this internal PRNG. Now for the weakness: due to the way the "random bytes" were retrieved, an attacker might have accessed the internal state of the PRNG and starting from that point predict new random numbers. For this to work, the attacker would need to retrieve "random bytes" bytes in very small chunks (down to 1 byte) and he would need 1024bytes of it. (Technical details are in the Announcement.) Any protocol, that does only retrieve random bytes in larger quantities is not vulnerable. Therefore programs using the SSL layer of OpenSSL are not vulnerable, as session keys, session ids etc all are built from larger numbers of random bytes. As new keys are generated for each session, the pool will be mixed in between and therefore even if an attacker could get the one single byte in each attempt, it would not help him due to the mixing. I did not analyze the SSH protocol into detail, but I as far as I see keys are always generated with a certain minimum length, effectively preventing the problem. Additionally: for each new connection, a new ssh process is started (having its own entropy pool) or sshd spawned (with entropy pool being different, as the pid is mixed in). sshd is reseeded in between, also an effective counter measure. Not officially speaking for the OpenSSL TEAM. For the official statement, please read the announcement that was agreed upon before :-) In the announcement we wrote: "No applications is known to us which is actually vulnerable." And we meant it that way, seriously. I do use OpenSSH. Probably most of the OpenSSL team members do use OpenSSH. Maybe all use it :-) Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From vinschen at redhat.com Thu Jul 12 06:37:54 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 11 Jul 2001 22:37:54 +0200 Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password Message-ID: <20010711223754.D29492@cygbert.vinschen.de> Hi, the following patch checks if OpenSSH is running under a Cygwin version >= 1.3.2 which allows switching user context without password. Otherwise sshd allows changing the user context only if password authentication is used as it was before. Corinna Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.4 diff -u -p -r1.4 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 2001/04/13 14:28:42 1.4 +++ openbsd-compat/bsd-cygwin_util.c 2001/07/11 20:35:40 @@ -21,10 +21,14 @@ RCSID("$Id: bsd-cygwin_util.c,v 1.4 2001 #include #include +#include #include #include #define is_winnt (GetVersion() < 0x80000000) +#define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) +#define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) + #if defined(open) && open == binary_open # undef open #endif @@ -61,12 +65,34 @@ int check_nt_auth(int pwd_authenticated, * context on NT systems is the password authentication. So * we deny all requsts for changing the user context if another * authentication method is used. - * This may change in future when a special openssh - * subauthentication package is available. + * + * This doesn't apply to Cygwin versions >= 1.3.2 anymore which + * uses the undocumented NtCreateToken() call to create a user + * token if the process has the appropriate privileges and if + * CYGWIN ntsec setting is on. */ - if (is_winnt && !pwd_authenticated && geteuid() != uid) - return 0; - + static int has_create_token = -1; + + if (is_winnt) { + if (has_create_token < 0) { + struct utsname uts; + int major_high = 0, major_low = 0, minor = 0; + char *cygwin = getenv("CYGWIN"); + + has_create_token = 0; + if (ntsec_on(cygwin) && !uname(&uts)) { + sscanf(uts.release, "%d.%d.%d", + &major_high, &major_low, &minor); + if (major_high > 1 || + (major_high == 1 && (major_low > 3 || + (major_low == 3 && minor >= 2)))) + has_create_token = 1; + } + } + if (has_create_token < 1 && + !pwd_authenticated && geteuid() != uid) + return 0; + } return 1; } @@ -82,12 +108,9 @@ int check_ntsec(const char *filename) return 0; /* Evaluate current CYGWIN settings. */ - if ((cygwin = getenv("CYGWIN")) != NULL) { - if (strstr(cygwin, "ntea") && !strstr(cygwin, "nontea")) - allow_ntea = 1; - if (strstr(cygwin, "ntsec") && !strstr(cygwin, "nontsec")) - allow_ntsec = 1; - } + cygwin = getenv("CYGWIN"); + allow_ntea = ntea_on(cygwin); + allow_ntsec = ntsec_on(cygwin); /* * `ntea' is an emulation of POSIX attributes. It doesn't support -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Thu Jul 12 06:42:43 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 11 Jul 2001 22:42:43 +0200 Subject: [PATCH]: Cygwin: Changes to cygwin contrib area Message-ID: <20010711224243.E29492@cygbert.vinschen.de> Hi, the following patch changes two files in the contrib/cygwin subdir: It changes the Cygwin specific README file which adds some hints related to the new feature to switch user context without password (which means using public key and/or rhosts authentication). Some old stuff is erased. The changes to ssh-host-config are intended to allow an easier startup for users which are new to Cygwin and/or OpenSSH. Corinna Index: contrib/cygwin/README =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v retrieving revision 1.5 diff -u -p -r1.5 README --- contrib/cygwin/README 2001/05/03 22:45:22 1.5 +++ contrib/cygwin/README 2001/07/11 20:40:02 @@ -1,6 +1,15 @@ -This package is the actual port of OpenSSH to Cygwin 1.1. +This package is the actual port of OpenSSH to Cygwin 1.3. =========================================================================== +Important change since 2.9p2: + +Since Cygwin is able to switch user context without password beginning +with version 1.3.2, OpenSSH now allows to do so when it's running under +a version >= 1.3.2. Keep in mind that `ntsec' has to be activated to +allow that feature. +=========================================================================== + +=========================================================================== Important change since 2.3.0p1: When using `ntea' or `ntsec' you now have to care for the ownership @@ -37,6 +46,9 @@ Options: --no -n Answer all questions with "no" automatically. --port -p sshd listens on port n. +Additionally ssh-host-config now asks if it should install sshd as a +service when running under NT/W2K. This requires cygrunsrv installed. + You can create the private and public keys for a user now by running /usr/bin/ssh-user-config @@ -53,16 +65,12 @@ Options: --no -n Answer all questions with "no" automatically. --passphrase -p word Use "word" as passphrase automatically. -Install sshd as daemon via SRVANY.EXE (recommended on NT/W2K), via inetd +Install sshd as daemon via cygrunsrv.exe (recommended on NT/W2K), via inetd (results in very slow deamon startup!) or from the command line (recommended on 9X/ME). -If you start sshd as deamon via SRVANY.EXE you will see two -sshd processes in the process list unless you give the "-D" -option to sshd. That will avoid that sshd detaches from the -controlling terminal and it will remain under process control -of SRVANY.EXE. That allows easy killing of the service by -using the `net stop ' command. +If you start sshd as deamon via cygrunsrv.exe you MUST give the +"-D" option to sshd. Otherwise the service can't get started at all. If starting via inetd, copy sshd to eg. /usr/sbin/in.sshd and add the following line to your inetd.conf file: @@ -74,6 +82,10 @@ ${SYSTEMROOT}/system32/drivers/etc/servi sshd 22/tcp #SSH daemon +=========================================================================== +The following restrictions only apply to Cygwin versions up to 1.3.1 +=========================================================================== + Authentication to sshd is possible in one of two ways. You'll have to decide before starting sshd! @@ -145,26 +157,22 @@ way as they are used by the `login' port SSH2 server and user keys are generated by the `ssh-*-config' scripts as well. -SSH2 authentication similar to SSH1: - Add keys to ~/.ssh/authorized_keys2 -Interop. w/ ssh.com dsa-keys: - ssh-keygen -f /key/from/ssh.com -X >> ~/.ssh/authorized_keys2 -and vice versa: - ssh-keygen -f /privatekey/from/openssh -x > ~/.ssh2/mykey.pub - echo Key mykey.pub >> ~/.ssh2/authorization - If you want to build from source, the following options to configure are used for the Cygwin binary distribution: ---prefix=/usr --sysconfdir=/etc --libexecdir='${exec_prefix}/sbin + --prefix=/usr \ + --sysconfdir=/etc \ + --libexecdir='${exec_prefix}/sbin \ + --with-pcre You must have installed the zlib, openssl and regex packages to -be able to build OpenSSH! +be able to build OpenSSH! The `--with-pcre' option requires +the installation of the pcre package. -Please send requests, error reports etc. to cygwin at sources.redhat.com. +Please send requests, error reports etc. to cygwin at cygwin.com. Have fun, -Corinna Vinschen +Corinna Vinschen Cygwin Developer Red Hat Inc. Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.2 diff -u -p -r1.2 ssh-host-config --- contrib/cygwin/ssh-host-config 2001/03/07 10:38:19 1.2 +++ contrib/cygwin/ssh-host-config 2001/07/11 20:40:03 @@ -309,7 +309,13 @@ PermitRootLogin yes IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes -StrictModes yes + +# +# The following setting overrides permission checks on host key files +# and directories. For security reasons set this to "yes" when running +# NT/W2K, NTFS and CYGWIN=ntsec. +StrictModes no + X11Forwarding no X11DisplayOffset 10 PrintMotd yes @@ -325,12 +331,9 @@ RhostsAuthentication no # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no -# To install for logon to different user accounts change to "no" here RSAAuthentication yes -# To install for logon to different user accounts change to "yes" here -PasswordAuthentication no - +PasswordAuthentication yes PermitEmptyPasswords no CheckMail no @@ -435,6 +438,48 @@ then echo '# ssh stream tcp nowait root /usr/sbin/sshd -i' >> "${_inetcnf}" fi echo "Added ssh to ${_inetcnf}" + fi +fi + +# Create /var/log and /var/log/lastlog if not already existing + +if [ -f /var/log ] +then + echo "Creating /var/log failed\!" +else + if [ ! -d /var/log ] + then + mkdir /var/log + fi + if [ -d /var/log/lastlog ] + then + echo "Creating /var/log/lastlog failed\!" + elif [ ! -f /var/log/lastlog ] + then + cat /dev/null > /var/log/lastlog + fi +fi + +# On NT ask if sshd should be installed as service +if [ $_nt -gt 0 ] +then + echo + echo "Do you want to install sshd as service?" + if request "(Say \"no\" if it's already installed as service)" + then + echo + echo "Which value should the environment variable CYGWIN have when" + echo "sshd starts? It's recommended to set at least \"ntsec\" to be" + echo "able to change user context without password." + echo -n "Default is \"binmode ntsec tty\". CYGWIN=" + read _cygwin + [ -z "${_cygwin}" ] && _cygwin="binmode ntsec tty" + if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=${_cygwin}" + then + chown system /etc/ssh* + echo + echo "The service has been installed under LocalSystem account." + fi fi fi -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Thu Jul 12 10:01:02 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Jul 2001 10:01:02 +1000 (EST) Subject: OpenSSL PRNG In-Reply-To: <20010711215908.B6454@serv01.aet.tu-cottbus.de> Message-ID: On Wed, 11 Jul 2001, Lutz Jaenicke wrote: > Nobody of the OpenSSH team did speak up until know. Probably they are busy > checking things out :-) As I read it we are not vulnerable. We take random bytes in 32 bytes chunks, rather than the 1 byte reads that the advisory warns against. Apart from OpenSSL's internal use of the of the PRNG (for creating keys, etc), OpenSSH mainly uses the PRNG to seed a second RC4-based PRNG. This RC4-based PRNG implements OpenBSD's arc4random function for systems that lack it (which is unfortunately most other OSs). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jones at mail.utexas.edu Thu Jul 12 11:10:22 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Wed, 11 Jul 2001 20:10:22 -0500 Subject: Need a little advice! Message-ID: I am working on a modest to port openssh to CRAY T3Es and SV1s. I am fairly close to finishing the patches. Most of the patches a fairly strait forward but I did one thing that I need some direction on. I created a source file in openbsd-compat called cray.c. It contains most of the code to support a cray. I guess I could of stuck it into session.c but I felt that session.c is already getting cluttered. Before I generate my patch I wanted to check and see I their would be any objection to this new file in openbsd-compat. Bill Jones From mouring at etoh.eviladmin.org Thu Jul 12 11:15:29 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 11 Jul 2001 20:15:29 -0500 (CDT) Subject: Need a little advice! In-Reply-To: Message-ID: On Wed, 11 Jul 2001, William L. Jones wrote: > > I am working on a modest to port openssh to CRAY T3Es and SV1s. I am > fairly close to finishing the patches. Most of the patches a fairly > strait forward but I did one thing that I need some direction on. I > created > a source file in openbsd-compat called cray.c. It contains most of the code > to support a cray. I guess I could of stuck it into session.c but I felt > that session.c is already getting cluttered. > > Before I generate my patch I wanted to check and see I their would be > any objection to this new file in openbsd-compat. > I would perfer functions that are required for a port to work to be in openbsd-compat/. Ensure that you attempt to keep your #if/#else/#end to a *BARE* miminal. We already have 3x as many #if/#endif in portable as that is in the upstream source. And it slowly makes it harder to sync the trees. - Ben From drosih at rpi.edu Thu Jul 12 11:36:14 2001 From: drosih at rpi.edu (Garance A Drosihn) Date: Wed, 11 Jul 2001 21:36:14 -0400 Subject: Need a little advice! In-Reply-To: References: Message-ID: At 8:15 PM -0500 7/11/01, wrote: >On Wed, 11 Jul 2001, William L. Jones wrote: > > ... I created a source file in openbsd-compat called cray.c. > > It contains most of the code to support a cray. I guess I > > could of stuck it into session.c but I felt that session.c is > > already getting cluttered. > >I would perfer functions that are required for a port to work to be in >openbsd-compat/. Ensure that you attempt to keep your #if/#else/#end to a >*BARE* miminal. By this do you mean you'd rather they were in openbsd-compat/session.c ? He already said cray.c was intended for directory openbsd-compat. -- Garance Alistair Drosehn = gad at eclipse.acs.rpi.edu Senior Systems Programmer or gad at freebsd.org Rensselaer Polytechnic Institute or drosih at rpi.edu From mouring at etoh.eviladmin.org Thu Jul 12 11:27:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 11 Jul 2001 20:27:07 -0500 (CDT) Subject: Need a little advice! In-Reply-To: Message-ID: On Wed, 11 Jul 2001, Garance A Drosihn wrote: > At 8:15 PM -0500 7/11/01, wrote: > >On Wed, 11 Jul 2001, William L. Jones wrote: > > > ... I created a source file in openbsd-compat called cray.c. > > > It contains most of the code to support a cray. I guess I > > > could of stuck it into session.c but I felt that session.c is > > > already getting cluttered. > > > >I would perfer functions that are required for a port to work to be in > >openbsd-compat/. Ensure that you attempt to keep your #if/#else/#end to a > >*BARE* miminal. > > By this do you mean you'd rather they were in openbsd-compat/session.c ? > He already said cray.c was intended for directory openbsd-compat. > He stated "I guess I could of stuck it into session.c but I felt that session.c is already getting cluttered." Which he is correct. openbsd-compat/bsd-cray.[ch] technically should be the name of it since all bsd-*.[ch] are non-OpenBSD code. - Ben From jones at tacc.utexas.edu Thu Jul 12 14:44:41 2001 From: jones at tacc.utexas.edu (William L. Jones) Date: Wed, 11 Jul 2001 23:44:41 -0500 Subject: Port of RIJNDAEL to cray machines! Message-ID: <001601c10a8d$7e15a9e0$0202a8c0@austin.rr.com> Is their a port of RIJNDAEL for the crays? The code in openssh does not work on cray's. Bill Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010711/59803796/attachment.html From bowman at math.ualberta.ca Thu Jul 12 16:08:44 2001 From: bowman at math.ualberta.ca (John Bowman) Date: 12 Jul 2001 06:08:44 -0000 Subject: Regarding hanging of ssh upon exit Message-ID: <20010712060844.9982.qmail@wizard.math.ualberta.ca> > a) the workaround in the FAQ seems useless: after all one doesn't want > the new process to be killed. Agreed. > b) the "TODO" file states "All current solutions break scp or leave > processes hanging around after the ssh connection has ended." > But the latter is exactly what one wants in the case of a nohup > process. So wouldn't it be possible to implement one of these "current > solutions" for this situation? Yes, such a patch already exists for Linux: http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta From wgriffin at tislabs.com Fri Jul 13 01:22:41 2001 From: wgriffin at tislabs.com (Wesley Griffin) Date: Thu, 12 Jul 2001 11:22:41 -0400 Subject: Updated DNSSEC patch Message-ID: <20010712112239.B1000@tislabs.com> I've updated my DNSSEC patch, available at ftp://ftp.tislabs.com/pub/fmeshd as openssh.[portable,openbsd].patch.20010712 The updates include a fix to correctly handle failure of the lookup methods and a new option to ssh-keygen to output the DNS format of the key. Both were supplied by Jakob Schlyter. I've also updated the style to conform better to openbsd's style(9). -- Wesley Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From qralston+ml.openssh-unix-dev at andrew.cmu.edu Fri Jul 13 05:43:26 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Thu, 12 Jul 2001 15:43:26 -0400 (EDT) Subject: Xauthority location: only per-user setting possible In-Reply-To: <20010709171851.B18595@zax.half.pint-stowp.cx> Message-ID: On Mon, 9 Jul 2001, Jim Knoble wrote: > This would probably work better: > > xauth -q -f "${XAUTHORITY}" - < add ${DISPLAY} ${proto} ${cookie} > EOF > [ $? -eq 0 ] || exit 1 > > Using the here-document keeps things from appearing in ps no matter > what kind of system you've got. Yes, that it would. (I was more interested in banging off the example and sending my message than pondering the Right Way to do it. ;) I kinda disappointed that no one else followed-up to my suggestion, though: } The quickest solution is to simply add back in the } xauth-cookie-in-tmp handling stuff, and make sure that } xauthfile_cleanup_proc uses temporarily_use_uid(). I've come up } with a patch against 2.9p2 to do exactly that, although I haven't } tested it. } } I think a better solution (and one more in tune with the desires of } the OpenSSH maintainers) would be to have OpenSSH capture the stdout } of $HOME/.ssh/rc and process it in exactly the same way as } $HOME/.ssh/environment. Am I the only one (besides Pekka Savola) who cares that 2.9p2 broke the ability to store one's Xauthority file outside of one's home directory? -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From eedalf at eed.ericsson.se Fri Jul 13 21:14:54 2001 From: eedalf at eed.ericsson.se (Alexander Farber (EED)) Date: Fri, 13 Jul 2001 13:14:54 +0200 Subject: Solaris 2.6: Undefined symbol seed_rng - solution (-lssh -lopenbsd-compat -lssh) Message-ID: <3B4ED82E.348730C9@eed.ericsson.se> Hi, > maas34:openssh-2.9p2 {172} make > gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto > Undefined first referenced > symbol in file > seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) > ld: fatal: Symbol referencing errors. No output written to ssh-keyscan > collect2: ld returned 1 exit status > *** Error code 1 > make: Fatal error: Command failed for target `ssh-keyscan' I haven't got any replies from this list, but an ingenious colleague of me has helped: the solution is to use "-lssh" twice (and I had to use it for the ssh, sftp-server, sftp and scp binaries): maas34:openssh-2.9p2 {181} gcc -o ssh-keyscan ssh-keyscan.o -L. -Lopenbsd-compat/ \ ? -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks \ ? -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh \ ? -lopenbsd-compat -lssh -lz -lsocket -lnsl -lgen -lcrypto gcc -o scp scp.o scp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto Undefined first referenced symbol in file seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) ld: fatal: Symbol referencing errors. No output written to scp collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `scp' maas34:openssh-2.9p2 {183} gcc -o scp scp.o scp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lssh -lz -lsocket -lnsl -lgen -lcrypto gcc -o sftp-server sftp-server.o sftp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto Undefined first referenced symbol in file seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) ld: fatal: Symbol referencing errors. No output written to sftp-server collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sftp-server' maas34:openssh-2.9p2 {185} gcc -o sftp-server sftp-server.o sftp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lssh -lz -lsocket -lnsl -lgen -lcrypto gcc -o sftp sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o scp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lgen -lcrypto Undefined first referenced symbol in file seed_rng openbsd-compat//libopenbsd-compat.a(bsd-arc4random.o) ld: fatal: Symbol referencing errors. No output written to sftp collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sftp' maas34:openssh-2.9p2 {187} gcc -o sftp sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o scp-common.o -L. -Lopenbsd-compat/ -R/home/eedalf/lib -L/home/eedalf/lib -L/home/eedalf/lib -ldsocks -L/opt/local/zlib-1.1.2/lib -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lssh -lz -lsocket -lnsl -lgen -lcrypto Regards Alex From OomKoos1 at cs.com Sat Jul 14 00:32:20 2001 From: OomKoos1 at cs.com (OomKoos1 at cs.com) Date: Fri, 13 Jul 2001 10:32:20 EDT Subject: --without-gssapi ? Message-ID: <7b.177da317.28806074@cs.com> Is there a ./configure argument to turn off gssapi authentication for openssh-2.5.2p2? Best Herman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010713/fd511d47/attachment.html From simon at sxw.org.uk Sat Jul 14 03:57:52 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Fri, 13 Jul 2001 18:57:52 +0100 Subject: --without-gssapi ? In-Reply-To: <7b.177da317.28806074@cs.com> References: <7b.177da317.28806074@cs.com> Message-ID: <01071318575307.05066@loki.dcs.ed.ac.uk> On Friday 13 July 2001 15:32, OomKoos1 at cs.com wrote: > > Is there a ./configure argument to turn off gssapi authentication for > openssh-2.5.2p2? Don't install the patch? :-) Alternatively --without-kerberos5 will disable it (but at the expense of the kerberos v5 stuff if you're wanting to use that). There's no specific configure option to disable just the protocol v2 GSSAPI stuff. Cheers, Simon -- Simon Wilkinson http://www.sxw.org.uk "The issue is not whether you are paranoid, the issue is whether you are paranoid enough." - Strange Days From rudeyak at yahoo.com Sat Jul 14 07:05:59 2001 From: rudeyak at yahoo.com (Rude Yak) Date: Fri, 13 Jul 2001 14:05:59 -0700 (PDT) Subject: terminal hangs on solaris Message-ID: <20010713210559.94830.qmail@web13303.mail.yahoo.com> Every once in a while, my terminal session with an OpenSSH server (any version, up to and including 2.9p2) will hang indefinitely upon logout, rather than returning to the shell on my UNIX client machine (or closing the window, if in a M$ environment). Unfortunately, I can't reproduce the problem, but it does occur frequently enough to be annoying. When it does happen, this is what I see on the server system (by logging in from a different terminal and tracking down the hung-out-to-dry process): # pstack 3296 3296: /usr/local/sbin/sshd -f /etc/sshd_config ef5b7488 poll (efffd160, 2, 64) ef5cd064 select (efffd170, ef6266cc, 11e8d0, ef6266d0, 11e8d4, 11) + 280 00034560 wait_until_can_do_something (effff24c, effff248, effff244, 64, 4, 1) + 2b8 00034d74 server_loop (fb000, 0, 104000, fb000, 104000, effff240) + 20c 00036c7c do_exec_pty (10bbcc, 11, 36634, fb400, 8a, 0) + 260 00036704 do_authenticated1 (0, 36400, fac00, 106800, ef623700, 36014) + 60c 00036074 do_authenticated (110fa8, efffefbc, d0710, 400, efffefc8, 0) + 80 0002d720 do_authentication (effff418, 3, fac00, cfc00, fb000, 10e400) + 174 0002c17c main (1eb4, f, 1, fac00, 1eb4, 10c498) + 1418 0002a27c _start (0, 0, 0, 0, 0, 0) + 5c # truss -p 3296 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 poll(0xEFFFD160, 2, 100) = 0 Has anyone else seen this issue? It's mostly a nuisance, but I am struggling to figure out exactly what causes it. I've been able to "gcore" the running process, and a gdb "bt" basically shows the same thing as pstack above. Sadly, this is the extent of what I know to do in gdb :-) Thanks in advance. RudeYak at yahoo.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From wgriffin at tislabs.com Sat Jul 14 10:54:56 2001 From: wgriffin at tislabs.com (Wesley Griffin) Date: Fri, 13 Jul 2001 20:54:56 -0400 Subject: DNSSEC patch updated to -current Message-ID: <20010713205455.A1263@tislabs.com> I've updated my patch to portable-current. Its available at ftp://ftp.tislabs.com/pub/fmeshd as openssh_cvs.20010713 -- Wesley Griffin NAI Labs wgriffin at tislabs.com 443.259.2388 From djm at mindrot.org Sat Jul 14 12:06:23 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 14 Jul 2001 12:06:23 +1000 (EST) Subject: --without-gssapi ? In-Reply-To: <7b.177da317.28806074@cs.com> Message-ID: On Fri, 13 Jul 2001 OomKoos1 at cs.com wrote: > Is there a ./configure argument to turn off gssapi authentication for > openssh-2.5.2p2? No, but since OpenSSH doesn't support gssapi auth without additional patches, I don't think you need to worry :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From jdlarios at cac.washington.edu Fri Jul 6 10:40:04 2001 From: jdlarios at cac.washington.edu (Josh Larios) Date: Thu, 05 Jul 2001 17:40:04 -0700 Subject: OpenSSH bug in MacOS X Message-ID: <46260000.994380004@D-128-208-94-129.dhcp2.washington.edu> In MacOS X 10.0.4, and probably other versions, getaddrinfo() is broken in such a way that when you try to connect to certain hosts, openssh fails. getaddrinfo is first failing the lookup, and then failing to return with an error code when it does fail. I've found that if you define BROKEN_GETADDRINFO for OS X, it compiles and runs just fine. This patch against configure works for me: --- configure.old Sat Jun 16 21:09:50 2001 +++ configure Thu Jul 5 17:04:28 2001 @@ -1498,6 +1498,11 @@ # Check for some target-specific stuff case "$host" in +*-*-darwin*) + cat >> confdefs.h <<\EOF +#define BROKEN_GETADDRINFO 1 +EOF + ;; *-*-aix*) AFS_LIBS="-lld" CPPFLAGS="$CPPFL I hope you're the right folks to be reporting this to. Yours, -- Josh Larios Computing & Communications Client Services University of Washington Box 352830 Seattle, WA 98195-2830 jdlarios at cac.washington.edu From slade at shore.net Mon Jul 16 11:06:44 2001 From: slade at shore.net (Richard E. Silverman) Date: Sun, 15 Jul 2001 21:06:44 -0400 Subject: terminal hangs on solaris Message-ID: <200107160106.VAA24444@syrinx.oankali.net> Rude Yak writes: > Every once in a while, my terminal session with an OpenSSH server (any > version, up to and including 2.9p2) will hang indefinitely upon logout, ... It's likely that when this happens, it's because you have started a background process from that shell which has not closed its stdout/stderr streams. sshd waits to receive eof on the pipes to the shell's stdout/stderr before exiting, and that can't happen until all references to those pipes are closed. When you start a background process that you want to continue after you end the SSH connection, be sure to redirect its stdout/stderr. - Richard From slade at shore.net Mon Jul 16 12:37:12 2001 From: slade at shore.net (Richard E. Silverman) Date: Sun, 15 Jul 2001 22:37:12 -0400 Subject: client side options -- KeyRegenerationInterval Message-ID: <200107160237.WAA25325@syrinx.oankali.net> The SSH-1 protocol does not provide for negotiation of the server key replacement interval; it is a purely server-side parameter. -- Richard Silverman slade at shore.net From a_ghsek at yahoo.co.in Mon Jul 16 15:59:06 2001 From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=) Date: Mon, 16 Jul 2001 06:59:06 +0100 (BST) Subject: porting OpenSSH to Lynx Message-ID: <20010716055906.25292.qmail@web8003.mail.in.yahoo.com> To Whoever can help me, I need to port OpenSSH that is available as part of Linux-7.0 to Lynx OS. Has it ever been tried to port to Lynx? If yes, kindly send me details regarding porting to Lynx. Expecting your help, A.Gnana Hari Sekar. ____________________________________________________________ Do You Yahoo!? For regular News updates go to http://in.news.yahoo.com From wichert at wiggy.net Mon Jul 16 17:53:02 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon, 16 Jul 2001 09:53:02 +0200 Subject: porting OpenSSH to Lynx In-Reply-To: <20010716055906.25292.qmail@web8003.mail.in.yahoo.com>; from a_ghsek@yahoo.co.in on Mon, Jul 16, 2001 at 06:59:06AM +0100 References: <20010716055906.25292.qmail@web8003.mail.in.yahoo.com> Message-ID: <20010716095301.C29578@cistron.nl> Previously hari sekar wrote: > I need to port OpenSSH that is available as part of > Linux-7.0 to Lynx OS. There is no such thing as Linux 7.0. Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert at wiggy.net http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From RCDavis at intermedia.com Tue Jul 17 00:04:07 2001 From: RCDavis at intermedia.com (Davis, Ricardo C.) Date: Mon, 16 Jul 2001 10:04:07 -0400 Subject: FWD: OpenSSH bug in MacOS X Message-ID: <77DA8BE17C46D2118B7A00805FA7D051047ADCAD@TPAEXCH2> -----Original Message----- From: Josh Larios [mailto:jdlarios at cac.washington.edu] Sent: Thursday, July 05, 2001 8:40 PM To: openssh at openssh.com Subject: OpenSSH bug in MacOS X In MacOS X 10.0.4, and probably other versions, getaddrinfo() is broken in such a way that when you try to connect to certain hosts, openssh fails. getaddrinfo is first failing the lookup, and then failing to return with an error code when it does fail. I've found that if you define BROKEN_GETADDRINFO for OS X, it compiles and runs just fine. This patch against configure works for me: --- configure.old Sat Jun 16 21:09:50 2001 +++ configure Thu Jul 5 17:04:28 2001 @@ -1498,6 +1498,11 @@ # Check for some target-specific stuff case "$host" in +*-*-darwin*) + cat >> confdefs.h <<\EOF +#define BROKEN_GETADDRINFO 1 +EOF + ;; *-*-aix*) AFS_LIBS="-lld" CPPFLAGS="$CPPFL I hope you're the right folks to be reporting this to. Yours, -- Josh Larios Computing & Communications Client Services University of Washington Box 352830 Seattle, WA 98195-2830 jdlarios at cac.washington.edu From jmcelroy at dtgnet.com Tue Jul 17 00:16:00 2001 From: jmcelroy at dtgnet.com (jeff mcelroy) Date: Mon, 16 Jul 2001 09:16:00 -0500 Subject: openssh keys in ldap Message-ID: <3B52F720.4F43DF26@dtgnet.com> Is there any work going into placing keys in a central directory such as LDAP ? Jeff McElroy jmcelroy at dtgnet.com From pochini at shiny.it Tue Jul 17 00:47:40 2001 From: pochini at shiny.it (Giuliano Pochini) Date: Mon, 16 Jul 2001 16:47:40 +0200 (CEST) Subject: OSSH configuration option bug Message-ID: --sysconfdir configuration option doesn't work. sshd always try to open its config files from /usr/local/etc/ : pochini at orione:/home/pochini/openssh-2.9p2# sshd --help sshd: invalid option -- - sshd version OpenSSH_2.9p2 Usage: sshd [options] Options: -f file Configuration file (default /etc/ssh/sshd_config) [...] -h file File from which to read host key (default: /etc/ssh/ssh_host_key) [...] pochini at orione:/home/pochini/openssh-2.9p2# sshd Could not load host key: /usr/local/etc/ssh_host_key Could not load host key: /usr/local/etc/ssh_host_rsa_key Could not load host key: /usr/local/etc/ssh_host_dsa_key Disabling protocol version 1. Could not load host key Disabling protocol version 2. Could not load host key sshd: no hostkeys available -- exiting. pochini at orione:/home/pochini/openssh-2.9p2# Bye. Giuliano Pochini ->)|(<- Shiny Network {AS6665} ->)|(<- From simon at sxw.org.uk Tue Jul 17 04:39:45 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Mon, 16 Jul 2001 19:39:45 +0100 Subject: openssh keys in ldap In-Reply-To: <3B52F720.4F43DF26@dtgnet.com> References: <3B52F720.4F43DF26@dtgnet.com> Message-ID: <0107161939450C.05066@loki.dcs.ed.ac.uk> On Monday 16 July 2001 15:16, you wrote: > Is there any work going into placing keys in a central directory such as > LDAP ? We're doing it ... I've got a script which uploads the keys to the LDAP server (over a Kerberos authenticated connection) and generates the ssh_known_hosts file (again using a Kerberos authenticated connection). We drive this from an rc.d style script which generates and uploads the key as necessary, and updates the known_hosts file nightly. All of this doesn't require touching the ssh code base at all. Our LDAP map is RFC2307-compliant - we add a new 'sshHost' auxiliary object class to the host records in it, which adds 'sshKey' and 'sshRSAKey' attributes to each host's information. These are used for version 2 and version 1 host keys respectively - the sshKey attribute is multi-valued allowing the use of different types of version 2 keys. If you're interested I can package up the script, our schema definitions, and the (OpenLDAP) server configuration thats required to make all of this work and make it available. Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "I don't want to live on in my work, I want to live on in my apartment." -- Woody Allen From Jarno.Huuskonen at uku.fi Tue Jul 17 04:50:24 2001 From: Jarno.Huuskonen at uku.fi (Jarno Huuskonen) Date: Mon, 16 Jul 2001 21:50:24 +0300 Subject: openssh keys in ldap In-Reply-To: <0107161939450C.05066@loki.dcs.ed.ac.uk>; from simon@sxw.org.uk on Mon, Jul 16, 2001 at 07:39:45PM +0100 References: <3B52F720.4F43DF26@dtgnet.com> <0107161939450C.05066@loki.dcs.ed.ac.uk> Message-ID: <20010716215024.A152274@messi.uku.fi> Hi, On Mon, Jul 16, Simon Wilkinson wrote: > I've got a script which uploads the keys to the LDAP server (over a Kerberos > authenticated connection) and generates the ssh_known_hosts file (again using > a Kerberos authenticated connection). We drive this from an rc.d style script > which generates and uploads the key as necessary, and updates the known_hosts > file nightly. All of this doesn't require touching the ssh code base at all. > > Our LDAP map is RFC2307-compliant - we add a new 'sshHost' auxiliary object > class to the host records in it, which adds 'sshKey' and 'sshRSAKey' > attributes to each host's information. These are used for version 2 and > version 1 host keys respectively - the sshKey attribute is multi-valued > allowing the use of different types of version 2 keys. > > If you're interested I can package up the script, our schema definitions, and > the (OpenLDAP) server configuration thats required to make all of this work > and make it available. This sounds interesting, I would really appreciate if you could package all the necessary stuff for others to use. Thanks, -Jarno -- Jarno Huuskonen From jmcelroy at dtgnet.com Tue Jul 17 06:05:56 2001 From: jmcelroy at dtgnet.com (jeff mcelroy) Date: Mon, 16 Jul 2001 15:05:56 -0500 Subject: openssh keys in ldap References: <3B52F720.4F43DF26@dtgnet.com> <0107161939450C.05066@loki.dcs.ed.ac.uk> Message-ID: <3B534924.171BA5F3@dtgnet.com> How about placing the user's private keys on an ldap server and retrieving them with a patched ssh-add ? If the ldap connection is encrypted (ssl) and if we assume the ldap server is secure, Are there any obvious security issues with this ? Jeff McElroy jmcelroy at dtgnet.com From pekkas at netcore.fi Tue Jul 17 06:22:30 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 16 Jul 2001 23:22:30 +0300 (EEST) Subject: openssh keys in ldap In-Reply-To: <3B534924.171BA5F3@dtgnet.com> Message-ID: On Mon, 16 Jul 2001, jeff mcelroy wrote: > How about placing the user's private keys on an ldap server and retrieving > them with a patched ssh-add ? If the ldap connection is encrypted (ssl) and if > we assume the ldap server is secure, Are there any obvious security issues with > this ? .. to curtail possible flaws, if this was done, this should only be possible with keys which have non-NULL passphrase. My brain keeps shouting: "Bad idea! Bad idea!" 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 douglas.manton at uk.ibm.com Tue Jul 17 06:32:49 2001 From: douglas.manton at uk.ibm.com (Doug E Manton) Date: Mon, 16 Jul 2001 21:32:49 +0100 Subject: openssh keys in ldap Message-ID: > we assume the ldap server is secure, If you manage the LDAP server, then you can assume it is secure. Are you willing to hand your private keys to a server you don't control? Maybe I am just paranoid, but in my line of work... ;-) My private key stays on a machine which I control and it never traverses the network, encrypted or not. I generated it, I protect it and so I trust it. We should educate our users to treat their private keys with the same respect. Simple, clear rules are most likely to be followed. -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From dboldt at usgs.gov Tue Jul 17 02:55:10 2001 From: dboldt at usgs.gov (David R Boldt) Date: Mon, 16 Jul 2001 12:55:10 -0400 Subject: openssh 2.9p1 on Solaris 2.6 with AFS Message-ID: Jan, maybe I should check the /afs information that you pointed me at in a subsequent email first, but I wanted to update you on what happened following this path: I did get some mileage out of both of your suggestions below, but still did not make it through (now working with openssh-2.9p2): gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -L/usr/athena/lib -R/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv -ldes -lkrb -lpam -ldl -lwrap -lz -lsocket -lnsl -lgen -lcrypto -ldes /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_check_key_parity': set_key.o(.text+0x380): multiple definition of `des_check_key_parity' /usr/local/lib/libdes.a(key_parity.o)(.text+0x98): first defined here /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol `des_check_key_parity' changed from 180 to 88 in set_key.o /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_is_weak_key': set_key.o(.text+0x3e0): multiple definition of `des_is_weak_key' /usr/local/lib/libdes.a(weak_key.o)(.text+0x10): first defined here /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol `des_is_weak_key' changed from 192 to 96 in set_key.o /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_key_sched': set_key.o(.text+0x4a0): multiple definition of `des_key_sched' /usr/local/lib/libdes.a(key_sched.o)(.text+0x10): first defined here /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol `des_key_sched' changed from 336 to 80 in set_key.o /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_fixup_key_parity': set_key.o(.text+0x5e0): multiple definition of `des_fixup_key_parity' /usr/local/lib/libdes.a(key_parity.o)(.text+0x10): first defined here /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol `des_fixup_key_parity' changed from 120 to 72 in set_key.o gmake: *** [ssh] Error 1 -- David Boldt Jan IVEN n.ch> cc: openssh at openssh.com Subject: Re: openssh 2.9p1 on Solaris 05/18/01 2.6 with AFS 03:13 AM >>>>> "DRB" == David R Boldt writes: DRB> Jan, DRB> here is the new patch: thanks. Maybe somebody will apply this to openssh cvs? DRB> alas I am still running amiss: DRB> In file included from /usr/athena/include/krb.h:50, DRB> from sshconnect1.c:22: DRB> /usr/local/include/des.h:24: warning: redefinition of `des_cblock' DRB> /usr/local/ssl/include/openssl/des.h:77: warning: `des_cblock' previously DRB> declared here DRB> /usr/local/include/des.h:26: redefinition of `struct des_ks_struct' DRB> /usr/local/include/des.h:26: warning: redefinition of `des_key_schedule' DRB> /usr/local/ssl/include/openssl/des.h:91: warning: `des_key_schedule' DRB> previously declared here DRB> /usr/local/include/des.h:54: conflicting types for `bit_64' DRB> /usr/local/ssl/include/openssl/des.h:259: previous declaration of `bit_64' Try to fiddle around with your include path, you probably don't want /usr/local/include to be in there. DRB> sshconnect1.c: In function `send_afs_tokens': DRB> sshconnect1.c:560: warning: implicit declaration of function `_IOW' DRB> sshconnect1.c:560: parse error before `struct' DRB> gmake: *** [sshconnect1.o] Error 1 patch to your krb-1.0.? installed include/kafs.h on Solaris: --- kafs.h~ Tue Dec 12 15:53:47 2000 +++ kafs.h Fri Dec 15 12:22:05 2000 @@ -36,6 +36,9 @@ #ifndef __KAFS_H #define __KAFS_H +/* need _IOW on Solaris , 15.12.00 JI */ +#include + /* XXX must include krb5.h or krb.h */ /* sys/ioctl.h must be included manually before kafs.h */ From sh at ciamserv.ciam.unibo.it Tue Jul 17 02:55:49 2001 From: sh at ciamserv.ciam.unibo.it (Siegfried Hoefinger) Date: Mon, 16 Jul 2001 18:55:49 +0200 Subject: No subject Message-ID: <200107161655.SAA18398@ciamserv.ciam.unibo.it> openssh at openssh.com Dear openssh team ! When I try to configure openssh version 2.9p2 on an ALPHA OSF1 V4.0 I get lots of error messages of the following type What is missing fundamentally ? Could this be due to not using gcc ? How can I solve these problems ? best regards S. Hoefinger >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:605: checking for gcc configure:635: checking for cc configure:718: checking whether the C compiler (cc ) works configure:734: cc -o conftest conftest.c 1>&5 configure:760: checking whether the C compiler (cc ) is a cross-compiler configure:765: checking whether we are using GNU C configure:774: cc -E conftest.c configure:793: checking whether cc accepts -g configure:850: checking host system type configure:871: checking whether byte ordering is bigendian configure:889: cc -c -g conftest.c 1>&5 configure:904: cc -c -g conftest.c 1>&5 cc: Error: configure, line 899: In this declaration, "not" must specify a type. (badparsedecl) not big endian -^ configure: failed program was: #line 893 "configure" #include "confdefs.h" #include #include int main() { #if BYTE_ORDER != BIG_ENDIAN not big endian #endif ; return 0; } configure:963: checking how to run the C preprocessor configure:984: cc -E conftest.c >/dev/null 2>conftest.out configure:1045: checking for ranlib configure:1084: checking for a BSD compatible install configure:1139: checking for ar configure:1176: checking for perl5 configure:1176: checking for perl configure:1215: checking for ent configure:1253: checking for filepriv configure:1292: checking for bash configure:1327: checking for ksh configure:1362: checking for sh configure:1410: checking for login configure:1457: checking for inline configure:1471: cc -c -g conftest.c 1>&5 cc: Error: configure, line 1467: Missing ";". (nosemi) } inline foo() { ---------^ configure: failed program was: #line 1464 "configure" #include "confdefs.h" int main() { } inline foo() { ; return 0; } configure:1471: cc -c -g conftest.c 1>&5 cc: Error: configure, line 1467: Missing ";". (nosemi) } __inline__ foo() { -------------^ configure: failed program was: #line 1464 "configure" #include "confdefs.h" int main() { } __inline__ foo() { ; return 0; } configure:1471: cc -c -g conftest.c 1>&5 configure:2156: checking for Digital Unix SIA configure:2296: checking for yp_match in -lnsl configure:2315: cc -o conftest -g conftest.c -lnsl -lsecurity -ldb -lm -laud 1>&5 ld: Can't locate file for: -lnsl configure: failed program was: #line 2304 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char yp_match(); int main() { yp_match() ; return 0; } configure:2345: checking for main in -lsocket configure:2360: cc -o conftest -g conftest.c -lsocket -lsecurity -ldb -lm -laud 1>&5 ld: Can't locate file for: -lsocket configure: failed program was: #line 2353 "configure" #include "confdefs.h" int main() { main() ; return 0; } configure:2390: checking for innetgr in -lrpc configure:2409: cc -o conftest -g conftest.c -lrpc -lyp -lrpc -lsecurity -ldb -lm -laud 1>&5 ld: Can't locate file for: -lyp configure: failed program was: #line 2398 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char innetgr(); int main() { innetgr() ; return 0; } configure:2431: checking for getspnam in -lgen configure:2450: cc -o conftest -g conftest.c -lgen -lsecurity -ldb -lm -laud 1>&5 ld: Can't locate file for: -lgen configure: failed program was: #line 2439 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getspnam(); int main() { getspnam() ; return 0; } configure:2471: checking for deflate in -lz configure:2490: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud 1>&5 configure:2519: checking for login in -lutil configure:2538: cc -o conftest -g conftest.c -lutil -lz -lsecurity -ldb -lm -laud 1>&5 configure:2565: checking for regcomp configure:2593: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:2670: checking for strcasecmp configure:2698: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:2759: checking for utimes configure:2787: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:2849: checking for strftime configure:2877: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:2950: checking for bstring.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for crypt.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for endian.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for floatingpoint.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for getopt.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for glob.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for lastlog.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for limits.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for login.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for login_cap.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for maillock.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for netdb.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for netgroup.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for netinet/in_systm.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for paths.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for poll.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for pty.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for regex.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for shadow.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for security/pam_appl.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/bitypes.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/bsdtty.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/cdefs.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/poll.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/queue.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/select.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/stat.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/stropts.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/sysmacros.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/time.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for sys/ttcompat.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for sys/un.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for stddef.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for time.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for ttyent.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for usersec.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for util.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2950: checking for utime.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for utmp.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for utmpx.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out configure:2950: checking for vis.h configure:2960: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 2956: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 2955 "configure" #include "confdefs.h" #include configure:2989: checking for GLOB_ALTDIRFUNC support configure:3022: checking for gl_matchc field in glob_t configure:3052: checking whether struct dirent allocates space for d_name configure:3065: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for arc4random configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: arc4random configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char arc4random(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char arc4random(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_arc4random) || defined (__stub___arc4random) choke me #else arc4random(); #endif ; return 0; } configure:3213: checking for atexit configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for b64_ntop configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: b64_ntop configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char b64_ntop(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char b64_ntop(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_b64_ntop) || defined (__stub___b64_ntop) choke me #else b64_ntop(); #endif ; return 0; } configure:3213: checking for bcopy configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 cc: Info: configure, line 3225: In this statement, the declaration for intrinsic function "bcopy" referenced at line number 3235 in file configure, the declared return type of "signed char" is not consistent with the expected type of "void". It will be treated as an ordinary external function. (intrinsicdecl) char bcopy(); -----^ configure:3213: checking for bindresvport_sa configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: bindresvport_sa configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char bindresvport_sa(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char bindresvport_sa(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_bindresvport_sa) || defined (__stub___bindresvport_sa) choke me #else bindresvport_sa(); #endif ; return 0; } configure:3213: checking for clock configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for fchown configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for fchmod configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for freeaddrinfo configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: freeaddrinfo configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char freeaddrinfo(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char freeaddrinfo(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_freeaddrinfo) || defined (__stub___freeaddrinfo) choke me #else freeaddrinfo(); #endif ; return 0; } configure:3213: checking for futimes configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: futimes configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char futimes(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char futimes(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_futimes) || defined (__stub___futimes) choke me #else futimes(); #endif ; return 0; } configure:3213: checking for gai_strerror configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: gai_strerror configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char gai_strerror(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char gai_strerror(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_gai_strerror) || defined (__stub___gai_strerror) choke me #else gai_strerror(); #endif ; return 0; } configure:3213: checking for getcwd configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for getaddrinfo configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: getaddrinfo configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getaddrinfo(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getaddrinfo(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getaddrinfo) || defined (__stub___getaddrinfo) choke me #else getaddrinfo(); #endif ; return 0; } configure:3213: checking for getgrouplist configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: getgrouplist configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getgrouplist(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getgrouplist(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getgrouplist) || defined (__stub___getgrouplist) choke me #else getgrouplist(); #endif ; return 0; } configure:3213: checking for getnameinfo configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: getnameinfo configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getnameinfo(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getnameinfo(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getnameinfo) || defined (__stub___getnameinfo) choke me #else getnameinfo(); #endif ; return 0; } configure:3213: checking for getrlimit configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for getrusage configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for getttyent configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for getusershell configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for glob configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for inet_aton configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for inet_ntoa configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for inet_ntop configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: inet_ntop configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char inet_ntop(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char inet_ntop(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_inet_ntop) || defined (__stub___inet_ntop) choke me #else inet_ntop(); #endif ; return 0; } configure:3213: checking for innetgr configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for login_getcapbool configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: login_getcapbool configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char login_getcapbool(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char login_getcapbool(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_login_getcapbool) || defined (__stub___login_getcapbool) choke me #else login_getcapbool(); #endif ; return 0; } configure:3213: checking for md5_crypt configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: md5_crypt configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char md5_crypt(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char md5_crypt(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_md5_crypt) || defined (__stub___md5_crypt) choke me #else md5_crypt(); #endif ; return 0; } configure:3213: checking for memmove configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 cc: Info: configure, line 3225: In this statement, the declaration for intrinsic function "memmove" referenced at line number 3235 in file configure, the declared return type of "signed char" is not consistent with the expected type of "pointer to void". It will be treated as an ordinary external function. (intrinsicdecl) char memmove(); -----^ configure:3213: checking for mkdtemp configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: mkdtemp configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char mkdtemp(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char mkdtemp(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_mkdtemp) || defined (__stub___mkdtemp) choke me #else mkdtemp(); #endif ; return 0; } configure:3213: checking for on_exit configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: on_exit configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char on_exit(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char on_exit(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_on_exit) || defined (__stub___on_exit) choke me #else on_exit(); #endif ; return 0; } configure:3213: checking for openpty configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for realpath configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for rresvport_af configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: rresvport_af configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char rresvport_af(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char rresvport_af(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_rresvport_af) || defined (__stub___rresvport_af) choke me #else rresvport_af(); #endif ; return 0; } configure:3213: checking for setdtablesize configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: setdtablesize configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char setdtablesize(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char setdtablesize(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_setdtablesize) || defined (__stub___setdtablesize) choke me #else setdtablesize(); #endif ; return 0; } configure:3213: checking for setenv configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setegid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for seteuid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setlogin configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setproctitle configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: setproctitle configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char setproctitle(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char setproctitle(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_setproctitle) || defined (__stub___setproctitle) choke me #else setproctitle(); #endif ; return 0; } configure:3213: checking for setresgid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: setresgid configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char setresgid(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char setresgid(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_setresgid) || defined (__stub___setresgid) choke me #else setresgid(); #endif ; return 0; } configure:3213: checking for setreuid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setrlimit configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setsid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for setvbuf configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for sigaction configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for sigvec configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for snprintf configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 cc: Info: configure, line 3225: In this statement, the declaration for intrinsic function "snprintf" referenced at line number 3235 in file configure, the declared return type of "signed char" is not consistent with the expected type of "int". It will be treated as an ordinary external function. (intrinsicdecl) char snprintf(); -----^ configure:3213: checking for strerror configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for strlcat configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: strlcat configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char strlcat(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char strlcat(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_strlcat) || defined (__stub___strlcat) choke me #else strlcat(); #endif ; return 0; } configure:3213: checking for strlcpy configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: strlcpy configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char strlcpy(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char strlcpy(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_strlcpy) || defined (__stub___strlcpy) choke me #else strlcpy(); #endif ; return 0; } configure:3213: checking for strmode configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: strmode configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char strmode(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char strmode(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_strmode) || defined (__stub___strmode) choke me #else strmode(); #endif ; return 0; } configure:3213: checking for strsep configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: strsep configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char strsep(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char strsep(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_strsep) || defined (__stub___strsep) choke me #else strsep(); #endif ; return 0; } configure:3213: checking for strtok_r configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for sysconf configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for tcgetpgrp configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for utimes configure:3213: checking for vsnprintf configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for vhangup configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: vhangup configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char vhangup(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char vhangup(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_vhangup) || defined (__stub___vhangup) choke me #else vhangup(); #endif ; return 0; } configure:3213: checking for vis configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: vis configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char vis(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char vis(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_vis) || defined (__stub___vis) choke me #else vis(); #endif ; return 0; } configure:3213: checking for waitpid configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3213: checking for _getpty configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: _getpty configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char _getpty(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char _getpty(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub__getpty) || defined (__stub____getpty) choke me #else _getpty(); #endif ; return 0; } configure:3213: checking for __b64_ntop configure:3241: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: __b64_ntop configure: failed program was: #line 3218 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char __b64_ntop(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char __b64_ntop(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub___b64_ntop) || defined (__stub_____b64_ntop) choke me #else __b64_ntop(); #endif ; return 0; } configure:3268: checking for gettimeofday configure:3296: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3268: checking for time configure:3296: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3324: checking for libutil.h configure:3334: cc -E conftest.c >/dev/null 2>conftest.out cc: Error: configure, line 3330: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 3329 "configure" #include "confdefs.h" #include configure:3363: checking for login configure:3391: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3363: checking for logout configure:3391: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3363: checking for updwtmp configure:3391: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: updwtmp configure: failed program was: #line 3368 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char updwtmp(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char updwtmp(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_updwtmp) || defined (__stub___updwtmp) choke me #else updwtmp(); #endif ; return 0; } configure:3363: checking for logwtmp configure:3391: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for endutent configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for getutent configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for getutid configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for getutline configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for pututline configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3418: checking for setutent configure:3446: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3473: checking for utmpname configure:3501: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3528: checking for endutxent configure:3556: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3528: checking for getutxent configure:3556: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3528: checking for getutxid configure:3556: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3528: checking for getutxline configure:3556: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3528: checking for pututxline configure:3556: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3583: checking for setutxent configure:3611: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3583: checking for utmpxname configure:3611: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: utmpxname configure: failed program was: #line 3588 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char utmpxname(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char utmpxname(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_utmpxname) || defined (__stub___utmpxname) choke me #else utmpxname(); #endif ; return 0; } configure:3637: checking for getuserattr configure:3665: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Unresolved: getuserattr configure: failed program was: #line 3642 "configure" #include "confdefs.h" /* System header to define __stub macros and hopefully few prototypes, which can conflict with char getuserattr(); below. */ #include /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getuserattr(); int main() { /* The GNU C library defines this for functions which it implements to always fail with ENOSYS. Some functions are actually named something starting with __ and the normal name is an alias. */ #if defined (__stub_getuserattr) || defined (__stub___getuserattr) choke me #else getuserattr(); #endif ; return 0; } configure:3686: checking for getuserattr in -ls configure:3705: cc -o conftest -g conftest.c -ls -lz -lsecurity -ldb -lm -laud -lutil 1>&5 ld: Can't locate file for: -ls configure: failed program was: #line 3694 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getuserattr(); int main() { getuserattr() ; return 0; } configure:3733: checking for login configure:3829: checking for daemon configure:3857: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:3925: checking for getpagesize configure:3953: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:4023: checking whether snprintf correctly terminates long strings configure:4035: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:4058: checking whether getpgrp takes no argument configure:4121: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil 1>&5 configure:4376: checking for OpenSSL directory configure:4433: cc -o conftest -g conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 cc: Severe: configure, line 4422: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 4419 "configure" #include "confdefs.h" #include #include int main(void) { char a[2048]; memset(a, 0, sizeof(a)); RAND_add(a, sizeof(a), sizeof(a)); return(RAND_status() <= 0); } configure:4433: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4502: checking for RSA support configure:4532: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4618: checking size of char configure:4637: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4657: checking size of short int configure:4676: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4696: checking size of int configure:4715: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4735: checking size of long int configure:4754: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4774: checking size of long long int configure:4793: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:4815: checking for u_int type configure:4828: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 4822: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 4824: In this declaration, "u_int" must specify a type. (badparsedecl) u_int a; a = 1; -^ cc: Error: configure, line 4824: In this statement, "a" is not declared. (undeclared) u_int a; a = 1; ----------^ configure: failed program was: #line 4821 "configure" #include "confdefs.h" #include int main() { u_int a; a = 1; ; return 0; } configure:4852: checking for intXX_t types configure:4865: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 4859: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 4861: In this declaration, "int8_t" must specify a type. (badparsedecl) int8_t a; int16_t b; int32_t c; a = b = c = 1; -^ cc: Error: configure, line 4861: In this declaration, "int16_t" must specify a type. (badparsedecl) int8_t a; int16_t b; int32_t c; a = b = c = 1; -----------^ cc: Error: configure, line 4861: In this declaration, "int32_t" must specify a type. (badparsedecl) int8_t a; int16_t b; int32_t c; a = b = c = 1; ----------------------^ cc: Error: configure, line 4861: In this statement, "a" is not declared. (undeclared) int8_t a; int16_t b; int32_t c; a = b = c = 1; ---------------------------------^ cc: Error: configure, line 4861: In this statement, "b" is not declared. (undeclared) int8_t a; int16_t b; int32_t c; a = b = c = 1; -------------------------------------^ cc: Error: configure, line 4861: In this statement, "c" is not declared. (undeclared) int8_t a; int16_t b; int32_t c; a = b = c = 1; -----------------------------------------^ configure: failed program was: #line 4858 "configure" #include "confdefs.h" #include int main() { int8_t a; int16_t b; int32_t c; a = b = c = 1; ; return 0; } configure:4889: checking for int64_t type configure:4902: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 4896: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 4898: In this declaration, "int64_t" must specify a type. (badparsedecl) int64_t a; a = 1; -^ cc: Error: configure, line 4898: In this statement, "a" is not declared. (undeclared) int64_t a; a = 1; ------------^ configure: failed program was: #line 4895 "configure" #include "confdefs.h" #include int main() { int64_t a; a = 1; ; return 0; } configure:4926: checking for u_intXX_t types configure:4939: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 4933: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 4935: In this declaration, "u_int8_t" must specify a type. (badparsedecl) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; -^ cc: Error: configure, line 4935: In this declaration, "u_int16_t" must specify a type. (badparsedecl) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; -------------^ cc: Error: configure, line 4935: In this declaration, "u_int32_t" must specify a type. (badparsedecl) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; --------------------------^ cc: Error: configure, line 4935: In this statement, "a" is not declared. (undeclared) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; ---------------------------------------^ cc: Error: configure, line 4935: In this statement, "b" is not declared. (undeclared) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; -------------------------------------------^ cc: Error: configure, line 4935: In this statement, "c" is not declared. (undeclared) u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; -----------------------------------------------^ configure: failed program was: #line 4932 "configure" #include "confdefs.h" #include int main() { u_int8_t a; u_int16_t b; u_int32_t c; a = b = c = 1; ; return 0; } configure:4963: checking for u_int64_t types configure:4976: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 4970: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 4972: In this declaration, "u_int64_t" must specify a type. (badparsedecl) u_int64_t a; a = 1; -^ cc: Error: configure, line 4972: In this statement, "a" is not declared. (undeclared) u_int64_t a; a = 1; --------------^ configure: failed program was: #line 4969 "configure" #include "confdefs.h" #include int main() { u_int64_t a; a = 1; ; return 0; } configure:5043: checking for uintXX_t types configure:5058: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 5054: In this declaration, "uint8_t" must specify a type. (badparsedecl) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; -^ cc: Error: configure, line 5054: In this declaration, "uint16_t" must specify a type. (badparsedecl) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; ------------^ cc: Error: configure, line 5054: In this declaration, "uint32_t" must specify a type. (badparsedecl) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; ------------------------^ cc: Error: configure, line 5054: In this statement, "a" is not declared. (undeclared) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; ------------------------------------^ cc: Error: configure, line 5054: In this statement, "b" is not declared. (undeclared) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; ----------------------------------------^ cc: Error: configure, line 5054: In this statement, "c" is not declared. (undeclared) uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; --------------------------------------------^ configure: failed program was: #line 5049 "configure" #include "confdefs.h" #include int main() { uint8_t a; uint16_t b; uint32_t c; a = b = c = 1; ; return 0; } configure:5082: checking for socklen_t configure:5098: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5121: checking for size_t configure:5136: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5159: checking for ssize_t configure:5174: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5197: checking for clock_t configure:5212: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5235: checking for sa_family_t configure:5251: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5296: checking for pid_t configure:5311: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5334: checking for mode_t configure:5349: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:5373: checking for struct sockaddr_storage configure:5389: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 5385: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct sockaddr_storage s; -------------------------^ configure: failed program was: #line 5379 "configure" #include "confdefs.h" #include #include int main() { struct sockaddr_storage s; ; return 0; } configure:5412: checking for struct sockaddr_in6 configure:5428: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 5424: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct sockaddr_in6 s; s.sin6_family = 0; ---------------------^ configure: failed program was: #line 5418 "configure" #include "confdefs.h" #include #include int main() { struct sockaddr_in6 s; s.sin6_family = 0; ; return 0; } configure:5451: checking for struct in6_addr configure:5467: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 5463: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct in6_addr s; s.s6_addr[0] = 0; -----------------^ configure: failed program was: #line 5457 "configure" #include "confdefs.h" #include #include int main() { struct in6_addr s; s.s6_addr[0] = 0; ; return 0; } configure:5490: checking for struct addrinfo configure:5507: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 5503: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct addrinfo s; s.ai_flags = AI_PASSIVE; -----------------^ cc: Error: configure, line 5503: In this statement, "AI_PASSIVE" is not declared. (undeclared) struct addrinfo s; s.ai_flags = AI_PASSIVE; ---------------------------------^ configure: failed program was: #line 5496 "configure" #include "confdefs.h" #include #include #include int main() { struct addrinfo s; s.ai_flags = AI_PASSIVE; ; return 0; } configure:5530: checking for struct timeval configure:5543: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Warning: configure, line 5537: # not in column 1 is ignored, skipping to end of line. (ignoretokens) #include -^ cc: Error: configure, line 5539: In this declaration, "tv" has no linkage and is of an incomplete type. (incompnolink) struct timeval tv; tv.tv_sec = 1; ----------------^ configure: failed program was: #line 5536 "configure" #include "confdefs.h" #include int main() { struct timeval tv; tv.tv_sec = 1; ; return 0; } configure:5604: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure: failed program was: #line 5577 "configure" #include "confdefs.h" #include #include #ifdef HAVE_SNPRINTF main() { char buf[50]; char expected_out[50]; int mazsize = 50 ; #if (SIZEOF_LONG_INT == 8) long int num = 0x7fffffffffffffff; #else long long num = 0x7fffffffffffffff; #endif strcpy(expected_out, "9223372036854775807"); snprintf(buf, mazsize, "%lld", num); if(strcmp(buf, expected_out) != 0) exit(1); exit(0); } #else main() { exit(0); } #endif configure:5628: checking for ut_host field in utmp.h configure:5668: checking for ut_host field in utmpx.h configure:5708: checking for syslen field in utmpx.h configure:5748: checking for ut_pid field in utmp.h configure:5788: checking for ut_type field in utmp.h configure:5828: checking for ut_type field in utmpx.h configure:5868: checking for ut_tv field in utmp.h configure:5908: checking for ut_id field in utmp.h configure:5948: checking for ut_id field in utmpx.h configure:5988: checking for ut_addr field in utmp.h configure:6028: checking for ut_addr field in utmpx.h configure:6068: checking for ut_addr_v6 field in utmp.h configure:6108: checking for ut_addr_v6 field in utmpx.h configure:6148: checking for ut_exit field in utmp.h configure:6188: checking for ut_time field in utmp.h configure:6228: checking for ut_time field in utmpx.h configure:6268: checking for ut_tv field in utmpx.h configure:6304: checking for st_blksize in struct stat configure:6317: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:6339: checking for sun_len field in struct sockaddr_un configure:6355: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 6351: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct sockaddr_un s; s.sun_len = 1; --------------------^ configure: failed program was: #line 6345 "configure" #include "confdefs.h" #include #include int main() { struct sockaddr_un s; s.sun_len = 1; ; return 0; } configure:6377: checking for ss_family field in struct sockaddr_storage configure:6393: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 6389: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct sockaddr_storage s; s.ss_family = 1; -------------------------^ configure: failed program was: #line 6383 "configure" #include "confdefs.h" #include #include int main() { struct sockaddr_storage s; s.ss_family = 1; ; return 0; } configure:6415: checking for __ss_family field in struct sockaddr_storage configure:6431: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 6427: In this declaration, "s" has no linkage and is of an incomplete type. (incompnolink) struct sockaddr_storage s; s.__ss_family = 1; -------------------------^ configure: failed program was: #line 6421 "configure" #include "confdefs.h" #include #include int main() { struct sockaddr_storage s; s.__ss_family = 1; ; return 0; } configure:6454: checking for pw_class field in struct passwd configure:6469: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 6465: In this statement, "pw_class" is not a member of "p". (needmember) struct passwd p; p.pw_class = 0; ------------------^ configure: failed program was: #line 6460 "configure" #include "confdefs.h" #include int main() { struct passwd p; p.pw_class = 0; ; return 0; } configure:6493: checking if libc defines __progname configure:6506: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 ld: Unresolved: __progname configure: failed program was: #line 6499 "configure" #include "confdefs.h" int main() { extern char *__progname; printf("%s", __progname); ; return 0; } configure:6530: checking if libc defines sys_errlist configure:6543: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:6567: checking if libc defines sys_nerr configure:6580: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:6973: checking for rsh configure:7023: checking for xauth configure:7094: checking for /dev/ptmx configure:7127: checking for /dev/ptc configure:7178: checking for /dev/urandom configure:7248: checking for PRNGD/EGD socket configure:7281: checking for ls configure:7322: checking for netstat configure:7363: checking for arp configure:7404: checking for ifconfig configure:7445: checking for ps configure:7486: checking for w configure:7527: checking for who configure:7568: checking for last configure:7609: checking for lastlog configure:7650: checking for df configure:7691: checking for vmstat configure:7732: checking for uptime configure:7773: checking for ipcs configure:7814: checking for tail configure:7879: checking for nroff configure:7968: checking if the systems has expire shadow information configure:7981: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Severe: configure, line 7973: Cannot find file specified in #include directive. (noinclfile) #include -^ configure: failed program was: #line 7970 "configure" #include "confdefs.h" #include #include struct spwd sp; int main() { sp.sp_expire = sp.sp_lstchg = sp.sp_inact = 0; ; return 0; } configure:8080: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 configure:8137: checking if we need to convert IPv4 in IPv6-mapped addresses configure:8189: checking whether to install ssh as suid root configure:8338: checking if your system defines LASTLOG_FILE configure:8356: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8352: In the initializer for lastlog, "LASTLOG_FILE" is not declared. (undeclared) char *lastlog = LASTLOG_FILE; -----------------^ configure: failed program was: #line 8340 "configure" #include "confdefs.h" #include #include #ifdef HAVE_LASTLOG_H # include #endif #ifdef HAVE_PATHS_H # include #endif int main() { char *lastlog = LASTLOG_FILE; ; return 0; } configure:8366: checking if your system defines _PATH_LASTLOG configure:8384: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8380: In the initializer for lastlog, "_PATH_LASTLOG" is not declared. (undeclared) char *lastlog = _PATH_LASTLOG; -----------------^ configure: failed program was: #line 8368 "configure" #include "confdefs.h" #include #include #ifdef HAVE_LASTLOG_H # include #endif #ifdef HAVE_PATHS_H # include #endif int main() { char *lastlog = _PATH_LASTLOG; ; return 0; } configure:8423: checking if your system defines UTMP_FILE configure:8438: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:8473: checking if your system defines WTMP_FILE configure:8488: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 configure:8524: checking if your system defines UTMPX_FILE configure:8542: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8538: In the initializer for utmpx, "UTMPX_FILE" is not declared. (undeclared) char *utmpx = UTMPX_FILE; ---------------^ configure: failed program was: #line 8526 "configure" #include "confdefs.h" #include #include #ifdef HAVE_UTMPX_H #include #endif #ifdef HAVE_PATHS_H # include #endif int main() { char *utmpx = UTMPX_FILE; ; return 0; } configure:8569: checking if your system defines WTMPX_FILE configure:8587: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8583: In the initializer for wtmpx, "WTMPX_FILE" is not declared. (undeclared) char *wtmpx = WTMPX_FILE; ---------------^ configure: failed program was: #line 8571 "configure" #include "confdefs.h" #include #include #ifdef HAVE_UTMPX_H #include #endif #ifdef HAVE_PATHS_H # include #endif int main() { char *wtmpx = WTMPX_FILE; ; return 0; } configure:8639: checking for Cygwin environment configure:8655: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8651: In this statement, "__CYGWIN32__" is not declared. (undeclared) return __CYGWIN__; -------^ configure: failed program was: #line 8644 "configure" #include "confdefs.h" int main() { #ifndef __CYGWIN__ #define __CYGWIN__ __CYGWIN32__ #endif return __CYGWIN__; ; return 0; } configure:8672: checking for mingw32 environment configure:8684: cc -c -g -I/usr/local/ssl/include conftest.c 1>&5 cc: Error: configure, line 8680: In this statement, "__MINGW32__" is not declared. (undeclared) return __MINGW32__; -------^ configure: failed program was: #line 8677 "configure" #include "confdefs.h" int main() { return __MINGW32__; ; return 0; } configure:8703: checking for executable suffix configure:8713: cc -o conftest -g -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lz -lsecurity -ldb -lm -laud -lutil -lcrypto 1>&5 From jmcelroy at dtgnet.com Tue Jul 17 08:04:45 2001 From: jmcelroy at dtgnet.com (jeff mcelroy) Date: Mon, 16 Jul 2001 17:04:45 -0500 Subject: openssh keys in ldap References: Message-ID: <3B5364FD.B5EEC841@dtgnet.com> Pekka Savola wrote: > On Mon, 16 Jul 2001, jeff mcelroy wrote: > > How about placing the user's private keys on an ldap server and retrieving > > them with a patched ssh-add ? If the ldap connection is encrypted (ssl) and if > > we assume the ldap server is secure, Are there any obvious security issues with > > this ? > > .. to curtail possible flaws, if this was done, this should only be > possible with keys which have non-NULL passphrase. > > My brain keeps shouting: "Bad idea! Bad idea!" though. If the keys stay encrypted (not counting ssl) until ssh-add decrypts them (in the same manner that it decrypts the private keys off the filesystem). Would we need to trust the LDAP server or transport protocol. What problems would we encounter with this? Jeff McElroy jmcelroy at dtgnet.com From jan.iven at cern.ch Tue Jul 17 07:38:10 2001 From: jan.iven at cern.ch (Jan IVEN) Date: 16 Jul 2001 23:38:10 +0200 Subject: openssh 2.9p1 on Solaris 2.6 with AFS In-Reply-To: References: Message-ID: >>>>> "DRB" == David R Boldt writes: DRB> Jan, DRB> maybe I should check the /afs information that you pointed me at DRB> in a subsequent email first, but I wanted to update you on what DRB> happened following this path: DRB> I did get some mileage out of both of your suggestions below, DRB> but still did not make it through (now working with openssh-2.9p2): DRB> gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o DRB> readconf.o clientloop.o -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib DRB> -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -L/usr/athena/lib DRB> -R/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv DRB> -ldes -lkrb -lpam -ldl -lwrap -lz -lsocket -lnsl -lgen -lcrypto -ldes 1. there are 2 -ldes in there? 2. try to get it working on the command line. I would start by removing -ldes -L/usr/local/lib: gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o \ readconf.o clientloop.o -L. -Lopenbsd-compat/ -R/usr/local/ssl/lib \ -L/usr/local/ssl/lib -L/usr/athena/lib \ -R/usr/athena/lib -L/usr/afsws/lib -lssh -lopenbsd-compat -lkafs -lresolv \ -lkrb -lpam -ldl -lwrap -lz -lsocket -lnsl -lgen -lcrypto -ldes If this still complains about /usr/local/lib/libdes.a, remove the remaining -ldes. If this starts to complain about missing functions, find out why these functions are not in libcrypto.a (and who is referencing them). Other possibilities: ld -t will stop the warnings... ld -z muldefs same as -t, allows first symbol to be taken No idea on the side effects - this could dump core on the spot. (you have to wrap these up for gcc, I think something like -Wl,-t or -Wl,-z,muldefs should do the trick) If it works, then we will have to find a way for configure to do the right thing automatically -- and please do document your efforts (at least the final working solution...). Best regards Jan DRB> /usr/local/ssl/lib/libcrypto.a(set_key.o): In function DRB> `des_check_key_parity': DRB> set_key.o(.text+0x380): multiple definition of `des_check_key_parity' DRB> /usr/local/lib/libdes.a(key_parity.o)(.text+0x98): first defined here DRB> /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol DRB> `des_check_key_parity' changed from 180 to 88 in set_key.o DRB> /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_is_weak_key': DRB> set_key.o(.text+0x3e0): multiple definition of `des_is_weak_key' DRB> /usr/local/lib/libdes.a(weak_key.o)(.text+0x10): first defined here DRB> /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol DRB> `des_is_weak_key' changed from 192 to 96 in set_key.o DRB> /usr/local/ssl/lib/libcrypto.a(set_key.o): In function `des_key_sched': DRB> set_key.o(.text+0x4a0): multiple definition of `des_key_sched' DRB> /usr/local/lib/libdes.a(key_sched.o)(.text+0x10): first defined here DRB> /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol DRB> `des_key_sched' changed from 336 to 80 in set_key.o DRB> /usr/local/ssl/lib/libcrypto.a(set_key.o): In function DRB> `des_fixup_key_parity': DRB> set_key.o(.text+0x5e0): multiple definition of `des_fixup_key_parity' DRB> /usr/local/lib/libdes.a(key_parity.o)(.text+0x10): first defined here DRB> /usr/local/sparc-sun-solaris2.6/bin/ld: Warning: size of symbol DRB> `des_fixup_key_parity' changed from 120 to 72 in set_key.o DRB> gmake: *** [ssh] Error 1 DRB> -- David Boldt DRB> DRB> Jan IVEN DRB> n.ch> cc: openssh at openssh.com DRB> Subject: Re: openssh 2.9p1 on Solaris DRB> 05/18/01 2.6 with AFS DRB> 03:13 AM >>>>> "DRB" == David R Boldt writes: DRB> Jan, DRB> here is the new patch: DRB> thanks. Maybe somebody will apply this to openssh cvs? DRB> alas I am still running amiss: DRB> In file included from /usr/athena/include/krb.h:50, DRB> from sshconnect1.c:22: DRB> /usr/local/include/des.h:24: warning: redefinition of `des_cblock' DRB> /usr/local/ssl/include/openssl/des.h:77: warning: `des_cblock' DRB> previously DRB> declared here DRB> /usr/local/include/des.h:26: redefinition of `struct des_ks_struct' DRB> /usr/local/include/des.h:26: warning: redefinition of DRB> `des_key_schedule' DRB> /usr/local/ssl/include/openssl/des.h:91: warning: `des_key_schedule' DRB> previously declared here DRB> /usr/local/include/des.h:54: conflicting types for `bit_64' DRB> /usr/local/ssl/include/openssl/des.h:259: previous declaration of DRB> `bit_64' DRB> Try to fiddle around with your include path, you probably don't want DRB> /usr/local/include to be in there. DRB> sshconnect1.c: In function `send_afs_tokens': DRB> sshconnect1.c:560: warning: implicit declaration of function `_IOW' DRB> sshconnect1.c:560: parse error before `struct' DRB> gmake: *** [sshconnect1.o] Error 1 DRB> patch to your krb-1.0.? installed include/kafs.h on Solaris: DRB> --- kafs.h~ Tue Dec 12 15:53:47 2000 DRB> +++ kafs.h Fri Dec 15 12:22:05 2000 DRB> @@ -36,6 +36,9 @@ DRB> #ifndef __KAFS_H DRB> #define __KAFS_H DRB> +/* need _IOW on Solaris , 15.12.00 JI */ DRB> +#include DRB> + DRB> /* XXX must include krb5.h or krb.h */ DRB> /* sys/ioctl.h must be included manually before kafs.h */ From Satish at coronanetworks.com Tue Jul 17 08:43:34 2001 From: Satish at coronanetworks.com (Satish Kikkeri) Date: Mon, 16 Jul 2001 15:43:34 -0700 Subject: INSTALL Message-ID: Hi , I'm new to openSSH and this environment as such. I had a few questions. 1. Do I need to follow the INSTALL to do the installation of the code. 2. Can I pick and choose the files (i.e., I only need the ssh client/agent/server and don't care much about the secureFTP and others).So, what are the files and the dependancies associated with this. 3. I tried to just compile the files in LIBSSH_OBJ, SSH_OBJ,SSHD_OBJ for the ssh part. Am I on the right track. Do I need anymore files. 4. Also, is config.h an "autogenerated file". How about the specific .h files like "openbsd_compat/.." files. I'm trying to port this to VxWorks. -Satish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010716/0dda3ec6/attachment.html From mouring at etoh.eviladmin.org Tue Jul 17 08:53:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 16 Jul 2001 17:53:31 -0500 (CDT) Subject: INSTALL In-Reply-To: Message-ID: On Mon, 16 Jul 2001, Satish Kikkeri wrote: > Hi , > I'm new to openSSH and this environment as such. I had a few questions. > 1. Do I need to follow the INSTALL to do the installation of the code. > 2. Can I pick and choose the files (i.e., I only need the ssh > client/agent/server and don't care much about the secureFTP and others).So, > what are the files and the dependancies associated with this. If you compile part of OpenSSH or all of OpenSSH. The 3 primary dependancies I told you before do not change. Your better off just getting './configure;make' working without dealing with "oh I want XYZ feature or PDQ feature".. It makes thing a lot easy on you. Plus it has a higher chance of getting back into the Portable CVS tree assuming the patches are tolerable. > 3. I tried to just compile the files in LIBSSH_OBJ, SSH_OBJ,SSHD_OBJ for the > ssh part. Am I on the right track. Do I need anymore files. and LIBCOMPAT > 4. Also, is config.h an "autogenerated file". How about the specific .h > files like "openbsd_compat/.." files. > You don't need to worry about openbsd-compat/ if you ran ./configure. Everything keys off the primary config.h file. I'm assuming that VxWorks has a POSIX enivornment or else this is going to be painful port. - Ben From slade at shore.net Tue Jul 17 12:03:11 2001 From: slade at shore.net (Richard E. Silverman) Date: Mon, 16 Jul 2001 22:03:11 -0400 Subject: OSSH configuration option bug Message-ID: <200107170203.WAA31051@syrinx.oankali.net> Giuliano Pochini writes: > --sysconfdir configuration option doesn't work. Yes, it does. > sshd always try to open its config files from > /usr/local/etc: > ... > Could not load host key: /usr/local/etc/ssh_host_key > Could not load host key: /usr/local/etc/ssh_host_rsa_key > Could not load host key: /usr/local/etc/ssh_host_dsa_key > Disabling protocol version 1. Could not load host key > Disabling protocol version 2. Could not load host key Just fix the HostKey paths in your sshd_config file. "make install" does not overwrite existing configuration files. - Richard From douglas.manton at uk.ibm.com Tue Jul 17 18:03:58 2001 From: douglas.manton at uk.ibm.com (Doug E Manton) Date: Tue, 17 Jul 2001 09:03:58 +0100 Subject: openssh keys in ldap Message-ID: > If the keys stay encrypted (not counting ssl) until ssh-add decrypts them (in the > same manner that it decrypts the private keys off the filesystem). Would we need to > trust the LDAP server or transport protocol. What problems would we encounter with > this? The private key encryption is a fallback position -- the first line of protection is to keep the key private! This is the same reason that most UNIX systems use shadow password files. If we rely on the key encryption, can we trust our users to select strong passphrases? We can't enforce passphrase rules because of the nature of key generation. Dictionary attacks demonstrate that users will do anything in their power to select poor passphrases! My personal preference is the exact opposite approach. Stick the private key onto some kind of smartcard. The ideal smartcard would run the SSH-agent itself and never reveal the key to anyone, you just initialise it with your passphrase before use -- and when you unplug it or a timeout occurs, it forgets the key and prompts upon next use. Doug. From Markus.Friedl at informatik.uni-erlangen.de Tue Jul 17 18:12:20 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 17 Jul 2001 10:12:20 +0200 Subject: openssh keys in ldap In-Reply-To: ; from douglas.manton@uk.ibm.com on Tue, Jul 17, 2001 at 09:03:58AM +0100 References: Message-ID: <20010717101220.A18238@faui02.informatik.uni-erlangen.de> On Tue, Jul 17, 2001 at 09:03:58AM +0100, Doug E Manton wrote: > My personal preference is the exact opposite approach. Stick the private > key onto some kind of smartcard. The ideal smartcard would run the > SSH-agent itself and never reveal the key to anyone, you just initialise > it with your passphrase before use -- and when you unplug it or a timeout > occurs, it forgets the key and prompts upon next use. there is limited support for this on OpenSSH on OpenBSD-current. you don't need to run the agent on the smartcard, but you can hide the card behind the agent, and even use the card remotely. -m From vinschen at redhat.com Tue Jul 17 19:20:11 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 17 Jul 2001 11:20:11 +0200 Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password In-Reply-To: <20010711223754.D29492@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Jul 11, 2001 at 10:37:54PM +0200 References: <20010711223754.D29492@cygbert.vinschen.de> Message-ID: <20010717112011.M25442@cygbert.vinschen.de> On Wed, Jul 11, 2001 at 10:37:54PM +0200, Corinna Vinschen wrote: > Hi, > > the following patch checks if OpenSSH is running under a Cygwin > version >= 1.3.2 which allows switching user context without password. > Otherwise sshd allows changing the user context only if password > authentication is used as it was before. > > Corinna > [...] Just a question: Does nobody review/apply patches at the moment? Vacation time? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Tue Jul 17 22:23:17 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Jul 2001 22:23:17 +1000 (EST) Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password In-Reply-To: <20010717112011.M25442@cygbert.vinschen.de> Message-ID: On Tue, 17 Jul 2001, Corinna Vinschen wrote: > On Wed, Jul 11, 2001 at 10:37:54PM +0200, Corinna Vinschen wrote: > > Hi, > > > > the following patch checks if OpenSSH is running under a Cygwin > > version >= 1.3.2 which allows switching user context without password. > > Otherwise sshd allows changing the user context only if password > > authentication is used as it was before. > > > > Corinna > > [...] > > Just a question: Does nobody review/apply patches at the moment? > Vacation time? Just busy - if you don't get a response, try resending with a gentle reminder. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From vinschen at redhat.com Tue Jul 17 22:26:48 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 17 Jul 2001 14:26:48 +0200 Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password In-Reply-To: ; from djm@mindrot.org on Tue, Jul 17, 2001 at 10:23:17PM +1000 References: <20010717112011.M25442@cygbert.vinschen.de> Message-ID: <20010717142648.A730@cygbert.vinschen.de> On Tue, Jul 17, 2001 at 10:23:17PM +1000, Damien Miller wrote: > On Tue, 17 Jul 2001, Corinna Vinschen wrote: > > > On Wed, Jul 11, 2001 at 10:37:54PM +0200, Corinna Vinschen wrote: > > > Hi, > > > > > > the following patch checks if OpenSSH is running under a Cygwin > > > version >= 1.3.2 which allows switching user context without password. > > > Otherwise sshd allows changing the user context only if password > > > authentication is used as it was before. > > > > > > Corinna > > > [...] > > > > Just a question: Does nobody review/apply patches at the moment? > > Vacation time? > > Just busy - if you don't get a response, try resending with a gentle > reminder. Thanks, I was really thinking that vacation is swamping people (which wouldn't be too bad, though ;-)) Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mouring at etoh.eviladmin.org Tue Jul 17 23:18:47 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 17 Jul 2001 08:18:47 -0500 (CDT) Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password In-Reply-To: <20010717142648.A730@cygbert.vinschen.de> Message-ID: On Tue, 17 Jul 2001, Corinna Vinschen wrote: > On Tue, Jul 17, 2001 at 10:23:17PM +1000, Damien Miller wrote: > > On Tue, 17 Jul 2001, Corinna Vinschen wrote: > > > > > On Wed, Jul 11, 2001 at 10:37:54PM +0200, Corinna Vinschen wrote: > > > > Hi, > > > > > > > > the following patch checks if OpenSSH is running under a Cygwin > > > > version >= 1.3.2 which allows switching user context without password. > > > > Otherwise sshd allows changing the user context only if password > > > > authentication is used as it was before. > > > > > > > > Corinna > > > > [...] > > > > > > Just a question: Does nobody review/apply patches at the moment? > > > Vacation time? > > > > Just busy - if you don't get a response, try resending with a gentle > > reminder. > > Thanks, I was really thinking that vacation is swamping people > (which wouldn't be too bad, though ;-)) > They are not forgotten.=) Yours and 79 other emails are piled up in my inbox that are shouting for review and applying. Just finding time to get back to doing anything useful is a killer right now. - Ben From strube at physik3.gwdg.de Wed Jul 18 00:33:41 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Tue, 17 Jul 2001 16:33:41 +0200 (MET DST) Subject: openssh-2.9p2, compat.c Message-ID: <200107171433.QAA05849@marc.physik3.gwdg.de> The most recent SSH versions 1.2.30, 1.2.31, 2.4.0, 3.0.0 from ssh.com have no entries in the table check[] in compat.c. Are these not required or have the compatibility properties of the versions not yet been evaluated? Hans Werner Strube strube at physik3.gwdg.de Drittes Physikalisches Institut, Univ. Goettingen Buergerstr. 42-44, D-37073 Goettingen, Germany From austin at coremetrics.com Wed Jul 18 04:55:17 2001 From: austin at coremetrics.com (Gonyou, Austin) Date: Tue, 17 Jul 2001 13:55:17 -0500 Subject: Kerberos Books/Documents Message-ID: <85063BBE668FD411944400D0B744267A643437@AUSMAIL> Hey all, I've tried kerberizing SSH but I can't get it to login. I've read a lot of documentation, but I wish I could find a "cook-book" type of setup or how-to to get this beast working correctly, or to at least verify it's working per a specification. With that, I'm interested in what books/docs/etc does anyone recommend to get a good understanding of: 1. Kerberos implementations in general 2. Kerberizing SSH to work in that type of environment 3. Utilizing SSH in a kerberized environment ANY help on this is much appreciated. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin at coremetrics.com From vincent.lonngren at telia.com Wed Jul 18 05:02:51 2001 From: vincent.lonngren at telia.com (vincent.lonngren at telia.com) Date: Tue, 17 Jul 2001 21:02:51 +0200 (CEST) Subject: openssh and QNX Message-ID: <200107171902.f6HJ2p008803@d1o32.telia.com> Hi. I have compiled openssh on QNX RTP 6.1, "x86-pc-nto-qnx". Some things to note if anyone should want to update configure and include support for this platform: * The enthropy device is normally /dev/random * INTXX and other similar types are in * macro howmany, constant NFDBITS and type fd_mask need to be defined. How this can be done has been discussed earlier on this list. * USE_PIPES needs to be defined - socketpair() doesn't seem to be implemented yet. * file /usr/adm/lastlog needs to be created, if it hasn't been already - touch is sufficient. I hope someone has use for this information, making this posting more than spam. -- Vincent L??nngren From mouring at etoh.eviladmin.org Wed Jul 18 06:44:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 17 Jul 2001 15:44:54 -0500 (CDT) Subject: openssh and QNX In-Reply-To: <200107171902.f6HJ2p008803@d1o32.telia.com> Message-ID: If you could submit a diff -u patch of the requires changes. It would greatly speed up the process. I know since I don't have QNX anywhere that I'm a bit leary to bindly make changes for that platform. - Ben On Tue, 17 Jul 2001 vincent.lonngren at telia.com wrote: > Hi. > > I have compiled openssh on QNX RTP 6.1, "x86-pc-nto-qnx". Some things to note if anyone should want to update configure and include support for this platform: > > * The enthropy device is normally /dev/random > * INTXX and other similar types are in > * macro howmany, constant NFDBITS and type fd_mask need to be defined. How this can be done has been discussed earlier on this list. > * USE_PIPES needs to be defined - socketpair() doesn't seem to be implemented yet. > * file /usr/adm/lastlog needs to be created, if it hasn't been already - touch is sufficient. > > I hope someone has use for this information, making this posting more than spam. > > -- > Vincent L??nngren > From markus.friedl at informatik.uni-erlangen.de Wed Jul 18 08:23:10 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Wed, 18 Jul 2001 00:23:10 +0200 Subject: openssh-2.9p2, compat.c In-Reply-To: <200107171433.QAA05849@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Tue, Jul 17, 2001 at 04:33:41PM +0200 References: <200107171433.QAA05849@marc.physik3.gwdg.de> Message-ID: <20010718002310.A22113@folly> On Tue, Jul 17, 2001 at 04:33:41PM +0200, Hans Werner Strube wrote: > The most recent SSH versions 1.2.30, 1.2.31, 2.4.0, 3.0.0 from ssh.com > have no entries in the table check[] in compat.c. Are these not required > or have the compatibility properties of the versions not yet been evaluated? do they introduce unkown bugs? From buckh at pobox.com Wed Jul 18 10:15:05 2001 From: buckh at pobox.com (Buck Huppmann) Date: Tue, 17 Jul 2001 20:15:05 -0400 Subject: configure: sense of --enable-utmpx test et al. reversed Message-ID: <20010717201505.A31148@dsl-64-192-58-194.telocity.com> it seems that --enable-utmpx and friends have the effect of disabling the corresponding feature (i.e., #define-ing DISABLE_UTMPX etc.), which leads to the (perhaps not so) obvious breakage of UseLogin on Solaris etc. For the less anal (or reformed anal) configure-r who leaves these unspecified, everything is OK i'd suggest changes to configure.in, but i'm blissfully ignorant of autoconf. suffice it to say, despite the help text arguments, these macro invocations seem suspect: ^dnl allow user to disable some login recording features AC_ARG_ENABLE(lastlog, [ --disable-lastlog disable use of lastlog even if detected [no]], [ AC_DEFINE(DISABLE_LASTLOG) ] ) AC_ARG_ENABLE(utmp, [ --disable-utmp disable use of utmp even if detected [no]], [ AC_DEFINE(DISABLE_UTMP) ] ) AC_ARG_ENABLE(utmpx, [ --disable-utmpx disable use of utmpx even if detected [no]], [ AC_DEFINE(DISABLE_UTMPX) ] ) etc. other than this complaint (assuming it's valid and that i'm not crocked), i'm an immensely satisfied customer--thanks very much, folks From yozo at imit.chiba-u.ac.jp Wed Jul 18 12:14:00 2001 From: yozo at imit.chiba-u.ac.jp (Yozo TODA) Date: Wed, 18 Jul 2001 11:14:00 +0900 Subject: Kerberos Books/Documents In-Reply-To: Your message of "Tue, 17 Jul 2001 13:55:17 JST." <85063BBE668FD411944400D0B744267A643437@AUSMAIL> Message-ID: <200107180214.f6I2E0R16795@aohakobe.imit.chiba-u.ac.jp> I have no experience with kerberized ssh, but... > a specification. With that, I'm interested in what books/docs/etc does > anyone recommend to get a good understanding of: > > 1. Kerberos implementations in general > 2. Kerberizing SSH to work in that type of environment > 3. Utilizing SSH in a kerberized environment OpenBSD FAQ 10.11 (http://www.openbsd.org/faq/faa10.html#10.11) describes kerberosIV server/client setup. some links to other docs there. (wow, which OS and which version of openssh you're using?) your first step should be setting up kerberized telnet/rlogin etc. I suppose it helps your understanding of kerberos environment. check if kerberos server/client setup is done correctly. and the next step is reading ssh manpage and examining configuration options again. I believe you already read ssh and sshd manpage many times (-: -- yozo. From jakob at crt.se Wed Jul 18 20:32:01 2001 From: jakob at crt.se (Jakob Schlyter) Date: Wed, 18 Jul 2001 12:32:01 +0200 (MEST) Subject: openssh keys in ldap In-Reply-To: <3B52F720.4F43DF26@dtgnet.com> Message-ID: On Mon, 16 Jul 2001, jeff mcelroy wrote: > Is there any work going into placing keys in a central directory such as > LDAP ? I see a problem with finding out what ldap server that has the key for host.example.com? and then communicate securly and fast enough with that server. I would rather consider the dnssec support to be the preferred key distribution mechanism in the future. jakob, dnssec advocate From pekkas at netcore.fi Wed Jul 18 21:23:51 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 18 Jul 2001 14:23:51 +0300 (EEST) Subject: openssh keys in ldap In-Reply-To: Message-ID: On Wed, 18 Jul 2001, Jakob Schlyter wrote: > On Mon, 16 Jul 2001, jeff mcelroy wrote: > > > Is there any work going into placing keys in a central directory such as > > LDAP ? > > I see a problem with finding out what ldap server that has the key for > host.example.com? and then communicate securly and fast enough with that > server. > > I would rather consider the dnssec support to be the preferred key > distribution mechanism in the future. I think the original meant placing keys of all servers _within organization_ to a central _internal_ directory. This is what I though of it at any rate. For "global" secure key access, dnssec is the way to go (if you want to put them in a database at any rate, and can proof the transaction). -- 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 jmcelroy at dtgnet.com Thu Jul 19 00:11:02 2001 From: jmcelroy at dtgnet.com (jeff mcelroy) Date: Wed, 18 Jul 2001 09:11:02 -0500 Subject: openssh keys in ldap References: Message-ID: <3B5598F6.21B4C9@dtgnet.com> Pekka Savola wrote: > On Wed, 18 Jul 2001, Jakob Schlyter wrote: > > On Mon, 16 Jul 2001, jeff mcelroy wrote: > > > > > Is there any work going into placing keys in a central directory such as > > > LDAP ? > > > > I see a problem with finding out what ldap server that has the key for > > host.example.com? and then communicate securly and fast enough with that > > server. > > > > I would rather consider the dnssec support to be the preferred key > > distribution mechanism in the future. > > I think the original meant placing keys of all servers _within > organization_ to a central _internal_ directory. > > This is what I though of it at any rate. > > For "global" secure key access, dnssec is the way to go (if you want to > put them in a database at any rate, and can proof the transaction). > > -- > 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 We have openssh deployed accross our organization and have to add/remove entries into the known_hosts / authorized_keys files often. I am looking for a way to centrally manage these keys. Jeff McElroy jmcelroy at dtgnet.com From mouring at etoh.eviladmin.org Thu Jul 19 02:14:56 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 18 Jul 2001 11:14:56 -0500 (CDT) Subject: [PATCH]: Cygwin: Allow sshd to switch user context without password In-Reply-To: <20010711223754.D29492@cygbert.vinschen.de> Message-ID: Applied. Along with the document/ssh-host-config update. Thanks. On Wed, 11 Jul 2001, Corinna Vinschen wrote: > Hi, > > the following patch checks if OpenSSH is running under a Cygwin > version >= 1.3.2 which allows switching user context without password. > Otherwise sshd allows changing the user context only if password > authentication is used as it was before. > > Corinna > > Index: openbsd-compat/bsd-cygwin_util.c > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v > retrieving revision 1.4 > diff -u -p -r1.4 bsd-cygwin_util.c > --- openbsd-compat/bsd-cygwin_util.c 2001/04/13 14:28:42 1.4 > +++ openbsd-compat/bsd-cygwin_util.c 2001/07/11 20:35:40 > @@ -21,10 +21,14 @@ RCSID("$Id: bsd-cygwin_util.c,v 1.4 2001 > > #include > #include > +#include > #include > #include > #define is_winnt (GetVersion() < 0x80000000) > > +#define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) > +#define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) > + > #if defined(open) && open == binary_open > # undef open > #endif > @@ -61,12 +65,34 @@ int check_nt_auth(int pwd_authenticated, > * context on NT systems is the password authentication. So > * we deny all requsts for changing the user context if another > * authentication method is used. > - * This may change in future when a special openssh > - * subauthentication package is available. > + * > + * This doesn't apply to Cygwin versions >= 1.3.2 anymore which > + * uses the undocumented NtCreateToken() call to create a user > + * token if the process has the appropriate privileges and if > + * CYGWIN ntsec setting is on. > */ > - if (is_winnt && !pwd_authenticated && geteuid() != uid) > - return 0; > - > + static int has_create_token = -1; > + > + if (is_winnt) { > + if (has_create_token < 0) { > + struct utsname uts; > + int major_high = 0, major_low = 0, minor = 0; > + char *cygwin = getenv("CYGWIN"); > + > + has_create_token = 0; > + if (ntsec_on(cygwin) && !uname(&uts)) { > + sscanf(uts.release, "%d.%d.%d", > + &major_high, &major_low, &minor); > + if (major_high > 1 || > + (major_high == 1 && (major_low > 3 || > + (major_low == 3 && minor >= 2)))) > + has_create_token = 1; > + } > + } > + if (has_create_token < 1 && > + !pwd_authenticated && geteuid() != uid) > + return 0; > + } > return 1; > } > > @@ -82,12 +108,9 @@ int check_ntsec(const char *filename) > return 0; > > /* Evaluate current CYGWIN settings. */ > - if ((cygwin = getenv("CYGWIN")) != NULL) { > - if (strstr(cygwin, "ntea") && !strstr(cygwin, "nontea")) > - allow_ntea = 1; > - if (strstr(cygwin, "ntsec") && !strstr(cygwin, "nontsec")) > - allow_ntsec = 1; > - } > + cygwin = getenv("CYGWIN"); > + allow_ntea = ntea_on(cygwin); > + allow_ntsec = ntsec_on(cygwin); > > /* > * `ntea' is an emulation of POSIX attributes. It doesn't support > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com > From slade at shore.net Thu Jul 19 13:07:09 2001 From: slade at shore.net (Richard E. Silverman) Date: Wed, 18 Jul 2001 23:07:09 -0400 Subject: Kerberos Books/Documents Message-ID: <200107190307.XAA20821@syrinx.oankali.net> The O'Reilly SSH book -- "SSH, The Secure Shell (The Definitive Guide)" written by myself and Dan Barrett -- contains a chapter on using Kerberos with SSH. -- Richard Silverman slade at shore.net From Markus.Friedl at informatik.uni-erlangen.de Thu Jul 19 19:09:55 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 19 Jul 2001 11:09:55 +0200 Subject: 2.9p?: connection hangs with agent forwarding In-Reply-To: <3B56A179.3323086C@hp.com>; from Christophe_Moret@hp.com on Thu, Jul 19, 2001 at 10:59:37AM +0200 References: <20010703174609.A24341@serv01.aet.tu-cottbus.de> <20010704152054.A6874@ws01.aet.tu-cottbus.de> <20010704154233.A16767@faui02.informatik.uni-erlangen.de> <3B56A179.3323086C@hp.com> Message-ID: <20010719110955.B20330@faui02.informatik.uni-erlangen.de> On Thu, Jul 19, 2001 at 10:59:37AM +0200, Christophe Moret wrote: > > Yes, this problem is deterministic for all channels forwarded while using USE_PIPES. > It exists since all versions of OpenSSH & even in ssh 1.2.2x, except for X11 forwarding > where a patch has been made in 1.2.2x. > > This was the reason of my old 'back connection problem' patch that I sent some times > ago, that was never integrated (see attached). i remember that the patch did change the protocol on the wire. -m From Christophe_Moret at hp.com Thu Jul 19 19:11:55 2001 From: Christophe_Moret at hp.com (Christophe Moret) Date: Thu, 19 Jul 2001 11:11:55 +0200 Subject: 2.9p?: connection hangs with agent forwarding References: <20010703174609.A24341@serv01.aet.tu-cottbus.de> <20010704152054.A6874@ws01.aet.tu-cottbus.de> <20010704154233.A16767@faui02.informatik.uni-erlangen.de> <3B56A179.3323086C@hp.com> <20010719110955.B20330@faui02.informatik.uni-erlangen.de> Message-ID: <3B56A45B.9C8E662F@hp.com> Yes, but it was compatible with other versions (did not break) and was the only way I found to actually correct this very ennoying problem. Of course if you have another solution... -Christophe Markus Friedl wrote: > On Thu, Jul 19, 2001 at 10:59:37AM +0200, Christophe Moret wrote: > > > > Yes, this problem is deterministic for all channels forwarded while using USE_PIPES. > > It exists since all versions of OpenSSH & even in ssh 1.2.2x, except for X11 forwarding > > where a patch has been made in 1.2.2x. > > > > This was the reason of my old 'back connection problem' patch that I sent some times > > ago, that was never integrated (see attached). > > i remember that the patch did change the protocol on the wire. > > -m -- Christophe Moret mailto:Christophe_Moret at hp.com Hewlett Packard Phone :+33 4 76 14 40 78 5, avenue Raymond Chanas Fax :+33 4 76 14 47 06 38053 GRENOBLE Cedex 09 Mobile:+33 6 72 99 16 51 -------------- next part -------------- A non-text attachment was scrubbed... Name: Christophe_Moret.vcf Type: text/x-vcard Size: 377 bytes Desc: Card for Christophe Moret Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010719/74c696e3/attachment.vcf From uwin at wipro.com Thu Jul 19 23:32:26 2001 From: uwin at wipro.com (Wipro UWIN) Date: Thu, 19 Jul 2001 19:02:26 +0530 Subject: ssh not recognising ssl libraries Message-ID: <010501c11057$403922d0$decda8c0@wipro.com> Hi all, We are in the process of compiling OpenSSH for our product UWIN which is very similar to cygwin. ======================================================= Here is a brief description about UWIN: Wipro UWIN is a Unix to Windows migration toolkit that gives you most features of a traditional Unix operating system on Windows NT and Windows 95/98. Features include pipes, hard file links, Unix networking, and Unix graphical support through the X Window System. UWIN also provides Unix and POSIX.2 utilities such as ksh, awk, and vi. The UWIN environment is a User-mode runtime library, which works over the Win32 subsystem. Shell scripts and other scripted applications that use Unix and POSIX.2 utilities will run under UWIN. Support is also provided for work on a Windows NT system remotely through a Telnet session. ======================================================= We could get the binaries of SSL & installed it. But we are getting an error, "could not find ssl library". ======================================================= checking for OpenSSL directory... configure: error: Could not find working Open SSL library, please install or check config.log ======================================================= We also tried giving the path from configure: $./configure --with-ssl-dir=/usr/local/openssl where /usr/local/openssl is the directory which contains the include, bin & lib files. but still the same problem continous. Any suggestion in compiling Openssh will be of immense help to us. Thanks in advance _________________________________ Wipro UWIN Support Team E & I Solutions, Wipro Technologies No.8, 7th Main, 1st Block, Koramangala, Bangalore - 34 Tel : +91-80-5525125/2 Ext.1042 Fax : +91-80-5530085 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Wipro_Disclaimer.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010719/718a25d5/attachment.txt From Florian.Weimer at RUS.Uni-Stuttgart.DE Fri Jul 20 02:46:09 2001 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: 19 Jul 2001 18:46:09 +0200 Subject: ssh not recognising ssl libraries In-Reply-To: <010501c11057$403922d0$decda8c0@wipro.com> ("Wipro UWIN"'s message of "Thu, 19 Jul 2001 19:02:26 +0530") References: <010501c11057$403922d0$decda8c0@wipro.com> Message-ID: "Wipro UWIN" writes: > We could get the binaries of SSL & installed it. > But we are getting an error, "could not find ssl library". > > ======================================================= > checking for OpenSSL directory... configure: error: Could not find working > Open > SSL library, please install or check config.log > ======================================================= Perhaps you should follow the second part of the suggestion ('check config.log')? -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From mouring at etoh.eviladmin.org Fri Jul 20 05:18:52 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 19 Jul 2001 14:18:52 -0500 (CDT) Subject: Fwd:Re:Announce: Building and Deploying OpenSSH on the Solar (fwd) Message-ID: I figured I'd forward this on in case someone needs a Sun article talking about OpenSSH deployment. - Ben ---------- Forwarded message ---------- Date: Thu, 19 Jul 2001 09:38:35 -0400 From: Alex Noordergraaf To: Focus on Sun Mailing List Subject: Announce: Building and Deploying OpenSSH on the Solaris OE A BluePrint OnLine article was published, this past weekend, in the July issue titled: Building and Deploying OpenSSH on the Solaris Operating Environment I'm sure all of you are aware of OpenSSH and if you have ever tried to compile it you know what happened. Dealing with isssues about which compiler to use (gcc or Forte), compile options, downloading all the different versions, etc. This BluePrint OnLine article provides detailed instructions on how to download and compile the required OpenSSH packages in addition to providing scripts to simplify making an OpenSSH package from the final compiled result and startup the appropriate daemons. Jason Reid and Keith Watson did a great job putting this together by bringing their experience with compilers, software distribution, script development, and security software to bear when putting this article together. Many thanks guys! The article is available at: http://www.sun.com/blueprints/0701/openSSH.html The HTML version will only be available until next month. The PDF version will, however, be archived indefinately at: http://www.sun.com/blueprints/0701/openSSH.pdf -Alex -- Alex Noordergraaf (voice) 781.442.3447 Enterprise Eng - Sr Staff Eng (email) alex.noordergraaf at sun.com http://www.sun.com/blueprints/browsesubject.html#security Received: from pcwiwb.wiwb.uscourts.gov ([156.126.44.254]) by mailgate.dcn.uscourts.gov with SMTP (IMA Internet Exchange 3.13) id 0026399F; Thu, 19 Jul 2001 14:10:34 -0400 Received: by pcwiwb.wiwb.uscourts.gov (Smail3.1.28.1 #2) id m15NIVr-00007lC; Thu, 19 Jul 101 13:27 CDT Date: Thu, 19 Jul 2001 13:27:03 -0500 From: Andy Bach To: Ben Lindstrom cc: Larry Bamford Subject: Announce: Building and Deploying OpenSSH on the Solaris OE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From Satish at coronanetworks.com Fri Jul 20 09:37:55 2001 From: Satish at coronanetworks.com (Satish Kikkeri) Date: Thu, 19 Jul 2001 16:37:55 -0700 Subject: This is what I get when I try to install openssh Message-ID: checking for OpenSSL directory... configure: error: Could not find working OpenSSL library, please install or check config.log Now if I go and check the config.log file I have this as error. This is for solaris 2.6/2.7OS configure:4354: checking for OpenSSL directory configure:4411: gcc -o conftest -g -O2 -Wall -I/usr/local/include -I/usr/local/ssl/ include -I/opt/TWWfsw/zlib11/include -L/usr/local/lib -R/usr/local/lib -L/usr/lib - R/usr/lib -L/opt/TWWfsw/zlib11/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib conftes t.c -lz -lsocket -lnsl -lgen -lcrypto 1>&5 Undefined first referenced symbol in file dlclose /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy mbol belongs to implicit dependency /usr/lib/libdl.so.1) dlsym /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy mbol belongs to implicit dependency /usr/lib/libdl.so.1) dlopen /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy mbol belongs to implicit dependency /usr/lib/libdl.so.1) ld: fatal: Symbol referencing errors. No output written to conftest configure: failed program was: #line 4397 "configure" #include "confdefs.h" #include #include int main(void) { char a[2048]; memset(a, 0, sizeof(a)); RAND_add(a, sizeof(a), sizeof(a)); return(RAND_status() <= 0); } Now, I wanted to try on the linux. And I get this error when loading the linux portable code (taken from openssh.com's linux ). What is the link error here. Has anyone had this problem. configure:4385: checking for OpenSSL directory configure:4442: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/include -I/usr/local/ssl/include -L/usr/local/lib -L/usr/local/ss l/lib conftest.c -lz -lnsl -lutil -lcrypto 1>&5 /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': dso_dlfcn.o(.text+0x8e): undefined reference to `dlopen' dso_dlfcn.o(.text+0xa4): undefined reference to `dlopen' dso_dlfcn.o(.text+0x10a): undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': dso_dlfcn.o(.text+0x1d2): undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': dso_dlfcn.o(.text+0x283): undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': dso_dlfcn.o(.text+0x353): undefined reference to `dlsym' configure: failed program was: #line 4428 "configure" #include "confdefs.h" Any help would be appreciated Regards, Satish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010719/f0d08824/attachment.html From Phil.Pennock at globnix.org Fri Jul 20 11:22:43 2001 From: Phil.Pennock at globnix.org (Phil Pennock) Date: Fri, 20 Jul 2001 03:22:43 +0200 Subject: Updated chroot patch Message-ID: <20010720032243.A19332@globnix.org> This is the patch part of contrib/chroot.diff updated to be appliable against openssh-2.9p2. Tested on FreeBSD (various 3.x and 4.x) without PAM or UseLogin. Also, as part of deployment (replacing emergency-withdrawal of Telnet access) I've chosen to get sftp on the relevant boxes. The deployment had a scriptlet doing the config/make/etc and after the "make install" would change Makefile to tack " -static" onto LDFLAGS and set EXEEXT=.static -- this binary, installed stripped inside the chroot'd environment, appears to work gorgeously. :^) Thanks for the hard work on OpenSSH. -----------------------------< cut here >------------------------------- --- session.c.orig Sun Jun 17 05:40:51 2001 +++ session.c Fri Jul 20 01:40:33 2001 @@ -93,6 +93,9 @@ # include #endif +/* support /./ in homedir */ +#define DOT_CHROOT + /* types */ #define TTYSZ 64 @@ -1037,6 +1040,10 @@ extern char **environ; struct stat st; char *argv[10]; +#ifdef DOT_CHROOT + char *user_dir; + char *new_root; +#endif int do_xauth = s->auth_proto != NULL && s->auth_data != NULL; #ifdef WITH_IRIX_PROJECT prid_t projid; @@ -1093,6 +1100,25 @@ # ifdef HAVE_GETUSERATTR set_limits_from_userattr(pw->pw_name); # endif /* HAVE_GETUSERATTR */ +# ifdef DOT_CHROOT + user_dir = xstrdup(pw->pw_dir); + new_root = user_dir + 1; + + while((new_root = strchr(new_root, '.')) != NULL) { + new_root--; + if(strncmp(new_root, "/./", 3) == 0) { + *new_root = '\0'; + new_root += 2; + + if(chroot(user_dir) != 0) + fatal("Couldn't chroot to user directory %s", user_dir); + + pw->pw_dir = new_root; + break; + } + new_root += 2; + } +# endif /* DOT_CHROOT */ # ifdef HAVE_LOGIN_CAP if (setusercontext(lc, pw, pw->pw_uid, (LOGIN_SETALL & ~LOGIN_SETPATH)) < 0) { -----------------------------< cut here >------------------------------- -- Civilisation: where they cut down the trees and name streets after them. From packard at mail2.jpl.nasa.gov Fri Jul 20 13:54:18 2001 From: packard at mail2.jpl.nasa.gov (packard) Date: Thu, 19 Jul 2001 20:54:18 -0700 (PDT) Subject: Haven't seen answer yet (was newbie man on Solaris question) Message-ID: On Thu, 3 May 2001, Gus Mancuso wrote: I haven't seen the answer to this question (included way below) yet. I'm installing it on Solaris 8 and have the same problem - I can't read the man pages in any format other than 80 column wrapped text. The Solaris 8 is pretty generic, with all the current patches. OpenSSH version is 2.9p1. The man pages stored in /usr/local/man/manx are formatted in something that looks different from the OEM Solaris man pages, even though the top of the file includes the commend "nroff". Regards, Scott > Hello OpenSSH developers > > First, many thanks for producing this app! > > I've noticed that the man pages for openssh don't look > at all like man pages. My somewhat limited > troubleshooting skills point towards a problem with > nroff not expanding the macros embedded in the man > files. > When I `man sshd`, I get pure text (No > bold/underlined, or even recognizable man page > sections) and "incomplete sentences" (probably a > result of those same nroff macros not being expanded). > > > I am using Solaris 7 on Sun Ultra450 and Ultra250 > servers, both of which exhibit the same problem. > uname -a results for both machines: > > SunOS xmnsas03 5.7 Generic_106541-08 sun4u sparc > SUNW,Ultra-4 > > I can't find any version info for nroff.. sorry. > > attached is the text I receive from `man sshd` > > Which OpenSSH release? Under the latest 2.9p1 it should autodetect if you can support 'mdoc' format (what most BSD used), and if it can't it will convert them to 'man' (SysV style) or step down to 'doc' (preformated). From packard at mail2.jpl.nasa.gov Fri Jul 20 14:06:29 2001 From: packard at mail2.jpl.nasa.gov (packard) Date: Thu, 19 Jul 2001 21:06:29 -0700 (PDT) Subject: Man question - disregard Message-ID: Please disregard my post from a few minutes ago. I found an earler question that solved the problem (the doc2man.pl script). What I'd done was build a working version on one machine, then build a Solaris package of that (using contrib/solaris), moved it to another host then pkgadd the package. That's when I got into trouble. Looks like I'm going to have to do some postinstall to run that Perl script. Regards, Scott From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Jul 20 19:41:26 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 20 Jul 2001 11:41:26 +0200 Subject: This is what I get when I try to install openssh In-Reply-To: ; from Satish@coronanetworks.com on Thu, Jul 19, 2001 at 04:37:55PM -0700 References: Message-ID: <20010720114126.D2774@serv01.aet.tu-cottbus.de> On Thu, Jul 19, 2001 at 04:37:55PM -0700, Satish Kikkeri wrote: > checking for OpenSSL directory... configure: error: Could not find working > OpenSSL library, please install or check config.log > > Now if I go and check the config.log file I have this as error. > This is for solaris 2.6/2.7OS > > configure:4354: checking for OpenSSL directory > configure:4411: gcc -o conftest -g -O2 -Wall -I/usr/local/include > -I/usr/local/ssl/ > include -I/opt/TWWfsw/zlib11/include -L/usr/local/lib -R/usr/local/lib > -L/usr/lib - > R/usr/lib -L/opt/TWWfsw/zlib11/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib > conftes > t.c -lz -lsocket -lnsl -lgen -lcrypto 1>&5 > Undefined first referenced > symbol in file > dlclose > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy > mbol belongs to implicit dependency /usr/lib/libdl.so.1) > dlsym > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy > mbol belongs to implicit dependency /usr/lib/libdl.so.1) > dlopen > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o) (sy > mbol belongs to implicit dependency /usr/lib/libdl.so.1) > ld: fatal: Symbol referencing errors. No output written to conftest > configure: failed program was: ... Obviously the OpenSSL library installed requires a shared library "/usr/lib/libdl.so.1" to work correctly. This library seems to be absent on your system. Probably the openssl library was compiled in another system and then copied to this one? Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From pekkas at netcore.fi Fri Jul 20 20:22:24 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 20 Jul 2001 13:22:24 +0300 (EEST) Subject: data loss with ssh -n Message-ID: Hi, Using OpenSSH 2.9p2 (2.5.2 was also bad), I've noticed data loss on Linux when: 1) ssh -n flag is used, and 2) ssh jobs are run from cron (effectively causing the same as above). What is done, is a command basically like: ssh [-n] -c blowfish -p 722 -i rsakey -l pwget passwdserver passwd > passwd.tmp 2> /tmp/log ie, retrieve dynamically created passwd-file from passwdserver using rsa keys. The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't be changed at the moment). The diff of ssh -v -v -v is: --- log Fri Jul 20 13:18:42 2001 +++ log.cron Fri Jul 20 13:02:01 2001 @@ -41,13 +41,12 @@ debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 -debug1: Requesting X11 forwarding with authentication spoofing. -debug1: Remote: X11 forwarding disabled in server configuration file. -Warning: Remote host denied X11 forwarding. debug1: Sending command: passwd debug1: Entering interactive session. +debug1: fd 0 setting O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug1: fd 2 setting O_NONBLOCK -debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.6 seconds -debug1: Bytes per second: stdin 0.0, stdout 95576.3, stderr 0.0 +debug1: Sending eof. +debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.5 seconds +debug1: Bytes per second: stdin 0.0, stdout 100654.4, stderr 0.0 debug1: Exit status 0 When run from cron, or with -n, you get "Sending eof." which truncates the data. Any ideas? -- 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 dankamin at cisco.com Fri Jul 20 21:00:30 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Fri, 20 Jul 2001 04:00:30 -0700 Subject: data loss with ssh -n References: Message-ID: <004501c1110b$311cfba0$ca2746ab@na.cisco.com> > The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't > be changed at the moment). Wellllll...there's this cute little trick that works because of SSHD's blissful lack of root dependancy: ssh -o 'ProxyCommand ssh user at host openssh/sshd -i' user at host Two conclusions to reach from this trick: 1) I have way too much fun with ProxyCommand 2) Unless you give a user a *really* restricted shell, sshd_config will *never* be the right place to put your security constraints. As for the larger issues...does the incorrect buffering behavior still manifest itself without the -n? In SSH1 and SSH2? With and without TTY? Yours Truly, Dan Kaminsky, CISSP www.doxpara.com From pekkas at netcore.fi Fri Jul 20 21:24:58 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 20 Jul 2001 14:24:58 +0300 (EEST) Subject: data loss with ssh -n In-Reply-To: <004501c1110b$311cfba0$ca2746ab@na.cisco.com> Message-ID: On Fri, 20 Jul 2001, Dan Kaminsky wrote: > 1) I have way too much fun with ProxyCommand > 2) Unless you give a user a *really* restricted shell, sshd_config will > *never* be the right place to put your security constraints. Perhaps these should be restricteable. > As for the larger issues...does the incorrect buffering behavior still > manifest itself without the -n? In SSH1 and SSH2? With and without TTY? As for SSH2, I don't know unfortunately. Impossible to test at the moment. I could try to get this done if there aren't any other ways to trace the problem. So, with SSH1 (tried all combinations of -, -t, -n, -t -n): When run as user, problem _appears to_ exist only if: 1) -n When run from cron, problem _appears to_ exist always except if: 1) -t (I wouldn't call the tests scientific, but should give the idea) So there's a hack of using '-t' as a workaround; it works with both. -- 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 pekkas at netcore.fi Fri Jul 20 21:39:46 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 20 Jul 2001 14:39:46 +0300 (EEST) Subject: data loss with ssh -n In-Reply-To: Message-ID: On Fri, 20 Jul 2001, Pekka Savola wrote: > So, with SSH1 (tried all combinations of -, -t, -n, -t -n): > > When run as user, problem _appears to_ exist only if: > 1) -n > > When run from cron, problem _appears to_ exist always except if: > 1) -t > > (I wouldn't call the tests scientific, but should give the idea) > > So there's a hack of using '-t' as a workaround; it works with both. It's good that I didn't say scientific, as I can't get "ssh -t in cron" workaround to work anymore.. :-/ -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From Markus.Friedl at informatik.uni-erlangen.de Fri Jul 20 21:50:26 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Fri, 20 Jul 2001 13:50:26 +0200 Subject: data loss with ssh -n In-Reply-To: ; from pekkas@netcore.fi on Fri, Jul 20, 2001 at 01:22:24PM +0300 References: Message-ID: <20010720135026.A7946@faui02.informatik.uni-erlangen.de> the data get's truncated? who's sending EOF? the client? so $ ssh -n host cat file > file2 fails on linux? every time? On Fri, Jul 20, 2001 at 01:22:24PM +0300, Pekka Savola wrote: > Hi, > > Using OpenSSH 2.9p2 (2.5.2 was also bad), I've noticed data loss on > Linux when: > 1) ssh -n flag is used, and > 2) ssh jobs are run from cron (effectively causing the same as above). > > What is done, is a command basically like: > > ssh [-n] -c blowfish -p 722 -i rsakey -l pwget passwdserver passwd > passwd.tmp 2> /tmp/log > > ie, retrieve dynamically created passwd-file from passwdserver using rsa > keys. > > The server is SSH 1.2.25 or the like (yeah, I know it's broken, but can't > be changed at the moment). > > The diff of ssh -v -v -v is: > > --- log Fri Jul 20 13:18:42 2001 > +++ log.cron Fri Jul 20 13:02:01 2001 > @@ -41,13 +41,12 @@ > debug3: clear hostkey 0 > debug3: clear hostkey 1 > debug3: clear hostkey 2 > -debug1: Requesting X11 forwarding with authentication spoofing. > -debug1: Remote: X11 forwarding disabled in server configuration file. > -Warning: Remote host denied X11 forwarding. > debug1: Sending command: passwd > debug1: Entering interactive session. > +debug1: fd 0 setting O_NONBLOCK > debug1: fd 1 setting O_NONBLOCK > debug1: fd 2 setting O_NONBLOCK > -debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.6 seconds > -debug1: Bytes per second: stdin 0.0, stdout 95576.3, stderr 0.0 > +debug1: Sending eof. > +debug1: Transferred: stdin 0, stdout 155303, stderr 0 bytes in 1.5 seconds > +debug1: Bytes per second: stdin 0.0, stdout 100654.4, stderr 0.0 > debug1: Exit status 0 > > When run from cron, or with -n, you get "Sending eof." which truncates the > data. > > Any ideas? > > -- > 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 dankamin at cisco.com Fri Jul 20 22:17:57 2001 From: dankamin at cisco.com (Dan Kaminsky) Date: Fri, 20 Jul 2001 05:17:57 -0700 Subject: ProxyCommand and sshd -i : Some Further Analysis References: Message-ID: <006001c11116$02fd6c40$ca2746ab@na.cisco.com> More Fun With SSH's Generic Functionality Encapsulation: Did some work playing around w/ ProxyCommand and inetd mode. The command line syntax is a bit hairier, something along the lines of: ssh -o 'ProxyCommand ssh user at host "cd /home/user/openssh; \ sshd -f sshd_config -h newkey -i"' \ ssh user at host-newkey Some notes: 1) You *have* to generate a new ssh key for the sshd to use, as a normal user shouldn't ever be able to read the host key. "ssh-keygen -f newkey" works nicely--server host keys and user identities are essentially identical. On the flip side, the client has to be told it's connecting to another host-id. Security is still maintained by the ProxyCommand hostkey check, though, and the new key will be stored and checked for in the future. 2) Specify the new SSH key when executing the userspace sshd. The -h option to sshd lets you do this. 3) You *may* have to specifically provide an sshd_config if one cannot be found; I haven't checked. The -f option to sshd lets you do this. 4) Remember that paths and variables are (rightfully) very tightly set when doing remote command execution--so you've gotta provide an absolute path to the ssh daemon. $HOME won't work, neither will ~. But if you directly execute /home/user/openssh/sshd, you'll *also* need to give the full path for the sshd_config and the newkey. An alternative is found by cd'ing to the directory of your choice and then executing your commands from there. This works surprisingly well--you don't even need to do annoying things like ./sshd, even though ./ doesn't appear in the default path. I haven't tested this across many platforms, however, and ./ is almost guaranteed to actually work. 5) Yes, you can specify multiple commands in a row and separate them with a semicolon; just be sure to quote the entire mess so it hits the remote shell invocation rather than your local shell. Among other things, this is nice for things like: tar cf - | ssh user at host "cd /path/to/untar/to; tar xf -" 6) Just for reference, "inetd mode" just causes sshd to run over stdin/stdout. Conveniently, ssh works quite well for doing 8 bit clean forwards of stdio, and ProxyCommand requires nothing more than an 8 bit clean forward. 7) If your platform lacks /dev/random *and* a decent deployed build of openssh, you're going to have problems with finding /etc/ssh_prng_cmds. I'll fix this "soon". 8) I don't think passwords are going to work too well in the userspace sshd. I'll do some work in this regard--probably we can specify a drop down to /bin/login in this context, definitely SRP will work fine--but if you're doing craziness at this level, the least you can do is set up some public keys. :-) 9) Unlike some other hacks I'm working on, I don't think this is a good candidate for any kind of syntax cleanup. You're effectively saying "route this ssh connection through an sshd executed on the remote side, and tell it to use this key and that config file, oh and this is where to find that ssh daemon." To be blunt, there's *so* little to make default that the full syntax is probably more concise than any alternative. Plus this is really more of a neat hack than something that's going to see heavy usage. I've *really* got quite a bit of SSH writing to do this weekend; I'll try to document and develop this hack a bit further. Bug me w/ requests or comments if you like. Yours Truly, Dan Kaminsky, CISSP http://www.doxpara.com P.S. Extreme SSH = Fun :-) From pekkas at netcore.fi Fri Jul 20 22:34:02 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 20 Jul 2001 15:34:02 +0300 (EEST) Subject: data loss with ssh -n In-Reply-To: <20010720135026.A7946@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 20 Jul 2001, Markus Friedl wrote: > the data get's truncated? yes. > so > $ ssh -n host cat file > file2 > fails on linux? > every time? Further ests using protocol1 or protocol2 show that that, as above, does appear to work as it should. Also from cron. Sigh. I wonder if a misbehaving command being run might trigger this, and "cat" working properly? Any clues what to look for there? -- 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 mstone at cs.loyola.edu Sat Jul 21 00:57:44 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Fri, 20 Jul 2001 10:57:44 -0400 Subject: big packets? Message-ID: <20010720105744.Z9022@justice.loyola.edu> I apologize if I'm missing the obvious, but does anyone know what causes sshd: channel 0: rcvd big packet 32281, maxpack 16384 The immediate cause seems to be van dyke's windows sftp client. The larger question would seem to be why it's using larger packets than openssh wants to accept. (client is SecureFX 3.3, server is openssh 2.9p2) -- Mike Stone From matthew at debian.org Sat Jul 21 21:55:18 2001 From: matthew at debian.org (Matthew Vernon) Date: Sat, 21 Jul 2001 12:55:18 +0100 (BST) Subject: Defaults for protocol and ssh-keygen (and an introduction) Message-ID: <15193.28070.938504.90111@rapun.sel.cam.ac.uk> Hi, I have recently taken over as Debian maintainer for ssh. This means you're going to be getting lots of mail from me in the near future :-) I'm aiming to be a little more active than the last maintainer, but the Debian packages were really out of date, so I've quite a lot of work (and probably some old bugs) to deal with. Anyhow, onto the first question. ssh these days uses protocol version 2 by default, but ssh-keygen stil generates old-style keys by default. Is this apparant contradiction intentional? Cheers, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at debian.org Sat Jul 21 22:34:50 2001 From: matthew at debian.org (Matthew Vernon) Date: 21 Jul 2001 13:34:50 +0100 Subject: Failed X11 authentication does the wrong thing Message-ID: <5bitgmpij9.fsf@chiark.greenend.org.uk> Hi, if I do the following: ssh -X localhost su - another_user xterm I get: X connection to ming:10.0 broken (explicit kill or server shutdown). Where what is really wanted was something like: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: :0.0 'tis easy to reproduce the bug, but the debug output that seems relevant is: debug1: X11 connection uses different authentication protocol. I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there are more easy things to do first), so I thought I'd let you know. Cheers, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at debian.org Sat Jul 21 23:03:44 2001 From: matthew at debian.org (Matthew Vernon) Date: 21 Jul 2001 14:03:44 +0100 Subject: ChallengeResponseAuthentication - typos and inconsistancies? Message-ID: <5bhew6ph73.fsf@chiark.greenend.org.uk> Hi, It seems from the source code that there are a couple of quirks with this option: firstly, in the code it's mis-spelt as "challenge_reponse_authentication" and secondly, the default for the client (in readconf.c) seems to be off, whereas for the server (servconf.c) seems to be on: readconf.c: if (options->challenge_reponse_authentication == -1) readconf.c: options->challenge_reponse_authentication = 0; servconf.c: if (options->challenge_reponse_authentication == -1) servconf.c: options->challenge_reponse_authentication = 1; Finally, the manual page says: The default is ``no''. Which set of defaults should be kept? in any case, the man page should agree with the code... Cheers, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From karn at ka9q.net Sat Jul 21 23:58:05 2001 From: karn at ka9q.net (Phil Karn) Date: Sat, 21 Jul 2001 06:58:05 -0700 Subject: DISPLAY variable References: <5bitgmpij9.fsf@chiark.greenend.org.uk> Message-ID: <200107211358.f6LDw5r01190@homer.ka9q.net> While we're on the subject of connections to the local X forwarding port, here's a nit of my own. When I slogin to a remote host with X forwarding enabled, the remote shell sets DISPLAY=foo.bar.com:10.0 (pick your own display number here) where "foo.bar.com" is the remote machine's host name. This works fine as long as there's a valid DNS address entry for that hostname. But if the remote hostname does not correspond to the correct IP address, X forwarding fails. Why should this happen? I have a laptop which normally sits on my home network, and its host name reflects this fact. But occasionally I take it into the office, obtain an IP address with DHCP and slogin into it from my desktop using that IP address. Then the DISPLAY variable setting is incorrect. True, I could set things up to change the host name on the laptop to that provided by DHCP, but I'd rather not do that. (It shows up in outbound email, for example.) Besides, there's a very simple fix: slogin should simply set DISPLAY=127.0.0.1:10.0 (or whatever) regardless of location. Phil From Markus.Friedl at informatik.uni-erlangen.de Sun Jul 22 00:08:21 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 21 Jul 2001 16:08:21 +0200 Subject: DISPLAY variable In-Reply-To: <200107211358.f6LDw5r01190@homer.ka9q.net>; from karn@ka9q.net on Sat, Jul 21, 2001 at 06:58:05AM -0700 References: <5bitgmpij9.fsf@chiark.greenend.org.uk> <200107211358.f6LDw5r01190@homer.ka9q.net> Message-ID: <20010721160821.B25496@faui02.informatik.uni-erlangen.de> On Sat, Jul 21, 2001 at 06:58:05AM -0700, Phil Karn wrote: > that provided by DHCP, but I'd rather not do that. (It shows up in > outbound email, for example.) Besides, there's a very simple fix: > slogin should simply set DISPLAY=127.0.0.1:10.0 (or whatever) > regardless of location. did you try this? it did not work for me due to some strange libX/xauth interactions. i'd prefer to have sshd listen to localhost only. -m From Markus.Friedl at informatik.uni-erlangen.de Sun Jul 22 00:11:14 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 21 Jul 2001 16:11:14 +0200 Subject: Defaults for protocol and ssh-keygen (and an introduction) In-Reply-To: <15193.28070.938504.90111@rapun.sel.cam.ac.uk>; from matthew@debian.org on Sat, Jul 21, 2001 at 12:55:18PM +0100 References: <15193.28070.938504.90111@rapun.sel.cam.ac.uk> Message-ID: <20010721161113.C25496@faui02.informatik.uni-erlangen.de> On Sat, Jul 21, 2001 at 12:55:18PM +0100, Matthew Vernon wrote: > Anyhow, onto the first question. ssh these days uses protocol version > 2 by default, but ssh-keygen stil generates old-style keys by > default. Is this apparant contradiction intentional? no, this is a default that should not be changed now. this will break to many things, i think. perhaps later. From karn at ka9q.net Sun Jul 22 00:58:08 2001 From: karn at ka9q.net (Phil Karn) Date: Sat, 21 Jul 2001 07:58:08 -0700 Subject: DISPLAY variable In-Reply-To: <20010721160821.B25496@faui02.informatik.uni-erlangen.de> (message from Markus Friedl on Sat, 21 Jul 2001 16:08:21 +0200) References: <5bitgmpij9.fsf@chiark.greenend.org.uk> <200107211358.f6LDw5r01190@homer.ka9q.net> <20010721160821.B25496@faui02.informatik.uni-erlangen.de> Message-ID: <200107211458.f6LEw8G03482@homer.ka9q.net> >did you try this? >it did not work for me due to some strange libX/xauth >interactions. i'd prefer to have sshd listen to localhost >only. Yes, it has always worked for me. I.e., I can manually say export DISPLAY=127.0.0.1:10.0 (using the correct display number, of course) and X forwarding from remote clients (e.g., emacs) running on that machine works fine. The environment here is Debian 2.2r3 on both ends. Phil From matthew at debian.org Sun Jul 22 04:04:43 2001 From: matthew at debian.org (Matthew Vernon) Date: 21 Jul 2001 19:04:43 +0100 Subject: Defaults for protocol and ssh-keygen (and an introduction) In-Reply-To: Markus Friedl's message of Sat, 21 Jul 2001 14:32:02 GMT References: <15193.28070.938504.90111@rapun.sel.cam.ac.uk> <15193.28070.938504.90111@rapun.sel.cam.ac.uk> <20010721161113.C25496@faui02.informatik.uni-erlangen.de> Message-ID: <5bg0bqp39g.fsf@chiark.greenend.org.uk> Markus Friedl writes: > > On Sat, Jul 21, 2001 at 12:55:18PM +0100, Matthew Vernon wrote: > > Anyhow, onto the first question. ssh these days uses protocol version > > 2 by default, but ssh-keygen stil generates old-style keys by > > default. Is this apparant contradiction intentional? > > no, this is a default that should not be changed now. > > this will break to many things, i think. perhaps later. Hrm. I'm not convinced. It's a little counter-intuitive that ssh-keygen will create you a useless .identify by default... Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From markus at openssh.com Sun Jul 22 06:01:06 2001 From: markus at openssh.com (Markus Friedl) Date: Sat, 21 Jul 2001 22:01:06 +0200 Subject: DISPLAY variable In-Reply-To: <200107211458.f6LEw8G03482@homer.ka9q.net>; from karn@ka9q.net on Sat, Jul 21, 2001 at 07:58:08AM -0700 References: <5bitgmpij9.fsf@chiark.greenend.org.uk> <200107211358.f6LDw5r01190@homer.ka9q.net> <20010721160821.B25496@faui02.informatik.uni-erlangen.de> <200107211458.f6LEw8G03482@homer.ka9q.net> Message-ID: <20010721220106.A16777@faui02.informatik.uni-erlangen.de> On Sat, Jul 21, 2001 at 07:58:08AM -0700, Phil Karn wrote: > >did you try this? > > >it did not work for me due to some strange libX/xauth > >interactions. i'd prefer to have sshd listen to localhost > >only. > > Yes, it has always worked for me. I.e., I can manually say > > export DISPLAY=127.0.0.1:10.0 > > (using the correct display number, of course) and X forwarding from > remote clients (e.g., emacs) running on that machine works fine. The > environment here is Debian 2.2r3 on both ends. i mean: does it work if you modify sshd to set DISPLAY to this before xauth is called from sshd? -m From markus.friedl at informatik.uni-erlangen.de Sun Jul 22 06:26:55 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 21 Jul 2001 22:26:55 +0200 Subject: data loss with ssh -n In-Reply-To: ; from pekkas@netcore.fi on Fri, Jul 20, 2001 at 02:39:46PM +0300 References: Message-ID: <20010721222655.A10132@folly> On Fri, Jul 20, 2001 at 02:39:46PM +0300, Pekka Savola wrote: > On Fri, 20 Jul 2001, Pekka Savola wrote: > > So, with SSH1 (tried all combinations of -, -t, -n, -t -n): > > > > When run as user, problem _appears to_ exist only if: > > 1) -n > > > > When run from cron, problem _appears to_ exist always except if: > > 1) -t > > > > (I wouldn't call the tests scientific, but should give the idea) > > > > So there's a hack of using '-t' as a workaround; it works with both. > > It's good that I didn't say scientific, as I can't get "ssh -t in cron" > workaround to work anymore.. :-/ ssh -t host cat file > other does not generate 8bit client transfers, since a tty is involved From markus.friedl at informatik.uni-erlangen.de Sun Jul 22 06:29:58 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 21 Jul 2001 22:29:58 +0200 Subject: big packets? In-Reply-To: <20010720105744.Z9022@justice.loyola.edu>; from mstone@cs.loyola.edu on Fri, Jul 20, 2001 at 10:57:44AM -0400 References: <20010720105744.Z9022@justice.loyola.edu> Message-ID: <20010721222958.B10132@folly> i think this is a bug in your sftp client. it seems that openssh announce a maximum packet size of 16K and the clients sends a bigger payload. in case i'm wrong then i have to check the specs again. -m On Fri, Jul 20, 2001 at 10:57:44AM -0400, Michael Stone wrote: > I apologize if I'm missing the obvious, but does anyone know what causes > sshd: channel 0: rcvd big packet 32281, maxpack 16384 > > The immediate cause seems to be van dyke's windows sftp client. The > larger question would seem to be why it's using larger packets than > openssh wants to accept. (client is SecureFX 3.3, server is openssh > 2.9p2) > > -- > Mike Stone From markus.friedl at informatik.uni-erlangen.de Sun Jul 22 06:31:30 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 21 Jul 2001 22:31:30 +0200 Subject: ChallengeResponseAuthentication - typos and inconsistancies? In-Reply-To: <5bhew6ph73.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Sat, Jul 21, 2001 at 02:03:44PM +0100 References: <5bhew6ph73.fsf@chiark.greenend.org.uk> Message-ID: <20010721223130.C10132@folly> On Sat, Jul 21, 2001 at 02:03:44PM +0100, Matthew Vernon wrote: > Hi, > > It seems from the source code that there are a couple of quirks > with this option: > > firstly, in the code it's mis-spelt as > "challenge_reponse_authentication" this should be fixed since time ago. From mstone at debian.org Sun Jul 22 10:55:37 2001 From: mstone at debian.org (Michael Stone) Date: Sat, 21 Jul 2001 20:55:37 -0400 Subject: keyboardinteractive default Message-ID: <20010721205537.D9022@justice.loyola.edu> Is there a reason to not move keyboard-interactive ahead of password in the default for PreferredAuthentications? -- Mike Stone From mstone at debian.org Sun Jul 22 10:56:21 2001 From: mstone at debian.org (Michael Stone) Date: Sat, 21 Jul 2001 20:56:21 -0400 Subject: big packets? In-Reply-To: <20010721222958.B10132@folly>; from markus.friedl@informatik.uni-erlangen.de on Sat, Jul 21, 2001 at 10:29:58PM +0200 References: <20010720105744.Z9022@justice.loyola.edu> <20010721222958.B10132@folly> Message-ID: <20010721205621.E9022@justice.loyola.edu> On Sat, Jul 21, 2001 at 10:29:58PM +0200, Markus Friedl wrote: > i think this is a bug in your sftp client. > > it seems that openssh announce a maximum packet > size of 16K and the clients sends a bigger payload. Someone suggested that there is a newer version of securefx that corrects that bug. We'll try that Monday. -- Mike Stone From matthew at empire.ucam.org Sun Jul 22 21:56:38 2001 From: matthew at empire.ucam.org (Matthew Vernon) Date: Sun, 22 Jul 2001 12:56:38 +0100 (BST) Subject: [patch] VPN enhancements Message-ID: <15194.49014.821115.344160@ming.empire.pick.ucam.org> Hi, This patch (mostly my work, except for protocolkeepalives, which rjk at greenend.org.uk wrote for 2.5, and I forward-ported) came out our usage for VPN tunnels of ssh, where it was useful for ssh to notice if the server went away. It includes documentation, and is pretty self-explanatory. Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-2.9p2-vpnfixes.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/2989dbe1/attachment.ksh -------------- next part -------------- -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at empire.ucam.org Sun Jul 22 22:03:21 2001 From: matthew at empire.ucam.org (Matthew Vernon) Date: Sun, 22 Jul 2001 13:03:21 +0100 (BST) Subject: [patch] ignore SSH2_MSG_IGNORE packets Message-ID: <15194.49417.888028.589551@ming.empire.pick.ucam.org> Hi, protocolkeepalives sends ssh_msg_ignore, which the ssh2 server handles incorrectly (i.e. it produces some output to syslog, instead of ignoring the packet): Jul 9 11:58:07 ren sshd[16580]: error: Hm, dispatch protocol error: type 32 plen 4 This patch implements a highly advanced function to ignore these packets ;) Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msgignore.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/7022ca8e/attachment.ksh -------------- next part -------------- -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at empire.ucam.org Sun Jul 22 22:05:28 2001 From: matthew at empire.ucam.org (Matthew Vernon) Date: Sun, 22 Jul 2001 13:05:28 +0100 (BST) Subject: [patch] GNU/Hurd compatibility patches Message-ID: <15194.49544.408056.72765@ming.empire.pick.ucam.org> Hi, These patches are from Robert Bihlmeyer to make ssh build on Hurd. If you have queries about them, I suggest contacting debian-hurd at lists.debian.org. Cheers, Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-2.9-hurd.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/1b8bf1dd/attachment.ksh -------------- next part -------------- -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at empire.ucam.org Sun Jul 22 22:06:34 2001 From: matthew at empire.ucam.org (Matthew Vernon) Date: Sun, 22 Jul 2001 13:06:34 +0100 (BST) Subject: [patch] add -1 and -2 options to scp Message-ID: <15194.49610.688418.193242@ming.empire.pick.ucam.org> Hi, Several people have asked that scp support the -1 and -2 options, so I wrote this patch. Cheers, Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scp.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/7e096fab/attachment.ksh -------------- next part -------------- -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at empire.ucam.org Sun Jul 22 22:08:21 2001 From: matthew at empire.ucam.org (Matthew Vernon) Date: Sun, 22 Jul 2001 13:08:21 +0100 (BST) Subject: [patch] document location of identity files Message-ID: <15194.49717.785113.579999@ming.empire.pick.ucam.org> Hi, Quick change to ssh.1 to document ~/.ssh/identity_rsa and _dsa. Cheers, Matthew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshman.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/a6d628e2/attachment.ksh -------------- next part -------------- -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From Markus.Friedl at informatik.uni-erlangen.de Sun Jul 22 22:37:19 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 22 Jul 2001 14:37:19 +0200 Subject: [patch] VPN enhancements In-Reply-To: <15194.49014.821115.344160@ming.empire.pick.ucam.org>; from matthew@empire.ucam.org on Sun, Jul 22, 2001 at 12:56:38PM +0100 References: <15194.49014.821115.344160@ming.empire.pick.ucam.org> Message-ID: <20010722143719.A20683@faui02.informatik.uni-erlangen.de> On Sun, Jul 22, 2001 at 12:56:38PM +0100, Matthew Vernon wrote: > +void alarm_catch (int signum) > +{ > + if(signum!=SIGALRM) return; > + else fatal("ssh_exchange_identification: Timeout waiting for version information."); > +} please not alarm() and signal handling. signals should not be used at all. connect timeouts will be supported soon using select() and async connects(). From Markus.Friedl at informatik.uni-erlangen.de Sun Jul 22 22:43:09 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 22 Jul 2001 14:43:09 +0200 Subject: [patch] ignore SSH2_MSG_IGNORE packets In-Reply-To: <15194.49417.888028.589551@ming.empire.pick.ucam.org>; from matthew@empire.ucam.org on Sun, Jul 22, 2001 at 01:03:21PM +0100 References: <15194.49417.888028.589551@ming.empire.pick.ucam.org> Message-ID: <20010722144309.B20683@faui02.informatik.uni-erlangen.de> i think the patch is wrong, because IGNORE messages are already handled in packet_read_poll(). sshd complains because it gets a protocol v1 ignore message. -m On Sun, Jul 22, 2001 at 01:03:21PM +0100, Matthew Vernon wrote: Content-Description: message body text > Hi, > > protocolkeepalives sends ssh_msg_ignore, which the ssh2 server handles > incorrectly (i.e. it produces some output to syslog, instead of > ignoring the packet): > > Jul 9 11:58:07 ren sshd[16580]: error: Hm, dispatch protocol error: > type 32 plen 4 > > This patch implements a highly advanced function to ignore these > packets ;) > > Matthew Content-Description: msg_ignore patch > --- /tmp/openssh-2.9p2/serverloop.c Sat Apr 14 00:28:03 2001 > +++ ./serverloop.c Tue Jul 17 23:36:47 2001 > @@ -741,6 +741,13 @@ > channel_stop_listening(); > } > > + > +void > +server_ignore(int type, int plen, void *ctxt) > +{ > + /*We've receive an SSH_MSG_IGNORE packet, so ignore it :) */ > +} > + > void > server_input_channel_failure(int type, int plen, void *ctxt) > { > @@ -956,6 +963,7 @@ > { > debug("server_init_dispatch_20"); > dispatch_init(&dispatch_protocol_error); > + dispatch_set(SSH2_MSG_IGNORE, &server_ignore); > dispatch_set(SSH2_MSG_CHANNEL_CLOSE, &channel_input_oclose); > dispatch_set(SSH2_MSG_CHANNEL_DATA, &channel_input_data); > dispatch_set(SSH2_MSG_CHANNEL_EOF, &channel_input_ieof); Content-Description: .signature > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org From Markus.Friedl at informatik.uni-erlangen.de Sun Jul 22 22:44:33 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 22 Jul 2001 14:44:33 +0200 Subject: [patch] add -1 and -2 options to scp In-Reply-To: <15194.49610.688418.193242@ming.empire.pick.ucam.org>; from matthew@empire.ucam.org on Sun, Jul 22, 2001 at 01:06:34PM +0100 References: <15194.49610.688418.193242@ming.empire.pick.ucam.org> Message-ID: <20010722144433.C20683@faui02.informatik.uni-erlangen.de> please use -o'protocol=1' otherwise we have to add option after option to scp. -m On Sun, Jul 22, 2001 at 01:06:34PM +0100, Matthew Vernon wrote: Content-Description: message body text > Hi, > > Several people have asked that scp support the -1 and -2 options, so I > wrote this patch. > > Cheers, > > Matthew Content-Description: scp patch > --- /tmp/openssh-2.9p2/scp.c Sun Apr 22 18:13:20 2001 > +++ openssh-2.9p2/scp.c Sat Jul 21 13:49:17 2001 > @@ -244,9 +244,11 @@ > addargs("-oFallBackToRsh no"); > > fflag = tflag = 0; > - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != -1) > + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:")) != -1) > switch (ch) { > /* User-visible flags. */ > + case '1': > + case '2': > case '4': > case '6': > case 'C': > --- /tmp/openssh-2.9p2/scp.1 Sun Feb 4 12:20:19 2001 > +++ openssh-2.9p2/scp.1 Sat Jul 21 13:51:55 2001 > @@ -19,7 +19,7 @@ > .Nd secure copy (remote file copy program) > .Sh SYNOPSIS > .Nm scp > -.Op Fl pqrvC46 > +.Op Fl pqrvC1246 > .Op Fl S Ar program > .Op Fl P Ar port > .Op Fl c Ar cipher > @@ -110,6 +110,14 @@ > .It Fl o Ar option > The given option is directly passed to > .Xr ssh 1 . > +.It Fl 1 > +Forces > +.Nm > +to try protocol version 1 only. > +.It Fl 2 > +Forces > +.Nm > +to try protocol version 2 only. > .It Fl 4 > Forces > .Nm Content-Description: .signature > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org From matthew at debian.org Mon Jul 23 00:00:24 2001 From: matthew at debian.org (Matthew Vernon) Date: 22 Jul 2001 15:00:24 +0100 Subject: [patch] VPN enhancements In-Reply-To: Markus Friedl's message of Sun, 22 Jul 2001 13:32:02 GMT References: <15194.49014.821115.344160@ming.empire.pick.ucam.org> <15194.49014.821115.344160@ming.empire.pick.ucam.org> <20010722143719.A20683@faui02.informatik.uni-erlangen.de> Message-ID: <5bofqdvzbb.fsf@chiark.greenend.org.uk> Markus Friedl writes: > > On Sun, Jul 22, 2001 at 12:56:38PM +0100, Matthew Vernon wrote: > > +void alarm_catch (int signum) > > +{ > > + if(signum!=SIGALRM) return; > > + else fatal("ssh_exchange_identification: Timeout waiting for version information."); > > +} > > please not alarm() and signal handling. > signals should not be used at all. Why on earth not? You'll notice that this patch is very careful to avoid doing bad things (or careless things) with signals. > connect timeouts will be supported soon using select() > and async connects(). It's not clear how this would help in this case. Unless you're saying that the socket will be O_NONBLOCK at this stage (which would be a change to current behaviour)? Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at debian.org Mon Jul 23 00:08:36 2001 From: matthew at debian.org (Matthew Vernon) Date: 22 Jul 2001 15:08:36 +0100 Subject: [patch] add -1 and -2 options to scp In-Reply-To: Markus Friedl's message of Sun, 22 Jul 2001 13:32:02 GMT References: <15194.49610.688418.193242@ming.empire.pick.ucam.org> <15194.49610.688418.193242@ming.empire.pick.ucam.org> <20010722144433.C20683@faui02.informatik.uni-erlangen.de> Message-ID: <5bn15xvyxn.fsf@chiark.greenend.org.uk> Markus Friedl writes: > > please use -o'protocol=1' > > otherwise we have to add option after option to scp. *boggle* ssh has the -1 and -2 option. Suggesting that it's wrong to add this to scp with a slippery-slope argument is daft. A consistent interface is a good thing, and given that there are often occasions where peopel want to choose a protocol version explicitly... Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From Markus.Friedl at informatik.uni-erlangen.de Mon Jul 23 01:43:40 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 22 Jul 2001 17:43:40 +0200 Subject: [patch] VPN enhancements In-Reply-To: <5bofqdvzbb.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Sun, Jul 22, 2001 at 03:00:24PM +0100 References: <15194.49014.821115.344160@ming.empire.pick.ucam.org> <15194.49014.821115.344160@ming.empire.pick.ucam.org> <20010722143719.A20683@faui02.informatik.uni-erlangen.de> <5bofqdvzbb.fsf@chiark.greenend.org.uk> Message-ID: <20010722174340.A10347@faui02.informatik.uni-erlangen.de> On Sun, Jul 22, 2001 at 03:00:24PM +0100, Matthew Vernon wrote: > Markus Friedl writes: > > > > > On Sun, Jul 22, 2001 at 12:56:38PM +0100, Matthew Vernon wrote: > > > +void alarm_catch (int signum) > > > +{ > > > + if(signum!=SIGALRM) return; > > > + else fatal("ssh_exchange_identification: Timeout waiting for version information."); > > > +} > > > > please not alarm() and signal handling. > > signals should not be used at all. > > Why on earth not? You'll notice that this patch is very careful to > avoid doing bad things (or careless things) with signals. for example: fatal() is not allowed in signal handlers since it calls exit(). From jones at mail.utexas.edu Mon Jul 23 02:27:30 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Sun, 22 Jul 2001 11:27:30 -0500 Subject: Test message Message-ID: Test message From jones at mail.utexas.edu Mon Jul 23 02:47:21 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Sun, 22 Jul 2001 11:47:21 -0500 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos Message-ID: This patch is against Cray patch against openssh-SNAP-20010710. Here a few notes about them: 1) rijndael does not work on cray due to the fact it is rooted in 32 bits. I looking for a fix, it may come form Wendy Palam. For now the cray default to the following cihpers for ssh version 2 ssh are: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour 2) Crays don't have setitimer so I changed scp.c to use alarm which should work on all systems. 3) Created bsd-cray.c in openbsd-compat. This mainly supports cray TMPDIR environment variable, jid, and setting job and process limits form cray's udb. I could have put them in seesion.c but I think session.c is getting to loaded with speicalied system codes. The same is true for pty.c. Maby it time to split out the code int seperate system modules in the openbsd-compat directiry. 4) Fixed a few minor issues with resetting SIGCHLD. If you permanently install a signal with mysingnal for SIGCHLD you don't need to reset it in the sigchld handler. You can get into a infinite signal loop if the sigchld handler does not reap the child win it is called if it reset the sigchld handler, it is a cray thing. 5) It is possible to get an EINTR on a waitpid call on a cray, it has to do with the job termination signal. Loop on waitpid if errno is EINTR in serverloop.c 6) Cray gets pty differently so getpty.c has a few more levels of ifdef's, sigh. 7) Add some more cray specific prng commands. Needed more entropy! Let me know if you have any questions or need any changes to this set of patches. This is the third posting. I think the others went into the bit bucket do to a domain change. William L Jones -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch Type: application/octet-stream Size: 20377 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010722/d27d7870/attachment.obj From mouring at etoh.eviladmin.org Mon Jul 23 03:39:32 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 22 Jul 2001 12:39:32 -0500 (CDT) Subject: [patch] GNU/Hurd compatibility patches In-Reply-To: <15194.49544.408056.72765@ming.empire.pick.ucam.org> Message-ID: We already rejected this patch as it distrupts too much code for no good reason (Look back on the marc archives). If Hurd decides to be POSIX compatable; we will be happy to accept patches for them. But from what I'm reading on the Hurd summary mailinglist it may be a long time. Until such time they will have to maintain their own version. Or come up with a better way of handling their inconsistance behavior. - Ben On Sun, 22 Jul 2001, Matthew Vernon wrote: > Hi, > > These patches are from Robert Bihlmeyer to make ssh build on Hurd. If > you have queries about them, I suggest contacting > debian-hurd at lists.debian.org. > > Cheers, > > Matthew > From mouring at etoh.eviladmin.org Mon Jul 23 03:43:29 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 22 Jul 2001 12:43:29 -0500 (CDT) Subject: [patch] document location of identity files In-Reply-To: <15194.49717.785113.579999@ming.empire.pick.ucam.org> Message-ID: Why? It's id_rsa and id_dsa for Protocol v2 keys.. - Ben On Sun, 22 Jul 2001, Matthew Vernon wrote: > Hi, > > Quick change to ssh.1 to document ~/.ssh/identity_rsa and _dsa. > > Cheers, > > Matthew > From mouring at etoh.eviladmin.org Mon Jul 23 04:45:40 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 22 Jul 2001 13:45:40 -0500 (CDT) Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: Message-ID: I'll commit the sections that are non distruptive soon.. I think there are things that will need to be discussed on list before the whole patch gets applied. But let deal with the easy issues. =) 1) Where is openbsd-compat/bsd-cray.h ? It should house all the stuff like this (from session.c) +#ifdef _CRAY +void cray_init_job(struct passwd *); /* init cray job */ +void cray_job_termination_handler(int); /* process end of job signal */ +void cray_setup(); /* set cray limits */ +extern char cray_tmpdir[]; /* cray tmpdir */ +#endif + And it should be included in the openbsd-compat.h 2) In deattack.c +#ifdef _CRAY + for (i=0; i This patch is against Cray patch against openssh-SNAP-20010710. Here > a few notes about them: > > 1) rijndael does not work on cray due to the fact it is rooted in 32 bits. > I looking for a fix, it may come form Wendy Palam. For now the cray > default to the following cihpers for ssh version 2 ssh are: > 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > > 2) Crays don't have setitimer so I changed scp.c to use alarm which > should work on all systems. > > 3) Created bsd-cray.c in openbsd-compat. This mainly supports cray TMPDIR > environment variable, jid, and setting job and process limits form cray's > udb. I could have put them in seesion.c but I think session.c is getting > to loaded with speicalied system codes. The same is true for pty.c. > Maby it time to split out the code int seperate system modules in > the openbsd-compat directiry. > > 4) Fixed a few minor issues with resetting SIGCHLD. If you permanently > install > a signal with mysingnal for SIGCHLD you don't need to reset it in the > sigchld handler. You can get into a infinite signal loop if the sigchld > handler does not reap the child win it is called if it reset the sigchld > handler, it is a cray thing. > > 5) It is possible to get an EINTR on a waitpid call on a cray, it has to do > with the job termination signal. Loop on waitpid if errno is EINTR in > serverloop.c > > 6) Cray gets pty differently so getpty.c has a few more levels of ifdef's, > sigh. > > 7) Add some more cray specific prng commands. Needed more entropy! > > Let me know if you have any questions or need any changes to this set > of patches. > > This is the third posting. I think the others went into the bit bucket > do to a domain change. > > William L Jones > From jones at mail.utexas.edu Mon Jul 23 06:24:51 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Sun, 22 Jul 2001 15:24:51 -0500 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: Message-ID: > -----Original Message----- > From: owner-openssh-unix-dev at mindrot.org > [mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of > mouring at etoh.eviladmin.org > Sent: Sunday, July 22, 2001 1:46 PM > To: William L. Jones > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Patches for Cray T3Es running Unicossmk and SV1s running > Unicos > > > > I'll commit the sections that are non distruptive soon.. I think there are > things that will need to be discussed on list before the whole patch gets > applied. > > But let deal with the easy issues. =) > > 1) Where is openbsd-compat/bsd-cray.h ? > It should house all the stuff like this (from session.c) > > +#ifdef _CRAY > +void cray_init_job(struct passwd *); /* init cray job */ > +void cray_job_termination_handler(int); /* process end of > job signal */ > +void cray_setup(); /* set cray limits */ > +extern char cray_tmpdir[]; /* cray tmpdir */ > +#endif > + > Easy enough! > And it should be included in the openbsd-compat.h > > 2) In deattack.c > > +#ifdef _CRAY > + for (i=0; i +#else > memset(h, HASH_UNUSEDCHAR, n * HASH_ENTRYSIZE); > +#endif > > I'd rather see bsd-cray.c have a memset() function that mimic what > we expect from memset(). It makes is easier when it comes to syncing > between portable and OpenBSD. > Unforintally I did not make enough changes here I should have looked closer at the ssh-1.2.27 cray mod set. In order to make deattack.c work on cray and all other system. You have to 1) Change set HASH_ENTRYSIZE to explicly to 2. 2) Every were their is a malloc using HASH_ENTRYSIZE it must be changed to use sizeof(u_int16_t). 3) Change memset(h, HASH_UNUSEDCHAR, n * HASH_ENTRYSIZE); to for (i=0; i will the following OpenBSD code run and work right under Cray? If so > I'll be happy to import it and then we can detect of memset() exists > and fall back to the below code if it's not. > > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/memset.c > > Better question is why the hackery around that memset() and not the one in > openssh/openbsd-compat/rresvport.c ?? > > 3) Is this a typo in ssh_prng_cmds.in ? > > + > +"sar -d" @PROG_SAR[@ 0.04 > > Is the ] really supose to be there? =) Yes! Sigh > > > Damien, I think we should consider renaming openbsd-compat/bindresvport.c > to openbsd-compat/bsd-bindresvport.c if we accept the cray proposed > changes. The code will be very hard to resync with the OpenBSD's version > after this patch. > Un fortunately your right. Like the deattach changes the bindresvport.c changes have to do with the lack of byte address and the locak of 16 bit shorts on Cray SV1s. > - Ben > > On Sun, 22 Jul 2001, William L. Jones wrote: > > > This patch is against Cray patch against openssh-SNAP-20010710. Here > > a few notes about them: > > > > 1) rijndael does not work on cray due to the fact it is rooted > in 32 bits. > > I looking for a fix, it may come form Wendy Palam. For now the cray > > default to the following cihpers for ssh version 2 ssh are: > > 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > > > > 2) Crays don't have setitimer so I changed scp.c to use alarm which > > should work on all systems. > > > > 3) Created bsd-cray.c in openbsd-compat. This mainly supports > cray TMPDIR > > environment variable, jid, and setting job and process > limits form cray's > > udb. I could have put them in seesion.c but I think > session.c is getting > > to loaded with speicalied system codes. The same is true for pty.c. > > Maby it time to split out the code int seperate system modules in > > the openbsd-compat directiry. > > > > 4) Fixed a few minor issues with resetting SIGCHLD. If you permanently > > install > > a signal with mysingnal for SIGCHLD you don't need to reset it in the > > sigchld handler. You can get into a infinite signal loop if > the sigchld > > handler does not reap the child win it is called if it reset > the sigchld > > handler, it is a cray thing. > > > > 5) It is possible to get an EINTR on a waitpid call on a cray, > it has to do > > with the job termination signal. Loop on waitpid if errno > is EINTR in > > serverloop.c > > > > 6) Cray gets pty differently so getpty.c has a few more levels > of ifdef's, > > sigh. > > > > 7) Add some more cray specific prng commands. Needed more entropy! > > > > Let me know if you have any questions or need any changes to this set > > of patches. > > > > This is the third posting. I think the others went into the bit bucket > > do to a domain change. > > > > William L Jones > > > > > From Marcus.Brinkmann at ruhr-uni-bochum.de Mon Jul 23 11:41:04 2001 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 23 Jul 2001 03:41:04 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <15195.26234.988414.175977@ming.empire.pick.ucam.org> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> Message-ID: <20010723034104.B505@212.23.136.22> Hi, I just looked in the mail archive to see what patch was posted (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99580473611227&w=2) This piece of the patch is not good, because it is not defined if the truncated name will be null terminated. This can be fixed by null terminating the reult no matter what, I think. However, I really suggest to just put a get_host_name implementation in ssh, that works on all systems and returns a malloced buffer. This can then be used everywhere were gethostname is used. A good implementation is for example in GNU inetutils (libinetutils/localhost.c) Thanks, Marcus diff -ur openssh-2.9p2-/channels.c openssh-2.9p2/channels.c --- openssh-2.9p2-/channels.c Sat Mar 17 01:47:55 2001 +++ openssh-2.9p2/channels.c Thu Jun 28 20:11:02 2001 @@ -1965,7 +1965,7 @@ char strport[NI_MAXSERV]; int gaierr, n, num_socks = 0, socks[NUM_SOCKS]; char display[512]; - char hostname[MAXHOSTNAMELEN]; + char hostname[401]; /* we only use the first 400 bytes anyway*/ for (display_number = x11_display_offset; display_number < MAX_DISPLAYS; @@ -2037,7 +2037,8 @@ } /* Set up a suitable value for the DISPLAY variable. */ - if (gethostname(hostname, sizeof(hostname)) < 0) + if (gethostname(hostname, sizeof(hostname)) < 0 + && errno != ENAMETOOLONG) fatal("gethostname: %.100s", strerror(errno)); #ifdef IPADDR_IN_DISPLAY -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org Marcus.Brinkmann at ruhr-uni-bochum.de http://www.marcus-brinkmann.de From Marcus.Brinkmann at ruhr-uni-bochum.de Mon Jul 23 11:35:17 2001 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 23 Jul 2001 03:35:17 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <15195.26234.988414.175977@ming.empire.pick.ucam.org> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> Message-ID: <20010723033517.A505@212.23.136.22> On Mon, Jul 23, 2001 at 12:49:14AM +0100, Matthew Vernon wrote: > ------- start of forwarded message ------- > From: > To: Matthew Vernon > cc: > Subject: Re: [patch] GNU/Hurd compatibility patches > Date: Sun, 22 Jul 2001 12:39:32 -0500 (CDT) > > > We already rejected this patch as it distrupts too much code for no good > reason (Look back on the marc archives). (The patch is about removing the arbitrary limit on the length of hostnames used by openssh.) > If Hurd decides to be POSIX > compatable; we will be happy to accept patches for them. But from > what I'm reading on the Hurd summary mailinglist it may be a long time. We are POSIX compatible (modulo bugs), at least we make the claim. We are happy to check the standard for each individual concern about compatibility you might raise. Concerning MAXHOSTNAMELEN, this symbol is widely spread on UNIX and other systems, but it is not defined by any released version of POSIX. The Single Unix Specification says that hostnames are limited to 255 characters, however, the upcoming POSIX draft which is supposed to cover also the area that SUSv2 does, does fix this. Again, the upcoming POSIX draft as reviewed by the Austin Group (I have draft6 here), does not define MAXHOSTNAMELEN (just as it doesn't define MAXPATHLEN), but it does say something about the new symbol HOST_NAME_MAX: "Runtime Invariant Values (Possibly Indeterminate) A definition of one of the symbolic names in the following list shall be omitted from on specific implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified. {HOST_NAME_MAX} Maximum length of a host name (not including the terminating null) as returned from the gethostname( ) function. Minimum Acceptable Value: {_POSIX_HOST_NAME_MAX} {_POSIX_HOST_NAME_MAX} Maximum length of a host name (not including the terminating null) as returned from the gethostname( ) function. Value: 255" (note that _POSIX_HOST_NAME_MAX defines the minimum acceptable value in an implementation). Please note that because the length of a hostname is unlimited on the Hurd, we do not define MAXHOSTNAMELEN now, and will not define HOST_NAME_MAX when the new POSIX draft (or any later draft with the above text) becomes a standard. According to the current draft, you will be able to query a possible run time limit with sysconf() and _SC_HOST_NAME_MAX, but again, the Hurd will just return -1 on this call, indicating that there is no limit. > Until such time they will have to maintain their own version. Or come up > with a better way of handling their inconsistance behavior. Please reconsider. I feel that a fork of the software is completely unnecessary. If you don't accept our patch, maybe we can write a better patch. For this, we would need to know what specific parts make you unhappy and how you would like them to be written in a better way. If you don't want to deal with arbitrary hostname lengths, even on systems which support them, you can define an arbitrary limit (greater than 255) yourself, and deal with gethostname returning -1 if the name doesn't fit. ssh does then impose an arbitrary restriction on the Hurd, and not deliver the systems flexibility fully to the user, but it will work in all (currently) common cases. We definiteily don't want to maintain our own version of the patch or ssh. It is our goal to improve the portability of your ssh. If you share this goal, please help us by letting us know how we can achieve it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org Marcus.Brinkmann at ruhr-uni-bochum.de http://www.marcus-brinkmann.de From robbe at orcus.priv.at Mon Jul 23 21:54:34 2001 From: robbe at orcus.priv.at (Robert Bihlmeyer) Date: 23 Jul 2001 13:54:34 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723034104.B505@212.23.136.22> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> Message-ID: <87r8v7j1xh.fsf@orcus.priv.at> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010723/a8dbb463/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010723/a8dbb463/attachment.bin From robbe at orcus.priv.at Mon Jul 23 21:54:34 2001 From: robbe at orcus.priv.at (Robert Bihlmeyer) Date: 23 Jul 2001 13:54:34 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723034104.B505@212.23.136.22> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> Message-ID: <87r8v7j1xh.fsf@orcus.priv.at> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010723/a8dbb463/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010723/a8dbb463/attachment-0001.bin From markus.friedl at informatik.uni-erlangen.de Tue Jul 24 04:55:53 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Mon, 23 Jul 2001 20:55:53 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723034104.B505@212.23.136.22>; from Marcus.Brinkmann@ruhr-uni-bochum.de on Mon, Jul 23, 2001 at 03:41:04AM +0200 References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> Message-ID: <20010723205553.A14623@folly> this patch looks fine, however, i don't want to see a magic numer 401 in openssh's code. why not just define MAXHOSTNAMELEN for HURD ? -m On Mon, Jul 23, 2001 at 03:41:04AM +0200, Marcus Brinkmann wrote: > Hi, > > I just looked in the mail archive to see what patch was posted > (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99580473611227&w=2) > > This piece of the patch is not good, because it is not defined if the > truncated name will be null terminated. This can be fixed by null > terminating the reult no matter what, I think. > > However, I really suggest to just put a get_host_name implementation in ssh, > that works on all systems and returns a malloced buffer. This can then be > used everywhere were gethostname is used. > > A good implementation is for example in GNU inetutils > (libinetutils/localhost.c) > > Thanks, > Marcus > > diff -ur openssh-2.9p2-/channels.c openssh-2.9p2/channels.c > --- openssh-2.9p2-/channels.c Sat Mar 17 01:47:55 2001 > +++ openssh-2.9p2/channels.c Thu Jun 28 20:11:02 2001 > @@ -1965,7 +1965,7 @@ > char strport[NI_MAXSERV]; > int gaierr, n, num_socks = 0, socks[NUM_SOCKS]; > char display[512]; > - char hostname[MAXHOSTNAMELEN]; > + char hostname[401]; /* we only use the first 400 bytes anyway*/ > > for (display_number = x11_display_offset; > display_number < MAX_DISPLAYS; > @@ -2037,7 +2037,8 @@ > } > > /* Set up a suitable value for the DISPLAY variable. */ > - if (gethostname(hostname, sizeof(hostname)) < 0) > + if (gethostname(hostname, sizeof(hostname)) < 0 > + && errno != ENAMETOOLONG) > fatal("gethostname: %.100s", strerror(errno)); > > #ifdef IPADDR_IN_DISPLAY > > > -- > `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org > Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org > Marcus.Brinkmann at ruhr-uni-bochum.de > http://www.marcus-brinkmann.de From pekkas at netcore.fi Tue Jul 24 06:36:47 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 23 Jul 2001 23:36:47 +0300 (EEST) Subject: 2.9p2: sshd -6, port fwd of ipv4 fails Message-ID: Hi, Running openssh-2.9p2 on Linux. If server is run with 'sshd -6' (to enable ipv6 easily on server end), ie all IPv4 are represented as mapped addresses, port forwarding will not work; just running plain ol' IPv4 fixes this of course. The server error, when forwarding from the client '143:localhost:143' and connecting to localhost 143 is: debug1: server_input_channel_open: ctype direct-tcpip rchan 1 win 20480 max 2048 debug1: server_request_direct_tcpip: originator 127.0.0.1 port 1340, target 127.0.0.1 port 143 connect_to 127.0.0.1: unknown host (Address family for hostname not supported) debug1: server_input_channel_open: failure direct-tcpip The problem is that the connecting clients might not know a thing about IPv6, so it wouldn't even be possible to forward something like '143/::127.0.0.1/143', I suspect. So it might appear sshd -6 is not entirely "safe" if you want to forward ports w/ ipv4? I wonder if this would work properly on systems that do double bind, ie. separate ipv4 and ipv6 socket. At least 2.5.2pX on FreeBSD appeared to have some problems, but didn't go to much into detail there. -- 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 Midwest_Marketing at yahoo.com Mon Jul 23 03:59:41 2001 From: Midwest_Marketing at yahoo.com (Midwest_Marketing at yahoo.com) Date: Mon, 23 Jul 2001 03:59:41 Subject: Your "Tell Me More" Information Message-ID: <22.409592.839495@yahoo.com> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010723/e062c356/attachment.html From Marcus.Brinkmann at ruhr-uni-bochum.de Tue Jul 24 13:25:04 2001 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 24 Jul 2001 05:25:04 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723205553.A14623@folly> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> <20010723205553.A14623@folly> Message-ID: <20010724052504.A511@212.23.136.22> Hi, On Mon, Jul 23, 2001 at 08:55:53PM +0200, Markus Friedl wrote: > this patch looks fine, > > however, i don't want to see a magic numer 401 in openssh's code. I can understand that. This is why I suggested to put a wrapper around gethostname which just xmallocs/xreallocs a large enough buffer, and use this wrapped version everywhere were gethostname is used right now. An implementation is already part of the original patch, if I recall correctly, and just needs to be isolated into a function. If you prefer it this way (and personally, I do), we can rework the whole patch and submit it to you for review. (of course if you want to do this yourself, we are fine with that!). > why not just define MAXHOSTNAMELEN for HURD ? One main goal of the Hurd is to not impose any arbitrary system limit on the users. The system code should be as flexible as possible so it does not inconvenience the user. Remember that the Hurd is a user-extensible system. Substantial (read: almost all) parts of the system are implemented in user space, and can be replaced by a users own implementation. So every constraint in the little system code we do have (system code here means code that the user must use to communicate with the remainder of the system, and cannot avoid or replace) has a serious impact on the freedom of the user of the system. Imposing an arbitrary limit on the length of a hostname is such a constraint we are going a long way to avoid, in the system code and the applications running on the Hurd. Another is PATH_MAX, MAXPATHLEN and co. Those are likewise not defined, as there is no global imit to the filename length known at compile time (and usually none at run time for the standard filesystems). Another is the number of open file descriptors, like NOFILE, and so on. So, to summarise it: We must not define and enforce such a limit in the system code that the user can not avoid, if we don't want to effectively force the limit on the user. You can define such a limit in an application (that doesn't need special privileges to run), as the user will always be able to create his own, unrestricted version of the program. However, we take it upon us to modify all programs (included in Debian) and remove such limitations, because otherwise there will be a lot of duplicated efforts. [ To put it even simpler: We don't want no stinkin' arbitrary limits ;) ] I hope it is now easier to understand why we don't define this symbol. Some understanding for the concepts of the Hurd and the goal of the project is needed, though, to see why we made that decision. Please ask if something is unclear. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org Marcus.Brinkmann at ruhr-uni-bochum.de http://www.marcus-brinkmann.de From mouring at etoh.eviladmin.org Tue Jul 24 14:49:29 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 23 Jul 2001 23:49:29 -0500 (CDT) Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723205553.A14623@folly> Message-ID: Markus, I still don't get why this is even an issue.. if gethostname() returns failures if the hostname is greater then MAXHOSTNAMELEN then this whole issue is moot, and this patch is wrong since it creates a case where you have inconsistance behavior between platforms. And if that is the case, I will refuse to apply it. If OpenBSD or other platforms hack the hostname off to match the current variable size, and they do not return some type of failure then the OS is broken. And it should be fixed in their code not our application since we have no way of detecting such evilness (Also, consider a hostname getting hacked to: "somehost.open" now.. How in the world do you use that correctly for key verification or X11 DISPLAY setting?! You end up having to make educated guess based on limited knowledge which can bite us in the ass later on). I still have to ask the same question I did the last time this was brought up.. Who in their right mind would have a hostname/FQDN that is over 256 characters (using OpenBSD's documented limit)?! That is over 3 lines worth of information to type!!! There are days I wish I would have bought a shorter name then 'eviladmin.org' =) I have no problems if we handle ENAMETOOLONG using xgethostname() (mirroring naming already used for replacement functions [xstrdup, xmalloc, etc]). However, since OpenBSD currently does not suppot ENAMETOOLONG it really should not be in the OpenBSD tree which leaves us with 3 unique changes for portable. Which is tolerable. Until such time we can provide configure.in checks and define such limitations in our code if the first assumption is true. The change would require a #define to be set in the configure.in since I know Damien does not like blindly setting such variables. Mr Brinkmann, The less core code that can be changed between the portable and the OpenBSD tree the happier I become. It is an extreme bear to get a patch set from the OpenBSD tree and find it fails to apply due to cross-platform differences. Then having to tip toe around code for platforms that I can't test. Praying I don't break the platform and it gets released in such a broken state in the next release (luckly, we have been doing pretty good on testing before a release thanks to the many people who help out!). Keep this in mind. =) We have already three OSes (NeXTStep, Cray, and Cygwin) with openbsd-compat/bsd-OSNAME.[ch] which I advocate for code that is not logical to share between platforms. So, you now understand where I come from. =) BTW, I do follow Hurd weekly kernel cousin report. So I have seen this issue before on your own mailinglists for other software packages. It's already horrible to do merges on a bad day when Markus starts playing with code that has large amount of #ifdef near by. =) - Ben On Mon, 23 Jul 2001, Markus Friedl wrote: > this patch looks fine, > > however, i don't want to see a magic numer 401 in openssh's code. > > why not just define MAXHOSTNAMELEN for HURD ? > > -m > > On Mon, Jul 23, 2001 at 03:41:04AM +0200, Marcus Brinkmann wrote: > > Hi, > > > > I just looked in the mail archive to see what patch was posted > > (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99580473611227&w=2) > > > > This piece of the patch is not good, because it is not defined if the > > truncated name will be null terminated. This can be fixed by null > > terminating the reult no matter what, I think. > > > > However, I really suggest to just put a get_host_name implementation in ssh, > > that works on all systems and returns a malloced buffer. This can then be > > used everywhere were gethostname is used. > > > > A good implementation is for example in GNU inetutils > > (libinetutils/localhost.c) > > > > Thanks, > > Marcus > > > > diff -ur openssh-2.9p2-/channels.c openssh-2.9p2/channels.c > > --- openssh-2.9p2-/channels.c Sat Mar 17 01:47:55 2001 > > +++ openssh-2.9p2/channels.c Thu Jun 28 20:11:02 2001 > > @@ -1965,7 +1965,7 @@ > > char strport[NI_MAXSERV]; > > int gaierr, n, num_socks = 0, socks[NUM_SOCKS]; > > char display[512]; > > - char hostname[MAXHOSTNAMELEN]; > > + char hostname[401]; /* we only use the first 400 bytes anyway*/ > > > > for (display_number = x11_display_offset; > > display_number < MAX_DISPLAYS; > > @@ -2037,7 +2037,8 @@ > > } > > > > /* Set up a suitable value for the DISPLAY variable. */ > > - if (gethostname(hostname, sizeof(hostname)) < 0) > > + if (gethostname(hostname, sizeof(hostname)) < 0 > > + && errno != ENAMETOOLONG) > > fatal("gethostname: %.100s", strerror(errno)); > > > > #ifdef IPADDR_IN_DISPLAY > > > > > > -- > > `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org > > Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org > > Marcus.Brinkmann at ruhr-uni-bochum.de > > http://www.marcus-brinkmann.de > From pekkas at netcore.fi Tue Jul 24 16:07:14 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 24 Jul 2001 09:07:14 +0300 (EEST) Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: Message-ID: On Mon, 23 Jul 2001 mouring at etoh.eviladmin.org wrote: > I still have to ask the same question I did the last time this was brought > up.. Who in their right mind would have a hostname/FQDN that is over 256 > characters (using OpenBSD's documented limit)?! That is over 3 lines > worth of information to type!!! There are days I wish I would have bought > a shorter name then 'eviladmin.org' =) I thought some DNS RFC stated that the maximum length of the hostname was 255 characters... Some hosts might exceed 64 (the classic: www.llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk; not that I'd name my domain after a name like this :-), which is a prime reason for often replacing MAXHOSTNAMELEN (often 64) with a higher value, but having to up 256 is IMO overkill... -- 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 pekkas at netcore.fi Tue Jul 24 16:07:14 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 24 Jul 2001 09:07:14 +0300 (EEST) Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: Message-ID: On Mon, 23 Jul 2001 mouring at etoh.eviladmin.org wrote: > I still have to ask the same question I did the last time this was brought > up.. Who in their right mind would have a hostname/FQDN that is over 256 > characters (using OpenBSD's documented limit)?! That is over 3 lines > worth of information to type!!! There are days I wish I would have bought > a shorter name then 'eviladmin.org' =) I thought some DNS RFC stated that the maximum length of the hostname was 255 characters... Some hosts might exceed 64 (the classic: www.llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.co.uk; not that I'd name my domain after a name like this :-), which is a prime reason for often replacing MAXHOSTNAMELEN (often 64) with a higher value, but having to up 256 is IMO overkill... -- 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 -- To UNSUBSCRIBE, email to debian-hurd-request at lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org From Markus.Friedl at informatik.uni-erlangen.de Tue Jul 24 17:56:22 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 24 Jul 2001 09:56:22 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010724052504.A511@212.23.136.22>; from Marcus.Brinkmann@ruhr-uni-bochum.de on Tue, Jul 24, 2001 at 05:25:04AM +0200 References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> <20010723205553.A14623@folly> <20010724052504.A511@212.23.136.22> Message-ID: <20010724095622.B7744@faui02.informatik.uni-erlangen.de> On Tue, Jul 24, 2001 at 05:25:04AM +0200, Marcus Brinkmann wrote: > Hi, > > On Mon, Jul 23, 2001 at 08:55:53PM +0200, Markus Friedl wrote: > > this patch looks fine, > > > > however, i don't want to see a magic numer 401 in openssh's code. > > I can understand that. This is why I suggested to put a wrapper around > gethostname which just xmallocs/xreallocs a large enough buffer, and use > this wrapped version everywhere were gethostname is used right now. > > An implementation is already part of the original patch, if I recall > correctly, and just needs to be isolated into a function. > > If you prefer it this way (and personally, I do), we can rework the > whole patch and submit it to you for review. (of course if you want to do > this yourself, we are fine with that!). > > > why not just define MAXHOSTNAMELEN for HURD ? > > One main goal of the Hurd is to not impose any arbitrary system limit on the > users. The system code should be as flexible as possible so it does not i was not talking about your system. our headers could do the same. From robbe at orcus.priv.at Tue Jul 24 19:41:40 2001 From: robbe at orcus.priv.at (Robert Bihlmeyer) Date: 24 Jul 2001 11:41:40 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010723205553.A14623@folly> References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> <20010723205553.A14623@folly> Message-ID: <87ae1ubr57.fsf@orcus.priv.at> Markus Friedl writes: > however, i don't want to see a magic numer 401 in openssh's code. Well, there's already a magic number in the same file (channel.c) Lines 2271-2273: /* Just set DISPLAY to hostname:screen.display */ snprintf(display, sizeof display, "%.400s:%d.%d", hostname, display_number, screen_number); It may be good to "#define DISPLAY_MAXHOSTLEN 400" somewhere. > why not just define MAXHOSTNAMELEN for HURD ? #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 256 #endif somewhere in openssh's code would be fine with us. We would like the other alternatives better, of course. -- Robbe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.ng Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010724/9b05a7d6/attachment.bin From Markus.Friedl at informatik.uni-erlangen.de Tue Jul 24 20:53:49 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 24 Jul 2001 12:53:49 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <87ae1ubr57.fsf@orcus.priv.at>; from robbe@orcus.priv.at on Tue, Jul 24, 2001 at 11:41:40AM +0200 References: <15195.26234.988414.175977@ming.empire.pick.ucam.org> <20010723034104.B505@212.23.136.22> <20010723205553.A14623@folly> <87ae1ubr57.fsf@orcus.priv.at> Message-ID: <20010724125349.B17086@faui02.informatik.uni-erlangen.de> i really like to have the gethostname() disappear from the x11 fwd code, and set the display to localhost:xx.yy perhaps someone can make this work? On Tue, Jul 24, 2001 at 11:41:40AM +0200, Robert Bihlmeyer wrote: > Markus Friedl writes: > > > however, i don't want to see a magic numer 401 in openssh's code. > > Well, there's already a magic number in the same file (channel.c) > Lines 2271-2273: > > /* Just set DISPLAY to hostname:screen.display */ > snprintf(display, sizeof display, "%.400s:%d.%d", hostname, > display_number, screen_number); > > It may be good to "#define DISPLAY_MAXHOSTLEN 400" somewhere. > > > why not just define MAXHOSTNAMELEN for HURD ? > > #ifndef MAXHOSTNAMELEN > #define MAXHOSTNAMELEN 256 > #endif > > somewhere in openssh's code would be fine with us. We would like the > other alternatives better, of course. > > -- > Robbe From wichert at wiggy.net Tue Jul 24 21:48:11 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Tue, 24 Jul 2001 13:48:11 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: ; from pekkas@netcore.fi on Tue, Jul 24, 2001 at 09:07:14AM +0300 References: Message-ID: <20010724134811.D27200@cistron.nl> Previously Pekka Savola wrote: > I thought some DNS RFC stated that the maximum length of the hostname was > 255 characters... It's 255 bytes, not character. An important distinction considering multibyte hostnames will be allowed soon. From what I remember that 255 byte limit is supposed to disappear as well. Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert at wiggy.net http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From Marcus.Brinkmann at ruhr-uni-bochum.de Tue Jul 24 22:15:33 2001 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 24 Jul 2001 14:15:33 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: References: Message-ID: <20010724141533.A438@212.23.136.22> Hi, On Mon, Jul 23, 2001 at 11:49:29PM -0500, mouring at etoh.eviladmin.org wrote: > if gethostname() returns failures if the hostname is greater then > MAXHOSTNAMELEN then this whole issue is moot, and this patch is wrong > since it creates a case where you have inconsistance behavior between > platforms. And if that is the case, I will refuse to apply it. The point is that in operating systems, hostnames longer than MAXHOSTNAMELEN are not supported throughout the whole system. So you get a consistent breakage (truncation, whatever) in the system. In the Hurd, the breakage would only apply to the applications which can't deal. So if ssh defines its own arbitrary limit, it could fail where the rest of the Hurd system wouldn't. If many programs define their own (probably different) arbitrary limits, the behaviour of applications would be inconsisten on the Hurd (so, while you slice it for ssh on several platforms, I slice it for the Hurd and several applications :) > I still have to ask the same question I did the last time this was brought > up.. Who in their right mind would have a hostname/FQDN that is over 256 > characters (using OpenBSD's documented limit)?! That is over 3 lines > worth of information to type!!! There are days I wish I would have bought > a shorter name then 'eviladmin.org' =) :) Well, Mr. Gates questioned who would ever need more than 640k memory. Of course, as I said in my first mail, nobody does right now, and if you choose to duck the issue and just define a limit, it will work just fine. Maybe in three years we have all switched to IPv6, and there are some (automatically processed) hostnames which are 257 characters long. Our stance is that we change the code today to deal with any length and not worry about it anymore. > I have no problems if we handle ENAMETOOLONG using xgethostname() > (mirroring naming already used for replacement functions [xstrdup, > xmalloc, etc]). However, since OpenBSD currently does not suppot > ENAMETOOLONG it really should not be in the OpenBSD tree which leaves us > with 3 unique changes for portable. Which is tolerable. I would be very happy about such a change. I am sorry that you have such issues with code maintenance, I was not aware of that. > Until such time we can provide configure.in checks and define such > limitations in our code if the first assumption is true. The change would > require a #define to be set in the configure.in since I know Damien does > not like blindly setting such variables. This is a functional work around (until suddenly the world goes mad and asks for very.long.hostnames ;) [...] > Then having to tip toe around code for platforms that I > can't test. Praying I don't break the platform and it gets released in > such a broken state in the next release (luckly, we have been doing pretty > good on testing before a release thanks to the many people who help out!). If there is nobody testing for the Hurd before a release, maybe we can find someone who is willing to do that. Do you have a low volume mailing list where you announce pre releases for testers? > So, you now understand where I come from. =) Thanks for the explanation. I don't envy you :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org Marcus.Brinkmann at ruhr-uni-bochum.de http://www.marcus-brinkmann.de From mouring at etoh.eviladmin.org Tue Jul 24 23:18:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 24 Jul 2001 08:18:55 -0500 (CDT) Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: <20010724141533.A438@212.23.136.22> Message-ID: On Tue, 24 Jul 2001, Marcus Brinkmann wrote: > Hi, > > On Mon, Jul 23, 2001 at 11:49:29PM -0500, mouring at etoh.eviladmin.org wrote: > > if gethostname() returns failures if the hostname is greater then > > MAXHOSTNAMELEN then this whole issue is moot, and this patch is wrong > > since it creates a case where you have inconsistance behavior between > > platforms. And if that is the case, I will refuse to apply it. > > The point is that in operating systems, hostnames longer than MAXHOSTNAMELEN > are not supported throughout the whole system. So you get a consistent > breakage (truncation, whatever) in the system. In the Hurd, the breakage > would only apply to the applications which can't deal. So if ssh defines > its own arbitrary limit, it could fail where the rest of the Hurd system > wouldn't. If many programs define their own (probably different) arbitrary > limits, the behaviour of applications would be inconsisten on the Hurd > (so, while you slice it for ssh on several platforms, I slice it for the > Hurd and several applications :) > I think you missed the point. =) The point is that I'd rather have consistant behavior over every OS then 4 platforms that continue since they have ENAMETOOLONG and the other 20+ fail. Being consistant for errors is the best when dealing with multiple OS projects. Which was my point above. I'll look back in the archives at the first rounds of patches that where suggested for dynamic gethostname() (almost a year ago IIRC) and see what I can come up with. However, it more then likely will be after my Gen Con trip next week. [..] > > can't test. Praying I don't break the platform and it gets released in > > such a broken state in the next release (luckly, we have been doing pretty > > good on testing before a release thanks to the many people who help out!). > > If there is nobody testing for the Hurd before a release, maybe we can find > someone who is willing to do that. Do you have a low volume mailing list > where you announce pre releases for testers? > We have an announcement list, but I don't believe we have ever used it to call for beta testers. Damien, do I have rights to post to the announcement list? Maybe we should start announcing testing during the code freezes. > > So, you now understand where I come from. =) > > Thanks for the explanation. I don't envy you :) > I have to say a good 90% of the patchsets from OpenBSD's tree apply with little fuss.. But it's the 10% that becames the bane of my existance. If I have my choice, it would stay that way to get better. =) - Ben From Marcus.Brinkmann at ruhr-uni-bochum.de Tue Jul 24 23:41:34 2001 From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue, 24 Jul 2001 15:41:34 +0200 Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: References: Message-ID: <20010724154134.D868@212.23.136.22> On Tue, Jul 24, 2001 at 08:18:55AM -0500, mouring at etoh.eviladmin.org wrote: > I think you missed the point. =) The point is that I'd rather have > consistant behavior over every OS then 4 platforms that continue since > they have ENAMETOOLONG and the other 20+ fail. Being consistant for > errors is the best when dealing with multiple OS projects. Which was my > point above. Ah, I see now. Sorry, I was indeed confused. Well, we would be happy with a change that only applies to systems which don't define MAXHOSTNAMELEN in the first place. (and you can put both versions in xgethostname, so it is completely transparent to the rest of the program). > We have an announcement list, but I don't believe we have ever used it to > call for beta testers. Damien, do I have rights to post to the > announcement list? Maybe we should start announcing testing during the > code freezes. If you announce code freezes I (and maybe others) will subscribe and try to make sure it gets tested on the Hurd (eg, if I don't have time, I forward it to one of the Hurd lists for other people to step up). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd at debian.org Marcus Brinkmann GNU http://www.gnu.org marcus at gnu.org Marcus.Brinkmann at ruhr-uni-bochum.de http://www.marcus-brinkmann.de From somar at tiny.net Wed Jul 25 00:29:44 2001 From: somar at tiny.net (Scott Burch) Date: Tue, 24 Jul 2001 09:29:44 -0500 Subject: OpenSSH and Solaris with 0.9.6x openssl Message-ID: <3B5D8658.A1790F79@tiny.net> Hello, I have tried to install openssh 2.9p2 on Solaris 2.6 and Solaris 2.8 after compiling the openssl (both 0.9.6a and 0.9.6b) and openssh software with both gcc 2.95.3, Sun's Forte compiler, Sun's linker, etc. I have tried the zlib from Sun freeware and version 11.8.0 REV=2000.01.08.18.12 contained in the SUNWzlib package. Both openssh and openssl appear to make properly and all the tests for openssl pass. When I do a make install for openssh it fails to generate public/private dsa keys..in fact ssh_keygen has a bus error when trying to do DSA operations. I know other people have had this problem, because I've seen similar messages in the mailing list. Unfortunately it appears that noone has a solution...at least I can't find an answer. What I am wondering is if anyone can get openssh to work on Solaris with the 0.9.6x openssl libraries. Maybe I'm missing someone, but everything seems to work fine with the 0.9.5x openssl libraries. It appears to me that something broke after the 0.9.5x libraries. I'm not sure if openssl is the problem. If this problem has been resolved then please enlighten me, otherwise I can provide more details to help resolve this issue. Thanks, Scott From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jul 25 01:06:03 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 24 Jul 2001 17:06:03 +0200 Subject: OpenSSH and Solaris with 0.9.6x openssl In-Reply-To: <3B5D8658.A1790F79@tiny.net>; from somar@tiny.net on Tue, Jul 24, 2001 at 09:29:44AM -0500 References: <3B5D8658.A1790F79@tiny.net> Message-ID: <20010724170603.A28918@serv01.aet.tu-cottbus.de> On Tue, Jul 24, 2001 at 09:29:44AM -0500, Scott Burch wrote: > I have tried to install openssh 2.9p2 on Solaris 2.6 and Solaris 2.8 > after compiling the openssl (both 0.9.6a and 0.9.6b) and openssh > software with both gcc 2.95.3, Sun's Forte compiler, Sun's linker, etc. > I have tried the zlib from Sun freeware and version 11.8.0 > REV=2000.01.08.18.12 contained in the SUNWzlib package. Both openssh and > openssl appear to make properly and all the tests for openssl pass. When > I do a make install for openssh it fails to generate public/private dsa > keys..in fact ssh_keygen has a bus error when trying to do DSA > operations. I know other people have had this problem, because I've seen > similar messages in the mailing list. Unfortunately it appears that > noone has a solution...at least I can't find an answer. What I am > wondering is if anyone can get openssh to work on Solaris with the > 0.9.6x openssl libraries. Maybe I'm missing someone, but everything > seems to work fine with the 0.9.5x openssl libraries. It appears to me > that something broke after the 0.9.5x libraries. I'm not sure if openssl > is the problem. If this problem has been resolved then please enlighten > me, otherwise I can provide more details to help resolve this issue. There is a more or less simple answer to this problem. Somebody who can reproduce this problem must recompile OpenSSH and OpenSSL with debugger support and analyze the core dump, to see where the problem is coming from. Of course I assume, that the header files used for the compilation matches the library versions of the openssl libraries actually linked in. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From jim at ic.uva.nl Wed Jul 25 02:50:55 2001 From: jim at ic.uva.nl (Jim Mintha) Date: Tue, 24 Jul 2001 18:50:55 +0200 Subject: OpenSSH and Solaris with 0.9.6x openssl In-Reply-To: <3B5D8658.A1790F79@tiny.net>; from somar@tiny.net on Tue, Jul 24, 2001 at 09:29:44AM -0500 References: <3B5D8658.A1790F79@tiny.net> Message-ID: <20010724185055.C12688@ic.uva.nl> On Tue, Jul 24, 2001 at 09:29:44AM -0500, Scott Burch wrote: > Hello, > > I have tried to install openssh 2.9p2 on Solaris 2.6 and Solaris 2.8 > after compiling the openssl (both 0.9.6a and 0.9.6b) and openssh > software with both gcc 2.95.3, Sun's Forte compiler, Sun's linker, etc. > I have tried the zlib from Sun freeware and version 11.8.0 > REV=2000.01.08.18.12 contained in the SUNWzlib package. Both openssh and > openssl appear to make properly and all the tests for openssl pass. When > I do a make install for openssh it fails to generate public/private dsa > keys..in fact ssh_keygen has a bus error when trying to do DSA > operations. I know other people have had this problem, because I've seen > similar messages in the mailing list. Unfortunately it appears that > noone has a solution...at least I can't find an answer. What I am > wondering is if anyone can get openssh to work on Solaris with the > 0.9.6x openssl libraries. Maybe I'm missing someone, but everything > seems to work fine with the 0.9.5x openssl libraries. It appears to me > that something broke after the 0.9.5x libraries. I'm not sure if openssl > is the problem. If this problem has been resolved then please enlighten > me, otherwise I can provide more details to help resolve this issue. Not sure if it is helpful but it worked for me. Here are the tools/libraries that I used openssl 0.9.6 openssh 2.9p2 (configure --with-tcp-wrapper --without-pam) gcc 2.95.3 zlib 1.1.3 ANDIrand package from http://www.cosy.sbg.ac.at/~andi/ which provides /dev/random for solaris. The only difference is the 0.9.6 instead of 0.9.6a/b. I just did a quick build of 0.9.6b and ssh and it seems to work fine, but I didn't test it too much. Jim -- Jim Mintha Email: jim at ic.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 stevesk at pobox.com Wed Jul 25 03:47:14 2001 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 24 Jul 2001 10:47:14 -0700 (PDT) Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: Message-ID: On Sun, 22 Jul 2001, William L. Jones wrote: :This patch is against Cray patch against openssh-SNAP-20010710. Here :a few notes about them: : :1) rijndael does not work on cray due to the fact it is rooted in 32 bits. : I looking for a fix, it may come form Wendy Palam. For now the cray : default to the following cihpers for ssh version 2 ssh are: : 3des-cbc,blowfish-cbc,cast128-cbc,arcfour i don't know the issues, but you can drop Brian Gladman a line, as it's his implementation. note that openssh doesn't use his latest version. http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm :2) Crays don't have setitimer so I changed scp.c to use alarm which : should work on all systems. i can see if something like this makes sense to go into the openbsd tree. :3) Created bsd-cray.c in openbsd-compat. This mainly supports cray TMPDIR : environment variable, jid, and setting job and process limits form cray's : udb. I could have put them in seesion.c but I think session.c is getting : to loaded with speicalied system codes. The same is true for pty.c. : Maby it time to split out the code int seperate system modules in : the openbsd-compat directiry. : :4) Fixed a few minor issues with resetting SIGCHLD. If you permanently :install : a signal with mysingnal for SIGCHLD you don't need to reset it in the : sigchld handler. You can get into a infinite signal loop if the sigchld : handler does not reap the child win it is called if it reset the sigchld : handler, it is a cray thing. does cray have sigaction()? i think we should be using mysignal() in the protocol 1 loop now that the signal handlers have converged. can you try the patch below? :5) It is possible to get an EINTR on a waitpid call on a cray, it has to do : with the job termination signal. Loop on waitpid if errno is EINTR in : serverloop.c another possible change to sync with openbsd. :6) Cray gets pty differently so getpty.c has a few more levels of ifdef's, : sigh. i need to look at that closer. :7) Add some more cray specific prng commands. Needed more entropy! : :Let me know if you have any questions or need any changes to this set :of patches. Index: serverloop.c =================================================================== RCS file: /var/cvs/openssh/serverloop.c,v retrieving revision 1.74 diff -u -r1.74 serverloop.c --- serverloop.c 2001/07/18 16:01:48 1.74 +++ serverloop.c 2001/07/24 17:35:35 @@ -448,7 +448,7 @@ /* Initialize the SIGCHLD kludge. */ child_terminated = 0; - signal(SIGCHLD, sigchld_handler); + mysignal(SIGCHLD, sigchld_handler); /* Initialize our global variables. */ fdin = fdin_arg; @@ -621,7 +621,7 @@ channel_free_all(); /* We no longer want our SIGCHLD handler to be called. */ - signal(SIGCHLD, SIG_DFL); + mysignal(SIGCHLD, SIG_DFL); wait_pid = waitpid(-1, &wait_status, child_terminated ? WNOHANG : 0); if (wait_pid == -1) @@ -710,7 +710,7 @@ if (writeset) xfree(writeset); - signal(SIGCHLD, SIG_DFL); + mysignal(SIGCHLD, SIG_DFL); while ((pid = waitpid(-1, &status, WNOHANG)) > 0) session_close_by_pid(pid, status); From john at chattanooga.net Wed Jul 25 04:13:05 2001 From: john at chattanooga.net (John Aldrich) Date: Tue, 24 Jul 2001 14:13:05 -0400 Subject: Small buglet trying to recompile SRPM Message-ID: <0107241413051G.13209@slave1.highertech.net> I've got RedHat 7.1 and when I downloaded the SRPM for openssh-2.9p2-1.src.rpm and tried to rpm --recompile it bombed. Here's the error message that it generated: + pushd x11-ssh-askpass-1.2.0 /usr/src/redhat/BUILD/openssh-2.9p2/x11-ssh-askpass-1.2.0 /usr/src/redhat/BUILD/openssh-2.9p2 + xmkmf -a imake -DUseInstalled -I/usr/X11R6/lib/X11/config make Makefiles Makefile:1052: *** target file `distclean' has both : and :: entries. Stop. error: Bad exit status from /var/tmp/rpm-tmp.57894 (%build) My "critical" files are as follows: RPM version: 4.0.2-8 OpenSSL Version: openssl-0.9.6-9 C++: cpp-2.96-85 GCC: same libstdc++: same Any questions? I'm not subbed to the list, so please CC me on any replies. thanks... John From partain at dcs.gla.ac.uk Wed Jul 25 04:17:37 2001 From: partain at dcs.gla.ac.uk (Will Partain) Date: 24 Jul 2001 19:17:37 +0100 Subject: OpenSSH and Solaris with 0.9.6x openssl In-Reply-To: <3B5D8658.A1790F79@tiny.net> References: <3B5D8658.A1790F79@tiny.net> Message-ID: Scott Burch writes: > I do a make install for openssh it fails to generate public/private dsa > keys..in fact ssh_keygen has a bus error when trying to do DSA > operations. I know other people have had this problem, because I've seen > similar messages in the mailing list. Unfortunately it appears that > noone has a solution... I was one of those people, and I think I'm out of the woods... I think there was more than one (bad) thing going on, and I cannot explain all of them... Anyway, I'm cookin' with: sparc-solaris2.6 (reasonably well patched) openssl 0.9.6b (had problems with anything earlier) openssh 2.9p2 (I don't *think* the configure options matter) gcc 3.0 (not sure that this matters) zlib 1.1.3 The problem that was *killing* me was: I compile openssl (and everything else) in directories-other-than-the-source, using the olde fashioned "symlink farm" method. HOWEVER, openssl has a couple of strategically-placed symlinks itself, and if you do symlinks-to-those-symlinks, you *will* hose yourself. I therefore run the bit of code below in the directory where I plan to build, *just before* I run ./Configure. Hope this is of some use, Will ===================================================== FIND=/usr/bin/find XARGS=/usr/bin/xargs # There are potentially several versions of .../opensslconf.h # floating about, and it is VERY important that we get rid of # any potentially bogus ones and end up with only the right ones. # So: make sure there are *none* in the original source, # the src linkfarm or here: $FIND ../openssl-* ../src . -name opensslconf.h -print | $XARGS /bin/rm -f # The include directory one is supposed to link to the # crypto/ dir one: $LN -s ../../crypto/opensslconf.h include/openssl/opensslconf.h # The default stuff writes new versions of these without /bin/rm'ing # them first; very naughty; so we help: $FIND ../openssl-* ../src -name Makefile.save -print | $XARGS /bin/rm -f /bin/rm -f Makefile.ssl From jones at mail.utexas.edu Wed Jul 25 04:48:07 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Tue, 24 Jul 2001 13:48:07 -0500 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: Message-ID: > -----Original Message----- > From: Kevin Steves [mailto:stevesk at pobox.com] > Sent: Tuesday, July 24, 2001 12:47 PM > To: William L. Jones > Cc: openssh-unix-dev at mindrot.org; jones at tacc.utexas.edu > Subject: Re: Patches for Cray T3Es running Unicossmk and SV1s running > Unicos > > > On Sun, 22 Jul 2001, William L. Jones wrote: > :This patch is against Cray patch against openssh-SNAP-20010710. Here > :a few notes about them: > : > :1) rijndael does not work on cray due to the fact it is rooted > in 32 bits. > : I looking for a fix, it may come form Wendy Palam. For now the cray > : default to the following cihpers for ssh version 2 ssh are: > : 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > > i don't know the issues, but you can drop Brian Gladman > a line, as it's his implementation. note that > openssh doesn't use his latest version. > http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm > I see if is intreasted in porting it to a cray. And I will take a look at his recent version and see if it can handle cray 64 bit carys. > :2) Crays don't have setitimer so I changed scp.c to use alarm which > : should work on all systems. > > i can see if something like this makes sense to go into the openbsd tree. > > :3) Created bsd-cray.c in openbsd-compat. This mainly supports > cray TMPDIR > : environment variable, jid, and setting job and process limits > form cray's > : udb. I could have put them in seesion.c but I think > session.c is getting > : to loaded with speicalied system codes. The same is true for pty.c. > : Maby it time to split out the code int seperate system modules in > : the openbsd-compat directiry. > : > :4) Fixed a few minor issues with resetting SIGCHLD. If you permanently > :install > : a signal with mysingnal for SIGCHLD you don't need to reset it in the > : sigchld handler. You can get into a infinite signal loop if > the sigchld > : handler does not reap the child win it is called if it reset > the sigchld > : handler, it is a cray thing. > > does cray have sigaction()? i think we should be using mysignal() in the > protocol 1 loop now that the signal handlers have converged. can you try > the patch below? > Will do! > :5) It is possible to get an EINTR on a waitpid call on a cray, > it has to do > : with the job termination signal. Loop on waitpid if errno is EINTR in > : serverloop.c > > another possible change to sync with openbsd. > > :6) Cray gets pty differently so getpty.c has a few more levels > of ifdef's, > : sigh. > > i need to look at that closer. > > :7) Add some more cray specific prng commands. Needed more entropy! > : > :Let me know if you have any questions or need any changes to this set > :of patches. > > I still need to provided a better cray patch to deattack.c. I botched the one I sent out so that part of the patch should be appliced to source the source. Bill Jones From wendyp at cray.com Wed Jul 25 04:52:46 2001 From: wendyp at cray.com (Wendy Palm) Date: Tue, 24 Jul 2001 13:52:46 -0500 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos References: Message-ID: <3B5DC3FE.C824441F@cray.com> Kevin Steves wrote: > > On Sun, 22 Jul 2001, William L. Jones wrote: > :This patch is against Cray patch against openssh-SNAP-20010710. Here > :a few notes about them: > : > :1) rijndael does not work on cray due to the fact it is rooted in 32 bits. > : I looking for a fix, it may come form Wendy Palam. For now the cray > : default to the following cihpers for ssh version 2 ssh are: > : 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > > i don't know the issues, but you can drop Brian Gladman > a line, as it's his implementation. note that > openssh doesn't use his latest version. > http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm thanks. i will. > > :2) Crays don't have setitimer so I changed scp.c to use alarm which > : should work on all systems. > > i can see if something like this makes sense to go into the openbsd tree. > > :3) Created bsd-cray.c in openbsd-compat. This mainly supports cray TMPDIR > : environment variable, jid, and setting job and process limits form cray's > : udb. I could have put them in seesion.c but I think session.c is getting > : to loaded with speicalied system codes. The same is true for pty.c. > : Maby it time to split out the code int seperate system modules in > : the openbsd-compat directiry. > : > :4) Fixed a few minor issues with resetting SIGCHLD. If you permanently > :install > : a signal with mysingnal for SIGCHLD you don't need to reset it in the > : sigchld handler. You can get into a infinite signal loop if the sigchld > : handler does not reap the child win it is called if it reset the sigchld > : handler, it is a cray thing. > > does cray have sigaction()? i think we should be using mysignal() in the > protocol 1 loop now that the signal handlers have converged. can you try > the patch below? yes. cray does have sigaction(). i'll check out the patch you provided (but probably won't get to it til next week, sorry). bill might beat me to it. > > :5) It is possible to get an EINTR on a waitpid call on a cray, it has to do > : with the job termination signal. Loop on waitpid if errno is EINTR in > : serverloop.c > > another possible change to sync with openbsd. > > :6) Cray gets pty differently so getpty.c has a few more levels of ifdef's, > : sigh. > > i need to look at that closer. > > :7) Add some more cray specific prng commands. Needed more entropy! > : > :Let me know if you have any questions or need any changes to this set > :of patches. thanks. wendy > > Index: serverloop.c > =================================================================== > RCS file: /var/cvs/openssh/serverloop.c,v > retrieving revision 1.74 > diff -u -r1.74 serverloop.c > --- serverloop.c 2001/07/18 16:01:48 1.74 > +++ serverloop.c 2001/07/24 17:35:35 > @@ -448,7 +448,7 @@ > > /* Initialize the SIGCHLD kludge. */ > child_terminated = 0; > - signal(SIGCHLD, sigchld_handler); > + mysignal(SIGCHLD, sigchld_handler); > > /* Initialize our global variables. */ > fdin = fdin_arg; > @@ -621,7 +621,7 @@ > channel_free_all(); > > /* We no longer want our SIGCHLD handler to be called. */ > - signal(SIGCHLD, SIG_DFL); > + mysignal(SIGCHLD, SIG_DFL); > > wait_pid = waitpid(-1, &wait_status, child_terminated ? WNOHANG : 0); > if (wait_pid == -1) > @@ -710,7 +710,7 @@ > if (writeset) > xfree(writeset); > > - signal(SIGCHLD, SIG_DFL); > + mysignal(SIGCHLD, SIG_DFL); > > while ((pid = waitpid(-1, &status, WNOHANG)) > 0) > session_close_by_pid(pid, status); -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From carson at taltos.org Wed Jul 25 04:58:44 2001 From: carson at taltos.org (Carson Gaspar) Date: Tue, 24 Jul 2001 11:58:44 -0700 Subject: OpenSSH and Solaris with 0.9.6x openssl In-Reply-To: <3B5D8658.A1790F79@tiny.net> References: <3B5D8658.A1790F79@tiny.net> Message-ID: <3541024484.995975924@ZATHROS> I have built the last many versions of OpenSSH, using zlib 1.1.3, and openssl 0.9.6, 0.9.6a, and 0.9.6b, using both Forte C and gcc 2.95.3, on SunOS 5.5.1, 5.6, 5.7, and 5.8. I've never seen this problem. I suggest you _don't_ use the downloaded packages off the net, but build everything yourself, all on the _same_ version of SunOS (e.g. don't run 5.6 binaries on 5.8). -- Carson Gaspar - carson at taltos.org Queen trapped in a butch body From jones at mail.utexas.edu Wed Jul 25 05:03:11 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Tue, 24 Jul 2001 14:03:11 -0500 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: <3B5DC3FE.C824441F@cray.com> Message-ID: Thanks it one less thing I have to worry about! > -----Original Message----- > From: owner-openssh-unix-dev at mindrot.org > [mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of Wendy Palm > Sent: Tuesday, July 24, 2001 1:53 PM > To: openssh-unix-dev at mindrot.org > Subject: Re: Patches for Cray T3Es running Unicossmk and SV1s running > Unicos > > > Kevin Steves wrote: > > > > On Sun, 22 Jul 2001, William L. Jones wrote: > > :This patch is against Cray patch against openssh-SNAP-20010710. Here > > :a few notes about them: > > : > > :1) rijndael does not work on cray due to the fact it is rooted > in 32 bits. > > : I looking for a fix, it may come form Wendy Palam. For now the cray > > : default to the following cihpers for ssh version 2 ssh are: > > : 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > > > > i don't know the issues, but you can drop Brian Gladman > > a line, as it's his implementation. note that > > openssh doesn't use his latest version. > > http://fp.gladman.plus.com/cryptography_technology/rijndael/index.htm > > thanks. i will. > > > > > :2) Crays don't have setitimer so I changed scp.c to use alarm which > > : should work on all systems. > > > > i can see if something like this makes sense to go into the > openbsd tree. > > > > :3) Created bsd-cray.c in openbsd-compat. This mainly supports > cray TMPDIR > > : environment variable, jid, and setting job and process > limits form cray's > > : udb. I could have put them in seesion.c but I think > session.c is getting > > : to loaded with speicalied system codes. The same is true for pty.c. > > : Maby it time to split out the code int seperate system modules in > > : the openbsd-compat directiry. > > : > > :4) Fixed a few minor issues with resetting SIGCHLD. If you > permanently > > :install > > : a signal with mysingnal for SIGCHLD you don't need to reset > it in the > > : sigchld handler. You can get into a infinite signal loop > if the sigchld > > : handler does not reap the child win it is called if it > reset the sigchld > > : handler, it is a cray thing. > > > > does cray have sigaction()? i think we should be using > mysignal() in the > > protocol 1 loop now that the signal handlers have converged. > can you try > > the patch below? > > yes. cray does have sigaction(). i'll check out the patch you > provided (but > probably won't get to it til next week, sorry). bill might beat me to it. > > > > > :5) It is possible to get an EINTR on a waitpid call on a cray, > it has to do > > : with the job termination signal. Loop on waitpid if errno > is EINTR in > > : serverloop.c > > > > another possible change to sync with openbsd. > > > > :6) Cray gets pty differently so getpty.c has a few more levels > of ifdef's, > > : sigh. > > > > i need to look at that closer. > > > > :7) Add some more cray specific prng commands. Needed more entropy! > > : > > :Let me know if you have any questions or need any changes to this set > > :of patches. > > thanks. > wendy > > > > > > Index: serverloop.c > > =================================================================== > > RCS file: /var/cvs/openssh/serverloop.c,v > > retrieving revision 1.74 > > diff -u -r1.74 serverloop.c > > --- serverloop.c 2001/07/18 16:01:48 1.74 > > +++ serverloop.c 2001/07/24 17:35:35 > > @@ -448,7 +448,7 @@ > > > > /* Initialize the SIGCHLD kludge. */ > > child_terminated = 0; > > - signal(SIGCHLD, sigchld_handler); > > + mysignal(SIGCHLD, sigchld_handler); > > > > /* Initialize our global variables. */ > > fdin = fdin_arg; > > @@ -621,7 +621,7 @@ > > channel_free_all(); > > > > /* We no longer want our SIGCHLD handler to be called. */ > > - signal(SIGCHLD, SIG_DFL); > > + mysignal(SIGCHLD, SIG_DFL); > > > > wait_pid = waitpid(-1, &wait_status, child_terminated ? > WNOHANG : 0); > > if (wait_pid == -1) > > @@ -710,7 +710,7 @@ > > if (writeset) > > xfree(writeset); > > > > - signal(SIGCHLD, SIG_DFL); > > + mysignal(SIGCHLD, SIG_DFL); > > > > while ((pid = waitpid(-1, &status, WNOHANG)) > 0) > > session_close_by_pid(pid, status); > > -- > wendy palm > Cray OS Sustaining Engineering, Cray Inc. > wendyp at cray.com, 651-605-9154 > From mstone at cs.loyola.edu Wed Jul 25 05:50:11 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Tue, 24 Jul 2001 15:50:11 -0400 Subject: Patches for Cray T3Es running Unicossmk and SV1s running Unicos In-Reply-To: ; from stevesk@pobox.com on Tue, Jul 24, 2001 at 10:47:14AM -0700 References: Message-ID: <20010724155011.H9022@justice.loyola.edu> On Tue, Jul 24, 2001 at 10:47:14AM -0700, Kevin Steves wrote: > :4) Fixed a few minor issues with resetting SIGCHLD. If you permanently > :install > : a signal with mysingnal for SIGCHLD you don't need to reset it in the > : sigchld handler. You can get into a infinite signal loop if the sigchld > : handler does not reap the child win it is called if it reset the sigchld > : handler, it is a cray thing. > > does cray have sigaction()? i think we should be using mysignal() in the > protocol 1 loop now that the signal handlers have converged. can you try > the patch below? That should work fine. IIRC, the issue was in resetting the sigchld handler inside the sigchld_handler2 before actually wait()ing for the child. (Which meant you'd get bounced right back into the sigchld handler...) -- Mike Stone From somar at tiny.net Wed Jul 25 05:58:31 2001 From: somar at tiny.net (Scott Burch) Date: Tue, 24 Jul 2001 14:58:31 -0500 Subject: Debugging ssh-keygen dsa on Solaris8 Message-ID: <3B5DD367.557FA94@tiny.net> Hello, >From the response to my original post regarding openssh, obviously the only way to resolve the problem of getting openssh to work properly under Solaris 8 with openssl 0.9.6b was to compile with debugging an analyze to core file. Let me state that I am not a developer, but maybe the following will help. I have compiled both openssh2.96p2 and openssl 0.9.6b with debugging using the Sun Forte Compiler update 2. I compiled each piece of software without any additional options, the only thing I did was change the --prefix. Below is some output from dbx: (The core I am examining here comes from the make install...when it trys to create the private/public dsa keys.) (If there is anything else I can do to help let me know. The system is 5.8 Generic_108528-08 with the recommended patch cluster from July 11th. This is an Ultra10 workstation) I also have the same problem using gcc 2.95.3 on Solaris 8 and Solaris 2.6. Reading ssh-keygen core file header read successfully Reading ld.so.1 Reading libsocket.so.1 Reading libnsl.so.1 Reading libgen.so.1 Reading libc.so.1 Reading libdl.so.1 Reading libmp.so.2 Reading libc_psr.so.1 program terminated by signal BUS (invalid address alignment) Current function is DSA_new_method (optimized) 127 ret->flags=ret->meth->flags; (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where =>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in "dsa_lib.c" [2] DSA_new() (optimized), at 0x4b580 (line ~86) in "dsa_lib.c" [3] DSA_generate_parameters(bits = ???, seed_in = ???, seed_len = ???, counter_ret = ???, h_ret = ???, callback = ???, cb_arg = ???) (optimized), at 0x4ace4 (line ~115) in "dsa_gen.c" [4] dsa_generate_private_key(bits = 1024U), line 560 in "key.c" [5] key_generate(type = 2, bits = 1024U), line 576 in "key.c" [6] main(ac = 7, av = 0xffbefc74), line 781 in "ssh-keygen.c" From jmknoble at pobox.com Wed Jul 25 06:11:30 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 24 Jul 2001 16:11:30 -0400 Subject: Small buglet trying to recompile SRPM In-Reply-To: <0107241413051G.13209@slave1.highertech.net>; from john@chattanooga.net on Tue, Jul 24, 2001 at 02:13:05PM -0400 References: <0107241413051G.13209@slave1.highertech.net> Message-ID: <20010724161130.B25153@zax.half.pint-stowp.cx> Circa 2001-Jul-24 14:13:05 -0400 dixit John Aldrich: : I've got RedHat 7.1 and when I downloaded the SRPM for : openssh-2.9p2-1.src.rpm and tried to rpm --recompile it bombed. : : Here's the error message that it generated: : + pushd x11-ssh-askpass-1.2.0 : /usr/src/redhat/BUILD/openssh-2.9p2/x11-ssh-askpass-1.2.0 : /usr/src/redhat/BUILD/openssh-2.9p2 : + xmkmf -a : imake -DUseInstalled -I/usr/X11R6/lib/X11/config : make Makefiles : Makefile:1052: *** target file `distclean' has both : and :: entries. Stop. : error: Bad exit status from /var/tmp/rpm-tmp.57894 (%build) For what it's worth (in case it's not obvious to you), the problem is in building x11-ssh-askpass (the graphical passphrase dialog), not OpenSSH proper. I'm the author and maintainer of x11-ssh-askpass. Sounds like your imake configuration adds some targets to the generated Makefile that no one else's does. Or, potentially, your version of 'make' complains at something that no one else's does. Please send the output of the following commands: rpm -qa |fgrep -i XFree86 |sort rpm -qf `which make` Also, please send me (privately, not to the list) the following: /usr/src/redhat/BUILD/openssh-2.9p2/x11-ssh-askpass-1.2.0/Imakefile /usr/src/redhat/BUILD/openssh-2.9p2/x11-ssh-askpass-1.2.0/Makefile so that i can try to diagnose the problem. -- 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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010724/4c31bfbf/attachment.bin From jmknoble at pobox.com Wed Jul 25 06:24:00 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 24 Jul 2001 15:24:00 -0500 Subject: Small buglet trying to recompile SRPM In-Reply-To: <0107241413051G.13209@slave1.highertech.net>; from john@chattanooga.net on Tue, Jul 24, 2001 at 02:13:05PM -0400 References: <0107241413051G.13209@slave1.highertech.net> Message-ID: <20010724152400.A13606@zax.half.pint-stowp.cx> Circa 2001-Jul-24 14:13:05 -0400 dixit John Aldrich: : I've got RedHat 7.1 and when I downloaded the SRPM for : openssh-2.9p2-1.src.rpm and tried to rpm --recompile it bombed. : : Here's the error message that it generated: : + pushd x11-ssh-askpass-1.2.0 : /usr/src/redhat/BUILD/openssh-2.9p2/x11-ssh-askpass-1.2.0 Damien, out of curiosity, is there a particular reason that you're not including x11-ssh-askpass-1.2.2 in the RPM packages, other than that you've not had much time? -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ | jmknoble at jmknoble.cx | http://www.jmknoble.cx/ (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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010724/e315ba26/attachment.bin From carson at taltos.org Wed Jul 25 06:32:28 2001 From: carson at taltos.org (Carson Gaspar) Date: Tue, 24 Jul 2001 13:32:28 -0700 Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <3B5DD367.557FA94@tiny.net> References: <3B5DD367.557FA94@tiny.net> Message-ID: <3546647890.995981548@ZATHROS> --On Tuesday, July 24, 2001 2:58 PM -0500 Scott Burch wrote: > analyze to core file. Let me state that I am not a developer, but maybe > the following will help. I have compiled both openssh2.96p2 and openssl > 0.9.6b with debugging using the Sun Forte Compiler update 2. I compiled Update 2? Isn't that beta? Or did it just ship? > where > =>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in > "dsa_lib.c" Please disable optimization, at least for dsa_lib.c -- Carson Gaspar - carson at taltos.org Queen trapped in a butch body From mouring at etoh.eviladmin.org Wed Jul 25 07:01:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 24 Jul 2001 16:01:08 -0500 (CDT) Subject: [PATCH] New Solaris Package script. Message-ID: I finally finished a full rewrite of the solaris packaging software for OpenSSH. This is still very young, but it should be considered the replacement for the existing system. It's a fake root package build so any ./configure options you use that changes where your configuration files and such go should be captured. It's not fully tested. However, I'm building packages for /opt and it works like a charm. I'm currently borrowing openssh.server from the openSSH-Tool.tar written by two Sun employees, and with Mr Watson's and Sun's permission I would like to include their openssh.server (renamed to opensshd but nothing else was changed so far) as part of the offical CVS tree when I feel the replacement is finished. If this is acceptable, I need to know what license it should be put under. We would perfer a BSD or PD license if possible. TODO: 1) Clean up the code. 2) Remove hardcoded references from the main part of the source 3) Test as many possible ./configure file placements to ensure they all are taken care of correctly. 4) Provide --with-prng=/path/to/prng/source option so that we can bundle PRNGD in with the final package to make things easier for deployment (One of the reason why I like Sun's version of the init script it comes with the ability to enable/disable PRNGD with out any real fuss). I've ONLY tested this on Solaris 7, but I will get to testing it under 2.5.1 tomorrow. For those building Solaris packages try it out and let me know how it goes. It should work for any version of OpenSSH. And as always, send me any patches for improvementa or fixes. If I don't hear too much bloody curling screems by time I get back from vacation I'll commit it. - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris2.tar Type: application/octet-stream Size: 11776 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010724/53f0bec6/attachment.obj From mouring at etoh.eviladmin.org Wed Jul 25 07:22:18 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 24 Jul 2001 16:22:18 -0500 (CDT) Subject: [PATCH] New Solaris Package script. In-Reply-To: Message-ID: Drat, =) Missing a patch. Makefile.in also needs to be modified to handle keyless installs. --- openssh/Makefile.in Sun Jul 22 14:07:53 2001 +++ ssh/Makefile.in Tue Jul 24 11:12:35 2001 @@ -171,6 +171,7 @@ autoreconf install: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files host-key +install-nokeys: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files install-files: $(srcdir)/mkinstalldirs $(DESTDIR)$(bindir) From eds at reric.net Wed Jul 25 08:32:33 2001 From: eds at reric.net (Eric Seppanen) Date: Tue, 24 Jul 2001 17:32:33 -0500 Subject: OpenSSH 2.9p2+Kerberos5 on RH7.1 fails Message-ID: <20010724173233.A27541@thud.reric.net> I've been installing OpenSSH 2.9p2 onto several RedHat Linux machines, after compiling in the GSSAPI/Kerberos5 patch from here: http://www.sxw.org.uk/computing/patches/openssh.html I've been using ssh both to let users in via passwords and Kerberos tickets, and both have been working fine... except for one irritating machine, which (for no good reason I can see) fails when using kerberos tickets. (it works fine when using passwords.) This is a Red Hat 7.1 machine, and the failure is: (the user sees:) [eds at ike eds]$ ssh hulk Connection closed by 208.24.105.2 (the server log reads:) Jul 24 16:37:41 hulk sshd[25687]: fatal: gss_accept_context died (if I run sshd -d I see:) Connection from 208.24.105.19 port 2847 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. 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: Wait SSH2_MSG_GSSAPI_INIT debug1: Miscellaneous failure debug1: Unknown code z 0 debug1: Got no client credentials gss_accept_context died debug1: Calling cleanup 0x8068fe0(0x0) I've built source and binary RPMS. Anyone interested can find them at http://www.reric.net/linux/openssh/ Anyone have any ideas what's wrong? Eric From djm at mindrot.org Wed Jul 25 09:55:32 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Jul 2001 09:55:32 +1000 (EST) Subject: forwarded message from mouring@etoh.eviladmin.org In-Reply-To: Message-ID: On Tue, 24 Jul 2001 mouring at etoh.eviladmin.org wrote: > > If there is nobody testing for the Hurd before a release, maybe we can find > > someone who is willing to do that. Do you have a low volume mailing list > > where you announce pre releases for testers? > > We have an announcement list, but I don't believe we have ever used it to > call for beta testers. Damien, do I have rights to post to the > announcement list? Maybe we should start announcing testing during the > code freezes. Yes and yes :) -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Wed Jul 25 10:10:13 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Jul 2001 10:10:13 +1000 (EST) Subject: Small buglet trying to recompile SRPM In-Reply-To: <20010724152400.A13606@zax.half.pint-stowp.cx> Message-ID: On Tue, 24 Jul 2001, Jim Knoble wrote: > Damien, out of curiosity, is there a particular reason that you're not > including x11-ssh-askpass-1.2.2 in the RPM packages, other than that > you've not had much time? Sorry - I must have missed you announce message. I'll fix -current now. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From ruf at tik.ee.ethz.ch Wed Jul 25 18:37:20 2001 From: ruf at tik.ee.ethz.ch (Lukas Ruf) Date: Wed, 25 Jul 2001 10:37:20 +0200 Subject: OpenSSH and Solaris with 0.9.6x openssl In-Reply-To: <3B5D8658.A1790F79@tiny.net>; from somar@tiny.net on Tue, Jul 24, 2001 at 09:29:44AM -0500 References: <3B5D8658.A1790F79@tiny.net> Message-ID: <20010725103720.G24054@tik.ee.ethz.ch> We experienced similar problems -- strange enough it works on all our (approx. 60) machines (2.6, 2.7, 2.8) except but one single Ultra30 that refuses from generating the DSA stuff. Lukily for us, we could just declare this single machine to be a test machine... We made use of the CC provided by Sun but compiled everything ourselves. --lpr On Tue, 24 Jul 2001, Scott Burch wrote: > Hello, > > I have tried to install openssh 2.9p2 on Solaris 2.6 and Solaris 2.8 > after compiling the openssl (both 0.9.6a and 0.9.6b) and openssh > software with both gcc 2.95.3, Sun's Forte compiler, Sun's linker, etc. > I have tried the zlib from Sun freeware and version 11.8.0 > REV=2000.01.08.18.12 contained in the SUNWzlib package. Both openssh and > openssl appear to make properly and all the tests for openssl pass. When > I do a make install for openssh it fails to generate public/private dsa > keys..in fact ssh_keygen has a bus error when trying to do DSA > operations. I know other people have had this problem, because I've seen > similar messages in the mailing list. Unfortunately it appears that > noone has a solution...at least I can't find an answer. What I am > wondering is if anyone can get openssh to work on Solaris with the > 0.9.6x openssl libraries. Maybe I'm missing someone, but everything > seems to work fine with the 0.9.5x openssl libraries. It appears to me > that something broke after the 0.9.5x libraries. I'm not sure if openssl > is the problem. If this problem has been resolved then please enlighten > me, otherwise I can provide more details to help resolve this issue. > > Thanks, > Scott -- Lukas Ruf Swiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312 Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED; Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7 CH-8092 Zurich From vinschen at redhat.com Wed Jul 25 19:09:31 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 25 Jul 2001 11:09:31 +0200 Subject: [PATCH]: sftp: Avoid paths beginning with "//" Message-ID: <20010725110931.B490@cygbert.vinschen.de> Hi, the following patch has been suggested by Mark Bradshaw . The simple concatenation of filenames in sftp client and server results in creating filenames beginning with double slashes when the cwd is the root directory: cwd: "/bar/baz" file: "foo" cwd + "/" + file = "/bar/baz/foo" cwd: "/" file: "foo" cwd + "/" + file = "//foo" While that's no problem on U*X based OSes, it's a problem at least on Windows platforms due to the fact that the "//" syntax is reserved for network paths in the style "//server/share". So, if the above concatenation occurs a Windows box desperately tries to contact a remote box called "foo" instead of trying to access file "/foo". The below patch is least intrusive, IMO. It simply checks if the directory is "/" before concatenation and avoids to add another "/" then. The problem is cross platform since the client is concerned as well. The reason is that the path concatenation occurs partly on the client side. So, if somebody starts an sftp client on a Sun box to connect to an sftp-server on a Windows box, the same problem occurs. That's the reason the patch is not `#ifdef'd' in any way. Thanks, Corinna Index: sftp-int.c =================================================================== RCS file: /cvs/openssh_cvs/sftp-int.c,v retrieving revision 1.27 diff -u -p -r1.27 sftp-int.c --- sftp-int.c 2001/07/14 02:19:37 1.27 +++ sftp-int.c 2001/07/25 08:44:29 @@ -204,7 +204,8 @@ path_append(char *p1, char *p2) ret = xmalloc(len); strlcpy(ret, p1, len); - strlcat(ret, "/", len); + if (strcmp(p1, "/") != 0) + strlcat(ret, "/", len); strlcat(ret, p2, len); return(ret); Index: sftp-server.c =================================================================== RCS file: /cvs/openssh_cvs/sftp-server.c,v retrieving revision 1.34 diff -u -p -r1.34 sftp-server.c --- sftp-server.c 2001/07/04 03:32:33 1.34 +++ sftp-server.c 2001/07/25 08:44:31 @@ -756,8 +756,8 @@ process_readdir(void) stats = xrealloc(stats, nstats * sizeof(Stat)); } /* XXX OVERFLOW ? */ - snprintf(pathname, sizeof pathname, - "%s/%s", path, dp->d_name); + snprintf(pathname, sizeof pathname, "%s%s%s", path, + strcmp(path, "/") ? "/" : "", dp->d_name); if (lstat(pathname, &st) < 0) continue; stat_to_attrib(&st, &(stats[count].attrib)); -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Jul 25 19:54:37 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 25 Jul 2001 11:54:37 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <3B5DD367.557FA94@tiny.net>; from somar@tiny.net on Tue, Jul 24, 2001 at 02:58:31PM -0500 References: <3B5DD367.557FA94@tiny.net> Message-ID: <20010725115437.B28742@ws01.aet.tu-cottbus.de> On Tue, Jul 24, 2001 at 02:58:31PM -0500, Scott Burch wrote: > (If there is anything else I can do to help let me know. The system is > 5.8 Generic_108528-08 with the recommended patch cluster from July 11th. > This is an Ultra10 workstation) I also have the same problem using gcc > 2.95.3 on Solaris 8 and Solaris 2.6. You are receiving a BUS error, which means that something is not properly aligned (e.g. omething is on a "odd" 4byte boundary while it should be on a 8 byte boundary). Please understand that I don't have Solaris around, so I can only give you a wild guess. I would think, that the OpenSSL library was compiled with some "64bit-alignment flag" (or maybe for some 64bit processor), while OpenSSH was compiled without this flag. Hence the members of the structure are not properly aligned and it will later fail in the OpenSSL library. > Reading ssh-keygen ... > program terminated by signal BUS (invalid address alignment) > Current function is DSA_new_method (optimized) > 127 ret->flags=ret->meth->flags; > (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) > where > =>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in > "dsa_lib.c" At this point a member of a structure is accessed. malloc() always tends to return data aligned for the worst case, so it only fails within a structure, which is not properly aligned. In any case: if the alignement (and hence the position) of members in a structure is wrong, the program must fail anyway, as the routines accessing the members will pick up wrong data. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From matthew at debian.org Wed Jul 25 23:55:30 2001 From: matthew at debian.org (Matthew Vernon) Date: 25 Jul 2001 14:55:30 +0100 Subject: [patch] document location of identity files In-Reply-To: 's message of Sun, 22 Jul 2001 18:32:02 GMT References: <15194.49717.785113.579999@ming.empire.pick.ucam.org> Message-ID: <5bsnflkt9p.fsf@chiark.greenend.org.uk> writes: > > > Why? It's id_rsa and id_dsa for Protocol v2 keys.. Duh. Too long reading the BTS :( I'll produce a correct patch in the near future. Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From somar at tiny.net Thu Jul 26 01:01:05 2001 From: somar at tiny.net (Scott Burch) Date: Wed, 25 Jul 2001 10:01:05 -0500 Subject: Debugging ssh-keygen dsa on Solaris8 Message-ID: <3B5EDF31.A393AC9F@tiny.net> Lutz, Responding to some of your statements: 1) Both openssl 0.9.6b and openssh 2.9p2 were compiled by myself on Solaris 8 as 32 bit binaries, I did not compile them for 64 bit. (The exact same compiler and compiler flags were used...the only extra flag I used was -g so I could use dbx). 2) If I use 0.9.5a of openssl I do not have any of these problems with the exact same compiler and options. (This is why I think some code change is causing this problem. 3) I can't get this work on any of our machines, however we do use custom jumpstart for all of our systems....and maybe something in our jumpstart image is causing this problem. I may have to build a new jumpstart image from scratch from the April 2001 Solaris 8 release and see if that makes a difference. This also happens on our 2.6 machines (which are also built from jumpstart). Lukas Ruf reported similar problems. He has a better situation than me, however....he says compiles work fine on every system except one...in my case I can't get the DSA stuff to work on any of the machines I am working with unless I use openssl 0.9.5a. Unless anyone else has any other ideas..I will try a new jumpstart image and see if that makes a difference. I would ultimately like to figure out what in Solaris is causing this not too work....it's starting to seem like some patch on our systems is causing the problem, but I'm at a loss as to what it might be...the system I am building on has all the recommended patches from July 11th and is based on the January 2001 Solaris 8 release. -Scott On Tue, Jul 24, 2001 at 02:58:31PM -0500, Scott Burch wrote: > (If there is anything else I can do to help let me know. The system is > 5.8 Generic_108528-08 with the recommended patch cluster from July 11th. > This is an Ultra10 workstation) I also have the same problem using gcc > 2.95.3 on Solaris 8 and Solaris 2.6. You are receiving a BUS error, which means that something is not properly aligned (e.g. omething is on a "odd" 4byte boundary while it should be on a 8 byte boundary). Please understand that I don't have Solaris around, so I can only give you a wild guess. I would think, that the OpenSSL library was compiled with some "64bit-alignment flag" (or maybe for some 64bit processor), while OpenSSH was compiled without this flag. Hence the members of the structure are not properly aligned and it will later fail in the OpenSSL library. > Reading ssh-keygen ... > program terminated by signal BUS (invalid address alignment) > Current function is DSA_new_method (optimized) > 127 ret->flags=ret->meth->flags; > (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) > where > =>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in > "dsa_lib.c" At this point a member of a structure is accessed. malloc() always tends to return data aligned for the worst case, so it only fails within a structure, which is not properly aligned. In any case: if the alignement (and hence the position) of members in a structure is wrong, the program must fail anyway, as the routines accessing the members will pick up wrong data. Best regards, Lutz From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jul 26 01:38:26 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 25 Jul 2001 17:38:26 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <3B5EDF31.A393AC9F@tiny.net>; from somar@tiny.net on Wed, Jul 25, 2001 at 10:01:05AM -0500 References: <3B5EDF31.A393AC9F@tiny.net> Message-ID: <20010725173826.A915@ws01.aet.tu-cottbus.de> On Wed, Jul 25, 2001 at 10:01:05AM -0500, Scott Burch wrote: > 2) If I use 0.9.5a of openssl I do not have any of these problems with > the exact same compiler and options. (This is why I think some code > change is causing this problem. I do not see any significant code changes in the dsa-code between 0.9.5a and 0.9.6b... Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from static DSA_METHOD *default_DSA_method; to static DSA_METHOD *default_DSA_method = NULL; (Actually, if this helps it means that the bug was already in 0.9.5a but it was not triggered for some reason. The initialization of things may be compiler and optimization dependant anyway.) Hmm. Strange. But there is also another report I had about strange problems generating DSA keys with ssh-keygen under Solaris... Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From appro at fy.chalmers.se Thu Jul 26 03:04:51 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Wed, 25 Jul 2001 19:04:51 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> Message-ID: <3B5EFC33.35F936F@fy.chalmers.se> > > 2) If I use 0.9.5a of openssl I do not have any of these problems with > > the exact same compiler and options. (This is why I think some code > > change is causing this problem. > > I do not see any significant code changes in the dsa-code between > 0.9.5a and 0.9.6b... > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > static DSA_METHOD *default_DSA_method; > to > static DSA_METHOD *default_DSA_method = NULL; Oh come on... 'static's are zeroed at startup. But Lutz is right about default_DSA_method being the prime suspect for being unaligned. I would suggest to setup watchpoint on default_DSA_method and see who's modifying it. If you can't do it yourself make executable available for download. Andy. From eds at reric.net Thu Jul 26 05:19:46 2001 From: eds at reric.net (Eric Seppanen) Date: Wed, 25 Jul 2001 14:19:46 -0500 Subject: OpenSSH 2.9p2+Kerberos5 on RH7.1 fails In-Reply-To: <20010724173233.A27541@thud.reric.net>; from eds@reric.net on Tue, Jul 24, 2001 at 05:32:33PM -0500 References: <20010724173233.A27541@thud.reric.net> Message-ID: <20010725141946.A32290@thud.reric.net> Problem solved. Cause: time skew. Kerberos doesn't work when the two machines' clocks are off by more than some number (5?) of minutes. The "kadmin" program can tell when this has happened. When I tried to run "kadmin" from the broken machine, it said: "kadmin: Clock skew too great in KDC reply while initializing kadmin interface" Neither ssh nor sshd gives any clue what the problem is... I wonder if it would be possible to detect and report this error on either end? Somehow I doubt I'll be the last person to forget to make sure ntpd is running after a reboot. Eric On Tue, Jul 24, 2001 at 05:32:33PM -0500, Eric Seppanen wrote: > I've been installing OpenSSH 2.9p2 onto several RedHat Linux machines, > after compiling in the GSSAPI/Kerberos5 patch from here: > http://www.sxw.org.uk/computing/patches/openssh.html > > I've been using ssh both to let users in via passwords and Kerberos > tickets, and both have been working fine... > > except for one irritating machine, which (for no good reason I can see) > fails when using kerberos tickets. (it works fine when using > passwords.) This is a Red Hat 7.1 machine, and the failure is: > (the user sees:) > [eds at ike eds]$ ssh hulk > Connection closed by 208.24.105.2 > > (the server log reads:) > Jul 24 16:37:41 hulk sshd[25687]: fatal: gss_accept_context died > > (if I run sshd -d I see:) > Connection from 208.24.105.19 port 2847 > debug1: Client protocol version 2.0; client software version > OpenSSH_2.9p2 > debug1: match: OpenSSH_2.9p2 pat ^OpenSSH > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.9p2 > debug1: Rhosts Authentication disabled, originating port not trusted. > 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: Wait SSH2_MSG_GSSAPI_INIT > debug1: Miscellaneous failure > debug1: Unknown code z 0 > debug1: Got no client credentials > gss_accept_context died > debug1: Calling cleanup 0x8068fe0(0x0) > > > I've built source and binary RPMS. Anyone interested can find them at > http://www.reric.net/linux/openssh/ > > Anyone have any ideas what's wrong? > > Eric From somar at tiny.net Thu Jul 26 08:09:14 2001 From: somar at tiny.net (Scott Burch) Date: Wed, 25 Jul 2001 17:09:14 -0500 Subject: Debugging ssh-keygen dsa on Solaris8 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> <3B5EFC33.35F936F@fy.chalmers.se> Message-ID: <3B5F438A.31DEE829@tiny.net> Andy Polyakov wrote: > > > > 2) If I use 0.9.5a of openssl I do not have any of these problems with > > > the exact same compiler and options. (This is why I think some code > > > change is causing this problem. > > > > I do not see any significant code changes in the dsa-code between > > 0.9.5a and 0.9.6b... > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > static DSA_METHOD *default_DSA_method; > > to > > static DSA_METHOD *default_DSA_method = NULL; > > Oh come on... 'static's are zeroed at startup. But Lutz is right about > default_DSA_method being the prime suspect for being unaligned. I would > suggest to setup watchpoint on default_DSA_method and see who's > modifying it. If you can't do it yourself make executable available for > download. > > Andy. I have some good news to report: 1) Doing the following worked: Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > static DSA_METHOD *default_DSA_method; > > to > > static DSA_METHOD *default_DSA_method = NULL; I compiled with -g -xarch=v8 for both openssl 0.9.6b and openssh 2.9p2 with Sun Forte Developer Update 2 and everything worked (with the above change)! I will be testing -xarch=v9 and 64 bit compilation to see if that works as well. In any case thanks for the suggestions. I still have to test the applications, but I will report back on that soon. Just to be sure I used a clean source tree and tried to compile with the above options and DSA was broken. If you need anything else from me at this point let me know. I have already started to build a clean jumpstart image to test with...what I would like to ultimately determine is why some people have been able to compile things without going through all this trouble...I'd hate to see everyone else go through all this testing, hopefully I can help prevent that. Thanks again, Scott From yozo at imit.chiba-u.ac.jp Thu Jul 26 18:25:37 2001 From: yozo at imit.chiba-u.ac.jp (Yozo TODA) Date: Thu, 26 Jul 2001 17:25:37 +0900 Subject: openssh.COM or openssh.ORG? Message-ID: <200107260825.f6Q8Pcj09575@aohakobe.imit.chiba-u.ac.jp> now both www.openssh.com and www.openssh.org are pointing to the same location. but domain holders (and NS records) of OPENSSH.COM and OPENSSH.ORG are different. which is the current situation? (1) both domains are controlled by OPENSSH developer team. use any you like. (2) openssh.COM is the official domain name for OPENSSH. openssh.org happens to point to the openssh.com now. (3) openssh.org will be the official domain name for OPENSSH. openssh.com will be "secondary" domain name for OPENSSH. and I wish someone put description around this domain name issues to the history or FAQ page... -- yozo. From Markus.Friedl at informatik.uni-erlangen.de Thu Jul 26 18:36:09 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Thu, 26 Jul 2001 10:36:09 +0200 Subject: openssh.COM or openssh.ORG? In-Reply-To: <200107260825.f6Q8Pcj09575@aohakobe.imit.chiba-u.ac.jp>; from yozo@imit.chiba-u.ac.jp on Thu, Jul 26, 2001 at 05:25:37PM +0900 References: <200107260825.f6Q8Pcj09575@aohakobe.imit.chiba-u.ac.jp> Message-ID: <20010726103609.C20279@faui02.informatik.uni-erlangen.de> for now: > (2) openssh.COM is the official domain name for OPENSSH. > openssh.org happens to point to the openssh.com now. From mark.reardon at irl.xerox.com Thu Jul 26 18:44:32 2001 From: mark.reardon at irl.xerox.com (Mark Reardon) Date: Thu, 26 Jul 2001 09:44:32 +0100 Subject: possible bug: OpenSSH appears to freeze on exit Message-ID: <3B5FD870.FDB150F0@irl.xerox.com> Hello, I believe I may have discovered what appears to be a small anomoly in the way OpenSSH closes connections and thought if I gave you some feedback I might be able to make a very small contributution to the development of openssh. This might be a Solaris 2.6 anomoly or an openssh anomoly or a combination of both. I came across this apparent anomoly because we use openssh (via cron) here to check on our many Solaris boxes for archive logs filling up so we can kick off an archive log backup on the machine if needs be. It was noticed after a few days that cron began to behave strangely on the box that was ssh'ing out to all the servers. This was because cron had too many outstanding processes to kick off any more ( we would literally be doing hundreds of cron'd ssh tasks every hour ). It appears that openssh sometimes has trouble closing connections on Solaris. To try and get as much detail as possible I set up a simple job that continually ssh'd into a box and executed a command until it finally froze. It took literally hours for it to happen, but eventually it did. I also hacked around with the sshd code in a effort to be able to run sshd continually in debug mode to try and pick up any information there but this yielded no more clues to what the problem might be ( apart from pointing back to ssh closing connections on the Solaris client). Included below is the tail of the debug log on the client. last successful connection and then the freeze... If I can provide any more information I will be glad to help. Best Regards, Mark Reardon PS Many thanks for an excellent piece of software. + ssh -v -v -v xcalibur ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data //.ssh/config debug1: Applying options for * debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to xcalibur [13.219.48.22] port 22. debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: Connection established. debug1: identity file //.ssh/identity type 0 debug3: No RSA1 key file //.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file //.ssh/id_dsa type 2 debug1: identity file //.ssh/id_rsa1 type -1 debug1: identity file //.ssh/id_rsa2 type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH 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 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: 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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 127/256 debug1: bits set: 1019/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 195 debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 195 debug1: Host 'xcalibur' is known and matches the RSA host key. debug1: Found key in //.ssh/known_hosts2:195 debug1: bits set: 1017/2049 debug1: ssh_rsa_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 debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try pubkey: //.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 10ae98 hint 1 debug2: input_userauth_pk_ok: fp b2:48:f6:61:cd:b8:d0:b5:58:85:95:be:7e:20:68:a8 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: sig size 20 20 debug1: ssh-userauth2 successful: method publickey debug1: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug1: Sending command: ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 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: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read debug2: channel 0: no data after CLOSE debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: channel 0: send close debug1: channel 0: is dead debug1: channel_free: channel 0: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) debug1: channel_free: channel 0: dettaching channel user 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 0 debug1: compress outgoing: raw data 1198, compressed 667, factor 0.56 debug1: compress incoming: raw data 592, compressed 580, factor 0.98 + ssh -v -v -v xcalibur ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data //.ssh/config debug1: Applying options for * debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to xcalibur [13.219.48.22] port 22. debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: Connection established. debug1: identity file //.ssh/identity type 0 debug3: No RSA1 key file //.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file //.ssh/id_dsa type 2 debug1: identity file //.ssh/id_rsa1 type -1 debug1: identity file //.ssh/id_rsa2 type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH 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 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: 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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 134/256 debug1: bits set: 1009/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 195 debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 195 debug1: Host 'xcalibur' is known and matches the RSA host key. debug1: Found key in //.ssh/known_hosts2:195 debug1: bits set: 1039/2049 debug1: ssh_rsa_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 debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try pubkey: //.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 10ae98 hint 1 debug2: input_userauth_pk_ok: fp b2:48:f6:61:cd:b8:d0:b5:58:85:95:be:7e:20:68:a8 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: sig size 20 20 debug1: ssh-userauth2 successful: method publickey debug1: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug1: Sending command: ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write freeze happens here...( I have run this test lots of times and it always freezes at exactly the same spot - when it eventually does freeze ) On the server we are ssh'ing from ( next morninng there are a few freezes overnight but not all are on host xcalibur ) > # ps -ef | grep ssh | grep -v sshd > root 6202 6201 0 06:30:29 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xnnprd00/arch > root 21855 21854 0 01:00:20 ? 0:00 ssh xcalibur du -sk /oracle/u01/admin/xdnprd00/arch > root 21904 21903 0 16:45:41 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xvkprd00/arch > root 27654 27653 0 01:15:38 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xunprd00/arch > root 6857 6856 0 17:45:09 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xanprd00/arch > root 25886 25885 0 15:00:40 ? 0:00 ssh xcalibur du -sk /oracle/u01/admin/xvkprd00/arch > root 22924 22923 0 14:45:27 ? 0:00 ssh xcalibur du -sk /oracle/u01/admin/xitprd00/arch > root 6335 6334 0 09:19:33 ? 0:00 /usr/local/bin/ssh -x -oFallBackToRsh no -C -4 monet scp -p -f /etc/hosts.allow > root 25047 25026 0 08:20:56 pts/16 0:00 grep ssh > root 22533 22393 0 08:13:13 pts/6 0:00 ssh middleware > root 10348 10347 0 05:45:07 ? 0:00 ssh xesapbw df -k | grep saparch > root 17284 17283 0 14:27:59 ? 0:00 ssh xcalibur du -sk /oracle/u01/admin/xunprd00/arch > root 3007 3006 0 15:30:20 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xdnprd00/arch > root 9024 8592 0 18:00:46 ? 0:00 ssh xesapdb1 grep '^tmproot' /etc/shadow | grep -v '*LK*' > root 26020 2746 0 17:03:19 pts/17 0:00 ssh -v -v -v xcalibur ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc > root 13526 13525 0 06:00:22 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xenprd00/arch > root 12757 12673 0 14:24:03 pts/2 0:01 ssh solar-2 > root 28679 28678 0 17:15:40 ? 0:00 ssh xcalibur df -k /oracle/u01/admin/xvkprd00/arch > root 20119 40 0 07:55:18 pts/22 0:00 ssh devsrv1 > root 13956 13955 0 02:00:03 ? 0:00 ssh -v -v -v devsrv1 df -k | grep saparch From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jul 26 19:12:42 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 26 Jul 2001 11:12:42 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <3B5F438A.31DEE829@tiny.net>; from somar@tiny.net on Wed, Jul 25, 2001 at 05:09:14PM -0500 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> <3B5EFC33.35F936F@fy.chalmers.se> <3B5F438A.31DEE829@tiny.net> Message-ID: <20010726111241.A5176@ws01.aet.tu-cottbus.de> On Wed, Jul 25, 2001 at 05:09:14PM -0500, Scott Burch wrote: > I have some good news to report: > > 1) Doing the following worked: > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > > static DSA_METHOD *default_DSA_method; > > > to > > > static DSA_METHOD *default_DSA_method = NULL; Ok. I have checked in this change to the OpenSSL repository, so that it will be fixed in the next release. Up to then it is a point for the FAQ or KNOWN_BUGS section... As it seems to me, there is no workaround OpenSSH could perform. ... > change)! I will be testing -xarch=v9 and 64 bit compilation to see if > that works as well. In any case thanks for the suggestions. I still have > to test the applications, but I will report back on that soon. Just to ... Please report about your results, so that we can be sure the problem won't pop up again. Best regards, Lutz PS. As Andy already pointed out, the behaviour shown violates the C standard. A static variable should automatically be defined to 0. Still, it seems, it is not. I don't have Solaris around to find out more details myself. But it would probably be worth finding out what is going on "behind the scenes" as other software might be affected as well. -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From appro at fy.chalmers.se Thu Jul 26 20:32:13 2001 From: appro at fy.chalmers.se (Andy Polyakov) Date: Thu, 26 Jul 2001 12:32:13 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> <3B5EFC33.35F936F@fy.chalmers.se> <3B5F438A.31DEE829@tiny.net> <20010726111241.A5176@ws01.aet.tu-cottbus.de> Message-ID: <3B5FF1AD.2801EA66@fy.chalmers.se> > > I have some good news to report: > > > > 1) Doing the following worked: > > > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > > > static DSA_METHOD *default_DSA_method; > > > > to > > > > static DSA_METHOD *default_DSA_method = NULL; > > Ok. I have checked in this change to the OpenSSL repository, so that it > will be fixed in the next release. Up to then it is a point for the > FAQ or KNOWN_BUGS section... There is one thing that is definitely different between 0.9.5 and 0.9.6. 0.9.6 is unconditionally compiled with -[Kf]PIC flag, i.e. regardless whether or not you intend to produce shared libraries(*). In general it shouldn't be a problem, it is perfectly possible to statically link PIC objects (it's even possible to link none-PIC objects into .so libraries(**)). The fact that we see contradicting report ("nothing works", "everything works", "works everywhere but one workstation") must be an indication of a bug in the way PICs are handled which was eventually fixed (at least there is linker patch #109147-09, updated a month ago, covering ld.so). One of course may wonder why does explicit initialization make the the problem go away? Well, it should be noted that explicit initialization effectively moves the variable from .bss to .data* segment. Now if buggy ld.so does better job on .data segment(s) than on .bss segment (at least those parts "belonging" to statically linked PICs), then... I wonder if Lukas ( who had that only machine failing to generate DSA key-pair) could run 'showrev -p | grep 109147' on that machine and others and compare output? What output does Scott get? (*) given the output from dbx posted earlier, Scott didn't produce .so libraries (Scott! Don't!:-) (**) yes, it is possible to put none-PICs into .so. Run-time linker shall fix-up all the unresolved references at the cost of making all the pages containing none-PIC private (kind of obsoletes the idea of .so) and potentially longer start-up time (because of page privatization and because there might be way more unresolved references in none-PIC object than in PIC). Andy. From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Jul 26 21:19:08 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 26 Jul 2001 13:19:08 +0200 Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <20010726111241.A5176@ws01.aet.tu-cottbus.de>; from jaenicke@ws01.aet.tu-cottbus.de on Thu, Jul 26, 2001 at 11:12:42AM +0200 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> <3B5EFC33.35F936F@fy.chalmers.se> <3B5F438A.31DEE829@tiny.net> <20010726111241.A5176@ws01.aet.tu-cottbus.de> Message-ID: <20010726131908.A20116@serv01.aet.tu-cottbus.de> On Thu, Jul 26, 2001 at 11:12:42AM +0200, Lutz Jaenicke wrote: > On Wed, Jul 25, 2001 at 05:09:14PM -0500, Scott Burch wrote: > Ok. I have checked in this change to the OpenSSL repository, so that it > will be fixed in the next release. Up to then it is a point for the > FAQ or KNOWN_BUGS section... > As it seems to me, there is no workaround OpenSSH could perform. As Andy Polyakov just pointed out to me in private email: There is a workaround: call DSA_set_default_method(NULL) before calling DSA_new() for the first time. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From mark.reardon at irl.xerox.com Thu Jul 26 22:08:24 2001 From: mark.reardon at irl.xerox.com (Mark Reardon) Date: Thu, 26 Jul 2001 13:08:24 +0100 Subject: possible bug: OpenSSH appears to freeze on exit References: <3B5FD870.FDB150F0@irl.xerox.com> <20010726111243.A26463@faui02.informatik.uni-erlangen.de> Message-ID: <3B600838.6E7FDF33@irl.xerox.com> Hi Markus, Thanks for getting back. I didn't think of attaching the script till after the mail. The grep should run remotely. I will change my test scripts to use the -n option and let you know... :-( I just kicked it off went back to typing my mail - then checked the script before I hit send and it had already frozen...It was working for about 5 minutes. while $1 do RUN_STATUS=`ssh -v -v -v -n xcalibur "ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l"` echo $RUN_STATUS sleep 7 done ...previous 5 minutes it was working.... RUN_STATUS= 1 + sleep 7 + ssh -v -v -v -n xcalibur ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data //.ssh/config debug1: Applying options for * debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Applying options for * debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to xcalibur [13.219.48.22] port 22. debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: Connection established. debug1: identity file //.ssh/identity type 0 debug3: No RSA1 key file //.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file //.ssh/id_dsa type 2 debug1: identity file //.ssh/id_rsa1 type -1 debug1: identity file //.ssh/id_rsa2 type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH 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 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: zlib debug2: kex_parse_kexinit: 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-dss,ssh-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 zlib debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 zlib debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 134/256 debug1: bits set: 1038/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 195 debug3: check_host_in_hostfile: filename //.ssh/known_hosts2 debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 195 debug1: Host 'xcalibur' is known and matches the RSA host key. debug1: Found key in //.ssh/known_hosts2:195 debug1: bits set: 1031/2049 debug1: ssh_rsa_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 debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,password,keyboard-interactive debug3: authmethod_lookup publickey debug3: remaining preferred: password,keyboard-interactive debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try pubkey: //.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 10ae98 hint 1 debug2: input_userauth_pk_ok: fp b2:48:f6:61:cd:b8:d0:b5:58:85:95:be:7e:20:68:a8 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: sig size 20 20 debug1: ssh-userauth2 successful: method publickey debug1: fd 5 setting O_NONBLOCK debug1: fd 6 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug1: Sending command: ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write ...freeze happens here Markus Friedl wrote: > > On Thu, Jul 26, 2001 at 09:44:32AM +0100, Mark Reardon wrote: > > ssh -v -v -v xcalibur ps -ef | egrep '(arc0|arch)'_xitprd00 | grep -v grep | wc -l > > should 'grep' run local or remote > > does '-n' help for ssh? e.g. > ssh -n host ps |grep bla > > -m From wolfgang at pi3.informatik.uni-mannheim.de Thu Jul 26 23:26:37 2001 From: wolfgang at pi3.informatik.uni-mannheim.de (Wolfgang Leideck) Date: Thu, 26 Jul 2001 15:26:37 +0200 Subject: Problems during building openssh-2.9p2 on solaris2.8 Message-ID: <20010726152637.E12768@scavenger.informatik.uni-mannheim.de> Hello. I have downloaded openssh-2.9p2 for solaris2.8. During compilation i got following errors: (cd openbsd-compat; make) make[1]: Entering directory `/home/wolfgang/openssh-2.9p2/openbsd-compat' gcc -g -O2 -Wall -I. -I.. -I. -I./.. -I/opt/Pkg/SunOS/include -I/usr/local/include -DHAVE_CONFIG_H -c bsd-arc4random.c In file included from ../config.h:748, from ../includes.h:22, from bsd-arc4random.c:25: ./defines.h:148: #error "8 bit int type not found." ./defines.h:156: #error "16 bit int type not found." ./defines.h:165: #error "32 bit int type not found." ./defines.h:181: #error "8 bit int type not found." ./defines.h:189: #error "16 bit int type not found." ./defines.h:198: #error "32 bit int type not found." In file included from ../openbsd-compat/openbsd-compat.h:35, from ../includes.h:102, from bsd-arc4random.c:25: ./openbsd-compat/bsd-waitpid.h:40: warning: `WEXITSTATUS' redefined /usr/include/sys/wait.h:78: warning: this is the location of the previous definition ./openbsd-compat/bsd-waitpid.h:41: warning: `WTERMSIG' redefined /usr/include/sys/wait.h:79: warning: this is the location of the previous definition ./openbsd-compat/bsd-waitpid.h:43: warning: `WCOREDUMP' redefined /usr/include/sys/wait.h:69: warning: this is the location of the previous definition In file included from ../openbsd-compat/openbsd-compat.h:40, from ../includes.h:102, from bsd-arc4random.c:25: ./openbsd-compat/fake-socket.h:10: warning: `_SS_MAXSIZE' redefined /usr/include/sys/socket.h:212: warning: this is the location of the previous definition make[1]: *** [bsd-arc4random.o] Error 1 make[1]: Leaving directory `/home/wolfgang/openssh-2.9p2/openbsd-compat' make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 The configuration options are: Host: sparc-sun-solaris2.8 Compiler: gcc Compiler flags: -g -O2 -Wall Preprocessor flags: -I/opt/Pkg/SunOS/include -I/usr/local/include Linker flags: -R/opt/Pkg/SunOS/lib -L/opt/Pkg/SunOS/lib -L/usr/local/lib -R/usr/local/lib Libraries: -lz -lsocket -lnsl -lgen -lcrypto Wolfgang -- Wolfgang Leideck * University of Mannheim * Dep. PI III D7,27 * Raum 409 * D 68161 Mannheim Fon: +49 621 181 2583 * Fax: +49 621 181 2588 Email: wolfgang at pi3.informatik.uni-mannheim.de From jones at tacc.utexes.edu Thu Jul 26 23:45:02 2001 From: jones at tacc.utexes.edu (William L. Jones) Date: Thu, 26 Jul 2001 08:45:02 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 Message-ID: This patch fixes my botched attempted to patch deattack.c. I created a bsd-cray.h file and cleaned up a few error cases in bsd-cray.c. Fixed cray_setup call to pass uid and login name in session.c and moved its call so that its called with root privs. Its been tested on a irix, sun, aix, unicos(SV1) and unicosmk(T3E) systems. If you are building this on a T3E you may have to edit the Makefile and edit out "-lrpc -lyp -lrpc". There a patch for sco that incorrectly assume that you have a yp library if you have a rpc library. I will submit a generic fix to this list latter since it is generic problem. I decided to go into a little more detail about the patches to each module: channels.c - Use a new subroutine from packet.c to get a singed integer. The original bsd code use the fact that you can set a 32bit unsigned int to a 32 bit signed variable and recover the sign bit. CRAY ints are 64 bit so the trick can't work. configure.in - Add OSSH_PATH_ENTROPY_PROG(PROG_SAR, sar). I missed this in the last patch. It is need for the sar entry in ssh_prng_cmds.in deattack.c - Modified to not depend on u_int16_t being 16bit in size. packet.c - Add new subroutine to return an explicit signed integer. scp.c - Modified to use alarm instead of setitimer. Unicos does not support setitier. serverloop.c - Modified sigchld_handler to only reset SIGCLD if HAVE_SIGACTION is not set. This is the only case its needs to be reset, the side effect is it fixes the problem with a infinite signal loop under unicos and unicosmk. Modified waitpid to keep trying if it gets an EINTR, this can happen due to job termination signal on unicos and unicosmk. session.c - Added unicos/unicosmk job termination signal handler. Add TMPDIR envireent variable. Add code to set up a unicos/unicosmk job and system limits. sshpty.c - Unicos/unicosk pty support. In openbsd-compat directory: bindresvport.c & - Code around the fact that the address of sin_port rresvport.c. really is 64 bit aligned on a SV1. bsd-cray.c - New - cray support routines. bsd-cray.h - Cray support. -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch-20010725 Type: application/octet-stream Size: 15439 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010726/f819450f/attachment.obj From jones at mail.utexas.edu Thu Jul 26 23:57:26 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 08:57:26 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 Message-ID: This patch fixes my botched attempted to patch deattack.c. I created a bsd-cray.h file and cleaned up a few error cases in bsd-cray.c. Fixed cray_setup call to pass uid and login name in session.c and moved its call so that its called with root privs. Its been tested on a irix, sun, aix, unicos(SV1) and unicosmk(T3E) systems. If you are building this on a T3E you may have to edit the Makefile and edit out "-lrpc -lyp -lrpc". There a patch for sco that incorrectly assume that you have a yp library if you have a rpc library. I will submit a generic fix to this list latter since it is generic problem. I decided to go into a little more detail about the patches to each module: channels.c - Use a new subroutine from packet.c to get a singed integer. The original bsd code use the fact that you can set a 32bit unsigned int to a 32 bit signed variable and recover the sign bit. CRAY ints are 64 bit so the trick can't work. configure.in - Add OSSH_PATH_ENTROPY_PROG(PROG_SAR, sar). I missed this in the last patch. It is need for the sar entry in ssh_prng_cmds.in deattack.c - Modified to not depend on u_int16_t being 16bit in size. packet.c - Add new subroutine to return an explicit signed integer. scp.c - Modified to use alarm instead of setitimer. Unicos does not support setitier. serverloop.c - Modified sigchld_handler to only reset SIGCLD if HAVE_SIGACTION is not set. This is the only case its needs to be reset, the side effect is it fixes the problem with a infinite signal loop under unicos and unicosmk. Modified waitpid to keep trying if it gets an EINTR, this can happen due to job termination signal on unicos and unicosmk. session.c - Added unicos/unicosmk job termination signal handler. Add TMPDIR envireent variable. Add code to set up a unicos/unicosmk job and system limits. sshpty.c - Unicos/unicosk pty support. In openbsd-compat directory: bindresvport.c & - Code around the fact that the address of sin_port rresvport.c. really is 64 bit aligned on a SV1. bsd-cray.c - New - cray support routines. bsd-cray.h - Cray support. -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch-20010725 Type: application/octet-stream Size: 15439 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010726/0065684f/attachment.obj From jones at mail.utexas.edu Fri Jul 27 00:00:09 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 09:00:09 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 Message-ID: This patch fixes my botched attempted to patch deattack.c. I created a bsd-cray.h file and cleaned up a few error cases in bsd-cray.c. Fixed cray_setup call to pass uid and login name in session.c and moved its call so that its called with root privs. Its been tested on a irix, sun, aix, unicos(SV1) and unicosmk(T3E) systems. If you are building this on a T3E you may have to edit the Makefile and edit out "-lrpc -lyp -lrpc". There a patch for sco that incorrectly assume that you have a yp library if you have a rpc library. I will submit a generic fix to this list latter since it is generic problem. I decided to go into a little more detail about the patches to each module: channels.c - Use a new subroutine from packet.c to get a singed integer. The original bsd code use the fact that you can set a 32bit unsigned int to a 32 bit signed variable and recover the sign bit. CRAY ints are 64 bit so the trick can't work. configure.in - Add OSSH_PATH_ENTROPY_PROG(PROG_SAR, sar). I missed this in the last patch. It is need for the sar entry in ssh_prng_cmds.in deattack.c - Modified to not depend on u_int16_t being 16bit in size. packet.c - Add new subroutine to return an explicit signed integer. scp.c - Modified to use alarm instead of setitimer. Unicos does not support setitier. serverloop.c - Modified sigchld_handler to only reset SIGCLD if HAVE_SIGACTION is not set. This is the only case its needs to be reset, the side effect is it fixes the problem with a infinite signal loop under unicos and unicosmk. Modified waitpid to keep trying if it gets an EINTR, this can happen due to job termination signal on unicos and unicosmk. session.c - Added unicos/unicosmk job termination signal handler. Add TMPDIR envireent variable. Add code to set up a unicos/unicosmk job and system limits. sshpty.c - Unicos/unicosk pty support. In openbsd-compat directory: bindresvport.c & - Code around the fact that the address of sin_port rresvport.c. really is 64 bit aligned on a SV1. bsd-cray.c - New - cray support routines. bsd-cray.h - Cray support. -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch-20010725 Type: application/octet-stream Size: 15439 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010726/6fa60188/attachment.obj From jones at mail.utexas.edu Fri Jul 27 00:07:28 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 09:07:28 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 Message-ID: This patch fixes my botched attempted to patch deattack.c. I created a bsd-cray.h file and cleaned up a few error cases in bsd-cray.c. Fixed cray_setup call to pass uid and login name in session.c and moved its call so that its called with root privs. Its been tested on a irix, sun, aix, unicos(SV1) and unicosmk(T3E) systems. If you are building this on a T3E you may have to edit the Makefile and edit out "-lrpc -lyp -lrpc". There a patch for sco that incorrectly assume that you have a yp library if you have a rpc library. I will submit a generic fix to this list latter since it is generic problem. I decided to go into a little more detail about the patches to each module: channels.c - Use a new subroutine from packet.c to get a singed integer. The original bsd code use the fact that you can set a 32bit unsigned int to a 32 bit signed variable and recover the sign bit. CRAY ints are 64 bit so the trick can't work. configure.in - Add OSSH_PATH_ENTROPY_PROG(PROG_SAR, sar). I missed this in the last patch. It is need for the sar entry in ssh_prng_cmds.in deattack.c - Modified to not depend on u_int16_t being 16bit in size. packet.c - Add new subroutine to return an explicit signed integer. scp.c - Modified to use alarm instead of setitimer. Unicos does not support setitier. serverloop.c - Modified sigchld_handler to only reset SIGCLD if HAVE_SIGACTION is not set. This is the only case its needs to be reset, the side effect is it fixes the problem with a infinite signal loop under unicos and unicosmk. Modified waitpid to keep trying if it gets an EINTR, this can happen due to job termination signal on unicos and unicosmk. session.c - Added unicos/unicosmk job termination signal handler. Add TMPDIR envireent variable. Add code to set up a unicos/unicosmk job and system limits. sshpty.c - Unicos/unicosk pty support. In openbsd-compat directory: bindresvport.c & - Code around the fact that the address of sin_port rresvport.c. really is 64 bit aligned on a SV1. bsd-cray.c - New - cray support routines. -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch-20010725 Type: application/octet-stream Size: 15439 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010726/bb6bcce9/attachment.obj From jones at mail.utexas.edu Fri Jul 27 00:11:12 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 09:11:12 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 Message-ID: This patch fixes my botched attempted to patch deattack.c. I created a bsd-cray.h file and cleaned up a few error cases in bsd-cray.c. Fixed cray_setup call to pass uid and login name in session.c and moved its call so that its called with root privs. Its been tested on a irix, sun, aix, unicos(SV1) and unicosmk(T3E) systems. If you are building this on a T3E you may have to edit the Makefile and edit out "-lrpc -lyp -lrpc". There a patch for sco that incorrectly assume that you have a yp library if you have a rpc library. I will submit a generic fix to this list latter since it is generic problem. I decided to go into a little more detail about the patches to each module: channels.c - Use a new subroutine from packet.c to get a singed integer. The original bsd code use the fact that you can set a 32bit unsigned int to a 32 bit signed variable and recover the sign bit. CRAY ints are 64 bit so the trick can't work. configure.in - Add OSSH_PATH_ENTROPY_PROG(PROG_SAR, sar). I missed this in the last patch. It is need for the sar entry in ssh_prng_cmds.in deattack.c - Modified to not depend on u_int16_t being 16bit in size. packet.c - Add new subroutine to return an explicit signed integer. scp.c - Modified to use alarm instead of setitimer. Unicos does not support setitier. serverloop.c - Modified sigchld_handler to only reset SIGCLD if HAVE_SIGACTION is not set. This is the only case its needs to be reset, the side effect is it fixes the problem with a infinite signal loop under unicos and unicosmk. Modified waitpid to keep trying if it gets an EINTR, this can happen due to job termination signal on unicos and unicosmk. session.c - Added unicos/unicosmk job termination signal handler. Add TMPDIR envireent variable. Add code to set up a unicos/unicosmk job and system limits. sshpty.c - Unicos/unicosk pty support. In openbsd-compat directory: bindresvport.c & - Code around the fact that the address of sin_port rresvport.c. really is 64 bit aligned on a SV1. bsd-cray.c - New - cray support routines. -------------- next part -------------- A non-text attachment was scrubbed... Name: craypatch-20010725 Type: application/octet-stream Size: 15439 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010726/14d5bb9e/attachment.obj From jones at tacc.utexas.edu Fri Jul 27 00:19:32 2001 From: jones at tacc.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 09:19:32 -0500 Subject: Request a change in idenity! Message-ID: Could some one change my entry in the mailing list from "jones at mail.utexas.edu" to "jones at tacc.utexas.edu" We are going through a domain change. Bill Jones From mouring at etoh.eviladmin.org Fri Jul 27 01:16:09 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 26 Jul 2001 10:16:09 -0500 (CDT) Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: Message-ID: > I decided to go into a little more detail about the patches to > each module: > [..] > serverloop.c - Modified sigchld_handler to only reset > SIGCLD if HAVE_SIGACTION is not set. This is the > only case its needs to be reset, the side effect > is it fixes the problem with a infinite signal loop > under unicos and unicosmk. Hmm.. I suggest if you want to keep doing this to do #if !defined(HAVE_SIGACTION) && defined(_CRAY) because this could be valid on other platforms. mysignal drops back to signal() if sigaction() can not be found (most notiable NeXTStep). From vinschen at redhat.com Fri Jul 27 01:35:59 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 26 Jul 2001 17:35:59 +0200 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: ; from jones@mail.utexas.edu on Thu, Jul 26, 2001 at 09:07:28AM -0500 References: Message-ID: <20010726173559.I490@cygbert.vinschen.de> On Thu, Jul 26, 2001 at 09:07:28AM -0500, William L. Jones wrote: > > This patch fixes my botched attempted to patch deattack.c. > [...] I'm just curious. How often do you want to send this mail? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From jones at mail.utexas.edu Fri Jul 27 01:56:44 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 10:56:44 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: Message-ID: I made the change based on the following logic: 1) If you have HAVE_SIGACTION then the signal is handler is not reset and thier is no need to reset it in the signal handler. 2) If you don't have HAVE_SIGACTION then the signal handler may or may not be reset. So I do the save thing a reset it. Since SIGACTION is a POSIX standered I can depened on 1. Case 2 insure that this code will work the same as it always does if you don't have SIGACTION. I really want to keep as many special out of the openbsd code as I can. Bill Jones > -----Original Message----- > From: mouring at etoh.eviladmin.org [mailto:mouring at etoh.eviladmin.org] > Sent: Thursday, July 26, 2001 10:16 AM > To: William L. Jones > Cc: openssh-unix-dev at mindrot.org; jones at tacc.utexas.edu > Subject: Re: Updated Cray patch against openssh SNAP-20010725 > > > > > I decided to go into a little more detail about the patches to > > each module: > > > [..] > > serverloop.c - Modified sigchld_handler to only reset > > SIGCLD if HAVE_SIGACTION is not set. This is the > > only case its needs to be reset, the side effect > > is it fixes the problem with a infinite signal loop > > under unicos and unicosmk. > Hmm.. I suggest if you want to keep doing this to do > > #if !defined(HAVE_SIGACTION) && defined(_CRAY) because this could be > valid on other platforms. mysignal drops back to signal() if sigaction() > can not be found (most notiable NeXTStep). > From jones at mail.utexas.edu Fri Jul 27 02:19:24 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 11:19:24 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: <20010726173559.I490@cygbert.vinschen.de> Message-ID: Woops, I had a bad day today. I meant to only post it once. Since I din't have the right idenity jones at mail.utexas.edu and mail address I was expecting the mail just go down the bit bucket. Sorry for doing soooooo many post! > -----Original Message----- > From: owner-openssh-unix-dev at mindrot.org > [mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of Corinna Vinschen > Sent: Thursday, July 26, 2001 10:36 AM > To: William L. Jones > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Updated Cray patch against openssh SNAP-20010725 > > > On Thu, Jul 26, 2001 at 09:07:28AM -0500, William L. Jones wrote: > > > > This patch fixes my botched attempted to patch deattack.c. > > [...] > > I'm just curious. How often do you want to send this mail? > > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com > From stevesk at pobox.com Fri Jul 27 03:59:54 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 26 Jul 2001 10:59:54 -0700 (PDT) Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: Message-ID: On Thu, 26 Jul 2001, William L. Jones wrote: :I made the change based on the following logic: : : 1) If you have HAVE_SIGACTION then the signal is handler is not reset and : thier is no need to reset it in the signal handler. : 2) If you don't have HAVE_SIGACTION then the signal handler may or may not : be reset. So I do the save thing a reset it. : :Since SIGACTION is a POSIX standered I can depened on 1. : :Case 2 insure that this code will work the same as it always does if :you don't have SIGACTION. if you have sigaction(), mysignal() will not reset the handler if it has not changed, so no changes are required with the switch to mysignal. i just commited a change so we use mysignal() entirely for proto 1 and 2 server loops. look in misc.c for mysignal. From jones at mail.utexas.edu Fri Jul 27 04:08:40 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 13:08:40 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: Message-ID: Hmm, Your right that is what it should do! For some reason it may not be working on Crays. Let me do some more investgation. Bill Jones > -----Original Message----- > From: Kevin Steves [mailto:stevesk at pobox.com] > Sent: Thursday, July 26, 2001 1:00 PM > To: William L. Jones > Cc: mouring at etoh.eviladmin.org; William L. Jones; > openssh-unix-dev at mindrot.org; jones at tacc.utexas.edu > Subject: RE: Updated Cray patch against openssh SNAP-20010725 > > > On Thu, 26 Jul 2001, William L. Jones wrote: > :I made the change based on the following logic: > : > : 1) If you have HAVE_SIGACTION then the signal is handler is > not reset and > : thier is no need to reset it in the signal handler. > : 2) If you don't have HAVE_SIGACTION then the signal handler > may or may not > : be reset. So I do the save thing a reset it. > : > :Since SIGACTION is a POSIX standered I can depened on 1. > : > :Case 2 insure that this code will work the same as it always does if > :you don't have SIGACTION. > > if you have sigaction(), mysignal() will not reset the handler if it has > not changed, so no changes are required with the switch to mysignal. i > just commited a change so we use mysignal() entirely for proto 1 and 2 > server loops. > > look in misc.c for mysignal. > From conrad at cgl.ucsf.EDU Fri Jul 27 04:26:22 2001 From: conrad at cgl.ucsf.EDU (Conrad Huang) Date: Thu, 26 Jul 2001 11:26:22 -0700 (PDT) Subject: Tru64 Unix vs. OpenSSH 2.9p2 Message-ID: <200107261826.LAA247785@socrates.cgl.ucsf.edu> Hi, We installed OpenSSH 2.9p2 with OpenSSL 0.9.6b on our Compaq Alpha ES40 running Tru64 Unix 5.0a. We've been having problems where one of our users appears in the output of "w" and is associated with a pseudoterminal even though he has no processes attached to that pty. The problem can be reproduced by connecting to the localhost host via ssh using protocol version 2, and then killing the ssh client with a SIGKILL. The sshd server notices the connection closing and exits, but does not update /etc/utmp. I believe the problem is in server_loop2() in serverloop.c. When the ssh connection is terminated abruptly, one falls out of the input processing loop and tries to clean up. There is a loop that "wait"s for child processes to die, and terminates the associated sessions. Unfortuately, the "wait" uses the WNOHANG flag, so any session associated with a child that has not exited is just ignored. Since the logout bookkeeping code is invoked through session_close(), that means /etc/utmp is not updated. (The child process, in this case a login shell, exits after sshd dies because its standard input closes.) Below are some diffs that seem to fix the problem. Can one of the OpenSSH developers please take a look and let me know if the analysis and the fix are correct? Thanks, Conrad =================================================================== RCS file: RCS/serverloop.c,v retrieving revision 1.1 diff -c -r1.1 serverloop.c *** serverloop.c 2001/07/26 16:50:27 1.1 --- serverloop.c 2001/07/26 18:09:04 *************** *** 697,702 **** --- 697,703 ---- fd_set *readset = NULL, *writeset = NULL; int rekeying = 0, max_fd, status; pid_t pid; + int fd; debug("Entering interactive session for SSH2."); *************** *** 736,742 **** xfree(writeset); signal(SIGCHLD, SIG_DFL); ! while ((pid = waitpid(-1, &status, WNOHANG)) > 0) session_close_by_pid(pid, status); channel_stop_listening(); } --- 737,745 ---- xfree(writeset); signal(SIGCHLD, SIG_DFL); ! while ((fd = channel_find_open()) >= 0) ! channel_free(fd); ! while ((pid = waitpid(-1, &status, 0)) > 0) session_close_by_pid(pid, status); channel_stop_listening(); } From dwd at bell-labs.com Fri Jul 27 04:31:22 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 26 Jul 2001 13:31:22 -0500 Subject: Failed X11 authentication does the wrong thing In-Reply-To: <5bitgmpij9.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Sat, Jul 21, 2001 at 01:34:50PM +0100 References: <5bitgmpij9.fsf@chiark.greenend.org.uk> Message-ID: <20010726133122.B27815@lucent.com> That's a fundamental limitation of the way ssh does forwarding of X connections; it stores the authentication information in ~/.Xauthority, and doing su - both changes the value of ~ and makes it impossible for you to read the file because it has to be readable only by the owner. Old SSH did the same thing. - Dave Dykstra On Sat, Jul 21, 2001 at 01:34:50PM +0100, Matthew Vernon wrote: > Hi, > > if I do the following: > > ssh -X localhost > su - another_user > xterm > > I get: > > X connection to ming:10.0 broken (explicit kill or server shutdown). > > Where what is really wanted was something like: > > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > xterm Xt error: Can't open display: :0.0 > > 'tis easy to reproduce the bug, but the debug output that seems > relevant is: > debug1: X11 connection uses different authentication protocol. > > I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there > are more easy things to do first), so I thought I'd let you know. > > Cheers, > > Matthew > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org From gearond at oit.edu Fri Jul 27 04:40:18 2001 From: gearond at oit.edu (Dennis Gearon) Date: Thu, 26 Jul 2001 11:40:18 -0700 Subject: comment on another command line option Message-ID: <3B606412.DC8F5EDE@oit.edu> I would like ssh to have the command line option of supplying the passphrase. This would make it possible to do attendant free scp transfers from PHP, for example. As it is, it is impossible to use a web script to initiate an scp xfer if an encrypted private key is used. I realize that stupid people could make shell scripts or web scripts then with the pass phrase in them, but those same stupid people are just as likely to walk out in front of cars. The preferred method is to supply the passphrase through an ssl connected web page/script for a one time use. without the ability to do attendant free scp transfers using pass phrased private keys, the only remote to remote transfers that can be initiated by a web script is via ssl, and that costs money for a certificate that most host's will accept. schematic of intended usage. Me with SSL browser<----->My company website<------->client website to be with PHP CASE TOOL edited with PHP CASE TOOL From stevev at darkwing.uoregon.edu Fri Jul 27 04:46:19 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Thu, 26 Jul 2001 11:46:19 -0700 Subject: comment on another command line option In-Reply-To: <3B606412.DC8F5EDE@oit.edu> References: <3B606412.DC8F5EDE@oit.edu> Message-ID: <15200.25979.258705.413934@darkwing.uoregon.edu> Dennis Gearon writes: > I would like ssh to have the command line option of supplying the passphrase. > This would make it possible to do attendant free scp transfers from PHP, for > example. As it is, it is impossible to use a web script to initiate an scp xfer > if an encrypted private key is used. > > I realize that stupid people could make shell scripts or web scripts then with > the pass phrase in them, but those same stupid people are just as likely to walk > out in front of cars. The preferred method is to supply the passphrase through > an ssl connected web page/script for a one time use. > > without the ability to do attendant free scp transfers using pass phrased > private keys, the only remote to remote transfers that can be initiated by a web > script is via ssl, and that costs money for a certificate that most host's will > accept. Why not just set up ssh-agent and add your intended key with ssh-add? Then you can do password-free logins with subsequent invocations of ssh or scp. That's probably not the only way you can get what you want with the existing OpenSSH functionality. From dwd at bell-labs.com Fri Jul 27 04:49:31 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 26 Jul 2001 13:49:31 -0500 Subject: ChallengeResponseAuthentication - typos and inconsistancies? In-Reply-To: <5bhew6ph73.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Sat, Jul 21, 2001 at 02:03:44PM +0100 References: <5bhew6ph73.fsf@chiark.greenend.org.uk> Message-ID: <20010726134931.C27815@lucent.com> On Sat, Jul 21, 2001 at 02:03:44PM +0100, Matthew Vernon wrote: > Hi, > > It seems from the source code that there are a couple of quirks > with this option: > > firstly, in the code it's mis-spelt as > "challenge_reponse_authentication" As Markus said, this is fixed in the current CVS. > and secondly, the default for the client (in readconf.c) seems to be > off, whereas for the server (servconf.c) seems to be on: > readconf.c: if (options->challenge_reponse_authentication == -1) > readconf.c: options->challenge_reponse_authentication = 0; > servconf.c: if (options->challenge_reponse_authentication == -1) > servconf.c: options->challenge_reponse_authentication = 1; > Finally, the manual page says: > The default is ``no''. > > Which set of defaults should be kept? in any case, the man page should > agree with the code... The sshd man page does say the Default is yes; only the ssh client says no. It only matters if you've got authentication code configured. - Dave Dykstra From Darren.Moffat at eng.sun.com Fri Jul 27 05:00:54 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 26 Jul 2001 12:00:54 -0700 (PDT) Subject: Failed X11 authentication does the wrong thing Message-ID: <200107261902.f6QJ26S165794@jurassic.eng.sun.com> >That's a fundamental limitation of the way ssh does forwarding of X >connections; it stores the authentication information in ~/.Xauthority, I don't believe any of this has anything what so ever to do with the X11 forwarding functionality of ssh since you get exactly the same behaviour on a local login. >and doing su - both changes the value of ~ and makes it impossible for >you to read the file because it has to be readable only by the owner. Not true at all, there is no enforcement of the permissions on the .Xauthority file by xauth or anyone else that I know of and there are no restrictions mentioned in the standard X11R6.4 man page for xauth. As an example: cube$ ssh -X borg Enter passphrase for key '/home/djm/.ssh/id_rsa': Last login: Thu Jul 26 11:50:56 2001 from cube borg$ ls -l ~/.Xauthority -rw------- 1 darrenm staff 453 Jul 26 11:50 /home/darrenm/.Xauthority borg$ chmod 644 ~/.Xauthority borg$ su - Password: # XAUTHORITY=/home/djm/.Xauthority # export XAUTHORITY # DISPLAY=borg:10.0 # export DISPLAY # /usr/X/bin/xdpyinfo name of display: borg:10.0 version number: 11.0 vendor string: Sun Microsystems, In ... I can also start an X client and it will display on braveheart. Okay so this involves the user opening up the permissions on their .Xauthority file to everyone if the users home directory is NFS mounted. If it is local then root could read it anyway (at least on traditional unix filesystems). You could use ACLs to give permission only to root (tricky actually since you need to give the permission to nobody not root, and this isn't really any better than giving world read). I've also written a PAM module for use with su that uses xauth to make a copy of the cookie for the current DISPLAY out of the src users .Xauthority and put it into the destination users .Xauthority. This a safe way to do it - if I ever get the time I'll update the PAM module to remove the cookie from the .Xauthority when the session exits. > >On Sat, Jul 21, 2001 at 01:34:50PM +0100, Matthew Vernon wrote: >> Hi, >> >> if I do the following: >> >> ssh -X localhost >> su - another_user >> xterm >> >> I get: >> >> X connection to ming:10.0 broken (explicit kill or server shutdown). >> >> Where what is really wanted was something like: >> >> Xlib: connection to ":0.0" refused by server >> Xlib: Client is not authorized to connect to Server >> xterm Xt error: Can't open display: :0.0 >> >> 'tis easy to reproduce the bug, but the debug output that seems >> relevant is: >> debug1: X11 connection uses different authentication protocol. >> >> I'm not sure I want to go hacking ssh'x X11 forwarding just yet (there >> are more easy things to do first), so I thought I'd let you know. >> >> Cheers, >> >> Matthew >> >> -- >> "At least you know where you are with Microsoft." >> "True. I just wish I'd brought a paddle." >> http://www.debian.org -- Darren J Moffat From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Jul 27 05:09:19 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 26 Jul 2001 21:09:19 +0200 Subject: Tru64 Unix vs. OpenSSH 2.9p2 In-Reply-To: <200107261826.LAA247785@socrates.cgl.ucsf.edu>; from conrad@cgl.ucsf.EDU on Thu, Jul 26, 2001 at 11:26:22AM -0700 References: <200107261826.LAA247785@socrates.cgl.ucsf.edu> Message-ID: <20010726210918.B25031@serv01.aet.tu-cottbus.de> On Thu, Jul 26, 2001 at 11:26:22AM -0700, Conrad Huang wrote: > The problem can be reproduced by connecting to the localhost host > via ssh using protocol version 2, and then killing the ssh client > with a SIGKILL. The sshd server notices the connection closing and > exits, but does not update /etc/utmp. [analysis and patch deleted] A corresponding fix is already in the CVS version. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From esm at pobox.com Fri Jul 27 05:14:01 2001 From: esm at pobox.com (Ed Santiago) Date: Thu, 26 Jul 2001 13:14:01 -0600 Subject: comment on another command line option In-Reply-To: gearond's message of Thu, 26 Jul 2001 11:40:18 -0700. <3B606412.DC8F5EDE@oit.edu> Message-ID: <20010726191406.E703718A21@dsl081-105-106.den1.dsl.speakeasy.net> Dennis Gearon writes: >I would like ssh to have the command line option of supplying the passphrase. Speaking only for myself: if I were ever to see this option implemented, it would make me wonder what _other_ mind-bogglingly stupid code was in the package, and destroy any shred of confidence in openssh as a whole. Why don't you just set up a passphrase-less key? % ssh-keygen -f ~/.ssh/id_wide_open ...then copy the public part to authorized_keys* on the remote machine (and, if you're wise, set up "from=xxxx" therein). ^E -- Ed Santiago Toolsmith santiago at ascend.com From dwd at bell-labs.com Fri Jul 27 05:29:19 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 26 Jul 2001 14:29:19 -0500 Subject: Failed X11 authentication does the wrong thing In-Reply-To: <200107261902.f6QJ26S165794@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Thu, Jul 26, 2001 at 12:00:54PM -0700 References: <200107261902.f6QJ26S165794@jurassic.eng.sun.com> Message-ID: <20010726142919.A29265@lucent.com> On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: > >That's a fundamental limitation of the way ssh does forwarding of X > >connections; it stores the authentication information in ~/.Xauthority, > > I don't believe any of this has anything what so ever to do with the > X11 forwarding functionality of ssh since you get exactly the same behaviour > on a local login. That's true, if you're using xauth. > >and doing su - both changes the value of ~ and makes it impossible for > >you to read the file because it has to be readable only by the owner. > > Not true at all, there is no enforcement of the permissions on the > .Xauthority file by xauth or anyone else that I know of and there are > no restrictions mentioned in the standard X11R6.4 man page for xauth. I didn't intend to imply that it was a fundamental limitation, just that it had to be that way for security reasons. ... > Okay so this involves the user opening up the permissions on their > .Xauthority file to everyone if the users home directory is NFS mounted. Or any other user on the local system even if the user's home directory is not NFS mounted. > If it is local then root could read it anyway (at least on traditional unix > filesystems). True. I believe I've seen cases where su'ing to root (without '-') results in the original user's .Xauthority file being owned by root, which messes things up too. ... > I've also written a PAM module for use with su that uses xauth to > make a copy of the cookie for the current DISPLAY out of the src users > .Xauthority and put it into the destination users .Xauthority. This a > safe way to do it - if I ever get the time I'll update the PAM module > to remove the cookie from the .Xauthority when the session exits. Interesting, but not necessarily safe, if a group of people share the login you su to. It's too bad that the xauth magic cookie can't be in an environment variable. On the other hand, I think some systems make it easy for other people to dump out your environment variables so that would be no good either. - Dave Dykstra From Darren.Moffat at eng.sun.com Fri Jul 27 05:39:10 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 26 Jul 2001 12:39:10 -0700 (PDT) Subject: Failed X11 authentication does the wrong thing Message-ID: <200107261940.f6QJeKS174995@jurassic.eng.sun.com> >On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: >> >That's a fundamental limitation of the way ssh does forwarding of X >> >connections; it stores the authentication information in ~/.Xauthority, >> >> I don't believe any of this has anything what so ever to do with the >> X11 forwarding functionality of ssh since you get exactly the same behaviour >> on a local login. > >That's true, if you're using xauth. xauth is what OpenSSH uses so what other X authentication are you talking about that has this limitation ? >> >and doing su - both changes the value of ~ and makes it impossible for >> >you to read the file because it has to be readable only by the owner. >> >> Not true at all, there is no enforcement of the permissions on the >> .Xauthority file by xauth or anyone else that I know of and there are >> no restrictions mentioned in the standard X11R6.4 man page for xauth. > >I didn't intend to imply that it was a fundamental limitation, just that >it had to be that way for security reasons. But you used the words ;-) I think I know what you mean though. >> Okay so this involves the user opening up the permissions on their >> .Xauthority file to everyone if the users home directory is NFS mounted. > >Or any other user on the local system even if the user's home directory >is not NFS mounted. If you do the chmod yes, what ai was trying to say was that if the home directory is local then root could read it anyway so you wouldn't need to change the perms. >> If it is local then root could read it anyway (at least on traditional unix >> filesystems). > >True. I believe I've seen cases where su'ing to root (without '-') results >in the original user's .Xauthority file being owned by root, which messes >things up too. The only 3 cases I can think of how that happens is: 1. Local homedir no pre exising .Xauthority, the su action creates one 2. As above but over NFS and homedir is 0777 3. A setuid xauth - bad idea! >> I've also written a PAM module for use with su that uses xauth to >> make a copy of the cookie for the current DISPLAY out of the src users >> .Xauthority and put it into the destination users .Xauthority. This a >> safe way to do it - if I ever get the time I'll update the PAM module >> to remove the cookie from the .Xauthority when the session exits. > >Interesting, but not necessarily safe, if a group of people share the login >you su to. It's too bad that the xauth magic cookie can't be in an Which is why people should use RBAC systems rather than su to root ;-) (Actually it really needs to be RBAC plus fine grained privilege). How else do you suggest it is done ? root needs the cookie to connect so you have to give it to them some how, if other people use root and you don't trust them then don't log into that machine. I agree that it isn't idea but it is the best that can be done when using the xauth cookie mechanism. >environment variable. On the other hand, I think some systems make it easy >for other people to dump out your environment variables so that would be no >good either. /usr/ucb/ps e (Or if your are on a BSD system I guess that is /usr/bin/ps ) /usr/bin/ps on Solaris can't do that since it is no longer setuid and there is no way to access someone elses environment via proc unless you are priveleged. Even still I don't agree with putting security information into environment variable or on the command line. -- Darren J Moffat From Nicolas.Williams at ubsw.com Fri Jul 27 05:51:40 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 26 Jul 2001 15:51:40 -0400 Subject: Failed X11 authentication does the wrong thing In-Reply-To: <20010726142919.A29265@lucent.com>; from dwd@bell-labs.com on Thu, Jul 26, 2001 at 02:29:19PM -0500 References: <200107261902.f6QJ26S165794@jurassic.eng.sun.com> <20010726142919.A29265@lucent.com> Message-ID: <20010726155139.C22964@sm2p1386swk.wdr.com> On Thu, Jul 26, 2001 at 02:29:19PM -0500, Dave Dykstra wrote: > On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: > ... > > I've also written a PAM module for use with su that uses xauth to > > make a copy of the cookie for the current DISPLAY out of the src users > > .Xauthority and put it into the destination users .Xauthority. This a > > safe way to do it - if I ever get the time I'll update the PAM module > > to remove the cookie from the .Xauthority when the session exits. > > Interesting, but not necessarily safe, if a group of people share the login > you su to. It's too bad that the xauth magic cookie can't be in an > environment variable. On the other hand, I think some systems make it easy > for other people to dump out your environment variables so that would be no > good either. Ideally the X libs would support the same sort of concept as the ssh-agent but for accessing X cookies. In fact, I'd really like to see an all-purpose agent along the lines of ssh-agent, but not just for SSH keys: Kerberos ccaches, X cookies, NTLM hashes (think about Samba's smbsh/smbwrapper) and so on. > - Dave Dykstra 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 jones at mail.utexas.edu Fri Jul 27 06:16:07 2001 From: jones at mail.utexas.edu (William L. Jones) Date: Thu, 26 Jul 2001 15:16:07 -0500 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: Message-ID: The Unicos on SV1 has bug in sigaction. I work with cray to get it fixed. I like to go ahead and use mouring at etoh.eviladmin.org suggestion until then: #if !defined(HAVE_SIGACTION) && defined(_CRAY) > -----Original Message----- > From: Kevin Steves [mailto:stevesk at pobox.com] > Sent: Thursday, July 26, 2001 1:00 PM > To: William L. Jones > Cc: mouring at etoh.eviladmin.org; William L. Jones; > openssh-unix-dev at mindrot.org; jones at tacc.utexas.edu > Subject: RE: Updated Cray patch against openssh SNAP-20010725 > > > On Thu, 26 Jul 2001, William L. Jones wrote: > :I made the change based on the following logic: > : > : 1) If you have HAVE_SIGACTION then the signal is handler is > not reset and > : thier is no need to reset it in the signal handler. > : 2) If you don't have HAVE_SIGACTION then the signal handler > may or may not > : be reset. So I do the save thing a reset it. > : > :Since SIGACTION is a POSIX standered I can depened on 1. > : > :Case 2 insure that this code will work the same as it always does if > :you don't have SIGACTION. > > if you have sigaction(), mysignal() will not reset the handler if it has > not changed, so no changes are required with the switch to mysignal. i > just commited a change so we use mysignal() entirely for proto 1 and 2 > server loops. > > look in misc.c for mysignal. > From somar at tiny.net Fri Jul 27 06:46:27 2001 From: somar at tiny.net (Scott Burch) Date: Thu, 26 Jul 2001 15:46:27 -0500 Subject: Debugging ssh-keygen dsa on Solaris8 References: <3B5EDF31.A393AC9F@tiny.net> <20010725173826.A915@ws01.aet.tu-cottbus.de> <3B5EFC33.35F936F@fy.chalmers.se> <3B5F438A.31DEE829@tiny.net> <20010726111241.A5176@ws01.aet.tu-cottbus.de> <3B5FF1AD.2801EA66@fy.chalmers.se> Message-ID: <3B6081A3.C54DA62C@tiny.net> Ok, Well I didn't have time to check the ssh binary or anything yesterday, but today I did. I can run ssh, but when I try to connect to anything I get a bus error, so the > > > > > static DSA_METHOD *default_DSA_method; > > > > > to > > > > > static DSA_METHOD *default_DSA_method = NULL; allows ssh_keygen to work when doing the dsa key generation, but ssh does seem to function properly. I'll see what I can track down. If you have any other ideas let me know. I verified that I can compile with xarch=v8,v9 without any changes beyond the one above (however things don't work properly). I can not compile openssl as a 64 bit target with the latest Forte (but that's not really a concern at this time). I think it may be time to try compiling on a new box based on the April 2001 release with the latest patch cluster. I'm at a loss now as what is happening. I verified that the binaries compiled against 0.9.5a work. -Scott Andy Polyakov wrote: > > > > I have some good news to report: > > > > > > 1) Doing the following worked: > > > > > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > > > > static DSA_METHOD *default_DSA_method; > > > > > to > > > > > static DSA_METHOD *default_DSA_method = NULL; > > > > Ok. I have checked in this change to the OpenSSL repository, so that it > > will be fixed in the next release. Up to then it is a point for the > > FAQ or KNOWN_BUGS section... > > There is one thing that is definitely different between 0.9.5 and 0.9.6. > 0.9.6 is unconditionally compiled with -[Kf]PIC flag, i.e. regardless > whether or not you intend to produce shared libraries(*). In general it > shouldn't be a problem, it is perfectly possible to statically link PIC > objects (it's even possible to link none-PIC objects into .so > libraries(**)). The fact that we see contradicting report ("nothing > works", "everything works", "works everywhere but one workstation") must > be an indication of a bug in the way PICs are handled which was > eventually fixed (at least there is linker patch #109147-09, updated a > month ago, covering ld.so). One of course may wonder why does explicit > initialization make the the problem go away? Well, it should be noted > that explicit initialization effectively moves the variable from .bss to > .data* segment. Now if buggy ld.so does better job on .data segment(s) > than on .bss segment (at least those parts "belonging" to statically > linked PICs), then... > > I wonder if Lukas ( who had that only machine > failing to generate DSA key-pair) could run 'showrev -p | grep 109147' > on that machine and others and compare output? What output does Scott > get? > > (*) given the output from dbx posted earlier, Scott didn't produce .so > libraries (Scott! Don't!:-) > > (**) yes, it is possible to put none-PICs into .so. Run-time linker > shall fix-up all the unresolved references at the cost of making all the > pages containing none-PIC private (kind of obsoletes the idea of .so) > and potentially longer start-up time (because of page privatization and > because there might be way more unresolved references in none-PIC object > than in PIC). > > Andy. From rachit at ensim.com Fri Jul 27 07:12:32 2001 From: rachit at ensim.com (Rachit Siamwalla) Date: Thu, 26 Jul 2001 14:12:32 -0700 Subject: comment on another command line option Message-ID: <9AC41B8C4781464695BB013F106FCA3102900AD7@nasdaq.ms.ensim.com> very dangerous. ps auxww | grep ssh will tell you why programs generally do not allow passwords to be put via the commandline. -rchit -----Original Message----- From: Dennis Gearon [mailto:gearond at oit.edu] Sent: Thursday, July 26, 2001 11:40 AM To: openssh-unix-dev at mindrot.org Subject: comment on another command line option I would like ssh to have the command line option of supplying the passphrase. This would make it possible to do attendant free scp transfers from PHP, for example. As it is, it is impossible to use a web script to initiate an scp xfer if an encrypted private key is used. I realize that stupid people could make shell scripts or web scripts then with the pass phrase in them, but those same stupid people are just as likely to walk out in front of cars. The preferred method is to supply the passphrase through an ssl connected web page/script for a one time use. without the ability to do attendant free scp transfers using pass phrased private keys, the only remote to remote transfers that can be initiated by a web script is via ssl, and that costs money for a certificate that most host's will accept. schematic of intended usage. Me with SSL browser<----->My company website<------->client website to be with PHP CASE TOOL edited with PHP CASE TOOL From wichert at wiggy.net Fri Jul 27 10:56:29 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri, 27 Jul 2001 02:56:29 +0200 Subject: comment on another command line option In-Reply-To: <20010726191406.E703718A21@dsl081-105-106.den1.dsl.speakeasy.net> References: <20010726191406.E703718A21@dsl081-105-106.den1.dsl.speakeasy.net> Message-ID: <20010727025629.C23713@wiggy.net> Previously Ed Santiago wrote: > Speaking only for myself: if I were ever to see this option > implemented, it would make me wonder what _other_ mind-bogglingly > stupid code was in the package, and destroy any shred of > confidence in openssh as a whole. A good alternative option is to do that gpg already does and have an option to specify a fd on which a passphrase is passed in. Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert at cistron.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From Darren.Moffat at eng.sun.com Fri Jul 27 11:04:31 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 26 Jul 2001 18:04:31 -0700 (PDT) Subject: comment on another command line option Message-ID: <200107270105.f6R15gS273195@jurassic.eng.sun.com> >Previously Ed Santiago wrote: >> Speaking only for myself: if I were ever to see this option >> implemented, it would make me wonder what _other_ mind-bogglingly >> stupid code was in the package, and destroy any shred of >> confidence in openssh as a whole. > >A good alternative option is to do that gpg already does and have an >option to specify a fd on which a passphrase is passed in. OpenSSH has another alternative, SSH_ASKPASS. -- Darren J Moffat From anonaka at miraclelinux.com Fri Jul 27 11:04:50 2001 From: anonaka at miraclelinux.com (NONAKA Akira) Date: Fri, 27 Jul 2001 10:04:50 +0900 Subject: openssl version check in entropy.c References: <03ce01c11598$b28d46e0$a300010a@mshome.net> <20010726094716.E28123@faui02.informatik.uni-erlangen.de> Message-ID: <01f701c11638$233a7da0$a300010a@mshome.net> ----- Original Message ----- From: "Markus Friedl" To: "NONAKA Akira" Cc: Sent: Thursday, July 26, 2001 4:47 PM Subject: Re: openssl version check in entropy.c > On Thu, Jul 26, 2001 at 03:03:31PM +0900, NONAKA Akira wrote: > > OpenSSH checks OpenSSL version in entropy.c. Do we still need this? IMHO, > > OpenSSL is stable enough and I do not think this is necessary any more. > > history shows that it's a problem. I see. If that is the case, why not static link libcrypto.so? -- NONAKA Akira Miraclelinux Tokyo, Japan From joden at eworld.wox.org Fri Jul 27 10:54:43 2001 From: joden at eworld.wox.org (James Oden) Date: Thu, 26 Jul 2001 20:54:43 -0400 (EDT) Subject: comment on another command line option In-Reply-To: <20010727025629.C23713@wiggy.net> from "Wichert Akkerman" at Jul 27, 2001 02:56:29 AM Message-ID: <200107270054.UAA28203@eworld.wox.org> > > A good alternative option is to do that gpg already does and have an > option to specify a fd on which a passphrase is passed in. > Yes, or perhaps even having it just come from stdin. Onetime I was working on a program that various things at an elevated privledge for a web application. I set it up to take its arguments via standard input. In this particular case I choose to format the input simular to CGI-BIN parameters, mainly because that was where my head was, but the main point is I could easily start up the program in perl with a write pipe, and pass the parameters without them showing up in the process table....james From tim at multitalents.net Fri Jul 27 13:02:03 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 26 Jul 2001 20:02:03 -0700 (PDT) Subject: Debugging ssh-keygen dsa on Solaris8 In-Reply-To: <3B5EDF31.A393AC9F@tiny.net> Message-ID: On Wed, 25 Jul 2001, Scott Burch wrote: [snip] > our systems is causing the problem, but I'm at a loss as to what it > might be...the system I am building on has all the recommended patches > from July 11th and is based on the January 2001 Solaris 8 release. In trying to duplicate the problem in my Solaris box I remembered my patch cluster was not the July 11th version so I went to sunsove.sun.com and found there was a newer one. ... # CLUSTER_README NAME: Solaris 8 Recommended Patch Cluster DATE: Jul/24/01 ... I don't know if it has anything that will fix your problem but it's worth looking at. ssh-keygen works fine here on Solaris 8 > > -Scott > > On Tue, Jul 24, 2001 at 02:58:31PM -0500, Scott Burch wrote: > > (If there is anything else I can do to help let me know. The system is > > 5.8 Generic_108528-08 with the recommended patch cluster from July 11th. > > This is an Ultra10 workstation) I also have the same problem using gcc > > 2.95.3 on Solaris 8 and Solaris 2.6. > > You are receiving a BUS error, which means that something is not > properly > aligned (e.g. omething is on a "odd" 4byte boundary while it should be > on a > 8 byte boundary). > Please understand that I don't have Solaris around, so I can only give > you a wild guess. I would think, that the OpenSSL library was compiled > with some "64bit-alignment flag" (or maybe for some 64bit processor), > while > OpenSSH was compiled without this flag. Hence the members of the > structure > are not properly aligned and it will later fail in the OpenSSL library. > > > Reading ssh-keygen > ... > > program terminated by signal BUS (invalid address alignment) > > Current function is DSA_new_method (optimized) > > 127 ret->flags=ret->meth->flags; > > (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) > > where > > =>[1] DSA_new_method(meth = ???) (optimized), at 0x4b6b8 (line ~127) in > > "dsa_lib.c" > > At this point a member of a structure is accessed. malloc() always tends > to return data aligned for the worst case, so it only fails within > a structure, which is not properly aligned. > > In any case: if the alignement (and hence the position) of members in > a structure is wrong, the program must fail anyway, as the routines > accessing the members will pick up wrong data. > > Best regards, > Lutz > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at mcgarry.ch Fri Jul 27 18:21:36 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Fri, 27 Jul 2001 10:21:36 +0200 Subject: OpenSSH-RSAAuth-NFS Message-ID: <002a01c11675$284e7660$0602a8c0@mcgarry.ch> Here's a bunch of changes I've made to the current portable version of OpenSSH. The aim is that the rsa_authentication flag in sshd_config can be given the values "without-nfs" This is really handy within a large organization where incorrectly secured home directories can allow authorized_keys(2) to be modified by someone other than the owner. So now rsa_authentication can take the values (no,without-nfs,yes). Maybe it would be better to use (no,yes,with-nfs). So it's an active decision that the user has to make if the wish to allow authorized_keys(2) from nfs mounts. I'd like to feed this enhancement back into the OpenBSD build, NFS security is not just a problem that relates to Solaris. Tim McGarry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-rsa-nfs.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010727/2a00f1c0/attachment.txt From a_ghsek at yahoo.co.in Fri Jul 27 17:20:31 2001 From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=) Date: Fri, 27 Jul 2001 08:20:31 +0100 (BST) Subject: openssh-2.9p2 compilation on LynxOS Message-ID: <20010727072031.5641.qmail@web8005.mail.in.yahoo.com> To whoever can help me, I tried to compile OpenSSH-2.9p2 on i386-LynxOS. I made a # ./configure --without-pam --without-shadow \ --with-ssl-dir=/usr/local/ssl --with-pcre \ --disable-libutil --sysconfdir=/etc/ssh Then, # make gave the following error: gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o reonf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -lssh -lopenbsompat -lz -lpcreposix -lpcre -lcrypto collect2: ld returned 1 exit status sshconnect.o: In function `ssh_connect': /openssh/openssh-2.9p2/sshconnect.c(207): undefined reference to `getservbynareadconf.o: In function `parse_token': /openssh/openssh-2.9p2/readconf.c(235): undefined reference to `strcasecmp' ./libssh.a(log.o): In function `log_facility_number': /openssh/openssh-2.9p2/log.c(97): undefined reference to `strcasecmp' ./libssh.a(log.o): In function `log_level_number': /openssh/openssh-2.9p2/log.c(108): undefined reference to `strcasecmp' ./libssh.a(log.o): In function `do_log': /openssh/openssh-2.9p2/log.c(383): undefined reference to `openlog' /openssh/openssh-2.9p2/log.c(384): undefined reference to `syslog' /openssh/openssh-2.9p2/log.c(385): undefined reference to `closelog' ./libssh.a(cipher.o): In function `cipher_by_name': /openssh/openssh-2.9p2/cipher.c(440): undefined reference to `strcasecmp' ./libssh.a(packet.o): In function `packet_read': /openssh/openssh-2.9p2/packet.c(692): undefined reference to `howmany' /openssh/openssh-2.9p2/packet.c(717): undefined reference to `howmany' ./libssh.a(packet.o): In function `packet_write_wait': /openssh/openssh-2.9p2/packet.c(1216): undefined reference to `howmany' /openssh/openssh-2.9p2/packet.c(1220): undefined reference to `howmany' ./libssh.a(channels.o): In function `channel_prepare_select': /openssh/openssh-2.9p2/channels.c(1171): undefined reference to `howmany' ./libssh.a(canohost.o): In function `check_ip_options': /openssh/openssh-2.9p2/canohost.c(152): undefined reference to `getprotobynamopenbsd-compat//libopenbsd-compat.a(fake-getaddrinfo.o): In function `getaddri': /openssh/openssh-2.9p2/openbsd-compat/fake-getaddrinfo.c(99): undefined refere to `gethostbyname' openbsd-compat//libopenbsd-compat.a(fake-getnameinfo.o): In function `getnamei': /openssh/openssh-2.9p2/openbsd-compat/fake-getnameinfo.c(41): undefined refere to `gethostbyaddr' collect2: ld returned 1 exit statusat/fake-getnameinfo.c(41): undefined refer make: *** [ssh] Error 1 The errors pertaining to gethostbyaddr, openlog, syslog and other buit-in functions are removed, if I add the following option: # ./configure --with-cflags -I/usr/include But, the error: "undefined reference to howmany" persists. ** I could not find the definition of howmany() in the openssh directory. Could anyone hellp me out. Thanks for any help, A.Gnana Hari Sekar ____________________________________________________________ Do You Yahoo!? For regular News updates go to http://in.news.yahoo.com From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Jul 27 20:21:25 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Fri, 27 Jul 2001 12:21:25 +0200 Subject: 2.9p?: connection hangs with agent forwarding In-Reply-To: <20010704154233.A16767@faui02.informatik.uni-erlangen.de>; from Markus.Friedl@informatik.uni-erlangen.de on Wed, Jul 04, 2001 at 03:42:33PM +0200 References: <20010703174609.A24341@serv01.aet.tu-cottbus.de> <20010704152054.A6874@ws01.aet.tu-cottbus.de> <20010704154233.A16767@faui02.informatik.uni-erlangen.de> Message-ID: <20010727122125.A10116@ws01.aet.tu-cottbus.de> On Wed, Jul 04, 2001 at 03:42:33PM +0200, Markus Friedl wrote: > On Wed, Jul 04, 2001 at 03:20:55PM +0200, Lutz Jaenicke wrote: > > On the other hand, if sshd would react on the complete close of its local > > agent connection and would itself initiate the bi-directional shutdown > > (the accessing process actually has closed both sides), the problem would > > also not appear. > > some time ago i recevied a patch that tried to do this: > > mark a 'forwarded channel' as special if it's a agent connection. > force a close for the send-half if the received half is closed > > however, the patch modified the protocol (this was not acceptiple). > > are you talking about a shutdown of a socket or of a 'forwarded' > channel? [For your information: since this message there was a private email exchange between Markus Friedl and myself about this issue.] Attached you will find a patch, that should solve the problem of hanging connections because of sockets not being correctly closed after forwarded ssh-agent or X11 connections. It actually handles a similar problem as the USE_PIPES switch. In the version attached it only handles the UNIX sockets on the client side, so the protocol on the wire is untouched. (There are two locations in it with a "force_drain=0" that is a no-op but I left it in as it was discussed during test between Markus and me. It will probably be removed if being applied.) This patch solves the problem on HP-UX 10.20 and I would ask people on other platforms affected by this problem to also test it and report back, so that the patch can be applied to the main release. (Patch is against CVS version) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 -------------- next part -------------- diff -r -u newsoft/openssh_cvs/channels.c n2/openssh/channels.c --- newsoft/openssh_cvs/channels.c Thu Jul 19 18:03:32 2001 +++ n2/openssh/channels.c Wed Jul 25 18:09:44 2001 @@ -260,6 +260,7 @@ c->cb_fn = NULL; c->cb_arg = NULL; c->cb_event = 0; + c->force_drain = 0; c->detach_user = NULL; c->input_filter = NULL; debug("channel %d: new [%s]", found, remote_name); @@ -1031,6 +1032,7 @@ xfree(remote_ipaddr); return; } + nc->force_drain = 0; if (compat20) { packet_start(SSH2_MSG_CHANNEL_OPEN); packet_put_cstring("x11"); @@ -1185,6 +1187,7 @@ xfree(name); close(newsock); } + nc->force_drain = 0; if (compat20) { packet_start(SSH2_MSG_CHANNEL_OPEN); packet_put_cstring("auth-agent at openssh.com"); @@ -1781,6 +1784,13 @@ if (c == NULL) packet_disconnect("Received ieof for nonexistent channel %d.", id); chan_rcvd_ieof(c); + + /* XXX force input close */ + if (c->force_drain) { + debug2("channel %d: XXX FORCE input drain", c->self); + c->istate = CHAN_INPUT_WAIT_DRAIN; + } + } void @@ -2669,6 +2679,7 @@ close(sock); } else { c->remote_id = remote_id; + c->force_drain = 1; } } if (c == NULL) { @@ -2931,6 +2942,7 @@ close(sock); } else { c->remote_id = remote_id; + c->force_drain = 1; } } if (c == NULL) { diff -r -u newsoft/openssh_cvs/channels.h n2/openssh/channels.h --- newsoft/openssh_cvs/channels.h Thu Jul 19 18:03:33 2001 +++ n2/openssh/channels.h Thu Jul 19 18:31:56 2001 @@ -77,6 +77,7 @@ int efd; /* extended fd */ int sock; /* sock fd */ int isatty; /* rfd is a tty */ + int force_drain; /* force close on iEOF */ Buffer input; /* data read from socket, to be sent over * encrypted connection */ Buffer output; /* data received over encrypted connection for diff -r -u newsoft/openssh_cvs/clientloop.c n2/openssh/clientloop.c --- newsoft/openssh_cvs/clientloop.c Thu Jul 19 18:03:33 2001 +++ n2/openssh/clientloop.c Thu Jul 19 19:24:27 2001 @@ -1111,6 +1111,7 @@ error("client_request_x11: channel_new failed"); close(sock); } + c->force_drain = 1; return c; } @@ -1136,6 +1137,7 @@ error("client_request_agent: channel_new failed"); close(sock); } + c->force_drain = 1; return c; } From Darren.Moffat at eng.sun.com Sat Jul 28 02:27:17 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Fri, 27 Jul 2001 09:27:17 -0700 (PDT) Subject: OpenSSH-RSAAuth-NFS Message-ID: <200107271628.f6RGSSS435390@jurassic.eng.sun.com> >I'd like to feed this enhancement back into the OpenBSD build, NFS security >is not just a problem that relates to Solaris. NFS on Solaris is secure, please don't propgate the myth that NFS is not secure - especially on Solaris. Since SunOS 4.x days NFS could be secured by using Secure RPC which uses public keys and diffie helman exchange for authentication. Since Solaris 2.6 (+ the free unbundled SEAM) you can secure NFS using Kerberos since NFS uses RPCSEC_GSS. Kerberos can be used for authentication, integrity and encrypting the data. NFSv4 has Kerberos (and SPKM/LIPKEY) as mandatory so any vendor claiming that they have NFSv4 is required to have strong security for NFS. Now that I've had my rant there are some issues with the patch. 1. I don't believe this works if NFS is used with cachefs since the file system won't show up as nfs but cachefs. 2. It assumes that all other remote filesystems are ok. 3. It assumes that NFS isn't secure - it maybe. -- Darren J Moffat From wayned at users.sourceforge.net Sat Jul 28 04:18:13 2001 From: wayned at users.sourceforge.net (Wayne Davison) Date: Fri, 27 Jul 2001 11:18:13 -0700 (PDT) Subject: Updated ssh-keyscan patch for ssh2 support Message-ID: In the past 2 months another change occurred in the CVS code that broke my ssh-keyscan patch. Here's an updated version that tweaks the changed name (in the Kex struct) and also causes an attempt to grab an ssh2 key from an older server (without ssh2 support) to fail earlier and without an error message (Stuart Pearlman emailed me some code for this). This patch is based on the BSD CVS source, but should also apply to the portable CVS codebase with just some offsets and a bit of fuzz. If there are any issues remaining that keep this from going into CVS, please let me know. ..wayne.. -------------- next part -------------- Index: ssh-keyscan.1 --- ssh-keyscan.1 2001/06/23 17:48:18 1.8 +++ ssh-keyscan.1 2001/07/27 17:56:05 @@ -14,14 +14,20 @@ .Nd gather ssh public keys .Sh SYNOPSIS .Nm ssh-keyscan -.Op Fl t Ar timeout -.Op Ar -- | host | addrlist namelist -.Op Fl f Ar files ... +.Op Fl v46 +.Op Fl T Ar timeout +.Op Fl t Ar type +.Op Fl - +.Op Ar host | addrlist namelist +.Op Fl f Ar files +.Op Ar ... .Sh DESCRIPTION .Nm is a utility for gathering the public ssh host keys of a number of hosts. It was designed to aid in building and verifying .Pa ssh_known_hosts +and +.Pa ssh_known_hosts2 files. .Nm provides a minimal interface suitable for use by shell and perl @@ -46,14 +52,43 @@ have begun after you created your ssh_known_hosts file. .Sh OPTIONS .Bl -tag -width Ds -.It Fl t +.It Fl v +Verbose mode. +Causes +.Nm +to print debugging messages about its progress. +.It Fl 4 +Forces +.Nm +to use IPv4 addresses only. +.It Fl 6 +Forces +.Nm +to use IPv6 addresses only. +.It Fl T Set the timeout for connection attempts. If .Pa timeout seconds have elapsed since a connection was initiated to a host or since the last time anything was read from that host, then the connection is closed and the host in question considered unavailable. Default is 5 seconds. -.It Fl f +.It Fl t Ar type +Specifies the type of the key to fetch from the following hosts. +The possible values are +.Dq rsa1 +for protocol version 1 and +.Dq rsa +or +.Dq dsa +for protocol version 2. +Multiple values may be specified by separating them with commas. +The default is +.Dq rsa1 . +Specifying the +.Pa -t +option again later on the line will change the value for the hostnames that +follow, allowing you to get different key-types from different hosts. +.It Fl f Ar filename Read hosts or .Pa addrlist namelist pairs from this file, one per line. @@ -64,33 +99,59 @@ will read hosts or .Pa addrlist namelist pairs from the standard input. +It is legal to specify multiple +.Pa -f +options and to intermingle them with literal hostnames in any order. .El .Sh EXAMPLES -Print the host key for machine -.Pa hostname : +.Pp +Print the +.Pa rsa1 +host key for machine +.Pa host1 +and the +.Pa dsa +host key for machine +.Pa host2 : .Bd -literal -ssh-keyscan hostname +ssh-keyscan host1 -t dsa host2 .Ed .Pp Find all hosts from the file .Pa ssh_hosts which have new or different keys from those in the sorted file -.Pa ssh_known_hosts : +.Pa ssh_known_hosts2 : .Bd -literal -$ ssh-keyscan -f ssh_hosts | sort -u - ssh_known_hosts | \e\ - diff ssh_known_hosts - +$ ssh-keyscan -t rsa,dsa -f ssh_hosts | \e\ + sort -u - ssh_known_hosts2 | diff ssh_known_hosts2 - .Ed .Sh FILES .Pa Input format: +.Bd -literal 1.2.3.4,1.2.4.4 name.my.domain,name,n.my.domain,n,1.2.3.4,1.2.4.4 +.Ed .Pp -.Pa Output format: +.Pa Output format for rsa1 keys: +.Bd -literal host-or-namelist bits exponent modulus +.Ed +.Pp +.Pa Output format for rsa and dsa keys: +.Bd -literal +host-or-namelist keytype base64-encoded-key +.Ed +.Pp +Where +.Pa keytype +is either +.Dq ssh-rsa +or +.Dq ssh-dsa . .Pp .Pa /etc/ssh_known_hosts .Sh BUGS It generates "Connection closed by remote host" messages on the consoles -of all the machines it scans. +of all the machines it scans if the server is older than version 2.9. This is because it opens a connection to the ssh port, reads the public key, and drops the connection as soon as it gets the key. .Sh SEE ALSO @@ -98,3 +159,6 @@ .Xr sshd 8 .Sh AUTHORS David Mazieres +wrote the initial version, and +Wayne Davison +added support for ssh protocol 2. Index: ssh-keyscan.c --- ssh-keyscan.c 2001/06/23 15:12:20 1.24 +++ ssh-keyscan.c 2001/07/27 17:56:05 @@ -14,10 +14,16 @@ #include +#include #include "xmalloc.h" #include "ssh.h" #include "ssh1.h" #include "key.h" +#include "kex.h" +#include "compat.h" +#include "myproposal.h" +#include "packet.h" +#include "dispatch.h" #include "buffer.h" #include "bufaux.h" #include "log.h" @@ -25,8 +31,20 @@ static int argno = 1; /* Number of argument currently being parsed */ -int family = AF_UNSPEC; /* IPv4, IPv6 or both */ +/* Flag indicating whether IPv4 or IPv6. This can be set on the command line. + Default value is AF_UNSPEC means both IPv4 and IPv6. */ +#ifdef IPV4_DEFAULT +int IPv4or6 = AF_INET; +#else +int IPv4or6 = AF_UNSPEC; +#endif + +#define KT_RSA1 1 +#define KT_DSA 2 +#define KT_RSA 4 +int get_keytypes = KT_RSA1; /* Get only RSA1 keys by default */ + #define MAXMAXFD 256 /* The number of seconds after which to give up on a TCP connection */ @@ -39,6 +57,8 @@ fd_set *read_wait; size_t read_wait_size; int ncon; +int nonfatal_fatal = 0; +jmp_buf kexjmp; /* * Keep a connection structure for each file descriptor. The state @@ -54,11 +74,13 @@ int c_plen; /* Packet length field for ssh packet */ int c_len; /* Total bytes which must be read. */ int c_off; /* Length of data read so far. */ + int c_keytype; /* Only one of KT_RSA1, KT_DSA, or KT_RSA */ char *c_namebase; /* Address to free for c_name and c_namelist */ char *c_name; /* Hostname of connection for errors */ char *c_namelist; /* Pointer to other possible addresses */ char *c_output_name; /* Hostname of connection for output */ char *c_data; /* Data read from this fd */ + Kex *c_kex; /* The key-exchange struct for ssh2 */ struct timeval c_tv; /* Time at which connection gets aborted */ TAILQ_ENTRY(Connection) c_link; /* List of connections in timeout order. */ } con; @@ -242,8 +264,8 @@ return (tok); } -static void -keyprint(char *host, char *output_name, char *kd, int len) +static Key * +keygrab_ssh1(con *c) { static Key *rsa; static Buffer msg; @@ -252,12 +274,12 @@ buffer_init(&msg); rsa = key_new(KEY_RSA1); } - buffer_append(&msg, kd, len); - buffer_consume(&msg, 8 - (len & 7)); /* padding */ + buffer_append(&msg, c->c_data, c->c_plen); + buffer_consume(&msg, 8 - (c->c_plen & 7)); /* padding */ if (buffer_get_char(&msg) != (int) SSH_SMSG_PUBLIC_KEY) { - error("%s: invalid packet type", host); + error("%s: invalid packet type", c->c_name); buffer_clear(&msg); - return; + return NULL; } buffer_consume(&msg, 8); /* cookie */ @@ -270,10 +292,70 @@ (void) buffer_get_int(&msg); buffer_get_bignum(&msg, rsa->rsa->e); buffer_get_bignum(&msg, rsa->rsa->n); + buffer_clear(&msg); + + return (rsa); +} + +static int +hostjump(Key *hostkey) +{ + longjmp(kexjmp, (int)hostkey); +} + +int +ssh2_capable(int remote_major, int remote_minor) +{ + switch (remote_major) { + case 1: + if (remote_minor == 99) + return 1; + break; + case 2: + return 1; + default: + break; + } + return 0; +} + +static Key * +keygrab_ssh2(con *c) +{ + int j; + + packet_set_connection(c->c_fd, c->c_fd); + enable_compat20(); + myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = c->c_keytype == KT_DSA? + "ssh-dss": "ssh-rsa"; + c->c_kex = kex_setup(myproposal); + c->c_kex->verify_host_key = hostjump; + + if (!(j = setjmp(kexjmp))) { + nonfatal_fatal = 1; + dispatch_run(DISPATCH_BLOCK, &c->c_kex->done, c->c_kex); + fprintf(stderr, "Impossible! dispatch_run() returned!\n"); + exit(1); + } + nonfatal_fatal = 0; + xfree(c->c_kex); + c->c_kex = NULL; + packet_close(); + if (j < 0) + j = 0; - fprintf(stdout, "%s ", output_name ? output_name : host); - key_write(rsa, stdout); + return (Key*)(j); +} + +static void +keyprint(con *c, Key *key) +{ + if (!key) + return; + + fprintf(stdout, "%s ", c->c_output_name ? c->c_output_name : c->c_name); + key_write(key, stdout); fputs("\n", stdout); } @@ -286,7 +368,7 @@ snprintf(strport, sizeof strport, "%d", SSH_DEFAULT_PORT); memset(&hints, 0, sizeof(hints)); - hints.ai_family = family; + hints.ai_family = IPv4or6; hints.ai_socktype = SOCK_STREAM; if ((gaierr = getaddrinfo(host, strport, &hints, &aitop)) != 0) fatal("getaddrinfo %s: %s", host, gai_strerror(gaierr)); @@ -311,7 +393,7 @@ } static int -conalloc(char *iname, char *oname) +conalloc(char *iname, char *oname, int keytype) { int s; char *namebase, *name, *namelist; @@ -340,6 +422,7 @@ fdcon[s].c_data = (char *) &fdcon[s].c_plen; fdcon[s].c_len = 4; fdcon[s].c_off = 0; + fdcon[s].c_keytype = keytype; gettimeofday(&fdcon[s].c_tv, NULL); fdcon[s].c_tv.tv_sec += timeout; TAILQ_INSERT_TAIL(&tq, &fdcon[s], c_link); @@ -359,6 +442,7 @@ if (fdcon[s].c_status == CS_KEYS) xfree(fdcon[s].c_data); fdcon[s].c_status = CS_UNUSED; + fdcon[s].c_keytype = 0; TAILQ_REMOVE(&tq, &fdcon[s], c_link); FD_CLR(s, read_wait); ncon--; @@ -378,21 +462,16 @@ { int ret; con *c = &fdcon[s]; - char *iname, *oname; - iname = xstrdup(c->c_namelist); - oname = xstrdup(c->c_output_name); + ret = conalloc(c->c_namelist, c->c_output_name, c->c_keytype); confree(s); - ret = conalloc(iname, oname); - xfree(iname); - xfree(oname); return (ret); } static void congreet(int s) { - char buf[80], *cp; + char buf[256], *cp; size_t bufsiz; int n = 0; con *c = &fdcon[s]; @@ -414,12 +493,34 @@ } *cp = '\0'; fprintf(stderr, "# %s %s\n", c->c_name, buf); - n = snprintf(buf, sizeof buf, "SSH-1.5-OpenSSH-keyscan\r\n"); + if (c->c_keytype != KT_RSA1) { + int remote_major, remote_minor; + char remote_version[sizeof buf]; + + if (sscanf(buf, "SSH-%d.%d-%[^\n]\n", + &remote_major, &remote_minor, remote_version) == 3) + compat_datafellows(remote_version); + else + datafellows = 0; + if (!ssh2_capable(remote_major, remote_minor)) { + debug("%s doesn't support ssh2", c->c_name); + confree(s); + return; + } + } + 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); if (atomicio(write, s, buf, n) != n) { error("write (%s): %s", c->c_name, strerror(errno)); confree(s); return; } + if (c->c_keytype != KT_RSA1) { + keyprint(c, keygrab_ssh2(c)); + confree(s); + return; + } c->c_status = CS_SIZE; contouch(s); } @@ -452,7 +553,7 @@ c->c_status = CS_KEYS; break; case CS_KEYS: - keyprint(c->c_name, c->c_output_name, c->c_data, c->c_plen); + keyprint(c, keygrab_ssh1(c)); confree(s); return; break; @@ -520,49 +621,99 @@ nexthost(int argc, char **argv) { static Linebuf *lb; + char *fname, *tname; for (;;) { - if (!lb) { - if (argno >= argc) - return (NULL); - if (argv[argno][0] != '-') - return (argv[argno++]); - if (!strcmp(argv[argno], "--")) { + if (lb) { + char *line; + + line = Linebuf_getline(lb); + if (line) + return (line); + Linebuf_free(lb); + lb = NULL; + } + if (argno >= argc) + return (NULL); + if (argv[argno][0] != '-') + return (argv[argno++]); + while (*++(argv[argno])) { + switch (argv[argno][0]) { + case '-': if (++argno >= argc) return (NULL); return (argv[argno++]); - } else if (!strncmp(argv[argno], "-f", 2)) { - char *fname; - - if (argv[argno][2]) - fname = &argv[argno++][2]; + case 'f': + if (argv[argno][1]) + fname = &argv[argno][1]; else if (++argno >= argc) { error("missing filename for `-f'"); return (NULL); } else - fname = argv[argno++]; + fname = argv[argno]; if (!strcmp(fname, "-")) fname = NULL; lb = Linebuf_alloc(fname, error); - } else + goto double_break; + case 't': + get_keytypes = 0; + tname = &argv[argno][1]; + if (!*tname) { + if (++argno >= argc) { + error("missing types for `-t'"); + return (NULL); + } + tname = argv[argno]; + } + tname = strtok(tname, ","); + while (tname) { + int type = key_type_from_name(tname); + switch (type) { + case KEY_RSA1: + get_keytypes |= KT_RSA1; + break; + case KEY_DSA: + get_keytypes |= KT_DSA; + break; + case KEY_RSA: + get_keytypes |= KT_RSA; + break; + case KEY_UNSPEC: + fatal("unknown key type %s\n", + tname); + } + tname = strtok(NULL, ","); + } + goto double_break; + case '4': + IPv4or6 = AF_INET; + break; + case '6': + IPv4or6 = AF_INET6; + break; + default: error("ignoring invalid/misplaced option `%s'", - argv[argno++]); - } else { - char *line; - - line = Linebuf_getline(lb); - if (line) - return (line); - Linebuf_free(lb); - lb = NULL; + argv[argno]); + goto double_break; + } } +double_break: + argno++; } } static void +fatal_callback(void *arg) +{ + if (nonfatal_fatal) + longjmp(kexjmp, -1); +} + +static void usage(void) { - fatal("usage: %s [-t timeout] { [--] host | -f file } ...", __progname); + fatal("usage: %s [-v46] [-T timeout] { [-t type] [--] host | -f file } ...", + __progname); return; } @@ -570,27 +721,53 @@ main(int argc, char **argv) { char *host = NULL; + int debug_flag = 0, log_level = SYSLOG_LEVEL_INFO; TAILQ_INIT(&tq); if (argc <= argno) usage(); - if (argv[1][0] == '-' && argv[1][1] == 't') { - argno++; - if (argv[1][2]) - timeout = atoi(&argv[1][2]); - else { - if (argno >= argc) - usage(); - timeout = atoi(argv[argno++]); + while (argv[argno][0] == '-') { + while (*++(argv[argno])) { + switch (argv[argno][0]) { + case 'T': + if (argv[argno][1]) + timeout = atoi(&argv[argno][1]); + else { + if (++argno >= argc) + usage(); + timeout = atoi(argv[argno]); + } + if (timeout <= 0) + usage(); + goto double_break; + case 'v': + if (!debug_flag) { + debug_flag = 1; + log_level = SYSLOG_LEVEL_DEBUG1; + } + else if (log_level < SYSLOG_LEVEL_DEBUG3) + log_level++; + else + fatal("Too high debugging level."); + break; + default: + if (*--(argv[argno]) != '-') + fatal("Please separate options T and v from any other options."); + goto triple_break; + } } - if (timeout <= 0) - usage(); +double_break: + argno++; } +triple_break: if (argc <= argno) usage(); + log_init("ssh-keyscan", log_level, SYSLOG_FACILITY_USER, 1); + fatal_add_cleanup(fatal_callback, NULL); + maxfd = fdlim_get(1); if (maxfd < 0) fatal("%s: fdlim_get: bad value", __progname); @@ -603,6 +780,9 @@ fdcon = xmalloc(maxfd * sizeof(con)); memset(fdcon, 0, maxfd * sizeof(con)); + init_rng(); + seed_rng(); + read_wait_size = howmany(maxfd, NFDBITS) * sizeof(fd_mask); read_wait = xmalloc(read_wait_size); memset(read_wait, 0, read_wait_size); @@ -610,12 +790,16 @@ do { while (ncon < MAXCON) { char *name; + int j; host = nexthost(argc, argv); if (host == NULL) break; name = strnnsep(&host, " \t\n"); - conalloc(name, *host ? host : name); + for (j = KT_RSA1; j <= KT_RSA; j *= 2) { + if (get_keytypes & j) + conalloc(name, *host ? host : name, j); + } } conloop(); } while (host); From dwd at bell-labs.com Sat Jul 28 04:35:58 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 27 Jul 2001 13:35:58 -0500 Subject: Failed X11 authentication does the wrong thing In-Reply-To: <200107261940.f6QJeKS174995@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Thu, Jul 26, 2001 at 12:39:10PM -0700 References: <200107261940.f6QJeKS174995@jurassic.eng.sun.com> Message-ID: <20010727133558.A22318@lucent.com> On Thu, Jul 26, 2001 at 12:39:10PM -0700, Darren Moffat wrote: > >On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: > >> >That's a fundamental limitation of the way ssh does forwarding of X > >> >connections; it stores the authentication information in ~/.Xauthority, > >> > >> I don't believe any of this has anything what so ever to do with the > >> X11 forwarding functionality of ssh since you get exactly the same behaviour > >> on a local login. > > > >That's true, if you're using xauth. > > xauth is what OpenSSH uses so what other X authentication are you talking > about that has this limitation ? It seems that we keep missing each other's meanings in this email communication media. I meant to say that any X access using xauth, including what OpenSSH does for X forwarding, has the limitation. If you're using plain old xhost authentication (abhorrent though it is) you don't have the same problem. My original statement did not intend to imply that I could think of some better way for OpenSSH to do X authentication, I was just trying to explain to the original questioner that the symptom he was talking about could not be easily solved. ... > >> I've also written a PAM module for use with su that uses xauth to > >> make a copy of the cookie for the current DISPLAY out of the src users > >> .Xauthority and put it into the destination users .Xauthority. This a > >> safe way to do it - if I ever get the time I'll update the PAM module > >> to remove the cookie from the .Xauthority when the session exits. > > > >Interesting, but not necessarily safe, if a group of people share the login > >you su to. It's too bad that the xauth magic cookie can't be in an > > Which is why people should use RBAC systems rather than su to root ;-) > (Actually it really needs to be RBAC plus fine grained privilege). Forgive my ignorance, but what's RBAC? I guess "something something Access Control". > How else do you suggest it is done ? root needs the cookie to connect > so you have to give it to them some how, if other people use root and you > don't trust them then don't log into that machine. Ah, I was thinking mainly of su'ing to other shared user ids, not root. That was our disconnect, and may explain all the confusion that we've had in this discussion. Does your PAM module only copy the cookies when su-ing to root? If you're su-ing to root anyway, perhaps all you need to do is set $XAUTHORITY to point to the original user's $HOME/.Xauthority. Oh, I see, when you're going over NFS, access by the root user id is usually disallowed. Was that the main purpose for your PAM module? > I agree that it isn't idea but it is the best that can be done when using > the xauth cookie mechanism. It is indeed very limiting. On Thu, Jul 26, 2001 at 03:51:40PM -0400, Nicolas Williams wrote: > On Thu, Jul 26, 2001 at 02:29:19PM -0500, Dave Dykstra wrote: > > On Thu, Jul 26, 2001 at 12:00:54PM -0700, Darren Moffat wrote: > > ... > > > I've also written a PAM module for use with su that uses xauth to > > > make a copy of the cookie for the current DISPLAY out of the src users > > > .Xauthority and put it into the destination users .Xauthority. This a > > > safe way to do it - if I ever get the time I'll update the PAM module > > > to remove the cookie from the .Xauthority when the session exits. > > > > Interesting, but not necessarily safe, if a group of people share the login > > you su to. It's too bad that the xauth magic cookie can't be in an > > environment variable. On the other hand, I think some systems make it easy > > for other people to dump out your environment variables so that would be no > > good either. > > Ideally the X libs would support the same sort of concept as the > ssh-agent but for accessing X cookies. > > In fact, I'd really like to see an all-purpose agent along the lines of > ssh-agent, but not just for SSH keys: Kerberos ccaches, X cookies, NTLM > hashes (think about Samba's smbsh/smbwrapper) and so on. But ssh-agent suffers essentially the same problem when su-ing to other user ids: the inherited environment variable only points to a unix-domain socket that's accessible only by the original user and root. I was trying to think of a way of passing the authentication through when you su to another user. - Dave Dykstra From Darren.Moffat at eng.sun.com Sat Jul 28 05:04:01 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Fri, 27 Jul 2001 12:04:01 -0700 (PDT) Subject: Failed X11 authentication does the wrong thing Message-ID: <200107271905.f6RJ5DS487976@jurassic.eng.sun.com> >I meant to say that any X access using xauth, including what OpenSSH does >for X forwarding, has the limitation. If you're using plain old xhost >authentication (abhorrent though it is) you don't have the same problem. Agreed. >> Which is why people should use RBAC systems rather than su to root ;-) >> (Actually it really needs to be RBAC plus fine grained privilege). > >Forgive my ignorance, but what's RBAC? I guess "something something Access >Control". Sorry, Role Based Access Control. sudo is kind of a form of RBAC. >in this discussion. Does your PAM module only copy the cookies when su-ing >to root? Yep. >If you're su-ing to root anyway, perhaps all you need to do is set >$XAUTHORITY to point to the original user's $HOME/.Xauthority. Oh, I see, >when you're going over NFS, access by the root user id is usually >disallowed. Was that the main purpose for your PAM module? Exactly. (The case I wrote it for was even more restrictive since it was NFS over Secure RPC). Which was the same as the case demonstrated in the orginal email, hence my mentioning of it. -- Darren J Moffat From Nicolas.Williams at ubsw.com Sat Jul 28 07:25:40 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 27 Jul 2001 17:25:40 -0400 Subject: Failed X11 authentication does the wrong thing In-Reply-To: <20010727133558.A22318@lucent.com>; from dwd@bell-labs.com on Fri, Jul 27, 2001 at 01:35:58PM -0500 References: <200107261940.f6QJeKS174995@jurassic.eng.sun.com> <20010727133558.A22318@lucent.com> Message-ID: <20010727172539.C5739@sm2p1386swk.wdr.com> On Fri, Jul 27, 2001 at 01:35:58PM -0500, Dave Dykstra wrote: > On Thu, Jul 26, 2001 at 03:51:40PM -0400, Nicolas Williams wrote: > > Ideally the X libs would support the same sort of concept as the > > ssh-agent but for accessing X cookies. > > > > In fact, I'd really like to see an all-purpose agent along the lines of > > ssh-agent, but not just for SSH keys: Kerberos ccaches, X cookies, NTLM > > hashes (think about Samba's smbsh/smbwrapper) and so on. > > > But ssh-agent suffers essentially the same problem when su-ing to other > user ids: the inherited environment variable only points to a unix-domain > socket that's accessible only by the original user and root. I was trying > to think of a way of passing the authentication through when you su to > another user. Yes, but, if you're suing to root, then you're doing so locally, and ssh-agent sockets are local, so root can access them. Yes, this breaks if you're suing to some other user, but then you can play permissions games with the agent's socket (it might be a useful feature to have a way to get the agent to create new sockets). If one could rely on open file descriptor inheritance (as much as one can rely on environment variable inheritance) then things would be easier, but, alas. > - Dave Dykstra Nico -- . Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From stenn at whimsy.udel.edu Sat Jul 28 13:05:47 2001 From: stenn at whimsy.udel.edu (Harlan Stenn) Date: Fri, 27 Jul 2001 23:05:47 -0400 Subject: Runtime problem with 2.9p2 on mips-dec-ultrix4.4 Message-ID: <4193.996289547@whimsy.udel.edu> I got 2.9p2 compiled and mostly working on mips-dec-ultrix4.4 . One problem I'm seeing when I try to ssh in to the box - I'm getting: sshd: error: open /dev/tty failed - could not set controlling tty: No such device or address out of sshd. Anybody have any ideas? Harlan From Markus.Friedl at informatik.uni-erlangen.de Sat Jul 28 19:03:20 2001 From: Markus.Friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 28 Jul 2001 11:03:20 +0200 Subject: OpenSSH-RSAAuth-NFS In-Reply-To: <002a01c11675$284e7660$0602a8c0@mcgarry.ch>; from tim@mcgarry.ch on Fri, Jul 27, 2001 at 10:21:36AM +0200 References: <002a01c11675$284e7660$0602a8c0@mcgarry.ch> Message-ID: <20010728110320.D22418@faui02.informatik.uni-erlangen.de> On Fri, Jul 27, 2001 at 10:21:36AM +0200, Tim McGarry wrote: > Here's a bunch of changes I've made to the current portable version of > OpenSSH. > > The aim is that the rsa_authentication flag in sshd_config can be given the > values "without-nfs" This is really handy within a large organization where > incorrectly secured home directories can allow authorized_keys(2) to be > modified by someone other than the owner. > > So now rsa_authentication can take the values (no,without-nfs,yes). Maybe it > would be better to use (no,yes,with-nfs). So it's an active decision that > the user has to make if the wish to allow authorized_keys(2) from nfs > mounts. > > I'd like to feed this enhancement back into the OpenBSD build, NFS security > is not just a problem that relates to Solaris. the security of NFS depends on how it is used. instead i suggest the AuthorizedKeysFile option from sshd. From markus.friedl at informatik.uni-erlangen.de Sat Jul 28 19:07:26 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 28 Jul 2001 11:07:26 +0200 Subject: comment on another command line option In-Reply-To: <3B606412.DC8F5EDE@oit.edu>; from gearond@oit.edu on Thu, Jul 26, 2001 at 11:40:18AM -0700 References: <3B606412.DC8F5EDE@oit.edu> Message-ID: <20010728110726.B1354@folly> you can use SSH_ASKPASS On Thu, Jul 26, 2001 at 11:40:18AM -0700, Dennis Gearon wrote: > I would like ssh to have the command line option of supplying the passphrase. > This would make it possible to do attendant free scp transfers from PHP, for > example. As it is, it is impossible to use a web script to initiate an scp xfer > if an encrypted private key is used. > > I realize that stupid people could make shell scripts or web scripts then with > the pass phrase in them, but those same stupid people are just as likely to walk > out in front of cars. The preferred method is to supply the passphrase through > an ssl connected web page/script for a one time use. > > without the ability to do attendant free scp transfers using pass phrased > private keys, the only remote to remote transfers that can be initiated by a web > script is via ssl, and that costs money for a certificate that most host's will > accept. > > schematic of intended usage. > > Me with SSL browser<----->My company website<------->client website to be > with PHP CASE TOOL edited with PHP > CASE TOOL From markus.friedl at informatik.uni-erlangen.de Sat Jul 28 18:53:37 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sat, 28 Jul 2001 10:53:37 +0200 Subject: Updated Cray patch against openssh SNAP-20010725 In-Reply-To: ; from jones@tacc.utexes.edu on Thu, Jul 26, 2001 at 08:45:02AM -0500 References: Message-ID: <20010728105336.A1354@folly> On Thu, Jul 26, 2001 at 08:45:02AM -0500, William L. Jones wrote: > packet.c - Add new subroutine to return an explicit signed > integer. i don't think you need this. an unsigned int should be ok in all cases. From walters at cis.ohio-state.edu Sun Jul 29 14:26:41 2001 From: walters at cis.ohio-state.edu (Colin Walters) Date: Sun, 29 Jul 2001 00:26:41 -0400 Subject: add version 2 identities by default, too Message-ID: <87itgcs6m6.church.of.emacs@space-ghost.verbum.org> [ I'm not subscribed to this list; please CC any followups to me as well ] When a user invokes "ssh-add" with no arguments, I think we should default to adding both version 1 and version 2 keys. Here's a patch against the source included with my Debian package of OpenSSH: walters at space-ghost:/usr/src/ssh/openssh-2.9p2$ diff -u ssh-add.c~ ssh-add.c --- ssh-add.c~ Thu Apr 19 16:33:08 2001 +++ ssh-add.c Sat Jul 28 23:49:01 2001 @@ -182,12 +182,63 @@ printf("The agent has no identities.\n"); } +void +add_default_identities(AuthenticationConnection *ac, int deleting) +{ + char identity_name[1024]; + char dsa_name[1024]; + char rsa_name[1024]; + struct passwd *pw = getpwuid(getuid()); + snprintf(identity_name, sizeof identity_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); + snprintf(rsa_name, sizeof rsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_RSA); + snprintf(dsa_name, sizeof dsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_DSA); + if (!pw) { + fprintf(stderr, "No user found with uid %u\n", + (u_int)getuid()); + ssh_close_authentication_connection(ac); + exit(1); + } else { + int identity_found = !access(identity_name, R_OK); + int rsa_found = !access(rsa_name, R_OK); + int dsa_found = !access(dsa_name, R_OK); + + if (!(identity_found || rsa_found || dsa_found)) { + fprintf(stderr, + "No files specified, and unable to find one of:\n%s\n%s\n%s\n", + + identity_name, + rsa_name, + dsa_name); + ssh_close_authentication_connection(ac); + exit(1); + } + if (identity_found) { + if (deleting) + delete_file(ac, identity_name); + else + add_file(ac, identity_name); + } + + if (rsa_found) { + if (deleting) + delete_file(ac, rsa_name); + else + add_file(ac, rsa_name); + } + + if (dsa_found) { + if (deleting) + delete_file(ac, dsa_name); + else + add_file(ac, dsa_name); + } + } +} + int main(int argc, char **argv) { AuthenticationConnection *ac = NULL; - struct passwd *pw; - char buf[1024]; int no_files = 1; int i; int deleting = 0; @@ -220,26 +271,16 @@ no_files = 0; continue; } + no_files = 0; if (deleting) delete_file(ac, argv[i]); else add_file(ac, argv[i]); } - if (no_files) { - pw = getpwuid(getuid()); - if (!pw) { - fprintf(stderr, "No user found with uid %u\n", - (u_int)getuid()); - ssh_close_authentication_connection(ac); - exit(1); - } - snprintf(buf, sizeof buf, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); - if (deleting) - delete_file(ac, buf); - else - add_file(ac, buf); - } + if (no_files) + add_default_identities(ac, deleting); + clear_pass(); ssh_close_authentication_connection(ac); exit(0); walters at space-ghost:/usr/src/ssh/openssh-2.9p2$ cd /usr/src/ssh/openssh-2.9p2/ diff -u /usr/src/ssh/openssh-2.9p2/ssh-add.1\~ /usr/src/ssh/openssh-2.9p2/ssh-add.1 --- /usr/src/ssh/openssh-2.9p2/ssh-add.1~ Wed Apr 11 11:59:36 2001 +++ /usr/src/ssh/openssh-2.9p2/ssh-add.1 Sun Jul 29 00:22:11 2001 @@ -51,10 +51,12 @@ .Nm adds RSA or DSA identities to the authentication agent, .Xr ssh-agent 1 . -When run without arguments, it adds the file -.Pa $HOME/.ssh/identity . -Alternative file names can be given on the command line. -If any file requires a passphrase, +When run without arguments, it looks for any of +.Pa $HOME/.ssh/identity , +.Pa $HOME/.ssh/id_rsa , and +.Pa $HOME/.ssh/id_dsa , +and adds them if present. Alternative file names can be given on the +command line. If any file requires a passphrase, .Nm asks for the passphrase from the user. The Passphrase it is read from the user's tty. @@ -88,9 +90,6 @@ It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file. -This is the default file added by -.Nm -when no other files have been specified. .It Pa $HOME/.ssh/id_dsa Contains the protocol version 2 DSA authentication identity of the user. .It Pa $HOME/.ssh/id_rsa Diff finished at Sun Jul 29 00:22:17 From mouring at etoh.eviladmin.org Sun Jul 29 15:04:08 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 29 Jul 2001 00:04:08 -0500 (CDT) Subject: add version 2 identities by default, too In-Reply-To: <87itgcs6m6.church.of.emacs@space-ghost.verbum.org> Message-ID: On Sun, 29 Jul 2001, Colin Walters wrote: > [ I'm not subscribed to this list; please CC any followups to me as > well ] > > When a user invokes "ssh-add" with no arguments, I think we should > default to adding both version 1 and version 2 keys. Here's a patch > against the source included with my Debian package of OpenSSH: > > walters at space-ghost:/usr/src/ssh/openssh-2.9p2$ diff -u ssh-add.c~ ssh-add.c > --- ssh-add.c~ Thu Apr 19 16:33:08 2001 > +++ ssh-add.c Sat Jul 28 23:49:01 2001 > @@ -182,12 +182,63 @@ > printf("The agent has no identities.\n"); > } > > +void > +add_default_identities(AuthenticationConnection *ac, int deleting) > +{ > + char identity_name[1024]; > + char dsa_name[1024]; > + char rsa_name[1024]; > + struct passwd *pw = getpwuid(getuid()); > + snprintf(identity_name, sizeof identity_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); > + snprintf(rsa_name, sizeof rsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_RSA); > + snprintf(dsa_name, sizeof dsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_DSA); Correct me if I'm wrong.. But this looks wrong.. Using pw before checking to ensure it's valid?! That just seems like asking for trouble. - Ben > + if (!pw) { > + fprintf(stderr, "No user found with uid %u\n", > + (u_int)getuid()); > + ssh_close_authentication_connection(ac); > + exit(1); > + } else { To me it the creation and population of those variables should be here. Where you know at least the pw has been populated with something that looks like data. > + int identity_found = !access(identity_name, R_OK); > + int rsa_found = !access(rsa_name, R_OK); > + int dsa_found = !access(dsa_name, R_OK); > + [..] - Ben From walters at cis.ohio-state.edu Sun Jul 29 18:28:53 2001 From: walters at cis.ohio-state.edu (Colin Walters) Date: Sun, 29 Jul 2001 04:28:53 -0400 Subject: add version 2 identities by default, too In-Reply-To: (mouring@etoh.eviladmin.org's message of "Sun, 29 Jul 2001 00:04:08 -0500 (CDT)") References: Message-ID: <8766ccrvei.church.of.emacs@space-ghost.verbum.org> mouring at etoh.eviladmin.org writes: > Correct me if I'm wrong.. But this looks wrong.. Using pw before > checking to ensure it's valid?! That just seems like asking for > trouble. Sorry, yes, you're right. That's very embarassing... Here's what is hopefully a better patch: cd /usr/src/ssh/openssh-2.9p2/ diff -u /usr/src/ssh/openssh-2.9p2/ssh-add.c /usr/src/ssh/openssh-2.9p2.new/ssh-add.c --- /usr/src/ssh/openssh-2.9p2/ssh-add.c Thu Apr 19 16:33:08 2001 +++ /usr/src/ssh/openssh-2.9p2.new/ssh-add.c Sun Jul 29 04:19:34 2001 @@ -182,12 +182,63 @@ printf("The agent has no identities.\n"); } +void +add_default_identities(AuthenticationConnection *ac, int deleting) +{ + char identity_name[1024]; + char dsa_name[1024]; + char rsa_name[1024]; + int identity_found, dsa_found, rsa_found; + struct passwd *pw = getpwuid(getuid()); + if (!pw) { + fprintf(stderr, "No user found with uid %u\n", + (u_int)getuid()); + ssh_close_authentication_connection(ac); + exit(1); + } + snprintf(identity_name, sizeof identity_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); + snprintf(rsa_name, sizeof rsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_RSA); + snprintf(dsa_name, sizeof dsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_DSA); + identity_found = !access(identity_name, R_OK); + rsa_found = !access(rsa_name, R_OK); + dsa_found = !access(dsa_name, R_OK); + + if (!(identity_found || rsa_found || dsa_found)) { + fprintf(stderr, + "No files specified, and unable to find one of:\n%s\n%s\n%s\n", + + identity_name, + rsa_name, + dsa_name); + ssh_close_authentication_connection(ac); + exit(1); + } + if (identity_found) { + if (deleting) + delete_file(ac, identity_name); + else + add_file(ac, identity_name); + } + + if (rsa_found) { + if (deleting) + delete_file(ac, rsa_name); + else + add_file(ac, rsa_name); + } + + if (dsa_found) { + if (deleting) + delete_file(ac, dsa_name); + else + add_file(ac, dsa_name); + } +} + int main(int argc, char **argv) { AuthenticationConnection *ac = NULL; - struct passwd *pw; - char buf[1024]; int no_files = 1; int i; int deleting = 0; @@ -220,26 +271,16 @@ no_files = 0; continue; } + no_files = 0; if (deleting) delete_file(ac, argv[i]); else add_file(ac, argv[i]); } - if (no_files) { - pw = getpwuid(getuid()); - if (!pw) { - fprintf(stderr, "No user found with uid %u\n", - (u_int)getuid()); - ssh_close_authentication_connection(ac); - exit(1); - } - snprintf(buf, sizeof buf, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); - if (deleting) - delete_file(ac, buf); - else - add_file(ac, buf); - } + if (no_files) + add_default_identities(ac, deleting); + clear_pass(); ssh_close_authentication_connection(ac); exit(0); Diff finished at Sun Jul 29 04:28:34 cd /usr/src/ssh/openssh-2.9p2/ diff -u /usr/src/ssh/openssh-2.9p2/ssh-add.1 /usr/src/ssh/openssh-2.9p2.new/ssh-add.1 --- /usr/src/ssh/openssh-2.9p2/ssh-add.1 Wed Apr 11 11:59:36 2001 +++ /usr/src/ssh/openssh-2.9p2.new/ssh-add.1 Sun Jul 29 00:22:11 2001 @@ -51,10 +51,12 @@ .Nm adds RSA or DSA identities to the authentication agent, .Xr ssh-agent 1 . -When run without arguments, it adds the file -.Pa $HOME/.ssh/identity . -Alternative file names can be given on the command line. -If any file requires a passphrase, +When run without arguments, it looks for any of +.Pa $HOME/.ssh/identity , +.Pa $HOME/.ssh/id_rsa , and +.Pa $HOME/.ssh/id_dsa , +and adds them if present. Alternative file names can be given on the +command line. If any file requires a passphrase, .Nm asks for the passphrase from the user. The Passphrase it is read from the user's tty. @@ -88,9 +90,6 @@ It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file. -This is the default file added by -.Nm -when no other files have been specified. .It Pa $HOME/.ssh/id_dsa Contains the protocol version 2 DSA authentication identity of the user. .It Pa $HOME/.ssh/id_rsa Diff finished at Sun Jul 29 03:57:54 From markus.friedl at informatik.uni-erlangen.de Sun Jul 29 23:54:10 2001 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Sun, 29 Jul 2001 15:54:10 +0200 Subject: add version 2 identities by default, too In-Reply-To: <8766ccrvei.church.of.emacs@space-ghost.verbum.org>; from walters@cis.ohio-state.edu on Sun, Jul 29, 2001 at 04:28:53AM -0400 References: <8766ccrvei.church.of.emacs@space-ghost.verbum.org> Message-ID: <20010729155410.A31927@folly> perhaps i'm going to add something similar, probably using a for() loop. On Sun, Jul 29, 2001 at 04:28:53AM -0400, Colin Walters wrote: > mouring at etoh.eviladmin.org writes: > > > Correct me if I'm wrong.. But this looks wrong.. Using pw before > > checking to ensure it's valid?! That just seems like asking for > > trouble. > > Sorry, yes, you're right. That's very embarassing... > > Here's what is hopefully a better patch: > > cd /usr/src/ssh/openssh-2.9p2/ > diff -u /usr/src/ssh/openssh-2.9p2/ssh-add.c /usr/src/ssh/openssh-2.9p2.new/ssh-add.c > --- /usr/src/ssh/openssh-2.9p2/ssh-add.c Thu Apr 19 16:33:08 2001 > +++ /usr/src/ssh/openssh-2.9p2.new/ssh-add.c Sun Jul 29 04:19:34 2001 > @@ -182,12 +182,63 @@ > printf("The agent has no identities.\n"); > } > > +void > +add_default_identities(AuthenticationConnection *ac, int deleting) > +{ > + char identity_name[1024]; > + char dsa_name[1024]; > + char rsa_name[1024]; > + int identity_found, dsa_found, rsa_found; > + struct passwd *pw = getpwuid(getuid()); > + if (!pw) { > + fprintf(stderr, "No user found with uid %u\n", > + (u_int)getuid()); > + ssh_close_authentication_connection(ac); > + exit(1); > + } > + snprintf(identity_name, sizeof identity_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); > + snprintf(rsa_name, sizeof rsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_RSA); > + snprintf(dsa_name, sizeof dsa_name, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_ID_DSA); > + identity_found = !access(identity_name, R_OK); > + rsa_found = !access(rsa_name, R_OK); > + dsa_found = !access(dsa_name, R_OK); > + > + if (!(identity_found || rsa_found || dsa_found)) { > + fprintf(stderr, > + "No files specified, and unable to find one of:\n%s\n%s\n%s\n", > + > + identity_name, > + rsa_name, > + dsa_name); > + ssh_close_authentication_connection(ac); > + exit(1); > + } > + if (identity_found) { > + if (deleting) > + delete_file(ac, identity_name); > + else > + add_file(ac, identity_name); > + } > + > + if (rsa_found) { > + if (deleting) > + delete_file(ac, rsa_name); > + else > + add_file(ac, rsa_name); > + } > + > + if (dsa_found) { > + if (deleting) > + delete_file(ac, dsa_name); > + else > + add_file(ac, dsa_name); > + } > +} > + > int > main(int argc, char **argv) > { > AuthenticationConnection *ac = NULL; > - struct passwd *pw; > - char buf[1024]; > int no_files = 1; > int i; > int deleting = 0; > @@ -220,26 +271,16 @@ > no_files = 0; > continue; > } > + > no_files = 0; > if (deleting) > delete_file(ac, argv[i]); > else > add_file(ac, argv[i]); > } > - if (no_files) { > - pw = getpwuid(getuid()); > - if (!pw) { > - fprintf(stderr, "No user found with uid %u\n", > - (u_int)getuid()); > - ssh_close_authentication_connection(ac); > - exit(1); > - } > - snprintf(buf, sizeof buf, "%s/%s", pw->pw_dir, _PATH_SSH_CLIENT_IDENTITY); > - if (deleting) > - delete_file(ac, buf); > - else > - add_file(ac, buf); > - } > + if (no_files) > + add_default_identities(ac, deleting); > + > clear_pass(); > ssh_close_authentication_connection(ac); > exit(0); > > Diff finished at Sun Jul 29 04:28:34 > > cd /usr/src/ssh/openssh-2.9p2/ > diff -u /usr/src/ssh/openssh-2.9p2/ssh-add.1 /usr/src/ssh/openssh-2.9p2.new/ssh-add.1 > --- /usr/src/ssh/openssh-2.9p2/ssh-add.1 Wed Apr 11 11:59:36 2001 > +++ /usr/src/ssh/openssh-2.9p2.new/ssh-add.1 Sun Jul 29 00:22:11 2001 > @@ -51,10 +51,12 @@ > .Nm > adds RSA or DSA identities to the authentication agent, > .Xr ssh-agent 1 . > -When run without arguments, it adds the file > -.Pa $HOME/.ssh/identity . > -Alternative file names can be given on the command line. > -If any file requires a passphrase, > +When run without arguments, it looks for any of > +.Pa $HOME/.ssh/identity , > +.Pa $HOME/.ssh/id_rsa , and > +.Pa $HOME/.ssh/id_dsa , > +and adds them if present. Alternative file names can be given on the > +command line. If any file requires a passphrase, > .Nm > asks for the passphrase from the user. > The Passphrase it is read from the user's tty. > @@ -88,9 +90,6 @@ > It is possible to > specify a passphrase when generating the key; that passphrase will be > used to encrypt the private part of this file. > -This is the default file added by > -.Nm > -when no other files have been specified. > .It Pa $HOME/.ssh/id_dsa > Contains the protocol version 2 DSA authentication identity of the user. > .It Pa $HOME/.ssh/id_rsa > > Diff finished at Sun Jul 29 03:57:54 From djm at mindrot.org Mon Jul 30 12:02:45 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 30 Jul 2001 12:02:45 +1000 (EST) Subject: comment on another command line option In-Reply-To: <200107270054.UAA28203@eworld.wox.org> Message-ID: On Thu, 26 Jul 2001, James Oden wrote: > Yes, or perhaps even having it just come from stdin. > Onetime I was working on a program that various things at > an elevated privledge for a web application. I set it up to > take its arguments via standard input. In this particular case I > choose to format the input simular to CGI-BIN parameters, mainly > because that was where my head was, but the main point is I could > easily start up the program in perl with a write pipe, and pass the > parameters without them showing up in the process table....james You can write an ssh-askpass replacement to do what you require. It just has to spit the passphrase out stdout. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Stephan.Hendl at lds.brandenburg.de Mon Jul 30 20:20:54 2001 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Mon, 30 Jul 2001 12:20:54 +0200 Subject: X11 changes between 2.5.1p2 and 2.9p2 Message-ID: Hello, I just upgraded one machine (HP-UX 11.0) from 2.5.1p2 to 2.9p2 and found that a hendl at host_a# ssh host_b works fine with authentication agent and X11 forwarding on but a hendl at host_b# su root at host_b# /usr/bin/X11/xclock afterwards gives errors like debug: X11 connection uses different authentication protocol. debug: X11 rejected 0 i1/o16 ... debug: X11 connection to ... broken... With version 2.5.1p2 these errors don't occur. What shell I do? Thanks regards Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 EMail: stephan.hendl at lds.brandenburg.de From vinschen at redhat.com Tue Jul 31 20:15:23 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 31 Jul 2001 12:15:23 +0200 Subject: [PATCH]: sftp: Avoid paths beginning with "//" In-Reply-To: <20010725110931.B490@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Jul 25, 2001 at 11:09:31AM +0200 References: <20010725110931.B490@cygbert.vinschen.de> Message-ID: <20010731121523.B19130@cygbert.vinschen.de> Hi, I would like to ask if somebody had a look into this patch and if anybody has a comment. I would like to push this a bit since it's really important for sftp clients on _any_ platform which have to communicate with sftp-server on a Windows platform. Corinna On Wed, Jul 25, 2001 at 11:09:31AM +0200, Corinna Vinschen wrote: > Hi, > > the following patch has been suggested by Mark Bradshaw > . > > The simple concatenation of filenames in sftp client and server > results in creating filenames beginning with double slashes > when the cwd is the root directory: > > cwd: "/bar/baz" > file: "foo" > cwd + "/" + file = "/bar/baz/foo" > > cwd: "/" > file: "foo" > cwd + "/" + file = "//foo" > > While that's no problem on U*X based OSes, it's a problem at least > on Windows platforms due to the fact that the "//" syntax is reserved > for network paths in the style "//server/share". > > So, if the above concatenation occurs a Windows box desperately > tries to contact a remote box called "foo" instead of trying to > access file "/foo". > > The below patch is least intrusive, IMO. It simply checks if the > directory is "/" before concatenation and avoids to add another > "/" then. > > The problem is cross platform since the client is concerned as well. > The reason is that the path concatenation occurs partly on the > client side. So, if somebody starts an sftp client on a Sun box > to connect to an sftp-server on a Windows box, the same problem > occurs. That's the reason the patch is not `#ifdef'd' in any > way. > > Thanks, > Corinna > > > Index: sftp-int.c > =================================================================== > RCS file: /cvs/openssh_cvs/sftp-int.c,v > retrieving revision 1.27 > diff -u -p -r1.27 sftp-int.c > --- sftp-int.c 2001/07/14 02:19:37 1.27 > +++ sftp-int.c 2001/07/25 08:44:29 > @@ -204,7 +204,8 @@ path_append(char *p1, char *p2) > > ret = xmalloc(len); > strlcpy(ret, p1, len); > - strlcat(ret, "/", len); > + if (strcmp(p1, "/") != 0) > + strlcat(ret, "/", len); > strlcat(ret, p2, len); > > return(ret); > Index: sftp-server.c > =================================================================== > RCS file: /cvs/openssh_cvs/sftp-server.c,v > retrieving revision 1.34 > diff -u -p -r1.34 sftp-server.c > --- sftp-server.c 2001/07/04 03:32:33 1.34 > +++ sftp-server.c 2001/07/25 08:44:31 > @@ -756,8 +756,8 @@ process_readdir(void) > stats = xrealloc(stats, nstats * sizeof(Stat)); > } > /* XXX OVERFLOW ? */ > - snprintf(pathname, sizeof pathname, > - "%s/%s", path, dp->d_name); > + snprintf(pathname, sizeof pathname, "%s%s%s", path, > + strcmp(path, "/") ? "/" : "", dp->d_name); > if (lstat(pathname, &st) < 0) > continue; > stat_to_attrib(&st, &(stats[count].attrib)); -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From jakob at openbsd.org Tue Jul 31 22:43:12 2001 From: jakob at openbsd.org (jakob at openbsd.org) Date: Tue, 31 Jul 2001 14:43:12 +0200 (MEST) Subject: [PATCH]: sftp: Avoid paths beginning with "//" In-Reply-To: <20010731121523.B19130@cygbert.vinschen.de> Message-ID: On Tue, 31 Jul 2001, Corinna Vinschen wrote: > I would like to ask if somebody had a look into this patch and > if anybody has a comment. I've just committed this. jakob From vinschen at redhat.com Tue Jul 31 23:49:40 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 31 Jul 2001 15:49:40 +0200 Subject: [PATCH]: sftp: Avoid paths beginning with "//" In-Reply-To: ; from jakob@openbsd.org on Tue, Jul 31, 2001 at 02:43:12PM +0200 References: <20010731121523.B19130@cygbert.vinschen.de> Message-ID: <20010731154940.C490@cygbert.vinschen.de> On Tue, Jul 31, 2001 at 02:43:12PM +0200, jakob at openbsd.org wrote: > On Tue, 31 Jul 2001, Corinna Vinschen wrote: > > > I would like to ask if somebody had a look into this patch and > > if anybody has a comment. > > I've just committed this. > > jakob Thanks, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From Alana.Thompson at ubsw.com Tue Jul 31 23:53:36 2001 From: Alana.Thompson at ubsw.com (Alana.Thompson at ubsw.com) Date: Tue, 31 Jul 2001 14:53:36 +0100 Subject: Unavailability of wdr.com Message-ID: Dear Recipient, It has been noticed that you have been receiving internal e-mails addressed to you at the @wdr.com internet address. On 31st August 2001, this internet address will no longer be applicable to the bank, and you will therefore not receive the e-mail. Please ensure that any people or applications sending e-mails to you using the @wdr.com address, change to using the @ubsw.com internet address. If you need any help, please contact your local TSC or Help Desk. Regards, GMCC ******************************************** Projects Team Global Messaging Control Centre Perot Systems Corporation UBS Warburg e-Mail: alana.thompson at ubsw.com Tel: +44 (0)20 7568 4822 ******************************************** 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 peter at bj-ig.de Thu Jul 5 23:43:23 2001 From: peter at bj-ig.de (Peter Brueckner) Date: Thu, 5 Jul 2001 15:43:23 +0200 (MEST) Subject: Feature request + patch for automatic portforward Message-ID: <200107051343.f65DhNv01305@peter.bj-ig.de> Hello developers, One off our applications requires that the users logs into the machine (secure), than starts an application and this application makes an back-connect to the client-machine. That sounds exactly like x11 but it works different and it needs an x11 like mechanism but not so special. The current source wouldt give the possibility to generate and backconnect with -R "0:otto:9999" because the bind with 0 as port gives an autoallocated nonreserved port over 1024, but unfortunately there is an test if (port < IPPORT_RESERVED && !is_root) in the source, that revokes this. With an little patch for this and an little hack for storing the autallocated port and giving that port to the environment of the executed process: SSH_AUTOPORT=23232 the problem wouldt be solved. here a patch against 2.9p2: (cvs-version was not compilable on my linux-2.4.5-machine) ----------------------- snip ---------------------------------------- diff -cr openssh-2.9p2/channels.c openssh-2.9p2-patched/channels.c *** openssh-2.9p2/channels.c Wed Jun 13 21:18:05 2001 --- openssh-2.9p2-patched/channels.c Wed Jul 4 08:18:03 2001 *************** *** 87,92 **** --- 87,96 ---- */ static int channel_max_fd = 0; + /* current return value for forwarding from automatical allocated + ports. goes to environmens SSH_AUTOPORT */ + static int current_autoport = 0; + /* Name and directory of socket for authentication agent forwarding. */ static char *channel_forwarded_auth_socket_name = NULL; static char *channel_forwarded_auth_socket_dir = NULL; *************** *** 1797,1802 **** --- 1801,1807 ---- struct linger linger; success = 0; + current_autoport = 0; if (remote_fwd) { host = listen_address; *************** *** 1873,1878 **** --- 1878,1892 ---- strlcpy(channels[ch].path, host, sizeof(channels[ch].path)); channels[ch].host_port = port_to_connect; channels[ch].listening_port = listen_port; + if (listen_port==0) { + struct sockaddr_in cli_addr; + int addrlen=sizeof(cli_addr); + if (getsockname(sock,(struct sockaddr *)&cli_addr,&addrlen)!=0) { + error("getsockname: %.100s", strerror(errno)); + } + current_autoport=ntohs((u_short)cli_addr.sin_port); + debug("Forwarding autoport %d.", current_autoport); + } success = 1; } if (success == 0) *************** *** 1962,1968 **** * Check that an unprivileged user is not trying to forward a * privileged port. */ ! if (port < IPPORT_RESERVED && !is_root) packet_disconnect("Requested forwarding of port %d but user is not root.", port); #endif --- 1976,1982 ---- * Check that an unprivileged user is not trying to forward a * privileged port. */ ! if (port && port < IPPORT_RESERVED && !is_root) packet_disconnect("Requested forwarding of port %d but user is not root.", port); #endif *************** *** 2815,2818 **** --- 2829,2836 ---- packet_put_int(c->remote_id); packet_put_int(c->local_window); packet_send(); + } + + int channel_get_autoport() { + return current_autoport; } diff -cr openssh-2.9p2/channels.h openssh-2.9p2-patched/channels.h *** openssh-2.9p2/channels.h Wed Jun 13 21:18:05 2001 --- openssh-2.9p2-patched/channels.h Wed Jul 4 08:16:08 2001 *************** *** 310,314 **** --- 310,315 ---- int x11_connect_display(void); int channel_find_open(void); + int channel_get_autoport(void); #endif diff -cr openssh-2.9p2/session.c openssh-2.9p2-patched/session.c *** openssh-2.9p2/session.c Sun Jun 17 05:40:51 2001 --- openssh-2.9p2-patched/session.c Wed Jul 4 08:16:54 2001 *************** *** 116,121 **** --- 116,122 ---- /* proto 2 */ int chanid; int is_subsystem; + int autoport; }; /* func */ *************** *** 376,381 **** --- 377,384 ---- } debug("Received TCP/IP port forwarding request."); channel_input_port_forward_request(s->pw->pw_uid == 0, options.gateway_ports); + s->autoport=channel_get_autoport(); + success = 1; break; *************** *** 1276,1281 **** --- 1279,1289 ---- if (s->ttyfd != -1) child_set_env(&env, &envsize, "SSH_TTY", s->tty); + if (s->autoport) { + char buffer[100]; + snprintf(buffer,sizeof(buffer),"%d",s->autoport); + child_set_env(&env, &envsize, "SSH_AUTOPORT", buffer); + } if (s->term) child_set_env(&env, &envsize, "TERM", s->term); if (s->display) -------------------------------- snap -------------------------------------- Thanks Peter Brueckner -- Peter Brueckner, Brueckner&Jarosch Ing.-GmbH Erfurt, Germany 99084 Andreasstr. 37, TEL +49=361-21240.12, FAX .19, MAIL peter at bj-ig.de,-42-